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.
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?
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
/
----------------------------------------------------------------------------------
