COTS product integration: An architectural approach http://www-128.ibm.

com/developerworks/ibm/library/ar-cotsint/

COTS product integration: An architectural approach

Tips to maximize the purchase and integration of COTS

Level: Intermediate
Benjamin A. Lieberman, Ph.D. ( blieberman@BioLogicSoftwareConsulting.com), Principal Architect, BioLogic
Software Consulting, LLC
22 Aug 2006

Purchasing and integrating a commercial off-the-shelf software (COTS) product can provide substantial
benefits to your development project. It can also lead to massive cost overruns, user dissatisfaction, and even
project cancellation. There is no single "silver-bullet" that you can apply to ensure that COTS product
integration will go well, but certain best practices can increase the likelihood of success. In this article, you
learn how to apply architectural approaches to improve COTS product implementation.

Introduction: The history of COTS

The practice of building systems from previously constructed commercial products has a long history. Indeed, such
mass-production techniques facilitated the Industrial Revolution by using the power of specialization. Each element of
a system could be built independently, and then assembled into the whole. The tremendous advantage in using generic
components is measured in terms of development cost, time to market, and overall system reliability. Using commercial
components also transfers much of the project risk to the component vendor for that part of the overall system.
Development resources can then be focused on specialized business tasks that add value to the delivered system.
Software development has likewise gained tremendous benefit from using COTS components and subsystems.
Consider how many software systems use a commercial database product such as Oracle or IBM® DB2® Universal
Database™ to store persistent data. Who spends time and money redeveloping database engines each time a data store
is required? It is far more effective to purchase a generic data-management system and configure it for a specific need.
This article discusses the architectural issues associated with developing software systems that integrate COTS
products. You'll get the pros and cons of using COTS products, learn the ways in which COTS products can interact
with a system, and discover techniques for avoiding the top three pitfalls of using COTS products in a development
effort, as shown in Table 1.

Table 1. COTS challenges

Challenge
Sensitivity to vendor
modifications and release
schedules
Vendor lock-in (entanglement)
Deployment complexity for
installation and configuration
Description
Vendors control the functional roadmap and release schedule for their products.
Consequently, customers must be prepared to deal with new releases, patches, and functional
changes.
Unless they're extremely careful in developing their system architectures, customers can
become tightly dependent on a particular vendor's product or component (for example, billing
engines).
Installation of COTS components can involve significant deployment and configuration
issues that must be considered early in the product selection process.

Using COTS components in software systems

Several kinds of COTS components are typically used in software systems:
Infrastructure. Libraries, frameworks, networking components
Application support. Billing engine, relational database, application server
Customizable application. Vitria, IBM On Demand Business solutions
Services. Weather reports, maps, reference information, translation
Embedded systems. Cable set-top box, instrumentation, device controllers

1 of 5 8/22/2006 3:27 PM
COTS product integration: An architectural approach http://www-128.ibm.com/developerworks/ibm/library/ar-cotsint/

Hardware. Actuators, motors, displays

Each of these products and services provides specialized support for the development effort, and each requires a
specific architectural approach to mitigate COTS component pitfalls. Four general techniques work well in dealing with
commercial product integrations:
Use an executable architecture.
Create wrappers around COTS products.
Use simulators to test the product.
Develop prototypes as proofs of concept.
Use an executable architecture

This approach creates a working system with minimal functionality to reduce technical risks and ensure compatibility
with requirements. Creating an executable architecture is effective with all forms of COTS products in which the
interfaces and functionality are exercised. The downside of this approach is the need for a fully working system --
albeit an incomplete one. If the COTS product is incomplete or incorrectly installed or configured, it won't be possible
to show a full execution path.
Create a wrapper

Wrappers are code constructs that hide the implementation details beneath a stable interface. Creating a wrapper around
a potential COTS product provides a buffer against vendor changes in either the interface or the functionality. Doing so
also provides a way to test the solution prior to full COTS product availability. You can provide the wrapper with stub
methods that return expected values, thereby allowing development of other parts of the system before the COTS
product is selected or delivered.
Use a simulator

A simulator provides a testing environment that appears to be the same as the final production system. Using a COTS
simulator, you can develop and test your integration plan without installing a full version of the product. For example,
whereas a full billing engine may require multiple mainframes for implementation, you could simulate such a system
on a single server.
Develop prototypes

