TOWARDS A METHOD FOR ENTERPRISE INFORMATION

SYSTEMS INTEGRATION

Rafael Silveira

, Joan Pastor

and Enric Mayol

Facultat d’Informàtica de Barcelona, Universitat Politècnica de Catalunya, Spain

Estudis d’Informàtica, Multimèdia i Telecomunicacions, Universitat Oberta de Catalunya, Spain

Keywords: Enterprise Integration, Enterprise Information Systems Integration, Enterprise Application Integration

(EAI), Business Process Management (BPM), Information Systems (IS), IC-BPM suites.

Abstract: Enterprise information systems integration is essential for organizations to fulfil interoperability

requirements between applications and business processes. To carry out most typical integration

requirements, traditional software development methodologies are not suitable. Neither are enterprise

package implementation methodologies. Thus, specific ad-hoc methodologies are needed for information

systems integration. This paper proposes the basis for a new method for enterprise information systems

integration in order to facilitate continuous learning and centralized management during all the integration

process. This method has been developed based on the ontology defined in ISO/IEC 24744.

1 INTRODUCTION

Nowadays, it is common that enterprises develop

specific projects for the integration of both disparate

information systems (IS) within one enterprise and

between IS from several enterprises. For such a task,

it is a good practice that facilitates project success to

apply an adequate method. Despite the fact that

traditional software engineering methods alone are

not adequate for enterprise information system

integration (Themistocleous & Irani, 2006),

previously published methods, specific for

enterprise IS integration, have not yet had a great

level of popularity. Therefore, two research lines

could be proposed: first, to analyse why these

methods are not so popular and second, to define

new enterprise IS integration methods more focused

on usefulness.

In this paper we propose the bases for a new

method for enterprise IS integration, which we are

designing with an aim towards continuous learning

and with a centralized management as a differential

feature. Moreover, we propose explicit evaluation

phases to improve the quality of the integration task

to be undertaken.

The paper is structured as follows. We begin

with an introduction to enterprise IS integration

projects. Then, section 3 describes the bases of the

proposed method. In section 4 we establish

relationships with previous research on integration

methods, and in section 5 we present our

conclusions and ideas for further work.

2 ENTERPRISE INFORMATION

SYSTEMS INTEGRATION

Enterprise IS integration refers, depending on the

context, to different concepts as Information

Technology Integration, Information System

Integration, Application Integration, Business

Integration or Data Integration, among others.

However, the main task of all of them implies to

integrate some element of enterprise. Currently,

enterprises have the need to integrate their data,

processes, applications or systems. At the end of the

90s, the high development costs, the trust in the

reliable operation of robust legacy systems, and the

need for the quick integration of new kinds of IS

such as eBusiness applications, motivated the rise of

Enterprise Application Integration (EAI). In fact

EAI was originally defined (Linthicum, 1999) as the

unrestricted sharing of data between two or more

organization applications, where a group of

technologies allow information flow and exchange

among different applications and business processes,

349

Silveira R., Pastor J. and Mayol E. (2008).

TOWARDS A METHOD FOR ENTERPRISE INFORMATION SYSTEMS INTEGRATION.

In Proceedings of the Tenth International Conference on Enterprise Information Systems - DISI, pages 349-354

DOI: 10.5220/0001715603490354

 SciTePress

of the same enterprise or between different

enterprises. Much more recently, the adoption of

web-services technology and Service-Oriented

Architectures (SOA), have changed the nature of the

IS development and integration paradigm. This new

approach supports high levels of system artefact

reuse and can frequently result in dramatically

reduced coding for new application functionality.

This new approach has promoted a new service

market, as the convergence of the previously

independent tool markets for EAI, Workflows and

Document Management, and Business Process

Management tools (Meta Group, 2003). By the end

of 2006, Forrester defined this new service market

as that one of the Integration Centric Business

Process Management (IC-BPM) suites (Vollmer &

Peyret, 2006).

