The OMG Specification Process

1
The OMG Specification Process

• OMG Government DTF Workshop
• Records Management Services RFP Briefing
• London UK 16-June-2006

2
From Requirements to Specification

• Prepare and Issue a Request for Information (RFI)
• Submit a Response to the RFI
• Response Evaluation
• Identify Request for Proposals (RFPs) for
  Roadmap Select RFP(s) for Execution
• Write RFP
• Form Response Teams
• Submit Letters of Intent to produce software
  based on RFP Response
• Prepare and Submit Response to RFP
• Evaluate Responses and Provide Feedback
  Recommendations to Submitters
• Prepare and Submit Revised Submission

• Evaluate Submissions and Select One to be the OMG
  Specification (or reject all)
• Submission Evaluated by Architecture Board
• Submission Modified as Needed to Mollify
  Architecture Board
• Up or Down Vote on Submission by the Domain
  Technology Committee (14 week eMail vote)
• Business Committee issues Questionnaire to
  Submitters concerning their plans to produce
  software based on the submission.
• Submitters return completed Questionnaire
• Business Committee evaluates commercial future of
  the submission
• Board of Directors votes up or down on
  Submission.
• Submission becomes anAdopted Submission

Actvities in Red take place Outside of the OMG
3
The Task Force Roadmap Participant Driven

• OMG and its Task Forces have no specific agenda
  apart from that established by participants.
• Using RFIs and/or meeting discussions, a likely
  progression of work items is identified by each
  OMG subgroup.
• However, no item is executed until a sufficient
  number of participants decide to come to the
  table and work on it.
• Our Roadmap is embryonic, but it was clear that
  the RMS Functional Requirements and the interest
  of US Government Agencies and Industry dictated
  that our first work item will be the RMS RFP.
• This meeting represents the kickoff of that work
  item.

4
Issuing a Request for Proposal (RFP)

• The Task Force documents the requirements for a
  specification as an RFP.
• (Task Force a team of participants with a
  vested interest in the specification as end-user
  or vendor)
• An RFP establishes requirements for a
  specification that are in keeping with the
  architectures and principles of the OMG.
• Every RFP must therefore be approved by the
  Architecture Board.
• A schedule with deadlines for initial, revised
  submission dates (and other process milestones)
  is established
• Each RFP is then approved by the appropriate
  Technical Committee

5
Responding to an RFP

• Response to an RFP takes place outside the OMG
  Process. (The OMG does not write specifications.
  It merely provides a process through which the
  community can come to consensus.)
• Teams of Vendors and End Users form to respond to
  the RFP.
• (Typically these teams are the same folks who
  came to consensus on the requirements in the RFP.
  These are the people with vested interest in the
  common standard.)
• To respond to an OMG RFP is not to propose to do
  the work, but to propose an actual specification
  to be adopted by the OMG (i.e., the response IS
  the work).
• The Response Teams have full control of their
  specification.

6
No Shelfware!!

• RFPs are accepted from Domain or Platform
  members above who have written a Letter of
  Intent to produce software in compliance with the
  specification they are proposing, if it is
  accepted.
• Therefore, Vendors have a special place in the
  process as the specification moves through its
  life-cycle.
• There are additional steps in the process to
  assure that the intent to produce product
  compliant with the specification still exists
  prior to Adoption.
• If after a period of time there are no
  commercially viable implementations of an adopted
  specification, nor interest in producing one, the
  specification is deprecated.

7
Task Force Review and Approval

• The Task Force establishes a review team to lead
  an analysis of the Initial Submissions,
  addressing compliance pluses minuses.
• If there are multiple Response Teams, they are
  encouraged to form a single Joint Response Team.
• (We like singing Kumbaya, but it is an artifact
  of culture, not policy)
• Revised Submissions are similarly evaluated.
• The Task Force votes on which submission they
  will recommend for adoption.
• The Task Force may, if it feels it necessary,
  establish a third revision deadline, or simply
  vote all submissions down, deciding that none of
  these dogsll hunt.

8
Review by the Architecture Board

• The Architecture Board reviews the specification
  to assure it is compliant with OMG architecture
  and principles.
• If the Task Forces recommended specification is
  not compliant, the Task Force is apprised of what
  needs to be fixed.
• (Generally the Submitters and Task Force are
  frequently touching base with their AB Buddy,
  so there are no big surprises, but it seems a
  little something always needs fixing).
• The Architecture Board votes up/down on the
  submission.

9
Poll of the Technical Committee

• The appropriate Technical Committee then votes
  (one vote per member organization) up or down on
  recommending the submission to the Board of
  Directors.
• This takes 1 to 3 months as the specification is
  deliberated and the votes are collected by eMail
  or fax.

10
Approval by the Board of Directors

• The Business Committee of the Board of Directors
  sends out business questionnaires to assure that
  the specification will be implemented by someone.
• The Committee then provides its report to the
  general Board.
• Assuming a good report, the Board of Directors
  approves the specification, making it an Adopted
  Submission

11
Life Cycle of a Specification

• Emerges from the Board of Directors as an Adopted
  Specfication
• Finalization Task Force (FTF) is formed
• Issues arising from implementation are identified
• Specification is revised based on issue
  resolution
• Revised Specification goes through the submission
  approval process (AB, DTC, Business Committee,
  Board of Directors)
• On approval, the specification becomes
  anAvailable Specification
• A Revision Task Force (RTF) is formed to handle
  any reported issues, fixing any problems that are
  discovered.
• The RTF fixes errors or inconsistencies and
  issues a Revised Specification through the usual
  process (AB, DTC, Business Committee Board of
  Directors)
• As each RTF completes its work, another is
  chartered to assure there is always a seated RTF
  to field problems over the life of the
  specification.

12
It Seemed Like a Good Idea at the Time
The Finalization Task Force (FTF)

• As implementation of the Adopted Submission
  proceeds during the first year of specification
  life problems with the specification are
  inevitably discovered.
• The FTF is responsible for fixing these problems.
• The repaired submission goes through the
  approval process.
• On approval by the Board, the Adopted Submission
  becomes an Available Specification

13
Once More with Feeling (and then again, and
again, and again)

• The FTF has fixed any truly significant problems
  at this juncture, but no one expects all problems
  have been found.
• There is always a seated Revision Task Force to
  address/fix issues throughout the life of the
  specification.
• The life of the specification is directed by
  experience and implementation.

14
Assuring Investments are Protected

• In the FTF/RTF Process, vendors with an
  up-to-date LOI and Business Questionnaire have
  Veto Power over any change in the specification.
• This protects the investment of vendors who have
  skin in the game.
• Additionally, RTFs have limited latitude in how
  much can be changed in a specification. An RTFs
  changes are supposed to be limited to fixing
  fiddley-bits and minor contradictions. The
  Architecture Board makes the call.