Top 10 Reasons SOA Projects Fail

Last month an interesting study about SOA implementation success rates was released:

The Burton Group SOA Study

It states that fully 50% of the projects assessed were considered a complete failure and 30% more seriously underperformed. That leaves only a 20% success rate - this track record is nothing less than dismal. Why is this still happening? Why is SOA so difficult to realize?

Well, rather than writing a dissertation, let's address the root causes with a top ten list:

1. There is still no widely agreed upon set of best practices for SOA implementation (or for that matter even an industry standard definition for what SOA is and isn't).
   
2. The confusion regarding SOA and web services is still pervasive; technically you can have SOA without any web services being developed per if the architectural principles are met.
   
3. SOA is not application-centric, despite appearances to the contrary. SOA is the first and only comprehensive development paradigm that is wholly integration-centric. (it combines the previous middle-ware integration capabilities with OO and web-centric logic).
   
4. Most SOA architects don't have a clue about 75% of what a true enterprise integration requires. Solution integrators tend to hire former J2EE / web services developers and assume that they will magically grasp the intricacies of System of Systems enterprises magically from the giant wisdom cloud in the middle of so many diagrams. NOT...
5. SOA without the enterprise data layer isn't going anywhere, fast.
6. COTs driven SOA is inherently risky, as the recent merger between two of the four leading vendors has proven (Oracle buying BEA). How many people are now having to reassess their infrastructure as a result?
7. Deploying a SOA stack in itself that doesn't actually do anything is an intellectual exercise to be sure, but also a complete waste of time and money.
8. SOA is dynamic, or at least it's supposed to be and more importantly it is not our first foray into managing dynamic environments, so why does the industry seem to have collective amnesia in this regard? Systems engineers have been doing what SOA developers are failing to do now for twenty years, yet you'll never see a member of that rare species on most SOA projects.
9. Developers rule - NOT. Design also drives development not the other way around, we wouldn't want the drywall guy designing a skyscraper, yet that happens in SOA implementations (figuratively speaking). Some people call this model-driven SOA, however it was the way SOA was always supposed to be conducted. You can't really do "Agile SOA" in the strictest sense of the Agile philosophy given SOA's integration implications - the big picture has to be understood up front.
10. The standards and hype don't drive the solutions, the business does - if we remember that we can avoid some obvious traps. Hype doesn't solve problems or deliver capability and the standards that are applied are the ones that make sense, not merely the ones everyone says ought to be applied in a perfect world.
    

copyright 2008, Semantech Inc.