BPMN 2.0 and the OMG Standards Development Process

[Former Member]

Overview of the Standards Development Process

OMG's Organizational Structure

     The OMG Technical Committee

     Task Forces, SIGs, and Working Groups

     MDA and CORBA

     Roles of the Platform Technical Committee vs. Domain Technical Committee

     The Business Modeling and Integration Domain Task Force

     Membership Categories

The Standards Creation Process in Some Detail

After I posted my recent blog about BPMN 2.0, I received a question from a reader who had gone looking for the BPMN 2.0 specification and could only find the RFP. 

The short answer is that it's very early in the BPMN 2.0 lifecycle, and thus the Object Management Group (OMG) has no BPMN 2.0 specifications yet.  The BPMN 2.0 RFP was issued only six weeks ago, and it invites OMG members to submit specifications to be considered for standardization. 

The OMG's standards development process is different in some respects than that of other standards bodies.  Thus, I think an overview of the OMG's process and organizational structure might be useful to those who would like to follow the emergence of BPMN 2.0.

https://weblogs.sdn.sap.com/cs/blank/edit/wlg/https://weblogs.sdn.sap.com/cs/blank/edit/wlg/Overview of the Standards Development Process

The OMG's standards development process is on the rigorous side, as standards development processes go. 

RFPs kick off the process of producing specifications that are candidates for adoption as a standard.  RFPs must pass a majority vote of the administering Task Force, then must pass a majority vote of the Architecture Board, then a majority vote of the general membership.

Specifications that are submitted in response to an RFP must pass a majority vote in the Task Force, then a majority of the Architecture board, and then a two-thirds supermajority of the general membership. 

Specifications that clear these hurdles also require certification by the Board of Director's Business Committee that there has been some commercial implementation, and, finally, a majority of the full Board of Directors must vote to approve before the specification is "available" as a standard to the general public.

The fact that the OMG has an Architecture Board with real power is notable point.  The Architecture Board is elected from the general membership.  The Architecture Board scrutinizes RFPs particularly closely, to make sure that they are consistent with the architecture of other OMG standards and to ensure that they don't seek to duplicate other OMG standards or non-OMG standards.

https://weblogs.sdn.sap.com/cs/blank/edit/wlg/OMG's Organizational Structure

Before going into the standards development process in more detail, it's useful to understand how the OMG is organized.

https://weblogs.sdn.sap.com/cs/blank/edit/wlg/The OMG Technical Committee

OMG Technical Committee manages the creation of standards .  It is divided into the Platform Technical Committee and the Domain Technical Committee.

The Technical Committee meets four times per year, running from Sunday through Friday.  Before 9/11, attendance at meetings was in the 500-600 person range.  After 9/11 it dropped immediately to 225-275.  It has slowly worked its way back up to 300-350.

https://weblogs.sdn.sap.com/cs/blank/edit/wlg/https://weblogs.sdn.sap.com/cs/blank/edit/wlg/Task Forces, SIGs, and Working Groups

The Platform Technical Committee and Domain Technical Committee consist of Task Forces, which recommend issuance of Requests for Proposals (RFPs) and recommend adoption of specifications as standards.

There are also special interest groups (SIGs), which have no such powers.   Special Interest Groups either address cross-cutting concerns or are nascent Task Forces.  If they wish to initiate the creation of a standard, they have to do so through a Task Force.

Task Forces often create working groups.  Working groups have no standing in the policies and procedures, and thus are informal bodies.

https://weblogs.sdn.sap.com/cs/blank/edit/wlg/https://weblogs.sdn.sap.com/cs/blank/edit/wlg/MDA and CORBA

Originally, the OMG was only about CORBA.  OMG has been the steward of the CORBA standards from CORBA's inception around 1990.  In 1997, the OMG ratified Unified Modeling Language (UML) and MOF, the first non-CORBA OMG standards, and Model-Driven Architecture (MDA) is a stack of OMG standards that has evolved from that work.

So now there are "two sides of the house"-- the CORBA side and the MDA side, although this distinction is not formally enshrined in the governing policies and procedures.  There is a significant amount of cross-fertilization; for instance, there is a UML Profile for CORBA and some of the originally CORBA-oriented Task Forces are defining "platform-independent" UML models with bindings to CORBA and to other technologies.

In the enterprise computing world, people assume that CORBA is a dead letter.  This is because Enterprise computing uses CORBA mostly under the covers, such as in the core of J2EE, but it is not part of the programming model that developers see.  However, the world of realtime and embedded systems uses CORBA quite a bit.

So the CORBA side of the house is very active with some large companies involved, but, almost exclusively, the companies involved are in realtime-embedded domains, including aerospace, command and control systems, and so on.  CORBA 3, which includes a powerful component model called the CORBA Component Model (CCM), is important in this context.

https://weblogs.sdn.sap.com/cs/blank/edit/wlg/Roles of the Platform Technical Committee vs. Domain Technical Committee

Originally there was only one Technical Committee.  The lineage of today's Platform Technical Committee traces back to the original, single Technical Committee.  The Platform Technical Committee has Task Forces that define and maintain the standards for the CORBA platform stack, and Task Forces that define and maintain the standards for the MDA stack