To carry out an enterprise IS integration project,

we could try to adapt and use some prior

development approach, such as a more conventional

software development methodology or some

proprietary enterprise package implantation

methodology. However, none of these alternatives

fits in a natural and easy way with the situations

arising in enterprise IS integration projects. Typical

software development methodologies are designed

for the bespoke construction of software solutions

from anew, while in enterprise IS integration

projects we find a varied set of legacy applications

that are to be integrated along some pre-existing or

newly designed business process. Enterprise IS

integration is far different from implementing an

enterprise package. Legacy applications are

heterogeneous in several ways, while enterprise

packages are much more homogenous and their

implementation methodologies and tools are adapted

to such a state.

3 OUR ENTERPRISE IS

INTEGRATION PROPOSAL

To define a new method it is convenient to refer to

previous method engineering results. Fortunately,

Method Engineering is not a new research area and

since the 90s many articles and proposals have been

published (Brinkkemper et al., 1999) (Weerd et al.,

2007). Our goal is to organize artefacts and

activities that can be found in a typical integration

project by using an ontology that will allow us to

formalize our method in a more straightforward

way. To accomplish this goal, we have based our

initial proposal on the ontology defined by the

ISO/IEC 24744 (González et al., 2007).

The ISO/IEC 24744 standard introduces the

Software Engineering Metamodel for Development

Methodologies, the aim of which is to define

methodologies in information-based domains (ie.

areas characterized by their intensive reliance on

information management and processing), such as

software, business or systems engineering. ISO/IEC

24744 is an instrument that is suited to our needs

and that also provides a quality and diffusion

framework.

Figure 1: Class diagrams of methodological elements.

ICEIS 2008 - International Conference on Enterprise Information Systems

350

Additionally, our method is based on an iterative

approach and bears continuous evaluation tasks in

the end of each integration stage. It promotes the

acquisition of integration knowledge through several

evaluation stages. These stages allow us to learn

from past successful actions as well as mistakes, and

to identify causes of deviations with respect to

initially-planned duration, budget or integrated

functionality. At the beginning of each new cycle, if

necessary, objectives may be adjusted based on

results on previous cycles. Moreover, we take also

into account several lessons learned from our

participation in a real enterprise IS integration

project within a big Spanish insurance enterprise.

Figure 1 shows the domain of usual method

elements of enterprise IS integration and their

relationship. We consider the following four main

elements:

 Stages. Different development activities are

scheduled in a generic level, through an

integration life cycle, where we distinguish

its stages and internal phases.

 Work units. Activities which should be

done during the integration project.

 Producers. Enterprise roles with the

responsibility to do those work units.

 Work Products. Set of artefacts considered

during the execution of work units.

Given the ontology described above, we define a life

cycle for enterprise IS integration with three basic

stages: Procurement, Implementation and Use. For

each stage we define four phases (see Figure 2). As

central elements in this cycle there are two kinds of

artefacts, those that make up the integration

(applications, processes, systems, tools) and those

that support project management (management tools

such as balanced scorecard). In each stage, we

distinguish two specific phases that interact with the

management artefacts: a first phase that includes

planning tasks, and a second one that includes

evaluation tasks. Management tools propose

initiatives to be considered during planning phases,

while evaluation phases generate feedback that is

used as data input for these management tools. In

this way, our proposal pretends to promote

continuous learning.

Next, we describe the main elements of our

method: life cycle, integration artefacts, and

management artefacts, among other important

elements.

Figure 2: Our Enterprise IS integration life cycle.

3.1 Life Cycle

We propose a life cycle for an enterprise IS

integration project defined in terms of three main

stages, each one decomposed in four phases (Figure

2). Our life cycle stages are:

 Procurement: Composed by the phases

named Planning, Scenarios building,

Contract and Evaluation.

 Implementation: Composed by the phases

named Planning, Alignment and

