Guideline: Mapping Existing Assets to Services
This guideline describes how existing custom applications and ISV packages can be mapped into a services model.
Relationships
Main Description

Mapping custom applications into services

Existing applications are mapped into services using a two-step approach:

  • First, map business processes to the portfolio of existing applications.  This is referred to as coarse-grained mapping.
  • Second, map a specific service to a specific function, transaction, or batch process within the legacy application.  This is referred to as fine-grained mapping.

Fine-grained mapping is context-dependent.  For this reason, it will not be discussed within this general guideline.

Coarse-grained mapping

The purpose of coarse-grained mapping is to derive the initial mapping of existing business functions to services.

In order to identify candidate services from functionality in existing applications, the relationship between the business process and existing applications must be understood. This can be described as coarse-grained mapping. This mapping is between the business activities or business processes and the business functions of existing applications as shown below. 

Figure 1.  Coarse-grained mapping between business processes and existing business functions

 

To capture the relationships between business processes and existing applications, perform the following coarse-grained mapping steps:

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

Coarse-grained mapping and application portfolio analysis

Application portfolio analysis is a necessary adjunct to coarse-grained mapping.  Understanding the business value and the technical quality of existing applications helps in creating a transformational plan with highest priority given to the highest value services.  Application portfolio analysis also helps to assess scope and technical risks based on the technical qualities of the application, for example, degree of coupling.

Figure 2.  Results provided by application portfolio analysis

Application portfolio analysis provides scope and boundaries for coarse-grain mapping. For example, applications with minimal business value or low technical value which are targeted for obsolescence would probably not be in scope for candidate service identification.

Application portfolio analysis, if performed, can provide information about existing services for coarse-grained mapping. The output of this combined analysis is candidate services as shown below.

Figure 3.  Application portfolio analysis + coarse grained mapping yield candidate services

Mapping ISV packages into services

Independent Software Vendor (ISV) packages are commonly implemented to enable subsystems and/or service components within an organization. For example, comprehensive Enterprise Resource Planning (ERP) ISV packages, such as those offered by SAP, PeopleSoft and Oracle, are often implemented as complete systems comprising multiple subsystems that fully support one or more Domains within an organization. This section describes a series of steps that will enable the practitioner to identify functionality and candidate services within existing ISV packages.

Note: Because each ISV package is different, it is not possible to develop a detailed prescriptive approach for each one. The following activities describe a generic approach and a generic set of activities that will:

  • Identify candidate services within ISV packages.
  • Identify the high-level characteristics of the ISV packages that will be considered during service realization.

ISV Package Identification

Some ISV packages, such as SAP, PeopleSoft and Oracle, comprise a number of core and optional modules. For example, SAP has a manufacturing module, human resources module, and customer relationship management module. In these cases, it is important to specify which specific modules of the ISV packages are being used. This will result in a more focused analysis that will save time and avoid unnecessary services proliferation.

ISV Package Categorization

Categorization of ISV Packages provides high-level insight into important characteristics that will need to be considered during service realization (this applies to both functional and technical components). ISVs can be categorized as Tier 1, 2 or 3 ISVs based on characteristics such as their core competencies, size and revenue as summarized in Table 1. Note in particular the Technical Impact and Business Impact aspects.

Table 1.  Characteristics to apply to categorize packaged application vendors

ISV Category Tier 1 ISVs Tier 2 and 3 ISVs
Description Large ISVs like the Enterprise Resource Planning (ERP) vendors providing packaged applications that help businesses manage their core resources and operations. Medium to smaller ISVs that tend to offer industry specific vertical business solutions
Characteristics
  • Integrated, multi-module, cross-industry applications for product planning, parts purchasing, maintaining inventories, interacting with suppliers, providing customer service, and tracking orders.
  • Can also include application modules for the finance and human resources aspects of a business.
  • Typically span multiple functional areas and even domains
  • Are often packaged with their own proprietary middleware, security and other technical components
  • Typically enable industry-specific vertical subsystems that support a specific function within an enterprise.
  • Typically have documented business interfaces with one or more Tier 1 ISVs.
  • Usually contained within a business and a small number of functional areas.
  • Usually rely on external, third party middleware and other technical components.
  • Might have their own security components.
Technical Impact Given their large "footprint", these ISVs might have a significant influence on the technical architecture and standards used within an organization. In these cases, these influences are identified and considered during service realization.
The middleware and other technical components, such as authentication and logging, will need to be considered during service realization.
These ISVs typically have less architectural influence within a large organization, but in a smaller, highly specialized industry-specific organization, they too might have a significant influence on service realization.
These packages typically do not provide their own middleware or technical components. They might rely on third-party middleware and technical components - or might rely on those provided by a Tier 1 ISV. Some smaller ISVs might not provide interfaces to technical components.
Business Impact Organizations that have invested in Tier 1 ISVs frequently have a predisposition to leverage these ISV packages to the fullest extent possible. In these cases, there will be a strong propensity to use these existing packages to realize services and also to enable new services. Because these packages tend to enable a narrower scope of functionality, there is less propensity and opportunity to extend these packages to realize new services.
Examples SAP, Siebel, Peoplesoft, Oracle Financials Manugistics, Provia, Evoke/TD

Because ISV packages are used within virtually every organization, most service-oriented solutions will incorporate services realized through Service Components based on ISV packages. Categorizing these ISV packages will enable the practitioner to understand the role and relative importance of these packages within the SOA solution, and also identify technical and functional characteristics that will be considered during service realization.

