1. Architectural Integration Styles for Large-scale Enterprise Software Systems
Jonas Anderson, Pontus Johnson
f
Dept. o Industrial Information and Control Systems,
KTH, Royal Institute of Technology
Osquldas vag 12, SE - 100 44 Stockholm, SWEDEN
Gonasa, pontusj} @ics.kth.se
Abstract
A predominant problem in the management of largescale enterprise software systems is application
integration. Despite the considerable efforts spent on the
development of new standards and technologies f o r
software interoperation, the integration of systems that
originally were not designed io interact with each other is
f
a major undertaking, requiring in-depth knowledge o
existing systems, incorporation of integration products,
and development and/or parameterization of various
kinds of adapters and gateways.
This article presents the concept of architectural
integration styles, i.e. architectural styles describing
software structures of integration solutions f o r enterprise
software systems. The article further proposes an
approach f o r selection of styles based on the
characteristics of the existing software applications and
the desired quality attributes of the integrated system.
A number of architectural integration styles f o r
enterprise systems are presented in the article, and a case
study o the style selection process applied to a mid-sized
f
Swedish electricity retailer is described.
1. Introduction
Integration of software systems has during the last
decades become one of the most important, as well as
resource consuming, activities in enterprise software
system management. Enterprise software systems are
typically composed of a mix of legacy, custom, and
commercial-of-the-shelf software, and characterized by
large-grained,
heterogeneous
and
unmodifiable
components, and heterogeneous connectors.
As a result of the increasing focus on system
integration, there is a growing market for software
integration products and standards. The once fairly clear
market division has recently been blurred by component
technologies and standards like CORBA [20], COM [9],
and Enterprise JavaBeans [171 incorporating more and
more services. Typical integration solutions are
exemplified by remote method invocation, message
0-7695-1345-X’01/$10.00 0 2001 IEEE
queuing systems, transaction management systems,
message brokers, adapters, and database connectivity
solutions [7] [16] [21] [22].
This article considers architectural styles [14] as a
means for design of integration solutions for enterprise
software systems. The article argues that architectural
styles on the level of enterprise software systems can be
used as generalizations of common integration solutions,
much in the same way that styles and pattems are used in
traditional software architecture and design. In other
words, architectural integrations styles may be seen as
generalizations of historically successful solutions to
common problems. The perhaps most interesting part
about architectural styles is that they are believed to
impact software quality attributes. Certain styles are more
appropriate than others for achieving certain quality
attributes in a system. It is consequently desirable to
classify “good” architectural styles and employ them when
certain goals are sought.
There are, however, a number of differences between
traditional software systems and enterprise software
systems that need to be taken into consideration. The
article assumes that the components of enterprise software
systems are unmodifiable. This is not always the case, but
whether it is or not, on the enterprise system level, it is
almost always desirable to construct non-intrusive
integration solutions, justifying the view of components as
unmodifiable. As a consequence, the article examines
enterprise software architecture from the aspect of systems
integration. This focus delimits the problem nicely,
permitting a structured analysis based on a manageable
number of variables.
1.1. Purpose of the article
The purpose of the article is to propose an approach for
selection of integration solutions, based on architectural
integration styles for enterprise software systems. To
promote this, a structure for describing architectural
integration styles is presented. To firther strengthen the
feasibility of the approach, a number of architectural
styles are presented. The approach and the presented
styles are subsequently considered in the context of a
224

2. systems integration project in an energy company on the
Swedish energy market.
1.2. Definitions
Below, some in the article recurring terms are defined.
Architectural style. Before describing architectural
integration styles for enterprise software systems, we need
to define architectural styles in general. According to
Alexander et al. [I], reiterated by Gamma et al. [12], a
pattern “describes a problem that occurs over and over
again in our environment, and then describes the core of
the solution to that problem, in such a way that you can
use this solution a million times over, without ever doing
it the same way twice”. According to Bass et al. [5], an
architectural style is the same thing as a system pattern (to
be differentiated from design and code patterns). Bass et
al. define architectural styles (or system patterns) as 1) a
set of component types, 2) a runtime topological layout of
these components, 3 ) a set of semantic constraints, and 4)
a set of connectors.
Enterprise software system. The total interconnected
system of systems and applications within an organization.
Thus, in an enterprise software system, software systems
that from a vendor view may be considered as large and
complex, are in an enterprise software system considered
as components.
Enterprise software architecture.
The
model
description of an enterprise software system, consisting of
more or less structured and/or explicit descriptions of the
source (present), intermediate, and target (intended)
architectures. In addition, technically outdated but
commonly business critical and/or inadequately
documented source architectures are commonly termed
legacy enterprise software architectures. This article
advocates architectural integration styles as a prominent
part in such architectural descriptions. Accordingly,
components in these different architectural descriptions
are termed legacy, source, intermediate, and target
components.
Architectural integration style. An architectural
integration style is in this article used to denote a
generalization of a historically successful integration
solution on the level of enterprise software systems.
Integration styles are further elaborated on in the
remainder of the article.
Base components. The term base component refers to
the original components introduced for hnctional rather
than integration purposes. Contributing to the selection of
base components are legacy components, available
packaged components, organizational needs, and business
vision. In this article, the base components are considered
as the main building blocks in the architectural integration
styles.
1.3. Outline of article
Section 2 discusses the main differences between
traditional single-vendor software systems and enterprise
software systems. Section 3 presents a structure for
describing architectural ‘integration styles for enterprise
software systems as well as the rationale for using such a
structure. In Section 4, a number of architectural
integration styles for enterprise software systems are
described. Analyzed styles include the gateway style, the
adapter style, the point-to-point style, the mediator style,
the message router style, the database federation style,
and the desktop integration style. Section 5 presents a
case study of the selection of architectural integration
style for an enterprise active on the Swedish energy
market. The styles in Section 4 are considered in the
context of an extensive application integration project.
Section 6 concludes the article with a discussion on the
findings of the research.
2. Large-scale enterprise systems
To support the article’s attempt to use the concept of
architectural styles on enterprise software systems, this
section presents the main differences between singlevendor software systems and large-scale enterprise
software systems. The main themes of the differences
stressed in this article are the latter system level’s
heterogeneity of interconnected architectural entities, and
the strive for maximizing the use of packaged software,
thus limiting cost and risk, but also the degree of freedom
regarding changes and replacement of components
compared to custom development. Hence, the
architectural design space for enterprise software systems
becomes rather discrete in terms of feasible design
alternatives, and the share of the total effort spent on the
parameterization and adaptation of components and
connectors is considerably larger.
The total enterprise software system in a medium-sized
enterprise may comprise of more than a hundred
interconnected components with different degree of
interaction [8]. Traditionally, systems have been
developed and customized from scratch in order to fulfill
the specific requirements for one organization. Some
notable characteristics of the elements in an enterprise
software architecture are briefly highlighted below [3].
Components are large-grained. Enterprise software
components reflect the chunks of software that the
organization wishes to makes explicit in order to maintain
a high level of freedom regarding the quality attributes
focused upon. Thus, enterprise software components are
often fairly large-grained, as they tend to reflect available
packaged software components, legacy software
components, and management goals. For instance,
225

