Actually architects do specify the actual building materials and their
strengths when coming up with a blueprint. They have to make sure the
buildings they design can stand up. Engineering companies may check and
validate the architect's choices.
The real point, I think, is those intermediate documents that you refer to
are architectural documents that belong to a reference architecture, not a
blueprint which deals with an implementation. Implementation means getting
vendor specific which I think is something the TC wants to avoid. We might
want to come up with reference architectures, or concrete architectures
which then could be implemented with a specific vendors technology (as with
Generico).
But call it a blueprint, or a reference architecture, we still have to
decide the domain of discourse. In other words, we have to decide what
types of documents we want, and why we want them.
I am not sure how one goes about doing that.
Michael
At 05:20 PM 1/23/2006, Jones, Steve G wrote:
>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:]
> > Sent: 23 January 2006 22:02
> > To: ;
> > 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, 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.
