Standards and the Process Lifecycle

Registration is free. Login or register to view/download this content.


Business Relationship Manager - Product Lifecycle Management, Chevron Corporation

In the BPM world, like the world in general, standards are like motherhood and apple pie. Vendors and buyers alike are vociferous in their support. After all, standards reduce the costs of vendor lock-in, simplify training and support, reduce risk of vendor failure, facilitate component integration and reuse, support interoperability of systems and processes, expand the choice of compatible technology, and promote agility in a changing world. Who could be against all that?

But if you ask around the BPM community about the current state of standards, you hear words like “confusing,” “chaos,” “a mess,” “a disaster.” Ironically, the mess is a direct result of recent progress in the standards committees. The problem with BPM standards is we now have so many of them, often overlapping but coming from different standards bodies and seemingly at cross-purposes.

At the heart of the BPM standards question is the process description, or model. In most people’s minds, standardization in BPM implies universal understanding of modeling language and diagram elements, portability of models between design tools, and interoperability of models across process engines. This kind of standardization, on which the promised business benefits depend, assumes three things: widespread acceptance and adoption of a single standard within a functional domain, completeness of functionality encompassed by that standard; and mutual compatibility of standards across functional domains. This is precisely what we don’t have yet in BPM.

In their 2002 book Business Process Management – The Third Wave, Smith and Fingar envisioned a new type of software, the BPM System (BPMS), in which a business analyst could graphically compose a process model, optimize it through simulation and analysis, and – perhaps after a slight technical tweak by IT – execute it on a built-in process engine. All this would be done in a single design tool, part of the BPMS, using a functionally complete, standardized modeling language.

While this vision remains compelling (to me, at least), the reality of BPMS in the process lifecycle today is more complex, and core to the standards issue.

  • Business analysts use dedicated tools to graphically model processes in the form of diagrams that can be annotated to allow simulation and analysis, but which lack the technical detail required for execution. Let’s call those analytical models.
  • System architects then interpret those models as business requirements and proceed to describe data elements and software components needed for implementation, using enterprise architecture modeling tools.
  • IT developers next create these components using programmer tools (IDEs) and integration middleware. Increasingly today such components are being architected as reusable “services.”
  • In the BPMS design environment, process designers import analytical models and convert them into executable models by linking them with the developer-built components. These executable models can be deployed from the design environment to the BPMS engine to automate and manage the process.

In the real world of BPMS, a “process designer” is usually a bit more technical than a business analyst, but a lot less than a Java programmer. In many ways, the “spirit” of The Third Wave is being achieved, but instead of business analysts implementing executable processes directly, the real lifecycle involves handoffs between distinct constituencies with different skills and concerns, working with different modeling tools.

This is one source of the BPM standards issue, since each standard is typically focused on one of these constituencies and one particular phase of the process lifecycle.

  • For example, the Business Process Modeling Notation (BPMN) from standardizes the meaning of shapes and lines in the process diagrams used in analytical models. While still meant for business analysts, BPMN goes beyond simple flowcharting to represent advanced features of modern service-oriented BPMSs such as message links, events, and transaction compensation. Currently BPMN is just a diagramming standard; it has no underlying language or schema. Models must be mapped to a common execution language (BPEL) to be portable across tools.
  • Component models used by enterprise architects typically are based not on BPMN but on a different modeling language, UML from the Object Management Group. UML includes a variety of diagrams, some of which – activity charts and statecharts – also describe process flows.
  • The language used by a BPMS for executable modeling depends on its underlying product architecture. There are two basic types: Workflow architecture, based on the well-established reference model of the Workflow Management Coalition (WfMC), features models based on XPDL from WfMC. Process models based on service orchestration architecture have committed to the Business Process Execution Language (BPEL) from OASIS. While you often hear that BPEL is an “execution language, not a design language,” the fact remains that in a BPEL-based BPMS, the design environment invariably features diagram elements that correspond one-to-one with elementary BPEL activities. In other words, in the real world BPEL is being used as a design language – for process designers technical enough to use it.

