In a service-oriented architecture (SOA), a service is a unit of work performed by a service provider to achieve desired results for one or more service consumers. A service provides a function that is well defined, self-contained (for example, loosely coupled to its environment), described solely by its interface contract and behavioral attributes (for example, it hides implementation), and located anywhere on the network.

Essential components of an SOA - such as a service provider, service repository, service mediator, and service consumers - all rely on service definitions as the key element to describe, access, transport, and understand services.

Modern SOA as a pattern for transforming enterprise architecture is still emerging, as are the strategies for service discovery and design. At this juncture of SOA's maturation, it's highly useful to consider concepts and practical experience gleaned from serious and substantial SOA implementations. In this article we provide both. For various aspects of service design activities, we discuss general considerations that are often motivated by well-accepted software engineering ideas. We also describe the experience of Deutsche Post, Germany - one of the world's largest global logistics service providers - where SOA concepts have been widely adopted at the enterprise level.

SOA at Deutsche Post is business focused. Several SOA-specific processes and methods have been established to put the promised benefits into practice. Further, a highly sophisticated, enterprise-quality service backplane called SOPware (service-oriented platform) that leverages Oracle's Fusion Middleware Suite provides the supporting infrastructure for business-service mediation. Thus, business units don't have to worry about the technical details of service implementation and provisioning; instead, they can quickly and easily assemble high-level business services and processes.

This article focuses on the crucial aspects of bringing SOA to life: how to establish business ownership, how to discover and design services, and how to foster an SOA-based enterprise architecture transformation.

The Starting Point: Service Discovery and Portfolio Management
Business Services vs Technical Services
The principal attraction of SOA is its ability to drive IT evolution through business and to enable better business operations through a more flexible IT. While the basic concepts of SOA can be helpful to build more efficient IT operations, the larger benefits of SOA are obtained when business operations can quickly build competitive business applications and make such applications resilient to change. Consequently, services used by high-level business processes, which we call business services, are the main focus of this article. Technical services, in contrast, are typically embedded in the infrastructure that supports these business services. As important as these technical services are, a good SOA implementation should clearly separate business from technical services.

To realize the full transformation potential of an SOA, business people must take responsibility for identifying business services and describing their characteristics. To that end, several enterprises, including Deutsche Post, are using the concept of business domains to establish business ownership.

Establishing Business Ownership for SOA
To create a common language for business and IT people to discuss potential services and to foster ownership for specific business services, it's wise to look at the fundamental structure and relationships defining the business (for example, a customer buys a product, or an invoice is sent to a customer). Here, the scope of an organization's business is first factored into business domains, which are essentially blocks containing closely related functionality and data, such as customers, products, and contracts. In order to design a domain landscape that renders the benefits of long-term stability and thus provides solid ground for introducing SOA at all levels, it's important to understand how a specific enterprise conducts its business (see Figure 1).

Practical experience at Deutsche Post shows that identifying core business objects and their relationships provides a suitable first iteration of constructing the domain architecture. Deeper analysis of the business processes and their interactions will lead to more precise domain descriptions, as well as the definition of subdomains for some major domains. We strongly recommend checking the robustness of the domain architecture by mapping it against actual and potential future business scenarios.

Designing business domains must be based on deep business understanding, but it also requires some gut feeling. Let's consider two domains: customer and customer relationship. The first mainly manages key customer data required by most other domains, while the second tracks various aspects of the ongoing customer relationship. These domains may seem strongly related at first, particularly because both deal with customers and the domain names sound similar - so why not combine them into one? A close inspection of the fundamental business relationship reveals crucial differences. The customer domain provides information that changes relatively infrequently, but it needs to provide a 360° view of all aspects of a customer and is used in a similar fashion in most domains. The customer relationship domain, on the other hand, provides functionality that has a broad variety and changes frequently - as often as the customer has some dealing with the company and as the CRM strategy of the company evolves. Business people responsible for customer relationships often use the information quite differently - for instance, some use it for real-time cross-selling while others use it to render better customer service. Thus, choosing separate domains for customer and customer relationship is well justified. (For other examples of domain architecture in mobile telecom and in banking, see the fourth and fifth entries in the References section.)

This example points to another important consideration: to use SOA to transform an enterprise IT landscape, business people must take ownership of business architecture. Business owners are responsible for the scope of the domains and for providing ideas for those business services that their domains provide, as well as for identifying requirements for services that their domain needs (which are, in turn, provided by other domains). This establishes a federal business-IT governance, including clear definitions of data ownership. At Deutsche Post, enterprise architects and service designers from the business-IT organizations help the business owners work out the details; however, the final responsibility lies with the business side (see Figure 2).

The business domains, as well as the business services, establish an abstraction layer between the process architecture and the application architecture of an enterprise.

The benefit is clear: by decoupling processes and applications through domains and their associated services, change cycles can be managed independently. IT systems (both on the application and the infrastructure layer) may be changed or replaced without affecting business processes, as long as the service contracts are kept stable. Conversely, business processes can be changed or augmented relatively easily when many of the building blocks (the business services) already exist, waiting to be reused.

Service Discovery
While in some ways services are similar to components, they are also similar to mini-applications that must be managed in a similar fashion to applications. As shown in Figure 3, Deutsche Post defined a set of five service design processes that provide a grid for creating and evolving the service portfolio - these processes have general applicability in any industry.

The first step of creating and managing a business service portfolio is service discovery. In order to look for a candidate set of services that a domain should provide, you can investigate the ensemble of business objects and their relationships. Business objects (such as customers, invoices, and addresses) are not IT objects, but entities required to do business described solely in business terms without reference to the specifics of any IT system. For example, one of the key services of the domain customer is likely to be CustomerInformation, and the elementary service operations associated with this business service are likely to be CRUD (create, read, update, delete) type. However, more complex functionality that combines several basic service operations,may also be associated with this domain. For example, a customer domain may host a CustomerAddressConsistency service, encapsulating the check for existence and proper name of the customer, as well as verifying (and potentially rectifying) her address. Other interesting service candidates may be found by looking at specific combinations of key business objects (such as looking at contracts and their associated invoices).