Interesting read from Jon Pyke on BPM on Demand.? He's pushing a vision of processes (and their component services) being available and provisioned "on demand" and assembled on the fly into working processes.
It's a great vision, but BPM isn't there yet.
The concept of Process on Demand enables you to build dynamic processes that can be changed ?on demand? to meet changing business needs. This dynamic process selection provides a substantial improvement in flexibility and agility and reduction in design complexity.? But we have to see if those advantages are sufficient enough to achieve the gains in agility, scalability, and robustness to meet the ever changing needs of today?s business environment.
The blog goes on to describe his new approach to process application development.? The conclusion:
What we have defined here constitutes an entirely different approach to the way we think about application development.? Providing services on demand removes almost all of the complexity of handling multiple options, exceptions, change, and uncertainty? all of that is transferred from the process developer to the system.? The consequences of which are dramatic. More complex applications can be built, far easier and faster simply because it is no longer necessary to encode all the special cases for dealing with a complex, unpredictable world.
This description is a bit too Utopian - someone still has to handle all those special cases and exceptions... that just doesn't go away entirely.? And the "entirely different approach to the way we think about application development" is actually exactly the approach that startups building applications in Amazon Web Services (and other cloud infrastructure providers) use to think about building applications.? So there's actually some proof in the world of this approach, outside of BPM.
Certainly it will be interesting if these "mashup" processes are manifested "on demand" as Jon describes.? This approach will work better for processes "outside the four walls" of a given business rather than internal processes that happen inside the four walls (Why? Because for the moment, critical internal systems aren't exposed via services to machines in the cloud).
Luckily, we don't have to jump straight from internally hosted, on-premise software to this Utopian dream.? There are shades of grey that are achievable today, and tomorrow... (more on that in a future post).