IBM: SOA Far, SOA Good?

It’s been a couple of months since I jumped on a plane back from IBM’s SOA Impact conference in Las Vegas. For those in the know, this conference is a re-named evolution of the IBM’s WebSphere conference series, and for those less so, WebSphere is IBM’s brand associated with its enterprise scale application server software and assorted gubbins to support transaction management, asynchronous messaging and so on – the “platform” elements of corporate applications. The 5,000 attendees comprised a fair whack of WebSphere developers and architects, and suitably impressive numbers of CIOs and other IT executives.

Why the conference is called “SOA Impact” and not anything to do with WebSphere is of course as much to do with marketing as anything. IBM has been quite forthright in pushing its SOA message, and even the very name of the conference offers one such opportunity to put SOA into the spotlight. The million dollar question is, is it right for IBM to do so? Before arriving at the answer (which, for all you skim-readers is yes, absolutely), it is probably worth a bit of background in SOA.

In this hype-ridden industry, the real trends can often be hidden underneath the layers of hype. One such trend has been the nature of software applications. For the 20-odd years I have been working in this business as a developer, quality manager, IT director, consultant and (only latterly) industry analyst software has been moving inexorably towards a distributed model. In such a model, chunks of software (note the avoidance of buzzwords here) do what they do well, and communicate with other chunks of software as, when and however necessary.

This is a very familiar scenario to anybody that ha been involved in IT over the past couple of decades. For years, organisations have been integrating their legacy systems, packaged applications, databases, rules engines, process control systems and so on using various forms of integration software. And it all works, after a fashion.

Not all of it is how we would like it to be, had we the opportunity to start afresh And this is where the evolution comes in. All those years of deploying and integrating applications have resulted in a pretty good understanding of how things should best be done. The first, most important and blatantly obvious aspect is that things should be planned out in advance, as an architecture rather than piecemeal components. That’s not rocket science, its common sense.

The second aspect concerns how the software elements – the applications and packages, or other discrete units of functionality – should communicate. In this there is an element of rocket science, in that many different mechanisms have been tried over the years. The branch that has developed most strongly has its origins in “object oriented” software design techniques, which begat component based development. It doesn’t matter so much what these things are; more important is the fact that they have evolved over many years before revealing the fundamental truth at their heart: that the best way to consider the interfaces between the software elements, is in terms of the services offered each element.

And so, we have an architecture which is service oriented: SOA. Do you see what I did there? At the risk of sounding like a broken record, this is not some invention of software vendors’ marketing departments, but a consequence of how things have happened in the past.

All of which has been seen as a bit of a conundrum in this fashion industry we call IT. One of the biggest issues IT vendors have had with SOA is that it is an approach, not a product: in other words, there’s nothing to sell. SOA has been confused with Web Services, and has suffered the indignity of being nothing more than a ploy to sell Enterprise Service Bus (ESB) software. But still, SOA is an inevitability – as sure as buildings need architecture, so does software.

Back at SOA Impact, then, IBM is indeed correct in promoting the architecture rather than any particular product line. However, IBM has possibly created a it of a hurdle for itself. Were this any other industry, SOA would be taken as timeless wisdom and we would all be free to get on with more current things. But this is the industry of the new – over-hyped promises of something far better than what went before are what sell technology. Can IBM really afford to stick with SOA in the long term?

The answer is, I blooming hope so.

In marketing and PR departments and among some IT journalists, I have heard more than once the idea that SOA is in some way defunct and we need to move on (indeed, we saw this with SOA 2.0 a couple of years ago, which prompted my esteemed partner at MWD Neil Ward-Dutton to implore that we stopped the madness). Such a standpoint is doomed however, as we are dealing with evolution not revolution: while the detail of SOA may not yet be ironed out, the concept is as sound as anything honed over the decades can be.

It does leave IBM with a bit of a conundrum, however. The company currently has its work cut out, and plenty of services upside, from promoting the SOA message. However, at its heart SOA is not particularly sexy and indeed, the better received it is, the less sexy it becomes as it ends up as part of the fabric. That doesn’t leave marketing much to play with.

All the same, the worst thing IBM could do is look for an alternative to SOA. Build on it by all means – with the caveat that it is early days, so it is important not to outpace what is still a fledgling audience. Perhaps one day SOA will become so well accepted that we shall stop talking about it. In the meantime however, of all the concepts that have been touted by this industry, SOA deserves to remain in the spotlight for some time yet.