RE: [soa-blueprints] To Proceed

[Michael Stiefel <development@reliablesoftware.com>]

I find it hard to see at the level of a blueprint, what agricultural and 
financial business problem statements have in common. You cannot come up 
with a generalized set of semantics.

I agree that there are common problems that need addressing and you list 
some of them. It would be worthwhile to pursue these. But I have trouble 
seeing how this fits into our charter. According to our charter an adoption 
blueprint must supply:
         a business problem statement
         a set of business requirements
         a normative set of functions to be fulfilled, on a vendor- and 
specification-neutral basis.

The only way I know how to proceed under these circumstances it to decide 
who we want to address our end product to and what problems they have we 
want to help them with. The charter's "Anyone involved in the design, 
documentation or implementation of Service Oriented Architectures (SOAs) or 
components thereof." is just to general.

I think your suggestion of common problems has merit and is worth pursuing.

Michael




At 10:17 AM 1/24/2006, marchadr@wellsfargo.com wrote:

>Post and Lintel design patterns...
>
>The value I see is defining common problem spaces and addressing those.
>Domain issues are usually represented within a certain amount of business 
>logic within a service. But what surrounds or is the foundation of the SOA 
>the service resides in?
>
>That seems to be the main point to address.
>
>Things like:
>
>- Governance
>- Service infrastructure
>- Best practices around availability and versioning
>- Etc...
>
>What is the value of an agricultural firm understanding a financial firms 
>business problem?
>
>- Dan
>
>
>-----Original Message-----
>From: Michael Stiefel [mailto:development@reliablesoftware.com]
>Sent: Tuesday, January 24, 2006 7:06 AM
>To: Reza Shafii; Jones, Steve G; Marchant, Dan R.;
>soa-blueprints@lists.oasis-open.org; miko@infravio.com; Beack, Theo
>Subject: RE: [soa-blueprints] To Proceed
>
>
>You raise an interesting an important point about bathrooms and entrances.
>
>Entrances are not always the front. Their are houses that do not have
>bathrooms, they have outhouses. Apartment houses with more than three
>floors have elevators? Perhaps you have never seen some circa 1800s
>townhouses. The point is that these practices that you refer to come from
>building codes and design decisions that reflect social, political,
>technical and economic choices.
>
>These means that we have to focus on choosing a domain of discourse, or
>even focus on what IT Governance means for a specific SOA to get at how
>organizations make these kinds of decisions.  To do this we have to ask
>ourselves why are we interested in doing this. We have to ask those
>questions that you mentioned at the end of your post.
>
>What do we want to give to the wider community that they would be
>interested in, and would be worth the time we spend in doing it?
>
>Michael
>
>At 09:55 PM 1/23/2006, Reza Shafii wrote:
> >Taking the construction analogy a little further... Blueprints do indeed
> >provide a very large level of details that can be used to implement
> >them. There can also be an infinite number of blueprints, as every
> >different design will have a different blueprint. However, it is the
> >similarities between all these blueprints that are most interesting:
> >
> >         - Notation: A standard notation is used to depict artifacts
> >         such as doors, windows, walls, stairs, etc...
> >
> >         - Practices: Blueprints follow best practices. A house must
> >         have at least one bathroom. Entrance door is at the front of
> >         the house. An apartment building with more than three floors
> >         should have an elevator.
> >
> >The more comparable the type of environment in question, the higher is
> >the degree of similarity in the aspects above. For example when we
> >compare the blueprints of two different shopping malls, we are more
> >likely to see similarity in terms of the notational elements involved
> >(shops, food courts, etc...) and the practices (A large parking lot).
> >
> >Going back to the software world now, can we make the same conclusions?
> >
> >It shouldn't be hard to argue that the actual blueprint that describes a
> >specific company's SOA is unique. Every company (and it's IT
> >architecture) is, after all, at least slightly different.
> >
> >Is there a common notation to describe an SOA blueprint? I can see how
> >answers could differ on this question, but to my knowledge, there is
> >currently no clear, standard, SOA description notation out there.
> >
> >Finally, are there practices that are common to similar SOA
> >environments? There is no question that such practices can be defined.
> >Many of them have already been described in the SOA literature out
> >there. Also, as is the case in construction blueprints, the types of
> >practices used are more likely to be the same as the environments in
> >questions are more alike. It is perhaps a little more difficult to
> >classify the SOA environments in a way that increases the similarities
> >in practices used: Would you go by industry, by company size, by the
> >complexity of the IT infrastructure required?
> >
> >Should the work of this TC be at least partly concerned with the
> >questions above? Should we work towards creating a common notation for
> >the creation of SOA blueprints? Should we create a classification
> >(taxonomy) for different types of SOA environments and define their
> >associated best practices? IMHO, answering these questions is more
> >valuable to the industry than the creation of actual (example)
> >blueprints themselves. Our work would then facilitate the creation of
> >unique blueprints for each company's individual set of circumstances.
> >
> >Regards,
> >
> >Reza
> >
> >
> >
> >
> >
> >-----Original Message-----
> >From: Jones, Steve G [mailto:steve.g.jones@capgemini.com]
> >Sent: Monday, January 23, 2006 5:20 PM
> >To: Michael Stiefel; marchadr@wellsfargo.com;
> >soa-blueprints@lists.oasis-open.org
> >Subject: RE: [soa-blueprints] To Proceed
> >
> >
> >
> >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.