A prototype represents a throw-away development effort to provide "proof of concept." With COTS integration, you
often create a prototype solely for the purpose of deciding between competing products. The prototype then provides
guidance in the creation of the final system architecture.

Integrating COTS products with your software system

Regardless of which type of COTS product you select, you must have some form of integration with the full software
system. Consequently, the best way to mitigate problems with integration is to integrate early and often, which means
using the best practice of iterative development to ensure that the COTS product works correctly with the system
throughout the full development life cycle, including final deployment (see Figure 1).

Figure 1. COTS integration cycle

In the Plan stage, you plan the next iteration of development, including meeting with the key system stakeholders and
reviewing the goals for the iteration. In the Gather phase, you evaluate the technical risks, create a design, and consider

2 of 5 8/22/2006 3:27 PM
COTS product integration: An architectural approach http://www-128.ibm.com/developerworks/ibm/library/ar-cotsint/

trade-offs. In the Assemble stage, you integrate the system with the COTS components you defined in the Plan stage.
Finally, in the Assess stage, you test the integration to ensure that it was performed as expected.
During the Plan and Gather stages of the integration life cycle, you must consider six additional aspects of COTS
product integration with your software system.
Vendor lock-in or entanglement

In general, avoid tight coupling to a particular vendor -- known as entanglement, or vendor lock-in. Design decisions
that make replacing the selected COTS product difficult increase the risk that the organization will be forced into a
long-term relationship with a particular vendor -- whether it wants to or not. As a result, development decisions can a
have grave repercussions to the organization if not considered carefully.
Versioning

Vendors periodically release updated versions of their products. Your system architecture should incorporate careful
consideration of how a new release will be deployed into all environments (development, test, acceptance, production).
Process changes

COTS product integration may require changes to your organization's core business practices and operations.
Therefore, integration may involve more than just software development; it may affect the full user community. Users
should be involved in the early rounds of integration so that they're aware of potential downstream impacts.
Validate the COTS product

Validation of a COTS product includes testing not only the integration but also the full system functional flows.
Validation argues strongly in favor of an incremental release approach, in which the partial system is delivered to test
to ensure that the component integration is meeting requirements.
Customization

COTS products often provide a limited set of configurable elements that you can tune to the specific needs of your
organization's environment. While this is a strong selling argument, it often raises issues of deployment, support, and
vendor lock-in. Customization should be limited to what's absolutely necessary.
Licensing

Installing and deploying COTS products involves licensing and configuration. Consider these factors in each iteration
to ensure that the final product can be efficiently delivered to the production environment.

Understanding the unique challenges of COTS products

COTS products represent a unique integration challenge. For example, while most commercial services may be
provided through a well-defined interface, the structure of the data may lead to hidden internal dependencies. To
combat this tendency, perform a data translation on incoming messages to a stable form under the control of the
development team. Doing so avoids a widespread breakage when a data structure changes unexpectedly.
Services are also typically distributed and so not under control of your development team or the client company. While
most service providers agree to a specific contractual service level, there will be outages -- planned and unplanned. It is
a good idea for the service client system to gracefully handle temporary outages (and potentially alert someone to the
situation). For core business services, the system should automatically recover operations when the service is again
available. Alternatively, the application may perform in a "degraded" mode while the outage persists. For example, an
order-entry system may queue orders during a billing outage, and then submit the collection in bulk when the billing
system interface is available again. Alternatively, the system can use a backup server to continue functioning.
Customizable applications are another form of COTS product that are often used to provide specific application
functionality. For example, Vitria provides products that can form the basis of a full-featured customer care and service
application. You extend the system functionality in carefully defined areas (as provided by the vendor). This technique
is highly successful for many organizations, but it can fail when you over-customize the framework, perhaps to avoid

3 of 5 8/22/2006 3:27 PM
COTS product integration: An architectural approach http://www-128.ibm.com/developerworks/ibm/library/ar-cotsint/

