BPM on Demand – Fantasy or Fast Track to Agility?

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 will not 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 BPM on Demand is often used to describe Software as a Service that delivers a BPM Suite as a Service (BPMSaaS) 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 provides 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. This approach is, without doubt, a key enabler for Cloud deployment. 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 we “Process on Demand” comes in.

Process On Demand

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.

In addition, each Service is tagged with the circumstances in which it can be used, defined as an “entry condition” for the process. The entry condition is a conditional statement defined over the case data and any sub-process parameters.  For example, the Service “Assess mechanical condition of vehicle” may be tagged with the entry condition “CarAge > 10” where CarAge is a field of the case data.  Other services would be similarly tagged.

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.

Modern BPM capabilities allow us to use different Services for different goals and desired outcomes – all with no coding required.

The important point is that the condition that defines the “applicability” of the Service is attached to the Service, not the calling process. The calling process need not know or specify  the selection criteria. This greatly simplifies the construction of the overall end-to-end process.  The developer of the overall process need not know how many Services are available to achieve the desired outcome, their names, or the criteria that determines their use —all that needs to be known is that at least one such service exists.

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. For example when an airplane lands at, say, London’s Heathrow Airport, a sequence of events (a process) is triggered to quickly and safely prepare the plane for its next flight. The top-line process – prepare plane – is always the same, but the companies and individuals performing the parts of the overall process will change according to time of day, availability of components (e.g., jet fuel), next destination and myriad other reasons. The important thing is that the plane has everything done to it that needs doing – regardless of the Services used. The needed Services are changed dynamically depending on need.

So Process On Demand

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.  However, how do we handle the exceptions, and less formal tasks of the case worker? What do we do when things don’t go to plan or they can’t be defined ahead of time ?

We all work in complex, unpredictable business environments. So to understand how process on demand can help we need to understand what people do. Knowledge workers have well defined objectives and goals but how they meet them depends on many factors – availability of documentation, response from others etc. Therefore they have to keep track of their goals and their current situation, and then choosing the sequence of tasks and processes that, given the situation they are in, can accomplish their needs.  In short, at each moment in time they select a process that gets them from where they are to where they want to be.  And they continue to do this, even as processes fail and unexpected events occur.

It should come as no surprise to learn that the same mechanism for handling exceptions and failures and the unexpected comes into play.  For example, suppose a business service has been selected to achieve a given goal.  If a service fails or causes an error condition during execution, the calling process detects the event and swaps in a service designed to handle errors. If a document arrives unsigned or filled in incorrectly this can be noted and a different set of actions are initiated to complete the task in hand.  As a result, applications are far more robust to exceptions, failure, and incomplete process specification than conventional BPM systems.

Web Services.

Needless to say, external applications and Web Services from the cloud can also be invoked using the same mechanisms as described above.  To achieve this, the cloud based application or Web Service is considered also to be a service, differing only from others in that it is to be achieved by one or more external service providers rather than by some internal process, effectively handing off the goal to a well known trusted service partner.

Since there may be many services and methods for achieving a given goal, so there may be many providers that can deliver or make available a given service; which means that as an internal service can be selected on the basis of its applicability to the given objective so can external services be pressed into play. Process delivered on-demand makes the loose coupling  of Web Services far more important to the main processes since it makes them easier to maintain, more robust and more elastic – reflecting the key benefits obtained from cloud computing as a whole.

However, the notion of process on demand as described here adds greatly to the robustness of Web Services applications.  Conventional Web Service deployments tend to ignore the impact of possible failure of a service provider. What we have outlined here is a well-grounded method for handling such situations.  If a particular service provider cannot meet its agreed service level agreements the on-demand nature of this approach ensures that another provider will be contacted and brought into service. So if Company A cannot respond within the requisite and agreed timescales the process will turn its attention to company B and fulfil its needs from them without user intervention or even knowledge.

The real benefits from process on demand

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.  In summary, the benefits of this approach are:

  • Applications that can be developed far quicker
  • Faster ROI and time to value
  • Applications are easy to change and maintain
  • Software becomes more extensible and easily reused
  • Software is more robust and reliable
  • Reduced complexity: simple, modular components,      easily validated and inspected, self contained, accessible to both      business analysts and IT developers
  • Develop in bite sized chunks