Re: [soa-blueprints] Primer

[<marchadr@wellsfargo.com>]

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.

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.

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.

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.

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