A Roadmap for Enterprise Integration
Dennis Smith, Liam O’Brien, Mario Barbacci
Software Engineering Institute
Carnegie Mellon University
4500 Fifth Avenue
Pittsburgh, PA 15213 USA
+1 412 268 6850
{lob, dbs, mrb}@sei.cmu.edu
Abstract
The ability to provide integration between business
functions that may be supported across multiple
applications is a critical need for modern organizations.
However, problems often emerge from overly ambitious or
imprecise requirements resulting from inadequate plans for
integrating different systems (legacy or otherwise). This
paper analyzes the field of enterprise integration and
provides an analysis of the extent of the problem and
current trends that address the problem. It identifies gaps in
the field, outstanding research issues, and provides an
initial roadmap toward a solution.
1 Introduction
Enterprise Integration has the goal of providing timely and
accurate exchange of consistent information between
business functions to support strategic and tactical business
goals in a manner that appears to be seamless. The initial
automated applications that were developed during the
1950s and 1960s tended to focus at the level of an
organizational unit. Over time, the scope of requirements
has increased, along with an unfortunate tendency for the
information systems to become brittle, difficult to manage,
and hard to understand. This in turns led to the inability of
users to integrate critical new applications into the existing
solution set, or to mix-and-match the capabilities provided
by the systems to solve new problems.
As automated systems became more pervasive within
organizations, and as organizations reorganized, split or
were acquired and reacquired over the years, the need for
integration between applications over a broad enterprise
has become increasingly important, and in fact is often a
critical success factor for the survival of the enterprise.
Rather than acting as independent programs, integrated
Proceedings of the 10th International Workshop on Software Technology and Engineering Practice (STEP’02)
0-7695-1878-8/02 $17.00 © 2002 IEEE
François Coallier
Département de génie électrique
École de technologie supérieure
1100, rue Notre-Dame Ouest
Montréal, Québec
Canada H3C 1K3
fcoallier@ele.etsmtl.ca
systems can provide better business value by sharing data,
communicating results, and improving overall
functionality. Integration of information systems is
expensive and time consuming. Between 20% and 40% of
labor costs can be traced to the storage and reconciliation of
data. In addition, 70% of code in corporate software
systems is dedicated to moving data from system to system
[1]. The challenge has always been how to realize this goal.
Over the past quarter century, there have been a number of
conceptual approaches and technology solutions that have
addressed the problem of enterprise integration. However, a
comprehensive solution is not yet available. This paper
reviews a set of current approaches to address enterprise
integration, discusses why many previous efforts have
failed, and suggests how an integrated approach may
provide the kind of benefits that have eluded the systems
world for the past 25 years.
Background
Despite the large investments that are made, many
integration efforts fail for a number of technical,
organizational and management, and migration planning
reasons. The technical issues include the following:
• Legacy systems originated from unplanned, stovepipe
development or were developed as batch, single tier.
• Data is specific to the applications and was not
designed for sharing.
• The legacy systems were not initially designed for
new quality-attribute requirements and are being
affected by needs for interoperability, performance,
security, and usability.
• The scope for the integration effort is not adequately
defined.
• Decisions are made without performing adequate
analyses (sometimes referred to as “management by
magazine”).
The organizational and management issues include the
need to obtain and maintain sponsorship and financial
 commitment at all levels of the organization for the
