See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/220672562

What is integration?

Article in Industrial Management & Data Systems · January 2006

DOI: 10.1108/02635570610640979 · Source: DBLP

CITATIONS READS
91 31,989

1 author:

Thomas R. Gulledge
George Mason University
125 PUBLICATIONS 1,536 CITATIONS

SEE PROFILE

All content following this page was uploaded by Thomas R. Gulledge on 27 June 2014.

The user has requested enhancement of the downloaded file.

 The current issue and full text archive of this journal is available at
www.emeraldinsight.com/0263-5577.htm

What is
What is integration? integration?
Thomas Gulledge
George Mason University, Fairfax, Virginia, USA

Abstract 5
Purpose – This paper aims to provide a clarification of the meaning of the term integration.
Design/methodology/approach – A taxonomy of integration definitions derived from the
academic and trade literature is developed, analyzed, and documented.
Findings – Integration is a word that is commonly used when discussing enterprise applications.
The term integration is inserted in technical papers, e-mail messages, correspondence, proposals, and
even causal conversations. After many years of project work, and many misunderstandings and failed
meetings and workshops, it can only be stated that the word has multiple and misunderstood
meanings. For technical papers (research and trade), the term must be provided with context, or it is
impossible to have a meaningful conversation. Next, multiple alternative definitions (that are valid in
the literature for the appropriate context) are presented and explained in some detail.
Research limitations/implications – The paper is not exhaustive, since new definitions of
integration may exist or may emerge.
Originality/value – The main contribution of the paper is that it yields clarity on a key term that is
frequently used in information systems research. The paper is useful to any researchers or
practitioners who are focused on enterprise system implementation.
Keywords Integration, Interface management, Applications, Information systems, Research
Paper type General review

Introduction and importance

Integration is a common term in the enterprise systems literature. Seldom does a
meeting occur when the word is not used multiple times and often within quite
technical contexts. Unfortunately, our experience is that individuals often have a
different understanding of the meaning of the word. Loosely speaking, there is a
general consensus that integration concerns making applications work together that
were never intended to work together by passing information through some form of
interface. This is certainly part of the context, but this paper argues that there is more
to be said. Since the earliest days of computing, the term “integration” has been used in
both the trade and academic literature to describe a process, a condition, a system, and
an end-state. Given that these competing labels have very different meanings, their
indiscriminate usage is often obscure and invites confusion. For example, a sloppy
conflation of process and condition encourages circular definitions that possess little
explanatory power.
Consider the following advertisement (Figure 1) from the Oracle Corporation and
the corresponding quote from the Oracle CEO, Larry Ellison. Figure 1 is clearly an
appeal for a type of integration that we call “Big I,” having all relevant data aligned
with a single data model and stored only once. The implication is that you can place all
of your data for the set of business processes listed in the middle column of Figure 1 Industrial Management & Data
inside of the Oracle E-Business Suite and significantly reduce total cost of ownership Systems
Vol. 106 No. 1, 2006
(TCO). In fact, the advertisement claims that Oracle saved over $1 billion USD per year pp. 5-20
by implementing Big I. The other implication in the quote is that if you implement q Emerald Group Publishing Limited
0263-5577
“Best of Breed” with interfaces, you are going to have implementation problems; DOI 10.1108/02635570610640979
IMDS
106,1

Figure 1.
Oracle advertisement for
Big I

i.e. “No matter how well you do it, systems integration can never get all of your data
together in one place”[1].
Ellison has a point – interfaces are expensive[2], and they can comprise a
significant portion of the cost of any enterprise system implementation project. And
also, there are the problems with complexity and managing scope integrity across
multiple data sources (Gulledge and Sommer, 2004). Consider Figure 2 from an
unnamed company. Figure 2 shows a situation that is described in the literature as
“systems integration;” i.e. the interfacing of systems together so they can pass
information across a complex technology landscape. We call this type of integration a
form of “Little i,” and we note that this form of Little i (point-to-point interfaces) is an
expensive proposition. Data must be constantly harmonized and cleansed across
multiple data sources, and any changes to one system can lead to complex and costly
re-testing or even re-design and coding of interfaces.
Clearly, we have presented two extremes, and by and large both have been rejected
by large organizations world wide. Most organizations do not want to include all of
their data in one application (e.g. Oracle, SAP, Microsoft, etc.) for a number of different
reasons, but at the same time, no one wants the problems that are associated with
implementations like that shown in Figure 2.
There are other options. In fact there are many options, and that is the point of this
paper. All of the options (including the two above) are called integration. So what is
integration? As one might guess, it depends on the context, and the usage must be
qualified. Big I may not achievable, and it may not even be appropriate. If Little i is
appropriate, what type of Little i is appropriate, given the situation and the state of
 What is