Development, Deployment and Evaluation.

 Use: Composed by the phases named

Planning, Usage and Evolution,

Deployment and Evaluation.

3.1.1 Procurement

In this stage, enterprise needs for the development

of the future integrated IS are studied and a

conceptual integration solution is designed. This

solution involves the conceptual description of

applications to be integrated and the interfaces

between them. Phases of this stage are the

following:

Procurement Planning: At this phase, business

processes and requirements are analyzed; integration

requirements are compiled; risks, benefits and

organizational impacts are evaluated; integration

strategies are established; available tools and

technological alternatives are analyzed; and possible

integration developments are identified. Moreover,

TOWARDS A METHOD FOR ENTERPRISE INFORMATION SYSTEMS INTEGRATION

351

perspective and business initiatives are considered;

knowledge from integration experience is used.

Scenarios Building and Business Process

Reengineering: Possible scenarios are built by

considering tools, technologies and architectures.

Design and development efforts are forecasted for

each scenario. Besides, it is an opportunity to do

appropriate business process reengineering. The

scenario most convenient is selected. The evaluation

of different IC-BPM suites may be done, fir example

through a quality model for EAI tools (Silveira &

Pastor, 2006). Plus, other non-technical system

factors, such as organizational issues (barriers,

benefits, costs, etc.), should be considered

(Themistocleous & Irani, 2001).

Contracting: Finally, the chosen IC-BPM suite

is acquired, the implementation and maintenance

team is contracted, and the organizational benefits

and impacts are estimated.

Procurement Evaluation: The quality of the

procurement process is evaluated. The results are

analyzed and stored in a base knowledge.

3.1.2 Implementation

After designing a conceptual solution and having the

tools and the technical team to carry on with it, the

implementation stage may start with the following

phases:

Implementation Planning: According to the

business initiatives and strategy of the hosting

enterprise or enterprises, the implementation of the

solution is planned, the implementation teams are

coordinated and the deployment strategy is defined.

Moreover, knowledge from integration experience is

used.

Alignment and Development: In this phase, the

architecture is deployed, the integration tools are

customized and the interconnecting code is designed

and developed. Unitary and integrated tests are

designed, populated and applied.

Deployment: Finally, data migrations are

executed, the new applications and interfaces are

distributed, the business processes are deployed, and

the system operators are trained.

Implementation Evaluation: The quality of the

integration process is evaluated. The results are

analyzed and stored in a knowledge base.

3.1.3 Use

After the resulting integrated information system is

deployed, it begins to be used and eventually will

need to be maintained.

Usage Planning: System usage and its evolution

(maintenance) are planned taking into account

enterprise strategy. Moreover, perspective and

business initiatives are considered; knowledge from

integration experience is used

Use and Evolution: The system is used and its

evolution maintenance strategy is followed.

Deploy Patches and New Versions: New

patches and versions are proposed to redress system

behaviour when appropriate.

Usage Evaluation: At this phase, the alignment

between the system integration and the enterprise

strategy is evaluated. The results are analyzed and

stored in a knowledge base. Moreover, it is also

considered how the system use fulfils the enterprise

goals.

3.2 Integration Artefacts

According to our ontology, we can say that

integration artefacts are Work Products. A work

product is an artefact of interest to the integration

effort. Many work products are created during the

development effort, but many others are procured

outside and are modified during the development.

Clearly, the IC-BPM suites are examples of artefacts

that are modified or customized during the

development while “glue code” is an example of a

product that is created during the development. All

of these are artefacts that compose the centre of

integration and we call them Integration artefacts.

Our method revolves around a group of

integration artefacts that compose the integrated IS.

These artefacts are the business processes,

applications and enterprise systems to be integrated,

the tools that simplify integration tasks and the

overall architecture where integration is going to be

founded.

3.3 Management Artefacts

Apart from integration artefacts, we distinguish

another type of work product, which are generated

in the development of the project in order to be used

as tools in the integration project management. We

