TF Issues RFP and Evaluates Submissions
- What's in an RFP?
- Who can respond to an RFP?
- Are RFP deadlines important?
- What is a closed voting list?
- Tell me about the Letter of Intent, please.
- How seriously should I take those Initial Submissions?
- So the Revised Submissions are closer to the real thing, then?
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 [email protected] (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.
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.
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.
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 ([email protected]). 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.
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!
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.
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.