RE: [soa-blueprints] Anti-Blueprints

From
<>
Date
2005-10-25T18:54:36+00:00
ID
Thread
RE: [soa-blueprints] Anti-Blueprints
Steve,

 

Good 
idea. I put up the first drafts of them at: http://blueprints.jot.com/WikiHome/SOA+Anti-Patterns/SOA%20Anti-Patterns

 

Let me 
know if I correctly eloborated and named them for you.

 

Thanks,

 

Dan

  
-----Original Message-----
From: Jones, Steve G 
  [mailto:]
Sent: Tuesday, October 25, 2005 
  11:21 AM
To: 
Subject: 
  [soa-blueprints] Anti-Blueprints

  

  
The SOA Blueprints will lay down a 
  “best practice” set of guidelines and templates for delivering SOA.  This 
  will definitely be a positive thing and help expand and firm up people’s 
  understanding of SOA.  One thing that the group states that it will do is 
  define standards and guidelines, does this mean that allied to our blueprints 
  we must also consider the “anti-blueprints” (analogous to anti-patterns) that 
  must be avoided.  So for instance focusing on process over service (bad), 
  only thinking of web services (bad) etc etc.  Defining the blueprints 
  give guidance towards success criteria, but should we also give guidance on 
  failure criteria for acceptance of a system as being “SOA”.

  
  

  
Not sure whether this should be in 
  the TC as its laying down best practice, and not to increase the already large 
  workload… but it needs to be somewhere.

  
 

  
My top 5 are

  
 

  
1)       
  If you’ve started with an 
  enterprise “best practice” process map you are NEVER going to be SOA and 90% 
  probability your system will be inflexible or fail.

  
2)       
  Web Service point to point is 
  STILL point to point, doing a bad practice in XML doesn’t make it 
  better

  
3)       
  Splitting into two separate tiers 
  of Service and Process with separate rules and governance results in divergent 
  solutions

  
4)       
  Creating “business” services based 
  on the belief that IT understands the business results in services that meet 
  neither IT nor business goals

  
5)       
  Building your own proprietary 
  XML-RPC stack to give yourself “control“

  
 

  
The last could still be SOA from 
  one perspective, but I’ve yet to see it done well when the driver was a belief 
  that its better done in house than using standards.  When we get the 
  official Wiki it could be something to document via that 
  route.

  
 

  
Steve

  
 

  
 

  
___________________________________________________________

  
Steve 
  Jones | Capgemini 
  

  
CTO, 
  Application Development Transformation

  
T +44 870 
  906 7026| 700 7026| www.capgemini.com

  
m: 
   

  
txt: +44 (0) 
  7891157026

  
Join the Collaborative 
  Experience

  
___________________________________________________________

  
 

  
    
    

      This message contains 
        information that may be privileged or confidential and is the property 
        of the Capgemini Group. It is intended only for the person to whom it is 
        addressed. If you are not the intended recipient, you are not authorized 
        to read, print, retain, copy, disseminate, distribute, or use this 
        message or any part thereof. If you receive this message in error, 
        please notify the sender immediately and delete all copies of this 
        message.