For each ISV package, an understanding in the following areas is obtained through the analysis performed during categorization:

  1. An understanding of the significance and influence of this ISV package within the enterprise.
  2. The propensity to realize any new services through this ISV package.
  3. The architecture standards and technical components used within the ISV package and their role within the enterprise.
  4. An understanding of the middleware and technical components compatible with the ISV package.

Analyze Options for Service Access within ISV Packages

This step identifies the mechanisms by which functions within the ISV packages can be accessed (that is, technical aspects of the package directly related to service exposure and realization). This information is used to help identify candidate services within the ISV packages (in the next step) and will also be used later for assessing technical feasibility and making service realization decisions.

Several mechanisms can be used to access ISV packages. During this step, each in-scope package is analyzed to determine and describe which mechanisms are available for each package. In general, ISV packages will support one or more of the mechanisms described in Table 2:

Table 2.  Options for accessing ISV packaged applications

Mechanism Description
Direct exposure as a service The package directly exposes functionality using SOA-compatible services, which are typically Web Services. These services might be listed in a catalog. The specific implementation is assessed for conformance to standards and interoperability.
Use of APIs The package provides one or more APIs that might be used to expose services within the package. These APIs might be used directly to expose functionality as a service, or Web Services wrappers or a facade can be developed to enable access to functionality through the API.
Direct data access In the case where no APIs are available, but a service that exposes data managed by the ISV package is required, a service that directly accesses the database used by the package is developed.
Note: While this approach might be technically feasible, bypassing business logic within the ISV package introduces a potential risk of corrupting data or violating program enforced data integrity. For this reason, it is recommended that this technique be restricted to services that perform "read-only" operations. Even so, this approach is still at risk due to potential changes to the ISV's data schema. Use this with great caution.

ISV Packages Service Identification Techniques

During this step, several techniques are used to analyze the ISV packages and identify functionality that can potentially be exposed as a service. Business rules associated with the functionality are also identified. Each technique is used to assess packages from a different perspective, enabling the packages to be thoroughly analyzed for candidate services. Analysis results can be captured in a matrix that relates business function vs. existing system, and in a business rules catalog.  

  1. Review the ISV packages' catalog of pre-defined services

    Some ISV packages offer a catalog of pre-defined services. If so, candidate services for the in-scope business domains and functional areas are identified through the catalog and added to the Candidate Service Portfolio. If supported by the ISV, this technique represents the easiest way to identify candidate services using the ISV packages.

    Note: During service specification, the degree of granularity of these services will be considered as part of making service exposure decisions. Hence, it is important to capture the degree of granularity as a characteristic of candidate services during service identification. It might be necessary to aggregate or decompose exposed services, depending upon the degree to which they align with the services realized within the ISV packages. This analysis also helps align candidate services within the service hierarchy.
  2. Review the ISV packages' APIs

    ISV packages might offer one or more APIs that can be used to access functionality within the packages. Examine these APIs for the in-scope domains and functional areas to identify candidate services to be added to the candidate service portfolio. Because functionality accessible through these APIs will not natively be offered as a service, a service wrapper or façade will need to be developed to expose these API calls as services. The flexibility of this approach enables the combination of two or more API calls within a single service.  This might enable services within the packages to be developed to align with services in the service hierarchy. In this case, the practitioner identifies services within the service hierarchy and maps these to the supporting functionality and API calls within the packages.
  3. Review ISV business process maps and workflow

    The business processes and workflow enabled by an ISV packages might be documented in either a hard copy or in electronic format. These artifacts are examined to identify additional candidate services for addition to the service portfolio. Specifically, this review needs to take an end-to-end view of business processes within the packages, as well as the workflow context in which the process is executed. This enables any related candidate services to be identified.  It also identifies business process and workflow considerations that need to be considered during service realization.
  4. Identify ISV packages' service boundaries

    An ISV package is developed to support business processes and manage data with a scope that is aligned with functional areas and domains. These business components form the "footprint" or "service boundary" for the ISV packages. However, within a specific enterprise, the ISV package might be implemented within a subset of the overall service boundary for that package. By identifying the overall service boundary for the ISV package, the practitioner determines if additional services within the package's service boundary need to be added to the candidate service portfolio. More importantly, the practitioner can determine if new services that are required need to be realized through the ISV packages

    If it is determined that new services are required to enable the service-oriented solution, the practitioner needs to determine if these services fall within the service boundary for the ISV package. If they do, services within the ISV package that support the required functionality are identified and added to the candidate service portfolio. This enables the solution to leverage the full capabilities of the ISV package, and it reduces the risk of developing duplication within multiple systems supporting the same business component.
  5. Analyze data elements controlled within the ISV packages

    The data elements within the scope of the solution are assessed to determine if they are managed within the ISV packages. If data is managed within the ISV packages, other business processes within the packages that read or update the same data are analyzed for candidate services to add to the candidate service portfolio.

    This analysis also reveals related or external processes and interfaces that might be affected by the solution and that must be considered during service realization. These are documented and assessed during service realization.
  6. Analyze ISV security and other technical components

    Many ISV packages contain their own security components for authentication and authorization and might contain other technical components that support functions such as logging and messaging. For each package, identify and analyze these components to identify candidate technical services that can be added to the candidate service portfolio.

    In addition, during this analysis, any issues or constraints that might be introduced by these components are identified for consideration during service realization. For example, the interaction required with the package's security components to access functionality within the package must be understood and accommodated during service realization.

Applying these various analysis techniques will enable candidate services within the in-scope ISV packages to be identified from several different perspectives. It will also identify issues and constraints introduced by the functional and technical components of the ISV packages that must be considered during service realization.

More Information