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

This 
is good input Theo.

 

Let's 
talk about this in the meeting today.

  
-----Original Message-----
From: Beack, Theo 
  [mailto:]
Sent: Monday, January 23, 2006 
  7:07 AM
To: 
Cc: 
  
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