RE: [soa-blueprints] Primer

[<marchadr@wellsfargo.com>]

The latter has the best benefit.


-----Original Message-----
From: Miko Matsumura [mailto:mmatsumura@infravio.com]
Sent: Tuesday, November 22, 2005 12:20 PM
To: Ken Laskey
Cc: soa-blueprints@lists.oasis-open.org
Subject: RE: [soa-blueprints] Primer


Very good point.

I do think that there will be some blueprints with more "horizontality",
depending on the set of business requirements and their
generalizability. So practically speaking, I think the answer is "it
depends".

The key dependency is on the generalizability of the root business case.
For example, if you were trying to solve a business case such as the one
raised by David on the con call--one of "how best to address the issue
of auditability in the context of SOA", this might be more of a factored
set of scenarios. 

Best,
Miko

-----Original Message-----
From: Ken Laskey [mailto:klaskey@mitre.org] 
Sent: Tuesday, November 22, 2005 12:17 PM
To: Miko Matsumura; marchadr@wellsfargo.com
Cc: soa-blueprints@lists.oasis-open.org
Subject: RE: [soa-blueprints] Primer

Reading the charter chunk and Dan's Blackberry scribbles (well done,
BTW), my first question is how specific a blueprint is supposed to be.
Is a blueprint an example solution off a specific scenario or is it a
factored solution to a set of scenarios?  The former gives a set of
examples that is foremost in the minds of the TC but may be limited in
scope to immediate interests of TC members.  The latter requires more
analysis but can show interesting patterns where a priori it was not
obvious that similarities exist.  Indeed, it can demonstrate an extent
to which such patterns (hopefully) do exist.

None of this really goes out of the scope of the charter but decisions
on what is a blueprint and a clear presentation of our decisions will
affect the clarity and usefulness of our final product.

Ken

At 01:51 PM 11/22/2005, Miko Matsumura wrote:
>Yes and there is the charter to consider:
>
>This essentially defines a blueprint as a business problem statement, 
>set of requirements and a set of functions. Perhaps not a terribly well

>specified definition, but a reasonable start point for my purposes...
>
>Text from the charter follows...
>-------------
>
>Statement of purpose
>
>Problem to be solved: In planning and building Service Oriented 
>Architectures (SOA), concrete examples often are useful. SOA designers,

>vendors and users can reference a wealth of abstract guidelines, 
>descriptions of functional layers and sets of specific standards or 
>software that fulfill SOA requirements.
>
>However, often there is a shortage of clear, demonstrable examples of 
>working implementations based on real needs and requirements that can 
>be used as best practices reference, to kickstart implementation 
>projects and to compare implementations. One way to encourage these 
>examples is to supply an archetypal "blueprint" set of business 
>requirements and functions that can be fulfilled by SOA methods.
>
>Purpose: The SOA Adoption Blueprints TC will develop, circulate, 
>maintain and update a set of example business profiles or "adoption 
>blueprints" to illustrate the practical deployment of services using 
>SOA methods. Each adoption blueprint will provide a (a) business 
>problem statement, (b) a set of business requirements, and (c) a 
>normative set of functions to be fulfilled, all on a vendor- and 
>specification-neutral basis. The TC anticipates starting with the
original "blueprint"
>scenario created by the project's host, The Middleware Company and its 
>expert group, to be contributed to OASIS. This scenario, the "Generico"
>core application set, will serve as a basic Adoption Blueprint. It is 
>expected that additional blueprints will be developed to address other 
>business requirement sets. Additional Adoption Blueprints may 
>interoperate with the basic Generico blueprint, or may describe a new 
>separate scenario.
>
>-----Original Message-----
>From: marchadr@wellsfargo.com [mailto:marchadr@wellsfargo.com]
>Sent: Tuesday, November 22, 2005 6:50 AM
>To: klaskey@mitre.org
>Cc: soa-blueprints@lists.oasis-open.org
>Subject: Re: [soa-blueprints] Primer
>
>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

--
 
------------------------------------------------------------------------
---------
   /   Ken 
Laskey                                                                \
  |    MITRE Corporation, M/S H305    phone:  703-983-7934   |
  |    7515 Colshire Drive                    fax:      703-983-1379   |
   \   McLean VA 22102-7508
/
 
------------------------------------------------------------------------
----------