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

 

SOA Blueprint Structure Overview - v1.jpg

SOA-Intro-02.png