Round Trip Revisited

Many business process management initiatives over the world suffer from the same pitfall. Most projects are successful in identifying and solving a particular business problem by redesigning and/or constantly improving the corresponding business process. The ROI figures are impressive and BPM gains the trust from executives. Yet attempts to leverage on the initial success to apply BPM enterprise-wide are often far less successful.

In terms of BPM maturity, we may say that these organizations fail to reach higher levels. According to CMMI, enterprise-wide processes management is the Level 3 capability:

Fig.1. Capability maturity levels according to CMMI

Other sources may define levels differently but the core idea is the same: at certain level organizations must progress from managing isolated processes to defining the whole enterprise as a system of business processes. BPM Common Body of Knowledge (BPM CBOK) by ABPMP for example names the Level 3 “Architected”:

Fig.2. Process maturity curve according to BPM CBOK

“The State of Business Process Management 2014” report (Paul Harmon and Celia Wolf, BPTrends) indicates that the process maturity does not increase but actually goes down during the last years. The table below shows that percentage of the organizations that practice process management activities “Occasionally” grows up at the expense of those who do it “Most Times” and “Always”.

Fig.3. Frequency of specific organizational activities that suggest organizational maturity

The authors conclude that “the response pattern in 2013 is more like the pattern we observed in 2009 than the one we saw in 2011”.

There is hardly one single explanation of the slow progress in BPM adoption; we’ll discuss just one aspect – technology. Does the current BPM technology fully answers the needs of organizations willing to go from managing business processes one by one to managing a system of processes constituting enterprise operations? The answer will be “not exactly” but before saying that let’s get back and see how the current progress in managing business processes has been reached.

Bridging Modeling/Execution Gap

The progress in business process management reached so far owes to BPM Suites at large extent. The previous generation of BPM tools was mostly process modelers and as for the process execution, it was ERP and/or standalone workflow engines.

It worked fine for reengineering type of projects: organizations modelled their process say in ARIS EPC, then semi-automatically translated the process model e.g. into SAP program code and here it is: the core company’s processes are implemented in robust execution environment.

But rather sooner than later every organization following this route hits the so-called “round-trip problem”. The essence of the problem is that it’s terribly hard to keep in sync two models – the analyst’s view of the business process depicted in a process notation and developer’s view implemented in the program code. When both representations evolve over time there is no good way to merge changes made by the analyst with changes introduced to the program code.

At the end of the day the program code becomes prevailing and business analysts get out of the game because process diagrams become irrelevant. Only IT department really knows how the process works so in fact it’s programmers who manage the business process! Sounds absurd yet it’s a reality of many organizations. Today’s mainstream BPM Suites leverage the power of BPMN to overcome this issue. BPMN was designed simple enough to be intuitive for business people and at the same time precise enough to be unambiguous for developers. This doesn’t come automatically of course – good “Method and Style” should be at place (this is the name of the famous Bruce Silver’s book on BPMN) but many organizations have shown that it’s doable.

There is no round-trip problem in such environment because BPMN is the code! Hence no gap, business analysts and business people behind them are in the game and everybody is happy.

Bridging Architecture/Execution Gap

So far so good – we are perfectly equipped to deal with any single business process.

But how do we manage processes enterprise-wide? Unfortunately most current BPM Suites offer no more than a list or hierarchy of processes. What’s even worse, BPMN – a de-facto standard notation used in leading BPM Suites – can’t model anything above a single process level. (There is message-based communication in BPMN but from business perspective it’s no more than modeling process internals.)

On the other hand, there are very versatile Enterprise Architecture tools. They support various artifacts, multiple notations, collaborative work within a single repository. But they are separated from execution environment.

Once again, we have two sources of truth – it was EPC vs. program code in the example above, now it’s architecture diagrams vs. BPMN diagrams. Even if it’s possible to export a process definition from EA to import it into BPMS, this produces the same round-trip problem, now on the architecture level. (Thanks to Keith Swenson who perfectly explained the difference between model transforming and model preserving strategies. BPMN-based BPMS follow the latter while EA/BPMS gap is the example of former.)

This is not a theory, speculation or guessing about customer’s need. My personal five years’ experience of teaching BPMN shows that almost every organization that wants to get most from BPMN and BPMS comes to the same question: how can we model process hierarchy above a single process’ level? Unfortunately the honest answer is: you can’t. Not within current mainstream BPM Suites.

What You Architect Is What You Run

We at Comindware attack this problem by implementing what we call “Executable Architecture”. It combines modeling process internals in BPMN with modeling high-level capabilities in the notation similar to Value Chain diagrams. Each capability may be mapped to a process, adaptive case or project – the product supports all forms of collaborative work, not just BPMN processes.

Process analysts and process designers work within a framework set up by the enterprise architect. There is no gap between them: e.g. when business requests certain activity to be implemented in the execution environment it first should be checked against the current architecture and a new capability should be introduced if it was missing.

Process performers are affected by the decision made at the architecture level, too: what user may or may not do depends on how capabilities and resources on the architecture diagram were mapped to processes and data records at the execution level.

The link is not that tight indeed: it’s possible to utilize only architecture and modeling without execution, or modeling and execution without defining architecture. Yet the company that are targeting themselves to the high levels of process maturity should appreciate the ability to manage process hierarchy from the top-level enterprise value chain down to individual tasks within a single tool.

We will show the Executable Architecture in action at the bpmNEXT’2015 conference; our demo is scheduled at the morning March 31. Please join us at the conference or visit the bpmNEXT.com later to watch the recorded video.