The SOA bandwagon has been trundling on for about ten years now and, if you believe Gartner (and why not?) SOA has passed the Peak of Inflated Expectations, dived to the Trough of Disillusionment, and is currently climbing the Slope of Enlightenment, on its way to the Plateau of Productivity. Industry estimates are that the journey for most companies is at least another 3 – 5 years. There are a small number of published success stories for SOA, and I am sure a large of unpublished horror stories.
Why has SOA proved so stubborn in demonstrating value in an easy to digest format to give us all confidence? My thoughts are as follows:
- Blissful Ignorance. In other words, buyers believing the sales spiel from the software vendors. About 3 years ago all traditional development and integration vendors rebadged their tools as SOA (-compliant, -ready, -leading, etc). So people who bought SAP were told it was SOA-compliant and they were now service-enabled… Not many SOA success stories here.
- Informed Ignorance. Buyers believing the analysts that SOA was here and if they weren’t doing it, their competitors would wipe the floor with them. I find it amusing going through the Butler/Gartner/Forrester predictions from a few years ago that assert that SOA will rule by now. Funnily enough, their current flights of fancy, sorry predictions, talk about newer snake oil – cloud computing, Web Oriented Architecture, etc. These trendies will already have dropped SOA for these new toys.
- Fashion-Proof. Think of those people you know who are still dressing as their parents did and wouldn’t be seen dead in the latest tight/flared/baggy jeans fad. Most of the people running large IT shops have the same mentality about new technology. The likelihood of them authorising their CICS/Cobol programs to be turned into WS-compliant services is zero.
So, most people’s experience of SOA so far has been either patchy (we wrote a web service and it worked – we’ll try another one next year) or frightened (analysts quoting cost of building SOA to be larger than most companies’ annual budget). Even though many CIOs see moving to SOA inevitable, most are still challenged to articulate what the business is going to get for its money if they allow their IT people another toy to play with (IT is usually seen as Kevin the teenager – inarticulate, negative, late for everything and getting bored with anything new they buy).
To get a believable ROI for SOA you need to do SMART SOA.
Smart SOA works as a phrase when you consider it more as an application of the old acronym SMART (Specific, Measurable, Agreed, Realistic, Timely) to Service Oriented Architecture.  Given the ongoing challenge of IT to deliver genuine and lasting business benefits, it makes sense to at least appear to be trying to add value.
Taking a SMART approach, IT can provide their sponsors with clear goals and benefits for any investment project, along with a set of metrics to ensure that promises are quantified and understood.
Another way to get SMART is to break down the journey and phase the adoption of new architecture as a journey rather than big bang. I have found that this evolutionary approach is both more acceptable to business as well as being more practical, less risky and therefore more cost-effective.
All of the SOA success stories I have been involved in have started small (one or more Proofs of Concept), attracted growing interest from other IT teams and business sponsors and has evolved to support the areas of the organisation that can get most benefit from SOAÂ – typically fast changing areas, that can be reasonably isolated from the mainstream until the processes are developed and the functionality can be reverse engineered into the core infrastructure.
Ironically, with the ‘Lego’ building block analogy prevalent in describing how SOA works, building an SOA strategy and infrastructure from a number of small interlocking projects shows how this analogy actually works in a slightly different way, but one in which the business sponsors will be more interested and supportive.
To derive a believable ROI for a prospective SOA project, I have found it advantageous to use process modelling to demonstrate the potential value by quantifying cost/time/quality benefits before staring the project and then achieving these benefits by exporting the model to an SOA environment and re-using the objects you have created and agreed with the user. This not only accelerates the development, the process model will also keep expectations aligned between the sponsor and the developer.
It should also be emphasised that you should NOT attempt to install and use a complete SOA stack on your first project. I have never seen this succeed other than in an artificial sandbox environment. An incremental adoption of the core SOA tools and techniques will significantly lower the risk, at the expense of delaying the full roll out of SOA. I would suggest this is no bad thing, except for the software vendors.
