SOA styles

Infoworld’s first SOA Executive Forum rolled out in San Jose, Calif. two weeks ago. This week we held the second installment in New York. At both events it was my privilege to engage some of the industry’s brightest minds in a series of conversations about SOA, and I’d like to thank everyone who participated.

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell

I don’t often emerge from a conference with a single overwhelming insight, but in this case that’s just what happened. The juxtaposition of the two events helped me reconcile a deep schism between two factions, which I’ll call the WS-* and Web 2.0 camps. The argument, which revolves around pairs of opposing and overloaded words — simplicity vs. complexity, decentralization vs. centralization, agility vs. stability — has been going on for years, but it’s gotten really loud in recent months.

Like a pair of bookends, our two keynote speakers neatly bracketed the debate. In San Jose, Motorola CIO Toby Redshaw sketched out a big-bang SOA deployment that was music to the ears of WS-aligned vendors and standards makers. For Redshaw, the key to success is shared infrastructure: a central directory based on the oft-maligned UDDI standard, and an enterprisewide WS management system. Motorola has exposed 180 core services and is beginning to shut down some of the point applications made redundant by them.

At our New York event, though, Harvard Medical School CIO John Halamka told a very different story. His task was to streamline financial and clinical data exchange across New England’s network of physicians, hospitals, and insurers. The solution relies on techniques that Web 2.0 advocates know and love: XML across HTTP, secured with SSL. SOAP and WS-Security are part of the mix now, but the system was up and running before those standards were baked. And to this day, for political and logistical reasons, it remains a loose federation with little shared infrastructure or central control.

The two parables converge on a set of principles on which everyone can now agree. Encapsulate your legacy systems in XML service wrappers. Map your business processes to a set of well-defined XML documents. And conduct interapplication communication in terms of those language- and platform-independent documents.

The two parables diverge with respect to shared infrastructure. Redshaw’s Motorola was in a position to deploy a lot of it early on; Halamka’s NEHEN (New England Healthcare EDI Network) wasn’t. Given that one of my panels at the forum defined SOA as the stuff outside service boundaries — routing, intermediation, policy enforcement, and coherent metadata that collectively bind services into large-scale systems — I wondered briefly if NEHEN should really be considered an SOA.

I immediately rejected that absurd notion. There’s more than one kind of SOA, and the location of services vis-à-vis the firewall isn’t necessarily a useful way to distinguish among them. Political taxonomy makes sharper distinctions. Motorola’s central leadership was able to mandate shared infrastructure from the get-go. For the federated states of NEHEN, shared infrastructure will unfold much more slowly in a series of incremental steps.

In light of these different models, the progress of species of SOA along parallel evolutionary tracks looks like a feature rather than a bug. What matters is that both can thrive in their respective habitats. As we learned this month, both evidently can.