Re: [soa-blueprints] To Proceed

[Michael Stiefel <development@reliablesoftware.com>]

+1

Michael

At 10:06 AM 1/25/2006, marchadr@wellsfargo.com wrote:
>If that is the case let's start there being careful as to not have a 
>vendor product drive the requirements.
>
>Once we have something working there maybe some ways to abstract out the 
>vendor or list a variety of vendors.
>
>- dan
>
>
>
>
>-----Original Message-----
>From: Michael Stiefel <development@reliablesoftware.com>
>To: Marchant, Dan R. <marchadr@imc.wellsfargo.com>; klaskey@mitre.org 
><klaskey@mitre.org>
>CC: steve.g.jones@capgemini.com <steve.g.jones@capgemini.com>; 
>soa-blueprints@lists.oasis-open.org <soa-blueprints@lists.oasis-open.org>
>Sent: Wed Jan 25 08:39:20 2006
>Subject: RE: [soa-blueprints] To Proceed
>
>But you cannot do that without getting into implementation specifics. The 
>tradeoffs are very often vendor specific. We will have to get into gory 
>detail to do this.
>
>Michael
>
>At 10:31 AM 1/24/2006, marchadr@wellsfargo.com wrote:
>
>
>I guess the point is...
>
>Can you get the group to adopt your house blueprint?
>What would be the motivation for everyone to build a house like yours?
>
>One thing that people may see value in is how you decorated or some of the 
>layout ideas your house has to incorporate into their house, but I doubt 
>anyone would adopt your blueprints room for room... facet by facet.
>
>I still like to use the analogy of the kitchen studies from the 1950s they 
>study a variety of kitchens to see what worked and what didn't.
>The final report was on best practices of designing kitchens for optimal 
>working based on the task of cooking.
>
>Is this making sense?
>
>- Dan
>
>
>-----Original Message-----
>
>
>From: Ken Laskey [mailto:klaskey@mitre.org]
>
>
>Sent: Tuesday, January 24, 2006 7:21 AM
>
>
>To: Marchant, Dan R.
>
>
>Cc: development@reliablesoftware.com; steve.g.jones@capgemini.com; 
>soa-blueprints@lists.oasis-open.org
>
>
>Subject: Re: [soa-blueprints] To Proceed
>
>
>
>Not to beat the housing analogy too much but, yes, there is iteration of a 
>sorts in building a house.  We had an addition put on and the contractors 
>realized there was a vent in a wall they were cutting through and that 
>vent would have to be rerouted.  Did they invent new windows?  No, but 
>they did swap out some "standard" components when the "implementation" 
>indicated a better approach.  Finally, did they update all the 
>blueprints?  Come on, when does the documentation ever catch up?
>
>
>
>As we noticed in SOA-RM, non-IT analogies are very valuable and there are 
>more parallels in life than you sometimes expect.  However, if you try to 
>work out every twist of the example to the work at hand, you will have a 
>frustrating, never-ending iteration.
>
>
>
>Ken
>
>
>
>
>On Jan 24, 2006, at 10:12 AM, <marchadr@wellsfargo.com> wrote:
>
>
>
>
>
>It is very interesting how a lot of software professionals equate building 
>software with building a house or building. Does this mean the practices 
>are the same between construction and software I think not. When have you 
>had a finalized business specification to build from, is it iterative? Can 
>you iterate construction?
>
>
>
>The practices are very different. One thing that does seem to be similar 
>is that both have a bill of materials for planning and best practices of 
>how to build sections of the subject. For instance, a blueprint in 
>construction is most of the time not going to invent a 3 quarter weld 
>approach or to redesign the lintel or basement approaches. It has some set 
>patterns or "reference blueprints" on sections of the blueprint. It puts 
>all the "reference blueprints" for specific problem spaces within it's 
>blueprint to make up the specific blueprint.
>
>
>
>A construction blueprint also does not invent the materials it uses, have 
>you ever seen anyone invent a new window for a building, with a variance 
>on the process. It is not in the best interest of a contractor of a 
>building to invent new materials or approaches, it means he has to find 
>different resources than his normal operations to fulfill these tasks.
>
>
>
>The same approach is something we should develop as the blueprint. Make it 
>more of a reference blueprint that can be applied in a domain as an 
>example of use. Coming up with domain specific blueprints will distract 
>the TC as they will tend to think that all banks fall in the specific 
>banking example. Has anyone ever seen an example of banking within 
>development and software design books? Did it meet what the specific bank 
>was doing? Probably not. Mergers and acquisitions changes domains in a 
>slight way that could be addressed through SOA but most of the time the 
>expense versus the business as usual is a major factor in purifying a 
>technical architecture.
>
>
>
>The way most of the approaches have been to SOA is to componentize your 
>software thereby making it easier to slap a service on it. Well welcome to 
>reality if you where to componentize every system you have before moving 
>to an SOA that could be a huge expense that in most cases becomes busy 
>work if the system is working.
>
>
>
>Those are my 2 cents before a cup of coffee.
>
>
>
>- Dan
>
>
>
>-----Original Message-----
>
>
>From: Michael Stiefel [mailto:development@reliablesoftware.com]
>
>
>Sent: Tuesday, January 24, 2006 6:50 AM
>
>
>To: Jones, Steve G; Marchant, Dan R.;
>
>
>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.
>
>
>
>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: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.
>
>
>
>
>
>---
>
>
>Ken Laskey
>
>
>MITRE Corporation, M/S H305     phone:  703-983-7934
>
>
>7515 Colshire Drive                        fax:        703-983-1379
>
>
>McLean VA 22102-7508