RE: [soa-blueprints] To Proceed - Best Practices

First tell me what the Generico or SOALogic 
blueprint provides as general value to the community and how you intend "the 
rest of the framework" to add to that value.

 

Generico is a very detailed an comprehensive blueprint. 
SOALogic contains less detail, but nonetheless contains a lot of useful 
information (I presume this is still a work in progress and we will build this 
blueprint out some more). 

 

These two blueprints use different document templates and 
the basic structure and content differ quite a bit. The Generico blueprint 
doesn't address the business case, but it delves into 3 different use cases in 
considerable detail. I won't highlight the basic structure followed in Generico 
since everyone can review that at their own leisure.

 

SOALogic starts with the scope of the document with 
some basic "procedural information" (maybe not the most appropriate term) - 
document scope, target audience, etc. Then it delves into the business 
aspects of the use case, namely Company Goals, Background, Business Domain 
Model, Service Model, etc. Next it covers the Service Model and Service 
Architecture. SOALogic doesn't include any of the details documented in 
Generico, for example Generico documented the Service data structures, 
methods/contracts, use case description, patterns covered, etc. In Generico 
the authors even went a step further by adding some 
extensive visualizations.

 

When I compare the two I find Generico to be the most 
useful one, due to the detailed (and explicit) nature of the content. Ideally 
SOALogic (or any blueprints) that follow should contain similar levels of 
detail. Furthermore Generico could potentially benefit from the inclusion of 
business related information as a precursor to the detailed documentation that 
follows.

 

We are working on SOA Adoption Blueprints with the hope 
that the SOA community will adopt and use the blueprints. Shouldn't we at the 
very least produce adoption blueprints using a standard 
template? When creating a blueprint that is focused on healthcare and 
another that is aimed at financial services, shouldn't they at the very 
least have a consistent layout and structure to make them more readable? 
Shouldn't the content in these blueprints be similar in nature, in order to 
assist the reader in interpreting that content?

 

Theo

 

From: Ken Laskey [mailto:] 

Sent: Tuesday, January 24, 2006 16:20
To: Beack, Theo; Reza 
Shafii; John Harby; ; ; 
; ; Jones, Steve G
Subject: 
RE: [soa-blueprints] To Proceed - Best Practices

First tell me what the Generico or SOALogic blueprint provides as 
general value to the community and how you intend "the rest of the framework" to 
add to that value.  Does anyone care now and will anyone care when you're 
done?

Ken

At 03:53 PM 1/24/2006, Beack, Theo wrote:

I wouldn't say that this will be our first deliverable, but I certainly 
  be would in favor of creating more structure around the adoption blueprints. 
  One option which I think might work well is to use the Genrico or SOALogic 
  blueprint and from that start to create the rest of the framework, which we 
  can use for subsequent blueprints.
 
Theo

  
  From: Reza Shafii [ mailto:] 
  
Sent: Tuesday, January 24, 2006 15:23
To: Beack, Theo; 
  John Harby; ; ; 
  ; ; Jones, Steve G
Subject: 
  RE: [soa-blueprints] To Proceed - Best Practices

Theo,
 
Should our first deliverable then be a 
  “Blueprint Adoption Standard Guideline”? Containing templates, notation, 
  classification, etc…? I can see a significant amount of effort required for 
  this work 
  alone.
 
Cheers,
 
Reza
 
 
 

  

  

From: Beack, 
  Theo [ 
  mailto:] 
Sent: Tuesday, January 24, 
  2006 3:03 PM
To: Reza Shafii; John Harby; 
  ; ; ; 
  ; Jones, Steve G
Subject: RE: 
  [soa-blueprints] To Proceed - Best Practices
 
Reza, 
 
I think during yesterday's call and the resulting 
  conversations on the list we are exploring several different topics, which I 
  think is related to your comments below. I agree that we should have some 
  standard guidelines (+ templates, classification system, etc.) which we use 
  for the creation of the adoption blueprints. 
 
However, I do not think we need a repository of SOA best 
  practices in order to create blueprints. In fact I think that the reverse 
  might be true. Best practices might start to surface out of the details of the 
  Adoption blueprints (and resulting real-world implementations). 
  
 
It is my experience that many best practices 
  would be implementation specific, with resulting code, models, technology 
  related implementation information, etc. As an example you could have a best 
  practice of how to secure Web Services within an app server such as WebLogic. 
  Such a best practice would be very specific to a certain vendor product and 
  implementation, which wouldn't fit into the charter of the TC. At the same 
  time it might be difficult to replicate or reuse the same best practice within 
  another implementation where a different app server is being 
  used.
 
I can also describe various other examples 
  of quite generic best practices that are removed from physical implementation, 
  but before exploring these in more detail we should consider the question; 
  what is a best practice? Before we can decide whether to include best 
  practices into the TC's work we need to define best practice, the role it will 
  play, relationship with adoption blueprints, how it will be used and of what 
  value it is to the larger SOA community.
 
