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