Loosely Coupled weblog

'Unplug and play' with IBM

Implementing an SOA leads to agile application assembly, which is a new approach to application development, maintenance and integration that I like to call 'Unplug and play': "... achieved by unplugging rigid integrations and embracing the concept of continuous change."

I'm glad to see IBM agrees with me, and has decided to 'walk the talk' by moving to a modular architecture for its next release of WebSphere: "... a componentized version of WebSphere, code-named Vela, which the company said represents the next generation of application servers," reports InfoWorld. "... Vela's ability to be receptive to mixing and matching components is intended to encourage corporate users to more quickly gravitate toward an on demand computing environment where shuttling in a variety of applications and computing power is a way of life."

In the same article, IBM's director of WebSphere strategy, Bob Sutor, is good enough to identify the concept of loose coupling as a key enabler: "A lot of the reason why componentization did not work was that the pieces were not loosely coupled enough. There were too many dependencies among the pieces, in terms of understanding how you talk to them as well as the way you connected them," he says.

Interestingly IBM has noticed that a distributed identity management infrastructure is also a vital prerequisite, and will add support for Kerberos and SAML next month. BEA and Microsoft have both recently been thinking the same way, so with any luck it will soon be possible to federate security across all three platforms without having to worry about which one is doing the work. I wonder if this is what Bob has in mind when he says, "The best way to get efficiencies out of [the incredibly heterogeneous environments users have to support] is to make it look more homogenous."

The third of InfoWorld's trio of articles on this topic is an interview with Bob. The above quotes, reused in the accompanying news articles, are the most interesting comments in it, although it's worth a look to see them in their full context. I was more interested to see what he didn't say when he was talking about adoption of web services and SOAs in specific industries:

"... they all have to start standardizing the descriptions of the Web services they expect their companies to use ... This is the standardization of how you talk to services and how they talk back to you ... What we are really talking about here is using SOAs to implement business processes, and that is what you standardize."

Unfortunately, Bob ends up seeming to conclude that business processes have to be standardized, when what he is actually talking about standardizing is the use of SOAs to implement them. That doesn't come across clearly because he doesn't give due emphasis to the difficulty of establishing shared meaning.

Am I nitpicking? No, this is a vital distinction. A business cannot be agile if the only processes it's able to use are completely standardized. But unfortunately, most mainstream enterprise software today relies precisely on process standardization to deliver value.

The purpose of standards in an SOA is to provide a stable, shared framework for successfully sharing services, which can then be combined, on demand, into highly adaptable business processes. Part of that framework is the shared infrastructure that WebSphere is shaping up to provide. But another very important element is the shared meaning that makes it possible to recombine services into new processes at will. That's a capability that IBM doesn't yet have in its arsenal, which is why Bob isn't talking about it very much. But without it, true agility cannot be achieved.
posted by Phil Wainewright 2:55 AM (GMT) | comments | link

Paint it Indigo

Microsoft's strategy for moving away from its legacy object-oriented COM architecture revolves around a project codenamed Indigo. This will form the messaging subsystem of Longhorn, which is the next release of Windows. What is the relationship of Indigo to .NET? Although .NET will continue to exist, Indigo is intended to embrace not only .NET but also all other services, whether they originate from outside Windows or from legacy COM resources. So Indigo is bigger than, and independent from, .NET.

Here, in no particular order, is a summary of some of the more useful coverage of Indigo from last week: