We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

Will BPM eventually replace traditional programming as a way for businesses to rapidly deploy IT solutions for their business problems?

Vote 0 Votes
Suggested by Scott Menter, will BPM eventually replace traditional programming as a way for businesses to rapidly deploy IT solutions for their business problems?

17 Replies

| Add a Reply
  • It will. We've had a steady march of programming languages, each a higher level of the next, allowing us first to ignore 0's and 1's, then assembler, then C. It is only natural that this march will take us to the point where business process (the only reason other than accounting that this all started) is the higher level language. We're just one generation away, I suspect. That doesn't mean there won't need to be network and integration people...there just won't need to be people coding functionality within the enterprise.

  • That presumes you can do everything in a Visual Programming Language of X number of artifacts that you can do with code, which is far from true. Given studies show that most people only use a few (a dozen or so) primary BPMN artifacts, it means they are primarily using BPMS for relatively simple apps that can be largely managed at the business level.

    If you assume all things re: interoperability and functionality are performed by external services, then BPMN is dependent on traditional programming.

    It is fair to say Visual Modeling will improve and continue grow as a share of development efforts.

  • The shift is already taking place.

    I wrote about this in 2010, where BPMS could eventually replace COTS software (Commercially Off The Shelf):


    Since then what we've seen is a rapid move from simply Process-centric tools to Application-centric (with still process at the core) and now towards Enterprise-centric platforms. BPMS is slowly losing the 'P' for Process to being 'P' for Platform. Larger vendors are no longer content with just picking up small pieces of the organisational pie, they are vying for the whole enterprise now and being the application and process platform of choice that underpins it all. And with that comes the dilemma and complexity of learning not an open development language but a closed proprietary one.

    The old question of "Do I build or buy?" is now replaced with "What do I buy to build?"

  • For this to become true, BPM needs to integrate with more general model-driven approaches, covering all the aspects of software application design.
    This will let BPM become widespread in the enterprise not only in terms of usage but also in term of modeling. In other words, BPM + MDE (Model Driven Engineering), with the support of appropriate software management and automation tools, will enable even users to work directly on the realization of enterprise applications.
    So far, this has been limited to situational applications, where IT department were perceived as a barrier to flexibility and speed of development. But I see it as the future of the enterprise.
    This is also the vision we are trying, on a smaller scale, to pursue with our WebRatio tool suite (http://www.webratio.com) which blends BP models, user interaction models, and Web service models, and provides one-click application deployment from models.

  • As programming languages become more sophisticated and further from the native code, the more they will look like a BPMS. Salesforce.com's Force development environment is a classic case in point.

    But as several people have noted, we will still need highly qualified developers to do the difficult bits; architecture and integration.

    Finally, let's not pretend that a few gifted analysts armed with BPMN will be able to eliminate the need for SAP.

  • As usual one issue with that question is term definition. In general BPM is both used for the methodology and the related software products. I tend to refer to the software as BPMS and it is quite obvious that BPMS are mostly used for application development and not to execute process management or implement BPM methodology.

    The reason is that current BPMS are utterly unsuited to actually do so: http://isismjpucher.wordpress.com/2012/08/27/bpm-vs-bpms-how-to-think-big-and-act-small/

    For a BPMS to be feasible as an application platform, it needs to use a model-driven approach - sans 'engineering' - to succeed in the long-term. The main problem with that is that most BPMS only cover a small percentage of the needed functionality and require a substantial integration effort and add-on programming. That is a long-term waste of money. Only some as Appian or Pegasystem have most of the pieces (process, rules, forms, events, rules), but still lack the content capabilities that we know are essential. Not just scanned content, but business content creation by the business users!

    Without content there is no business and no app and it is not doable with MS-Word. Most content for applications and processes today is actually hard-coded in various programming languages ... utterly amazing: http://isismjpucher.wordpress.com/2012/02/04/digital-landfills-spam-versus-content-is-the-process/

  • I believe that will be necessary in order to run a competitive business, open for change. One challenge though will be to have Solution Architects and Developers to think in terms of processes-orientation instead of object-orientation. This transformation has so far been driven by SOA enthusiasts with IT objectives. This is where BPM and SOA needs to work together, this is where Business and IT needs to align their goals.

  • We live in a strange world, one in which programmers form a huge percentage of the employees of businesses having nothing to do with software. Surely that's unsustainable.

    I don't know that BPM (or BPMS, as Max would have it) alone will replace custom coding. But it's sure making a dent in it. When you can deploy sophisticated, highly-customized solutions to relatively complex challenges like customer onboarding, HR change requests, and capital expenditure management without writing a line of code, something has certainly changed. And that's just a fraction of what's already possible.

    On a related note, I'd argue this shift is not only good for companies, but good for programmers as well. But that's another topic for another day.

  • user-pic

    Considering the number of apps developed by programmers that are just GUIs to update databases with maybe some validation logic, even basic BPM products can certainly make a dent in how companies need in-house developers.

    Perhaps there are subtleties in some processes that are difficult to emulate with a BPM product that isn't bloated with features, but LISP tells us that it's possible to make something both powerful and simple.

  • To turn this into a question that makes sense, BPM must be BPMS, because many companies are excellent in BPM without any S.

    Latest research by Kelly BPM annoyalists ltd. showed that only 9.23 % of a performing process can be related to using a BPMS, the rest of process performance is depending on other aspects.

    But to be able to put business in the lead of any process initiative, some easy deployable BPMS for executing, monitoring, adjusting processes would have my preference.

    And if the vendor pays me a few bucks , I'm sure this percentage of 9.23% could rise easily for his product.

  • The day BPM/BPMS becomes able to replace traditional programming is the day the term becomes meaningless. BPM becomes everything, right?

    We've been through this wave previously. CASE tools, visual programming tools, 4GL's with aspirations, and the programming keeps going.

    If you *could* get it all in one "thing" - what do you call a tool that does some logic flow, some content management, some user interface manipulation, some data manipulation, some queries and reports... Might as well call it "business application development amorphous software suite." Lame acronym intended ;-). It's a BPMS in vendor focus only. It might evolve from a different class of software. And you will still need programming here and there to make it do exactly what you want.

    • What matter is system design. A flexible architecture separates rules from processes, from tasks, from data, from UI, etc.

      How this is implemented is less important. The programmer could either use traditional languages such as Java, best of breath within each discipline, or a golden hammer such as a BPMS. The downside with traditional tools is the lack flexibility when we change the business model. The downside with a BPMS is vendor lock-in. I would point any mature IT organization to work with tools that are specialized in there own discipline and make them work together based on industry standards.

  • Good to see general agreement. Let’s remember BPM is a discipline that puts people and their processes as the driver in any business. The big step is how is this recognised in “IT” delivering that dream or the quest as Bill Gates put it in 2008 where there is little reliance on coding? But this has been the vision of many for decades yet few have ventured to deliver. And when they do they face a huge challenge it is very disruptive and the big vendors will not like the consequences.

    One of the best articles comes from Naomi Bloom an experienced independent analyst http://infullbloom.us/?p=3222 the “object model driven” future for enterprise software creating a “moat” for vendors to cross. It will be driven by new entrants with unencumbered thinking I know we set out to do this 20 years ago!

    There are a few of fundamentals to be recognised
    1. Business logic never changes and should be separated from the ever changing delivery technologies
    2. People create all source information and when their work is analysed there are less that 13 work task types, human and system, that address all requirements
    3. People constantly need to react to new circumstances so any digitisation supporting their work needs to recognise this otherwise good processes as assets could quickly become liabilities?
    4. Legacy investment needs to be recognised and as such “collaboration” is not just about people it is about legacy data!

    If you are curious how follow some of the links in the Naomi’s article. Somewhat topically the core design can never be patented. By good fortune we caught Microsoft trying to patent the core capabilities but our prior art of some 10 years including some activity in the US ensures no one can “dominate” as this capability becomes the long over due step to commoditisation of business software. It starts by adopting the BPM discipline but I agree with Max BPMN will not be up to the job to handle the required flexibility. Following Theo’s thinking for BPMS the S becomes “solutions” or perhaps BPAS as Business Platform Adaptable Solutions?

  • Interesting discussion, the goal for such brainstorming is about how to enhance Lego style design to shortern software development cycle, similar to API as an architecture choice, not as technology choice: http://futureofcio.blogspot.com/2012/08/cio-as-producer-api-as-lego-blocks.html

    Process as building block does improve business maturity, still, BPM is not only about process automation, but also about process innovation and optimization. thanks.

  • Yes, this is reality already. Model driven technologies allow organizations to separate the rules (the 'know') from the process (the 'flow').
    Organizations basically describe what they do. This description is consequently modelled into an application and it can immediately be executed.
    It is literally possible to build for instance a tax system for any country in a couple of days...

    Opportunities to save enormous amounts of money are imminent

  • What needs to be added to this discussion is a what BPM(S) are used for, as programming replacement or not.

    I distinguish (following the lead of AIIM) between systems of record and systems of engagement (SOE). We will always have systems of record (SOR) and they are by design not practical to handle human interaction.

    So Adaptive Processes will not replace SOR, but will do away with the programming for SOE. Current orthodox BPMS will not do so as they are just a little bit more flexible than programming. The processes need to be in the hands of the people performing them.

    It is the SOR in which the 'legacy data' reside and clearly SOE make no sense without legacy data access in the SOR.

    Re: Vendor lock-in.
    One can not avoid vendor lock-in except if the business codes everything themselves and than they are locked in into their own ability to keep a proprietary system alive. It works a lot less than buying a fitting product.

Add a Reply

Recently Commented On

Monthly Archives