integration?

Figure 2.
Interfacing systems
components to define an
enterprise solution

emerging technologies? This paper addresses those questions, and it also categorizes
the most used forms of Little i in the context of enterprise system implementation. This
categorization and associated discussion is essential, or it is impossible to have a
meaningful discourse about application integration.

Integration – Big I
To establish a baseline, the following definition is proposed for integration.
Integration (Big I) – integration implies that all relevant data for a particular
bounded and closed set of business processes is processed in the same software
application. Updates in one application module or component are reflected throughout
the business process logic, with no complex external interfacing. Data are stored once,
and it is instantaneously shared by all business processes that are enabled by the
software application.
This is a rather comprehensive and restrictive definition that revives memories of
first generation enterprise resource planning (ERP). The business process implications
of Big I are discussed in some detail by Gulledge and Sommer (2003).
To preserve clarity throughout this paper, the above definition will always be
referred to as “Big I.” Big I is definitely the goal of management, especially for
mundane business processes. This implies “one source of truth” for those business
processes that are enabled by core ERP solutions. The concept is simple: if all data are
stored once and shared, then integrity issues are less likely to occur. The TCO is
significantly less, since interfaces across application components are not required.
Furthermore, complexity is significantly reduced.
IMDS Figure 3 shows how Big I relates to Little i for a simple example related to US Army
106,1 Logistics.
In this example, Army Logistics processes are scoped with the SAP solution as Big
I; i.e. there is no interfacing across the SAP components. However, some of the logistics
business processes flow outside of the Army. In this case, we indicate the
transportation processes that are part of the end-to-end logistics business processes,
8 but they fall outside of the Army, and they are managed by the US Transportation
Command (TRANSCOM). The systems that support this segment of the end-to-end
process are not SAP, and they are not even owned by the army. This is a classical
composite application[3] and some form of Little i is must be implemented in order to
preserve the integrity of the business process logic[4].
Figure 3, even though a simple picture, shows much about integration. First, it
suggests that large and complex organizations are unlikely to place all of their
business processes in a single application. While assertions of Figure 1 are accurate,
there are at least two reasons why single instance ERP will not occur in most firms:
(1) the internet opened more options for Little i; and
(2) the culture and control of the internal and external system integration
communities will not allow such consolidation.
Like it or not, given the current state of technology, we are going to have to live with is
a mixture of Big I and Little i, at least as long as the current trends continue. The reality
of this situation is reinforced by the fact that the larger software providers are
“opening” their products and making them more flexible for mix and match

Figure 3.
An example of Big I and
Little i in the same
enterprise
opportunities with Little i. This is evidenced by such products as the Oracle Data Hubs What is
and SAP NetWeaver technologies. While it is true, just as Figure 1 shows, that the TCO integration?
could be reduced by moving to Big I, most organizations do not have the flexibility nor
the desire to do that.
However, this does not mean that Big I is dead. There will always be pockets of
Big I; connected by Little i, to other pockets of Big I. This is not a technical assertion,
but is directly related to common sense. For example, one would never “rip” a product 9
like SAP core ERP apart and then interface it back together again. This is self inflicted
pain, and it can be avoided by just implementing the product the way it was intended
to be implemented[5]. Preserve the integrity of the product by implementing Big I
whenever possible, and use Little i to include those components that cannot be included
in the integration domain. One would never dream of separating financials from
materials in an SAP implementation, and then interface it back together again. Or even
worse, it makes even less sense to stand up independent SAP solutions in different
divisions of a company, operating as a family or fiefdom, with the absence of an
enterprise orientation.
We will revisit implementation options later, but before doing that, we must further
explore the options for Little i. The choice of a particular little i technology has
significant implications for the types of mix and match options that are available for
consideration.

