Common causes of SOA failure

A number of common misconceptions will make most SOA initiatives fail, hard to survive or not start at all. This post is not complete, and may be updated many times, depending on the feedback I get from you, the users. If you feel a cause is missing, drop a comment including your issue, cause and resolution. Don't forget to mention your name and contact details.

• SOA is a silver bullet
  
• Failure to implement proper governance
  
• Failure to get management buy-in
  
• SOA "the enterprise"
  
• Specific vendor has the best SOA implementation
  
• SOA quickly brings ROI
  
• We are doing web services, so we are doing SOA

SOA is a silver bullet

Issue: SOA is not a tool but an architectural approach. Implementing a tool does not implement the SOA concepts into the business and technology.

Cause: Vendors explain their SOA tools to be the silver bullet.

Resolution: There is none. SOA is a mindset supported by tools; as long as you are aware about that, and live up to those concepts and patterns, you may be fine.



Failure to implement proper governance

Issue: Failure to consider/facilitate the governance burden in a project will increase the governance burden after the project, if not make it virtually impossible.

Cause: Implementing a SOA in a project instead of a programme may easily let the project slip into the tactical approach instead of the strategical approach.

Resolution: Setup some governance requirements prior to starting your first business project. Having these can force the project to include governance in the project, making sure the deliverables are not left 'floating' in the organization after project delivery.



Failure to get management buy-in

Issue: We, the IT department got this SOA installed, but no-one is willing to invest the extra money required with the implementation of SOA services. Every project is going for the quick and dirty approach, continuing as they were...

Cause: No management buy-in, resulting in lack of appropriate governance.

Resolution: Evangelize! Convince the senior management staff that the SOA thing they bought is really a good thing, resulting in long-term benefits, the traditional way of working will not provide. Result of management buy-in can be that the appropriate governance is implemented and a SOA way of working is enforced. Explain the same situation to everyone who's willing to hear your story.



SOA "The enterprise"

Issue: Companies try to change the entire enterprise at once. This is a definite recipe for failure. No single company can change all their IT systems, business processes, governance etc. in one go.

Cause: This is a common misconception: Implementing a SOA involves people from the entire enterprise when the business analysis and service modeling project phases take place. This means people from the entire enterprise, multiple disciplinces. This does NOT mean that we need to involve EVERYONE and ALL systems.

Resolution: To start very small: select specific business processes to change. Implement SOA services using the SOA approach which show a clear business value and can demonstrate that SOA can work. Typically management only chooses a technology if the proof is there. Maybe even demonstrate a few quick wins. Even then, SOA is a strategical approach so don't expect miracles.



Specific vendor has the best SOA implementation

Issue: Comparing vendors' SOA products based on their marketing and their product specifications gave me this best of breed product, but it's not doing what I want. It's not possible to 'get the best SOA products out there'.

Cause: A lot of vendors deliver their SOA product with a lot of promises and marketing terminology. Sometimes it's even not true that certain vendors claim delivering SOA tools because people mistakenly assume 'web services' being 'services'. Also it's hard to do a product selection without requirements. It is similar to the 'get me the best car out there' discussion. If you don't tell your requirements you may end up with a Ferrari on an offroad track.

Resolution: Define your company's requirements, define a strategy and then compare products with your requirements.



SOA quickly brings ROI

Issue: If I buy this SOA thing, I will quickly get a better ROI.

Cause: Not understanding the strategical nature of a SOA.

Resolution: Increased ROI, Better technology/organizational alignment are prerequisites for a reduced IT burden. All of these are indirectly obtainable SOA characteristics, depending on a number of other SOA concepts. This illustrates the strategical nature of the SOA approach.



We are doing web services, so we are doing SOA

Issue: Web services and SOA service terminology is mistakenly assumed "the same thing"

Cause: Web services provide a standard technology for the service contract. Web services don't force the user into following SOA concepts and patterns delivered by the SOA approach, resulting in "SOA Services"

Resolution: This needs a proper implementation of accurate terminology in people's minds. Once this is reached, a common understanding of the difference between a web service as technology and service as concept is reached and the mistake will not be made again. This may very well be one of the hardest things to achieve (my definition of service is better than yours, your definition of service does not deliver anything concrete etcetera).

SOA is not a disease!

So... I finally gave in... Soooo many times I have thought about what I could do with my experience and ideas related to clarifying what SOA is all about. Yes I hear you! I'm nr. 10 billion who writes about SOA and probably there will be another five before the next hype comes along! And you are probably right. Just bear with me and give it a chance - and btw thank you for being one of the five people reading this blog!

So here I am, in the field since 1995 and many years experience with SOA and distributed computing in general. After graduating I started working at a large consumer electronics firm, writing prototype software (user interfaces) for televisions and set-top boxes. This was mainly of the demo nature and the only true production-ready SW I ever wrote for that company was embedded software implementation for a set-top box. This was challenging as the platform had many constraints and performance was all that mattered. These restrictions got to me and I moved to another company. I still remember when I wrote my first service broker based component based distributed system for my new employer, a large telco in the Netherlands. I've tried MS's COM/DCOM/MSMQ/MTS server based software and was amazed with the openness and flexibility this gave me. Nowadays we would know the concepts applied back then as service broker, asynchronous queuing, distributed transactions, durable subscribers etcetera. Little did I know :). Later I continued on the J(2)EE platform which was much more stable and required hardly any workarounds. I integrated a lot of systems and even dipped into the web-pool shortly while (co)writing two web portals intended to merge information management, workflow and sales tooling for this telco. We used BEA and JBOSS (now oracle and redhat) tooling. Around 2002 some people were talking about SOA and I looked into it - it looked promising. At the time I considered SOA a been-there-done-that exercise. Well, guess what - we made some mistakes - expensive ones. Very expensive ones! Not just technology and architecture, but mainly governance and organisational mistakes.

Anyway, this brings me to the title of this blog. Where I'm from, The Netherlands, the acronym means something entirely different - in English you will all know the term STD and that's what SOA means in Dutch: Sexually Transmittable Disease. Today, many companies have turned their back towards SOA and indeed treat it as a disease. Because it did not deliver what it promised, or because they purchased a tool and figured it would change their luck and would reduce their investment. Well, WAKE UP! Nothing is less true. SOA will not bring return on investment, and will probably make matters worse if nothing else changes in the enterprise. Great, you think, I just invested tons into this new tool and hardware, and now you tell me it was a mistake. You tell me I will spend much more. Whoa... hold your horses. Indeed I am convinced that if nothing else changes, purchasing a "tool with a promise" will cost you. So, what else needs to change? In order to figure that out, we have to explore a number of concepts and patterns which will most likely change your mindset about SOA. And when it does, we are ready to talk about how the tools can help you leverage your architecture to bring reduced IT burden and consequently, a better return on investment.

I won't be writing often as I simply don't have the time for it - yes I too tend to think I have a life. I will purposely pick topics to trigger discussion clarifying how SOA may or may not work, hoping that it may do the same for you.

From this article I hope to convey one message: it's not something you can buy, it something that requires hard work and a lot of planning! Implementing a SOA is not something you do in a week-end. It is something that takes years. Any benefit you expect, don't expect it anytime soon. From my personal experience I think it would take 3-5 years before the SOA starts bringing structural benefits. If you think you need show return on investment results during this or in the next fiscal year, maybe SOA is just not your thing! That's what it is about: tactical versus strategic. And SOA definitely qualifies for the strategic approach.

See you next time...