Design and develop a more effective SOA, Part 2: Confidently define and design your service-oriented solutions using Rational SOMA 2.9

This is the second article in a five-part series on IBM's commercial solution for service-oriented systems design and development. This article describes IBM's commercially available best practices – Rational SOMA -- for identifying, specifying, and realizing services. It describes both the method – which is tool-agnostic – and specific guidance that is included with Rational SOMA for using Rational Software Architect for WebSphere Software to perform the steps of the method.

13 August 2014 - Updated two broken links in Resources: IBM Practices and Rational SOMA 2.9.


Todd Dunnavant (, Principal Solution Architect, IBM China

Todd Dunnavant is a Principal Solution Architect in the Solution Delivery Assurance team of IBM’s Rational brand. He also is the primary author of the Rational SOMA best practices for service solution design. For the past 14 years, his professional passion has been enabling Rational and IBM clients to improve their ability to deliver business-relevant software and system solutions. His current focal areas of interest are service-oriented systems and collaborative architecture management.

Gary Johnston (, Rational SOA Tools Architect, Senior Software Engineer, IBM China

Gary Johnston is a Senior Software Engineer and SOA Tools Architect in the Rational Software Architect development organization. For the past couple of years, Gary has been working to deliver and enhance support for SOA design and development in Rational Software Architect itself and to better integrate it with other SOA-related tools (both Rational and non-Rational).

13 August 2014 (First published 03 May 2011)


A service solution is a set of service-oriented software assembled to form a composite application -- an application built by combining multiple existing functions into a new application. As was described in the first installment of this series, a comprehensive approach for service solution design must provide the following components:

  • A proven service solution design method. The method needs to have these characteristics and qualities:
    • It is easy to use and understand
    • It provides clear advice on how to start a service solution design
    • It helps users identify the right, business-oriented services to work on
    • It enables the creation of flexible service architectures that can adapt to changes in the business
    • It helps users specify the component implementations that realize their services.
  • Effective tooling that:
    • Automates the approach
    • Helps users keep their service solution design content organized
  • Advice on how to use the tooling to perform the design approach.

IBM's commercial solution includes Rational SOMA 2.9 (henceforth, "Rational SOMA"), which provides the first and third of these components, and IBM Rational Software Architect for WebSphere Software, Version 7.5.4 and higher (henceforth, "Rational Software Architect"), which provides the service design and development tooling.

This article elaborates on the content of the first installment of this series, to provide a deeper description of Rational SOMA.

Rational SOMA overview

Briefly, Rational SOMA is a method for identifying services, specifying them, and making decisions regarding how to realize them. It also provides architectural-level advice regarding service design best practices and specific advice regarding how to perform the method using Rational Software Architect.


Rational SOMA is provided as a website that is published using IBM Rational Method Composer or higher. It is available to users via download (see the Resources section of this article). It also is available to licensees of Rational Software Architect Version 8.0 or greater, as a Process Advisor method configuration.

Purpose, organization, and primary content sources

Article 1 in this series describes the purpose, high-level organization, and primary inspirations for Rational SOMA. Please refer to that article for this overview content.

Rational SOMA details

Rational SOMA includes:

  • Method content that describes how to identify, specify, and make realization decisions for services;
  • A workflow that organizes the method content into a process;
  • Architectural-level pattern descriptions for service design best practices; and
  • Tool mentors that prescribe how to perform the process using Rational Software Architect.

We will first present the high-level Rational SOMA workflow. We then will describe the central concept of the service model and follow that with method content and workflow details. We will end with discussions of the architectural patterns and the tool mentors.

High-level workflow

As is described in Rational SOMA, the method’s task descriptions and activities can be used to support either enterprise-scope or project-scope SOA initiatives. Rational SOMA includes a high-level workflow that is targeted at project-scope efforts. Figure 1 illustrates this workflow.

Figure 1. Project-scoped service solution design workflow
The project-scoped workflow from Rational SOMA includes activities to identify, specify, and realize services, and an optional use case driven business modeling activity to create business inputs for service identification.

The main path through the workflow is illustrated as a sequential series of activities for identifying candidate services, specifying services that are selected for external exposure, and making decisions regarding how the services are to be realized. As Rational SOMA explains, real-world execution of the method is not necessarily linear. For example, some of the lower-level tasks that appear in the "Service Realization Decisions" activity also appear during "Service Identification". Further, work product refactoring can occur at essentially any point in the overall method, as new knowledge is gained regarding the service solution.

Business-oriented service solutions naturally require business-oriented inputs – this will be discussed in greater detail, later. In cases where such inputs are not available, the Rational SOMA workflow includes a light-weight activity, Use Case Driven Business Modeling, which can be used to develop some of the necessary business-related inputs.

Central concept – the service model

In the context of IT application of the service concept, the service model is an abstraction of the IT services implemented within an enterprise. It supports the development of one or more service-oriented solutions. It is used to conceive and document the design of the software services. It is a comprehensive, composite work product encompassing all services, providers, specifications, partitions, messages, collaborations, and the relationships between them. It is needed to:

  • Identify candidate services (that is, capabilities that "might" be implemented as exposed services) and capture decisions about which services will actually be exposed
  • Specify the contract between the service provider and the consumer of the services
  • Associate services with the components needed to realize these services

Figure 2 abstractly illustrates the key aspects of the service model and the relationship between them and Rational SOMA's Service Identification, Service Specification, and Service Realization Decision activities.

Figure 2. Aspects of the service model
The service model is a composite work product that is incrementally constructed across all the major activities of a service solution design project

Method content description

As was described in Article 1, the Rational SOMA method content is organized into four practices, those being

  • Use Case Driven Business Modeling
  • Service Identification
  • Service Specification
  • Service Realization

Each practice includes descriptions and detailed discussions of the tasks, work products, and roles that are involved in achieving that practice's specified purposes. Detailed guidance, in the form of concept descriptions, examples, and task performance guidelines, further illuminate the core method content. A workflow also is provided for each individual practice.

The following subsections address the three core service solution design practices. Please refer to Rational SOMA itself for information regarding the Use Case Driven Business Modeling practice.

Service Identification

This practice describes how to discover and define candidate services for possible inclusion into an organization's service oriented execution architecture. The practice describes seven complementary techniques for identifying services, with each technique attacking the service identification issue from a different perspective. Table 1 describes the seven techniques and the purpose that each plays during Service Identification.

Table 1. Service identification techniques in Rational SOMA
Goal-service modelingEnsure that each considered business goal is supported by a candidate service, and that each identified candidate service supports at least one business goal
Functional model analysisIdentify candidate services using static models of an organization’s functional structure and the business functions that each business unit requires or provides
Business process analysisIdentify candidate services by mapping them to business tasks, roles, and processes found in business process models
Business rule analysisIdentify candidate services that encapsulate reusable business rules
Business use case analysisIdentify candidate services from business use case realizations
Domain model analysisIdentify candidate services that are needed to manage key information elements
Existing asset analysisIdentify candidate services that can be harvested from existing IT software assets

Use of all seven techniques is not mandatory, but doing so can substantially reduce the chance that relevant candidate services have been missed.

Figure 3 illustrates the first level of decomposition in the Service Identification workflow.

Figure 3. Service identification high-level workflow
The service identification workflow includes techniques that take a top-down, business-driven approach and techniques that take a bottom-up, technology-driven approach. Goal-service modeling is used to ensure that each identified candidate service is relevant to the business

As the figure illustrates, goal-service modeling can be used both to jump-start candidate service identification and to ensure, at the end of the overall workflow, that the candidates are business-relevant.

The Domain Decomposition activity in Figure 3 collects various tasks that involve using the business-oriented, top-down identification techniques that are described in Table 1. See Rational SOMA for further detailed workflows that illustrate the time ordering of those tasks.

Similarly, the Existing Asset Analysis activity collects tasks that are performed to identify candidate services using a technology-driven, bottom-up approach.

Note that it is expected that the candidate service model – which is a subset of the service model – will be refactored throughout the service identification workflow. Rational SOMA provides advice regarding some useful refactoring techniques.

Service Specification

This practice describes how to specify services, the interactions in which they are involved, and their realizing elements. When used in the context of a services delivery process, the list of candidate services from the Service Identification practice provides the input to Service Specification.

Figure 4 illustrates the first level of decomposition in the Service Specification workflow. Refer to Rational SOMA for details regarding finer-grained workflow decomposition and step descriptions for each task.

Figure 4. Service Specification high-level workflow
The workflow for service specification includes governance activities, design activities, and tasks to identify and address security threats


  • "Apply Service Litmus Test" is a governance task. The candidate services that were identified during Service Identification are filtered to determine which ones will be specified further and eventually realized as externally-exposed services.
  • The "Specify Services" activity contains the core service specification tasks. The candidate services that passed through litmus testing are detailed. The results include service interface specifications, defined service providers and consumers, and descriptions of how providers and consumers interact to realize business processes and use cases.
  • The "Perform Subsystem Analysis" task is performed to identify the conceptual IT subsystems involved in the service solution, identity their dependencies, and identify the subsystem components that will be involved in realizing the service model. This task marks the beginning of the transition from service solution specification into service realization design.
  • The "Perform Component Specification" task, once performed, results in creating the external and high-level internal details of the software components that realize the services.
  • As an acknowledgement of the importance of security, we provide an "Identify Security Patterns" task that ensures the level of security required by the system.

This workflow borrowed heavily from pre-existing work:

  • Litmus testing, subsystem analysis, and component specification tasks were derived from similar tasks in IBM's proprietary version of SOMA;
  • The detailed sub-process for service solution design owes its origin largely to the IBM Redbook, "Building SOA Solutions Using the Rational SDP;" and
  • The service solution design sub-process was enhanced to use the Object Management Group's SoaML notation and concepts, following the advice provided in Jim Amsden's developerWorks articles on service design using SoaML.

Service Realization

Along with the service model, Service Specification produces logical descriptions of the system components that realize services. The Service Realization practice provides methods to help users decide how to realize these components, using either new-built or pre-existing system functionality. The results of the practice include the following:

  • Detailed designs of the components that will realize the services, ready for implementation;
  • Details of how the components will be integrated at run-time; and
  • Details of how the components will leverage operational resources in the organization's IT environment.

Figure 5 illustrates the first level of decomposition in the Service Realization workflow. Refer to Rational SOMA for details regarding finer-grained workflow decomposition and step descriptions for each task.

Figure 5. Service Realization high-level workflow
The service realization workflow yields detailed designs of the system components that will realize services, plus decisions regarding how the components will be realized using new or pre-existing run-time components

The activity, "Make Service Component Realization Decisions," includes tasks that yield realization decisions for functional services and information management services. Along with these tasks, the activity provides a task for performing technical feasibility studies, to be performed when it is necessary to determine whether an existing run-time component can provide the QoS (Quality of Service) characteristics that are required of a service.

Performing the final task, "Detail the Service Components Layer", results in detailed design content that is sufficient to implement and deploy the service solution into the organization’s run-time environment.

Architectural patterns for service solutions

In addition to the prescriptive method content for service solution design, Rational SOMA describes 12 best practices related to designing and building more resilient, reusable SOA architectures. These are high-level, guiding principles that complement the foundational Rational SOMA method content. These best practices appeared previously in the IBM Redbook, "Building SOA Solutions Using the Rational SDP." The best practices are cast into software pattern format. Each pattern description includes a context, problem statement, description of the consequences of the problem, solution, and solution rationale. These patterns are referred to liberally within the method content, to remind Rational SOMA users of pertinent architectural issues as they use the content to guide their design work.

Figure 6 illustrates the patterns and their relationships. As the graphic shows, the patterns address such topics as:

  • Separating service composition and business process logic;
  • Re-factoring services for improved reuse;
  • Ensuring that services are business-relevant;
  • Using services to manage information;
  • Designing services for easier maintenance; and
  • Using services to represent business processes.
Figure 6. SOA architectural patterns in Rational SOMA
The SOA architectural patterns address concerns that impact the reusability and maintainability of a service solution. Generally, the patterns reinforce each other. Two patterns address the same issue – maintenance of service specification artifacts – using diametrically opposed philosophies, and therefore are mutually exclusive

Rational Software Architect tool mentors

In addition to method content and architecture-level guidance, Rational SOMA includes a comprehensive suite of 19 tool mentors that provide detailed direction regarding how to use Rational Software Architect to design service solutions using the method. Figure 7 illustrates how the tool mentors are organized in the Rational SOMA content navigator pane.

Figure 7. Tool mentors in Rational SOMA
Rational SOMA provides 19 tool mentors that describe how to use Rational Software Architect to design service solutions using the Rational SOMA method

We authored the Rational SOMA tool mentors using a novel approach. The first tool mentor – "Build a SoaML Service Model Using the SoaML Template" – is used to organize access to all the other tool mentors. This tool mentor includes a narrative description of the overall service solution design process. Each of the other tool mentors is hot-linked into the process description, at the point in the process where a designer would be using Rational Software Architect to automate those particular process steps. We believe this approach – having a high-level tool mentor to choreograph access to all the others -- makes it easier for the Rational Software Architect user to understand the context in which the tool is being used and to access the appropriate tool mentor.


To recap, Rational SOMA is IBM's commercial method content for service solution design. It is one of the two major components of IBM’s solution for service design, the other component being the Rational Software Architect modeling tool.

  • Rational SOMA addresses the core service solution design activities of service identification, service specification, and making service realization decisions.
  • Rational SOMA also includes advice for creating business-oriented inputs to service identification, for use by organizations that don’t already have such inputs defined.
  • In addition to design-level advice, Rational SOMA includes 12 best practices, described in the form of patterns, which address architecture-level issues that impact the reusability and maintainability of SOA artifacts.
  • Finally, Rational SOMA includes a tool usage model, in the form of 19 tool mentors that guide the user through how to use Rational Software Architect to automate the process.
  • Rational SOMA is available either as downloadable method content, which can be published using Rational Method Composer, or as a Process Advisor configuration within Rational Software Architect 8.0 and greater.

Our purpose in creating the solution was to enable our customers to design and build service solutions independently. We believe that these solution components, when used in concert, will enable many customers to do this.

Coming up

The remaining articles in this series provide details regarding how to use Rational Software Architect to automate service solution modeling and development:

  • Article 3 describes the Rational Software Architect tooling for using Business Process Modeling Notation (BPMN2) to build business and business process models;
  • Article 4 describes the service design tooling in RSA and how this can be used to build business-aligned service models; and
  • Article 5 describes how service models built using Rational Software Architect 8.0 can be used to accelerate the creation of valuable service solution artifacts. This article focuses on leveraging service models to create SCA-related content.



  • SoaML (Service Oriented Architecture Modeling Language) is a specification of the Object Management Group. SoaML defines a notation and a meta-model for describing and specifying service-oriented systems.
  • Learn more about SOA and service governance in Bobby Woolf's developerWorks article, Introduction to SOA governance.
  • IBM now delivers its commercial best practices content in the form of largely-separable, discretely-adoptable practices. Visit IBM practices to learn more about our Practices.
  • To learn more about IBM Global Business Service's proprietary method for service design and development, read SOMA: A method for developing service-oriented solutions.
  • One of the major sources of inspiration for the detailed service design method in Rational SOMA is the IBM Redbook, "Building SOA Solutions Using the Rational SDP". The latest update to the Redbook occurred in 2008, thus the tooling it illustrates is dated. Nonetheless, this is a good service design resource to have on your "book shelf".
  • Rational SOMA 2.9 borrows much of its approach to service modeling using SoaML from Jim Amsden's 5-part IBM developerWorks series, "Modeling with SoaML, the Service-Oriented Architecture Modeling Language".

Get products and technologies


developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks

Zone=SOA and web services, Rational
ArticleTitle=Design and develop a more effective SOA, Part 2: Confidently define and design your service-oriented solutions using Rational SOMA 2.9