« The future of BPM | Main | Make the most of your intranet and extranet »

This is the concluding entry in a 5-part series on BPM futures. Previous blog entries showed that:

1. The imminent provision by the OMG of a standard XML format for BPMN will effectively render BPEL unnecessary
2. The adoption of BPMN for process definition means that business process automation will become a high-level graphical interface to component technologies, rather than a separate layer in enterprise architecture
3. By taking a computer science perspective, we can see that in due course Web service choreography will supersede Web service orchestration for the definition of those processes in which human involvement is limited to key decision and data entry points (what I call "mechanistic" processes)
4. Hence, forward-looking organizations need to consider now the creation of choreography descriptions, an activity for which the techniques of Human Interaction Management can be used: both to develop the processes needed to establish agreement on multi-party collaborative contracts, and to provide the graphical notation needed to depict the contracts themselves.

In this final blog entry (for now) on BPM futures, I will look at the type of software vendors best positioned to take business process automation forwards.

The argument above shows that business process automation is turning into a rather different sort of activity than has been supposed to date. As implemented by current BPM suites, business process automation is largely a matter of drawing flowcharts - effectively it is a sort of high-level, graphical programming. In fact, BPM competes directly with a combination of the UML and J2EE, for example. Though the picture painted by BPM vendors, and some analysts, is rather different, the battle could be considered a David vs Goliath one. I would happily bet that the total number of all BPM installations ever is nowhere even close to the average number of downloads of JBoss (say) in a single month - which in November 2005 was about 200K.

Of course, a BPM suite provides features that do not always come for free with a component-based approach to process automation - in particular, Business Activity Monitoring (BAM) - though here too technologies such as JMX are starting to provide a viable alternative. However, my point is simply that to date BPM has not become an ubiquitous part of enterprise technology, and this is because it is competing with other approaches that are mature and very well-established. Moreover, the people who are in the end responsible for implementing and maintaining BPM - the IT department and their outsourcing suppliers - are a lot more comfortable with J2EE or .NET than they are with a particular proprietary BPM toolset.

However, all this may change with the next generation of BPM tools. The argument that was made in previous blog entries, and that is outlined above, shows that business process automation will inevitably move towards the creation of multi-party collaborative contracts - where the parties may be internal to a single organization or span several organizations - and the use of these contracts to generate executable business processes. This is a very different kettle of fish from the usual software development process. Though agile methodologies, in particular, place an emphasis on negotiation and re-negotiation of client expectations, the future focus of BPM will be on the creation of agreements among several collaborating parties. BPM tools will then provide the means for each party to automatically turn their part in such agreements into working software.

Tools of this nature bear little relation to existing BPM products. But they do bear a strong relation to another class of products - those provided by vendors specializing in middleware to support Service-Orientated Architecture (SOA). SOA techniques are in flux at the moment, and there is a lot of debate among experts as to the benefits of a distributed vs centralized backbone, or the WS-* stack over simpler techniques such as REST and XML-over-HTTP. However, despite all this debate, there are some tenets to which most people adhere - in particular, the key technique of SOA is to establish what are generally called service contracts. There is little agreement among those in the field even on what a service is, but most agree that a service should expose some kind of description as to what it does. A service contract is a description of itself that a service publishes (somehow) - it is used by those that wish to call the service to determine what they can expect from it.

There is a strong parallel here to the direction in which business process automation is going. Both are based on the definition of contracts rather than on the definition of internal behaviour. SOA tools have not yet advanced to the point of being able to generate the latter from the former, but (as shown in the previous blog entry) there is every reason to suppose that this can and will be automated by software in due course.

There is a growing realization that the architectural principles emerging for the design of business processes by analysts (based on establishment of multi-party service contracts for collaborative behaviour) are the same as those already used by technicians in SOA. In fact, there is a strong argument that in a decentralized, globalized, Internet-enabled economy it will soon be hard to survive without applying such principles to the organization of your enterprise. As McKinsey wrote recently:

"the shift from transactional to tacit interactions requires companies to think differently about how to improve performance - and about their technology investments. Moreover, the rise of tacit occupations opens up the possibility that companies can again create capabilities and advantages that rivals can't easily duplicate."

Hence, it is realistic to expect that the next generation of tools for business process automation will come neither from platform vendors, nor from BPM pure-plays, but from vendors currently providing a complex, and to many people invisible, part of the IT middleware infrastructure - tools that come under such confusing and often overlapping categories as Web Services Management (WSM), Enterprise Service Bus (ESB), Enterprise System Management (ESM), and so on.

TAKE AWAY

In the next year or two, expect SOA to become high-profile among business leaders as well as technical folk - to become as much a management methodology as an approach to IT. This change will bring with it some key questions, related not only to development - how can we create a set of services, and agree on them with those responsible - but also to governance - what policies, procedures and other controls do we have in place for maintaining and regulating services? The SOA community is evolving some answers to these questions, but inevitably these answers are currently too IT-focused. If SOA is to successfully make the transition into a management approach, it needs to take on board the general principles and patterns that underpin business activity.

Such principles and patterns need not only to encompass diverse fields of business theory (quality management, knowledge management, project management, ...) but also insights from the many scientific disciplines connected with organizational life (psychology, biology, social systems theory, learning theory, and so on). Further, it is no good assembling such insights into a huge, diverse and confusing set of "best practices" - the consultant's favourite trick. They must be organized properly into a theory with a formal basis that provides the reassurance of sound thinking together with a structured and maintainable approach to implementation.

With respect to IT industry support for this move, expect SOA vendors to find an exciting new field opening up for them - the full support of mechanistic business processes, currently considered the domain of BPM tools. Those SOA vendors that embrace the move to declarative expression of processes descriptions, and automatic generation of process implementations, may well find themselves catapulted to a new and prominent level of visibility among business leaders.

PS

On a personal note, before publishing the ideas in this series I did not expect them to be met with much (or any) agreement. BPEL in particular is a focus of current IT industry interest, and consequent vendor investment. So it was a pleasant surprise not only to find that some influential people have already come to similar conclusions about BPEL - Phil Gilbert of Lombardi, for example, in his own blog - but also to receive many messages of support for the ideas in general. Whether you agree or disagree with the views expressed in the series, please let me know, either publicly via a blog comment or privately via email (see my bio). Private messages will of course be treated in confidence.

In the next blog entries, I will be looking at some of the most important open source software tools. I am continually surprised in my consulting work to find that organizations are paying for software that is less mature, less feature-rich and less well supported than that provided by the open source community. I will also discuss some of the situations in which open source is not a good idea.

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

Posted by: Martin Owen at March 22, 2006 01:14 PM