changes to existing systems or business processes. In this case, the custom scripts require increased maintenance efforts
and complicate release management for new versions. This, in turn, may lead to dramatic increases in ownership costs.
Other frameworks facilitate user interface development, data conversion, or networking. In all cases, the challenge is
the same: Choosing the solution that meets your organization's need with the minimal amount of customization.
Hardware-based COTS products have additional unique architectural implications. For example, consider a
video-on-demand system for a hotel. In this case, each room must be equipped with a specialized video converter box,
perhaps enabled with a built-in Internet browser capability. The solution that must be delivered to the customer has
become dependent on the particular hardware manufacture -- a limit to future product direction or deployments. To
combat this vendor lock-in problem, you may choose to avoid using all the built-in capabilities and instead provide that
part of the system functionality yourself. In this way, a new hardware vendor that doesn't support those capabilities can
be introduced with minimal system changes.
Extending COTS-integrated systems requires a few additional considerations. An integrated vendor may not be willing
to support a competitor's product or interface. A vendor may have partnership agreements in place that prohibits
coexisting with another COTS product in the final solution. Dependencies on a particular operating system or hardware
platform may prevent migration to a new system -- even if the integrating code is supported on the target platform. As
noted above, a COTS vendor product plan may not include a necessary function that your organization wants, but it
may also include moving the product in a market direction that doesn't support your needs, placing your organization at
a disadvantage if the organization isn't insulated against those changes.
Given these challenges, your organization may not realize all the touted benefits of COTS product integration if you
don't deal with these issues early in the project. As the system architect, your role is to provide a range of options to the
organization. Detail all the positive and negative aspects of the available COTS components, including cost in the near
and long term for all potential solutions.

Summary: Treating vendors like strategic partners

Relationships with vendors aren't like those with contractors; you must treat vendors as key strategic partners rather
than individuals performing a single task, then leaving. Although this is not strictly an architectural issue, it affects
decisions on architectural tradeoffs. Vendors know the limitations of their products (even if they are reluctant to admit
them): Ignore their advice at your peril. Vendor representatives should be involved in the planning and execution of the
product integration to ensure that these limitations are taken into consideration. The development team is primarily
concerned with the technical details of integrating the system to the COTS component, but there may be special tricks
or traps known to members of the vendor organization.
Establishing a strategic vendor relationship provides several benefits. First, you get close working ties between the
organizations, allowing communication of changes and release schedules. Second, as partners, there's a higher
likelihood that the vendor will listen closely to your organization's needs, including issue resolution and enhancements.
Finally, the partnership reduces the vendor-lock risk, because the businesses are operating as partners rather than
potential competitors.
Selecting, integrating, and fielding COTS components have the potential for great benefits for an organization, but with
these benefits come great risks. An architectural approach mitigates many of these risks by reducing the dependency on
a single vendor and insulating against changes in the commercially driven component.

Resources
Learn
For more information about the risks of COTS product integration in existing systems, read " Identifying
Commercial Off-the-Shelf (COTS) Product Risks: The COTS Usage Risk Evaluation" (Carnegie Mellon Software
Engineering Institute, 2005).

4 of 5 8/22/2006 3:27 PM
COTS product integration: An architectural approach http://www-128.ibm.com/developerworks/ibm/library/ar-cotsint/

"Evolutionary Process for Integrating COTS-Based Systems (EPIC): An Overview " (Carnegie Mellon Software
Engineering Institute, 2005) provides a process framework for integrating COTS products into existing software
systems.

To learn more about integrating COTS products, read "Can We Ever Build Survivable Systems from COTS
Components?" (Carnegie Mellon Software Engineering Institute, 2005).

Stay current with developerWorks technical events and webcasts.

Get more information from developerWorks (including articles, tutorials, and interviews) about IT architecture.

Get products and technologies

Build your next development project with IBM trial software, available for download directly from
developerWorks.

Discuss
Participate in developerWorks blogs and get involved in the developerWorks community.

About the author

Benjamin A. Lieberman serves as principal architect for BioLogic Software Consulting, providing expertise
consulting and training on a wide variety of software development topics, including requirements analysis,
software analysis and design, configuration management, and development process improvement. Dr.
Lieberman specializes in object-oriented architectures and distributed computing. You can reach him at
blieberman@BioLogicSoftwareConsulting.com.

5 of 5 8/22/2006 3:27 PM