Integration (Little i)
As previously mentioned, all forms of Little I are some form of interfacing, even though
they are loosely called “system integration.” Much has been written on the subject, so
we only focus on those types of Little i that are most relevant for the implementation of
enterprise systems:
.
point-to-point integration;
.
database-to-database integration;
.
data warehouse integration;
.
enterprise application integration (EAI);
.
application server integration; and
.
business-to-business (B2B) integration.
Point-to-point integration
This is the most expensive form of integration. Point-to-point integration is the pair
wise development of interfaces among systems. The data model of the target and
source system are known, and someone (e.g. a system integrator) develops the code for
passing information back and forth. Sometimes accelerator products are used, a good
example being the IBM MQSeries of middleware products that are now included as a
part of WebSphere. MQSeries does require writing code at both the source and target
system. The approach to point-to-point integration is well known, most frequently
involving changing both applications to use a middleware layer, by rewriting the
transaction handling code to communicate across the two applications. The traditional
model of interaction is through remote function calls.
The largest problem with point-to-point integration is shown in Figure 4, a situation
that Schäfer (2002) attributes to a customer situation.
IMDS
106,1

10

Figure 4.
Example of point-to-point
integration

As the number of interfaced components is increased, the number of interfaces to be

maintained increases dramatically. The TCO likewise increases. As a real example
consider the financial interfaces to a Navy SAP solution that is shown in Figure 5[6].
Figure 5 is a good example of the previously mentioned case that can arise when
financials are separated from materials or assets in an enterprise solution and then
must be interfaced back to the ERP product, violating the integrity of the solution.
While Figure 5 is reality and could not be easily avoided, the SAP product was
never intended to be implemented in this way. The integrity of the product is violated
by destroying the Big I that is engineered into the product. For all of the reasons
previously mentioned, point-to-point integration should be avoided and only be used
when there are no other options.

Database-to-database integration
This form of Little i, requires the sharing of information at the database level; hence,
providing interoperable applications. The basic replication solution leverages features
built into many databases to move information between databases as long as they
maintain the same schema information on all sources and targets. There are companies
that provide middleware to accelerate this process. Database and replication software are
provided by companies such as Pervasive’s Integration Architect and DataMirror’s
Constellar Hub that permit moving information among many different database products
with different schema. Figure 6 shows the conceptual layout for this form of Little i.
While this integration procedure may work well for database applications, it does
not work so well for enterprise applications. Most enterprise applications have
 What is
integration?

11

Figure 5.
Point-to-point integration
from defense financial and
accounting services to the
US Navy Pilot SAP
implementations

Figure 6.
Conceptual layout for
database-to-database
integration
IMDS multi-tiered architectures, where even though the applications reside at a separate tier,
106,1 the business process logic is “bound” to the master data. So, if one simply passes
information at the database level, it is easy to create data integrity problems.
Enterprise software vendors typically publish application program interfaces (APIs)
that allow interfacing at the application level, and it is best to use these APIs. If you
update the database without using the APIs, then you are violating the Big I that is
12 engineered into the product, and integrity problems are a likely result. See that
Anonymous (1999) article in enterprise development where some of these difficulties
are discussed within the context of interfacing with SAP’s R/3 product. For enterprise
implementations, this form of Little i should be avoided.

Data warehouse integration

This form of Little i is similar to database-to-database integration, but instead of
replicating data across various databases, a single “virtual database” is used to map
the data from any number of physical databases, which can be various brands, models,
or schema. In other words, a new data warehouse is created, and information is
aggregated from a number of sources, where it may be analyzed or used for report
generation. The effectiveness of this approach depends on the sophistication of the
tools that are used and the quality of the data that is pulled from the various sources.
Once the data are aggregated, reporting is straight forward; however, if business
process logic must be applied to the aggregated data, then that logic must be created at
the data warehouse level. The basic layout for data warehouse integration is shown
in Figure 7.

Figure 7.
Conceptual view of data
warehouse integration
If the integration is at the database level, the same problems associated with What is
database-to-database integration that were mentioned above still apply. If the integration?
integration is at the application level, then data warehouse integration is similar to
point-to-point integration, and the problems with that approach also apply. This form
of integration is quite popular, even though it is expensive to maintain. The reason that
data warehouse integration is popular, is that it allows all parties involved to maintain
their individual stove-piped environments while sharing selective data in a neutral 13
environment. In short, one is trading Big I for autonomy. An example of a large data
warehouse integration effort in the US Army is shown in Figure 8. The logistics
integrated database (LIDB) contains aggregates information from many stand-alone
systems, with the objective of providing enterprise-level analytics. As the figure
indicates, the input data are aggregated from many sources, and output data are
pushed to many sources. Constant cleansing and harmonization is required in order to
avoid integrity problems.
Many enterprise solutions, like those from SAP and Oracle, use data warehouse
solutions for reporting and enterprise analytics. However, this static view of enterprise
data are not the same as Big I. Even if the concept is extended to include a federated
query capability with the data warehouse being a virtual repository of metadata, this is
still no substitute for Big I. However, the big problem, as previously mentioned, is the
maintaining of business process logic at the data warehouse level. While this option
preserves organizational autonomy, it is indeed costly. The data that are pushed into
the warehouse must be constantly monitored for quality, and any changes in any one
of the target or source systems create significant testing and/or additional coding
problems.

