[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-blueprints] To Proceed
+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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]