The second piece of the BPM standards issue is that both XPDL and BPEL omit major elements of real business processes from their respective languages. In XPDL, application integration logic is embedded in process activities, i.e. external to the process model. In BPEL, participant roles and other details of human interaction are embedded in services, again external to the process model. Thus to handle real-world business processes, the BPMS must either support hybrid models, part XPDL, part BPEL, or – the usual solution – simply add the missing functionality as proprietary “value-add” outside of the language standard. While the most functionally complete BPMSs tend to use the workflow/XPDL architecture, support for BPEL from IBM, Microsoft, BEA, Oracle, and SAP – and its inclusion in the web services standards “stack” – has led most analysts to declare BPEL the presumed “winner” of the BPM standards battle.

With this as background, let’s revisit the current state of BPM standards (warning – alphabet soup ahead!):

  • BPMN diagrams, having no standard language or schema, are not portable between analytical modeling tools. They can only be mapped to BPEL. But while BPMN can describe human activities, the details of human interaction cannot be mapped to BPEL. They have to be added in the BPMS’s BPEL tool, which, as discussed, is not well-matched to non-technical process designers.
  • BPMN has no mapping to XPDL. Even if wanted to provide this, XPDL today does not support everything in BPMN. That means XPDL-based BPMS vendors have to add BPMN tools to their own design environment, usually with less functionality than the analytical modeling specialists.
  • OMG is working on its own Business Process Description Metamodel (BPDM). Rather than compete with OMG, is hoping to work with them to develop an underlying schema for BPMN based on BPDM. But that work appears over the horizon, and OMG really serves a different constituency in the lifecycle. Others say should just standardize the BPMN schema and be done with it.
  • Neither BPEL nor XPDL are functionally complete. Some information described in BPMN cannot be mapped to the execution language. Real-world BPMSs have to add this functionality in vendor-proprietary portions of the executable model, making those parts no longer portable.

Confusing and messy? That’s fair. Chaos is a bit extreme. It’s certainly not a disaster. It’s fixable.

That at least was the mindset of when they convened a summit of leading BPM users and vendors, together with honchos from OASIS, OMG, and WfMC, in Miami this month. There was a published agenda, but the details of the event were left intentionally ad hoc. The outcome took me by surprise.

I went in thinking that XPDL was a non-starter, a relic of the client/server ‘90s. I believed that the key task was an initiative to extend BPEL, the obvious “winner,” to handle human interaction, the biggest missing piece. There had been leaks to the press about something called BPXL – human workflow extensions to BPEL that the technical committee in OASIS didn’t have the bandwidth (or perhaps the motivation) to attack.

But it turned out that the majority of users and vendors in attendance had no interest in BPEL at all. In fact, most would characterize it as a sort of 4GL for composite applications using web services, having little to do with business processes as understood by the BPM community. And that’s probably not unfair. The “BP” in BPEL, depending on one’s point of view, could be viewed either as a historical accident or a classic bait-and-switch. Certainly the community of programmers interested in composite applications using BPEL is distinct from – and larger than – the community of business process management.

Among attendees at the summit, there was far more interest was in “fixing” BPMN – giving it a metamodel and schema, mapping it to XPDL – and extending XPDL to handle everything BPMN could throw at it, including message links and events. Real work on XPDL 2.0 is well underway, as is the mapping to it from BPMN.

There was another group (myself included), far smaller, still interested in adding human workflow to BPEL. Most likely this would take the shape of a standardized TaskManager (Worklist) service rather than a new activity type in the BPEL language.

