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:
-
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
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:
-
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 (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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
|