Vendors, analysts and the press are now hyping service-oriented architecture (SOA) as the next great revolution in enterprise computing. And woe unto the CIO, CTO or IT director who does not have at least some kind of SOA pilot program under way, with the promise to deliver a gaggle of “enterprise-level SOA services” just as soon as humanly possible. Indeed many corporate C-level types already contend they are delivering SOA even while their own development staffs might, with all due respect, disagree.

Despite the hype, SOA is not some totally new thing beamed down from a passing spacecraft. It is just the latest iteration in a long-term industry trend to move from building stand-alone applications to constructing new solutions from standardized, reusable software components. Long ago, we started with “functions” that evolved to “subroutines” and “libraries,” then onto “client-server architecture,” “objects” and finally to the present-day notion of “services.”

So, is there really anything really new about SOA? In terms of the time-honored industry hype cycle, probably not. And, to be truthful, there are as yet only a few documented success stories for SOA, and almost none at the enterprise level. Moreover, everyone agrees that, to date, there is still a dearth of mature tools and few universally adopted best practices.

At the same time, just because something is being hyped doesn’t mean it isn’t real. SOA has arisen to address very compelling problems — and opportunities — and these will not go away. Even the most conservative IT organizations have already begun a transition to something like SOA, whether they call it that or not.

The Many Advantages of SOA is a language- and platform- independent approach to architecting enterprise systems. SOA’s main goal is to reduce the enterprise’s functional domain to a set of distinct but interrelated services to be shared by all applications through well-defined interfaces. In the world of SOA, applications are not islands grudgingly connected by proprietary bridges, but by specialized orchestrations of shared enterprise services.

The advantages of such an approach are many, as any SOA product salesperson will be only too happy to elaborate. The advantage most often cited is the rapid development and deployment of new applications through the reuse of available services. Another important advantage is the ability to more easily integrate existing applications by reorganizing their connection points into shared services. And finally, in today’s Internet-enabled world, there is the promise of publishing, and subscribing to, SOA-enabled services across the Internet, a must to support true electronic commerce.

As we noted earlier, the core concepts behind SOA are not new. In the 1990s, when the industry was struggling to agree on a universal standard for distributed computing (CORBA, COM, RMI, for instance), many of the ideas behind SOA were already taking shape. But SOA as we know it today is truly an outgrowth of the (in)famous rise of the Internet. The Internet has blazed a trail that SOA is now positioned to widen and pave. It is short step from a universal Internet messaging protocol to the idea of a Web service. And it is a very logical leap from a collection of such services to the notion of a service-oriented architecture. But the rise of SOA owes much more to the Internet than just a more ubiquitous communications protocol standard.

The Rise and Fall of the Corporate IT Levee

In pre-Internet times, no matter how a business managed its information, it sat behind a levee usually only permeated by paper or people. No matter how sophisticated and efficient its billing system, for example, a given business still relied on salespeople to personally book orders and the postal system to deliver paper bills, invoices and, ultimately, payments.

Not surprisingly, the traditional corporate IT systems grew up almost entirely inside that levee, assuming its existence and, in many cases, even depending on it for support and protection. The epitome of this IT mentality was the “white room,” a tightly controlled, proprietary environment where all the computers — and all the data — lived behind closed doors, totally inaccessible to anyone on the outside. In this sense, most IT departments operated like pre-Katrina New Orleans.

This mentality took a major hit with the introduction of the PC in the 1980s. In the 1990s, as the PC proliferated to customers and various forms of connectivity became common, many IT shops were forced to begin dealing with users well beyond the boundaries of the levee.

In general, however, since this arena had few widely adopted standards, IT dealt with these outside users, often grudgingly, on a case-by-case basis, using a variety of approaches. The levees remained largely in place, even if a few more entry sluices had to be erected. Furthermore, the cost, risk and trouble of erecting such proprietary inlets tended to dampen the business’s enthusiasm for moving in this direction. In this way, before the advent of the Internet, the more ambitious B2B or B2C initiatives that might threaten the levee were quickly downsized or nipped in the bud.

Nonetheless, by the late 1990s, the global proliferation and distribution of both computing and telecommunication MIPs eventually reached critical mass, and the Internet was born. It is neither hype nor exaggeration to say that Internet has generated a sustained series of tsunami waves and hurricanes that have breached all the traditional levees that have heretofore existed between a business and its customers, suppliers and partners.

For the most part, this has left IT departments cringing behind the few storm walls and levees that remain, up their collective waists (and sometimes necks) in floodwaters, looking for some way out. It is quite clear by now that no amount of pumping or sandbagging is likely to save the day, or restore the traditional levees.

SOA to the Rescue?

This is, of course, where SOA comes in. Even the most conservative IT departments are now willing to consider any new approach that promises to more loosely couple, and Internet-enable, their information systems. In a triumph of hope over experience, they want to believe the vendors, pundits and analysts that SOA might just be the silver bullet that can get them out of deep water and prepare them for any future Internet-driven hurricane.

The good news is that it could work. SOA really does hold the potential to help radically restructure the way that IT delivers business solutions. SOA can simultaneously simplify their development of new applications and enable them to more easily integrate and interoperate with other applications both within and outside the enterprise.

