Posted by Jon Pyke

The automation of processes is a key enabler of the Cloud phenomena – without process the Cloud remains a passive environment that undoubtedly saves you money and removes some of the operational headaches, but does little else. The Cloud without process cannot deliver on the promise of Business Technology or the Service-Oriented Enterprise. All of the thoughts and ideas around assembling applications quickly to support a business imperative simply wont happen without process technology.

However we need to be very clear – process management in the cloud is not just about BPM Suites on demand. Indeed, the term BPM on Demand is beginning to take on a new meaning when used in conjunction with cloud computing.

The traditional use of the term “BPM on Demand” is often used to describe Software as a Service that delivers a BPM Suite as a Service, much like customer relationship management (CRM) applications are delivered as a service (e.g., Salesforce.com). Both use a pay per usage or subscription pricing model. BPMSaaS provies a full suite of BPM lifecycle capabilities, from modeling to deployment, and on to analysis and optimization. It’s a third party, Cloud hosted alternative to bringing in a BPM Suite in house. But there is much more to BPM on Demand than would at first appear to be the case. If we take the stance that the Cloud can deliver an infinite number of business software Services to all who need them, then we need a mechanism that makes that easy to orchestrate those Services and delivers the maximum flexibility. This is where a new meaning for “Process on Demand” comes in.

Process on Demand means having the capability to call up business Services when needed to change or augment a process that is already being executed.

This capability is in intrinsic part of the Service-Oriented Enterprise. The Services we are talking about are not the usual, fine-grained ones normally associated with the SOA world. These services are far more sophisticated than simple “get data/put data” activities. What we have are Services that contain:

• User Interface
• Business Rules
• Key Performance Indicators
• Meta data

In short, we have everything that makes a self-contained application all wrapped up as a Service that can be incorporated into an end-to-end business process.

Why do I need this type of capability? In a word Simplicity

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.

When developing business processes it is quite often very difficult to determine what will ultimately be needed in terms of documentation, sub-processes, timing and dependencies of tasks to accomplish some given requirement.  For example, in designing a process to handle an insurance claim for a traffic accident, the analyst may know that the customer will need to get his car assessed for repair and that a payment may or may not be forthcoming, but may not know the types of documentation (e.g., the mechanics costing, police witness reports, and hospital bills) that will potentially be required to process the claim, nor will he or she know the dynamics that determine which one or ones of possibly many documents to use.

These interrelated paths through the claim process may already have been defined by different people, in different parts of the organization as self-contained business Services or sub-processes, and may be changed frequently as the procedures and rules change. In such cases, it is not possible for the main claim process to determine, even dynamically, what particular Services to use.  All the developer knows is that a particular goal is to be achieved, but exactly which Service can be used to achieve it cannot be easily determined.  Nor, in fact, does the developer really care—he or she simply wants the goal accomplished in an appropriate way.

To solve this problem, we need a repository where we can keep the Services for use by the company. What differentiates these Services from sub-processes or data integration tools is that our Cloud applications know what each Service does, the circumstances in which it can be used, and the goals and outcomes that are required.   

This enables us to define which required Services are available “on demand.” By this means, the calling process simply needs to access a Service in the process flow, leaving it to the system to determine which business Service best achieves the goal in a given circumstance.  During the execution of the process all those Services that satisfy the goal are known so that on evaluation of a value or the detection of an event, the Service that is required can be incorporated and executed one second before the transaction occurs – making each iteration of the process totally different from and previous or subsequent processes depending on the dynamics in play at the time.

This approach improves significantly the development, agility, and scalability of business processes.  The main process is simple, the “happy path,” and is therefore easily understood. New services can be added or removed without any change whatsoever to the calling process or processes. So Process on Demand provides a simple and effective way of defining processes that completely encapsulate their definition in self-contained, semantically complete business Services, significantly increasing agility and scalability as a side effect.

This is the real power of BPM, SOA and the Cloud.

 

more about author