call them Management artefacts. Over the work

products, events are executed through the concrete

action of specifics tasks.

ICEIS 2008 - International Conference on Enterprise Information Systems

352

In our method, we include the development of a

model for the management of the project. For

example, management tools as balanced scorecard

may be essential to align business strategies with

information integration strategies. Moreover, these

may be the key in continuous learning through

cycles of evaluation and analysis of the results that

are used as input for future iterations.

3.4 Others Key Elements

To provide a complete method it is necessary to

describe some additional methodological elements

that so far we have not described in our domain such

as: Work Units and Roles. In this paper, we have not

deepened in their description, but we present a brief

overview.

Work units describe the main activities that must

be done in each phase; these activities can be

processes or specific tasks. Typically, a process is

described associating it to a set of tasks.

We use "roles" to describe agent responsibilities;

in our case, stakeholders are agents, and three

groups of responsibilities are identified:

 Responsible people for Business Activities

performed by CTO, CEO, among others.

 Responsible people for Technical Activities

performed by project managers, end-users, etc.

 Responsible people for Organizational

Activities performed by operations staff,

maintenance staff, etc.

We call work performance to the assignment of a

stakeholder to a work unit, and the type of

assignment that is specified there (Mandatory,

Recommended, Optional, Discouraged, Forbidden).

4 RELATIONSHIPS WITH PRIOR

IS INTEGRATION RESEARCH

In contrast with the relevance of the topic in

industry, so far there is not much research on IS

integration project management or in IS integration

methods. As far as we know, only two contributions

have appeared out of academic research: Lam and

Shankararaman (2004) and Themistocleous and

Irani (2006). Next we present them and compare our

proposal with them.

Lam and Shankararaman (2004) were the first

who proposed a methodology for enterprise IS

integration. Their proposal, called Enterprise

Integration Methodology (EIM), consists on five

stages (Lam & Shankararaman, 2004). The steps

defined in these five stages are also considered in

our proposal: To understand the end-to-end business

process is the first step of the analysis, which we

considered in our procurement planning phase.

Their tasks named Map the process onto

components and derive the requirements stages, are

considered in our Scenarios Building phase, because

of each scenario building we must map the process

onto components and we deal with the integration

requirements analyzed in previous phases. Their task

Produce the architecture is one of the steps that we

include in our Alignment and Development phase.

Finally, their stage named Plan the integration

corresponds to our beginning phase of the

Implementation stage.

The methodology proposed by Lam et al. defines

general lines but does not detail or describe specific

points in integration projects. They do not deal in

their procurement stage with issues such as scenario

building and evaluation. Regarding implementation

stage, unless they do not identify in early instances

the needs of new developments, they do not

consider their implementation either. Finally, no

usage stage is considered at all, thus leaving out any

integration evolution evaluation phases, nor the

evaluation of the usage of integrated IS.

The methodology of Lam et al. has some

limitations, such as the lack of consideration of

systems restructuring or the necessity to develop

new software. Trying to cover these limitations,

Themistocleous et al. (2006) propose another

methodology of eight stages.

The sequence of steps defined by

Themeistocleous et al. is distributed over our

structure of stages and phases. Their Planning stage

covers activities that aim towards the study of the

factors that affect the process of adopting an IS

Integration approach, such as barriers, costs or

benefits. We make these studies when evaluating the

different scenarios, because costs, barriers, benefits

or organizational issues in general affect in different

ways each scenario. Their Scenarios building and

evaluation stage, Business Process reengineering

stage and Systems restructuring stage corresponds

with our Scenarios building and business process

reengineering phase. While we build our scenarios,

we are taking advantage of the opportunity to

propose initiatives in business process reengineering

and Systems restructuring. We locate their

Requirements analysis stage in a different position,

because we believe that integration requirements

must be clear before the building of scenarios. Their

Filling the gap and New systems development stages

