The problems with IBM’s SOA message

This is the fourth and final set of my observations based on IBM’s recent analyst conference from its Software Group. As I have discussed in my previous articles, SOA (service-oriented architecture) now pervades all of IBM’s software offerings. Is this a good thing? Yes. Are there unanswered problems? Yes. I have discussed the former in my previous articles; I will now highlight the latter.

The first and most obvious problem with IBM’s take on SOA is that you cannot simply go to IBM and say “I want to implement SOA in this part of my business, what product do I need?” Or, rather, you can say that, but the answer you get back will be horrendously complicated. For example, in order to monitor your SOA environment there are two different tools within the Tivoli suite that you might use and a third within the Rational suite—or maybe it was in Lotus, or WebSphere—but in case three different tools.

I know of one organisation that asked the sort of question highlighted in the last paragraph and the answer it got back was that it needed some 30 different products to do the job required. Needless to say, the company in question looked elsewhere.

The point here is that the whole basis of SOA is simplification of the interface and environment. It would help if IBM applied the same principles to its own product suite, which is anything but simplified. It would also help if the company stayed with easily understood and recognised English, rather than trying to invent new terminology whenever it suits them (and, yes, I recognise that this is an American trait in general and is not unique to IBM).

The second problem, which is not specific to IBM, is to do with the cultural change that is implicit in SOA. A service-oriented architecture is essentially a business-driven, as opposed to an IT-driven, environment. This will have a cultural impact on both the business departments involved and the IT department. Now, we all know that change on this scale can be difficult to implement and certainly change management, at least as far as people are concerned (as opposed to software, say), is not the domain of the IBM Software Group. However, it would make sense to have a robust collaboration with IBM Global Services (IGS) to provide such capabilities.

In fact, IGS was represented at the conference but when this issue was raised (not by me) the answer was very unspecific. Whilst it is obvious that appropriate change management must be tailored to the individual company, it would be helpful if a specific programme was in place for that purpose.

These are the main two issues I had with what I heard. All things considered that is pretty good for such an all-encompassing vision.