RE: [soa-blueprints] To Proceed

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

> -----Original Message-----
> From: Michael Stiefel [mailto:development@reliablesoftware.com]
> Sent: 24 January 2006 14:50
> To: Jones, Steve G; marchadr@wellsfargo.com; soa-blueprints@lists.oasis-
> open.org
> Subject: RE: [soa-blueprints] To Proceed
>
> 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.
[Jones, Steve G]
Architect companies should do but the
http://www.urban75.org/london/millennium.html millennium bridge placed the
blame on the engineers.  I was thinking more about the "name" architects on
the pieces who are often working more on paper than in CAD and pass it on to
the underlings to make it actually happen.

>
> 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.
[Jones, Steve G]

I'm not sure on this as a reference architecture to me (I'm liable to be
wrong though!) defines the general terms and areas and outline that are
applicable in all cases
(http://www-128.ibm.com/developerworks/rational/library/2774.html "A
reference architecture is a resource containing a consistent set of
architectural best practices for use by all the teams") whereas a blueprint
is aimed at the specific challenge being addressed and may use a reference
architecture during the process from idea to implementation.  A blueprint
for a solution needs to start from the point of the idea and evolve towards
the final solution bringing in all of the relevant elements.

So a blueprint has to include (at minimum)

1) Business Goals & Services
2) Governance
3) Conceptual architecture->Physical
4) Operation

Where as a Reference Architecture (IMO) sits in number 3 only and doesn't
have to be domain specific.

There is definitely a grey/gray area around Blueprint v RA in number 3, but
I don't think an RA would look at the other elements.


> 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).
[Jones, Steve G]

I'd definitely disagree that implementation means getting vendor specific
from a blueprint perspective.  If you are working at the Business end of SOA
(rather than the technical end), even things like SAP's blueprinting process
using Solution Maps
(http://www.sap.com/solutions/businessmaps/solutionmaps/index.epx) doesn't
have to be vendor specific (but it does say where SAP can help).  SOA
Adoption Blueprints could definitely be domain specific however (e.g. the
manufacturing services in a 4PL could be different to those in a discreet
manufacturer, even if the external service is the same.).  I've done SOA
blueprints (finished one yesterday) that provide a 3 year business service
architecture as a target for evolution, so the vendor specific element comes
next and will evolve towards the business service architecture.

Part of the challenge here is a similar question that came up in the SOA RM
group about whether SOA is just about technology, the RM is pretty clear
that SOA can be considered as broader than that. 
>
> 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.
[Jones, Steve G]

Definitely, and a big part could be semantics.  First question is whether
there is one domain in the adoption of SOA, layers in one domain or clearly
separated domains (services?!) that have dependencies and impacts.
>
> I am not sure how one goes about doing that.
[Jones, Steve G]

Knife fights are always an interesting and fairly definitive solution...

>
> 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: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.
>
>


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.