TOWARDS A METHOD FOR ENTERPRISE INFORMATION SYSTEMS INTEGRATION

353

are included in our Align and development phase

within the Implementation stage. Their steps of

Integration and testing are distributed in our Align

and development and Testing and evaluation stages.

Finally, their Operation and maintenance stage

corresponds with our Use and evolution phase.

On the other hand, Themeistocleous et al. do not

consider hiring subjects, which we inserted in a

phase between the selection of the suitable scenario

and the beginning of the planning implementation

phase. The results obtained in the Hiring stage often

affect technically the development of a project, so

we considered them sufficiently important to

dedicate a phase where we can align the

technological strategy with the business strategy.

They do not propose any management tool to help

manage business initiatives or technical adjustments

derived from the continuous evaluation.

5 CONCLUSIONS AND

FURTHER WORK

It is not yet usual that important failures in IS

integration projects are published, but through

interviews with experts in integration, we know

several fiasco cases in Spain and other countries. In

these cases, often after great investments in

integration platforms, at the end they have ended up

in great overruns and low satisfaction, with

interconnections have ended up being implemented

point to point to hide the project failure.

From these observations, we assume that it is not

enough to have implemented an integration platform

to take advantage of the benefits promoted from IS

integration, or from EAI projects.

In this paper we have presented our bases for a

new method for enterprise IS integration,

constructed on prior research on EAI topics, and

from the analysis of mistakes and successes in a real

rich experience study (Silveira et al., 2008), from

interviews with experts in integration projects, other

case studies published, and the analysis of the

methodologies previously proposed.

The ideas and artefacts incorporated in our

proposal must be formalized within the tenets of

prior research from other related areas, such as

Method Engineering from software and IS

engineering. Similarly, prior results on best practices

recognized in the management of other similar

projects within information systems, such as ERP,

CRM or SCM implementation projects, should be

taken into account in the refinement of our method

for IS integration projects.

REFERENCES

Brinkkemper, S., Saeki, M., Harmsen, F., 1999. Meta-

Modelling based assembly techniques for situational

method engineering. Information Systems, Vol. 24,

No. 3, p. 209-228.

González, C., Larrucea, X., Bediaga, A., Gortazar, A.,

2007. Metamodelo para Metodologías de Desarrollo.

Retrieved September, 2007, from

http://meta.dsic.upv.es

Lam, W. & Shankararaman, V., 2004. An Enterprise

Application Methodology, IT Profesionals, 6(1): pp.

40-48.

Linthicum, D., 1999. Enterprise Application Integration,

Addison-Wesley, Massachusetts, USA.

Meta Group, 2003. Enterprise Application Integration

METAspectrumSM Evaluation.

Silveira, R. & Pastor, J., 2006. A model for enterprise

application integration tools evaluation. Proceedings

of the European and Mediterranean Conference on

Information Systems (EMCIS).

Silveira, R., Pastor, J., Mayol, E., 2008. Towards a

method for enterprise information systems integration

(Extended version). Universitat Politècnica de

Catalunya , Report LSI-08-11-R

(http://www.lsi.upc.edu/dept/techreps/buscar.php)

Themistocleous, M. & Irani, Z., 2001. Benchmarking the

Benefits and Barriers of Application Integration,

Benchmarking: An International Journal. Vol. 8. No.

4, 317-331.

Themistocleous, M. & Irani, Z., 2006. Towards a

Methodology for the Development of Integrated IT

Infrastructures. Proceedings of the 39th Hawaii

International Conference on System Sciences.

Vollmer, K. & Peyret, H., 2006. The Forrester Wave:

Integration-Centric Business Process Management

Suites, Q4 2006”.

Weerd, I., Brinkkemper, S., Versendaal, J., 2007.

Concepts for incremental method evolution: Empirical

exploration and validation in requirements

management. Proceedings of CAiSE, pp. 469-484.

ICEIS 2008 - International Conference on Enterprise Information Systems

354