More on IBM and SOA

Further to my previous article resulting from IBM’s annual analyst Software Group conference, here are some further thoughts on what IBM was talking about.

One of the things that struck me, and which I am not sure that I have seen discussed anywhere, is that an SOA (service oriented architecture) solution is topologically equivalent to the earlier hub-and-spoke architecture employed by EAI (enterprise application integration) vendors such as Tibco, Sun (SeeBeyond) and WebMethods. In SOA, all the services connect to an ESB (enterprise service bus) whereas in the traditional EAI environment all applications connect to the hub. So the hub equates to the bus and, indeed, the EAI vendors all support the use of ESBs nowadays as well as the more traditional hub-and-spoke approach.

So, what is the difference between SOA and hub-and-spoke? Simply, that the connections are much more easily defined because they make use of common standards (SOAP, WSDL and the like – not to mention the putative standards just announced by IBM and others for a service component architecture and service data objects) rather than having to be individually crafted for each connecting application. Actually, this is a lie. Standards are enablers not causes. Standards make it more viable for suppliers to develop tools that can automate the development of, in this case, web services.

That’s not the only difference. In traditional EAI what you were doing was connecting applications. With SOA the connectivity is performed at a much more granular level, typically at the level of business processes. This reflects another emphasis at the conference – on business process management as a fundamental element within SOA – if you don’t understand your business processes, how can you determine what you want to service enable?

The importance of business processes to SOA has a further corollary: that SOA therefore predicates business and organisational change. Moreover, IBM’s view is that the move to SOA has to be business-driven rather than IT-driven. The company’s view is that the user needs to select, at least initially, a project that can demonstrate clear business benefit. Once this has been successfully implemented and the benefits proven, then the business can go on to consider broadening the application of SOA in an incremental manner.

Going beyond this, IBM’s view (which seems entirely reasonable) is that if you don’t take this approach then you are likely to fail, either because the IT-driven initial project will not demonstrate any value or because you have taken on more than you can chew.

However, the over-riding impression left by this conference was how big SOA is. I don’t mean that in terms of hype (though that is also true) but about how many aspects of IT it touches. In this article I have not even mentioned the governance of SOA (both in development and deployment) or the monitoring of the environment (using Tivoli) and the composite applications you have created, for example, but these are equally as important to a successful SOA implementation as web services or SOAP. Ultimately, SOA touches the entire software infrastructure of the enterprise. IBM describes SOA as the biggest change to the industry since client/server: I am inclined to agree.