See

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

Software systems integration and architectural

analysis - A case study

Conference Paper · October 2003

DOI: 10.1109/ICSM.2003.1235441 · Source: IEEE Xplore

CITATIONS READS

25 172

2 authors:

Rikard Land Ivica Crnkovic

53 PUBLICATIONS 390 CITATIONS Chalmers University of Technology
236 PUBLICATIONS 3,304 CITATIONS
SEE PROFILE

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

ORION: Decision-Support for Component-Based Software Engineering of Cyber-Physical Systems View

project

PROGRESS View project

All content following this page was uploaded by Ivica Crnkovic on 19 July 2015.

The user has requested enhancement of the downloaded file. All in-text references underlined in blue are added to the original document
and are linked to publications on ResearchGate, letting you access and read them immediately.
 Software Systems Integration and Architectural Analysis – A Case Study

Rikard Land, Ivica Crnkovic

Mälardalen University
Department of Computer Science and Engineering
PO Box 883, SE-721 23 Västerås, Sweden
+46 21 10 70 35, +46 21 10 31 83
{rikard.land, ivica.crnkovic}@mdh.se
http://www.idt.mdh.se/{~rld, ~icc}

Abstract integrated and seamless process. Company mergers

Software systems no longer evolve as separate entities but demand increased interoperability and integration of tools.
are also integrated with each other. The purpose of Such tools can be very diverse with respect to technologies,
integrating software systems can be to increase user-value structures and use and their integration can therefore be
or to decrease maintenance costs. Different approaches, very complex, tedious, and time- and effort-consuming.
one of which is software architectural analysis, can be One important question which arises: Is it feasible to
used in the process of integration planning and design. integrate these tools and which approach is the best to
analyze, design and implement the integration?
This paper presents a case study in which three software
systems were to be integrated. We show how architectural Architecture-centered software development is a well-
reasoning was used to design and compare integration established strategy [2,3,13,21]. We have experienced the
alternatives. In particular, four different levels of the architecture of a system as an appropriate starting point
integration were discussed (interoperation, a so-called around which to concentrate integration activities. One
Enterprise Application Integration, an integration based on common experience is that integration is more complex and
a common data model, and a full integration). We also costly than first expected due to “architectural mismatches”
show how cost, time to delivery and maintainability of the [10,11], and this problem should be addressed at the
integrated solution were estimated. architectural level. It also seems possible that some
architectural analysis techniques used during new
On the basis of the case study, we analyze the advantages
development could also be applicable during system
and limits of the architectural approach as such and
evolution and integration. In this paper we show the extent
conclude by outlining directions for future research: how
to which an architecture-centric approach can be used
to incorporate analysis of cost, time to delivery, and risk in
during system evolution and integration, and how accurate
architectural analysis, and how to make architectural
and relevant the result of such an architecture-based
analysis more suitable for comparing many aspects of
analysis is.
many alternatives during development. Finally we outline
the limitations of architectural analysis. Our aim has been to present our experiences from a
case study in which three software systems were to be
Keywords integrated after a company merger. We have monitored the
Architectural Analysis, Enterprise Application Integration, decision process, and the actual integration has just begun.
Information Systems, Legacy Systems, Software The activities were focused around the systems’
Architecture, Software Integration. architectures. We describe the three integration approaches
that were discerned and discussed, how architectural
1. Introduction descriptions of the two most interesting were developed
The evolution, migration and integration of existing and analyzed and the decisions taken for the development
software (legacy) systems are widespread and a formidable project. Further we analyze the proposed solutions showing
challenge to today's businesses [4,19]. This paper will the strong and weak sides of the architectural strategy as
focus on the integration of software systems. Systems need such.
to be integrated for many reasons. In an organization, The rest of this paper is organized as follows. Section
processes are usually supported by several tools and there 2 provides the background of our case study, section 3
is a need for integration of these tools to achieve an discusses four integration approaches, and section 4 uses
the case study to elaborate on architectural analyses lines of code). One system uses a proprietary object-
possible during system integration. Section 5 describes oriented database, implemented as files accessed through
related work, and section 6 concludes the paper and library functions, while the other two systems, which were
suggests directions for future research. developed at the same site, share data in a common
commercial relational database executing as a database
2. Introducing the Case Study server. The most modern system is built with three-tier
architecture in Java 2 Enterprise Edition (J2EE), while the
The case study concerns a large North American
two older systems are developed to run in a Unix
industrial enterprise with thousands of employees that
environment with only a thin X Windows client displaying
acquired a smaller (approximately 800 employees)
the user interface (the “thin” client is denoted by a
European company operating in the same business area.
rectangle with zero height in the figure). These are written
Software, mainly developed in-house, is used for
mostly in Tcl and C++, and C++ with the use of Motif. The
simulations and management of simulation data, i.e. as
“Tcl/C++ system” contains ~350 KLOC (thousands of
tools for development and production of other products.
lines of code), the “C++/Motif system” 140 KLOC, and the
The functionality of the software developed in the two
“Java system” 90 KLOC.
organizations prior to the merger was found to overlap to
some extent, and three systems suitable for integration
3. Integration Approaches
were identified. A project was launched with the aim of
arriving at a decision on strategic principles for the When developing architectures of new systems, the
integration, based on the proposed architecture for the main goal is to achieve the functionality and quality
integrated system. This was the first major collaboration properties of the system in accordance with the specified
between the two previously separate software departments. requirements and identified constraints. When, however,
existing systems are to be integrated, there may be many
Client Client Client
more constraints to be considered: backward compatibility
requirements, existing procedures in the organization,
Java possible incompatibility between the systems, partial
overlap of functionality, etc. Similarly, the integrated
Unix Unix system is basically required to provide the same
Server Server Server functionality as the separate systems did previously, but
also, for example, to ensure data consistency and enable
Tcl C++ Java automation of certain tasks previously performed manually.
When developing new software, it is possible to design a
C++ system that is conceptually integrated [5] (i.e. conforms to
Server
a coherent set of design ideas), but this is typically not
possible when integrating software since the existing
Data Database
software may have been built with different design
Files Server
concepts [11]. Another problem is how to deal with the
existing systems during the integration phase (and even
long after, if they have been delivered and are subject to
Key long-term commitments). This problem becomes more
Process complex the more calendar-time the integration will take as
there is a pronounced tradeoff between costs in the short
File term and in the long term when different integration
solutions have different maintainability characteristics. For
Bidirected Runtime example, there is an opportunity to replace older with more
Communication recent technologies to secure the system usability for the
File Access future. Scenarios possible if the systems are not integrated
should also be considered.
Figure 1. Today’s three systems. In the analysis and decision process we have discerned
four integration approaches or “levels” with different
Figure 1 describes the existing systems’ architectures characteristics. They are:
in a simplified manner in a high-level diagram combining • Interoperability through import and export
an execution view of the system with the code view facilities. The simplest form of using services between
[2,7,13,16]. The sizes of the rectangles indicate the relative tools is to obtain interoperability by
sizes of the components of the systems (as measured in importing/exporting data and providing services. The
 data could either be transferred manually when data is one database (the commercial database used today by
needed, or automatically. To some extent, this could be the C++/Motif system and the Java system). Future
done without modifying existing systems (e.g. if there maintenance costs can be decreased since it would be
is a known API or it is possible to access data directly conceptually integrated, and presumably the total
from the data sources), and if source code is available number of lines of code, programming languages,
it is possible to add these types of facilities. This third-party software and technologies used will
approach would allow information to flow between the decrease. Most probably the code integration would
systems, which would give users a limited amount of require integration of data.
increased value. It would be difficult to achieve an Interoperability through import and export facilities is
integrated and seamless process, as some data could be the most common way of beginning an integration
generated by a particular tool not necessarily capable initiative [8]. It is the fastest way to achieve (a limited
of automatic execution. Moreover, there would be amount of) increased functionality and it includes the
problems of data inconsistency. lowest risk of all alternatives, which is the reason why
• Enterprise Application Integration (EAI). Many managers usually adopt this approach. In a combination
systems used inside a company are acquired rather with a loose integration (EAI) it can provide a flexible and
than built, and it is not an option to modify them. Such smooth integration process of transition: the import/export
systems are used within a company, as opposed to the facilities can be successively replaced by communicating
software products a company not only uses but also components and more and more integrated repositories. Of
manufactures and installs at customers’ sites. course, this approach has its disadvantages – in total it will
Integrating such enterprise software systems involve arguably require more effort, and the final solution may
using and building wrappers, adapters, or other types technically not be as optimized as the results of the “data
of connectors. In such a resulting “loose” integration level” or “code level” approaches. This of course depends
the system components operate independently of each on the goals of the integration.
other and may store data in their own repository. Which integration approach to use in a particular
Depending on the situation, EAI can be based on context depends not only the objective of the integration,
component technologies such as COM or CORBA, but also e.g. the organizational context and whether source
while in other cases EAI is enabled through import and code is available or not. For example, is the goal to produce
export interfaces (as described in previous bullet). an integrated product for the market, or is the system to be
Well-specified interfaces and intercommunication used only in-house? Is integration of software a result of a
services (middleware) often play a crucial role in this company merger? Is integration expected to decrease
type of integration. maintenance costs or to increase the value for users (or
• Integration on data level. By sharing data e.g. both)? Who owns the source code? Can the systems to be
through the use of a common database, the users will integrated be expected to be released in subsequent
benefit from access to more information. Since the versions by (other) independent vendors? Is modifying
systems store complementary information about the source code an option, considering both its availability and
same data items; the information will be consistent, possible legal restrictions? Business constraints also limit
coherent and correct. However, it would presumably the possibilities – the resources are limited and time to
require more effort to reach there: a common data market an important concern. One must also consider the
model must be defined and implemented and the risks associated with each alternative, meaning the
existing systems must be modified to use this database. probability of overrunning budget and/or schedule or not
If this is done carefully, maintenance costs could be succeed with the integration. The risk parameters include
decreased since there is only one database to be not only those related to technical problems, but also those
maintained and there are opportunities to coordinate associated with the collaboration of two software
certain maintenance tasks. On the other hand, development departments which had previously belonged
maintenance becomes more complex since the to different companies and only recently began
database must be compatible with three systems collaborating.
(which are possibly released in new versions The project team of the case study intuitively felt that
independently). Also data integration may have an the benefits and the cost of implementation, the time to
impact on code change, due to possible data delivery, and the risk of the integration approaches
inconsistencies or duplicated information. described above should be related roughly as shown in
• Integration on source code level. By “merging” Figure 2. The diagram is very simplistic assuming there is
source code, the users would experience one only one “benefit” dimension, but as mentioned earlier
homogeneous system in which similar tasks are there may be different types of goals for integration, such
performed in the same way and there would be only as increased usability or decreased maintenance costs. EAI
was never explicitly considered as a separate approach reflected in the present paper where we only present two
during the case study and is therefore omitted from the remaining alternatives and the analyses of three specific
figure. concerns in more detail (sections 0 through 4.3).
Cost, The two remaining main alternatives conformed well
Risk, to the “data level” and the “code level” integration
Time "Code level" approaches. Both these alternatives would necessarily need
a common data model and shared data storage. From there,
"Data level" the two different levels of integration would require
different types of actions: for “data level” integration, the
existing systems would need to be modified due to changes
"Import/Export Interface"
in the data model, and for “code level” integration, much of
the existing functionality would need to be rewritten in
Benefit Java; see Figure 3. In reality, these descriptions were more
detailed than the figure suggests; About ten components
Figure 2: Expected relations between risk, cost, and were used in each of the same two views for describing the
time to delivery. existing systems, a code view and an execution view.
4. Development of Integration Alternatives a) "Data level" integration, preserves existing
architectures
Developers from the two sites met and analyzed the
existing systems at the architectural level, and then
Client Client Client
developed and analyzed two integration alternatives. The
developers had architected, implemented and/or maintained
Java
the existing systems and were thus very experienced in the
design rationale of the systems and the technologies used Unix Unix
therein. The architectural alternatives were then handed Server Server Server
over to management to decide which alternative should be
used. The integration process was based on IEEE standard Tcl
C++ Java
1471-2000 [14] and is described in more detail in [17,18].
C++
The “import/export level” interoperability was not dis-
cussed in any depth since it was apparent that more benefits
were desired than could be expected with this approach.
Instead, the software developers/architects tried the other Server
approaches to integration, by conceptually combining the Database Server
source code components of the existing system in different
ways. The existing documentation had first to be improved b) "Code level" integration, uses 3-tiered
architecture
by e.g. using the same notation (UML) and the same sets of
architectural views (a code view and an execution view
were considered sufficient) to make them easy to merge Client
[18]. Each diagram contained about ten components, Java or Tcl
sufficient to permit the kind of reasoning that will be
described. By annotating the existing components with
associated effort, number of lines of code, language,
Server
technologies, and third-party software used, the developers
could reason about how well the components would fit
together. During the development of alternatives, Java
statements about the quality properties of the integrated
system such as performance and scalability were based on
the characteristics of the existing systems. Patterns known
to have caused deficiencies and strengths in the existing Server
systems in these respects made it possible to evaluate and
Database
discard working alternatives rapidly. The developers had a
Server
list of such concerns, to ensure that all those of importance
were addressed. The process of developing and refining
alternatives and analyzing them was more iterative than is Figure 3. The two main integration alternatives.
 Architectural descriptions such as these make it totally in Java. Would it not be possible to pursue the EAI