Figure 8.
A conceptual view of the
LIDB
IMDS Enterprise application integration
106,1 EAI is the sharing of data and business process logic across hetero/homogeneous
instances through message-oriented-middleware (MOM). EAI may be managed by
packaged vendors (e.g. SAP and Oracle) or through solutions provided by third party
vendors (e.g. IBM, WebMethods, etc.). EAI is sometimes called application-centric
interfacing. EAI is used to connect multiple systems at the application or database
14 levels, using a form of middleware that is sometimes called a broker. The middleware
moves information in and out of multiple systems, using pre-engineered “connectors.”
The connectors are a source of competitive advantage for EAI software providers,
because if a connector already exists for the target and source application, the cost of
interface development can be reduced.
The problems associated with point-to-point integration are reduced by adopting a
hub and spoke model for sharing information. The EAI Middleware allows one to write
a single interface between each application and the middleware, instead of individually
connecting each application to every other application. An example of a hub and spoke
architecture is shown in Figure 9.
Once the information is extracted, it is sent to a central server using some sort of
messaging system, where the information is processed and routed to the target system.
If there is a gap in required business process logic, the logic can be created on the
central server for execution. In theory, any-to-any document swap is possible,
considering the business process logic in the source and target systems.
Using “connectors,” the EAI software processes messages from packaged
applications, databases, and custom applications using a queuing engine. When an

Figure 9.
Hub and spoke
architecture for enterprise
application integration
event occurs (e.g. a transaction in an ERP package or a database table update), a What is
message is published to the queue about the event. Subscribers to queue access the integration?
event envelope, analyze the content, and if it is intended for processing in the target
system, the envelope contains everything necessary for recreating the event in the
target system. The queuing engine ensures that all events are processed in the correct
sequence, ensuring transactional integrity.
Many companies provide pre-packaged EAI solutions, and the market is extremely 15
competitive. The hub and spoke model using connectors has been operational for many
years, and the products have reached a mature level. However, we note that EAI is still
interfacing, and while this is a significant improvement over point-to-point integration,
EAI can be costly to implement and costly to maintain. The main benefits flow from
being able to use “partially configured” connectors, while leverage industry
partnerships which yield certified interfaces. Tremendous consolidation has
occurred in recent years in companies that provide EAI solutions as the larger
software providers have moved in to provide EAI solutions that interact with their Big
I products. For example, SAP now supports EAI as part of its NetWeaver[7] solution,
where previously SAP had used third party providers like IBM and WebMethods to
provide EAI capabilities.
It is also important to note that EAI is typically used inside the enterprise, as
opposed to across the enterprise. For this reason EAI is sometimes called
application-centric interfacing. The objective is to interfaces processes and share
data within the enterprise. The inter-enterprise model falls under a class of solutions
that are called Business-to-Business eCommerce, and this form of interfacing will be
discussed in a later section.

Application server integration

This is the most sophisticated form of Little i that is discussed in this paper. Think of
application server integration as the creation of a single, centralized application (logical
or physical) that can provide a common set of services to any number of other remote
applications. These “services” are common business objects that are shared across
enterprise applications. The sharing and reuse of services is the goal of distributed
objects and applications servers. Application server integration enables the enterprise
by sharing services across the enterprise. The concept of application server integration
is shown in Figure 10.
Modern systems invoke shared objects to share business logic and interact with
resources (such as databases, ERP systems, or queues). In modern ERP systems these
shared objects may be more highly aggregated as “wrapped” transactions. For
example, when configuring the SAP solution, one aligns transactions with process
steps. A process step could be associated with one or more transactions. If the
transactions associated with a process step are bundled together and “wrapped” as a
web service, then they may be shared across other SAP and non-SAP components.
SAP calls this aggregated object an “Enterprise Service,” and it is the basis of SAP’s
Enterprise Services Architecture (SAP AG, 2004).
Application integration occurs through the sharing of business logic, as well as
through the back-end integration of many different applications and resources. The
application server “binds” the data from a relational or relational-object database to the
common shared objects. The main advantage of application server integration is that
IMDS
106,1

