Thought Leadership for the Global C-Suite

The VITO Report

Subscribe to The VITO Report : eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get The VITO Report : homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

VITO Report Authors: Elizabeth White, Liz McMillan, Roger Strukhoff, Timothy Fisher, Ernest de Leon

Related Topics: Java EE Journal, Sustainable Investment, SOA & WOA Magazine, VITO Report


Bringing SOA to Life: The Art and Science of Service Discovery and Design

Practical guidelines and experiences from real-world SOA projects

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 service specification exercise is completed in the last step, the technical service specification, where service mediation platform-specific requirements are spelled out, and other missing technical requirements (such as specific throughput or message sizes) are defined in detail. Proper classification of a service also helps you apply design and implementation best practices to that 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.

More Stories By Manas Deb

Dr. Manas Deb, a senior director at Oracle's Fusion Middleware Group, currently leads strategic engagements operations for Oracle's service-oriented integration solutions. He has worked in the software industry for nearly 20 years, half of which he spent architecting and leading a wide variety of enterprise-level application and business integrations projects. Manas has a PhD in Computer Science and Applied Mathematics, as well as an MBA.

More Stories By Johannes Helbig

Dr. Johannes Helbig is considered among the first to have formulated the concept of a service-oriented architecture, and is father of the SOA program at Deutsche Post, where he currently serves as member of the board and CIO of the MAIL division. He holds a doctoral degree in theoretical computer science and his main interests include IT architecture and IT management.

More Stories By Manfred Kroll

Manfred Kroll is director of Business Architecture and Processes at Deutsche Post's MAIL division. As chief enterprise architect, his objective is to implement a cooperative, SOA-based application landscape pursuing an evolutionary approach. Before joining Deutsche Post MAIL, he held several management positions, most notably at IBM Development Labs and at T-Mobile. Kroll has a Masters degree in Computer Science from University Dortmund, Germany.

More Stories By Alexander Scherdin

Dr. Alexander Scherdin, senior professional for IT Service Design and SOA at Deutsche Post's MAIL division, is responsible for broadening the company's service portfolio and driving forward the definition and execution of its service design processes. Before joining Deutsche Post MAIL, he worked as an IT architecture consultant at McKinsey & Company's Business Technology office. Scherdin studied at the University of Frankfurt, Germany, and holds a PhD in Theoretical Physics.

Comments (1)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.