I was sitting in the Delphi BPIS Summit a couple of weeks back contemplating my closing keynote address and not completely listening to the speaker (Kevin Fickenscher) at the time who was doing a “call to arms” type of piece about how the world was changing (as if we didn’t know).
I shouldn’t sound disparaging, as the talk was actually very interesting. At one point he started to describe a concept he called “Simultaneity” (is there such a word I was thinking … having looked it up since, I can tell you there is).
He then went on to say that in Perot Systems they have literally thousands of associates working on a single client’s problem (system) at once. Really, what he was getting at was how things in the world often need to happen all at once, in parallel.
And it started a chain of thought – so how do you manage that (sort of problem). Or if you are say, Shell or Nokia with literally hundreds of different functions that need to collaborate on major projects; or indeed any large business attempting to deliver a consistent customer experience … just how do you manage that.
Ahhhh – Process. You need processes to help coordinate the various resources at your disposal. Of course!!
But the problem is that most people still think of process in terms of input output chains of activities borrowed from manufacturing. That notion of process doesn’t help you too much when you are talking about the coordination of multiple actors, operating in parallel.
And that chain of actors is increasingly up and down the value chain, no longer constrained to the familiar boundaries of the organization where command and control principles can apply.
What you need to do (as well) is to start thinking about processes as sets of “interactions.” This is the other side of the coin from the procedural notions of process that we are all so familiar with. Instead of solely focusing on the chains of activities with their (hopefully neat) sets of input-output documents, you also need to think about the protocols and agreements made between the actors. They represent the white space in between the functional silos, the hand-offs and commitments made from one party to another. Indeed, one could start to think about how a process is composed from fragments of interaction.
Having understood the interface requirements for your process, you can start to explore how your part of the business (value chain) wants to implement against that set of needs.
Really we are talking here about the difference between “Process Orchestration” and “Process Choreography”:
- Orchestration is a term used to describe the traditional notion of managed or directed execution, where activities are carried out, with branching and synchronization of different threads.
- Choreography is a more abstract notion of process (for most people). It is used to describe the “Interactions” of collaborating entities, each of which may have their own internal orchestration processes.
And this is where the emerging business process standards are starting to come to the rescue. The OMG “Business Process Definition Metamodel” (BPDM) provides the capability to represent the semantics of business process models, independently of the modeling notation. Think of it as a sort of “universal syntax” of process. The central idea is that BPDM is capable of supporting a mapping to the semantics of most common types of process model – whether that is BPMN on one side and Role Activity Diagrams or UML models on the other. As a result it enables the robust exchange of information between models of one type and other types of process models, while preserving the fidelity of the model content (as much as is possible).
At the heart of BPDM is support for both orchestration and choreography. This is going to become critical to modern organizations as the business boundaries change ever more quickly. It is self evident that businesses are constantly reorganizing, merging and splitting their operations, resulting in continuous changes in both the internal boundaries, and that which what owned or outsourced to both collaborators (in the supply chain) and the customer. Yet there is still a common process operating across the value chain. BPDM facilitates this evolving, permeable boundary by identifying and managing the common elements, enabling the modeler to easily transition between them.
Because of this sophistication, BPDM can support a very wide range of usage scenarios. For example, it enables high level, abstract “business capability models” used in the boardroom, to exchange information with lower level, procedural modeling notations used in BPM projects, and then on into process execution environments (BPM Suites).
BPDM will also facilitate the definition of complex inter-company interactions (and between the roles within the company). Such models could be created from scratch, or created through the composition of existing interaction fragments (from a library). The resulting model might then provide the terms of reference for each participants’ own internal orchestration model. In turn, this orchestration model could be teased apart to explore the business interactions that exist between the internal participants (internal roles) and/or used to generate a robust BPEL execution model that directly supported the firms agreed choreography with the other companies.
In this way, the process would not need to be completely ripped apart and redrawn every time there was a change of organizational responsibility. Roles (areas of responsibility) and their interactions could be modeled in an abstract way, then instantiated as needed to meet the requirements of the case in hand.
While most might think of BPMN collaboration diagrams to model interactions, a better approach is to use Role Activity Diagrams which focus on the interactions themselves and how a role changes state as a result of the actions and interactions that occur. So assuming we had tools that supported the BPDM package for BPMN and another tool that had mapped RADs to BPDM, it would be possible to translate between the two with clarity and fidelity. (BTW – the best reference on RADs is Martyn Ould’s book “Business Process Management – A Rigorous Approach”
So what does this mean in the real world of organizations like Perot Systems, Nokia or Shell – that business process standards, such as BPDM, will make it easier to model (and therefore understand) the simultaneity in a world where interaction has become as important as procedures (in some cases or more). It also makes it more straight forward to drive those processes using BPM Suites and report on the performance of the individuals and teams involved.