16

Figure 10.
Application server
integration concept

the interfaced applications or components are tightly coupled to each other by sharing
methods. By our assessment, application server integration is Little i, but given the
limits of current technology it is the best approximation that we can provide to
Big I. This is because the data integrity checks and business logic bound to the objects
are always shared, and therefore, never circumvented.
The SAP example is not unique. Most of the major software vendors have a similar
strategy. For example, Figure 11 shows the Oracle strategy for application server
integration.
The key component of Figure 11 for our discussion is in the right-center of the
figure. The Oracle Application Server manages the shared objects and during runtime
“Top Link manages persistence between java objects and database tables.” At the
conceptual level the integration approaches pursued by Oracle and SAP are similar.
The widely accepted disadvantage of using this application server integration is
that significant changes may have to be made to all source and target applications to
expose them around a common set of services (you may have to write object
wrappers[8]). For newer applications, most code is designed with a service-orientation,
alleviating some of the problems with older legacy systems. For a more comprehensive
discussion of the SAP application server offering, see Kangas (2005).

Business-to-business eCommerce
We include this section to clarify other sources of confusion. Independent companies
often execute electronic transactions with each other. While on the surface, this is
similar to point-to-point integration, it is different. B2B connectivity is the passing of
 What is
integration?

17

Figure 11.
Application server
integration within Oracle’s
service-oriented vision

data (not business process logic) through agreed-upon implementation conventions of

standards; e.g. electronic data interchange (EDI), extensible markup language (XML),
etc. Since business process logic is not shared, B2B connectivity is sometimes called
data-centric interfacing. This type of interfacing is broadly addressed in the literature,
and in many case, the term integration is used in this context. For a good example of
this literature, see Zeng and Phatak (2003).
As previously mentioned, the forms of integration discussed in this paper typically
deal with US army with the integration of applications and data sources within an
enterprise. Other features are required when interacting with external organizations;
e.g. community management, trading partner profile management, sophisticated
security mechanisms, and support for industry standards, such as open buying over
the internet (OBI), XML, and EDI.
In contrast, B2B connectivity is used to pass information to external constituents,
such as suppliers and customers. B2B connectivity could support any number of
business requirements, such as sharing information with trading partners to
support a supply chain or collaborating on a product design. B2B connectivity
includes many features that are absolute requirements for interacting with external
claimants, but it typically does not include the extensive business processes
integration that is required when interfacing to enterprise systems. The differences
between point-to-point integration and B2B connectivity are significant, even though
they both may employ middleware, such as message brokers, to exchange
information among various systems. Linthicum (2001) provides a good discussion of
these differences.
IMDS These are some of the distinguishing characteristics:
106,1 .
B2B connectivity typically focuses on the sharing of information with external
constituents, such as customers and suppliers, while other forms of integration
are typically focused within a bounded enterprise.
.
B2B connectively typically resides outside of the integration (Big I or Little i)
domain (e.g. at an application server or a translator), but functions in near
18 real-time and with limited end user influence. Since external constituents are
exchanging information, appropriate fire-walls must be in place.
.
B2B connectivity typically passes information using accepted industry
standards, such as XML or EDI, where integration considers the proprietary
business process configurations within enterprise software products.
.
B2B connectivity allows users who understand relatively little about internal
business process logic to pass information across organizations, where
integration requires a detailed knowledge of the business processes as they
are configured in the interfacing systems.
.
B2B connectivity requires that trading partners agree on implementation
conventions of industry standards. If agreement is reached, information can be
passed.
.
B2B connectivity assumes that the source and target enterprise systems cannot
be altered; hence, the passing of information is “non-intrusive” in the sense that
the business process logic of the interfaced systems is not affected. All passing of
information is though standard exit points.
.
B2B connectivity requires advanced security requirements, because the
organization is sharing information with external constituents.

Most organizations have needs for B2B connectivity, as well as other forms of
integration. Internal business processes and systems require enterprise integration
efforts, where external business transactions are processed through B2B eCommerce.

