How to avoid your SOA initiative becoming a big So What?

For the past few years service-oriented architectures (SOA) have been promoted as the panacea of the IT world, but cracks in the SOA hegemony are already beginning to appear.

Celona Technologies Tony Sceales examines the hype, hope and reality surrounding SOA, and points out some home truths that anyone embarking on a SOA programme would be well advised to take note of.

One of the quirks of the IT industry is our love affair with the three letter acronym (or TLA as I suppose I should call it). Somewhere in the world there are a whole bunch of very clever marketing people slaving over the next-generation of TLAs as we speak. They are busy bundling up the hopes and dreams of the entire IT industry into three seductive letters that look mightily persuasive on a PowerPoint slide. One of their more recent successes is SOA, or service-oriented architectures if you prefer. For a number of years SOA has been widely promoted as a panacea to many of the problems our industry is facing particularly the requirement to reduce costs and increase agility. Analysts, vendors and end users alike appear united in their enthusiasm for it. Butler Group, for example, tells us that only 3% of organisations have rejected SOA. And a recent survey by systems integrator Griffiths Waite[i] found that 2008 is a critical year for SOA implementation, with 15% of organisations already running SOA but a much larger 38% progressing towards it. Of the 47% still contemplating it, Giffiths Waite says evidence suggests these will [start to] move into strategising and planning.

But it has to be said that despite these bullish figures scepticism about SOA is starting to gain voice, along with news of the first SOA casualties from the front line. Anne Thomas Manes, VP and Research Director with the Burton Group, recently blogged[ii] about her ongoing research with enterprises implementing SOA, for example.  She says:I think Ive become a bit jaded from the interviews, [because] it has become clear to me that SOA is not working in most organisations. She goes on to describe how despite the stunningly beautiful SOA infrastructures these companies have developed, their SOA initiatives invariably stall out. She says: The techies just cant sell SOA to the business. They have yet to demonstrate how all this infrastructure yields any business value. More to the point, the techies have not been able to explain to the business units why they should adopt a better attitude about sharing and collaboration which is the fundamental cultural shift required for SOA to succeedAs one of my interviewees said, Altruism is not an enterprise strategy.

Anne has highlighted an important issue: we can throw as much technology (and as many TLAs) as we like at these business problems, but technology does not guarantee a business-oriented solution. The very real risk is that when SOA fails to deliver the bulleted benefits promised on that Powerpoint slide 12 to 18 months ago, a serious backlash begins. SOA is instantly transformed from a no-brainer to a big so what?

Im not for one minute suggesting that SOA isnt a very good way of building enterprise systems, but I think its important to recognise that SOA is not a magic bullet, and is only one part of the overall solution. As Anne has outlined, SOA may integrate application silos but it does not in itself transform organisations, break down organisational barriers or streamline processes. Neither does it guarantee that the services created are useful.

Take, for example, a train company which has three seat booking systems: one for its self-service web booking system, another for staff in stations and a third to support its telephone booking system. The company uses a SOA approach to redistribute these applications as enterprise services. Unfortunately, it then discovers that each application has its own database, each of which has its own version of the truth. While the application supporting station staff replicates and updates the seat inventory every 10 minutes, the phone line application only replicates once per hour and the website application only once a day. This means that there is a discrepancy between the number of seats available according to the application being used, and between these and the seat inventory system.

Now consider the CIO who sold the SOA concept to his CEO on the basis that he could deliver a service that brought together key data which would help support critical decision-making. Now what happens when this CIO discovers that there are duplications, inconsistencies due to refresh cycles, and that the aggregated data is in any case meaningless because the source data had different shades of meaning?

What this demonstrates is that while you might have thought SOA would circumvent the requirement for risky application migrations, in fact it has simply delivered a nightmare scenario of its own by exposing weaknesses in the underlying data infrastructure. And unfortunately if, like the man who built his house on sand, you choose a weak (data) foundation for your SOA, ultimately your beautifully-built edifice will crack, subside and fail.

So if you are contemplating a SOA initiative, or are just embarking upon one, how can you prevent your project turning into a big SOA what?

Firstly you need to recognise that SOA is just one part of the solution. To succeed you will need to address a wide range of people and process issues to ensure the project is business-aligned and delivering against real business need. You must also be careful not to underestimate the data migration and data testing effort that will be required. Be mindful of that old IT adage: garbage in, garbage out.  If you dont put the effort in at the data layer then SOA will simply become a more efficient way of delivering poor quality data. In reality, SOA will inevitably involve some migration and consolidation effort even if you decide that a distributed data infrastructure is the best approach for your enterprise.

Need to show quick wins? Then the good news is that third-generation data migration technology can support a think big, start small strategy because it enables you to decide which data sets you wish to migrate first, using business rules not technical ones. Whats more, it also supports bi-directional synchronization of sources and target, helping you achieve a consistent and accurate state.

I cant put it any more succinctly than Dana Gardner did, way back in 2006: So dont put the SOA cart in front of the meta data horse. If anything err on the side of the data investment. That way your SOA will readily reap the rewards of your hard work in data management and optimization for maximum process efficiency and knowledge commerce.[iii]

Tony Sceales is CTO of third-generation migration technology vendor Celona Technologies.

[i] See SOA Maturity Survey Report: Discover How to Ensure That Your SOA Program is on the Path to Success, Griffiths Waite (sponsored by Oracle) www.oracle-itfusion-conference.com/common/griffiths%20waite%20soa%20report.pdf

[ii] See Application Platform Strategies Blog, Anne Thomas Manes, March 09, 2008 apsblog.burtongroup.com/2008/03/looking-for-soa.html

[iii] See SOA requires that you get your data act together, Dana Gardner, February 22, 2006, http://blogs.zdnet.com/Gardner/index.php?p=2258