possible to reason about several properties of the resulting approach and produce a loosely integrated solution,
integrated system. involving the reuse of existing parts written e.g. in C++?
With the platform already in use, J2EE, it would be
4.1 Future Maintainability possible to write wrappers that “componentized” different
parts of the legacy code. This was considered, and, by
The following factors were considered in the case
iteration the architectural description of this alternative was
study to be able to compare the future maintenance costs of
modified and analyzed with respect to the cost of
the integration alternatives:
implementation. Based on these estimates, all solutions
• Technologies used. The number of technologies used involving wrappers and componentization were ultimately
in the integrated system arguably tells something about discarded and only the two alternatives already presented
its complexity. By technologies we more specifically remained.
mean the following: programming languages, Whether to use Java or Tcl in the client for the “code
development tools (such as code generators and level” alternative was the subject of discussion. Much more
environments), third-party software packages used in user interface code was available in the Tcl/C++ system
runtime, and interaction protocols. Too many such than in the Java system which was preferable for other
technologies will presumably create maintenance reasons. The pros and cons of each alternative were hard to
difficulties since maintaining staff needs to master a quantify, and eventually this became a question of cost, left
large number of languages and specific products and to the management to decide.
technologies, but at the same time tools and third-party
software should of course be used whenever possible
4.2 Cost Estimation
to increase efficiency. A reasonable number must
therefore be estimated in any specific case. In our case Estimating the cost of implementing an integrated
study, the total number of languages and technologies system based on an architectural description is fairly
used in the “code level” alternative would be reduced straightforward. Based on previous experience, developers
to 6 to 8 languages instead of the 11 found in the could estimate the effort associated with each component,
existing system combined, a number which would be considering whether it will remain unmodified, be
preserved in the “data level” alternative. The number modified, rewritten, or totally new in the integrated system.
of third-party packages providing approximately the Clearly, the outcome of this type of estimation is no better
same functionality could be reduced from 9 to 5, and than the estimations for individual components. The
two other technologies would also become advantage of estimation at the component level is that it is
superfluous. easier to grasp, understand, and (we argue) estimate costs
• LOC. The total number of lines of code (LOC) has for smaller units than for the system as a whole.
been suggested as a measure of maintainability; it is This estimation is fairly informal and mainly based on
e.g. part of the Maintainability Index (MI) [20,23]. In experience, but it can be considered reasonable. First, the
the case study, the total number of lines of code would developers in the case study were very experienced in the
be considerably less with the “code level” alternative. existing systems and software development, second, the
No numbers were estimated, but while the “code level” developers themselves agreed on the numbers, third, these
alternative would mean that code was merged and the numbers were higher than the management had expected
number of lines of code would be less than today, the (implying it not being overly optimistic/unrealistic), fourth,
“data level” alternative would rather raise the need of management explicitly asked the developers during the
duplicating more functionality in the long term. development of the alternatives to find cheaper (and faster)
• Conceptual integrity. Although a system commonly alternatives, something they were unable to do – the only
implements several architectural styles at the same alternative according to them would be the import and
time – “heterogeneous systems” [2] – this should come export facilities (for the interoperability approach). When
as a result of a conscious decision rather than summing the effort associated with all components in each
fortuitously for the architecture to be conceptually alternative the developers found (partly to their surprise)
integrated [5]. In the case study, it was clear, by that the implementation costs would be the same for both
considering the overall architectural styles of the alternatives (the total estimated times differed by only 5%,
systems, that the “data level” alternative involved three which is negligible for such early, relatively rough
styles in parallel while the “code level” would reflect a estimations). This was true for the variant of the “code
single set of design ideas. level” alternative if Tcl was chosen for the client part -
using Java would require more resources. The apparently
It might seem surprising that in the case study, in the high cost of the “data level” alternative was due to the
“code level” integration alternative, the server is written definition of a common data model, and in the case of the
Tcl/C++ system the use of a new database (a commercial a) Project schedule plan for "data level" alternative:
relational database instead of an object-oriented proprietary General C++/Motif Tcl/C++ Java
database). These changes would ripple through the data activities system system system
access layer, the classes modeling the items in the database, Develop
and to a limited extent the user interface. Since the total general
functionality
number of lines of code is much greater than the estimated
number of lines of code in the “code level” integration Define data
model
alternative, the apparently lower cost of modifying code
Replace
instead of rewriting it would be nullified by the larger proprietary
New Modify Modify
number of lines of code. It would also be necessary to write functionality classes/user database classes/user
some new components in two languages. W interface interface
Bridging solutions would be required and functionality
duplicated in both C++ and Java by the existing code (and
Modify Extend with
added to by the development of new functionality and the classes/user functionality
modifications of e.g. data access layers). When the interface X
developers estimated the costs associated with using both
Extend with Extend with
Tcl and Java in the client (since much code could be functionality functionality
reused), and using only one (thus extending the existing Z Y
code in one language with the functionality of the other), it
was concluded that using two different languages in the b) Project schedule plan for "code level" alternative:
client would probably be more costly than using either one, General Transfer
due to the same arguments as above. Some generic Implement new functionality
activities functionality
components, among them non-trivial graphical widgets, Develop
would need to be written in two languages. general
functionality
Building a common data model from existing data
Define data
models is one of the major challenges of software model
engineering [1,10], which was apparent from the cost
estimations. We cannot claim, on the basis of a single case
study, that the “data level” approach will always be as Transfer
expensive as the “code level” approach, but this reasoning New New functionality
functionality functionality A from Tcl/
gives at hand that in general, neither approach is cheap, X Z C++ system
once a minimum of data level integration is decided upon.
For the “data level” alternative this requires changes New New
Transfer
functionality
throughout the existing systems and the “code level” functionality functionality
B from Tcl/
alternative requires changes, to adapt to both the new data Y W
C++ system
model and a single set of technologies, languages, and
Transfer
architectural styles. functionality
C from C++/
4.3 Estimated Time to Delivery Motif system

