Jaywalk

Business Process Management Notation (BPMN), in its current stage, is primarily a graphical business process notation with inexact and implied semantics. What is called for is one authoritative specification of BPMN semantics. In practice, this means fixing the concrete syntax of BPMN to an abstract syntax for which there already is semantics.

In the last few days, there has been heated discussion within OMG on the UML Profile for BPMN and whether it should be submitted as part of the BPDM specification. A new RFC is being issued on BPMN mapping to UML2 metamodel to speed up the process of the standardization of the profile.

This adds to the confusion as to what the BPMN serialization should be, as BPDM is supposed to be the metamodel of BPMN. Proponents of BPDM argue for an UML Profile for BPDM for the relevant BPMN semantics, yet no work has been started on this. On the other, work on an UML-based metamodel is already underway within UPDM standardization to permit integration of BPMN process models with UML models.

The new RFC addresses the need of vendors that want to apply UML transforms to BPMN models closely integrated with UML modeling. While it is acknowledged that the normative standard mapping from BPMN to UML should go indirectly through BPDM and the direct mapping from BPMN to UML specified in the RFC would be retired at the introduction of UML Profile for BPDM, the shortcut may be a decisive nail to BPDM’s coffin: with the introduction of an UML Profile to BPMN, it would become easier to develop a competing MOF-defined metamodel of BPMN based on UML XMI, which would give more justification for voting down the BPDM proposal.

It is to be hoped that BPDM submitters would now concentrate on the key requirements of the RFP: UML Profile and MOF-compliance. BPDM is the key process standard in the broader MDA strategy of OMG. It would be sad to see the comprehensive effort die in the face of divergent standardization of BPMN semantics.

The September submission of Business Process Definition Metamodel (BPDM) shows some signs of revival of the standardization effort of this technology-independent representation of business processes. The metamodel has been substantially extended from the previous release and the many examples help to comprehend the complex model.

Submitting this draft specification were nine companies, including noteworthy modeling tool vendors such as Borland Software Corporation or MEGA International. Unfortunately, however, infrastructure heavyweights, including the earlier submitter IBM, are not joining this party.

Instead, vendors like IBM, BEA Systems, Microsoft and SAP are staying on the BPEL bandwagon. BPEL (Business Process Execution Language), however, does not qualify as a standard for exchange between vendor products. First of all, it does not provide a full representation of business processes. Therefore, it has also been extended by individual product vendors, thereby fragmenting the standard.

Furthermore, BPEL can only be used to automate business processes as centrally-controlled orchestrations within a business system domain such as an individual department of an enterprise. Coordination mechanisms and standards such as choreography and WS-CDL are needed to integrate processes across the enterprise an its partners.

The business analyst is not usually concerned with a particular implementation or coordination architecture. BPDM is designed to represent concepts that are relevant to business analysts. One of the primary purposes of BPDM is the unification of orchestration and choreography by identifying the common elements of these two aspects. On the more abstract level, Processing Behavior unifies all process-oriented behavior. The term Process refers to a concrete process (”orchestration”) and Service Protocol to a contract between processes (”choreography”). Both are specializations of the Processing Behavior abstraction.

In general, BPDM is consistent with the MDA (Model Driven Architecture) approach. It provides a high-level, business-driven representation of the business process and leaves more specific implementation choices to other stages of system design. Instances of the metamodel (user models) are specifications of what the modeler would like to happen in the processes and protocols as they actually occur. The relation of a process or protocol specification to its desired occurrences is the semantics of BPDM.

Notably, the new version of BPDM specifies a mapping between BPDM and BPMN (Business Process Modeling Notation), thereby providing a standard interpretation of the diagrams. In the future, it also promises to standardize the serialization of BPMN models using XMI. Support for BPMN ensures that BPDM represents widely accepted business process modeling concepts.

While an abstract view of a business process that involves multiple participants may be represented much the same as an internal business process, BPMN falls short in representing choreography — an agreed-upon pattern of exchange of messages between participants. BPDM includes this representation as well as means to validate that the processes are in compliance with choreography. Further, it supports composition of a large complex choreography from more specific, validated choreographies.

Although the BPDM specification has matured significantly, some key sections still remain to be completed: UML Profile and mappings to BPEL and WS-CDL.

In its recent Technical Meeting in Anaheim, OMG issued an interesting RFI called “Event Driven Architecture (EDA) and its relationship with SOA & BPM”. Herein, I put in my five cents in an attempt to respond to some selected questions posed in the RFI:

What is an Event?

An Event is the representation of an asynchronous occurence in an agent’s environment to which that participant must respond.

What is Event Driven Architecture (EDA)?

Event-Driven Architecture (EDA) is the set of design principles to specify and implement a network of decoupled and coordinated event-processing agents that exchange messages.

What is the relationship between EDA and SOA?

Service-Oriented Architecture (SOA) is the set of design principles to structure and expose information resources as coarse-level, context independent services. It is based on hierarchical composition, in which context-independent services are subordinate and reactive to their client; the service has no presuppositions of the context in which it is being called and only performs constrained bottom-up computation upon particular resources pertaining to its domain.

In contrast, EDA is about structuring a network of agents. The overarching architectural principle is communication rather than composition. Agents are autonomous entities that share common goals. They can determine the flow of control independently; it is not controlled by the client like in SOA. They are structurally decoupled from each other and merely maintain cohesion through contracts governing their interaction.

What is the relationship between EDA and BPM?

As business processes in BPM are executed as a network rather than a chain, event-driven principles become pronouncedly important. The role of EDA in BPM will be in coordination of executable processes. At the moment, such coordination can be achieved with service choreography that governs the interplay of long-running complex services with conversational interface behavior. It can still be argued that choreography is part of SOA, as the processes are exposed as services.

In the future, however, BPM will arguably embrace event-processing agents as the containers of executable processes. At the latest then, EDA will be the architectural foundation of inter-agent coordination within business process management.

My second lecture at HUT’s BPM course today was about different IT approaches to process management.

Essentially, I classified three degrees of processes and three paradigms to manage these type of processes, respectively:

1. “Controlled processes” managed with Workflow Management (WfM),
2. “Coordinated processes” managed with Business Process Management (BPM), and
3. “Contracted processes” managed with Human Interaction Management (HIM).

I maintained that “controlled processes” take place within the scope of a single control and thereby pertain to the structure of the system. Workflow processes belong to this class of processes.

“Coordinated processes” consist of a network of concurrent processes. These processes execute in parallel and have their private control over resources within the structure, whereas the public process governs the externally observable message exchange between the processes (= the organization of the system). This class of processes covers structured collaborative processes.

Finally, the class of “contracted processes” enables negotiating the public process, i.e. change the declarative constraints of the business process during its execution. These processes also include irregular collaborations.

All these mechanisms, control, coordination and contract, will be required to achieve the architecture of an agile enterprise. The top-level strategy sets a contract for coordination (business processes) of controls (functions).

In the end, I extrapolated that in the near future both IT and human resources will be exposed as software agents that dynamically coordinate their actions by negotiating roles and future work in goal-oriented collaborations.

For more details, see the slides.