RE: [soa-blueprints] SOA Adoption Blueprints TC Discussion for today's conference call

[<marchadr@wellsfargo.com>]

This is good input Theo.

 

Let's talk about this in the meeting today.

-----Original Message-----
From: Beack, Theo [mailto:Theo.Beack@softwareagusa.com]
Sent: Monday, January 23, 2006 7:07 AM
To: soa-blueprints@lists.oasis-open.org
Cc: mmatsumura@infravio.com
Subject: [soa-blueprints] SOA Adoption Blueprints TC Discussion for today's conference call

Hi everyone,

I put together some of my thoughts for today’s meeting in the hope that it would help facilitate the discussion. Let's see where the conversation will lead us.

Regards

Theo

 

---

Towards the end of last year Ken Laskey and Marc Davies made to interesting comments, namely:

+1 on Ken’s view here. It strikes me that Blueprints will necessitate levels of definition; else this debate will become circular. Duane recently posted a good image (for SOA-RM intro discussion) around this, which I’ve modified (very!) slightly – see attached – both original and modified. Nutshell – a high level Blueprint (meta?) with the highest level of abstraction could allow us to more comfortably move forward on some (several?) scenario’s. - Marc Davies

Reading this and the emails that followed, I think we need to differentiate whether we are building blueprints that are reusable skeletons or generating random examples. I see a framework into which the steps of buy Product can be assembled as being a framework but this is the intent of BPEL. I see the specifics of buy Product as being an example that will be quite different for every company. While one can argue that the former should find its way to a standard, the latter belongs in a how-to book. - Ken Laskey

I included the diagram (SOA-Into-02.png) Marc referred to in this email.

We started to touch on these topics in the draft SOA Blueprints document. I think it would be worthwhile to explore them in more detail so that we can capture the guidelines of how we are going to move forward in 2006.

The diagram (Marc shared) depicts the context of a Generic set of SOA blueprints and more specialized blueprints in the context of the SOA RM and SOA Implementations. I think this is a very good diagram, but I think we should also explore the idea of a generic set of SOA blueprints. What are they? What types of generic blueprints will we create? I think a structure and goal will help guide us through the first half of this year to get started on producing some very good material.

In order to help facilitate the discussion this morning I added a diagram of my own in which I tried to visualize the context and relationship between the Generic SOA Blueprints, Specialized SOA Blueprints, Reference Implementations, etc. 

• Should we identify different Levels of Blueprints?

o Very detailed

o Abstract

o High-Level

• Blueprints are currently created in different formats or layouts.

• Do we want to add more structure and focus to the blueprints efforts? For example:

o Create a common template/structure for every blueprint/anti-pattern

o Use this as template to document all

o Identify Mandatory sections and optional sections

o Identify levels of blueprints or create a classification system for Blueprints

o Domains could include:

• Architectural blueprints

• Anti-patterns

• Specific use case or problem domain blueprints, for example:

o  Supply chain blueprint

o  Credit Check blueprint

o  Order processing blueprint