Service-Oriented Architecture (SOA) is gaining momentum as a new IT implementation paradigm. Organizations are eager to capitalize on its benefits. However, with many of these organizations focusing too narrowly on project-specific implementations, though, some are at risk of never achieving the full value that the SOA concept could bring them. Their result will be a collection of technology-driven remnants instead of a holistic, business-driven system of integrated services.

When SOA is viewed as a "technology" it is often pursued without a clear understanding of how the resulting services fit as part of the larger enterprise architecture. The solution is to view service orientation as one of many means to conceptualize and deliver holistic enterprise architecture, not the other way around. By doing so, the outcome will reflect the true promise of SOA as a powerful business design paradigm.

SOA Fictions
Narrowly-focused, project-specific SOA approaches are a double-edged sword. While they can produce rapid, short-term value, they often also produce unintended consequences in the form of new silos. It is easy to understand how this can happen. Driven by different requirements, often from different parts of the business, implemented by different teams, at different times, during different phases of tactical decision making, each with there own interpretation of strategy, and during different stages of technological evolution - it is a leap of faith to believe that the end result will be an integrated, aligned, adaptive enterprise. Yet that is precisely what many enterprises hope.

While it is self-evident to many that it is a long-shot to achieve an adequately aligned and integrated enterprise, there continues to be hope among the SOA-faithful that technology and brute-force approaches will save the day. Don't misinterpret this statement as a criticism of SOA. SOA has the best opportunity of any recent paradigm change to profoundly influence the way businesses operate and the way IT participates. Indeed, great strides have already been made as the industry educates itself, adjusts and generally tunes in to the approach. However, like many innovative ideas of the past - such as early distributed computing frameworks, data-driven and metadata approaches, and pioneering object-oriented approaches - there's a risk that hasty and uncoordinated adoption could cause momentum to cool as expectations prove overly grand. To prevent this, it is important to examine SOA for what it is, and what it isn't, and define exactly what it means to the business. As examples, look at these common marketplace perceptions and the fictions underlying them.

Fiction: SOA and Web services are the same thing
While Web services represent the currently accepted (and perhaps best) way to implement a service oriented architecture, it's not the only way. More traditional technologies such as EAI (Enterprise Application Infrastructure) approaches can support the general concepts underlying service orientation. In fact, many 30-40 year old process-control systems and embedded real-time systems were implemented as services. There are even examples of services implemented in COBOL/CICS environments. Service-orientation is a logical concept that can be applied at many levels, not just via a technology such as Web services implementation methods.

Fiction: Just Start Building Services, the Approach Will Take Care of Itself
There is a common belief that there is so much power in the underlying standards, and their loosely coupled formats and protocols, that simply building collections of services that adhere to these standards will lead inevitably to a fully-functional representation of the enterprise. It is a rather large leap to expect that any two services, created at random in an enterprise, would have agreement on concepts as broad as strategic context or as narrow and specific as the meaning and proper use of a data element called "customer."

Deconstructing SOA
The acronym "SOA" continues to trigger an immediate association with Web services, in large part due to the successful marketing by Web services proponents. To truly understand SOA, though, requires breaking this association and examining SOA in a different light. To begin, the term must be deconstructed so that the real meaning behind the concept can be discovered.

First, abandon the term "architecture." Most IT professionals are so comfortable with the tools, techniques, infrastructures, products, etc. that make up an architecture, it is only natural for them to view SOA as an "architecture," with its own enabling technologies, interfaces, standards, vendors, and implementation details. That approach misses not only the larger picture, but also its power.

Services and Service Orientation
Consider, instead, treating "service orientation" as the operative concept. Ignore the "architecture," for now, and examine the system characteristics that the term SOA describes - a "service-oriented" one. To appreciate service orientation, it is important to first have a clear understanding of what is meant by "service," in non-technological terms.

To define it simply, "service" is a task performed by a provider, upon objects, for a client known as a service requestor. Each service has a well-defined interaction with the outside world in the form of input received, output delivered, and objects modified. In software, this interaction can be viewed as its interface. Services, though, are not just software constructs. Humans and even mechanical systems behave in similar ways. Additionally, each service should be expected to satisfy specific performance criteria, often called service levels.

Services, therefore, represent well-defined building blocks (i.e., objects) that can be useful at various levels of abstraction. These range from the top-level of the business, down through human and automated systems such as business or IT capabilities, processes, applications, and their enabling infrastructural and operational underpinnings. Service orientation, therefore, is a defining characteristic of any system designed to be viewed as a service, up to a system as large as an entire enterprise. The enterprise can be viewed as a network of these services.

Service Orientation as a Natural Model for Business
The "business" references in the definition above are significant. While IT professionals tend to focus on infrastructure or other primitive services, the concept of services is surprisingly easy for business personnel to embrace. "Services" have always been a way for businesses to deconstruct what they do, even if they didn't use that specific term (though many did and still do).

