Decomposing Process Models

The last post The Architecture of Purpose, described how a strategic plan is aligned with an operational plan in a Business Architecture. The concept of an Outcome was explained as the state-of-affairs for Resources in a business domain. Outcomes are modeled as patterns for the properties of Resources.

This discussion will continue to explore an outcome-based Business Architecture model, beginning with the important exercise of decomposing business processes to convert behaviour-oriented models into outcome-oriented models.

In 2007 I was on a quest for an executable architecture when I came across an intriguing article posted on InfoQ by Jean-Jacques Dubray discussing the interesting concept of Resource lifecycles. Anyone who knows and understands the CAPSICUM Framework would recognise how influential this thinking has been. I’ve used his example of the job application process many times in discussions on process decomposition.

Process models are behaviour oriented. They focus on the occurring sequential coordination of activities and the logic that links them. For a generation of business analysts they have provided very useful, clear and structured representations of the decision-making that informs sequential behaviour through extraordinarily expressive notations such as BPMN. Many of the brightest minds in our community in recent times have been staunch promoters of process models and to many people BPM is as close to a religion as you can get with a three letter acronym.

So what are the down-sides of behaviour orientation and why would you need to consider anything different? Who would dare challenge their supremacy and risk incurring the wrath of an evangelistic community with such heresy? Is there anything to be gained from alternative approaches?

I like Outcomes. It just seems so obvious that if you haven’t defined what you want to achieve, there’s no point in defining how you’re going to do it. Kicking off a recent process re-engineering project I was surprised by the strident concern voiced by business stakeholders that by automating their manual activities they were going to be mummified in rigid and inflexible process automation. “We’ll record any information you want, but don’t make us have to follow a process”.

Anecdotal evidence and a sample of one isn’t going to convince anyone, but clearly there have been some bad experiences and not everyone is a convert. Stepping back objectively and compiling a list of some of the negatives, here’s the information I’ve come up with:

• As those business stakeholders sensed, the challenge in modelling behaviour is the brittle, rigidity imposed by burying logic and rules into process models. Conditional rules and the sequential flow logic embedded in process models are difficult to access and manipulate by anyone who hasn’t mastered the notation, frustrating business people and stifling flexibility in adapting to change.
• Decoupling logic from behaviour models has long been recognised as a desirable objective, which Business Rules engines and Real-time Decision engines attempt to address. Delivering on the promise may still be some way off, although an argument could be made that process models are possibly hindering rather than sustaining the potential.
• Whilst rigid process structures do have some business value in documenting and enforcing highly regimented administrative or financial procedures, they create tedious, bureaucracy for more dynamic business behaviour, which is not necessarily desirable or effective when over-structured.
• Procedures are actually governance constructs, not behaviour constructs. Procedures represent policy logic (Directives) and yet they are so entwined in process logic that they get mistaken for the same thing. Once procedure rules are modelled into process logic they become trapped, indistinguishable and unavailable for parametric tweaking by the business.
• Process models are at best a compromise. Process maps and models do not truly reflect the achievement of business objectives with their focus on “how” rather than “what”. Business stakeholders are measured on what they achieve, with a lot less emphasis on how they do it. A sales team is not measured by how efficiently it follows the sales process, but by how many orders are booked. Organisations have been managing by objectives for decades. Objectives are Ends, not Means; measured by results which are tallies of Outcomes. Processes are Means and do not recognise or provide any tangible representation of the Outcomes that management is concerned with.
• The typical business stakeholder gets little practical value from process models other than as a documentation of business procedure, as discussed. The effort in developing process models is largely targeted at informing technology teams how the business works.
• However in a similar manner, process models aren’t particularly useful artefacts in the development process since they don’t reflect the way in which system code is developed. If they did, the BPMN constructs of gateways and events should map directly to native constructs in an object-oriented language such as Java for example. In fact, “implementation of BPMN is difficult and costly to achieve” (Durocher, 2011). Try giving a BPMN process to a developer and saying “Build this”.
• Modern rest base API’s are based on the design principals of decoupling, encapsulation of logic and statelessness of services. Processes represent the antithesis of this philosophy. Processes impose tightly coupled dependencies between activities, have sequencing logic disseminated throughout their structure and are entirely state-full. The resolution of this dichotomy was achieved in service oriented architecture through service Orchestration and Choreography, which does go some way towards decoupling process logic from process activities (services) but which still relies heavily on sequencing and flow logic rather than state-based logic.
• Perhaps most importantly, almost any software application is designed around a data-model. Yet a process model doesn’t have any construct for identifying or describing the data that is necessarily produced, consumed or transformed in its execution. That surely is a glaring omission in BPMN.

There are many other well-articulated discussions that explore this question, including the article referred to earlier. So what is the alternative? How do you build an outcome-oriented model and what do we mean by decomposing a process. I will use the example advanced by Jean-Jacque to illustrate the steps.

The following is his existing BPMN model for a job application process. It provides a concise articulation of business roles (swim-lanes), their tasks and activities (boxes) coordinated by the logic of gateways (diamonds) and events (circles) that connect the boxes. We’re going to decompose this process into more granular, reusable constructs and decouple the logic to make it more accessible for manipulation.

We start by looking for Resources, the things that will evolve in the process recording the outcome states of this endeavour. We know that BPMN doesn’t model things (nouns) it models activities, which are verbs, but they act on nouns. Identifying the Resources in a process model is simply a matter of looking for nouns. In this part of the Recruitment model the activities operate on three core nouns namely a Job Application, an Interview Schedule and a Job Offer before moving on to Hiring. In Step 1 below, Resources are identified in Red.

1. Identify the core Business Objects (Resources)

From the activities carried out each of these Resources we can piece together the Outcome states that represent the lifecycles of the Resources. Outcomes are shown in Green in Step 2 below:

2. Identify the Resource Outcome Lifecycle

We can now remove the complexity of the rules, events and logic from the model as shown in Step 3

3. Remove Sequencing Logic

Simply reorganising these states into an inventory of Outcomes reveals a very simple and clear depiction of the Resource lifecycles.

4. Reorganise into an Inventory of Outcomes

We know already that each Outcome is achieved by an Activity, especially and intentionally designed for that purpose, so can add those in Step 5

5. Attach to the Tree of Undertakings

From the swim-lanes we already know which Roles are needed and can deduce the subject Resources (or Parties) that they will capacitate, as shown in Step 6:

6. Identify the Roles

These four constructs comprise the first four cells of the CAPSICUM Framework, with Resources, Outcomes and Roles representing the Domain Model Scaffold. Undertakings are easily grouped into Capabilities and the tree of Capabilities forms the Business Architecture backbone, off of which the models all factored.

The Domain Scaffold cells are highlighted in their respective colours in the CAPSICUM Business View overview below. The uncoloured cells represent additional levels of detail and logic that are incrementally added to the Business Architecture models in the subsequent steps.