This top-down approach to service discovery can be complemented by two other approaches. Tracing business processes, following their key interactions with their business environment, and grouping similar functionality can lead to service candidates potentially overlooked by a pure top-down approach. This business process-driven approach can provide a sanity check for completeness and give a first indication of the reuse potential of specific services. However, it requires some degree of caution: different business processes (potentially defined by different business people) often feature different semantics for the same (or similar) concepts. Our experience shows that a thorough and rigid analysis of business semantics (including translating or even harmonizing business terms) is a key prerequisite to achieving a working service portfolio. Note that this approach alone may easily lead to a too fine-grained definition of services.

Additionally, a usage-driven approach to service discovery looks for which IT infrastructure (such as mainframe or legacy) application functionalities and data have been used by business applications to date, wraps service interfaces on them, and uses these services for future business applications. While this so-called bottom-up approach may complement the two other approaches for service discovery, we believe that the lack of semantic harmonization of services will not lead to a sustainable SOA transformation. We'd recommend this approach only as a starting point - for example, to prove the general working of an SOA in a political environment.

Further, we suggest starting service discovery with a small investment in creating conceptual services (for example, only specification but no realization) that combines the aforementioned approaches, and start with actual service implementation in a step-wise fashion, strictly based on business priorities and business cases for individual projects. Business analysts and enterprise business architects obviously play a major role in the business service discovery phase.

Making Change Happen: Enterprise Architecture Transformation Through SOA
Building the Service Portfolio
At Deutsche Post, service discovery yielded a portfolio of nearly 100 business service candidates (each, on average, featuring 5 to 10 service operations) that were subsequently prioritized by factors such as business value, reuse potential, and IT complexity reduction potential. These candidates provide the baseline for an ongoing service portfolio management process that refines the roster of candidates and triggers detailed specification, implementation, reuse, and life-cycle management of specific services.

There are many important issues to deal with while building up a service portfolio, such as service ownership, funding for creating and maintaining services, and life-cycle management. Based on the balance between focusing on SOA services and focusing on project execution, different service acquisition styles can be recognized. For example, one style might undertake an enterprise-wide effort to create or acquire most of the potentially useful services and then start a series of SOA projects that would implement (and use) them. This more services-focused approach aims at first creating a rich service portfolio but involves solid, long-term strategy and some degree of up-front investment (most notably for service design methodology, as well as for a service mediation platform). Another, more projects-focused approach would give priority to building services as required by some projects without much emphasis on how they might be shared. This approach would provide short-term returns but could hamper long-term SOA benefits.

From the beginning, Deutsche Post has emphasized an evolutionary approach for architecture transformation in accordance with SOA principles. This managed evolution approach aims to define smaller IT projects with positive business cases and limited scope, so as to provide short-term business benefits (tactical aspect) while complying with a target application landscape (the SOA blueprint along the business domains) defined at the enterprise level. These projects must have a business owner and will be conducted anyway, with or without an SOA. However, by identifying the services that could be either implemented or reused by a project, the managed evolution approach creates a desirable balance between the services-focused and the projects-focused approach. Each project will thus create business value and contribute to the evolution of a flexible IT landscape based on a broad service portfolio (see Figure 4).

Specifying Services
Additional refinements pertaining to various characteristics of this service are required for each candidate service to be implemented by a project. Service specification at Deutsche Post has three steps. The first step is taken during the service discovery phase, rendering an enterprise service description in the context of Deutsche Post's enterprise architecture model. This enterprise business object and service model describes the logical service architecture view and contains domains, business objects, and services. The services are described as interfaces in this model (UML is used as a formal language), while the description of service operations refers to business objects and other data types in the model.

The second step, the detailed business service specification, includes refining the service interface and taking specific aspects of the IT project (such as potential limitations of the service scope) and then realizing or acquiring the service under consideration. Business service specification is critical in the service design processes, as these specifications are the essential communication method for all parties interested in the service. You should consider the following key categories of information while creating service specifications:

• Definition: Service and service operation names, input and output parameters for each operation, admissible invocation styles (such as synchronous or asynchronous), and service classification (such as business, technical, or infrastructure; or process-oriented, business logic, or data access).
• QoS/SLA: This category has information on the service's performance quality, including useful details on load versus response times, availability and fail-over responses, and possible SLAs.
• Constraints and Policies: This includes pre and post conditions relevant to the service invocation, admissible/expected ranges of input/output parameters, including error returns, and particular sequences in which operations should be invoked. Security guidelines and other essential policies can also be included here.
• Ownership: Information on those who own or maintain the service.
• Release Information: This groups status or planning information about past, current, and planned versions of the service, plus information on any interversion compatibility-related issues.
• Operational Behavior and Usage Patterns: This category, which is particularly helpful for complex or nonobvious services, should provide information about different and recommended ways to use the service.

The functionality, quality, and policies that govern the service render an agreement between the provider and the consumer, the so-called service contract. Currently there are no industry-wide accepted standards for service specification. However, WSDL and UDDI are becoming the de facto standards for describing and publishing the basic service definition. Tests using Web Services Interoperability (WS-I) specifications are also becoming popular with services aimed at wider reuse.

Specification iterations produce finer and more concrete details about the service interfaces and functionalities, thus making the service more flexible and cost-effective by incorporating present requirements as well as projected future needs. Service specification iterations typically require close collaboration between business service owners, business analysts, and technical analysts.