OASIS Emergency Management TC

 View Only

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

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

    Posted 03-23-2004 22:06
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    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


    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.
    


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