duration of a potentially lengthy integration project; the
need to break a project up into subprojects so that
consistent, intermittent milestones can be measured; and
the need to communicate effectively.
In addition issues involved in migration planning are often
poorly understood. These include a consideration of
migrating databases and data, understanding user issues,
providing training, and developing both temporary and
long-term bridges between legacy systems and the newer
applications.
The Significance of Enterprise Integration
The problem of enterprise integration is equally significant
within the government and corporate world. Within the
U.S. federal government, every federal government
organization has been mandated by the Clinger–Cohen Act
of 1996 [2] to appoint a Chief Information Officer (CIO).
The CIO has the responsibility of “developing, maintaining
and facilitating the implementation of a sound and
integrated information technology architecture” for the
agencies.
Within the corporate world business survival often depends
on the ability to effectively integrate applications across the
value chain of the business. One critical success factor in
Dell’s rise to prominence over such established companies
as IBM and Compaq has been its ability to provide
integrated and efficient end-to-end service including order
entry, tracking, fulfillment, back-end processing and
customer support. While enterprise integration is critically
important for all modern organizations, it is mandatory for
some types of organizations, such as those that rely on e-
business.
Although executives specify enterprise integration as a
critical goal, the track record of implementations has been
spotty. A number of publicly documented failures [3]
include:
• Hershey Foods Corp., $115 million SAP installation to
replace “scores of legacy programs running everything
from inventory to order processing to human
resources”; during busiest season of the year
(Halloween), “Hershey warehouses piled up with
undelivered Kisses, Twizzlers and peanut-butter cups.
The upshot: third-quarter sales dropped by a
staggering 12.4 percent … and earnings were off 18.6
percent.”
• Whirlpool, Dow Chemical, Boeing, Dell Computer,
Apple Computer and Waste Management experienced
similar disappointment.
Proceedings of the 10th International Workshop on Software Technology and Engineering Practice (STEP’02)
0-7695-1878-8/02 $17.00 © 2002 IEEE
• W. L. Gore & Associates sued Deloite Consulting for
breach of contract, fraud and negligence to recover
$3.5 million in fees; also names PeopleSoft for
certifying incompetent party.
• SunLite Casual Furniture sued Deloitte in Arkansas for
maliciously “indoctrinating in SunLite a total
dependency on D&T that D&T hoped would result in
lucrative fees for years to come.”
• FoxMeyer Drugs blames “botched implementation of
SAP's F/3 software for pushing it into bankruptcy back
in 1996.” Suing Andersen and SAP for $500 million,
also only spending $30 million for the project.
Two analyses [4, 5] attribute the reasons for failures to 7
primary reasons:
1. Miscommunication
2. Hazy goals
3. Poor project management
4. Scope creep
5. Modifying ERP software prior to pilot testing
6. Inadequate training
7. Insufficient implementation support
2 Planning for Enterprise Integration
EI requires developing an overall plan to determine the
scope of a set of projects and then implementing this plan
with a sound technical approach. Both of these activities
are crucial for the success of EI. We next briefly describe
the overall planning activity and the activities associated
with implementing the plan.
Planning for enterprise integration is most often associated
with the development of enterprise architectures. Enterprise
architecture planning is the process of defining
“architectures” for the use of information in support of the
business and the plan for implementing those architectures
These “architectures” are high level definitions of the data,
applications, and technology needed to support the
business. The result of the process is a long-range plan to
support the overall goal of enterprise integration.
Most approaches to enterprise architecture planning
approaches are based on a framework originally proposed
by Zachman [6] that creates a matrix with data, functions
and network as the columns and a set of different views
(contextual, conceptual, logical, physical and detailed
representation ) as rows. Planning decisions involve logical
 clustering of data and business processes into applications.
