We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion
What Are the Primary Reasons SOA Initiatives Fail?

What Are the Primary Reasons SOA Initiatives Fail?

Vote 0 Votes

Was reading through Beth Gold-Bernstein's excellent feature article, Is SOA Dead? Long
Live SOA!
, and the last thing companies need right now is a failed SOA initiative. So with that in mind, what are the primary reasons for these SOA failures?

10 Replies

| Add a Reply
  • I agree with Dave , Talent shortage is a very important factor why SOA intiatives fail.

  • Failure to measure. Many SOA projects are launched in which managers don't know how well the initiative may have succeeded beyond anecdotal evidence. It may, for all anybody knows, a raging success. Likewise, how do we really know when an SOA effort has truly "failed"? There need to be baseline metrics of various business impacts or performance indicators to measure progress against.

  • Lack of talent is certainly important, but I think unrealistic expectations from management are probably just as important. This is a corollary to having mutually agreed upon metrics for success in place prior to a project even getting started.

  • Okay, I'll play devil's advocate and ask the more important question -- how can you determine if your SOA initiative has failed? Has it failed to deliver enterprise agility? Or, has it failed to drive reuse? Better yet, has it failed to bring about a change in how the business thinks and invests in information technology?

    Not just SOA, but any initiative "fails" if it doesn't deliver agreed upon results. The best way not to fail is to underpromise and overdeliver; even with SOA. I recently penned an article entitled, "A Classification Scheme for Defining SOA," which disassembles SOA into a set of classifications, each with a set of benefits. In that classification scheme, there's a subclass called application SOA, which is what a lot of people are talking about when they say they are doing SOA today. Yet, this is a very practical approach to starting with SOA and locking in the value proposition on a small scale before attempting Enterprise SOA.

    You wouldn't give someone a car and then send them into traffic without first letting them get practice in driving. First in safe areas and then slowly entering in to more higher speed, more heavily traveled areas. The same is true for SOA. You can't read a magazine or book on SOA and dive into a successful SOA initiative. Take it out for a test drive, make sure you know all the boundaries that will impact you, then get bigger and bigger.

  • From working on SOA projects and watching others, I'd say these are some of the top reasons that SOA initiatives fail:

    1) Poor understanding of SOA outside of IT. Although I do see the business side of many organizations increasingly understand the importance of SOA, a sustained lack of engagement from the business-side starves the SOA of priority involvement from the most important people in an organization: Those that run it. Why is this? SOA is still too technical to be embraced by the average business person. Whose fault is this? It has to be shared: Business and IT must continue to tear down the barriers between them and SOA is well positioned to do this. However, all too often, the SOA fails to be truly strategic and becomes marginalized, often to fail.

    2) Aligning SOA with actual projects. SOA initiatives and the downstream projects that use SOA capabilities are usually separate groups and often have divergent goals and deadlines. They must work closely together but these differences encourage projects to "route around" SOA to get things done and have the positive control necessary to deliver solutions.

    3) Not-invented-here. If you're buying big IT systems from major vendors that don't follow your SOA standards or just trying to get IT groups from different parts of your organization (often spread around the world) to follow standard EA and SOA guidelines, you'll find that NIH makes formal SOA guidelines all to optional when push comes to shove.

    4) Development tools that don't support SOA. Too many of the latest and most exciting development tools don't support so-called "Big SOA" standards and technologies. Developers don't have what they need to succeed with SOA and can't comply. Older technologies such as Java and .NET do tend to support Big SOA but they are getting longer in the tooth and younger developers aren't interested in them.

    There are other reasons SOA initiatives, such as inadequate funding and low levels of information technology sophistication, but the ones above are potentially preventable if we take them seriously.



  • I would very much agree with JP (and with Anne in her original blog that triggered the hand wringing), the goal with a SOA project is to deliver tangible business benefit, and not architecture or technology for its own sake.

    The problem is that SOA for too long has been seen as a special case, with its own governance stack, lifecycle, tooling, and architect/development specialists. In actuality SOA is an architectural style that may be suitable for supporting enterprise agility through loose, standardized coupling of enterprise or external software, process, and/or data assets. The development lifecycle should be part of the SDLC; similarly, run time governance should be part of IT Service Management. I can understand Joe's comment above that thee have been poor or non-existent metrics from SOA projects, but frankly, it's not a matter of measuring SOA effectiveness, but the effectiveness of a software project through its development and operational lifecycle in general. An SLA is an SLA, regardless of whether you are talking about a SOAP or RESTful service, an RPC, a database, or whatever.

    Promoting SOA as an end in itself that is not aligned with business requirements or integrated into the SDLC and IT peraiotns is doomed to failure.

  • Primary reason for failing SOA initiatives:

    Vendors selling products instead of supporting an architecture.
    SOA very quickly became about integration and middleware instead of interACTION and truly loose coupling, because that was what the web service oriented products did.

    Just about every vendor with a service bus in their portfolio basically doesn't get SOA as an architecture at all (or rather CHOOSE not to get it).

  • I'd like to re-phrase the question. In my opinion, it's too early to ask why SOA fails... I think a more timely question may be "why do projects based on the principles of SOA fail"? Here's a quick metaphor.. My first round of golf was a complete failure. Did that make me a failure as a golfer? I don't think I could say that... I realized what I lacked was skills, education, practice and discipline. I'm now taking lessons. It is conceivable that I may turn out to be a failure as a golfer but one round is too early to tell.

    I think many customers have made initial attempts to deliver projects that they believe are based on SOA but they are finding out that wanting to adopt SOA is not that easy and SOA just doesn't happen. We are now in the phase that I would like to call the "SOA school of hard knocks" where we are learning what it takes to effectively infiltrate SOA into the IT consciousness as an architectural approach and methodology to more easily modernize applications and orchestrate business processes. Initial projects may fail based on many of the reasons well communicated in earlier posts:

    --lack of skills and education
    -- lack of definition of objectives and measures -- how do we define success?
    -- lack of integration of the SOA effort with the rest of IT and the application lifecycle

    and more...

    But this doesn't make SOA a failure if an organization realizes they are on a journey and has the ability to learn from their mistakes and the intestinal fortitude to continue the effort. The benefits of taking the SOA journey will come for the organizations that have the patience to build the foundations for success -- skills, education, cultural change, clearly defined measures of success, governance, and linkages with the rest of the application lifecycle.

    Back to the golf lessons...

  • I agree with most of the responses. At a very fundamental level, it is often a mismatch between benefits expected and the definition of SOA being implemented. See my blog:

  • It’s not the technology; it’s the people. The single biggest cause of failure of SOA initiatives is an inconsistent level of support among the stakeholders. The big vision of all-encompassing, enterprise SOA is nice, but the reality is that SOA always starts small, often with a single distributed application. Sounds easy, right? Well… no. Get this one wrong and you may not get a second chance. The problem with your nice little application is the number of departments that need to be involved, coordinated, and—here’s the tough one—fully committed to its success.

    The initiative may have been driven by the CTO’s office, so her architects are certainly involved. There are the individual developers who are usually start off enthusiastic because the technology is interesting and new. The CIO’s department is well represented through operations: firewall admins, network engineers, database and application server specialists. Finally, there’s that security guy, the one who shaves his head and always dresses in black. Nobody is certain who his boss is but his opinions carry a lot of weight. I hope you booked a large enough room.

    SOA cuts across departments and blurs existing IT hierarchy. Some of the technology you will introduce will challenge roles and ownership. To be successful, you need diplomacy, tact, and very good team building skills. If you get this part right, you will overcome the inevitable technology road bumps. Otherwise, these will be leveraged to make your SOA fail.

Add a Reply

Recently Commented On

Monthly Archives