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's the Key Difference Between SOA that Succeeds and SOA That Fails?

Vote 0 Votes
What's the key difference between SOA that succeeds and SOA that fails?

19 Replies

| Add a Reply
  • SOA requires sound engineering principles, which should not be a paradigm shift but rather paradigm enforcement. In studying the success and failures of SOA projects over the last 25 months, it is clear that the lack of solid architectural and engineering practices has played a statistically significant role on many of the SOA failures that were under investigation. For some unknown reason, those implementing a service-orientation in their solutions often leave behind the sound principles taught in school and reinforced in life. In lue of what’s right, the engineering community is led to believe that somehow SOA requires some new and previously unthought-of paradigm. But the interesting question is who is leading this effort and why?

    Please check out my blog if this kind of discussion is interesting. I have written extensively on SOA, especially its necessary and sufficient characteristics.


  • The problem is, most companies simply don't know if their SOA is succeeding or failing. There needs to be key performance metrics, measurement, before and after, what-if analysis. Right now, most SOA efforts have delivered "feel-good" results, such as better connectivity. But managers have had precious little insights on the impact on business growth.

  • I have two major issues with many SOA success stories.

    One is the definition of SOA used in the success story. Many times what they mean by SOA is Web services (or some other interoperability technology) used in an EAI context. In other words, it's about old-style integration of existing silos, with no attempt to actually break up those silos and refactor their functionality into reusable and recomposable business services.

    The second issue I have is that proper verification of SOA success in certain areas of claimed SOA benefits requires a significant amount of time (e.g. a couple of years) and those success stories are far from verifying success across that time period. For example, let's take the claimed agility benefit. That requires verifying how the SOA architecture enables agility in the face of business changes (e.g. change in government regulations). That, again, requires time to allow those business changes to take place. After those changes occur, verification should be made that the originally business services identified and implemented are still valid (if they need to be replaced, substantially modified, or new services need to be added, the agility claim might go out of the window). Then a comparison should be made with other companies and/or projects that did not use the SOA approach and see the agility of their response to the same business changes. I personally have not seen any example of this kind of rigorous success verification.

  • Right context. In my experience, the best context for SOA is a well-architected BPM (discipline + tools + your enterprise system).


  • I agree with Brenda. It all comes down to expectations, because there is no single definition of SOA adoption of success. You can ask, "Did your SOA efforts meet or exceed your expectations and goals?" and you might get back 95% yes answers, but some people may dig deep and say, "All you did was start using web services where you previously did legacy screen scraping" or any of many other things that could raise doubt as to whether it was really SOA or not. What's important is not broad, general surveys, it's whether or not the things you did succeeded in achieving the desired goals. If your goal was to improve application delivery time through better reuse of existing stuff, then look and see if that has been the case. If so, claim success. If you called the effort to make reuse happen SOA, then you'll claim SOA success. Someone else may have different goals for their SOA effort and a completely different criteria for success.

    Back to the point, I do think the major difference between what companies claim as success or failure does come down to expectations and goals. When the expectations are clear and the goals are clear, claiming success or failure is also clear. If anything, I'd also say your chances of success are even higher, because you know what you're shooting for and most people will work hard until they achieve it. A common reason things fail is not due to lack of hard work, but because the expectations and goals of it are simply unknown, so the people involved are simply chasing a moving target until someone finally says, "we've spent enough, cut it off." Is that a failure of the people working, or was that a failure of management to establish appropriate expectations and goals?

    Here's your litmus test. If you are adopting SOA, can you answer the question, "How will you know when you're successful?" If you can't answer it, then guess what. You're probably setting yourself up for a perceived failure.

    • sorry, I got my people wrong. I just agree with Brenda so much of the time. It was Guy who said expectations, not Brenda. But I'm sure she thinks that, too, in addition to being business-driven. :)

      • So, if I normally agree with you, and you agree with Guy, does that mean (via a transitive rule), I also agree with Guy?

        I'll buy that. "Business-driven" starts with business reasons, which of course, need to have measurable expected outcomes; followed by measured actual outcomes.

        Which ties nicely with Joe's comment. All winners today ;-)

  • @Todd, I can agree with your approach only if you specify that the expectations must be directly related to SOA claimed benefits (business visibility, agility, service reuse, service composability, etc).

    Otherwise, anybody could just attach the SOA label to any project not even distantly related to SOA, then set expectations which also might have nothing to do with SOA claimed benefits, and, as long as those expectations are met, there you have a new successful SOA project. That could only add to the SOA hype.

    Also, even by using only SOA-related expectations, I am rather skeptical of subjective declarations of success. Have you ever seen a project manager happy to declare that his project was a failure?

  • If you cost out the design and development of a “Service-Oriented Architecture? that adheres to SOA principles then you have a start at success, but if you truly want to help the business then you need to wrap your “Service-Oriented Architecture? with a SOA Infrastructure so that the business’s valuable assets can be protected and made to be dynamically and rapidly changed to meet business drivers and market change. Without such a SOA Infrastructure your “Service-Oriented Architecture? is only half way helping you succeed in reducing costs, increasing productivity and escalating competitive advantage, the three cornerstones of what I would consider to be “business-driven.?

    In today’s economy, there is a desperate need to develop tool-sets and processes to assist in combating the inadequacies that hold back businesses such as prolonged project deadlines, resources limitations, and migrating assets into new technologies merely for the sake of technology or worse, being tied into a proprietary solution set.

    This is the evolution to a SOA Infrastructure, which, is the tool-set that provides the agile service process that will take you to “Service-Oriented? success.

    Notwithstanding, the use of a Service-Oriented Maturity Model with well-defined phases and pre-defined outcomes will provide you the necessary boundaries, confidence, score keeping, and evidence that you need to mature.

  • Ugo, a couple of things. First, I certainly agree that a company shouldn't slap an SOA moniker on an effort and claim SOA success, and there have certainly been examples that an outside observer might question. I've judged an SOA case study competition and you do have to try to separate the "my project used web services" case studies from the companies that had broader, cross-project goals around the themes you indicate.

    The second thing, however, is that it doesn't matter what some outside observer thinks. What matters is whether or not your effort achieved your goals. You can question whether or not it should called an SOA effort or not, you can question whether the goals were quantifiable or not, but if the goals were clearly stated to where success or failure is easily determined, then it doesn't matter what you or I think, or whether it matches what some other company did under their SOA effort. What matters is that organization set out to do something and they accomplished it. That denotes success for them, period. Unfortunately, establishing those clear definitions of success is not something I've seen done often. I see too many definitions tied to delivering on time and on budget, and not on business outcome, which links up with Brenda's comments.

  • Todd, I understand your point: whatever works for a company it's great for them. Even if they mislabeled their effort as SOA when it is not, but it worked for them, more power to them.

    The point I am making is different. We are telling people: use SOA principles and you'll get these benefits. Those people are entitled to say: can you prove it? That's when you show them rigorously defined SOA projects that succeeded by providing measurable SOA benefits. You don't want to show them the other type of "SOA" examples (i.e. something that is really not SOA, but still worked for a particular company) because in that case the example does not have anything to do with proving SOA success.

    Going back to my previous discussion about providing rigorous proof of agility, can you point me to specific examples that demonstrate actual agility being achieved by a SOA effort? As I mentioned before, I need to see the actual impact of business change on an existing SOA solution, and I need to see how that impact compares with similar non-SOA solutions facing the same business change.

  • @Thomas, I am not sure what you mean by "SOA Infrastructure", but I suspect you mean what is today sold as "SOA Platforms" (e.g. IBM SOA Suite, or Oracle Fusion) or as "SOA products" (e.g. one of the many ESB products).

    If that is what you meant, I would like to ask you: do you think that somebody who rigorously applies SOA principles, but does not use a SOA Infrastructure, would not be able to achieve a situation where "business’s valuable assets can be protected and made to be dynamically and rapidly changed to meet business drivers and market change"? In other words, is SOA success tied to using particular technology solutions?

    • Ugo, there are SOA principles that must be adhered to in order to create a Service-Oriented Architecture(SOA). A SOA can be developed in a number of technologies, i.e., J2EE, .Net, etc. This will provide you with the "architecture" but wrapped around that architecture are the things that truly make service-orientation successful.

      For example, folks are using the term "governance" which has meaning at the people level as well as at the technology level. A SOA Infrastructure will provide the governance at the technology level, for example, who created the service, what does it do, what version is it, etc. Without getting into details and tipping my hat there are other things that a SOA Infrastructure tool provides that greatly enhance the opportunity for success. You may contact me off-line if you wish and we can discuss further. Hope this helps a bit.

  • In most cases the most important keys for successful SOA are:
    1. Business and IT cooperation and not IT only driven initiative.
    2. Adequate Maturity level
    3. SOA integrated with Event Driven Architecture and with BPM

    For more information read the following posts in my blog:
    SOA in 2009

    SOA and Corporate Culture change

    Reuse Easy to say and hard to use

  • Thomas, I think we disagree on the relative importance of infrastructure vs. architecture regarding SOA success.

    Without detracting anything from the usefulness of many SOA frameworks, in my view the ultimate success of a SOA project depends on how well the SOA principles have been applied to the particular business context.

    If I use an ESB (or whatever else is being sold as necessary for doing SOA), I might speed up the development of my business services, but if my services are poorly defined no SOA infrastructure will change that.

    If I had to choose, I would certainly prefer to have a SOA project where the services are implemented with rudimentary tools but are the right business services, than a SOA project where the implementation uses all kinds of sophisticated infrastructures but the business services are all wrong.

    I can apply the same reasoning to governance. If I had to choose, I would prefer to have governance in place with all the right processes, policies, contracts, SLAs, etc. but using rudimentary tools (e.g. a shared file system), rather than having the most sophisticated registry/repository holding the wrong governance elements.

  • Thomas, another point. Most of those sophisticated SOA frameworks are very complex and require a long learning curve.

    (I have direct experience of that, having spent the last four years using the latest and greatest offerings from the IBM WebSphere SOA suite and the Oracle Fusion SOA suite - by the way, have you ever been in the situation where you find there are problems with a SOA product and realize that almost nobody in the vendor's technical support even knows what you are talking about?).

    If you had limited time and resources in your SOA project, would you rather spend more time perfecting your architecture or learning those complex tools?

    Of course, if you have time and money for doing both, all the better. (In fact, it's part of my business to know those complex tools so that I can charge money for that knowledge ;-).

    • Ugo, I totally agree that the tools you mention are overly complex and require in some cases "Certifications" to be used.

      Our approach is much more simple and direct. We have a SOA that was designed and developed that adheres to the SOA principles, but we have also created the SOA Infrastructure that surrounds the SOA itself allowing the user to concentrate on creating the right "Entity", "Task", or "Utility" service necessary to meet the business requirements, in a dynamic, non-coding environment.

      I would agree that you can get success with a good SOA and some adequate tools, but you can get what I would consider "real" success by using a very sophisticated but easy to use SOA Infrastructure tool. Best of breed and best of both worlds.

Add a Reply

Recently Commented On

Monthly Archives