Nobody really cares about standards… until suddenly they do. When a standard reaches some threshold of adoption, a tipping point is reached. Then, if you’re not on the standard you’re proprietary. Legacy. A dinosaur. Not where you want to be. By this time next year we may see that tipping point for one piece of the BPM standards puzzle with a potential domino effect on the other pieces as well.
Standards deliver tremendous value for buyers and practitioners of BPM. They provide a common BPM language, and lower costs and risk. If they didn’t have inherent appeal to customers, why would vendors of BPM tools and technologies go to the trouble of conforming to them? Nevertheless, BPM users play almost no role in the standards development process. It’s not for lack of opportunity. The vendors and consultants who do the hard work of standards-making would be thrilled to receive end user input, but there is frankly very little offered.
Standards for process modeling and standards for process execution have very different objectives and benefits, but are frequently confused – not only in the popular imagination but in the standards organizations themselves. The primary goal of a process modeling standard is shared understanding, a universal diagramming notation through which business process description can, in principle, be shared unambiguously across business units in an enterprise, across companies in an industry, even across the notorious business-IT divide.
For BPM as a management discipline this benefit is huge, because in order to manage the business of the enterprise from a process perspective you need to be able to describe how it works and share that description across the stovepipes. Many of those processes will never be automated and monitored with a BPM Suite, but some will. A BPM standard that serves the needs of both process modeling (i.e., abstract or non-executable description) and executable process design also has value, because it empowers business to collaborate with IT in BPM implementation, instead of tossing requirements over the wall.
BPMN as a process modeling standard is nearing the tipping point. BPMN 1.1, the current version, is familiar to business analysts in its basic constructs – essentially swimlane flowcharts – yet expressive and precise enough to underpin executable implementation in a BPMS. Many inexpensive tools for creating BPMN diagrams exist – some of them free. While BPMS vendors have driven the adoption of BPMN as a standard, most process modelers are using the tools for process description and analysis, and have little immediate interest in executable implementation. Depending on your point of view, that is either ironic or perfectly sensible.
The true tipping point should arrive next year with BPMN 2.0, which will deliver two still-missing pieces: an XML format enabling exchange of process models across a wide variety of tools, and enthusiastic support by the kingpins of the software world: IBM, Oracle, Microsoft, and SAP. At that point, any process modeling tools that are not BPMN-based will begin to be seen as proprietary and outdated.
The prospect for executable process standards is more muddled. Here the vendor community is divided. Remember, it’s the vendors who create the standards, and their business hinges on selling the execution runtime, not the modeling tools. They are willing to subsidize the majority of BPMN users who just want abstract modeling, in the hopes of capturing the few that move on to implementation.
BPMN 1.1 is not really executable. While the standard does enumerate a set of execution-related attributes, I don’t know a single BPMS that uses them. Instead, most BPM Suites provide their own vendor-specific execution properties on top of the BPMN-based activity flow, and they are happy with that solution. Moreover, BPMN does not demand that tools support all of the notation, which is a good thing, because no BPMS today implements all of the event and gateway types. On balance, BPMN gives modelers what they want – a vendor-independent quasi-standard for shared understanding of processes – while preserving a diverse BPMS landscape in which a wide variety of products can compete.
There is, however, a persistent argument for something more: a standard process execution language, or, what seems like the same thing, a standard executable process design language. It’s fair to ask, what would be the benefit to BPM buyers of such a thing? That depends on the approach.
One approach is BPEL, an OASIS standard. BPEL is purely an execution language; it does not provide a diagramming notation. Unlike with BPMN, a vendor cannot elect to support a subset of BPEL. If you can’t execute all of it, you’re not BPEL-compliant. BPEL effectively commoditizes the process engine component of a BPMS. That makes it an extremely disruptive force in the BPMS landscape, because only two types of vendors can compete in that world: middleware stack vendors (like IBM and Oracle) and open-source vendors.
Because BPEL is more “technical” than BPMN, it is favored by developers who find nothing more annoying than business-types wanting to “collaborate” on implementation. On the other hand, such motives are not really in the spirit of BPM. To be fair, a vendor could support BPMN in the design tool and BPEL in the executable, and some in fact do: Oracle, Intalio, and Active Endpoints, to name a few.
But there’s more to it than that. A key reason why modelers find BPMN familiar and comfortable is it is graph-oriented like a flowchart, not block-oriented like a structured program, or more to the point, like BPEL. For example, you can loop back to some previous step with a BPMN gateway, but BPEL places severe restrictions on that. What that means is you can draw BPMN diagrams that cannot be mapped to BPEL, or at least to “roundtrippable” BPEL that preserves the BPMN view after even minimal tweaking in the BPEL environment. Most vendors that use BPMN as a design front end to BPEL either give up on roundtripping or restrict the BPMN to block structures that lose the very thing that made BPMN so popular in the first place.
Some have questioned the whole premise of roundtripping, since you do have a fighting chance of mapping arbitrary BPMN to BPEL if you do not insist the resulting BPEL be “readable” or, more to the point, directly editable. In that view, the BPEL is just like machine language or bytecode; it’s there for execution, but the designer never deals with it directly. That’s one approach.
The other approach is to make BPMN itself executable. In essence, it means replacing the universally ignored implementation attributes in BPMN 1.1 with better ones. In combination with a more formal metamodel and XML serialization, you could use BPMN not only as a universal process modeling language but a standard process design language as well. This sentiment runs deep in OMG and in the BPMN 2.0 spec in particular. It removes some BPMS vendors’ objections to BPEL – block orientation and commoditized runtime – while preserving BPEL’s semi-promise of runtime portability. And it would do more than anything else imaginable to realize the old Third Wave dream of business-empowered implementation.
But I fear too much insistence on this in BPMN 2.0 will mess up BPMN’s attractiveness to process modelers, who are not thinking about implementing anything. OMG has never made a distinction between BPMN attributes needed for modeling and those needed for implementation. That was not a problem in the past, as everyone ignored the implementation attributes anyway. But in BPMN 2.0, with all the increased emphasis on implementation – meaning a BPMS – there is a danger of making it less useful for modeling.
Before moving too far in that direction, we need to recognize that standards for process modeling and process execution have different purposes and benefits. They should be linked, but with proper attention to those differences.