One of my favorite examples comes from the first film version of the "Miracle on 34th Street." Early in the film, an overhead shot shows a large room in the department store headquarters with rows of desks. There is constant motion as employees move in and out of the room, dropping off and picking up stacks of paper from the desks. Even without any specific knowledge of what they are doing, it is easy to see that the room is a service. The service being performed is completely contained, has defined inputs and outputs, performs a service function, and (one would imagine) has an expected service level in terms of volume, processing rate and quality. One can easily imagine many other pre-IT examples including such services as "sell a product," "collect payment," "schedule a delivery," or "generate a quote."

The point in telling this story is to raise the question, "What's different about business today?" The simple answer is: nothing. Businesses for the most part operate the same as they always have and services are a natural abstraction of the business.

In many cases, though, the concept of services and service functions don't map to the current way that businesses think of themselves. As a result of years of cross-training by IT staff - through the consumption of too many technical magazines and listening to too many consultants - business people now describe themselves in the context and language of applications, servers, databases, data, and business processes. Attend almost any business requirements session to see this in action. Business people don't list requirements or the services they need, even after pointed questioning from the IT professionals. Instead, they describe the end environment they want implemented, often listing databases, vendors, and platforms by name. This disconnect - between the business and IT organizations, and the systems and their purposes - can be profound.

One of the most significant opportunities afforded by the concept of service orientation is the chance to change the language that IT and the business use to communicate with each other. It is IT's chance to un-teach unnatural technological abstractions in favor of something that drives business and IT onto the same page. The strongest argument for a move to service orientation is to improve alignment between what the business needs, expects, and requests, and what IT can deliver.

Why Service Orientation?
Why, then, is so much market emphasis placed on reuse as a justification for the value of SOA instead of business value? When SOA is equated to Web services, and the subject of these Web services are fine-grained infrastructure services, reuse is an argument that can hold water for cost-justification purposes. With services as business constructs, as discussed above, that argument is not as strong.

The truth is that large, coarse-grained services that are meaningful to the business are not ideal candidates for reuse, at least in the traditional sense of replicated cross-functional instances. The cost-benefit equations often used for software reuse justification break down when there is only one user of the service. Instead, the justification for service orientation must be made at a higher level. Sure, nicely encapsulated services are easier to maintain and safer to test. The real value of service orientation, though, is in the ability to naturally map a service to the business capabilities it supports, and deliver to the business the ability to disassemble and reassemble collections of services to align with changing business strategies. Furthermore, the notion of "software as a service" opens up entirely new avenues to acquire, or to offer to others, a collection of business capabilities. Service orientation, then, is a way to construct a business to maximize the adaptive, agile enterprise. This, in turn, requires an enterprise-wide approach.

Services Orientation, the Enterprise Architecture Way
In the world of IT projects - with their requirements, schedules, annual budgets, monthly progress reports and weekly operating measures - where is the center of gravity for this enterprise-wide approach? Enter "Enterprise Architecture", or EA. The principle objective of the EA function is to work with executive leadership to gain an appreciation for the big-picture enterprise perspective, to analyze the implications of strategy on the various aspects of the business and IT, and to guide each domain toward a target representing an integrated, balanced, coordinated and aligned enterprise, with all the piece-parts optimized to the objectives of the enterprise.

Enterprise Architecture is defined as a strategic management discipline that creates a single, business-driven, future-oriented perspective designed to deliver on the business vision and strategy of the enterprise. That perspective is represented by an integrated view of the desired business processes, information and services, as enabled by the technology. The primary design goal for enterprise architecture must be to enable efficient change in business processes and capabilities through the services that enable them.

In order to fully realize the benefits of services orientation - including meeting the requirements for enterprise strategic alignment, full delivery of the desired business capabilities, and the agility required to change and adapt strategy in response to a changing environment - the enterprise perspective needs to be a part of both strategic and tactical planning processes. If this is the case, there is a lower risk of uncoordinated service creation that can result in additional silos of process, information, technology, and applications.

A detailed description of how to organize and operate an effective EA program is beyond the scope of this article. However, one important element that must be present in every successful EA program is its collection of "roadmap" style documents describing the enterprise journey from its current state to one that fully delivers on the enterprise vision and strategy, known as the future state. These deliverables detail, in the form of information repositories, graphical models, principles, standards, lifecycles and roadmaps - each of the elements of the enterprise and their associated relationships. They also provide a framework for the hierarchy of abstractions that range from the highest level strategic alignment down to the lowest level implementation specifics (see Figure 1). EA work products must be created with a balance of large-scale perspective and lower-level detail appropriate to the enterprise's strategic objectives and its short-term tactical, operational, and pragmatic investment realities.