Summary and conclusions

Table I summarizes the taxonomy that we have developed for classifying the meanings
of integration.
The main purpose of the paper is to create a vocabulary for discussing issues that
relate to integration. While on the surface this may not seem so important, our
assertion is that the term “integration” is often used in research and trade documents
and conversations without a clear understanding of meaning. The result is circular
definitions that often lead to misunderstandings.

Integration Intra-organizational Big I

Point-to-point Intra-organizational Little I
Database-to-database Intra-organizational Little I
Data warehouse Intra-organizational Little I
Table I. Enterprise application integration Intra-organizational Little I
Classification of Application server Intra-organizational Little i
integration B2B eCommerce Inter-organizational Data exchange
No claim is made that Table I is exhaustive. The types of integration discussed What is
are most relevant for enterprise system implementation, and other forms of integration integration?
may be appropriate for extended research and other more sophisticated
implementations.

Notes
1. This quote appears in Ferguson and Callaghan (2002). 19
2. Some indication of the cost is provided in Gulledge et al. (2004).
3. See Woods (2003).
4. These business process extensions are often called “architectural alignment,” and we discuss
these issues in detail Gulledge et al. (2005).
5. See Gulledge and Sommer (2004).
6. This figure was taken from a presentation by Farrell (2001).
7. SAP’s EAI solution is know as the exchange infrastructure (XI).
8. Wrapper is a common term in the software development literature. See the paper by Sivan
and Venkatavaradan (2005) for the context of usage in this paper.

References
Anonymous (1999), “Integrate with R/3”, Enterprise Development, Vol. 1 No. 8, pp. 25-6.
Farrell, J. (2001), ERP Financial Interfaces, (Power Point Presentation), Defense Financial and
Accounting Services, August.
Ferguson, R.B. and Callaghan, D. (2002), “Tools to ease integration”, eWeek, Vol. 19 No. 15, p. 12.
Gulledge, T.R. and Sommer, R. (2003), “Public sector enterprise resource planning”, Industrial
Management & Data Systems, Vol. 103 No. 7, pp. 471-83.
Gulledge, T.R. and Sommer, R. (2004), “Splitting the SAP instance: lessons on scope and business
processes”, Journal of Computer Information Systems, Vol. 44 No. 3, pp. 109-15.
Gulledge, T.R., Simon, G. and Sommer, R. (2004), “Analyzing convergence alternatives across
existing SAP solutions”, Industrial Management & Data Systems, Vol. 104 No. 9,
pp. 722-34.
Gulledge, T.R., Hafez, W., Ledwon, M. and Svensson, C. (2005), “Solution architecture alignment
for logistics portfolio management”, International Journal of Services and Standardsin
press.
Kangas, M. (2005), Introduction to the SAP Web Application Server, SAP AG, Walldorf.
Linthicum, D.S. (2001), “Where EAI meets B2B”, Software Magazine, Vol. 21 No. 2, pp. 22-5.
SAP AG (2004), Enterprise Services Architecture: An Introduction, SAP AG, Walldorf.
Schäfer, T. (2002), SAP Exchange Infrastructure Architecture Overview, SAP AG, Walldorf,
(Power Point Presentation), (December).
Sivan, S.S. and Venkatavaradan, R. (2005), “Design guidelines: building web service wrappers for
an XML-based system”, DevX, available at: www.devx.com/enterprise/Article/27882
(accessed 19 April).
Woods, D. (2003), Packaged Composite Applications: An O’Reilly Field Guide to Enterprise
Software, O’Reilly Publications, Sebastopol, CA.
Zeng, A.Z. and Phatak, B.K. (2003), “Achieving information integration in supply chain
management through B2B e-hubs: concepts and analyses”, Industrial Management & Data
Systems, Vol. 103 No. 9, pp. 657-65.
IMDS Further reading
106,1 CrossWorlds Software, Inc. (1999), Enabling the Real-time Enterprise: Enterprise Application
Integration with CrossWorlds Software, CrossWorlds Software (Now IBM), Burlingame,
CA.
Joch, A. (2005), “Modern design”, Oracle Magazine, May-June.

20 Corresponding author
Thomas Gulledge can be contacted at [email protected]

To purchase reprints of this article please e-mail: [email protected]

Or visit our web site for further details: www.emeraldinsight.com/reprints

View publication stats