Re: additional para from 31 oct telecon

Roger,

Starting with your second point (the business context): In the EDI world, Implementation Guides are often far larger than the underlying standards specifications.  It can take many consultants, developers and business analysts working for many months to get from legal contract to first production business document exchange.  One year later, the agreement changes slightly and both sides need to find those consultants again.  This illustrates two related problems: The need to describe this information for human use and the common inflexibility (hard coding) of the implementations.

Since one part of the deployment process that's presently manual is implementing and enforcing the appropriate sequencing (choreography) of interactions between the trading partners, automation of this deployment step should be a big win to Chevron Texaco.  In short, we're trying to save you some time and money.  It doesn't solve the entire manual deployment problem but does continue the chipping away at it begun with interoperable messaging solutions (no need to recode at that layer) and interface description languages (easier to respond to changes and variance between your relationships).  We aren't replicating an existing EDI feature, we're working on one of its oft mentioned issues (time to deployment).  A general solution may even be applicable for future EDI deployments.

On the last sentence (the standards context): The point was around the ability for vertical standards bodies to use a standard language when describing the relationship between the documents they define.  This horizontal standard would support the vertical standard development effort, providing those bodies (OTA, RossettaNet, CIDX, AIAG, STAR, ...) with standard infrastructure and allowing them to concentrate on adding value in their problem domain.  It also allows vendors to create horizontal solutions more adaptable to the demands of the different verticals.  Again, this saves money for customers such as Chevron Texaco because the software you purchase is configured for your requirements and not developed against them (scaling the market).

I'm now wondering whether "vertical" is required in the above description and whether the interoperable implementation value is a footnote on the ability to focus.  Could we rephrase Jeff's last sentence as:

    As well, creating a standard language to describe the relationships
    between document exchanges will be helpful to other standards
    bodies, such as RosettaNet or CIDX, giving them a standard
    infrastructure for message choreography and enabling them to focus
    on the core competencies relevant to their domain.

thanx,
    doug

Cutler, Roger (RogerCutler) wrote:

>Looks pretty good to me.  However, I honestly do not understand the last
>sentence at all.  I'm not disagreeing with it, I'm just not getting it.  Is
>there some way that you can recast or expand it to make it more clear?
>
>Maybe I should try to be more explicit about my confusion, if that is
>possible.  In this sentence I don't understand what "standards context"
>means.  Using or makinfg standards?  Does "specification of choreographies"
>mean specifying techniques of expressing choreographies or specific
>instances of choreographies (like "A sends an invoice to B")?  In either
>case, what does it mean to be interoperable and what is the value?  Is this
>interoperable between Oracle and IBM or between W3C and OASIS?  I think,
>from the discussion on the phone, that it may be the latter.  If so, I
>really think that this needs to be explained more clearly and the actual
>area of value added explicitly pointed out.
>
>So far, "reduce the cost of integrating with new trading partners and
>responding to changes in existing interfaces [that effect the logic of the
>message exchanges]" is the core of the business value I am seeing displayed.
>Are there any other payouts?  It really seems to me that there might be, but
>I'm not coming up with anything real specific.
>
>As it stands, it seems to me that this business value may be achieved by a
>rather small subset of the complex specs in play.  That is, what I would
>call (probably not very accurately) the message sequencing part.
>
>-----Original Message-----
>From: Jeff Mischkinsky [mailto:jeff.mischkinsky@oracle.com] 
>Sent: Friday, November 01, 2002 3:59 AM
>To: www-ws-arch@w3.org
>Subject: additional para from 31 oct telecon
>
>
>
>Hi,
>    Here's my attempt to capture today's discussion centering around adding 
>a description of the business drivers for developing a choreography spec.
>
>This goes right before Section 1.1 - Inputs
>
>cheers,
>   jeff
>
>  WSDL has proved very useful for describing a single service. Currently 
>complex natural language describing the obligations of the participants 
>detailing how to use a service (sequencing, state management, etc.) have to 
>accompany a WSDL description. The next step is to partially replace these 
>somewhat imprecise instructions with precise language. This will simplify 
>the daunting task companies now face when trying to use web services to 
>integrate their business processes. In a B2B context such a specification 
>could reduce the cost of integrating with new trading partners and 
>responding to changes in existing interfaces. In a standards context it 
>will allow the development of specifications of choreographies  in 
>sufficient detail to enable interoperable implementations. 
>
>  
>