Lectura 2.1 architectural integrationstylesfor largescale-editable_pdf

Architectural Integration Styles for Large-scale Enterprise Software Systems

Jonas Anderson, Pontus Johnson Dept. of 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 large- scale 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 a major undertaking, requiring in-depth knowledge of 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 fo 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 of the style selection process applied to a mid-sized 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

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 single- vendor 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

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

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.

components

accessibility I User I How much of the functionality that is accessible to the functionality end-users. accessibility

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.

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, limited- service, 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.

Adapter

Point-to-Point

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

L L ------ ------

I Target I I Application r-----

Source I Amiication I I I

i - L-J I %,'-

The Screen-Scraping, Application, and Database Gateway Style

L-----

+I Component

The Desktop Integration Style 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

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 self- parameterization 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

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-to- point, 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

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.

2

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

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 inter- component 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-to- point 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-of- entry. 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

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 sub- style 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

components, such as customer information systems, billing systems, energy settlement systems, and sales support systems. Furthermore, the system revealed non- modifiable, 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 client- server 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 screen- scraping. 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 well- established 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

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 sub- styles 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 sub- style 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 general- purpose 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

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 GUS, 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

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

[ I ] 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.

[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. [ 1 13 Gacek, C., Detecting Architectural Mismatch During System Composition (Ph.D. The:j.is), University of Southern California, 1998. [ 121 Gamma, E., Helm, R., Johnson, R., Vlissides, J., Design Patterns: Elements of Reusabk Object-Oriented Software, 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

[ 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‘h ed., McGraw-Hill, 2000. [20] Pritchard, J., COM and CORBA Side by Side: Architectures, Strategies, and Implementations, Addison- Wesley, 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.

CMU/SEI-94-TR-IO, SEI, 1994.

236