The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Mark Little on Nov 20, 2008
There have been quite a few articles recently on the subject of whether or not SOA should be considered a failure. Gartner analysts have entered the debate with a mock letter supposedly written by Project Manager, EA Artchitect or Lead Developer "To the CIO, CEO, CFO, CTO and shareholders", indicating why the writer admits that SOA is certainly a failure:
As a result of the following I can now only deduce that SOA is a failure and any attempts at SOA will result in failure. Under my direction:
Although the list of reasons for the failure are written in a humorous manner, they relate to issues that others have identified as possible reasons for failures where SOA is concerned:
- I have failed to associate our SOA initiatives with our business needs, therefore I cannot show any value for the hundreds of services we have created ,
- I have failed to properly create and support an SOA Center of Excellence, Steering Committee or Competency Center,
- I have failed to enlist the executive staff as true supporters and evangelistscfor our SOA efforts.
- I chose to buy an ESB prior to truly understanding our SOA infrastructure needs (In reality this wasn’t my fault, the vendor said it was super duper necessary)
- I have failed to provide my developers incentives to reuse artifacts,
- It was not my responsibility to follow what was going on next door where there was a separate team dealing with BPM, I mean they are two different initiatives,
- I firmly believe that SOA is nothing more than fancy CORBA or COM.
Of course the point is that some or all of these things should have been considered and implemented in order to achieve success.
Despite all of the things I have NOT done, SOA has failed. My additional failure to recognize and implement best practices that have been proven successful in many other companies worldwide also play into the failure of SOA.
As one commenter points out:
I tell clients that SOA is in a reverse-dating-breakup-blame scenario. When things go wrong SOA can look you in the eye and with sincerety over the failed relationship say, “Really, its not me, its you.” We have enough proof now that SOA is not bad. But there is still a LOT of bad SOA out there. These are indeed, good tips.
Although as another comment points out, SOA is not a global panacea and should not be treated as one:
SOA works in some case but fails in others - and, not only because of the organization, or, people. Face it, in some cases it just doesn’t make sense based on your company’s architecture. Yes, as a concept it is a good thing - and, depending on how your enterprise is organized it may only fit in some pockets but not necessarily all.
The letter ends with a shot at some of the (relatively new) kids on the block:
Thanks for understanding and I’d like to declare in advance that Cloud Computing, Virtualization and SaaS will be failures under my direction as well.
So how long before we get the "Cloud Computing is a failure" or "SaaS doesn't work" letters?
In other news, Gartner analysts reported that "writing software is hard," chiming in that "with the help of our analytical analysis, our analysts will be glad to help your business analyze and undo the cutting edge technology that we lauded and heralded as the second coming just three quarters ago."
Nicholas, thanks for making me laugh! I respectfully request permission to reproduce your response in my email signature at work (with attribution of course).
To be fair, Gartner do produce some good stuff, however they do seem to often ride a knife edge between brilliant insight and absurdity.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
2 comments
Watch Thread Reply