If either of these efforts leads to something that is implemented in successful commercial products, we might look forward to a new iteration of BPMS in the process lifecycle – something closer to the Third Wave vision, but with a twist. Instead of creating executable models within the BPMS environment, you’ll be able to build them anywhere, from enterprise architecture tools to specialty modeling tools to inexpensive Visio plug-ins, using BPMN as a business-friendly front end. You just draw the BPMN diagram, simulate and optimize it, and click to compile it to a complete executable process – deployable to any BPMS. In normal circumstances, the execution language will never be seen by the process designer. In some ways that’s even better than the Third Wave ideal, since modeling tools could be selected independently from the BPMS, something enterprise architects probably favor.

Behind the confusion, there is definitely hope for meaningful BPM standards. We’re really just getting started.

Similar Resources

Featured Certificate: BPM Specialist

Everyone starts here.

You're looking for a way to improve your process improvement skills, but you're not sure where to start.

Earning your Business Process Management Specialist (BPMS) Certificate will give you the competitive advantage you need in today's world. Our courses help you deliver faster and makes projects easier.

Your skills will include building hierarchical process models, using tools to analyze and assess process performance, defining critical process metrics, using best practice principles to redesign processes, developing process improvement project plans, building a center of excellence, and establishing process governance.

The BPMS Certificate is the perfect way to show employers that you are serious about business process management. With in-depth knowledge of process improvement and management, you'll be able to take your business career to the next level.

Learn more about the BPM Specialist Certificate





  • Business Process Management Specialist
  • Earning your Business Process Management Specialist (BPMS) Certificate will provide you with a distinct competitive advantage in today’s rapidly evolving business landscape. With in-depth knowledge of process improvement and management, you’ll be able to take your business career to the next level.
  • BPM Professional Certificate
    Business Process Management Professional
  • Earning your Business Process Management Professional (BPMP) Certificate will elevate your expertise and professional standing in the field of business process management. Our BPMP Certificate is a tangible symbol of your achievement, demonstrating your in-depth knowledge of process improvement and management.


BPM Certification

  • Make the most of your hard-earned skills. Earn the respect of your peers and superiors with Business Process Management Certification from the industry's top BPM educational organization.




  • Operational Excellence Specialist
  • Earning your Operational Excellence Specialist Certificate will provide you with a distinct advantage in driving organizational excellence and achieving sustainable improvements in performance.


OpEx Professional Certificate

  • Operational Excellence Professional
  • Earn your Operational Excellence Professional Certificate and gain a competitive edge in driving organizational excellence and achieving sustainable improvements in performance.



  • Agile BPM Specialist
  • Earn your Agile BPM Specialist Certificate and gain a competitive edge in driving business process management (BPM) with agile methodologies. You’ll gain a strong understanding of how to apply agile principles and concepts to business process management initiatives.  

Business Architecture



  • Business Architecture Specialist
  • The Business Architecture Specialist (BAIS) Certificate is proof that you’ve begun your business architecture journey by committing to the industry’s most meaningful and credible business architecture training program.

  • Business Architecture Professional
  • When you earn your Business Architecture Professional (BAIP) Certificate, you will be able to design and implement a governance structure for your organization, develop and optimize business processes, and manage business information effectively.

BA CertificationCertification

  • Make the most of your hard-earned skills. Earn the respect of your peers and superiors with Business Architecture Certification from the industry's top BPM educational organization.




  • Digital Transformation Specialist
  • Earning your Digital Transformation Specialist Certificate will provide you with a distinct advantage in today’s rapidly evolving business landscape. 


  • Digital Transformation Professional
  • The Digital Transformation Professional Certificate is the first program in the industry to cover all the key pillars of Digital Transformation holistically with practical recommendations and exercises.



  • Agile Business Analysis Specialist
  • Earning your Agile Business Analysis Specialist Certificate will provide you with a distinct advantage in the world of agile software development.


  • DAS Certificate
  • Decision Automation Specialist
  • Earning your Decision Automation Certificate will empower you to excel in the dynamic field of automated decision-making, where data-driven insights are pivotal to driving business innovation and efficiency.