Taking a New Tack With SOAs

Few phrases have seized enterprise mind share to the same degree as "service-oriented architecture," or SOA. Buyers want to spend money building SOAs, and vendors want to position themselves as being part of those plans. As is so often the case, its enterprise developers who are on the grinding edge of the resulting phenomenon: Its the application development managers and teams that must find the sweet spot where enterprise desire intersects with vendor reality.

Impelled by the combination of technology push and management pull to "do services," developers must be wary of the common pitfall of using new tools to do old tasks. The high-buzz enabling technologies of SOA—Web services, XML and multiple middleware initiatives—can be used to liberate enterprise IT from sluggish, brittle, costly systems. They can also be used to build the next generation of ... brittle, slow and costly systems.

Its far from a novel idea to visualize enterprise IT as a dynamic confederacy of services rather than a welded-together structure of tightly coupled IT assets. The "blackboard" systems of artificial intelligence researchers in the 1980s and the distributed object protocols such as CORBA that were hot topics for enterprise IT in the 90s all had the common goal of building systems that revolved around what was done rather than what was doing it.

Major recording company uses SOAs as part of its Web strategy. Click here to read more.

What gets the SOA pot perking now is the confluence of cheap bandwidth, commodity processing power and violent agreement on nonproprietary standards on the technology side, combined with newly vigorous demand for an IT strategy that serves the business mission rather than forcing the business into the mold of the technology.

But if business wants to drive the definition of future IT direction, then business-unit managers must be looking through the windshield as well as seizing hold of the steering wheel. The price of using SOA technologies without an overall SOA buy-in from business units may not be apparent in the short run, but it will become painfully clear down the road when expected payoffs of business flexibility and money-saving code reuse do not live up to expectations.

To follow the forward path to liberation—rather than the circular path that repeats past mistakes—its certainly useful to master new standards, skills and tools. But its essential to develop and maintain a clear understanding of the difference between the parts (that is, the component technologies of SOA) and the whole (that is, the mission-driven and highly adaptable IT architecture that they can be used to create).

Its an error, in particular, to think that an SOA can be built only with the Web services technology portfolio, despite the similarity of terms. The most successful SOA deployment is most likely to combine Web services pilot projects with the simplest possible interfaces to mature legacy systems.

Its an even bigger error, though, to think that an IT architecture based on Web services will be, by definition, an SOA.

Next Page: What SOA is not