See
comments below. Good feedback Ken.
-----Original Message-----
From: Ken Laskey
[mailto:]
Sent: Tuesday, November 22, 2005 12:07
PM
To: Marchant, Dan R.
Cc:
Subject: Re: [soa-blueprints]
Primer
At 09:50 AM 11/22/2005,
wrote:
Ken these are questions that I am
sure with be concretely established by this tc. Here is my take (keep in
mind I am on a blackberry so it might be more terse than normal).
1.
A blueprint in my mind is to establish a structure to an other wise
disorganized approach to developing software. I have typically called
blueprints a reference architecture (not to be confused w/reference model).
2. Think of the scenario of buying building blueprints from a house
designer and than having though blueprints tweaked by a local architect of
the house. Maybe for your requirements you need the kitchen closer to the
family room or a water closet turned into a walk in closet. Whatever the
changes the basic structure is defined for what you need to accomplish
building a house with N number of rooms that each have a
function.
You might find this analogy interesting:
> Go
back to our house analogy. The RM captures concepts related to
> what
makes up a house, e.g. room, window, door. It might include
> the
concepts of food preparation area and personal hygiene area and
> the
relationship that there should be physical separation between
> the
two. Note that this provides a very North American/western
> Europe
reference and not necessarily one that covers a tent. So a
> given RM
already provides a perspective.
>
> Given RM concepts, various RAs
show how these concepts can be
> arranged in a useful pattern. So RA
examples would be (sorry for
> the American terms) a colonial, a
split-level, a rambler, etc. You
> can play with the pattern but one
can say that any given pattern
> serves a particular set of purposes
(e.g. a rambler is on one level
> for those who want/need to avoid
stairs).
>
> An architecture is then a specific plan to build a
house or set of
> houses. There can still be some variations but you
don't do things
> like moving fireplaces or structural walls, else you
have a new
> architecture.
[Marchant, Dan R.] Sounds a lot like the movie "Kitchen Stories"
about the period of time where sweden was conducting studies on the usability
of a kitchen to identify patterns of usage. In some ways the development of a
blueprint is similar in nature to the kitchen studies in the
50s.
Is a rambler a ranch style house? I agree with the
structural statement creating a bit of constraints that take care of the
reduntant nature of developing an SOA. Everyone in the US probably has a water
closet (bathroom) in the master bedroom a pattern that is identified based on
the experience of the architects in finding the needs of the consumer of the
house. Likewise the blueprints can evolve by building on the reference
model.
3. To establish direction or
rudder the ship. You need to establish the pie in the sky and a blueprint
can help get a handle on that pie.
If you have a ship
without a rudder, you are likely beyond being saved by a blueprint :-)
4. There is a type of tracability
that can be accomplished through following a blueprint. Also it may be
important to use a third-party blueprint to establish a motive for changing
the way a business does things, not sure if this applicable for everyone but
there is definely value in having something to refer too.
Good points. Now can someone craft those into a paragraph or
two that any of us can present to a client and they would feel they know
something they didn't know before?
[Marchant, Dan R.] Wiki ?
My take is this on the blueprint
roadmap so to speak.
1. Establish a couple different scenarios where
services would help and how the service would be structured within that
context and including supporting services.
2. Take the scenarios and
generalize them into patterns with some technology choices as and example of
implementing pattern.
3. Establish an overview of how all the
supporting services could be structure to support the various
patterns.
It would essentially turn into a type of framework, a
service could follow and establish the need for supporting services in a
formal way.
Step 2 after you define a blueprint is to lay
out how you would create one. Your roadmap looks like a good initial
approach, both for motivating a blueprint and showing how one blueprint
can/should/might support more than one scenario.
I could see it on the same lines
of developing anything spring or a portal. You have a set of facilities that
are applicable for certain scenarios that than could be implemented of
configured appropriately.
The great unknown being what business logic
is performed but most of it could be generalized into some type of pattern.
For example, transaction based, inquiry based, aggregation, or even
everyone's favorite semantic service.
Thoughts from the
group?
Dan
-----Original Message-----
From: Ken
Laskey <>
To: Marchant, Dan R.
<>
CC:
<>
Sent: Mon Nov 21 22:42:48
2005
Subject: Re: [soa-blueprints] Primer
I have not been
following the email carefully enough, so forgive me if this has already been
established but
1. Exactly what is a blueprint?
2. What purpose
does it serve?
3. Why should I think one will be generally
applicable?
4. Why do I care?
Do we expect that a blueprint will
be a sort of turnkey formula? How do we determine the limits of
applicability for a given blueprint? Are there underlying assumptions
that all blueprints have in common, or is each blueprint fundamentally
different (a very possible construction), or are there fundamental groupings
with multiple non-redundant examples in each group?
I think agreeing
on a clear strawman definition of blueprint is essential. It can be
modified as we learn more but we need a clear starting
point.
Ken
On Nov 21, 2005, at 9:12 PM,
<> <>
wrote:
One question to pose to the group is maybe the case
study actually becomes a type of primer for the blueprints once the
blueprints are
defined.
Thoughts?
Dan
---
Ken
Laskey
MITRE Corporation, M/S H305 phone:
703-983-7934
7515 Colshire
Drive
fax: 703-983-1379
McLean VA
22102-7508
--
---------------------------------------------------------------------------------
/ Ken
Laskey
\
| MITRE Corporation, M/S H305
phone: 703-983-7934 |
| 7515
Colshire
Drive
fax: 703-983-1379 |
\ McLean VA
22102-7508
/
----------------------------------------------------------------------------------
