OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-blueprints message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [soa-blueprints] To Proceed


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]