The Domain Technical Committee was created later to create standards for vertical markets.  The most active Domain Task Forces and Domain Special Interest Groups in OMG are in markets that have a large amount of realtime-embedded systems, such as aerospace, air traffic control, software-controlled radio, command and control for military and emergency services, and so on. 

The active Domain Task Forces in enterprise software cover finance, healthcare, and government, and a new one is spinning up for Governance, Risk, and Compliance (GRC).  The Domain Task Force that I know the most about is the Finance Domain Task Force, which works in close collaboration with the ISO expert group that maintains the ISO 20022 (a.k.a. "UNIFI" standard).

https://weblogs.sdn.sap.com/cs/blank/edit/wlg/The Business Modeling and Integration Domain Task Force

The Business Modeling and Integration Domain Task Force has jurisdiction over BPMN.  It was formed following the merger of the BPMI.org into the OMG.  BPMI.org was the original steward of the BPMN standard. 

The fact that this new Task Force is a Domain rather than Platform Task Force is an anomaly, tracing back to some history in the OMG that isn't worth going into.  Logically, it should be a Platform Task Force, because BPMN is not specific to any vertical market.

https://weblogs.sdn.sap.com/cs/blank/edit/wlg/https://weblogs.sdn.sap.com/cs/blank/edit/wlg/Membership Categories

There are a number of membership categories.  Members are organizations, not individuals:

• Contributing Member: Can submit technology proposals (i.e. can submit responses to RFPs that consist of specifications to be considered for standardization) to the Platform and Domain Technical Committees, can vote on resolutions in both Technical Committes, and has access to all email lists and member-only areas of the web site
• Platform Member: Can submit technology proposals to the Platform Technical Committee only, can vote on resolutions in both the Platform and Domain Technical Committees, and has access to all email lists and member-only areas of the web site
• Domain Member: Can submit technology proposals to the Domain Technical Committee only, can vote on resolutions in both the Domain and Platform Technical Committees, and has access to all email lists and member-only areas of the web site
• Influencing Member:  Cannot submit technology proposals or vote, but has access to all email lists and member-only areas of the web site.
• University Member: A special category for universities providing full email rights and access to member-only areas of the web site, but conferring no voting rights
• Trial: Similar to Influencing, with lower cost; but a company cannot stay in this status for more than one year and, and only one person from the company can use the email lists and member-only web pages.
• Analyst: Also similar to Influencing, for accredited industry analysts.

SAP is a Domain Member.

https://weblogs.sdn.sap.com/cs/blank/edit/wlg/https://weblogs.sdn.sap.com/cs/blank/edit/wlg/The Standards Creation Process in Some Detail

The first step in the creation of a standard is to issue an RFP for technology proposals.  Task Forces initiate RFPs, which have to be approved by the Architecture Board and the general membership of the Technical Committee (Platform or Domain) to which the initiating Task Force belongs.  The BPMN 2.0 RFP was issued in June, 2007.

A response to an RFP is a draft standard, and is called a "submission."  There are initial submissions and revised submissions.  Multiple companies often form alliances and co-submit.  Usually there are a number of competing initial submissions coming from different alliances.  After initial submissions are received, mergers of co-submission alliances usually occur to produce revised submissions, often resulting in one unified, revised submission.  The RFP specifies deadlines by which submissions must be received.  The BPMN 2.0 RFP's initial submission deadline is February 18, 2008.  Revised submissions are due June 2, 2008. 

Each RFP has a registered voting list consisting of member companies with voting rights who took the assertive step of registering to vote.  This entitles each member company to one vote on any resolution having to do with that RFP, including the changing of submission deadlines and recommending of a submission for adoption as a standard.  The RFP establishes a deadline for registering to vote.  The registration deadline for BPMN 2.0 is February 18, 2008.

Once revised submissions have been received, a Task Force plenary can entertain a motion to recommend adoption of a submission. If a majority of the members of the registered voting list who are present vote in favor of the motion, the Task Force passes on that recommendation to the Architecture Board.  The Architecture Board either approves, rejects outright, or sends a submission back to the Task Force for more work on specific points. 

Upon approval by the Architecture Board, the submission is an "adopted" standard but is still not "available" to the general public.  the relevant Domain Technical Committee -- i.e., the Platform Technical Committee or the Domain Technical Committee -- casts votes to ratify the standard.  Unlike the vote in the Task Force and Architecture Board, which requires a simple majority of the registered voting list, the Platform or Domain Technical Committee vote requires a two-thirds super majority of the general membership.  

At that point, the relevant Technical Committee charters a Finalization Task Force to fix bugs that member companies encounter during implementation of the standard.  Once the Finalization Task Force finishes its work, and once the OMG Business Committee (an arm of the Board of Directors) certifies that there is at least one implementation, the Board of Directors approves the standard and it becomes "available."  Prior to reaching this last stage, the specification documents are accessible only to members.  Once the standard is "available," anyone can download the documents from the public area of the OMG web site.