Task: Identify Candidate Services from Existing Assets
Effectively reusing existing functionality can significantly reduce the lifecycle cost of an SOA. This task facilitates such reuse, by identifying candidate services that can be harvested from existing IT software assets.
Disciplines: Service
Purpose
The purpose of this task is to begin the reuse process within an SOA initiative, by identifying candidate services that can be harvested from existing IT assets.
Relationships
Main Description

Reuse of existing IT assets within an SOA has two components: (1) identification of reusable assets and the Capabilities that they offer, and (2) determination of how these assets will be used to realize services that have been selected for exposure.  The first component of this sub-process is performed in this task.  Realization decisions are made within a Service Realization initiative, and are beyond the scope of the present discussion.

In this task, candidate services and flows are identified using Existing Asset Analysis.  The assets examined can include existing systems, such as packaged or custom applications, and industry standards, models, and components. Technical constraints related to existing systems need to be evaluated as early as possible for risk management purposes. Because of this requirement, the related task, Perform Technical Feasibility Exploration, is often performed as soon as possible after or during Existing Asset Analysis.

Guideline: Mapping Existing Assets to Services provides detailed advice for this task.

In this task, the work product slot of [Business Design] is filled by Business Model, which includes business process descriptions.


Tool Mentor: Build a SoaML Service Model Using the SoaML Template is the entry point into a family of tool mentors that collectively describe how to build a SoaML-based service model using IBM® Rational® Software Architect.  This tool mentor provides an overview description of a process for using the tool to create the model.  It includes callouts to several other tool mentors that accelerate Service Identification efforts.

Steps
Identify the existing assets that are to be analyzed.
This can be a major workflow in itself.  One useful approach is to build a context diagram that establishes the functional boundary between the to-be SOA system and the actors outside that system.  Then, examine the current application portfolio to identify the business processes, applications, and data flows that lie within that boundary.
Document the functions of the relevant existing custom systems
Describe the functions of the systems, the events that they respond to, and the data flows that they manage.  Work with the Developer who is responsible for the existing systems, if necessary.  Leverage his or her expertise, so that you can more quickly identify the functions offered by the existing asset.
Perform coarse-grained mapping between existing business functions and the to-be business processes.

This pertains mainly to custom applications.  Analysis of packaged applications is addressed in other steps of this task.

As is further described in Guideline: Mapping Existing Assets to Services, coarse-grained mapping involves three steps:

  1. Understand the business functions supported by each application.  Typically a business function can be mapped to an activity within a business process [Business Design].
  2. Record attributes of existing applications in terms of technologies used, architectural styles, and so on.
  3. Identify applications that perform common services.

Map the useful functions of existing custom systems into new candidate services

In the previous step, you identified existing business functions that could be used to support specific portions of the to-be business processes.  Create new candidate services that are derived from these useful business functions.

Identify candidate services from packaged applications
Guideline: Mapping Existing Assets to Services provides detailed advice regarding this step.
Update candidate service portfolio and service hierarchy
Add the new candidate services to the candidate service portfolio, which is part of the Service Model.   Position them within the candidate service hierarchy, according to your chosen taxonomic approach.
Ensure that non-functional asset requirements are documented.

When documenting Non-Functional Requirements for existing assets, consider the topics described in Guideline: Non-Functional Requirements for Existing Systems

Create an Asset Fit Gap Analysis for each asset that has been mapped to a candidate service.
Create an Asset Fit Gap Analysis for each existing asset that is a strong candidate for reuse.  Creating this document helps you to better understand the goodness-of-fit between the asset and the business requirement that it is being targeted to fulfill.  This insight is used later to determine whether it is cost-effective to use the asset to realize one or more services. 
More Information