Beyond BPM: Runtime SOA

Beyond BPM: Runtime SOA

Summary: In an insightful essay, ZapThink's Ronald Schmelzer suggests that the factor that separates SOA from other past programming movements is business process. SOA, he contends, has the potential to take us beyond the current prison of Business Process Management (BPM).


In an insightful essay, ZapThink's Ronald Schmelzer suggests that the factor that separates SOA from other past programming movements is business process. SOA, he contends, has the potential to take us beyond the current prison of Business Process Management (BPM).

As he explains it, "BPM or workflow tools, often present a flowchart-type visual interface or natural language business rules engine that enable business analysts or their proxies in the IT organization to build a representation of the business process in a step-by-step fashion and then attach individual activities in a process to the company’s operations."

The problem? "[T]his approach to business process development and creation often suffers from the problem that the person who is responsible for creating the representation of the process either doesn’t know all the details of the business process at hand in sufficient depth, is not up-to-date with the current state of how a business process is actually working in the company, and/or doesn’t have knowledge of the whole process from end-to-end. As a result, most business process definition exercises often produce little more than 'shelfware' – that is, they end up creating nothing more than writing on paper that represents either the business process as it used to be, or the business process as it’s supposed to be, but never the business process as it actually is or will be."

Schmelzer makes the case for a "runtime business process model -- one in which a change to the model will in turn change the way that the business and its systems operate, and vice-versa, where a change to the business will automatically appear in the business process model. This bidirectional, runtime vision of business process should therefore be a key goal of any SOA implementation."

I encourage you to read the entire essay in which he explains how we might go about making this happen by separating "the notion of business logic and process from the underlying code that implements an individual task or step in a process."

While the conversation remains far too technicallly arcane and inaccessible to decision-makers at this point, Schmelzer takes a helpful step in the right direction by at least addressing today's SOA "cynics" -- and you know who you are -- in their own language.    

Topic: Enterprise Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Business "Nirvana"

    I agree with Ron. SOA is indeed one step forward in the abstraction of the process layer from the implementation layer.

    Basically, we should be able to layer business processes over the constituent application modules that comprise these business processes. The processes themselves could comprise and be composed from other finer-grained processes.

    The application modules that constitute the processes could in turn also be composites of other simpler and finer-grained modules. The modules could be physically distributed and implemented on different platforms using disparate object and programming models and APIs. Standardized interfaces to the constituent modules would enable these chunks of code to be packaged as services, thus enabling processes to be be configured/reconfigured from one or more of these services...presto : business agility!
  • Unravelling the Knot

    The two biggest reasons for BP-coding, or BPR, failure are:

    -1 - Friction between silos.

    For example; Finance becomes the lead department for a new billing cycle. Because Sales is not responsible for the programme's success or failure they appoint representatives to the change programme who:
    - Have no, or little, remit;
    - Have no, or little knowledge of the current process;
    - Have no, or little understanding of their department's needs.

    Business Process capture programs (e.g. Enterprise Resource Planning) suffer from this problem - only bigger. These projects are typically run by ICT departments (or an outside supplier!) who, by definition, know very little about any of the business processes involved. Is it any wonder that many such projects cost a mighty sum - and failed.

    - 2 - No CEO support.

    This was more in evidence in the BPR failures of the 1990s, but remains a factor.

    This is where the cynics draw their strength.

    The answer, increasingly, is to employ a Programme Manager (PM) - a highly politically charged role. However, so long as the PM has the confidence of the Board, and the overall strategy is properly defined at the start, there is no reason why a change management programme with a process focus cannot deliver accurate, timely, co-ordinated, flexible, efficient - and ICT supported - business processes.

    SOA service contracts can be introduced as part of any Business Process (BP)-coding, or Business Process Re-Engineering (BPR), programme. Indeed, I now consider them to be the easiest way of describing delivery of newly-coded BPs, and their flexibility, to non-ICT Chiefs.

    Ronald's column is an interesting one - but makes the mistake that I find myself addressing with almost every CIO. It keeps coming at the problem from an ICT-first perspective. There is an assumption that the business must be implementing Web Services with suppliers partners and customers, and (for large organisations) that they have legacy/middleware strategies and skills in XML and Schema development. It is not essential for these structures to be in place before starting to implement SOA, though it helps.

    It is also not essential, as I have said on ZDNet before, to redefine current ICT infrastructure as a set of SOA services right now. It is the business agreement on how change management is handled, and what flexibility really means to the business looking into the future, that are the keys to understanding best practice for implementing service oriented processes.

    Implementing SOA contracts in a change programme scenario helps to bridge the gap between current infrastructure and a full-service future. Current infrastructure can be described as 'fixed' elements in the services provided. This leaves the Board to decide which fixed elements most need to be upgraded to meet the strategic goals of each programme - and the flexibility needs of the business as a whole as they move forward. If they do this within the framework they have, themselves, agreed for change management then they will decide, case by case, how the SOA is built and defined.
    Stephen Wheeler
  • Runtime SOA: Another name for BPMS began the BPM movement in 2000. Its architecture includes what ZapThink call "run time SOA". The fact that a bunch of workflow and EAI vendors jumped on the BPM bandwagon and defined "BPM" as workflow has led to a lot of confusion. ZapThink have made the same mistake. BPM is not workflow. BPM include a process virtual machine (pvm) based on the new computing paradigm, Pi Calculus. If ZapThink want to call this "run time SOA", that's fine, as long as they realize its real name is BPM.

    Howard Smith, author and BPM innovator,
    • Howard's right

      Further to my point - Howard chimes in too.
      This stuff is not new.
      Its name is BPM. "Beyond" is redundant.
  • Missing so many points


    I believe ZapThink is a fair bit wide of the mark here. There are a number of holes in the analysis, future-gazing and recommendations:
    - the idea of a business process model which drives runtime systems is hardly new - just ask "BPMS" providers like Intalio (and no, I don't work for Intalio!)
    - the analysis assumes that business processes are encoded end-to-end in software - this is miles from the truth except for perhaps 5% of cases maximum (straight-through processing in financial services; billing in telecoms; etc) and belies a tech-focused mindset which doesn't take into account the complexity of real business
    - all Ron Schmelzer is really recommending is that we have tools which help us extend service contract metadata to include contextual constraints - which is very nice but hardly new - see Eiffel - and really doesn't help with the business process conundrum at all.

    ZapThink says some smart things, but this ain't one of them.
  • Hate to spoil the party

    but I hope the "decision makers" aren't listening to technical "experts" who believe it is possible to program anything in XML.

    I presume these "decision makers" are the same ones who didn't listen to the "cynics" who told them that reduplicating data would inevitably lead to inconsistencies, resulting in data that you cannot trust anymore. However the "decision makers" went straight out and bought individual "packages" that reduplicated data willy nilly.

    Surprisingly they now find they have a problem. Though the smarter ones have probably worked out that adding a whole load of additional programs all supplied by different suppliers on top of the mess they already have is unlikely to solve anything.

    The others are presumably busy blaming the mess they created on some kind of historical inevitability (shucks thats just how it is in IT) rather than accepting the fact that by ignoring data management fundamentals they have created a huge, expensive and unmanageable mess for which the customers and shareholders all pay.