Re: Template/Guidelines for building the ebXML Delivery Matrix

[Gordon van Huizen <gvanhuiz@progress.com>]

Hi Dick and gang,

Here are my draft delivery matrix items for the service interface (most
definitely NOT a Cadillac). In looking through the overview &
requirements doc it became clear that section 5.2 of that document is
most frighteningly whacked. The deliverables that I indicate are based
on our discussions to date, plus the direction that is expressed TA doc,
which is quite a bit more current (and reasonable!) than the TR&P O&R
doc.

-gvh-

Dick Brooks wrote:
> 
> 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
> 
>   ------------------------------------------------------------------------
>                                      Name: ebXML TR&P DELIVERY MATRIX.doc
>    ebXML TR&P DELIVERY MATRIX.doc    Type: WINWORD File (application/msword)
>                                  Encoding: base64

ebXML Messaging Service Specification v0-2.doc

begin:vcard 
n:Van Huizen;Gordon
tel;work:510-848-1988
x-mozilla-html:TRUE
url:http://www.sonicmq.com
org:Progress Software;XML and Internet Technology
adr:;;14 Oak Park;Bedford;MA;01730;
version:2.1
email;internet:gvh@progress.com
title:Director, Product Management
fn:Gordon Van Huizen
end:vcard