Burton Group's Anne Thomas Manes recently proclaimed that 'SOA is dead, long live services'. There was a rapid response from David Chappell at Oracle, spirited pro-SOA cheerleading from Sandy Carter at IBM, as well as excellent rebuttal from Joe McKendrick writing at ZDNet.

What might be regarded simply as 'headline grabbing', has stimulated decent renewed discussion and provided an opportunity for introspection and realigning implementation approach. With this in mind Steve Nimmons, Atos Origin, examines if there is really any life left in service orientated architecture.

I categorically believe that SOA is 'alive and well'. I think it is suffering from TLA (three letter acronym) 'burn-out'. The best practices and genuine sensibilities of SOA (although suffering from the tedium of endless repetition) are well founded, pervasive and in many cases practically ubiquitous. As SOA started to become 'business as usual' (i.e. a defacto pattern) we sufferers of SOA Fatigue Syndrome (exponents of less talk, more implementation) breathed something of a sigh of relief.

I gave this quote in the latter half of 2007: 'SOA is disruptive, business and IT alignment potentially difficult and costly and the "the time is at hand" to ensure your major investments are in the hands of professional engineers'.

Was this advice followed and what happened to tarnish SOA's reputation?

I recall the summer of 2007, looking out across a skyline peppered with the paraphernalia of industrialisation pondering the differences between software and civil engineering. I considered that civil engineers and architects well understood the transformation of customer requirements into functional, safe and cost effective structures.

Experimentation in this domain lived (mostly) in the realm of aesthetics. Tooling, best practices and industry regulation were mature; 'structural formulae' and limitations well understood and swathes of truly re-usable assets constantly utilised.

As the multi-million pound buildings sprung up like concrete clones, I considered how eyebrows would be raised if an architect arrived with a blank sheet, vague estimates and limited credentials.

If the concentration turned to the functional minutia (for example workshops to determine the number of desired stairs between floors), it would rapidly be concluded that guidance was being provided by the inexperienced. software engineering and SOA are perhaps more logical in nature, less physically tangible, but there is significant commonality.

Think back, did your suppliers come with reference sites, a defined methodology, established and credible assurance processes; with proven reusable assets (those customisable with limited fuss and head scratching over intellectual property rights)?

Taking the construction paradigm, did you expend valuable time discussing metaphorical stair depths, window frame sizes, concrete and steel mixtures or the width of elevator shafts?

Unless you are a time and cash rich eccentric the answer should be a resounding 'no'. Why then did 'the industry' tolerate a panoply of technological roustabouts, who simply do not 'walk the walk' of their ‘alleged’ convictions? What wounds did SOA suffer as a result?

• Hype! IT's oldest adversary responsible for the demise of many great hopes. As I warn repeatedly, waves tend to hit the beach and leave those on-board wiped-out and washed-up. Silver-bullet / panacea marketing is responsible for many undelivered promises. When it takes 'the judgement of Solomon' to separate substance from spin, hype is prime suspect. Hype is also a great attractor of 'accidental practitioners', those nomadic creatures whose job titles change in line with the analysts' annual round of fortune telling.
• SOA was harder than you were told? How many 'piece of cake' presentations did you see in '07/'08? Do you recall the 'we've really been doing this for 20 plus years anyway' mantra? Wrong! If the funding, sponsorship, commitment and expectations were misaligned you cannot blame the underlying principles of SOA for short falls.
• Wrong people driving it. Not everyone that told you they were a SOA visionary really knew what they were talking about. False prophets lead to false profits. I'm sorry to say the IT industry has more than its share of 'great pretenders'. This underpinned my 2007 plea to place your SOA implementation in the hands of professional engineers with professional engineering principles
• The ultimate silo. I get exceedingly vitriolic on this topic. This starts with 'IT and the business' as if modern enterprises are entwined as the cosmic interplay of ying and yang. No, no and thrice no! This creates or perpetuates a 'them and us' culture and created the two 'ultimate silos of SOA failure'.
• Overly complex tooling. There are absolutely wonderful tools on the market, but RoI is 'maximised' when suitable investment is made in training of resources. At the 'sharp end' SOA tooling can be tricky and down-right arcane. In the wrong hands I'm afraid it leads to 'disaster'. Bloated tools created by squabbling vendors trying to differentiate above common standards share some of the blame.

The endless repetition and regurgitation of SOA benefits in itself became tedious. 2009's 'hype death' might well bring significant benefit as some of the 'accidental practitioners' head off into cloud, SaaS and other 'favoured' domains for 2009.

But still I say 'long-live business component encapsulation, abstraction, orchestration and choreography, re-use, composite applications, decoupling, asynchronous transactions, governance, interface contracts and canonical data'. If SOA needs a 'new name' then so be it, but let's not artificially separate 'baby from bath water' in an act of sacrificial convenience. Leave some milk out for SOA, that silky architectural wonder with numerous lives and numerous names.

May 2009