These approaches, which are widely used, enable the
important task of developing a high level integration
blueprint. They also offer a method for discussing issues at
different levels of detail, and for isolating information
requirements from their dependencies on existing legacy
systems.
Unfortunately, the label “architecture” has resulted in
confusion rather than clarity. These “architectures” provide
a starting point for understanding the problem domain, but
do not provide the foundation for software development
that software architecture does. An enterprise architecture
has a very different scope from a software architecture. The
software architecture is the structure or structures of a
system, which comprise software elements, the externally
visible properties of those elements, and the relationships
among them [7]. Thus, a software architecture should begin
where the enterprise architecture ends.
There are also several problems with the current set of
approaches. The linkage to the software architecture
required to implement the plans is often left for future
work, resulting in a disjunction between the planning stage
and the implementation stage. In general, there is not clear
guidance on this step. As a result, initial plans are often
developed which later flounder for lack of a clear
connection to actual system development and for the lack
of a detailed implementation plan. Few enterprise
architecture plans have actually been implemented
successfully. In addition, most approaches to enterprise
architecture planning assume a structured development
approach, and there have not been systematic updates
reflecting object-orientation.
One way to plan for enterprise integration is to develop an
enterprise architecture that represents how major
information systems across the enterprise fit together. The
architecture identifies the scope of individual systems and
the boundaries between them. Thus, an enterprise
architecture is essentially a planning activity, rather than a
development activity.
In practice, however, this distinction between planning and
development is often ignored. Organizations focus on the
wrong sets of issues in developing an enterprise
architecture, and as a result get little value from it. There
are two basic problems that often occur in practice:
1. overscoping the enterprise architecture, resulting in an
open-ended effort that is too ambitious to ever
successfully implement
Proceedings of the 10th International Workshop on Software Technology and Engineering Practice (STEP’02)
0-7695-1878-8/02 $17.00 © 2002 IEEE
2. driving the enterprise architecture down to low levels
of detail
a. this results in losing the focus of the
enterprise architecture as well as modeling
low levels of detail that will only need to be
repeated when actual systems are developed.
b. it also results in focusing on the functionality
of individual systems rather than the
interconnections between them.
An Example of the Scope of an Enterprise Architecture
Figure 1 illustrates an example of an enterprise
architecture. This figure represents an enterprise
architecture (derived from [8]) for a general
telecommunications application.
Figure 2 illustrates an example of an enterprise architecture
context model [13] which deals with various business
issues, represented by strategic planning, which drive, the
model. The enterprise architecture provides the blueprint
for scoping future IT applications. This leads to a set of
specific projects which are developed and managed
according to the standard organizational development
processes. As shown in Figure 2, the detailed analysis and
development activities are performed in the follow-on
activities, and not as part of the enterprise architecture.
3 Implementing the plan
Implementing the plan for enterprise integration requires a
set of projects that rely on a systematic approach for
representing business, information, and technology
perspectives; a systematic method to plan for specific
tactical solutions, including budgets and project plans; and
an understanding of infrastructure issues, such as
processors and storage, networking, data management, and
management and staffing. The management and
organizational issues are critical for enterprise integration.
In this paper, we will focus primarily on technical issues.
To understand the relationship between the technical issues,
we developed an integration model, which is shown in
Figure 3.
 Figure 1: Example of an Enterprise Architecture

Enterprise IT Processes Context M odel

Strategic Planning
Enterprise Architecture
G o ve r n a n c e
Program and Integration Managem ent
M a nagement Dim ensio ns
Governance
Scope/Change
Risks
Schedule
Costs

Quality
Resources
Communications
Impacts
Vendor
Architecture
Assets

D e li v e r y
Project PROJECT Project
Initiation Closure
V&V
Engineering

Pure W aterfall
Product

Spiral
M odified W aterfall
Evolutionary Prototyping
Staged D elivery
CO TS So ftw are
Code-and -Fix
Design-to -Schedule
Design-to
Delivery -Tools
Ap proaches
Quality Assurance and C h ange M ana gem ent
O p er ation s
IT Proce ss M anagem ent and Support
a n d S u p p o rt
Infrastructure and Asset M anagem e nt
Operations and Support

Figure 2: Example of an Enterprise Architecture Context Model

Figure 1: Exam ple of an E nterprise Architecture Conte xt M odel

Proceedings of the 10th International Workshop on Software Technology and Engineering Practice (STEP’02)
0-7695-1878-8/02 $17.00 © 2002 IEEE

