SOA AntiPatterns for the Data Architect

I'm really tired of hearing these inflated claims that SOA is going to solve world hunger and fix all that ails software processes.  It's great, but like anything else there is no such thing as a free lunch...with each SOA benefit comes a cost somewhere else. 

 
If you aren't familiar with antipatterns they are simple.  A pattern is a solution to a common problem.  An antipattern is the problem(s) with common solutions.  It shows the other side of the economic equation. 
 
Some common SOA worst practices I've lived through.  Note that many of these are interrelated.:
  1. An over-reliance on technology.  SOA seems to like the latest and greatest technology that will solve all existing shortcomings.  Folks, it's just a tool.  You still need good people, architectures, etc.  Instead of focusing on procuring more technology instead focus on where you want the business to be in the future and how best to get there. 
  2. Focusing too much on technical purity and IT elegance.  SOA attempts to be this very elegant "thing".  We must have the perfect enterprise bus, the perfect data model.  No you don't.  Business people rarely care if it is elegant, they want functionality.  Obviously some elegance is needed for ility concerns, but never sacrifice deadlines and performance to achieve this goal, else your project risks cancelation.  Ask yourself, is this elegant architecture benefitting my developers or my business. 
  3. Just because you are using a web service doesn't mean you are using SOA.  Using a web service can lead to any of the existing software development antipatterns (spaghetti code for instance). 
  4. Not getting good requirements.  Just because you are agile or you are introducing SOA solutions does not mean the solution fulfills the business need. 
  5. Creating services based on "perceived" needs.  Just because you need something and that something is part of an SOA architecture doesn't mean it needs to be a service.  What is the actual requirement?  Otherwise you risk making a service that no one will use because it has no need.  This service will still cost the business since it will need to be maintained. 
  6. Too many very similar services.  Two services...one call CheckOrderData another called OrderDataCheck.  What's the difference?  Likely they were written and are supported by different teams.  You still need to have some control and your modules must communicate.  SOA by nature is decentralized.  But there needs to be some governance. 
  7. The opposite of 6 is the super service.  There is one big service that does too much and is not fine grained.  Now how do you modify and version it?  Tight coupling. 
  8. Did you ever hear "but we ARE ALREADY doing SOA."  Says who?  Do you have governance?  Where's your roadmap and change control?  If you can't answer those basic questions then you might have services, but not SOA.  And IT can't determine this on its own. 
  9. Stovepiping.  We've all heard this term and heard of and can recite why stovepiping is bad.  Here's an example that is really poor ServiceA written by ModuleA retrieves lots of data from a database.  ServiceB/ModuleB consumes a subset of that data based on additional restrictors from their module.  Result is lots of data marshalling.  If we shared data closer to the source and broke down the service barrier performance would improve drastically. 

[[Performance Management Home]]

CONTENT
performance data architecture

Archive