The resulting project plans developed in the case study Figure 4: The outlined project plans.
are shown in Figure 4. Although the diagrams presented
here are somewhat simplified compared with those • Management is given a certain amount of freedom by
developed in the project, they suffice to illustrate some not assigning strict dates to activities. Activities can be
features of this type of project plan: prioritized and reordered, and deliveries “spawned off”
• The definition of a common data model is crucial in to meet business demands. More staff can be assigned
both integration approaches, since most other activities to certain activities to increase parallelism and
are dependent on it. In the case study, the developers throughput. Based on which components would need
were explicit that this activity should not be rushed, to be included in a delivery, it is possible to define
and should involve the most experienced users as well activities that produce these components; for example,
as developers. if a delivery with functionality “X” is desired, the
activity “Extend with functionality X” or “New
functionality X” (for the two alternatives respectively)
must be performed as well as all activities on which it
 is dependent. One strategy could be to aim at by more tools, easier to use and more attractive to potential
delivering a “vertical slice” of the system, employees. Not least, the resulting product would be
incorporating the functionality that is most used first. conceptually integrated. Regarding the choice between
In this way some users can begin using the new using Java and Tcl in the client, the management accepted
system, thus minimizing the need for maintenance and that if the “code level” was decided upon, Tcl would be
development of the existing systems (which will soon used since using Tcl implied a significantly smaller effort
be retired). (due to a larger code base to reuse).
• In the “code level” alternative, many activities are of When management considered all this information,
the “transfer functionality” type. In this way, users of they judged the integration to be sufficiently beneficial to
the Java system will only see the functionality grow motivate the high cost. The benefits included, as we have
rapidly, but the users of the other systems will indicated earlier, increased user efficiency, decreased
experience a period when most of the functionality maintenance costs (in the case of the “code level”
exists in both the system with which they are familiar alternative), as well as less tangible business advantages
and the new system. For the “data level” alternative, such as having an integrated system to offer customers.
the activities are more of the kind “modify the existing Also, the evolution scenarios for the existing systems if no
systems”. The users would then continue using their integration was performed would be costly; for example,
familiar system but, when beginning to use the other the European organization would probably replace in the
systems, would have access to more functionality near future, the proprietary object-oriented database with a
working on the same data. This type of reasoning commercial relational database for maintenance and
impacts on long-term planning aspects such as the time performance reasons. The cost of implementing the “data
at which existing systems can be phased out and level” and “code level” alternatives (when using Tcl in the
retired. client) had been estimated to differ insignificantly, and as
• In the “code level” alternative, it was possible to the organization had to develop it with a limited number of
identify more general components that would require staff, the estimated time to delivery would also be very
an initial extra amount of effort and calendar-time but similar, although the deliveries would be of different kinds
would eventually make the project cheaper and faster. due to the different natures of the activities needed for the
In the “data level” alternative, only few such two alternatives. The relation benefit vs. cost and time to
components were identified. delivery can therefore be visualized as Figure 5 illustrates
(the “import/export interface” level was not analyzed,
• Some development of totally new functionality hence the parentheses).
demanded by users was already planned and could not
be delayed until the systems integration efforts were Cost,
completed. However, it was agreed that these activities Time
should be delayed as long as possible – at least until el" el"
lev lev
one of the integration alternatives was chosen, and if a e
at od
possible, until the new data model had been defined, "D "C
and even general components implemented in the case
of the “code level” alternative. This was to avoid ("Import/Export Interface")
producing even more source code that would need to
be modified during the integration.
Benefit
4.4 The Decision Figure 5: The estimated cost and time to delivery.
When the developers from the two sites had jointly As became clear by now, it was less important to get as
produced these two alternatives and analyzed them, the much benefit as possible for the cost than to decrease the
management was to decide which alternative to choose. It risk as much as possible. No formal risk analysis was
was agreed that the “code level” alternative was considered performed at this point, but the risk was judged to be
to be superior to the “data level” alternative from virtually higher for the “code level” alternative, since it involves
all points of view. The users would experience a more rewriting code that already exists and works, i.e. risking
powerful, uniform and homogeneous system. It would also overrunning schedule and budget and/or decreasing the
be easier (meaning less costly) to maintain. The analysis quality of the product, but also a risk in terms of
had shown that it would include a smaller code base as well “commitment required” from the departments of two
as a smaller number of languages, third-party software, and previously separate organizations, not yet close
other technologies. The languages and technologies used collaborators. By choosing the “data level” alternative,
were more modern, implying that they would be supported each system would still be functioning and include more
functionality than before, should the integration be during the project work. However, it is intended as a type
discontinued due to e.g. an unacceptable schedule and/or of formal review involving more stakeholders and this was
budget situation. This is discernible in the project plans of not possible because the project schedule was already
Figure 4. Management doubted that the cost of the two fixed, and too tight for an ARID exercise. All of these
alternatives would really be similar; they intuitively methodologies analyze functionality (which was relatively
assumed that the higher benefit, the more effort was trivial in the case study as the integrated system would
required (cost and time), as was sketched in Figure 2. Still, have the functionality of the three systems combined) and
they were explicit in that the risk was the decisive factor quality attributes such as performance and security (which
and not cost, when choosing the “data level” alternative. are of course important for the product of the case study,
but considered to be similar to the existing systems) – but
5. Related Work none addresses cost, time to delivery, or risk, which were
considered more important. The project therefore relied
There are suggestions that project management during
more on the analysts’ experience and intuition in analyzing
ordinary software development has much to gain from
functionality and quality attributes (because of the project’s
being “architecture-centric” [21]. We have shown some
limited resources), and cost, time to delivery, and risk
ways of pursuing the architecture-centric approach during
(because there are no available lightweight methodologies
integration also. The rest of this section will focus on two
for analyzing these properties from architecture sketches).
related aspects of this, the literature relating to integration
approaches, and methods and analysis techniques based on
6. Conclusions
architectural descriptions.
Of the four integration approaches we have discussed, We have shown the central role of software
Enterprise Application Integration (EAI) seems to be the architecture in a case study concerning the integration of
most documented [9,12,15,19,22]. This approach concerns three software systems after a company merger. Some
in-house integration of the systems an enterprise uses rather important lessons we learned from this case study can be
than produces. Johnson [15] uses an architectural approach formulated as follows:
to analyze the integration of enterprise software systems. In • There are at least four approaches available to a
spite of the difficulty of accurately describing the software integrator: Enterprise Application Integration
architecture of this type of system because the available (EAI), interoperability, data level integration, and
documentation is inadequate, architectural analysis can be source code integration. The choice between these is
successfully applied to the design of enterprise systems typically based on business or organizational
integration. Johnson has also examined the limitations of considerations rather than technical.
architectural descriptions which one must be aware of, • When the architectural descriptions of existing systems
limitations that were also experienced in the case study. are not easily comparable, the first task is to construct
None of the architectural methodologies available similar architectural descriptions of these. The
were completely feasible for the task. The Architecture components of the existing systems can then be
Trade-off Analysis Method (ATAM) [6] and the Software rearranged in different ways to form different
Architecture Analysis Method (SAAM) [2,6] are based on alternatives. The working alternatives can be briefly
stakeholder-generated scenarios. The ATAM requires analyzed, largely on the basis of known properties of
business drivers and quality attributes to be specified in architectural patterns of the existing systems.
advance and more detailed architectural descriptions to be • The functional requirements of an integrated system
available. In the case study, all of this was done in a more are typically a combination of the functionality of the
iterative manner. Also, with limited resources, it would be existing systems, and are relatively easy to assess as
impossible to evaluate and compare several alternatives, it compared with other quality attributes.
being too time-consuming to investigate all combinations
of quality attributes for all working alternatives. While both • The effort required to implement each component of
SAAM and ATAM use scenarios to evaluate the new system can be estimated in terms of how much
maintainability, we used another, if less accurate can be reused from the existing systems and how much
measurement method, comparing the number of lines of must be rewritten. The total cost of the system is easily
code, third-party software, languages, and technologies calculated from these figures.
used, assuming that the lower the number, the easier the • According to the estimations performed in the case
maintenance . The Active Reviews for Intermediate Designs study, source code level integration is not necessarily
method (ARID) [6] builds on Active Design Reviews more expensive than data level integration.
(ADR) and incorporates the idea of scenarios from SAAM • Architectural analysis, as it was carried out in the
and ATAM. It is intended for evaluating partial project, fails to capture all business aspects important
architectural descriptions, exactly that which was available
 for decisions. All the information needed to produce a [5] Brooks F. P., The Mythical Man-Month - Essays On
