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, Len,

I didn't know 1 or 2. Did know the bullet points. You're right, 
again. Listening is everything.

Ciao,
Rex

At 4:20 PM -0600 3/23/04, 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.


-- 
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request


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