3. complete systems such as customer information systems
and geographical information systems might be
considered as components in enterprise software
architectures [ 161.
The supply of packaged components is limited. The
number of on the market available large-grained
components is always limited. Often components with the
desired hnctionality do not exist, forcing enterprises to
either develop those components from scratch or combine
packaged software to fulfill the requirements of the
component.
The legacy architecture constitutes the starting
point of the system development effort. Enterprises
have to take their legacy software components under
consideration. These components often constitute a
significant asset that may not be easily replaceable without
severe disturbances to the business operations [6].
The enterprise software system may contain both
data and functional redundancy. The use of packaged
components increases complexity since those components
rarely correspond completely to the organization’s
requirements. In order to grasp the bulk of the
requirements, different packaged components are
combined with custom-developed components, such as
adapters, wrappers, and gateways [6] [ 161, often resulting
in both functional and data redundancy. Data and
hnctionality can also be virtually redundant, i.e. similar
but not identical, causing further inconsistencies in
enterprise databases [4].
Components are not modifiable. Since enterprise
software systems to a large extent consist of packaged
software, changes to the system cannot be performed
directly on the base components. Normally, the source
code is not available, and if it were, changes might violate
the components’ commercial status as packaged software.
Therefore, changes to the system are preferably handled
indirectly, either by influencing the software vendor to
adapt its packaged product in coming releases, or by
implementing non-intrusive modifications, e.g. by
wrapping the component in order to change its external
behavior.
Components are heterogeneous. In an enterprise
software system that to a large extent is composed of the
combination of packaged and legacy components from a
wide range of vendors, epochs, and intended purposes,
uniform system components normally proves hard, costly,
and often even inappropriate to realize.
Connectors are heterogeneous. Connectors in an
enterprise software system are by nature diverse since
their main purpose is to glue heterogeneous components
together. Moreover, connectors do not only interface with
other components within the same enterprise software
system, they also provide interfaces to other
organizations’ software systems bringing even more
heterogeneity into the enterprise’s total battery of
connectors.
3. Describing architectural integration styles
for enterprise software systems
Traditional development is a creative process where
the components are defined and the functionality is
determined and allocated along with the selection of
architectural style. Because of these parallel processes, the
degrees of freedom are innumerous, making controlled
decision processes hard to implement.
When developing integration solutions of the kind
discussed herein, the components are unmodifiable and
the functionality is determined and allocated beforehand.
These limitations make it far easier to structure the
process of style selection.
Assuming that the main style selection process starts
after the base components have been chosen, this article
proposes that selection of architectural styles for
enterprise systems can be based on the characteristics of
the individual base components and the desired quality
attributes of the resulting system.
In other words, applying an architectural style on a
certain set of components yields some specific quality
attributes. To relate this to Alexander et al. [I] and
Gamma et al. [12], the problem is described as a set of
components and a set of desired quality attributes while
the solution is the style definition. This is not a new
definition of styles but a reformulation adapted for
architectural integration styles for enterprise software
systems.
To make the style selection process straightforward,
styles need to be described in three parts. Firstly, the style
must be defined. Secondly, the constraints that the
components are subject to (these are part of or
consequences of the style definition) should be described.
Finally, the quality attributes that the resulting system
displays need to be examined.
Perhaps the most problematic issue with architectural
styles, whether they are limited to enterprise software
systems or not, is the identification of all the relevant
component constraints and resulting quality attributes. In
this article, a basic set will be considered without claiming
any kind of completeness. Below, we present the basic
parts of a style description.
3.1. Style definition
In the proposed style description, the definition is thus
expressed as one or several constraints on components,
connectors, semantics or topology. These defining
constraints may imply other constraints (e.g., a constraint
on connectors is often also a constraint on the component
226

4. interfaces). In the style definition, the primary constraints
are described.
3.2. Quality attributes
Architectural styles are principally believed to impact
quality attributes of the resulting system [IS]. The
resulting characteristics are therefore described in terms of
“ilities” [19]. As such, a number of quality attributes are
considered in Table 1 . The table is by no means a
complete account of quality attributes, and the hierarchical
division is not claimed to be the only possible division.
Perhaps the most obvious component constraint relates
to the component types allowed by the architectural style
(stand-alone components, database components, etc.).
There are also a number,of constraints related to the
things that one component needs to know or manage about
a collaborating component. This includes collaborator
location and availability, information such as transfer
protocol [IO], data format [18], schema, and content
(including method signatures and interfaces) as well as
architectural assumptions [ 1 I ] [ 131.
Furthermore, there may be constraints on the types of
access that the component must provide, e.g. interface
access to the database, to the application logic, or to
internal objects of the component. Interfaces can
furthermore be subdivided into full-service, limitedservice, and controlled interfaces [ 161.
3.4. Organizing styles
Styles are related to each other in several different
ways and a clear organization of proposed styles may help
both in the use of and in the proposition of new styles.
The two most important relations are the sub-style and
uses relations. A sub-style is constructed by adding
constraints to its parent style (or meta-style). A uses
relation indicates that one style typically uses another
style.
components
accessibility
User
functionality
accessibility
I
I
Adapter
How much of the functionality that is accessible to the
end-users.
Point-to-Point
Table 1. Quality attributes
Also note that most quality attributes are directional
(the more of the quality attribute the better); a style that
improves many quality attributes is better than a style that
only improves one. Also, the easier it is to combine a style
with other styles without affecting the quality attributes
(the more orthogonal the styles are), the better it is.
3.3. Component constraint dimensions
Component constraints are either part of, or results of,
the style definition. As argued before, however, it makes
sense to express these constraints separately and in more
detail in the case of integration of unmodifiable
components. Connectors are treated more en passant since
they are not decided on beforehand.
Figure 2. “Uses”and sub-style relations between
presented architectural integration styles.
Another way of relating styles is by the type of
architectural constraints that they impose. On the topmost
level, constraints maybe divided into component type,
connector, topological, and semantic constraints.
A third set of dimensions for relating styles are the
quality attributes that they supposedly support.
Particularly interesting to note is that the quality attributes
of the styles are most easily expressed using a
comparative approach, since it is difficult to e.g. express
the scalability of one style without referring to another
style.
227

5. L L
------
r-----
I
Source
I
I
J
L
-
%
-',
Target
Amiication
-----I
I
I
Application
I
I
+I
i-
Component
L-----
The Screen-Scraping, Application, and
Database Gateway Style
The Desktop IntegrationStyle
The Message Router Style
m
Component
Component
Component
The Database Federation Style
The Point-to-Point Style
The Adapter Style
Figure I Architectural integration styles. Note that the gateway, the desktop integration, the message router,
.
and the database federation architectural integration styles all are sub-styles to the general mediator style.
Therefore, the mediator style is not explicitly illustrated in the figure.
4. Examples of architectural integration
styles
In this section, a number of architectural integration
styles for enterprise software systems are presented. The
styles are diverse and are not selected based on any
specific principle. Each style is described according to the
structure discussed in the previous section, including a
style definition, supported quality attributes, and
component constraints. The considered styles are the
gateway style, the adapter style, the point-to-point style,
the mediator style, the message router style, the database
federation style, and the desktop integration style.
4.1. The gateway style
The gateway style summarizes many ideas behind the
system migration approach of gradually altering complex
software system, e.g. summarized in [6]. Consequently,
the purpose of the gateway style is to allow direct
integration between two systems on the data or application
logic level. These two systems are normally referred to as
the source and target enterprise system. The gateway style
assumes that at least the source system is composed of a
database component, an application logic component, and
a user interface component. However, these may or may
not be separable (and whether they are often determines
the gateway sub-style employed). As is shown below,
gateways come in many colors and forms.
Style definition. The gateway style is defined by the
introduction of a component for direct interface mapping
between a source and a target system. The style is
divisible into several sub-styles based on the type of
source systems and the means for communication. A
database gateway encapsulates a database from the
application logic in the source component by providing a
new database management interface suited for the target
component. Application gateways, or adapters,
encapsulate the application logic and the data by
providing the source component with an application
interface compatible with the target component. The
screen scraper gateway is an application gateway that
connects to a (legacy) source component by tapping into
the data stream originally intended for the terminal.
As the name implies, the static gateway binds the
interfaces at design-time, while the dynamic gateway
allows runtime binding. A thin gateway provides nothing
but interface binding, while a thick gateway also includes
transformation of data format and schema.
228

6. The gateways may offer forward translation of calls
and data from a source component to a target component
and/or reverse translation from a target component to a
source component.
Quality attributes. The gateway style is intended to
provide integration of methods and data in a non-intrusive
manner. Component accessibility is therefore the main
benefit of the style. Database gateways have no effect on
functionality accessibility while application gateways may
or may not improve data accessibility.
A static gateway makes the integrated system less
modijiable than a dynamic gateway because minor
changes in any base component may necessitate a change
in the gateway. Dynamic gateways are designed to
manage some of these changes run-time. Dynamic
gateways may further increase the modifiability by selfparameterization through probing of the base component
when first connected.
For database gateways, forward translation facilitates
the accessibility of source data and functionality for the
target system, whereas the reverse translation primarily
addresses the issue of data consistency.
Given that the gateway is well implemented, it will
have moderately negative effects on performance, and no
effects on reliability or security per se. However, e.g.
reliability and security of the integrated system may be
compromised by unmanaged architectural assumptions.
Components. The database gatewqy requires the
separation of the source database from the rest of the
source component as well as access to the database. On
the back-end, the gateway interfaces with the database and
on the front-end, it interfaces with the application logic of
the target component.
The application gateway requires the separation of the
user interface and the rest of the source component as well
as access to the application logic. The back-end interfaces
with the source component’s application logic while the
front-end interfaces with the target component’s user
interface and/or application logic.
The back-end of the screen-scraper gatewa-v interfaces
with the source component’s application logic. As with all
application gateways, the front-end interfaces with the
target component’s user interface andor application logic.
The whole point of the gateway style is to let both the
target and source components remain oblivious of its
counterparts’ interfaces, data formats, locations, etc., as
well as of the specificities of the gateway.
4.2. The adapter style
interfaces. It is closely related to the gateway style; it is
however presented as a style in its own right because of its
common usage.
Style definition. The style introduces a component
between a mediator, for instance a message router, and a
base component, for interface binding and transformation.
As for gateways, static adapters bind the base
component interfaces at design-time, while dynamic
adapters allow runtime binding. The thin adapter
provides nothing but interface binding, while the thick
adapter also includes transformation of data format and
schema.
Centralized adapters run on the same node as the
mediator (and possibly even in the same process space)
and are normally thin. Distributed adapters on the other
hand reside both on the source and the target node and are
normally thick.
Quality attributes. The characteristics of adapters are
the similar to those of application gateways. Their main
benefit is thus component accessibility of functionality
and data. A drawback is that adapters often need to be
modified when the source application is upgraded (this is
more true of thin and static adapters than of thick and
dynamic).
Distributed adapters have the advantage of closeness to
the source or target component, making it easier to
supervise and control the application, e.g. restarting it,
capturing events, etc. Also, coordination of the interaction
between the mediator and the source or target component
is easier dealt with when the adapter resides on both sides
of the communication.
Components. On the one end of the adapter, a base
component is located, and on the other sits a mediator
component (e.g. a message router).
The base component does not need to have any
information about the mediator, while the mediator needs
to mange information about the adapter’s location,
availability and possibly also the base components (and
adapters) architectural assumptions. If the adapter is thin,
the mediator may also need to know the data format and
schema of the base component’s data (although it might
just pass the problem of data interpretation on to the
collaborators).
The base component needs to expose its application
logic interfaces either (and preferably) as APls, or through
screen-scraping. If the base component does not expose
functionality in a (for integration purposes) reasonable
manner, this will likely become a major concern for the
whole integration process.
The purpose of the adapter style is to allow integration
between mediators (such as message routers) and base
components. The style provides a binding and
transformation between mediator and base component
229

7. 4.3. The point-to-point style
The point-to-point style is perhaps the simplest style to
implement for small systems, featuring as direct
communication between components as is possible.
Style definition. The main conceptual feature of this
style is that all inter-component communication is direct
or when necessary, via (thin) gateways, i.e. each
component is connected using static binding to those
collaborators with which it needs to communicate.
There are many sub-styles of the point-to-point style.
These include synchronous or asynchronous point-topoint, queued, or direct point-to-point.
Quality attributes. The style can be used for limited
both user and inter-component data access as well as for
limited user and inter-component function access. The
accessibility may be limited since a target component or
graphical user interface (GUI) may not be designed to
invoke functions offered by a source component. The
common functionality and data is thus reduced to the least
common denominator of the interconnected base
components.
The style is easily implemented for systems with a
small number of components but quickly becomes
unwieldy as the number of components increases, since
the number of connectors increases rapidly. Hence, the
point-to-point style does not scale well. In the worst case,
the number of connectors becomes n(n - I ) ,where n is the
2
number of components. Furthermore, the more
heterogeneous the component interfaces are, the more
gateways are needed.
The style may also result in a weak security system. If
the components have different security standards, these
may be highly problematic to integrate, in the worst case
these need to be negotiated as many times as there are
connectors. Further, the style is not very efficient for
managing data consistency, since this requires all affected
components to be notified when data changes in one
component. Since users may change data in all systems
(no single point of data entry), all components must be
able to notify all other affected components of the data
change and all must be able to accept and act on such
notifications.
Components. The components in the point-to-point
style need to be active stand-alone components. Since all
intelligence is located in the base components, they need
to be more or less compatible from the start. For instance,
one component must be designed to ask for certain data
and another to be able to provide it. Integrating a
component that is based on the assumption that the
communication is synchronous with a component with an
asynchronous assumption may further cause difficulties,
which indicates potential problems of transfer protocols.
As indicated above, the more similar the components are
(as to GUIs, security standards, etc.), the easier they will
be to integrate. This goes for most styles, but becomes
particularly pertinent in this case because of the rapid
growth of integration surfaces as the number of
components increases. The style does not include
directory services or other mediators, which means that
the components need to have (certain knowledge about
their collaborators. They need to know the location of the
collaborators, the interface signatures, data formats and
schemas, they need to be able to manage temporary
unavailability of collaborators, etc. Some of these issues
may however be managed using gateways.
Finally, the components need to provide access to the
relevant data and functionality through application
interfaces.
4.4. The mediator style
The mediator style features a central component
implementing services to simplify integration. All styles
presented below are sub-styles to the mediator style.
Style definition. The main feature of the mediator
style is the introduction of a new central component
providing services facilitating integration. These services
may include load-balancing services, transformation
services, routing services, etc.
In the middle-tier mediator sub-style, client
components are located on one end of the mediator and
server components on the other. In the peer-to-peer
mediator sub-style, all components may act as clients or
servers.
In the hub mediator sub-style, all traffic is directed
through the mediator, and no additional point-to-point
connections are allowed between components.
Quality attributes. The characteristics of the mediator
style vary markedly depending on the services provided
by the central component. However, the centralized
topology of the style, and in particular the strict rules of
the hub mediator sub-style, may have effects on the
reliability, providing a single point of failure; on
scalability, minimizing the number of connectors; on
security, permitting the deployment of a centralized
authorization and access control system; on accessibility,
providing a single point of information exchange; and on
performance, in particular for the middle-tier sub-style,
permitting distribution of loads among servers. Just as
with the point-to-point style, the accessibility may be
limited if target components or GUIs are not designed to
invoke functions offered by source components. The
common fhctionality and data is thus reduced to the least
common denominator, implying that the style is best
suited for similar components.
230

8. Components. Components can be of any kind in the
general mediator style. Sub-styles do however normally
limit the options. All components need to be designed for
interaction with the mediators. In many cases, however,
adapters can provide these capabilities.
4.5. The message router style
The message router style allows components to remain
unaware of the specific locations and availability of their
collaborators.
Style definition. The message router is a hub and
peer-to-peer mediator style with a central component that
directs information between the base components based
on the content or source of the information. All intercomponent communication is routed through the central
component. A message queuing service is typically
provided by the message router.
Quality attributes. The message router reduces the
complexity and thus scalability problems of the point-topoint style topology. The previous worst-case scenario of
n! connectors (where n is the number of interconnected
components) is reduced to a worst case of n connectors,
since all base components communicate via the mediator.
As with all mediator styles, a single-point-of-failure may
decrease reliability. The message queuing service may
however increase durability of information if persistent
storage is provided. Authentication and access control can
be provided as additional services on top of the message
router. Encryption must be provided at the component
level for message protection. Accessibility is similar to the
point-to-point style.
Components. The components in the message router
style are typically stand-alone components. The style
requires that the transmitting components know the
address, availability, transfer protocol, and interfaces of
the router. If the components are not designed to
communicate with the router, adapters may be employed.
The availability of the recipients normally becomes
unimportant for the sender because of the message
router’s queuing service. The sender needs to know only
the data representation format and content expected by the
recipient. Severe performance problems may occur if a
component is designed for direct synchronous
communication, since the message router is based on an
asynchronous communication model. The calling
component may, e.g. block its execution waiting for the
competition of a request sent to an unavailable server
component while the message router queues the message
without generating errors. These problems are, however,
not unique for the message router style.
Components need to be able to send and receive
messages. Adapters can often package API calls as
messages if the component does not provide this
capability.
4.6. The database federation style
The database federation style is employed in order to
integrate heterogeneous databases and to provide a unified
view of their contents to the database users.
Style definition. The style is a middle-tier mediator
style; the back-end of the central component is connected
to several databases while the client-end provides a
uniform interface to client applications, creating a virtual
database model containing the information of the source
databases. The virtual database may also be physically
replicated creating a data warehouse sub-style.
Quality attributes. The database federation style is
mainly aimed at improving data accessibility, isolation,
and consistency. The centralized control over the data
stores makes these objectives feasible. Modifiability is
improved in the sense that new client applications only
need to adhere to one database management system
interface, and new databases only need to interface to the
central component. Security is easier to implement than in
the point-to-point style because of the single-point-ofentry. The vulnerability is however also increased because
of the single-point-of-failure.
Components. The back-end components of the
database style are database management systems of
various kinds. These components need not know anything
of the collaborating components and they may in principle
feature any DBMS interface.
The
client-end
components
are stand-alone
components and need to know everything (address,
interface formats, etc.) about the mediator component, but
nothing about the back-end databases. They need to
access the central unit but need not necessarily provide
any interfaces of their own.
4.7. The desktop integration style
The desktop integration style offers a pragmatic
alternative to more ambitious approaches to integration by
employing the user interface as the main point of
integration. The main usage of this style and its obvious
advantages are for the rapid deployment of new user
interfaces without changing the bulk of the underlying
components, e.g. for giving a new look-and-feel to legacy
systems or to provide a unique user view for a specific
purpose. Further, the user interface component may be
supplemented with a gateway component to increase the
inter-component interaction.
Style definition. The desktop integration style is a
mediator style where a new user interface is employed as
integrator of disparate stand-alone components.
23 1

9. Depending on whether the interface component is thin or
thick, the style may also provide gateway functionality in
terms of function and data synchronization between
components.
The thin desktop integration sub-style introduces no
new functionality, simply visualizing the components
functionality and data in a new user interface. The thick
desktop integration sub-style adds an active component
providing some gateway fimctionality to the solution.
Also, new functionality may be introduced using the GUI
as the gateway mediator.
Quality attributes. The thin desktop integration substyle provides user accessibility to both functionality and
data. If the interface is well implemented, the user is able
to perform the same functions and access the same data
using the new interface as by using user interfaces of all
the base components. Components cannot however,
access functions and data of the other components; all
inter-component interaction must be mediated by the user.
Data consistency, atomicity, isolation, durability, and
security are not managed by the sub-style. Introducing a
new component or upgrading an existing one may
necessitate redevelopment of the user interface.
Furthermore, the usability of the system is probably poor
since the user faces several applications in one GUI.
Introducing a gateway component, the thick desktop
integration
sub-style
improves the
component
accessibility of both functionality and data. The gateway
may for instance be used to manage data consistency or
security between the base components. Dependencies
introduced in terms of static bindings to underlying
components may, however, require that changes in
components, either directly or by hard-detected side
effects, must be reflected in GUI. Hence, complexity and
upgradeability are inflicted.
Components. The components connected to the thin
interface are stand-alone components. Typically these
components are in themselves complete application
systems with a database, application logic and a user
interface. The user interfaces of all of the components are
replaced with the new CUI. The base components need
not manage any information about the other base
components, the user interface and the optional gateway
do however need to be aware of the locations, interfaces,
availability, etc. of the base components.
5. Application of architectural integration
styles
This section exemplifies the use of some of the
architectural integration styles previously described. The
example is based on a participatory case study of the
acquisition of a business system for a mid-sized electricity
retailer, active on the deregulated Scandinavian energy
market.
Architectural integration styles may be utilized in
several ways. To select a suitable style for a given
scenario, the base components need to be described and
the desired quality attributes of the resulting system need
to be specified. Having completed this description, the
characteristics of the base components can be compared to
the component constraints of the different architectural
integration styles and the desired quality attributes can be
compared to the attributes supported by the architectural
integration styles. These comparisons reveal the style that
best suits the base components and the desired quality
attributes. Because of the high cost associated with custom
development, the most preferred styles need to be
compared with the products available on the market to
determine which parts of the integration solution that can
be procured as third-party products and which parts that
need to be custom developed.
5.1. The initial scenario
The enterprise under study was recently formed by the
merger of the energy sales departments of five
municipality-owned electric utilities into one organization.
As a consequence, five completely disparate organizations
had to be integrated without a single day out of operation.
The functional areas for the target architecture were sales
and marketing, customer relations, electricity trading,
new interfaces towards customer and partners (e.g.,
Swedish national grid, large customers, and banks), and
basic administration (e.g., billing). In some of the
hnctional areas, one or several legacy systems were
already in operation, while other functional areas totally
lacked system support. In order to quickly reap some of
the benefits of the merger while maintaining business
operations, rudimentary scripts andor spreadsheet
applications were used as temporary solutions for the
exchange of information between the legacy components
and the compilation of this information. However, the
degree of automation was low, demanding considerable
manual intervention to provide a reasonable flow of
operations. This case has previously been discussed from
an enterprise architectural analysis process perspective
in [3], and from the perspective of strategic information
systems planning in [2].
Base system. The resulting enterprise software system
consisted of five different sets of geographically
distributed legacy enterprise software systems (to maintain
a consistent terminology, the legacy systems are hereafter
called components). The enterprise software system thus
contained a complex collection of legacy systems
(especially with regard to the large and complex
databases) and extensive use of large-grained packaged
232

10. components, such as customer information systems,
billing systems, energy settlement systems, and sales
support systems. Furthermore, the system revealed nonmodifiable, heterogeneous components, overlapping data
and functionality, and rudimentary and heterogeneous
connectors ranging from object brokers to the exchange of
flat files.
The legacy components were based on four
significantly different approaches; two installations were
minicomputer-based customer information systems, one
was based on an outsourced mainframe solution, one was
a small-scale client-server type of system, and one
installation was a large-scale bespoke developed clientserver system. All but the bespoke developed system were
packaged applications that were also used by several other
energy companies, and consequently maintained and
upgraded in regular releases.
None of the legacy components were designed to
interoperate with other applications. All provided limited
data interfaces, allowing reading of database data but not
writing, and only one component provided an application
programming .interface (API), the remaining components
application logic only accessible by means of screenscraping. Only the bespoke component was designed to
use external services for locating and managing
availability of collaborators. All components featured
proprietary data formats and schemas. The one component
that featured an API did not conform to any wellestablished standard.
Initial architectural style. Describing the initial
system in any specific architectural style is most
straightforwardly done in terms of the point-to-point style,
since most connectors provided simplistic one-to-one
connections (heavily relying on file transfer). Message
passing and data formats were constructed ad-hoc by the
use of proprietary formats, with the exception of
settlement measurement data that was expressed in an
Electronic Data Interchange (EDI) format derivate, and
that was based on a message routing product. As message
passing was asynchronous and batch-oriented, i.e. files
were transferred regularly for instance once every 24Ih
hour or weekly, transaction atomicity was poor.
Moreover, since enterprise data were distributed on
several databases (and in several cases redundant), dhta
consistency was inadequate.
Before the company merger, the components, their
interconnections, and the data managed in the architecture
were of limited number and size. Hence, given the limited
complexity the point-to-point style proved adequate. But,
the company merger called for a more coherent view of
the new organization’s total enterprise software
architecture. Since new connectors and adapters had to be
applied for every new inter-component interaction,
complexity accelerated with each additional component
introduced into the architecture.
In the remainder of this section, the process for
selecting feasible design alternatives in terms of
architectural styles is hrther elaborated.
Desired quality attributes. Starting with the
enterprise’s business requirements, high-level quality and
functional requirements of the new enterprise software
architecture were formulated. This effort led to a refined
set of requirements. In that stage of the process, the
functional requirements mainly served as the rationale for
determining which base components to include in the
target architecture. From an initially rather long list of
desirable quality attributes, a limited set to focus upon was
selected. The quality attributes hereby addressed were
modifiability, reliability, accessibility, and performance.
5.2. Architectural integration styles
This section exemplifies how architectural integration
styles may be employed by demonstrating some of the
main design alternatives from the selected case. Some of
the design alternatives omitted in this case description
circumvented the architectural problem by either
outsourcing the complete operation to a service provider
or by procuring a turn-key, packaged system that was not
intended to be decomposable into smaller components. It
is also stressed that some styles, such as the transaction
management style and the publishhbscribe style are
omitted since they were not reflected in any of the design
alternatives in the case study.
The investigated styles were Adapter, Desktop
integration, Message router, Gateway, and Database
Federation. All styles but the first two were used as the
basis (solitary or in combination with other styles) for
different design alternatives. The adapter and transformer
styles played an important role in the implementation of
the other styles, but were not considered as primary design
drivers; rather, they provided informative constraints on
whether the main design alternatives were feasible or not.
The presentation order of the styles differs somewhat from
Section 4 due to pedagogic reasons.
The adapter style. During the style selection process,
the styles discussed under the headings below provided
the basis for the main design alternatives. Because of the
diverse interfaces provided by the base components,
prohibiting direct inter-component access to data as well
as hnctionality, adapters were considered for all
integration styles based on mediators. Adapters do,
however, only increase accessibility by binding and
transforming interfaces. The limited-service base
component interfaces (e.g., allowing database reading but
not writing) remain limited even after the introduction of
an adapter. In most cases, available adapters were static,
i.e. bound to base component interfaces at design-time,
233

11. and thick in order to cope with significantly differing data
schemes and formats in source data components.
As a result, an important trade-off was between
spending resources on data conversion in order to limit the
number of concurrent (and redundant) data components,
or on implementation and/or parameterization of adapters
to pave the way for mediator integration styles.
The desktop integration style. From a component
view, the main benefit of the desktop integration style is
that it is applicable to almost any components. This was
also the case for the studied base components. As a first
integrating step to create uniform business operations,
although the enterprise was spatially distributed, the
desktop integration style was considered, since it is
designed to improve user accessibility to both data and
hnctionality.
Both the thin and the thick desktop integration substyles were studied. The thick desktop style, also
providing gateway functionality is discussed below
together with the gateway style.
Application of the thin desktop integration style was
considered in order to hastily tie systems together
adapting to the new business and organizational
requirements, e.g., GUIs that were adapted to a specific
user group or business process.
In its most simplistic form, the user was considered as
the intelligent mediator by allowing the user access to
more than one legacy component through the client CUI,
e.g. by accessing the underlying systems directly using
their native user interfaces (if required using for instance a
terminal emulator as adapter/connector), and the functions
included in the client GUI, such as “cut and paste” to
ensure the proper exchange of data between components.
The main advantage of the thin desktop integration
sub-style was that it did not require any programming and
none, or only sparse, parameterization since the
integration functionality was “implemented” through
trained users.
However, in order to implement the thin desktop
integration sub-style, extensive user training had to be
carried out due to source components’ heavily diverse
user interfaces. Also, it was early revealed that the substyle could not be fully implemented since the users then
would have to be fully trained to operate four totally
different user interfaces. However, implemented in a
limited scale and combined with some organizational
changes, the style offered some ease of the burden. But,
the design alternative had severe shortcomings as to
modifiability mainly in terms of scalability.
The message router style. The benefits of a message
router style include accessibility and modifiability (mainly
in terms of scalability). For two major parts of the source
architecture, the message router style was already applied,
which provided useful information in the architectural
planning process.
Firstly, the bespoke developed client-sever application
mentioned above employed a commercial message
oriented middleware product bolh for interaction between
components within the application, and with
interconnected legacy enterprise components. However,
the experiences from this effort were deterrent. Since the
base components were not selected from an integration
perspective, information exchange between components
could not be controlled and turned out to be both complex
and voluminous. Hence, both performance, and reliability
suffered. Moreover, the remaining legacy base
components were not compatible with the considered
message router e.g. as to data formats, data schemas, data
interface signatures, or location and availability
management. Since these incompatibilities required
powerful adapters that were not available on the market,
the necessary resources for developing these adapters
from scratch became significant.
Secondly, as mentioned above, all energy measurement
related information was, due to the regulatory framework
on the electricity market, exchanged in a common
message format (EDlel, an Electronic Data Interchange
format derivate) using a packaged message router product.
The message router was employed both for internal
interactions among components in the enterprise system,
and externally to connect to systems located at other
energy companies or at the Swedish National Grid
authority. For its intended purpose, the message router
functioned well, proving itself as a simple, stable and
flexible solution. However, its real-time performance was
poor and it had limitations in its transfer protocol (e.g.
making it unable to provide transaction atomicity). Thus,
making this design alternative inappropriate as a generalpurpose message router mediator.
The gateway style. Ensuring a high degree of
modifiability in terms of both scalability and
upgradeability was the prime reason for making use of the
gateway style in one of the design alternatives. Legacy
considerations, especially with regard to legacy data, were
a major consideration throughout the architectural
planning process. As a result, the database gateway style
was considered, to allow new components to be added or
phased out gradually. A contributing factor for this was
that several of the legacy components in operation served
their purpose well, and the wrapping of these components
was initially expected to allow the development effort to
be focused on the functionality that lacked or was
inadequate in the source architecture.
In addition, there were several business and political
reasons for management to maintain a freedom of action
regarding a gradual transition into a target architecture.
The company’s aggressive policy of company
acquisitions, mergers and partnerships demanded
flexibility in terms of information systems. Accordingly,
the style provided means for a gradual reduction in the
234

12. number of redundant components, but also for the
incorporation of new components. However, when
assessing the availability of third party products to support
the integration to the base components’ database
management systems, it became evident that these had to
be custom developed to a considerable cost and risk (cf.
the adapter and transformer styles).
An optional design alternative was to consider the
legacy/source components as non, or semi-decomposable,
and to deploy a combined application and screen-scraper
gateway. A distinct advantage with this choice was that it
could provide a uniform GUI for users throughout the
enterprise, thus providing a single-point-of-entry-data, and
(to a limited extent) both reverse and forward translation
of information. This would support data consistency,
atomicity, and isolation. Moreover, new G U S ,
specifically adapted to different user groups could be
developed, improving both usability and security (in terms
of authentication and access control). The style also
permitted a limited addition of new components, such as
contact center functionality. The main drawback with this
style was, however, that in order to provide a uniform
interface to several heterogeneous source/legacy
components, the gateway would only be able to provide
the least common denominator of the functionality and
data of the underlying components. Furthermore, the
gateway had to be fairly complex and hence both hard and
costly to implement and to maintain over time.
The database federation style. To provide a one-way
forward translation of a sub-set of the data from the
source architecture data components, either by providing a
virtual database, or by replicating the selected information
into a separate data store (data warehouse), a design
alternative that employed the database federation style
was considered. The benefits of this approach were mainly
that it provided reading accessibility to the selected data
in the entire organization, e.g. for generating economical
statistics. Because of the limited-service interfaces of the
base components, write access was not provided on the
data level. Moreover, the poor performance of this
alternative ruled it out as a method for real-time access of
enterprise data. Also from a usability and data consistency
perspective, the approach was cumbersome, as changes to
data in the source components had to be done through the
present legacy GUIs, causing a bothersome situation for
the users (cf. the desktop integration style above).
5.3. Results of the style selection process
In the planning process, the architectural styles
discussed in this section served several purposes. Firstly,
styles and patterns are proven solutions to recurring
problems; a main benefit is therefore the reuse of
historically successful designs.
Secondly, they served as a simple intuitive description
of different design alternatives that stakeholder found
comprehensible. Once overcoming this novel way of
describing an enterprise software architecture, the
structure provided by the style description and its
relatively pure coupling between the style problem, its
advantages and disadvantages, together with the style’s
relation to other styles were found helpful as a way to
promote awareness and communication among
stakeholders (e.g. top-management, IT-staff, users, and
vendors).
Thirdly, design alternatives expressed in terms of
architectural styles provided useful input the architectural
design by clarifying feasible design choices, thus
gradually delimiting the design space. It should here be
stressed that initially, the design space seemed rather
endless. But as design alternatives were abandoned, both
due to legacy architecture considerations, availability of
appropriate packaged software, and organizational
matters, only a very limited number of alternatives were
left to choose between.
In the exemplifying case, it was concluded that in the
given context, the point-to-point integration style was
initially ruled out mainly due to its poor scalability.
Despite several attractive properties, the gateway, and the
message router style proved too costly and too risky to
implement in full scale in the short run, and therefore only
constituted feasible solutions in the longer perspective. A
paramount reason for ruling out the general mediator
styles was the poor availability of COTS adapters.
Therefore, since this state of affairs was expected to
change as bigger electricity retail companies in
conjunction with vendors would contribute to the
development of these products, it was concluded that the
desktop integration and the database federation styles
were the only feasible design alternatives during the
foreseeable planning period. Although, tactical rather than
strategic to their nature, and with several major
weaknesses, the relatively low cost and risk involved in
the implementation gave them an decisive advantage over
the other considered styles, even if they arguably
postponed several strategic architectural design choices.
6. Summary
In the article, we propose an approach for selection of
integration solution based on architectural integration
styles for enterprise software systems. The approach is
supported by an adapted structure for integration style
description based on the characteristics of enterprise
software systems, e.g., non-modifiable components,
extensive use of packaged software and legacy
components. Integration styles and the proposed structure
235

13. for integration style description is exemplified by a
presentation of seven styles.
The application of integration styles in the enterprise
context is demonstrated in a case study, briefly outlining
the architectural planning process, describing the source
architecture and presenting a number of design
alternatives in terms of architectural integration styles.
Styles and patterns are proven solutions to recurring
problems; a main benefit is therefore the reuse of
historically successful designs. Moreover and due to the
limited supply of integration product on the market, the
selection of an architectural integration style constitutes a
considerable part of the enterprise software system design.
Architectural integration styles allow this design process
to be conducted on a generalized level, independent of
specificities of individual products. Further benefits are
due to improved communication between stakeholders
and increased awareness of risks, constraints, and
opportunities in enterprise architectures.
7 References
.
Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M.,
Fiksdahl-King,I., Angel, S., A Pattern Language, Oxford
University Press, 1977.
[2] Anderson, J., Cegrell, T., Cheong, K.H., Haglind, M.,
“Strategic Management of Information Technology in Small and
Medium Sized Electric Utilities: Bridging the Gap Between
Theory and Practice,” to appear in proceedings of Portland
International Conference on Management of Engineering and
Technology, 2001.
[3] Anderson, J., Johnson, P., “Extending Attribute-Based
Architectural Analysis to Enterprise Software Systems,
Proceedings of the Third Australasian Workshop on Software
and System Architectures, 2000.
[4] Anderson, J., Johnson, P., “IT Infrastructure Architectures
for Electric Utilities: A Comparative Analysis of Description
Techniques”, Proceedings of the 33“/ Hawaii International
Conference on Systems Sciences, 2000.
[I]
’
[5] Bass, L., Clements, P., Kazman, R., Software Architecture
in Practice. Addison-Wesley, 1998.
[6] Brodie, M. L., Stonebraker, M., Migrating Legacy Systems:
Gateways, Interfaces. and the Incremental Approach, Morgan
Kaufmann Publishers, 1995.
[7] Brown, A., Large-scale, Component-Based Development,
Prentice-Hall, 2000.
[8] Cegrell, T.. et.al., “IT Strategy for Electric Utilities: From a
Paper Tiger to an Effective Management Tool,” Proceedings of
DA/DSM DistribuTech Europe 97, 1998.
[ 9 ] Chappell, D., Understanding ActiveX and OLE: A Guide
for Developers and Managers, Microsoft Press, 1996.
[IO] DeLine, R., Resolving Packaging Mismatch (Ph.D. Thesis),
Camegie Mellon University, 1999.
[ 11 Gacek, C., Detecting Architectural Mismatch During
3
System Composition (Ph.D. The:j.is), University of Southern
California, 1998.
[ 121 Gamma, E., Helm, R., Johnson, R., Vlissides, J., Design
Patterns: Elements o Reusabk Object-Oriented Software,
f
Addison-Wesley, 1998.
[I31 Garlan, D., Allen, R., Ockerbloom, J., “Architectural
Mismatch: Why Reuse is so Hard,” IEEE Software, 1994.
[ 141 Garlan, D., Shaw, M., Software Architecture: Perspectives
on an Emerging Discipline, Prentice Hall, 1996.
[ 151 Kazman, R., Bass, L., Toward Deriving Software
Architectures from Quality Attributes, Technical Report
CMU/SEI-94-TR-IO,SEI, 1994.
[ 161 Linthicum,D.,
Enterprise Application Integration,
Addison-Wesley, 2000.
[ 171 Monson-Haefel, R., Enterprise JavaBeans, 2“d Ed.,
O’Reilly & Associates, 2000.
[ 181 Ockerbloom, J., Mediating Among Diverse Data Formats
(Ph.D. Thesis), Camegie Mellon University, 1998.
[191 Pressman, R., Software Engineering: A Practitioner’s
Approach, 5‘hed., McGraw-Hill, 2000.
[20] Pritchard, J., COM and CORBA Side by Side:
Architectures, Strategies, and Implementations, AddisonWesley, 1999.
[21] Ruh, W., Maginnis, F., Brown, J., Enterprise Application
Integration: A Wiley Tech Brief; John Wiley & Sons, Inc., 2001.
[22] Thomas, A., Selecting Enterprise JavaBeans Technology,
Patricia Seybold Group, 1998.
236