project schedule is not present in an architectural Software Engineering, 20th Anniversary Edition,
description. The risk associated with the alternatives ISBN 0201835959, Addison-Wesley Longman,
was identified as the most important and least analyzed 1995.
decision criteria.
There are a number of concerns that must be addressed [6] Clements P., Bachmann F., Bass L., Garlan D., Ivers
during integration planning as well as during software J., Little R., Nord R., and Stafford J., Evaluating
activities in general. These include the process and time Software Architectures, SEI Series in Software
perspective (e.g. will the integration be carried out Engineering, ISBN 0-201-70482-X, Addison-
incrementally, enabling stepwise delivery and retirement of Wesley, 2001.
the existing systems?), the organizational issues (e.g. who
are the stakeholders?), the cost and effort requirements [7] Clements P., Bachmann F., Bass L., Garlan D., Ivers
(e.g. are only minimal additional efforts allowed?), etc. We J., Little R., Nord R., and Stafford J., Documenting
have shown how a system’s architecture can be used as a Software Architectures: Views and Beyond, SEI
starting and central point for a systematic analysis of Series in Software Engineering, ISBN 0201703726,
several features. To what extent can such concerns be Addison-Wesley, 2002.
addressed by architectural analysis? Perhaps the focus on
the architecture, basically a technical artifact poses a risk to [8] Crnkovic Ivica and Larsson M., “Challenges of
these other concerns? We have presented means of Component-based Development”, In Journal of
estimating cost and time of implementation based on Systems & Software, volume 61, issue 3, 2002.
architectural descriptions, including outlining project
schedules. We have also shown that only the parts of such [9] Cummins F. A., Enterprise Integration: An
project schedules involving implementation of source code Architecture for Enterprise Application and Systems
can be produced from the architectural descriptions, Integration, ISBN 0471400106, John Wiley & Sons,
activities such as design or analysis must be added from 2002.
other sources. We also showed that the risk of choosing
one alternative or the other was not considered. We [10] Estublier J., “Software Configuration Management:
therefore propose that risk analysis be included in A Roadmap”, In Proceedings of 22nd International
architectural analysis to make it more explicit (or the Conference on Software Engineering, The Future of
opposite, that architectural analysis be used in project risk Software Engineering, ACM Press, 2000.
analysis). This would make it possible to treat risk together
with other quality properties and make a conscious trade- [11] Garlan D., Allen R., and Ockerbloom J.,
off between them. Research in this area will presumably “Architectural Mismatch: Why Reuse is so Hard”, In
need to incorporate an organizational development and IEEE Software, volume 12, issue 6, 1995.
production process model – which would also provide a
better basis for time and cost estimation. [12] Gyllenswärd E., Kap M., and Land R., “Information
Organizer - A Comprehensive View on Reuse”, In
7. References Proceedings of 4th International Conference on
Enterprise Information Systems (ICEIS), 2002.
[1] Aiken P. H., Data Reverse Engineering : Slaying the
Legacy Dragon, ISBN 0-07-000748-9, McGraw [13] Hofmeister C., Nord R., and Soni D., Applied
Hill, 1996. Software Architecture, ISBN 0-201-32571-3,
Addison-Wesley, 2000.
[2] Bass L., Clements P., and Kazman R., Software
Architecture in Practice (2nd edition), ISBN 0-321- [14] IEEE Architecture Working Group, IEEE
15495-9, Addison-Wesley, 2003. Recommended Practice for Architectural
Description of Software-Intensive Systems, report
[3] Bosch J., Design & Use of Software Architectures, IEEE Std 1471-2000, IEEE, 2000.
ISBN 0-201-67494-7, Addison-Wesley, 2000.
[15] Johnson P., Enterprise Software System Integration
[4] Brodie M. L. and Stonebraker M., Migrating Legacy – An Architectural Perspective, Ph.D. Thesis,
Systems: Gateways, Interfaces & the Incremental Industrial Information and Control Systems, Royal
Approach, Morgan Kaufmann Series in Data Institute of Technology, 2002.
Management Systems, ISBN 1558603301, Morgan
Kaufmann, 1995.
 [16] Kruchten P., “The 4+1 View Model of [20] Oman P., Hagemeister J., and Ash D., A Definition
