Survey Says ... SOA Failure?!
Assaf Arkin questions a recent report indicating SOA failures, rather the success of web oriented architectures (WOA). He points to the survey results in an Information Week article, which suggests that
IT pros have expressed skepticism about SOA’s promised return on investment. A 2007 InformationWeek Web survey of 278 IT pros found that 32% of those using SOA said those projects fell short of expectations. Of those, 58% said their SOA projects introduced more complexity into their IT environments, and 30% said they cost more than expected. Out of all respondents using SOAs, just 10% said the results exceeded expectations [which is confirmed by a survey by] Nucleus Research, which found that only 37% of 106 organizations it surveyed actually were realizing ROI from their investments in SOA technology and programming.
He compares this to industry averages in the software development and opines that "Considering industry standard, that doesn’t look all that doomy or gloomy. It looks … just average". He asserts that
What will change is not the rate of success. What will change is the ability of the successful to do more interesting things, and do them better.
That’s where the change is. The possibilities you can realize.
What didn’t change is the industry average. And the average article using statistics out of context to make a point that sounds good but doesn’t say anything. There are other things horribly wrong with this article, but this one point stood out because, as fallacies go, it tends to propagate wide and far.
Joe McKendrick of ZDNet examines the meaning of SOA failure in his article where he says that "Frankly, I haven’t heard about any big failures… yet. But for most companies, it’s still too soon in the evolution to SOA to make the call". However he identifies a couple of tell-tale signs that an SOA effort is in trouble
- Lack of a true SOA. An organization may only think it has SOA. Having a primordial soup of services across the organization and hoping an SOA may evolve from it at some point.
- Lack of reuse or sharing by multiple business units. Such services may languish until a more effective governance strategy can bring them into the light of day. Or, sharing may actually be happening, but the business is not tracking these metrics.
- More money spent than gained — over the long run.
- More, not less, vendor lock-in. The purpose of SOA is independence from vendors, so components or services can be swapped out as needed.
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.
"Failure", or just not a silver bullet?
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...
Blaming the wrong animal
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.
Business as Usual
Re: Blaming the wrong animal