Challenges of Being a BPM Pioneer: Part 4 - Building Work: Deploying Process Automation Artefacts
- Published: June 14, 2017
- Written by John Morris
It’s not often apparent to first-time users of BPM software that they may have in fact purchased two BPM systems!
There is (1) the BPM modeling system and (2) there’s the BPM system that is used every day by people working on real live business processes. (The two BPM systems are depicted on the diagrams by the red “S” storage icons. Typically, but not always, the two systems will have separate process information stores, one for process model artefacts and one for process execution artefacts.)
Process models are created or edited during modeling, Step No. 2., either by or in dialogue with business people. But whether you are actually allowed to deploy exactly that process is constrained by the deployed process system, Step No. 4. These are Gaps “B” and “C” .
These gaps might not even be worth mentioning if the two systems worked well together. But until recently, the challenge of synchronizing the two systems has often been more or less difficult and expensive, depending on product and circumstances.
BPM Automation Artefact Life-Cycle
As a consequence, the success of your BPM automation programme may depend on successful navigating the potential mismatch between process model and process execution. Both business and technical staff responsible for a BPM-based automation programme should be familiar with the following two topics:
The Roundtrip Problem or How Not To Throw Your Beautiful Process Models Away
You wouldn’t be surprised if after deploying a new business process, that the very next day, you and your team learn something new about your business process. And want to change the process!
This is why you bought or deployed with BPM software in the first place, to be able to build and evolve your business processes faster. But you find that changing your in-place process isn’t quite as easy as you’d hoped!
The so-called “process modeling roundtrip problem” was, and often still is, a challenge.
Typically an executable process artefact needs to have all sorts of additional “techy” improvements added to the artefact to make it usable in a corporate environment. IT staff might even add new process steps that the business people didn’t think of!1
And so very quickly the two process models, the original process model and the deployed process model, are now out of sync. This is the “roundtrip problem”: synchronizing changes made in either business model or execution model, back and forth between the two models.
For technical reasons, pushing changes back and forth between these two pieces of software might not be easy – and even when it can be done, limitations on modeling freedom are sometimes added part of the synchronization.
The result of the roundtrip problem has all too often been that the full management-friendly business process model (that shows up in nice sales demos) is no longer usable, and that the only people who can now change a deployed model are IT people. This is very disappointing of course to the business team who imagined being able to evolve business processes quickly, without always need IT help.
Fortunately, with new BPM software products and more research into the computer science of BPM software the round tripping issue is slowly diminishing in importance. Especially important is the rise of executable BPMN; with executable BPMN there are no longer two process languages and/or two process data stores to synchronize.
(The reason that the round trip problem is diminishing is in part because of improving technology, but also because of the innovation discussed in the next section on “segregation patterns”.)
Even though the roundtrip issue is based on very technical issues, the impact on BPM technology adoption has been, your author believes, much more substantial than is generally acknowledged.
An Important Innovation Regarding The Roundtrip Problem: The “Business Logic Segregation Pattern”
In the previous section we made an observation that deployed business process automation artefacts have often required all sorts of additional development to “make them work” in a business environment. What does it mean to “make them work”?
The most significant requirement for making deployed business processes work is that the processes should be integrated to all required existing organizational systems. Most business processes are integrated to all kinds of business systems, for example, employee databases, warehouse inventories, manufacturing, accounting etc. etc., whatever business functions are touched by a given business process. Integration with business systems is typically a key enabler for the business value of any process.
In order to successfully and safely integrate with all such systems, sophisticated interfaces have to be set up and managed. (We could label many of these interfaces collectively as SOA or ESB interfaces; the term “API” is also used.) Once set up, these interfaces will be available to the business analyst building a new business process model.
Such business systems interfaces are essential to the success of a BPM programme -- but at the same time they are often very tricky both technically and business-wise (EDI is an example of a class of business interface that is notorious for its complexity).
It can be a challenge to find the staff or consultants who understand your interfaces and who know how to integrate with them. Business staff might have some of the business knowledge required for interface wrangling, but it’s not common to find business people who are able to lead such a project. The business process interface problem is thus a serious challenge on the road to BPM programme success.
The result of the business process interface challenge is project delay. But worse, the technical complexities associated with interfaces are often imported into formerly well-conceived business process models. And what was originally a flexible easy-to-understand model is no longer flexible and no longer easy to understand.
This is why the revolutionary work of Volker Stiehl, a long term BPM champion on both business and academic sides, is so exciting. Dr. Stiehl has provided a recipe for what your author calls “business logic segregation” in the construction of business process artefacts. Based on research and real-life examples, Dr. Stiehl has been able to show that much of the round-trip issue can be eliminated, even if one is not using the latest BPM software!2
The approach recommended by Dr. Stiehl is that a business process environment should be set up so that business side people can construct any reasonable business process without concerns for lower-level interface issues. It is the job of IT to provide an “set of interface contract services” that are completely self-contained and safe to use by business side people.
In this way, business process artefacts can be constructed exclusively with business logic. There is no longer any reason for “deployment-specific process modeling” or “deployment coding” in order to make a process work. In this way, business people can model new process ideas and have them deployed them right away. And in an ideal segregated environment there would no longer be any synchronization issue either.
The Stiehl recipe requires technical and business leadership to make it work. But all the tools and methodologies are already known and available to most business process teams.
The benefits of following the “business logic segregation pattern” cannot be overstated. When a business team can specify a new business initiative and in a matter of hours or days at most, deploy that new initiative, instead of waiting weeks or more – the change is dramatic! Business cycle times and business learning can accelerate enormously.
Paper Road Map
There are four papers in the Series: Explore BPM Technology As Revolutionary Enabler:
- The first Paper, “Why BPM Is Unique & Important”, introduces the exciting topic of BPM software technology and why BPM so relevant to business today. Work, process and modeling are revealed as built-in to BPM software, enabling rapid construction of new business capabilities. Published in five parts.
- The second Paper, “Minimum Viable Definition Of BPM”, introduces the whole BPM ecosystem but then zeros in on the Minimum Viable Definition. Promotion and adoption of BPM software technology is facilitated when the unique value of core BPM is clear. Published in two parts.
- This third Paper, “Challenges Of Being A BPM Pioneer”, highlights technical keys to success for a BPM programme. BPM software technology is not mature, and “results may vary”. However, there are ways of narrowing the “cone of outcomes” for your BPM programme.
- The fourth Paper, “Adoption Process & BPM Institutionalization”, covers how BPM software technology adoption can accelerate beyond the current technology grid-lock, a process which is less about technology and more about community.