Either
way it seems we are getting into the problem that Taylorism
had.
-
Dan
-----Original Message-----
From: Marchant, Dan R.
Sent: Tuesday, January 24, 2006 7:31 AM
To: 'Ken
Laskey'
Cc: ;
;
Subject: RE: [soa-blueprints] To
Proceed
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:]
Sent: Tuesday, January 24, 2006 7:21
AM
To: Marchant, Dan R.
Cc:
; ;
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, <>
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:]
Sent: Tuesday, January 24, 2006 6:50 AM
To: Jones, Steve G; Marchant, Dan R.;
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:]
Sent: 23 January 2006 22:02
To: ;
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,
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
