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
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.
Tier 1 ISVs
Tier 2 and 3 ISVs
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
Integrated, multi-module, cross-industry applications for product planning, parts purchasing,
maintaining inventories, interacting with suppliers, providing customer service, and tracking
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
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.
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
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.
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.
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
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
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
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 package's 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 package's 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 facade 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 package's 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
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.