Only 1 in 5 SOA Projects Actually Succeed
Despite its growing popularity and constant improvements in SOA technology, according to SOA survey done by Barton’s group Anne Thomas Manes,
...in-depth studies of 20 companies found a 50% complete failure rate, while another 30% were considered neither successful nor wholly failed... Many of them had deployed multiple successful projects, but most of those projects were focused on just one integration problem. It was just a bunch of Web services... The service is only built for one application and it’s never going to be used again
The results of the survey were echoed by several news posts, for example, Joe McKendrick and Michael Meehan both are agreeing with Anne point of view that the reason of these failures were for the main part not a bad technical execution, but rather a lack of business/architectural SOA vision, more specifically
- Lack of defined service models
- Infrastructure focus
- Governance only of SOAP-based systems, if that
- Failure of developers to leverage the runtime governance in place
- Initiatives led by and solely involving the app dev group
- Roadmaps lacking specificity
- Inability to measure ROI
- Project-centric culture
- An "I'm special" attitude
According to Chris Haddad, Vice president of application platform strategies and data management strategies at Barton group:
Failed SOA projects get too focused on the means rather than the end. The failure to focus on business goals is a problem and focusing on them is the solution There is sometimes a failure to ask the most basic questions in building the business case for SOA, Why should we be building services? What does it mean at the end of the day?... While one of the business drivers for SOA is reducing costs and achieving return on investment (ROI), ROI for SOA remains an elusive goal and SOA project leaders frequently take a leap of faith where ROI is concerned
Here are the common denominators Burton Group found within the successful efforts:
- Business and IT reorganization, usually with a new CIO coming on board
- Sponsorship at the C-level or by the Board of Directors
- Agile/iterative development methodologies put into place
- Projects tied to and measured by business goals, not IT drivers
- Well-defined funding and maintenance models that balance the needs of service providers and consumers
- A simplified architecture, making it easier to access and manage quality data
- A culture of trust between business and IT
According to Burton’s report:
The problem is not technology. People and processes are at the heart of what’s wrong with SOA as it currently exists in enterprises
This conclusion is supported by the post by David Linthicum:
Issues with SOA continue to be that SOA is a core and systemic change to the way we do IT. Change is something everyone seems to embrace conceptually, but when it comes down to actually changing systems that are a part of someone’s job security, that’s when things get ugly, fast. Moreover, those who are tasked with driving SOA within their enterprise are not given the money and/or the power to drive change. Instead they are asked to "convince" and "influence". That never works; you have to control their budgets and be able to fire them in order to drive change at the speed it needs to be driven
Furthermore, in his post David is proposing a simple recipe for improving SOA quality:
- Define the business cases clearly. If you can’t, don’t do SOA
- Empower those who need to drive the systemic change that SOA requires, typically, with the money and the authority to do something. Else, don’t bother. You need to control the money and be able to fire people if this is to work in a reasonable amount of time. Otherwise, you’re in endless meetings with people who have agendas that don’t include rebuilding the architecture for agility and reuse.
- Think long term and strategic, not short term and tactical. It’s okay; things won’t collapse as you move from a reactive to a proactive mode. Indeed, that’s how companies win their markets.
- Start small, but keep the momentum going. Small battles win the war, and little by little the architecture will get better if you just keep moving the ball forward
This proves once again that the key ingredients for SOA success are:
- An architectural based approach
- An appropriate methodology
- Supporting organizational structure
- Understanding of the business and information and a strategic vision
SOA is not just webservices
Arum Systems uses a service oriented approach for it's DataEye product, but there isn't a web service in sight (though there could easily be if it was needed).
DataEye is based on Solstice, which is an open source platform that combines Flex and OSGi. OSGi is explicitly service oriented. However, we didn't choose OSGi because of SOA, but because it encourages good practices (such as low coupling) and makes it easy to extend, customise and maintain the product.
So once the world gets over their fixation with associating web services with SOA, and realises there are other technologies out there that promote the design principals at the heart of SOA, people will realise there are quite a few successful SOA projects and that it is a paradigm which is sound for project and application development. (Though I think most developers/architects actually know this in their heart of hearts.)
OSGi vs SOA:
SOA turning out to be yet another IT solution!
Re: SOA turning out to be yet another IT solution!
It is always dangerous to focus too much on technology and loose focus on the domain. Todays SOA seems to be a best example of this situation. A lot of vendors offer solutions which attract business people and architects to implement an SOA. But the focus changes from business needs which we are trying to solve to the technology which leads to the recipe for disaster.
I hope the current trend would change to bring back the focus on what we are trying to solve.
Re: SOA turning out to be yet another IT solution!
There's too few people who can deal with taking a concept, and doing the crunching to make it a reality, so those who try often don't have what it takes, and fail.
I'm honestly amazed that its as much as 1/5 (and probably more since those number are skewed). Means there's still SOME hope.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015