Requirements and
Principles
Business Integration
Application Integration
Quality Attributes
Presentation
Integration
Data Control
Integration
Integration
Connectivity
Figure 3: Integration Model
The Technical Issues
Requirements and Principles deal with determining the
business drivers and guiding principles that help in the
development of the enterprise architecture. Each functional
and non-functional requirement should be traceable to one
or more business drivers. Organizations are beginning to
become more aware of the need for capturing and
managing requirements. Use-case modeling is one of the
techniques that is used for doing this.
Business Integration concerns the design and modeling of
business processes. Processes represent how the user sees
the system. They are often highlighted when companies
merge. Business process reengineering (BPR) decisions are
often made in the context of enterprise integration.
Presentation Integration involves with integration of
corporate knowledge and business processes to enable an
enterprise to share applications, services, and core
competencies among the enterprise’s main constituents:
employees, customers, partners, and suppliers.
Data Integration deals with aspects of integrating data
within an enterprise. It deals with how data is modeled and
the meaning of the data. It deals with normalization,
Proceedings of the 10th International Workshop on Software Technology and Engineering Practice (STEP’02)
0-7695-1878-8/02 $17.00 © 2002 IEEE
validation, and integrity of data and what translations need
to be applied to the data for exchange between applications
within the enterprise or between the enterprise and outside
systems.
Control Integration deals with different types of messaging
between applications and how these messages are handled
based on different modes of communication and protocols.
Connectivity relates to workflow, data, and service
connectivity and is handled by application bridges and
gateways, message-handling services, and basic
communication protocols.
Quality Attributes involve architectural decisions that
influence quality characteristics such as performance,
dependability, and security. Quality attributes span several
aspects of the integration model. When the software
architecture is specified, designers need to determine the
extent to which architecture decisions influence quality
attributes, the extent to which techniques used for one
quality attribute support or conflict with those of another
attribute, and the extent to which multiple quality-attribute
requirements can be satisfied simultaneously.
Quality-attribute issues do not get enough attention in
enterprise integration. Quality-attribute requirements are
usually defined too late in the development process. One
problem is to determine how business requirements and
drivers translate into quality-attribute requirements.
Application Integration deals with getting different
applications to work together using mechanisms such as
automatic event notification, flow control, and content
routing. Transactional integrity and application-context
transformation across applications are important aspects of
application integration. Application integration spans
several layers of the integration model. Clear techniques
are not available for making decisions about which
applications to integrate and determining the nature of the
problem. Applications on the same server may be easier to
integrate, as cross-network integration can be complicated
by different operating system versions, network delays, and
differing protocols.
This model is elaborated in more detail in [9].
4 Enterprise Resource Planning Solutions
(ERPs).
Enterprise resource planning (ERPs) solutions are
integrated, technology-based solutions that provide support
 for standard enterprise needs in such areas as finance,
human resources, and logistics. A number of vendors
provide ERP solutions, including PeopleSoft, SAP, Baan,
and Oracle. ERPs are popular because they offer the
promise of enabling an organization to leverage the
research and development efforts of the ERP vendors.
Functional areas such as taxes, purchasing, and human
resource management have a significant amount of
commonality between organizations, and there are strong
arguments for purchasing a ready solution rather than
developing an application from scratch.
ERPs can make good sense for an organization. However,
the benefits are far from automatic. In fact, a number of
disasters in ERP implementations have occurred. A
decision to implement an ERP requires careful analysis of
the following factors:
• an understanding of the gap between the
underlying object, data, or functional models of
the ERP solution and those currently supported by
an organization’s legacy systems (often substantial
effort is required to customize the ERP or change
the organizational processes to match those of the
ERP)
• an understanding of specific ways in which the
ERP will interface with legacy systems, other
ERPs, and future development efforts
• an understanding of migration issues, such as user
training, data migration, phasing in of the ERPs,
and phasing out of the legacy systems
• development of realistic cost and schedule
estimates reflecting realistic expectations
5 Disciplined Migration Planning
Enterprise integration can also be considered to be a
complex migration problem. Although the initial step of
developing an enterprise integration plan establishes a
blueprint for the final goal, in general these efforts have not
developed adequate plans. In general there is an
assumption, which may be unrealistic, that legacy systems
will be replaced over a period of time. As a result, such
efforts have sometimes been big bang approaches – without
substantial intermediate deliverables. There is a need to
have a greater focus on migration plans from current legacy
systems and to clearly relate the perceptions and needs of
end users to the long-range plans that are developed.
Bergey, O’Brien and Smith [10] have addressed the issue
of migration planning, and recommend addressing a set of
issues, including:
Proceedings of the 10th International Workshop on Software Technology and Engineering Practice (STEP’02)
0-7695-1878-8/02 $17.00 © 2002 IEEE
• Identifying all relevant stakeholders and involving
them throughout the project
• Ensuring there is a common understanding of the
problem to be solved
• Determining that the initiative is commensurate
with the maturity of the organization’s software
practices
• Define all aspects of the software architecture and
its constraints on existing and new systems
• Perform a thorough analysis of legacy systems,
their interfaces, and changes required
• Break the problem into bite size chunks that are
phased in incrementally
• Do a pilot effort before committing to a large scale
plan
6 A Roadmap to Future Progress
As we have seen, the demand for enterprise integration is
broad. This affects all organizations, and addressing
enterprise integration can often be a key to meeting the
strategic goals of the organization. This section summarizes
the positive trends and gaps related to technology issues
and organizational issues. It then outlines the steps that
need to be taken in order for significant progress to be
made.
Technology Issues
A workshop on enterprise integration conducted at
CASCON2001 highlighted a number of the technology
trends that have been converging and that offer the
potential of making substantial progress in addressing the
problem of enterprise integration. It also identified
outstanding issues that need to be addressed before
substantial progress can be made.
The positive trends include:
• Net-centric computing
• Web as a portal to corporate data
• Implications of eCommerce
• Java enabled portability across hardware platforms and
operating systems
 • Maturity of Enterprise Application Integration (EAI)
