OMG Process Introduction
- Who should read this description?
- Who does what, as the process evolves?
- What are the process stages?
Who should read this description?
Object Management Group (OMG) members write and adopt their specifications according to a very strict process, set out in the group's Policies and Procedures Manual, affectionately known as the P&P. Even though we'll describe the entire process here, keep in mind that Only the P&P description is official. If there's a discrepancy between it and this page, the P&P wins, every time.
There are at least two reasons why you might be interested in the OMG process: If you're a member, or thinking about becoming a member, you want to know all about the process (including its various nuances) so you can participate in it to influence specifications that you're interested in. This is the version for you, right here on this page.If you're about to participate in the process, or are already participating and need help understanding a step or two, you should read all of these pages and then follow up by reading The Hitchhiker's Guide to the OMG Technology Adoption Process. You'll find that these pages and Guide are complementary, looking at the same process from two different points of view. To observe and understand the sequence of steps, these pages suffice; but to run the process and come to each step with your i's dotted and t's crossed requires the additional information in the Guide (unless you've done it several times before).
On the other hand, if you're not a member but are interested in the specifications anyhow (because, for example, your company produces or uses products based on them), you're not concerned with the nuances but you do need to know about the various stages that a submission passes through on its way to becoming a specification, and on the maintenance process that keeps it evergreen.Our Download Instructions page tells you most of what you need to know so check out that page first. If you need more information, come back here.
Who does what, as the process evolves?
Participants play one of two primary roles during the process:
- A large group of OMG members participate in writing the RFP, evaluating the submissions that arrive in response, and voting on the results. We'll call this group the voters.The makeup of this group changes as the votes move from the TF, through the AB, TC, and finally the BOD.
- A smaller group write and edit the submissions. We'll call this group the Submitters.The members of this group are identified on OMG's web page for each standards effort, which you can access from our Work in Progress page. Once the LOI deadline passes, members of this group can drop out, but not join (or re-join).All submitters are automatically also voters, but not all voters are submitters.
The two roles are complementary.A shallow look suggests that they might be antagonistic at times, but this is not so: The culture of consensus at OMG creates an environment where these two groups cooperate as they work towards the goal of high-quality specifications.
The submitters' special role derives primarily from the responsibilities they assume by signing the Letter of Intent (LOI).
What are the process stages?
On this introductory page, we've put only a thumbnail sketch of each stage of the technology adoption process. Each stage has a full-page description of its own - click on its header in the outline below to go there. If your company is interested in contributing to the OMG technology standards, you'll be most interested in the RFP stage.
Click on a header for details:
- The TF writes an RFI and votes to recommend issuance by its parent TC.
- The TC votes to issue the RFI.
- The TF accepts, reads, and analyzes responses to the RFI.
- Possibly using information received via the RFI, the TF writes and votes to recommend issuance of an RFP by its parent TC.
- The AB approves the RFP.
- The TF's parent TC votes to issue the RFP.
- On or before the LOI deadline, one or more OMG member companies submit LOIs.
- On or before the Initial Submission deadline, which falls four weeks before an OMG technical meeting week, all or most of these companies submit initial submissions.
- Interested OMG members read the submissions, and comment on them during the meeting (especially if they find things they don't like, of course).
- During the interim between this meeting and the revised submission deadline, interesting things may happen.
- The revised submission deadline may be extended. There may be multiple deadlines for revised submissions.
- On or before the revised submission deadline, one or more revised submissions may be submitted.
- OMG members read and evaluate the revised submission (most likely) or submissions (less likely). If most members consider the submission worthy, a series of votes begins.
- If the votes are to begin at the meeting that immediately follows the revised submission deadline, a procedural hurdle known as the "vote to vote" is encountered.
- The TF votes to recommend adoption to its parent TC.
- The AB votes approval.
- The parent TC votes to recommend to OMG's BOD.
- The BOD Business Subcommittee (BSC) reports to the BOD on Business Committee Questionnaire responses from the submitters.
- If at least one satisfactory response was received, the BOD votes to adopt the specification. At this point, the submission becomes an official OMG Adopted Specification, but does not receive a release number.
- The TC charters a Finalization Task Force (FTF).
- The FTF performs the first maintenance revision on the specification, resolving issues submitted to OMG, while simultaneously producing implementations back in their companies.
- The FTF-revised version of the specificaiton is adopted as official OMG technology, through the same series of votes as the original submission (TF, AB, TC, and BOD). This time it receives a release number, and is designated an available specification.
- The document is edited into a formal OMG specification.
- Typically, products reach the market around this time too.
- A recurring maintenance cycle starts here. The TC charters an RTF and sets deadlines for its report and specification revision. .
- The RTF collects and acts on issues submitted to OMG, producing a revised specification.
- The revised specification is adopted through the series of four votes.
- A new RTF is chartered, and the process repeats.
- Obsolete (not superseded) specifications may be retired