RE: [soa-blueprints] To Proceed

["Jones, Steve G" <steve.g.jones@capgemini.com>]

When an architect sketches out the original design for the building it
outlines the principles and practice and puts in place the areas where more
refinement is required.  These areas are further refined by the architects
team they become an outline blueprint that defines the major elements, this
is then passed to an engineering company who determine the actual materials
and strengths, and its probably these folks who produce the final
construction blueprints and these can be modified.

At each level the blueprint has become more and more detailed from the
initial sketches on the architects desk.  For me its this process that is
mirrored in SOA blueprints, if your project is only 20 people or so they
might be one document put out at the start, if however you are trying to
move an entire organisation towards SOA its more like building a small town
so there are lots of levels of blueprints.  Even in one building there are
blueprints for the building and then blueprints for each floor, each at
different levels of abstraction.

I might have taken this metaphor as far as I can go, but the point is that
when you are planning any major construction project whether in software,
buildings or planes you have various levels of abstractions to communicate
different levels of concepts and break down the problem for different
audiences.

Steve


> -----Original Message-----
> From: Michael Stiefel [mailto:development@reliablesoftware.com]
> Sent: 23 January 2006 22:02
> To: marchadr@wellsfargo.com; soa-blueprints@lists.oasis-open.org
> Subject: Re: [soa-blueprints] To Proceed
>
> A blueprint is detailed instructions on how to implement a particular
> design. Construction blueprints are modified as the building is
> constructed
> to reflect the actual decisions the contractor made in the field.
>
> In building construction, of course, one can have a plan that is distinct
> from the artifact itself. In the software world, detailed instructions on
> implementation is very often identical to writing code.
>
> I suppose one could describe a particular SOA in terms of service inputs
> and outputs and orchestrations, etc. without reference to a vendor
> implementation. This is some soft of architectural document, not a
> blueprint.
>
> I understand what a reference architecture is. I understand what a
> concrete
> architecture is. I have no idea what an abstract blueprint is.
>
> Michael
>
> At 12:49 PM 1/23/2006, marchadr@wellsfargo.com wrote:
> >To All,
> >
> >Here is what I gather from the group as a whole:
> >
> >1. Need a context on what we are doing.
> >     - 2 cents:  A problem statement would be a great start with
> audience,
> > etc...
> >
> >2. Need to defining use cases to provide context on the blueprints
> defined
> >      - 2 cents: establish a use case document that can be expand on this
> > and may have domain related spin offs
> >
> >3. Need to establish what a blueprint is.
> >
> >I think everyone should start adding to this list and adding opinions,
> etc...
> >
> >This may help to create a bit of focus or strategy.
> >
> >Thanks,
> >
> >Dan
>
>


This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient,  you are not authorized to read, print, retain, copy, disseminate,  distribute, or use this message or any part thereof. If you receive this  message in error, please notify the sender immediately and delete all  copies of this message.