OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [emergency] FW: [legalxml-intjustice] GJXDM subset schema exa mple and documen tation

Thanks.  Analyst at work.  One more example before I 
go...  please, this is not in reference to anyone here 
or the work of this group.  It is just Tales of Nasrudin...

There is another category of RFP that is harder to work 
with.  A consultant, typically a retired industry professional 
goes to school and gets a masters degree while reading a lot 
of magazines and other works from which he/she abstracts a 
computer architecture for a futuristic system, in their opinion.  
One can spot these because they will 
contain a mix of terminology that is long in the tooth 
with some that is probably ten years into the future. 
Because the consultant come from the industry, they do understand 
perfectly the document types and processes, but the text 
they contribute to the RFP is for an architecture that can't 
be built today cost-effectively if at all.   The RFP 
is issued by a forward looking agency without vetting 
it in the industry.

These are disasters unless the forward facing vendor 
reps can get in there and adjust expectations, or the 
vendor reworks the response to match the language of 
the RFP but with all contractual details bound to an 
implementable product.   The trick is to specify 
what can be delivered within the cycle.  A typical 
RFP is bid about 18 months ahead of implementation, 
so any technology it includes must be road worthy 
within that cycle.  Because systems are built today 
over frameworks from other vendors such as Microsoft, 
Sun, etc., the system vendor is behind their curve 
and until the platform framework vendor is ready, 
the system vendor can't implement completely.  So any reasonably 
large procurement will be for a system that is somewhere 
between four and five years behind the leading edge, 
or will be a one-off that may be a cul de sac or may 
be the prototype for the next generation.

The procurement official bets their badge on that.


-----Original Message-----
From: R. Allen Wyke [mailto:emergency-tc@earthlink.net]
Sent: Friday, March 26, 2004 9:46 AM
To: Bullard, Claude L (Len)
Cc: Art Botterell; Emergency TC; 'Rex Brooks'
Subject: Re: [emergency] FW: [legalxml-intjustice] GJXDM subset schema
exa mple and documen tation

<roundofapplause method="standing">clap, clap, clap</roundofapplause>

You are, as you have done so many times, hitting on the essence of both 
the market, the opportunity, and the challenge. I can appreciate what 
you are saying on many different levels (standards guy, author, CTO, 
technology, business strategy, etc.). Putting on my Blue292 hat for 
just 1 second, what you just described is what we call some of the 
characteristics of the "nut". The nut we are trying to crack. It is 
very easy to get absorbed into the trees and never see the forest. 
Sometimes you do have to think different.


On Mar 23, 2004, at 5:20 PM, Bullard, Claude L (Len) wrote:

> A typical adoption will be something like, this early:
> o  Must use XML for all external interfaces
> which is a very weak requirement.  Then later:
> o  Must implement CAP (version) for alerting to (cite receivers)
> or something like that, which is specific and a strong
> requirement.  Ideally, by the time that strong requirement
> appears, a studious sharp vendor has done their homework
> and is within a year of fielding the features to support
> a requirement.  Keep in mind, a single requirement can
> spawn multiple tasks and implementations in a single product.
> If you read RFPs, after awhile you discover that they are seldom
> written by the procurement organization, but by a consulting firm
> such as Gartner. There are some points of interest:
> 1.  Some consulting firms analyse the organization's data and
> business rules and produce a tight specification based on the
> current organization.   These are actually bad RFPs.  They create
> many exceptions and a one-off custom product.
> 2.  Some consulting firms have a boilerplate RFP consisting of
> the most common requirements they have discerned over some
> number of procurements.   These are better because like a
> standard, they represent accumulated knowledge over a domain.
> The problem either of these have is that they may not follow
> the price domains, sometimes called 'market tiers'.  These means
> the procurement is specifying a system which a given customer
> cannot afford to buy and the vendor cannot afford to build at
> that price point.  If the evaluation group is doing a naive
> evaluation, say just counting nos and yeses, they may reject a
> bid that is actually closest to their price point and buy a
> system that cannot be delivered.  The typical result is they
> lose the money invested and have to do it all again.
> As is easy to observe, this process affects commodization and
> thus, standardization.  Over time, tiers tend to collapse downward
> and thus, smaller vendors with the right products at the right
> time can gain in market share by taking it from established
> vendors.
> Listening is everything.  Timing is everything else.
> len
> From: Rex Brooks [mailto:rexb@starbourne.com
> To be honest, I doubt we could settle this notion of adoption uptake
> in RFPs here.
R. Allen Wyke
Chair, OASIS Emergency Management TC

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]