In practice, what does this mean? In short, traditional tools are focused on developing and deploying stand-alone applications, while SOA tools are focused on creating and deploying shared services. The challenges of transitioning from the older paradigm to the new one should not be underestimated. Moving to SOA is not going to be like switching to a new database or operating system, which, as we all know, can be daunting enough.

To achieve true business benefits, a real transition means radically changing the way that IT has traditionally done its job, especially the life cycle of that sacred cow, the stand-alone, monolithic IT application. As we all know, in the pre-SOA world, the stand-alone application has ruled the roost. Developed expressly for (and funded by) a single business client, the stand-alone application is deployed and maintained independent of all other applications and tightly tied to a specific computing platform and configuration.

One big problem with this approach is that it results in brittle applications — hard to change and hard to integrate. If a new application needs data or functionality of some existing applications, custom views are carefully and laboriously extracted from those legacy stand-alone applications to meet that requirement. Real sharing and reuse are seldom achieved, and, in practice, are effectively discouraged.

This isn’t news, but the recent need to rapidly Internet-enable business has significantly exacerbated this problem. An Internet-based business has to be particularly nimble, responding to change far more quickly than a traditional business and exposing those changes almost immediately to a wide audience of stakeholders. On the Internet, generating new, improved and highly customized views of its business processes is the rule, not the exception. And those views have to operate — and interoperate — reliably, right out of the box.

There’s no way the old monolithic view of application development and deployment can be stretched to support an increasingly Internet-centric business environment. Therefore, in the post-SOA world, the traditional application is supposed to disappear, or at least shrivel away. Instead, an SOA-enabled shop develops a new or improved business-facing application by configuring and orchestrating a predefined set of independent, interoperable “services” based on a well-defined service-oriented architecture — that is, the SOA. The back-end role once supported by the traditional application, rich in data and functionality, is now broken down into those interoperable, reusable services.

SOA also offers a different model for maintaining and upgrading solutions. When a business solution needs to change, only the lightweight orchestrating “script” must be updated. Meanwhile, service implementations can be upgraded — or rehosted to new platforms — at will, normally without directly changing the business solutions that share them. The shared business services only need to change if something fundamental about the business changes.

Similarly, both applications and services can more easily incorporate outside services, accessing them over the Internet (or corporate intranet) using the same messages and protocols as local ones (e.g., they are location independent). Access to all core business services can be brokered via an extension to the same standardized, distributed, secure infrastructure that supports the enterprise SOA. Ultimately, this can be supported at the global level, enabling widespread e-commerce.

Making the Transition

So, what are we waiting for? Experience suggests that vendors are likely to deliver SOA-enabling technology much more quickly than the all but the most sophisticated IT departments and their business clients can effectively absorb it.

First, let’s sidestep all the tactical debates about which particular standards, products or approaches to SOA are best, or which vendors are likely to win in the emerging SOA marketplace. The marketplace will ultimately decide these issues, and other books and articles will no doubt exhaustively debate them. Instead, we want focus our collective attention on a more strategic question: How are traditional IT organizations going to effectuate their transition to SOA? This question is largely independent of the particular “brand” of SOA that ultimately triumphs.

Given all the current hype surrounding SOA, one might expect that a little Web-surfing would quickly unearth a plethora of good advice about how best to transition your IT organization from no-SOA to SOA. After all, this is one of the most critical transitions most companies will make in the next decade. Unfortunately, our own electronic survey of the available literature quickly shows that it is almost all technical in nature, and most of that is focused on hyping specific vendor products.

In fact, very few of either the SOA vendors or the SOA-friendly pundits have as yet given much more than lip service to the many serious strategic and organizational issues that most IT companies are going to face when they try to implement SOA. But, at a minimum, everyone admits that traditional software development processes and tools are quite different from those that will be required to support SOA.

So, is your organization really ready for SOA? It stands to reason that SOA’s true potential can’t be realized without first asking some difficult questions:

• Do your developers — and your partners — really understand what it takes to create a true enterprise service, much less a whole service architecture?
• What do you need to change about the way your organization funds development projects, collects requirements, specifies solutions, and develops, acquires and integrates software?
• What will the organization look like once it is SOA enabled?
• How will it interact with the business and its various stakeholders?
• Who will own (for instance, specify, develop, control and maintain) the set of shared services?

In our experience, these questions cannot be answered, much less effectively addressed, just by piloting some new SOA products. The transition to SOA is a major endeavor in itself and needs to be approached as a major strategic organizational initiative. Moreover, the transition won’t be completed in a single leap forward. A successful transition will proceed through a series of stages and phases, each leading to measurable improvements in both technical capabilities and organizational effectiveness.

In our columns to follow, we will examine what’s involved in making an enterprise transition from a typical traditional IT (and business) environment to one capable of developing, deploying and supporting a computing paradigm based on SOA. This won’t be a cookbook, since, as we shall see, detailed recipes must be customized to suit each organization’s needs. Instead, we’ll provide a framework and a set of patterns that hold true for almost any such transition and show specifically how to apply them to SOA in your organization. SW

Guttman is an independent IT consultant who has completed dozens of major projects in areas of business and IT strategy and enterprise architecture. He is the author of Developing E-Business System and Architectures: A Manager’s Guide. He can be reached at Michael@guttman.net.

Matthews is widely recognized throughout the industry as one of the foremost industry consultants bringing information technology to meet today’s business needs. He currently serves as vice president with MomentumSI online at www.momentumsi.com. He can be reached at Jason@momentumsi.com