While Moore’s Law and fierce competition among vendors virtually guarantee that your IT dollar will continuously gain in purchasing power, don’t let the good deals blind you to an underlying truth: the complexity of what you’re buying may be no bargain at all. In a recent study of more than 20 large enterprises, Boston Consulting Group found that as time went on and these large companies acquired an expanding arsenal of IT, far from gaining economies of scale they were in fact left with “diseconomies of complexity.” Think of it as scope creep on a macro level, as a glut of homegrown and packaged software, hardware, network capacity, and sundry other aspects of IT become ever more costly to maintain, impede new projects, and hamstring companies’ efforts to respond to changes in the business climate.
This complexity crisis is a key selling point for vendors of utility computing (see “The Meter System,” Summer), and in fact most companies in the IT world now emphasize simplification as a selling point. But as IT is called upon to build new applications and extend old ones to the Web, support ever-shifting business strategies, outsource this process or that, accommodate mergers and acquisitions, meet regulatory burdens, and, of course, work faster within tighter budgets, companies may not be able to spend their way toward a brighter future. New thinking may be called for, a new way to frame IT strategy that provides a handle on complexity while improving ROI and better aligning IT activities with the enterprise as a whole.
That, at least, is the argument made by proponents of service-oriented architecture, or SOA. While the term underscores the IT industry’s continuing inability to concoct catchy phrases, don’t let its clunkiness lead you to believe that it can be left solely to the IT department. SOA promises a more momentous shift in business technology than client/server or even Web-based computing. “This is a significant and big movement within IT,” claims Ron Schmelzer, senior analyst at research firm ZapThink. “This is the maturing of an industry, with competitors agreeing on some important standards that will help them all accommodate each other.” Even Microsoft, he points out, is throwing its weight behind the standards that make SOA possible.
Traditionally architected IT systems tightly intertwine so many aspects of the business processes they automate that making even simple changes to some facet of the operation is enormously difficult. Similarly, it’s difficult to get several systems — each originally installed, potentially, by a different business unit pursuing its own tactical goals, with no coordinated planning — to share their data or cooperate in executing complex business transactions. Either a company springs for a costly integration project or its employees cope by opening different applications on the same crowded PC screens and flipping back and forth between them. There are some clever new workarounds (see “You Make Me Feel Young Again“), but while they can help extend the life of older applications, they can’t address the larger risk of an entire IT system collapsing under its own weight.
Not so with the new architecture. Ongoing, incremental, unanticipated change is its raison d’etre. SOA calls for enterprises to create, acquire, and make use of software functionality in the form of easily containable and reusable services that are easily joined to create useful and complete applications. In other words, monolithic gives way to mix-and-match, as Lego-like building blocks of software are recombined in almost endless combinations. An individual service can handle anything from a frequently invoked IT-level task such as converting dollars to a foreign currency to full-blown business processes such as scheduling a factory assembly line. Each service is a self-contained chunk of functionality or process that can be called into action by traditional computer programs and other services. Indeed, many services will end up being composed of other services, which in turn may contain still more, and so on.
While this emerging category of IT services is based on standards, they are defined in purely functional terms, without reference to any details about how or where they are executed. That, in theory, makes them easy to stitch together, pull apart, reconfigure, reuse, and even replace — again and again, any time a company wants to change a business process. This is possible because these services and the functions they perform are not nearly as tightly bound together as they would be in traditional software. Instead, as techies put it, the services are “loosely coupled.”
This approach represents the latest attempt to create reusable software. Once a service has been developed, many different applications can employ it at the same time. Reusing software with older techniques and now with SOA has saved AXA Financial some $55 million in development costs during the past 15 years, according to Don Buskard, senior vice president and CTO. AXA has built a user-authorization service, for instance, that all of its approximately 25 applications make use of. “Our legacy systems are like big gears with big teeth, while our customer-facing applications are like small gears that turn faster,” says Buskard. “We need to connect them, and SOA lets us do that.”
So far, SOA is making headway at large companies such as AXA, Boeing, Merrill Lynch, The Hartford, and Pfizer, where savvy IT staffs are building strategic service frameworks and strictly enforcing their use. Unfortunately, rogue business units in many companies have begun to use Web services, the dominant technological underpinning of SOA, to quickly connect disparate software programs. Forgoing the planning of a true services architecture, which addresses both business and IT goals equally, these companies may save some money in the short run but will find it harder to reap SOA’s full benefits.
“You end up with what I call meta-spaghetti,” says consultant John Hagel — an incoherent mess of services that are difficult to reuse and generate escalating maintenance and support expenses. That’s because while individual services may possess remarkable plug-and-play and reuse capabilities, companies are best served by developing them with some sort of big-picture view in mind versus endless ad hoc development. If three different business units build or buy a service that wraps some level of security around a given process, for example, that’s potentially far less efficient than the company agreeing at a high level how security will be addressed. Hagel says business units aren’t always at fault: if IT is slow to develop an SOA and business units see quick payback from Web services projects, they may feel compelled to forge ahead.
Virtually every major player in the computer industry, including IBM, Microsoft, Oracle, and SAP, is aggressively pursuing the SOA vision, while a number of early-stage firms are scrambling to supply the software development and management tools needed to build, deploy, operate, and maintain SOA-based applications. Centrata and newScale, for instance, provide software that IT shops can use to present menus of well-defined business services for business units to choose from. Blazent, Collation, mValent, Relicore, and Troux Technologies provide tools for managing an enterprise’s many hardware and software elements with an eye toward maintaining the performance levels of individual IT and business services.
Internal development isn’t the only option. Already, such software companies as Talaris, a start-up in San Mateo, California, are coming to market with products built around Web services. Talaris provides a platform for employee business services such as travel arrangements, allowing the employees of client companies to make a range of reservations over the Web, change them on the fly, and have all the details about them sent to the client’s internal systems for budgeting and other purposes.
By building its system from Web services and related components, Talaris can respond instantly to new business conditions. If a client decides to change preferred airline carriers, for example, or wants data about travel expenses delivered in a different way, or if the hotels, airlines, and rental car companies make changes to their own policies and procedures, Talaris can make the necessary adjustments far more quickly than it could if its software had been developed via traditional coding methods.
Whether building or buying, SOA will require some major rethinking about IT strategy. As Hagel and his associate John Seely Brown point out, while initial steps with SOA and Web services aren’t particularly disruptive, to make the most of the technology, companies will have to move away from centralized control toward “federated” decision-making. “This is particularly true because much of the business value of Web services and SOAs is coming from connections established across enterprises — for example, in supply-chain or distribution-channel management processes — where there is no single decision-maker,” says Hagel.
Burned by botched projects in the past, companies now try to avoid similar missteps by carefully planning and specifying the goals of a given software initiative up front. But that misses the greater potential of SOA, which can provide far more flexibility and responsiveness as business needs change and can link multiple enterprises far more effectively than current methods of integration. Even if some aspects of the technology behind SOA have yet to be clarified, a focused discussion among C-level executives about its potential benefits should not be put off.
John Verity is a freelance writer in South Orange, New Jersey.
SOA at a Glance
Eases development, maintenance, and integration of large applications.
Allows companies to reconfigure applications without rewriting much code or changing databases.
Promotes reuse of business components and data in multiple applications and access channels (such as mobile, Web, desktop and batch).
Difficulties associated with reusing services among disparate development teams.
Doesn’t eliminate the need for integration technology to cope with differences between applications.
Many application-specific services can’t be reused.