middleware (Websphere, Component Broker, Vitria,
.NET) and platforms (such as Eclipse) for the effective
integration of tools [11]
• Potential of mark-up languages (such as XML) for
linking structured and non-structured data [12].
Despite this progress, the overall status of the field is
immature. The issues of planning and scoping continue to
hamper many efforts. There is significant confusion
between the roles of different types of architectures. As a
result, organizations sometimes go into too low a level of
detail in developing an enterprise architecture, leading to a
failure to adequately specify the scope, as well as a
duplication of the effort that will later be applied to
defining the software architecture. Although middleware
technologies have matured significantly, clear guidelines
are not yet available about when to use different types of
technologies. As a result, some organizations have made
decisions in a haphazard manner and have sometimes
focused on vendor-driven approaches without adequate
analysis. Some ERP products are heavily promoted as a
total solution to enterprise integration. However, substantial
modifications are often required to the ERP product for it to
work in a specific organization. In addition, interfaces with
legacy systems and other ERP products can be problematic.
Organizational Issues
The organizational issues are significant. An enterprise-
integration effort affects an entire organization, and it is
necessary to have long-term management support and
financial commitment, realistic plans, and systematic
migration planning.
The outstanding organizational issues and problems
include:
• a need for an effective methodology for enterprise
integration including a clear distinction between the
scoping that an enterprise architecture provides and
the detailed blueprint for development that a software
architecture for an application provides. This includes
clear guidelines for the deferral of details from the
enterprise architecture to the software architecture
• lack of generic solutions to integration problem
(integration solutions tend to be local)
• the extraction of interfaces from existing systems and
identification of side effects
• need for clear guidance for management decision
making
• need for overall solution to distributed transaction
Proceedings of the 10th International Workshop on Software Technology and Engineering Practice (STEP’02)
0-7695-1878-8/02 $17.00 © 2002 IEEE
processing on a WAN (latency, wide-scale
transaction, scalability)
• A need to recognize that integration cannot be
mandated, legislated or assumed. It needs to be
nurtured. There is often a lack of understanding of the
cost of integration at upper management levels. Cost,
risks, and potential harm need to be fed back to the
upper levels.
• A common failure to clearly define the scope of an
"enterprise" to integrate. This can result in a shifting
definition of the enterprise, overlapping organizations,
and turf battles. There is a great deal of pressure to
define an enterprise too broadly, and thus to make it
difficult to partition the problem into manageable
entities.
• A need to recognize that any technology solution
should derive from business drivers using technology
as an enabler, as opposed to viewing technology as a
primary driver. Many failures result from a
“technology first” or “solution first” approach, and
from the failure to adequately address organizational
and cultural issues.
• There is often a failure to take a long term view. Some
of the factors include the practice of rapid rotation of
leadership, budget instabilities, and failure to plan for
long-term maintenance and upgrading costs.
• A need to consider the total cost of ownership for an
ERP solution. The total cost includes not only the
ERP software cost but the other associated costs
including integration, training, system analysis,
customization, maintenance, etc. The associated costs
may be of the order of magnitude of 5 to 7 that of the
software cost.
• There can be a tension between the requirement of
developing an enterprise architecture and the
pragmatic demands of individual ERP/COTS
solutions, leading to the impression that technology is
the solution.
• When making a decision on an ERP, low level
analysis of the details needs to be done to determine a
match in some cases changing existing business
processes to match those of an ERP may be the most
cost-effective approach. However, this needs to be
done with careful analysis which unfortunately does
not occur often.
• There is a strong need for a coordinated migration
plan for the existing systems to move towards
integration

