In my previous post, I quoted Paul Strassman and his argument about the use of technology to deliver economic results. In order to deliver these results, BPM cannot just be about improving individual processes but more importantly about improving the management of processes. With his customary incisiveness, Bruce Silver comments that “the M (for management) implies continuity, the ability to constantly re-align processes to every changing market needs and company goals”. The management of processes involves answering some of these questions:
• How do you discover the processes?
• How do you ensure they are aligned with organizational goals and objectives?
• How are processes designed and alternatives evaluated?
• What approach is used to collect process performance data?
• How is the process performance data used to improve existing processes?
• How are individual processes composed together to form new services?
Obviously, the above is not an exhaustive list but they give us a general idea about some of the key aspects of process management. This leads us to examine what should constitute a BPM Suite and its architectural building blocks. Bruce Silver wrote an article (I say article, it’s really more of a guide) a couple of years ago about this so I’ll summarize the points he made here.
Very broadly speaking, a BPM Suite consists of the following components:
• Process Modeling
• Process Automation
• Process Architecture and Standards
• Business Rules
• Application Integration
• Performance Management
• Process Lifecycle
Let’s look at each in turn.
Process Modeling
Some BPM practitioners like to distinguish between process modeling and process design. Process modeling means creating an abstract description of a process used for documentation and analysis whereas process design means creating an executable process management application developed by IT. Whilst this accurately describes the lifecycle of traditional software development, advances in BPMS technology reduces the gap.
In a landmark book published in 2003, Smith and Fingar introduced the notion of an executable process model. Essentially, an executable process model is one that is built graphically without programming but can also be deployed to a process engine to automate, integrate as well as monitor a process from the beginning to the end. It is therefore more helpful to think of 2 types of modeling and their respective and associated tools i.e. analytical modeling and executable modeling.
Analytical modelling is abstract and not bound to any proprietary implementations. However, they provide a number of functions both to traditional BPM and modern BPMS:
• Capture of existing process flow in a structured diagrammatic notation
• Diagramming new or modified processes using the same notation that can associate resources, processing time, cost etc with each process activity
• Simulation of process performance based on various scenarios of process instance volume, resource allocation and other process parameters
• Analysis and reporting of service level, throughput, cost for various scenarios
• Documentation off the process in exportable format.
Analytical modelling is now an integral part of modern BPMS and most modelling tools now use the BPMN standard for this purpose.
Executable process modelling refers to the design of an executable application through the graphical composition of process activities. Executable models also use a structured graphical notation but their implementation details depend upon the particular BPMS itself. As such, the look and feel of executable process diagrams can vary considerably between BPMS and usually dependent on the implementation itself. Most tools use a serialization format, usually XML-based, to store the process definitions such as:
• XPDL from the Workflow Management Coalition
• BPEL from OASIS
Process Automation
The engine is the runtime component which allows processes to run. When processes are run, the engine creates process instances. A process instance is a single enactment of a process and the engine allows you to create as many process instances of all deployed processes. Process instances can be triggered manually by a process participant or automatically by an outside event. The engine then coordinates all the different activities, some of which can be human activities while others can be automated. Generally, process participants will be able to interact with the process instances by means of a web-based portal-like application. The web application displays the list of outstanding process items on which users have to act in the form of a worklist while the automated tasks may be executed natively in the engine or remotely by calling a remote application or Web Service. Process participants may also launch new process instances from this application.
Process Architecture and Standards
In another very insightful article, Bruce Silver identified 2 types of BPMS architectures:
• Workflow
• Service-Oriented
The workflow-based BPMS architecture is characterized by:
• Usage of the WfMC reference model, XPDL as its basis
• Activities are assigned to roles or queues
• Strong support for human interaction but generally weaker in integration
• Tools oriented towards business analysts
whereas the service-oriented BPMS architecture is characterized by:
• Usage of web service orchestration, in particular BPEL, as its basis
• Activites are assigned to services end-points
• Generally strong in integration but weaker for human interaction
• Tools oriented towards the developer
Most vendors generally agree on the common set of functionalities that should constitute a BPM Engine but they rarely do on the standards to use, or more relevantly, which architecture to use, or to be more accurate, which architecture to use to tackle which problem. A quick trawl on the various blogs will reveal the extent of the debate making it even more confusing for customers. But more on that in later posts.
