RE: Template/Guidelines for building the ebXML Delivery Matrix

[Dick Brooks <dick@8760.com>]

Marty,

The delivery matrix is intended to define what will be delivered within each
phase, with regard to the Messaging Service. If TP/Discovery is separate
then I agree, it should be removed from the delivery matrix. If there are
any TP/Discovery requirements that you believe are needed in phase 1 of the
messaging service then please provide these in the matrix.

One example that comes to mind, the requirement to include trading partner
agreement information in the ebXML header. This may be in phase 2 or
wherever you feel is most appropriate.


Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
> Sent: Friday, September 08, 2000 2:31 PM
> To: Dick Brooks
> Cc: Ebxml; Rik Drummond; Chris Ferris; Dick Brooks
> Subject: Re: Template/Guidelines for building the ebXML Delivery Matrix
>
>
>
> Dick,
>
> Now that I have your posting about the requirements matrix, I understand
> something I missed yesterday.
>
> You are including a requirements chart for Trading Partner/Discovery.
> However Trading Partner is a separate team and so I don't think it belongs
> in your matrix.  There is at least an implicit requirement on the TRP team
> to feed requirements into the TP team, but I am not sure that is the kind
> of requirement you are documenting.
>
> If the Overview and Requirements document is ever updated, it ought to
> describe the connections to the TP team under "Relationships with Other
> ebXML Activities".
>
> If I have missed a point somewhere along the line, please let me know.
>
> Regards,
> Marty
>
> ******************************************************************
> *******************
>
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287;  IBM tie line 863-7287
> Notes address:  Martin W Sachs/Watson/IBM
> Internet address:  mwsachs @ us.ibm.com
> ******************************************************************
> *******************
>
>
>
> Dick Brooks <dick@8760.com> on 09/08/2000 01:18:41 PM
>
> Please respond to dick@8760.com
>
> To:   Ebxml <ebxml-transport@lists.ebxml.org>
> cc:   Rik Drummond <drummond@onramp.net>, Chris Ferris
>       <chris.ferris@east.sun.com>, Dick Brooks <dick@8760.com>
> Subject:  Template/Guidelines for building the ebXML Delivery Matrix
>
>
>
> Sorry I couldn't get this out yesterday, my real job interfered with my
> plans.
>
> This message is in response to yesterdays conference call where I
> agreed to
> coordinate development of a delivery matrix.
> This message contains the following sections:
>
> - Purpose/Goals, describes why we are creating the delivery matrix
> - Guidelines, provides some procedural/process advice to those responsible
> for creating the delivery matrix
> - Template, format of the delivery matrix document (MS Word attachment)
>
> PURPOSE/GOALS
>
> Throughout the design of ebXML's Messaging Service, debates have arisen
> over
> WHAT we are building (i.e. SCOPE of ebXML MS). The ebXML TR&P requirements
> document is very broad and the problem space we're addressing has some
> complex problems. It's important, for the success of ebXML, to provide a
> Messaging Service solution that is useful for a majority of the
> current and
> anticipated B2B business needs, "out of the gate", while also serving as a
> foundation for future expansion to address the more complex B2B scenarios.
>
> A delivery matrix clearly identifies the functional requirements
> (scope) of
> WHAT is being built. The matrix consists of three phases:
>
> Phase 1 - Identifies functional requirements of a Messaging Service that
> meets the needs of a significant number of B2B scenarios
>
> Phase 2 - Identifies functional requirements of a Messaging Service that
> meets the needs of more complex B2B scenarios and may include
> optimizations
> or improvements to the Phase 1 deliverable
>
> Phase 3 - Identifies functional requirements of a Messaging Service that
> meets the needs of the most complicated B2B scenarios and may include
> optimizations or improvements to the phase 2 deliverable
>
> Each phase will have a set of use cases to define the SCOPE of the problem
> space being addressed. The delivery matrix serves as a guide for
> all design
> and development efforts. Design/development teams should use the matrix to
> decide if discussions, requirements, features are in or out of scope for
> any
> particular phase.
>
> I'm hoping to have a first draft of the delivery matrix available for
> review
> by Monday evening, 9/11. I'm a firm believer that the parameters
> define the
> deliverable. That means I don't expect everyone to have a Cadillac on
> Monday. This is a starting point and we can expand as far as we want after
> Monday, this first draft is intended to stimulate discussion and focus
> everyone's attention on defining (and agreeing on) the scope of
> each phase.
>
> The following people volunteered to assist in creating the
> delivery matrix:
>
> - Jim Hughes, Reliability
> - Marty Sacks, Trading Partner/Discovery
> - David Burdett, Error handling
> - Chris Ferris, Core functionality
> - Gordon van Huizen, Service Interface
> - Dick Brooks, Transport/packaging
> - Dick Brooks, Miscellaneous
> - Dick Brooks, use cases for each phase
>
> I'm asking each of the people above to provide me with their delivery
> matrix
> by Monday, 9/11, at 5:00 Eastern time so that I can consolidate the
> information and deliver a complete document to the group for review on
> Monday evening.
>
>
> GUIDELINES
>
> I suggest that each individual use the current Requirements and Overview
> Spec to identify the requirements to be placed in the delivery
> matrix. If a
> requirement belongs in all 3 phases place it in each phase and provide
> comments describing the "scope" of each. Please include a reference to the
> R&O spec (page no.) when placing a requirement in the delivery matrix. Any
> time you feel it necessary to qualify a requirement in the delivery matrix
> please do so under the column titled COMMENTS, for example:
>
> A requirement of "must be reliable" under phase 1 should specify WHAT is
> meant by reliable. In other words, bound the scope of each requirement
> relative to the phase it appears in. The reliability requirements of phase
> 1
> are very different from those of phase 3. Use the comments column to
> describe the "scope".
>
> If you place a requirement in the delivery matrix that is not contained in
> the R&O spec please provide a reference to indicate where it came from
> along
> with some qualifying remarks in the comments column.
>
> DON'T try to build a Cadillac, we only have until Monday at 5:00
> to produce
> the first draft, nobody is expecting perfection.
> This is a starting point, it will evolve.
>
> When complete the delivery matrix will serve as a tool to help the team
> focus discussions AND serve as an arbitrator for resolving conflicts
> related
> to scope.
>
> I'm also including my cell phone (205-281-7647) if anyone needs to contact
> me over the weekend.
>
> Thanks to all who offered their valuable time to assist in this effort.
>
> Dick Brooks
> Group 8760
> 110 12th Street North
> Birmingham, AL 35203
> dick@8760.com
> 205-250-8053
> Fax: 205-250-8057
> http://www.8760.com/
>
> InsideAgent - Empowering e-commerce solutions
>
>
>
>