Monday, July 7, 2008

Top 10 SOA Pitfalls revisited

There is a very interesting article the one at Xebia here, also pointed by TheServerSide here. The guys at Xebia have been collecting a series of common grounds for trouble while implementing a SOA programme in an organization.

They list the following as the "common pitfalls":

#10 - Not Invented Here Syndrome
#9 - Versioning
#8 - Security
#7 - Incorrect Granularity of Services
#6 - SOA does not solve complexity automatically
#5 - Big Design Upfront
#4 - Incorrectly applied Canonical Data Model
#3 - Missing skills
#2 - Unclear ownership/Project based funding
#1 - Ignoring culture when introducing SOA

...go read their article for a better insight at each.

The curious thing is that I've been lecturing a series of SOA courses over the last couple of weeks, and it is amazing how most of the problems listed above are present in the recurring questions the students ask. I believe the most interesting conclusion to be reached from analyzing the list above is how unevenly split between technical and non-technical themes it is.

In fact, from the list above,

  • Not Invented Here Syndrome
  • Security (crosscuts technology)
  • SOA does not solve complexity automatically
  • Big Design Upfront
  • Missing skills
  • Unclear ownership/Project based funding
  • Ignoring culture when introducing SOA

...7 out of 10 of the pitfalls Xebia lists are mainly related to culture and human-related problems (mostly communication, skills and awareness), and not technology-related problems.

What strikes me as odd is that SOA is being "sold" extremely agressively in the marketplace mostly by technology providers and system integrators - eager to deliver organizational change through new technology. This is plain wrong, a technolust dream, and leads mostly to frustrating project failures.

In real life, you won't get to magically change an organization to be "more into SOA" by magically stuffing new products into it - new ESB's, Registries or BPM suites won't change the fact that the people will have to want them in - and need them - there in the first place. And for that to happen, we'll have to show them why SOA is relevant for them - but, more importantly, check if they really really need it.

Cheers,

Hugo

1 comment:

Joshua Smith said...

Hey! thank you for useful review. It was simple to read, but I'd like to add that if your business needs to be updated try outsource software development.