Задача: Existing Asset Analysis

Identify Candidate Services from Custom Applications

Two sub-steps are used to identify the functionality provided by existing applications. The first sub-step, coarse-grained mapping, maps business processes to the portfolio of existing applications. The second sub-step, fine-grained mapping, involves mapping a service to a specific transaction or batch process within the legacy application. Fine-grained mapping is done during service specification.

The purpose of coarse-grained mapping is to derive the preliminary, i.e. initial, mapping of 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.

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

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

Coarse-grained mapping and application portfolio analysis

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, and to assess scope and technical risks based on the technical qualities of the application, for example, degree of coupling.

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, may provide information about existing services for coarse-grained mapping. The output of this analysis is candidate services as shown below.

Identify Candidate Services from Packaged Applications

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. This analysis will enable the Business Function/System Matrix, Business Rules Catalog and Service Model work products to be populated based on the capabilities of the 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

Ideally, ISV packages for the in-scope domains and business components should have been identified in the CBM System to Business Component Overlay input (or equivalent). This would result in a list of ISV packages that enable functionality within the specific business components in the scope of the envisioned solution. If this input is missing, the ISV packages that support the in scope domains and business components will have to be identified and mapped to business components.

Note that some ISV packages, such as SAP, PeopleSoft and Oracle, are comprised of 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 10. Note in particular the Technical Impact and Business Impact aspects.

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 Business Components and even Domains within a CBM map 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 CBM Domain and a small number of Business Components. Usually rely on external, third party middleware and other technical components. May have their own security components.
Technical Impact	Given their large “footprint”, these ISVs may 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 may have a significant influence on service realization. These packages typically do not provide their own middleware or technical components. They may rely on third-party middleware and technical components – or may rely on those provided by a Tier 1 ISV. Some smaller ISVs may not provide interfaces to technical components. They may rely on third-party middleware and technical components – or may rely on those provided by a Tier 1 ISV. Some smaller ISVs may 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>

Since 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:

An understanding of the significance and influence of this ISV package within the enterprise.
The propensity to realize any new services through this ISV package.
The architecture standards and technical components used within the ISV package and their role within the enterprise.
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 (i.e. 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 may 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 following mechanisms:

Mechanism	Description
Direct exposure as a service	The package directly exposes functionality using SOA-compatible services, which are typically Web Services. These services may 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 may be used to expose services within the package. These APIs may be used directly to expose functionality as a service, or Web Services wrappers or a facade may 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 may 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, and should therefore be used 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 are captured in the Business Function/System Matrix and Business Rules Catalog work products. As with the other SOMA identification activities, candidate services are added to the Service Portfolio and Service Hierarchy.

Review the ISV packages’ catalogue of pre-defined services

Some ISV packages offer a catalogue of pre-defined services. If so, candidate services for the in-scope Domains and Business Components are identified through the catalogue and added to the Service Portfolio. If supported by the ISV, this technique represents the easiest way to identify candidate services using the ISV packages.

Note: During the SOMA Specification step, 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 SOMA Identification. It may 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.
Review the ISV packages’ APIs

ISV packages may offer one or more APIs that can be used to access functionality within the packages. These APIs are examined for the in-scope Domains and Business Components to identify candidate services to be added to the service portfolio. Since 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, which may 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.
Review ISV business process maps and workflow

The business processes and workflow enabled by an ISV packages may be documented in either a hard copy of electronic format. These artifacts are examined to identify additional candidate services for addition to the service portfolio. Specifically, this review should 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 and also identifies business process and workflow considerations that need to be considered during service realization.
Identify ISV packages’ service boundaries

An ISV package is developed to support business processes and manage data with a scope that is aligned with Business Components (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 may 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 should be added to the Service Portfolio. More importantly, the practitioner can determine if new services that are required should be realized through the ISV packages

If it is determined that new services are required to enable the service-oriented solution, the practitioner should 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 Service Portfolio. This enables the solution to leverage the full capabilities of the ISV package, and reduces the risk of developing duplication within multiple systems supporting the same Business Component.
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 Service Portfolio.

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

Many ISV packages contain their own security components for authentication and authorization and may contain other technical components that support functions such as logging and messaging. For each package, these components are identified and analyzed to identify candidate technical services that may be added to the Service Portfolio.

In addition, during this analysis, any issues or constraints that may 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.

Ensure Asset Non-Functional Requirements are Documented

When documenting Non-Functional Requirements for existing assets the following key topics need to be considered.

Exception Handling - We need to understand how exception handling works today. In batch processing, when exception occurs, the program abends (abnormally terminates) and produces a core dump. The programmer is required to look at the core dump and figure out what needs to be done. This may not be acceptable. One would need to figure out what needs to be done, for instance, and how to integrate with exception handling framework.
Process and Data Distribution - We need to examine where the data and process are executed. CICS application executing on one machine may send a request to another machine (also known as function shipping in CICS) or remote call data on another machine. We may like to consider going directly (JDBC to DB) to remote machine where the process or data is running, instead of using the connector which goes through the JDBC to DB.
Data Availability - If we have customer file in VSAM which requires, say, a 4 hour maintenance window, then we can't support 24/7 customer service. We would need to consider a new storage solution.
Authorization/Authentication - Many legacy applications have authorization and authentication mechanisms in the application code. This would require migrating user access management to federated managed environment supported by best practices.
Staging Delays - Typically batch programs run once a day in the night. If requirements are to run the program more often, then we will have to modify the schedule program to change the frequency.