For decades, IT professionals have put up with the headaches of managing a complex and rigid enterprise architecture that has become a Petri dish for the too-familiar misalignment between IT and the business. Enter service-oriented architecture (SOA), which promises to create applications composed of modular software components that are interconnected through well-defined, open Web service standards. Just as companies moved from mainframe to client-server, so must IT move from monolithic applications to a matrix of loosely coupled Web services that enable the composition and recomposition of business processes.

However while many in IT are familiar with and more than eager to realize these benefits, few understand that getting the big SOA payoff requires a fundamental shift in the design, deployment, management, and governance of enterprise architecture.

Architecture: More Than a Document
Typically, an enterprise IT architecture amounts to little more than a static document that describes an equally static environment. This document is often created in isolation, without significant input from business managers, and usually exists as inert PowerPoint slides or Word pages that development groups rarely reference as they create new applications.

And frankly, why should they? Putting such a document in the hands of development teams as a means of communicating and enforcing enterprise architecture is a bit like asking a construction crew to use a single exterior photograph as a blueprint for an office tower. The finished product may look exactly like the photo, but when those top-floor elevator doors open, can you be sure you're not stepping into an empty shaft?

Even in its most streamlined, efficient state, enterprise architecture is far too complex - let alone important - to be expressed in a collection of documents that no one will read, and that are severely limited in their ability to affect how things get built. Can a set of static documents tucked away in a file somewhere offer any assurance that an organization has anything resembling a true enterprise architecture? Yet how many organizations in exactly that situation are already involved in plans to implement an SOA? How much head scratching goes on at these organizations because their SOA efforts appear to have stepped into an empty elevator shaft?

This doesn't mean that these organizations don't place a high value on enterprise architecture. Indeed, few organizations will be given carte blanche to revamp the entire enterprise architecture around an SOA, regardless of the promised flexibility and agility benefits. Rather than a massive, expensive network overhaul, the SOA rollout will happen incrementally, within the context of funded projects. As the business side requests new applications and new functionality, Web services can be created and reused. In this manner the SOA will emerge over time.

However whether the SOA emerges as a highly organized, loosely coupled collection of services that can be remixed to suit changing business needs, or as a future legacy nightmare, depends on how the SOA integrates with the existing enterprise architecture and its ability to respond to business challenges.

The failure to focus on architecture during this process will ultimately dilute the architecture beyond its ability to have positive impact on the business. It is critical, especially with just such a gradual architectural rollout, that the architecture design exists as more than a static document. It must be a living entity that evolves in coordination with changing business needs. This makes the service-oriented enterprise architecture a perpetually moving target. SOA is about anticipating the future, which is as much about where architecture needs to be as it is about where it is today. That is all the more reason to enact measures to ensure that all concerned parties keep that target architecture in their sights at every step.

Balancing Act: Control and Chaos
Effective enterprise architecture requires a balance between control and chaos. It must be dynamic, interactive, and holistic. It must overcome project myopia, spanning space by connecting projects to each other, and spanning time by ensuring that projects are fully aware of what has already been built, what needs to be built now, and what will be built in the future.

The funded project model for SOA deployment underscores the need for architects to confer on an ongoing basis with business managers in order to understand their priorities, model the architecture to support critical business needs, and clearly illustrate how technical assets and services directly affect the ability of business managers to do their jobs more effectively.

• Architects will have to translate their plans into the bottom-line language of time and money that is spoken by business managers with little technical expertise. Toward that end, dynamic graphical mapping of project and service dependencies will bring the business implications of IT projects vividly to life.
• Only a robust enterprise registry/repository that links the management of services, business processes, and other software assets with business objectives will provide the kind of long-term impact metrics that IT must supply to guide the business-side decisions that will shape the enterprise architecture (see Figure 1).

Creating the target architecture is only half the battle though. An architecture that no one implements is no architecture at all. Ensuring that developers adhere to the target architecture is absolutely critical to a successful SOA. In this effort, the model for application development in isolation is a recipe for disaster.

Bridging the Silos
Organizations that are adopting SOA must systematically bridge the gaps that separate development silos: those groups of programmers working on projects in almost total isolation, who often insist on building everything from scratch. In the past, the effect of this not-invented-here disease - a malady that afflicts so many corporate development groups - was limited to a severe swelling in the amount of time and money a company needed to spend on any given application. For an SOA, the consequences are life threatening: isolated silos are to SOA what kryptonite is to Superman.

Web services are inherently interdependent, and connect with middleware components, legacy systems, e-business applications, and other software assets in the IT environment. Development teams in an enterprise environment are no less interdependent. Unless these teams communicate and collaborate effectively, the out-of-control cost and complexity of the pre-SOA enterprise infrastructure will become a fond memory to those charged with the responsibility of managing and maintaining the service-oriented enterprise architecture.

In such an environment, what is there to prevent the complexity that is the result of the development of duplicate services? What is there to guard against the disastrous potential of changes to existing services, or to other assets and areas of the business on which those services may depend? There is more to SOA, after all, than the services themselves. Effective SOA requires the ability to govern the implementation of services from project to project, across silos, and forward into time.

Once silos are truly connected, IT management and development project leads must establish governance practices and systems that require project teams to follow the architecture, adhere to standards, and ensure that services are in compliance with the SOA. Publishing the architecture in a central services registry is a good start, but IT management can go much farther, especially if it has deployed a robust SOA registry/repository.

No "A" in UDDI
Without a central registry/repository that discovers, identifies, and maps services for reuse - one that understands, illustrates, and manages the relationships between services, policies, applications, components, and all of the other software assets in the organization's overall architecture - services will inevitably end up being developed in isolation and misaligned with architecture, despite the best efforts of IT management to connect the silos.

The UDDI standard is useful for the runtime discovery and management of services and for the support of interoperability, but offers little to enforce and govern the overall enterprise architecture. Beyond UDDI, it is essential to understand the interdependencies between services, architecture and the other software assets in the enterprise portfolio. Without these capabilities, there is no chance of eliminating the project myopia that breeds silos, and no way to present the time- and distance-spanning view of the entire enterprise architecture. In the effort to put the "A" in SOA, it is important to recognize that there is no "A" in UDDI.

Head Start: Manage XSD
A critical but often overlooked element of managing and governing the service-oriented enterprise architecture is the institution of early control of the XSD files that represent corporate data. A service-oriented architecture can easily achieve a level of complexity at which XSD files become nearly impossible to untangle. Client-server projects faced much the same problem because IT departments failed to control database schemas from the beginning. Early efforts to manage XSD files will smooth the road to SOA success.

SOA Reality
As yesterday's monolithic IT infrastructure is deconstructed into a dynamic matrix of loosely coupled services, the realization of the dream of the agile, on-demand enterprise inches ever closer to reality. The most important factor in that transformation is that SOA exists within the larger enterprise architecture. The success of the SOA effort depends entirely on the manner in which the enterprise architecture is expressed, communicated, deployed, and governed (See Sidebar).