Re: [soa-blueprints] Primer

[Ken Laskey <klaskey@mitre.org>]

At 09:50 AM 11/22/2005, marchadr@wellsfargo.com 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 <klaskey@mitre.org>
> To: Marchant, Dan R. <marchadr@imc.wellsfargo.com>
> CC: soa-blueprints@lists.oasis-open.org
> <soa-blueprints@lists.oasis-open.org>
> 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, <marchadr@wellsfargo.com>
> <marchadr@wellsfargo.com> 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                                              /
    ----------------------------------------------------------------------------------