Business process management (BPM) is still a young area, with new products and technologies.
As with any new computing market, there are dozens of suppliers of pre-existing products who are rebadging them as BPM software. Sometimes this is reasonable, with the basic abilities of the product matching most of the criteria for a BPM application.
At other times it is done on the basis that there is "one born every minute". The stance of these suppliers is that if they say it loudly and often enough, people will believe their product is suitable for BPM. This is cheaper for them than building something new or re-engineering the existing product line. It is the sort of thing that happens whenever a new market emerges: you need to be on your guard against it.
Among the major changes confronting users and designers of BPM systems is the rise of service-based approaches to computing.
The way organisations manage their business processes continues to evolve. Many have workflow and electronic data management systems. Today's solution is to combine the basics of these with system integration tools and activity monitoring to give BPM software. Process management systems are now entering a third stage, which is about managing computing services and orchestrating them.
Computing services allow programs or entire systems to call for or provide services to other programs and processes. To take a simple example, the graphics part of a word processing program might send a command to a printer or retrieve a piece of clipart from storage.
A resource could be on the same machine, on the same network or separated by the internet. Working like this over the internet is often called web services. This uses XML and other standards to define its components. The rise of middleware and the emergence of the internet as a computing infrastructure have made this move to web services possible.
Whether communicating through web services or some other method, service requesters and providers should each be indifferent to where the other is. The requester simply sends out the call and, provided it is valid, the provider responds to it.
This kind of arrangement is known as "loosely coupled computing". In this, a program always communicates with the same, known resources.
There are, of course, many ways of defining how different programs and applets communicate in a loosely coupled arrangement or architecture. Inevitably, there is hot debate among their adherents about which method is the best. These debates do not concern us here. They are conducted at a high technical (and emotional) level and change almost weekly.
Corporate computing is thus increasingly a matter of connecting various computing service providers with requesters. This is changing the manner in which organisations deliver business services to their customers and interact with their suppliers, partners and employees.
Orchestrating these programs and services has become inevitably more complex. Higher levels of mass customisation and personalisation at websites demand a widening range of choices and interactions. Also, the technical environment is no longer the closed and controlled system long familiar to IT departments. It is open, unpredictable and rich with exceptions.
The result of these innovations is that organisations using these loosely coupled arrangements are no longer in direct control of the services other organisations provide.
Failures in delivery or processing, incomplete information and unanticipated responses are now the norm rather than the exception. Efforts to develop high-value application programs in this new business environment have proved mainly to be:
- Hard to change and extend
- Hard to validate
- Susceptible to failures and exceptions
- Unable to grow easily (scale)
- Unable to deliver the expected value.
From a technical perspective, workflow and BPM both provide users with a process architecture that has well-defined initiators and participants. Processes can be "workflow enabled" and made up of reusable sub-processes. Organisations can encapsulate the underlying process logic in a readily understandable way, which helps them become responsive (agile) and adaptable (flexible).
The newer approach, of orchestrating and managing services rather than programs, involves creating a service oriented architecture. This separates the what (process and metrics) from the how (resources provided by events and managed services). In short, processes become managed services. These can be loosely coupled, component-based and usable on various kinds of computer and operating systems. Above all, they become reusable.
Organisations need something to co-ordinate the interworking of all these reusable process elements. We call it the process event manager. This will take charge of, and synchronise, the way process components are extracted and linked to meet a specific process need. It will do so according to user-defined process templates that reside within the BPM software.
Much of what is wrapped up in the notion of BPM is well established, if not old. This is true of nearly all computer software and the way it is used. There are, however, important new ingredients in any new comprehensive BPM software which could offer real benefits to the business.
Jon Pyke is founder and president of The Process Factory and senior vice-president of technology strategy at Global 360. This article is based on an extract from his book Mastering Your Organisation's Processes published by Cambridge University Press