« Orchestration and choreography | Main | Who will take BPM into the future? »

The previous blog entry discussed Web service orchestration and choreography, and asked: what is their true relationship?

To understand this, we need to step back for a moment. It is possible to view the entire history of computing as a gradual move from “imperative” to “declarative” technologies (see the previous blog entry for an explanation of these terms). The continual emergence of higher- and higher-level programming languages and frameworks, the introduction of technologies like SQL and HTML where the intended results are specified not the means of achieving them, the inclusion in operating systems of techniques to install, update and repair program configuration, the use of business rules in enterprise systems, the introduction of “autonomic” systems that know how to maintain themselves, … all these and many more aspects of modern computer science are aimed at removing from the user the burden of knowing how things should be done.

Essentially, the fundamental aim of computer science innovators has always been the same - that people should be able to tell computers what they would like done, then let their machines figure out, as well as carry out, the actions required to make this happen.

How does this relate to Web services? From this perspective, the eventual aim of computer science is for orchestration to be done automatically, based on choreography. And there is nothing preventing this vision from coming to pass. The emerging standard for Web services choreography is WS-CDL. And it has already been demonstrated that, in theory, enough information can be placed in a WS-CDL process description to generate a complete executable process implementation. Though the demonstration presented is only partial, and there are issues to be resolved in order to provide a complete solution, there seem to be no theoretical barriers to doing so.

Hence, it is to be expected that, in due course, organizations will not install software tools for specifying executable processes. Rather, they will install software tools for creating process descriptions – and agreeing on these descriptions with business partners. Once an agreement has been made on a particular description, each party will let their own systems generate an executable process for their part of the description. The generation of each party’s executable process will be based on the business rules they have set up to describe how their business practices are implemented via Web services - what some people would think of as their SOA, though this is a poor use of the term.

It is interesting to consider how the parties will make agreements on process descriptions. This is a business process, of course – but not one that can be described using WS-CDL. Such negotiation is too flexible, adaptive and dynamic. To support collaborative human work processes of this kind, the techniques of Human Interaction Management (HIM) are required – along with supporting software tools. I’ll be saying more about this in future blog entries.

For now, and picking up where the previous blog entry left off, what is particularly interesting about WS-CDL is that it takes as direct inspiration the pi-calculus of Robin Milner. In other words, it has a formal underpinning. You can use WS-CDL to assert things about business processes (for example, that in a particular situation A, a certain response B will be made) - and then ensure that this happens automatically. There are already open source tools energing to support such controls. This may not be how the third wave visionaries predicted that BPM would evolve, but it fulfils their dream: that BPM would allow businesses to regain control of their applications via mathematical techniques invisible to the user, but vital for the analyst.

To summarise the above discussion - previous blog entries showed how BPMN effectively renders BPEL unnecessary. On the basis of the discussion here, one can predict that BPMN itself will most likely become obsolete in future. All that is required is the maturation of current prototype techniques for generating executable processes from WS-CDL - at which point the BPM third wave will finally have become a reality.

And then what? The development of a graphical notation for WS-CDL, of course (which is not currently part of the W3C charter). Such a notation will need its own XML representation - let’s suppose this is called CDL-XMI. CDL-XMI will have to be more fully-featured than WS-CDL, to support storage of diagram layout for example. In fact, CDL-XMI will make WS-CDL itself obsolete, since (as shown in a previous blog entry for BPMN and BPEL), you will be able to generate WS-CDL automatically from CDL-XMI – and if you can generate it automatically, why bother at all? Just use CDL-XMI as your process description language. In fact, there are graphical process notations in existence today that could be used to generate WS-CDL, and that have a native XML representation, so this vision may not be as far away as it seems.

So it’s not only goodbye BPEL. Eventually, and perhaps sooner than expected, it will be goodbye BPMN and even goodbye WS-CDL too! But in the meantime, WS-CDL offers the enterprise a more promising way forward for business process description than any other technique currently available.

In the next and (for now) concluding entry of this blog series on BPM futures, I will use the analysis above to look at the type of software vendors best positioned to take business process automation forwards. We will see that the next generation of BPM tools will come neither from platform vendors nor from BPM pure-plays, but from another source entirely.

TAKE AWAY

It’s not only standards bodies that would be well-advised to start thinking now about these issues – it’s any current or prospective user of tools based on BPMN and WS-CDL.

For a start, ask your process support vendors what they think about this discussion, and how they will make sure that your business processes are forwards-compatible as current standards migrate inevitably towards more sophisticated solutions based on executable process generation. You might not get a very useful response at this stage, but at least you’ll get them thinking.

And in the meantime, you should be looking carefully at your own process mapping efforts – are they biased more towards orchestration or towards choreography? If it is the former, it would be worth redressing the balance now, so that your organization is prepared for the change towards executable process generation when it comes. It may be years away rather than months, but things move fast in the Internet age, when new tools often emerge, mature, and acquire a large user base much more quickly than anyone expects. If you have descriptions of all your many processes in WS-CDL, you will certainly be better prepared to benefit from the transition than your competitors.

PS

Various people have written to me to ask why these blog entries on BPM futures are being presented as a series of cliff-hangers :-)

It is because blog entries are generally, by convention:

1. Shorter than articles or white papers, typically paragraphs rather than pages long


2. Posted often, typically more than once a week

So I am trying to make this blog fit the accepted practice by breaking rather long chains of argument into small pieces, posting them in succession over a short period, and encouraging the reader to follow the entire series. If you would like to keep up with new entries as soon as possible, I generally post on Tuesday and Thursday mornings. You could also use one of the many free RSS aggregators to check on the status of this and other blogs.

Posted by keithhb in Business Process Management • Service-Orientated Architecture |Digg This|Add to del.icio.us

Posted by: Steve Ross-Talbot at March 13, 2006 10:00 PM