Theo
 

  

  

From: Reza 
  Shafii [ 
  mailto:] 
Sent: Tuesday, January 24, 2006 
  13:47
To: John Harby; ; Beack, 
  Theo; ; ; ; Jones, 
  Steve G
Subject: RE: [soa-blueprints] To Proceed - Best 
  Practices
Shouldn’t a blueprint creation 
  guideline that gives us a common methodology/notation, classification, and a 
  repository of best practices (some of which could be just pointers to existing 
  best practices) precede the creation of individual 
  blueprints?
 
Reza
 

  

  

From: John 
  Harby [ 
  mailto:] 
Sent: Tuesday, January 24, 2006 1:06 
  PM
To: 
Subject: Re: 
  [soa-blueprints] To Proceed - Best Practices
 
I would be in favor of a repository of 
  best practices that are not necessarily tied to a single blueprint but can 
  certainly reference one or more blueprints.
On 1/24/06, Beack, Theo 
  < 
  > wrote:
If we decide to include best practices under the general 
  Adoption Blueprint "umbrella", it would be helpful to understand the 
  relationship between the blueprint and associated best practices. Immediate 
  questions I have is whether we will create "one off" best practices related to 
  a specific blueprint or whether we would try to make them generic enough to be 
  used within other blueprints. If that is the case, do the best practices 
  deserve to stand on their own and should we create a classes of best practices 
  that can be reused within Adoption Blueprints (or even 
  separately).
 
Theo
 

  

  

From: John 
  Harby [ 
  mailto:] 
Sent: Tuesday, January 24, 2006 
  12:38
To: 
Subject: 
  Re: [soa-blueprints] To Proceed - Best Practices
Possibly although I think there are loopholes 
  within the charter that would allow us to specify best practices. Firstly, the 
  Generico blueprint has some treatment of best practices therefore inclusion 
  and advancement of those is included by this statement: 
  
    
Circulate, improve, maintain and standardize the existing "Generico" 
    blueprint to be contributed, in the form of a basic Adoption Blueprint. 
  
 
On 1/24/06, Beack, Theo < 
  > wrote: 
Don,

I'm not convinced that we agreed on 
  the role or place for best practices
as part of the Blueprints TC. I 
  reviewed the charter of this TC
( http://www.oasis-open.org/committees/soa-blueprints/charter.php) 
  and it
made no mention of best practices. Not that I think it is a bad 
  idea.
The notion of creating best practices could be of 
  value.

However, we need to determine whether this TC will focus it's 
  efforts on 
only creating SOA blueprints (+ anti-patterns) or whether best 
  practices
will be included in these efforts.

I think one of the 
  dangers of trying to focus our efforts on best
practices, is that we might 
  enlarge the scope to the extent that it will 
be difficult to focus and get 
  some real blueprint work done. It is
definitely a topic worth 
  discussing.

Regards
Theo

-----Original 
  Message-----
From: Don Flinn [mailto: ]
Sent: Monday, January 23, 
  2006 13:57
To: 
Cc:  
  
Subject: Re: [soa-blueprints] To Proceed

Agreed.

In 
  addition, I believe that one of the goals that was agreed upon 
  is
developing best practices, BP.  These could be partitioned into 
  the
following categories: 
- General BP, which would be applicable to 
  all domains
- Domain Specific BP, where the domains might 
  be:
   - Financial
   - 
  Manufacturing
   - Retail
   - Professional 
  services
   - Business services (not SOA services) 
  
   - Media & Marketing
   - 
  Education
   - Government

Each of these could be further 
  subdivided, but too fine a subdivision,
IMHO, is not in the spirit of a 
  specification.  If we could come up with 
best practices at this level 
  we would deliver information that would be
useful to a broad category of 
  people.  We could point out significant
exceptions or additions for 
  subcategories of the chosen domains.
Although the primary effort would be 
  to generalize the BP as much as 
feasible while still making them 
  useful.

Don

On Mon, 2006-01-23 at 11:49 -0600,  
  wrote:
> To All,
>
> Here is what I gather from the group as 
  a whole: 
>
> 1. Need a context on what we are 
  doing.
>     - 2 cents:  A problem statement 
  would be a great start with
audience, etc...
>
> 2. Need to 
  defining use cases to provide context on the blueprints 
  
defined
>      - 2 cents: establish a use 
  case document that can be expand on
> this and may have domain related 
  spin offs
>
> 3. Need to establish what a blueprint 
  is.
>
> I think everyone should start adding to this list and 
  adding opinions, 
etc...
>
> This may help to create a bit of 
  focus or strategy.
>
> Thanks,
>
> 
  Dan
>
--
Don Flinn
President, Flint Security LLC
Tel: 
  781-856-7230
Fax: 781-631-7693 
e-mail: 
http://flintsecurity.com
 
 

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