Only 1 in 5 SOA Projects Actually Succeed

Posted by Boris Lublinsky on Jul 26, 2008

Community

SOA

Topics

Enterprise Architecture

Tags

SOA Adoption ,

Service Design

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

1. Back to top

   SOA is not just webservices

   Jul 27, 2008 4:31 AM by Christopher Brind

   The figure of 1 in 5 is probably skewed because when people hear SOA they exclusively think web services.

   
   
   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.)

   
   
   Cheers,
   
   Chris

   
   
   Further reading...

   
   
   OSGi vs SOA:
   
   www.osgi.org/blog/2007/09/soa-osgi.html

   
   
   Solstice:
   
   www.arum.co.uk/solstice.php

   
   
   Arum DataEye:
   
   www.arum.co.uk/arumdataeye.php

   Reply

2. Back to top

   SOA turning out to be yet another IT solution!

   Jul 27, 2008 11:23 PM by Hitesh Bagchi

   Every new approach to software development comes with its own aura of being a panacea to all problems that it addresses. Same for SOA! Unfortunately, even after half decade of its formal existence it's still very little understood by the larger IT community. The above post is an eye opener but are we listening?

   Reply

3. Back to top

   Re: SOA turning out to be yet another IT solution!

   Jul 28, 2008 1:15 AM by Sai Venkatakrishnan

   Its sad to see so many trends in IT coming and going trying to make a mark. So many mistakes have been made and so many lessons learned. But still IT projects seems to be a Tar Pit described in the classical book The Mythical Man Month.
   
   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.

   Reply

4. Back to top

   Re: SOA turning out to be yet another IT solution!

   Jul 28, 2008 12:59 PM by Francois Ward

   Simply put, the amount of professional, senior software developers is extremely small in the industry. It is easy to find someone who can do your R&D in Operational Research or fundamental algorythms for you (I use the term "easy" loosely here), but it is incredibly hard to find a senior software solution architect, that can take a new way of building a system, and make something that works out of it.
   
   
   
   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.

   Reply

• Older >