Survey Says ... SOA Failure?!

As part of my experience, I have seen a couple of huge scale SOA projects fail miserably, not in my company but that of my friends.
The first project started off with a group of enthusiastic developers, starting out on performing requirements gathering with the business, analysts etc. jotting down the functions that different parts of the corporate performs, and started writing fine grained web-services across the corporate, orchestrating the calls using ESB. Over a period of time, for certain composite apps in the enterprise, certain use cases had to orchestrate with 12 or 13 different web-services across the corporate, bringing the application to a halt under high production load. At that time, the business wanted to generify some of the web-services into 1 or 2. But that rework was a big mess, once all of the services had been designed and the business just said "Oh.. F*CK it, rollback the entire system, lets start out fresh and get it complete before next holiday freeze" - In fact some of the web-services I believe from what he said, did not have a business specification to them, they just send back some data from a database to the client, given a key.
The second project, failed due to developers being extremely enthusiastic in technical jargons while failing to capture business use-cases and translating them into technical requirements.

I think a large part of any technology "failing" is that nothing ever lives up to the hype and SOA hasn't turned out to be the magic silver bullet that the hype machine promised. There's still challenges, and at the end of the day, like anything, if you don't understand and buy into the theory and philosophy of the technology/methodolgy/process/whatever you're trying to implement, disaster will loom.



Does it mean SOA is a failure? No. It just means that it doesn't solve every problem in the world and not every organization can or should move everything onto an SOA platform. And above all, make sure your training and education includes the theory and philosophy, not just the nuts and bolts.


Software Development Amidst the Whiz of Silver Bullets...

The problem with any technology "failure", SOA, J2EE, .NET or whatever is that the business processes in most cases are what needs re-engineering, not the technology that supports it.

Most of the problems derive,(at least in SOA), is as others have put it here, from the fact that in the end, the endpoints become too fine grained. Then, to create any useful business composition requires a myriad of dependent services. I'd add that they become too narrow-scoped because legacy lines of business end up dominating the interface contracts and defeat the whole exercise of the re-engineering in the first place.

No architectural abstraction is going to fix that.

I think that SOA's success rate corresponding to the industry average is more an indicator of industry performance than SOA performance particularly; industry performance is unlikely to improve regardless of IT based approaches like SOA. I think this will be a fact of life as long as typical corporate funding and executive compensation models remain in place.

You are spot on. Also since all the fine grained services are hosted on different hardware boxes, programming a composite application that accesses a bunch of services also needs to be prepared for exception handling when services are unavailable. The problem with exception handling when services are unavailable is that, as the services become more and more fine grained, the exception handling becomes extremely tough, since the number of test cases increases significantly when the number of services are huge for any use case. Development agility slows down, mission critical applications fail, business loses hope and finds out that the pre-SOA world was more agile and more robust even if they did not have the latest and the greatest.