Foundations for Future Progress
A number of recent trends provide a foundation that can
lead to future success. Middleware technologies have
advanced rapidly over the past 10 years, and these enable
more options for integration than had been previously
available. The maturing of markup languages such as XML
enable more effective integration, particularly between
structured data, such as data from databases, and non-
structured data, such as email.
The Web can serve as a common front end for integrating a
variety of applications, and it can enable effective
presentation integration. Web services are maturing as an
important mechanism for integration of legacy systems,
new applications and ERPs. The emergence of enterprise
portals over the past several years demonstrates the strong
interest and need for effective presentation integration. In
addition, ERP applications, while still displaying
significant problems, have become more mature, and their
interfaces are better able to share data with other
applications.
7 Conclusions: Moving From Present Reality
to Desired State
There is a significant gap between the desired state of
seamless integration and present reality. In order to bridge
this gap the following critical issues need to be addressed:
• Determining an effective scope for an integration
effort as well as the development of a proven method
for developing an effective scope for integration
efforts. Currently, many efforts flounder because they
fail to define an effective scope. Often current efforts
develop very ambitious scopes that are difficult, or
impossible to successfully implement.
• Aligning the integration effort with the mission and
high-level goals of the enterprise, and developing
commitment and sponsorship at the appropriate levels
• Understanding the appropriate role of an enterprise
architecture, and its relationship to a software
architecture
• Understanding appropriate role of frameworks and
standards
Proceedings of the 10th International Workshop on Software Technology and Engineering Practice (STEP’02)
0-7695-1878-8/02 $17.00 © 2002 IEEE
• Addressing the technology issues of data integration,
control integration and presentation integration
• Decision rules for making choices on the types of
technology that are most appropriate for specific types
of efforts. Although many technology solutions are
available, there are not easily accessible guidelines for
when to use different types of solutions.
• Understanding when ERP solutions are appropriate,
and when they are not appropriate
• Breaking down an overall project into realistic parts
• Developing realistic sets of plans for the effort
• Addressing issues of contracting, funding and
oversight management within organizations. This is
especially relevant for government organizations.
• Migration and integration of legacy systems
References
1. Zachman, J. “Enterprise Architecture: The Issue of the
Century.” Database Programming and Design, March,
1997.
2. U.S. Public Laws. Public Law 104-106, 1996.
3. Osterland, A. ERP Disasters. CFO, The Magazine for
Senior Financial Executives, Jan. 2000.
4. Nash, K. “Companies Don’t Learn From Previous IT
Snafus”, Computerworld, October, 2000.
5. McAlary, S. “Three Pitfalls in ERP Implementations”,
The Managers Publication of Data Solutions, March,
2000.
6. Zachman, J. “A Framework for Information Systems
Architecture,” IBM Systems Journal, Vol 26, No. 3,
1987.
7. Bass, L., Clements, P. and Kazman, R. Software
Architecture in Practice. 2nd. Ed. Addison Wesley.
2003.
8. Telemanagement Forum. eTOM Business Process
Framework. Available online at:
http://www.waywise.at/files/eTOM%20Model.pdf.
9. Kontogiannis, K., Smith, D., and O’Brien, L. On the
Role of Services in Enterprise Application Integration.
Proceedings of STEP 2002. IEEE Press. 2003.
 10. Bergey, J., O’Brien, L. and Smith, D. DoD Software 12. Finkelstein, C. and Aiken. P. Building Corporate
Migration Planning. Carnegie Mellon University, Portals using XML. McGraw-Hill, 1999.
Software Engineering Institute, CMU/SEI-2001-TN-
13. Coallier F. and Garceau B., An Integrated Enterprise
012.
IT Process Model, (unpublished).
11. Britton, C. IT Architectures and Middleware. Addison-
Wesley, 2000.

Proceedings of the 10th International Workshop on Software Technology and Engineering Practice (STEP’02)
0-7695-1878-8/02 $17.00 © 2002 IEEE