Architecture”, In IEEE Software, volume 12, issue and Taxonomy for Software Maintainability, report
6, 1995. SETL Report 91-08-TR, University of Idaho, 1991.

[17] Land R., “Applying the IEEE 1471-2000 [21] Paulish D., Architecture-Centric Software Project
Recommended Practice to a Software Integration Management: A Practical Guide, SEI Series in
Project”, In Proceedings of International Software Engineering, ISBN 0-201-73409-5,
Conference on Software Engineering Research and Addison-Wesley, 2002.
Practice (SERP'03), CSREA Press, 2003.
[22] Ruh W. A., Maginnis F. X., and Brown W. J.,
[18] Land R., Crnkovic I., and Wallin C., “Integration of Enterprise Application Integration, A Wiley Tech
Software Systems – Process Challenges”, In Brief, ISBN 0471376418, John Wiley & Sons, 2000.
Proceedings of Euromicro Conference, 2003.
[23] SEI Software Technology Review, Maintainability
[19] Linthicum D. S., Enterprise Application Integration, Index Technique for Measuring Program
Addison-Wesley Information Technology Series, Maintainability, URL:
ISBN 0201615835, Addison-Wesley, 1999. http://www.sei.cmu.edu/str/descriptions/mitmpm.html,
2003.

View publication stats