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.
Would you agree with the survey results? do you have your own SOA wins/ horror-stories to share? Be sure to check out the original articles.
Community comments
SOA failure.
by Sara Jay,
"Failure", or just not a silver bullet?
by Jim Leonardo,
Blaming the wrong animal
by Frank Bolander,
Re: Blaming the wrong animal
by Sara Jay,
Business as Usual
by Paul Korney,
SOA failure.
by Sara Jay,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
"Failure", or just not a silver bullet?
by Jim Leonardo,
Your message is awaiting moderation. Thank you for participating in the discussion.
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...
Blaming the wrong animal
by Frank Bolander,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Business as Usual
by Paul Korney,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.
Re: Blaming the wrong animal
by Sara Jay,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.