OMG Technology Adoption Process
Part II: TF Issues RFP and Evaluates Submissions
|
|
|
|
What's in an RFP?
OMG technology adoptions revolve around the RFP, or Request
for Proposals:
- The issuing of an RFP by vote of a TC officially starts the
adoption process running.
- The RFP itself is the requirements document for the future
specification.
- The RFP lists the original deadline dates for each stage of
the adoption process. (We will see shortly that many of these
dates change as the process progresses.)
OMG's Work in Progress
web page lists every specification
effort underway in the group. All new efforts are listed under
their RFP name. (Maintenance efforts are listed as either RTF or
FTF.)
How do I write an RFP?
If you're an OMG member, you can download
the RFP template from the OMG document server, and write your
requirements summary into it at the beginning, and full
requirements and timetable into Chaper 6. Hopefully, you will have
some friends who support your efforts and will help you. When you
and your friends finish your first draft, you will have to take it
to a Task Force for a vote to recommend issuance.
How do I download an RFP?
On the Work in Progress
page, click on the name of an RFP
you're interested in. On the detail page that comes up, in the
table near the top, click on the RFP's document number (in the
leftmost column headed "Notes"). This brings up a page
with URLs for download of the RFP in a number of formats. Click
on the format you like to download the document.
The first page of the RFP contains a lot of information: It
starts with the OMG's address and telephone contact info, followed
by the RFP's title in bold type, and its document number. Beneath
this are two lines giving the due dates for LOIs (on RFPs issued
since mid-2000) and Initial Submissions. Below is the heading, Objective
of this RFP:, followed by a list of objectives and the
admonishment that details follow in Chapter 6.
What's in Chapters 1 through 5, then? OMG members
affectionately refer to these chapters as "boiler
plate", since they come from a template and do not change
from one RFP to the next. But, if you're not
familiar with OMG and its technology adoption process, these
chapters are essential reading. Chapter 1 is a brief, general
introduction. Chapter 2 places the technology in its context with
respect to CORBA and the Object Management Architecture (although
not UML or any of OMG's other modeling standards). Chapter 3
summarizes the adoption process - think of it as a version of this
web page in formal dress. Chapter 4 consists of instructions for
submitters; it includes a template for the LOI and states OMG's
requirements for commercial availability and access to IPR. Ending
this section, Chapter 5 lists general requirements on proposals.
Chapter 6 presents the topic-specific requirements on
proposals. Its nine section headings (but none of their content)
are prescribed by the template. We won't list the sections here;
you'll find them easily enough when you download an RFP and read
through it.
The last item in Chapter 6 is the timetable. As you read it,
keep in mind that TFs are free to extend dates almost at will, as
long as they honor the requirement to extend dates uniformly for
every participant, post the new dates conspicuously, and always
extend at least two weeks beyond the day that they vote the
extension. For the latest dates, click on the RFP name on the Work
in Progress page and read the dates off the table. Dates may
change during an OMG
meeting technical week - if you need to know about a date during a
meeting, email juergen@omg.org
(or look for him in the hallway if you're at the meeting) and ask him if the dates have changed. For more about dates, look
down two topics.
Top
|
|
|
Who can respond to an RFP?
OMG members are companies, not people. Companies that respond to RFPs (and only companies, not people,
may respond) are referred to as submitters or submitting
companies.
Any company that is an OMG member at one of the required levels
(see next paragraph) may submit in response to an OMG RFP. Since any company may join
OMG at any level, submission is open to every company. Submitting
companies must also agree to meet certain conditions; see Letter of
Intent three topics down.
If the RFP was issued by the PTC, a company must be either a
Contributing or Platform member of OMG in order to submit. If the
RFP was issued by the DTC, the company must be either a
Contributing or Domain member. Companies can join OMG by
filling out this form and paying the
requisite
fee, which is based
on your company's revenue.
Top
|
|
|
Are RFP deadlines important?
Absolutely. Late LOIs and submissions are not accepted into the
process. TFs have been known to extend deadlines from time to
time, to cope with late letters and submissions, but this is a
hassle as well as an imposition on the other members. The P&P
requires that (as we mentioned two topics above) the deadline be
extended at least two weeks, for all companies equally, and that
the new date be posted on OMG's website for all to see. Because it
is only practical to vote deadline extensions at the OMG technical
meetings which happen only four times per year, extending an LOI
deadline typically delays a technology adoption a minimum of three
months. OMG members (and the companies that submitted their LOIs
on time) are loath to vote such delays, and do so only under
duress. If you intend to submit to an OMG RFP, be sure to get all
of your documents in on time!
Initial submissions must also get in on time. If a company's
initial submission does not come in on time, the company loses its
submitter status.
The situation is different for revised submissions. Frequently, submitters discover during the
writing process that the submission requires more time and effort
than they had expected, and that it's impossible for them to complete
a revised proposal by the deadline. Good form in this
instance requires that the company submit what they have by the
deadline, and present a progress report to the TF at the following
meeting along with a
request (in the form of a motion) to extend the
deadline. These requests are virtually always honored.
For the latest revision of the dates for an RFP, click on its name on the
Work
in Progress page and read the dates off the table.
Top
|
|
|
What is a closed voting list?
There is no "membership roster" for any OMG TF: Every
company of every membership level that is allowed to vote (that
is, every level except trial and analyst) is allowed to vote in
every
TF. In practice, resource constraints prevent companies from
participating and voting in TFs except those where their primary
interests lie. So, in spite of the seeming lack of procedural constraint, TF
meetings attract very few participants who are not truly
interested, but most (from among the attending member delegates,
anyhow) who are.
However, to gain the advantages of consistent membership (that
is, a fair
decision by informed voters), a TF may (and virtually always does)
close its voting list on an RFP-by-RFP basis. Companies register
for a voting list by informing either the chair of the TF or,
preferably, OMG's process manager Juergen Boldt via email (juergen@omg.org).
The deadline for signup for a voting list typically falls around the deadline for
initial submissions, and is listed on the RFP and posted on the
RFP's web page, one click away from the Work
in Progress page. The
list of registered voting companies is listed there, too.
For an adoption, there are four votes in all: in the TF that
issued the RFP, the AB, the
DTC or PTC, and OMG's BOD. The closed voting list affects only the TF vote.
There's a lot more about the four votes on
the next page.
Top
|
|
|
Tell me about the Letter of Intent, please.
There's a template for the LOI in every RFP: http://doc.omg.org/loi
In its LOI, a company states that it intends to submit in response
to the RFP named in the letter, and that it will comply
with OMG Business Committee requirements in five areas:
- Viability;
- Commercial availability;
- Access to IPR;
- Publication; and
- Continuing support.
Because these are legal commitments and the exact wording is
important, we haven't paraphrased them. Instead, we've copied them
onto a page which you can look over by clicking
here.
If your company is considering submitting to an OMG RFP for the
first time and your legal beagles are worried about the LOI,
there's one thing they and you should know which isn't obvious at
first glance: The legal obligations in the LOI, which are very
real and should be taken very seriously, nevertheless only take
effect when and if your company's submission is adopted as the
official OMG specification. Until they do, it is very easy to drop out of the
process and shed these obligations. Why is this important?
Read on:
Frequently, technical staff in a company will want to submit an
LOI but encounter resistance from their legal department as the
LOI deadline approaches. Because it is difficult (and sometimes
impossible) to extend the LOI deadline, it is preferable to submit
an LOI on time and withdraw later, rather than missing the
deadline and forcing OMG members (including all of the companies
that submitted their LOIs on time) to extend the process deadlines
on your account.
There are lots of ways to drop out: The easiest way is to fail to submit an initial
submission by the deadline; companies also drop out by sending a
letter or email to OMG. It's considered bad form to participate
all the way through and drop out just before the final BOD vote,
especially if you're the only submitting company -
by this time, many people have invested time and effort into
evaluating and voting for a company's submission and they deserve
consideration. Nevertheless, some adoption efforts make it this
far and then fail when the submitting company fails to submit an
acceptable Business Committee questionnaire, which is the last way
to bail out. In any case, once a company drops out, it no
longer bears any of the obligations of the LOI. The company
is also not allowed to re-enter the process. Dropping out is
final!
Top
|
|
|
How seriously should I take those Initial Submissions?
That depends on whether you're a voter or submitter. And, in
order to explain this, we have to go over a bit of OMG lore about
the tendency for initial submissions to get merged into a far
smaller number of submissions (typically one) during the revision
period.
Typically, an RFP will attract between a half-dozen and a dozen
LOIs and receive only a slightly smaller number of initial
submissions. (Some companies drop out between LOI and initial
submission stages. Other companies form small groups and submit
only one document for the group.) Some RFPs, especially in
specialized domain areas, attract only one or a few LOIs.
Following the initial submission deadline, a period of four
months (plus or minus; the period is suggested but not fixed by
the P&P) is allotted to revision of submissions. No rules
restrict the amount of revision that may be done: Any company that
submitted an LOI and initial submission by their deadlines is
allowed to submit anything it likes as a revised submission by
its deadline. And, as you figured out from the last paragraph,
companies are allowed to submit together as long as every company
has submitted its various documents by their deadlines. Just as
there are no restrictions on the content of the revised
submissions, there are also no restrictions on the composition of
submitter groups which can change at the whim of the companies
involved. Submitter groups are not OMG subgroups and not subject
to any open membership requirements. The group
itself determines its membership and how it works.
The OMG P&P says nothing about merging of submissions,
although the RFP template acknowledges that it may happen.
Merging, when it does occur, takes place outside the OMG
process. (So does the writing of submissions, which remain the
property of the submitting company subject to the constraints in
the LOI business annex that we just discussed.) Nonetheless,
merging happens to virtually every RFP that draws more than one
submitting company, so there must be powerful economic motivation
to merge, in addition to the tradition among OMG members to attain
as wide a consensus as possible on every specification.
Because of the likelihood of a merger, the revised submission
will likely be different from all of the initial submissions
although it may have a strong resemblance to one of them. Don't
assume that you'll get an opportunity to select one submission out
of several, if you're a
voter. But, it would be worthwhile for you to examine the original
submissions for
good architecture and technical ideas, and watch for these to
carry through into the revised submission. If they're not in it,
you can bring this up during the evaluation meetings, or by email
over the TF's discussion list.
If you're a submitter, the other companies' initial submissions
are important to you. They represent what these companies bring to
the table for the merger negotiation process, and suggest what they may
want to see in a revised submission that they can support.
Top
|
|
|
So the Revised Submissions are closer to the real thing, then?
Well, yes, although the first round of revisions is probably
not the final word.
Sometimes, a single revised submission comes in at the original
deadline set in the RFP, and it's so good and complete that the TF
members take one look and vote to recommend it for adoption. This
is great when it happens. It's also rare. So, what else might
happen?
Sometimes, the submitters underestimate the amount of work
necessary to dot all the i's and cross all the t's on their
submission, and discover as the deadline approacheth that they
need more time. In this case, they submit an interim document by
the deadline and notify the TF by email that they plan to request
an extension at the upcoming meeting. At that meeting, the
submitters present a progress report and ask (by way of a motion)
for an extension. Virtually without exception, the extension is
granted. This is the most common reason that deadlines get
extended.
Occasionally, submitters will present a document which they
think is acceptable and discover at the meeting that some voters
think otherwise, or (more likely), an issue will come up in
discussion at the meeting and all (submitters and voters together)
will agree that the submission needs to be changed to resolve it.
This, also, may result in a deadline extension and a new revised
submission. (If the issue is small, it may be dealt with in
an erratum attached to the submission and no deadline extension
will be necessary.)
On occasion, issues come up during AB review (which we cover
on the next page) and the submission needs to be changed to resolve them.
This may require a deadline extension vote in the TF, and a new
revised submission. (If the AB considers the issue minor, it will
be dealt with in an erratum added to the submission, or later during the finalization process. This
doesn't delay adoption.)
Once all issues have been resolved, the last revised submission
undergoes a series of four votes
(next page). After successful completion of
these votes, the submission document becomes an OMG specification.
Top
|
|
|
Last updated on
02/14/2013
|
|
