0% found this document useful (0 votes)

507 views

Enterprise Architecture

Uploaded by

Amon Simelane

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

507 views

Enterprise Architecture

Uploaded by

Amon Simelane

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 365

Enterprise Architecture

and Integration:
Methods, Implementation, and
Technologies

Wing Lam
U21 Global, Singapore

Venky Shankararaman
Singapore Management University, Singapore

InformatIon scIence reference

Hershey • New York
Acquisitions Editor: Kristin Klinger
Development Editor: Kristin Roth
Senior Managing Editor: Jennifer Neidig
Managing Editor: Sara Reed
Assistant Managing Editor: Sharon Berger
Copy Editor: Shanelle Ramelb
Typesetter: Jennifer Neidig
Cover Design: Lisa Tosheff
Printed at: Yurchak Printing Inc.

Published in the United States of America by

Information Science Reference (an imprint of IGI Global)
701 E. Chocolate Avenue, Suite 200
Hershey PA 17033
Tel: 717-533-8845
Fax: 717-533-8661
E-mail: [email protected]
Web site: http://www.info-sci-ref.com

and in the United Kingdom by

Information Science Reference (an imprint of IGI Global)
3 Henrietta Street
Covent Garden
London WC2E 8LU
Tel: 44 20 7240 0856
Fax: 44 20 7379 0609
Web site: http://www.eurospanonline.com

Copyright © 2007 by IGI Global. All rights reserved. No part of this publication may be reproduced, stored or distributed in any form or by
any means, electronic or mechanical, including photocopying, without written permission from the publisher.
Product or company names used in this set are for identification purposes only. Inclusion of the names of the products or companies does
not indicate a claim of ownership by IGI Global of the trademark or registered trademark.

Library of Congress Cataloging-in-Publication Data

Enterprise architecture and integration : methods, implementation, and technologies / Wing Lam and Venky Shankararaman, editors.

p. cm.

Summary: "This book provides a detailed analysis of the important strategies for integrating IT systems into fields such as e-business
and customer-relationship management. It supplies readers with a comprehensive survey of existing enterprise architecture and integration
approaches, and presents case studies that illustrate best practices, describing innovative methods, tools, and architectures with which
organizations can systematically achieve enterprise integration"--Provided by publisher.

Includes bibliographical references and index.

ISBN 978-1-59140-887-1 (hardcover) -- ISBN 978-1-59140-889-5 (ebook)

1. Management information systems. 2. Business enterprises--Computer networks. 3. Information technology--Management. 4. Software

architecture. I. Lam, Wing Hong. II. Shankararaman, Venky.

HD30.213.E58 2007

658.4'038011--dc22

2007007279
British Cataloguing in Publication Data
A Cataloguing in Publication record for this book is available from the British Library.

All work contributed to this book is new, previously-unpublished material. The views expressed in this book are those of the authors, but
not necessarily of the publisher.
Table of Contents

Detailed Table of Contents................................................................................................................... vi

Preface . ................................................................................................................................................. xi
Acknowledgment . .............................................................................................................................. xix

Section I
Business Requirements and Organizational Modeling

Chapter I
Dissolving Organisational and Technological Silos: An Overview of Enterprise Integration
Concepts / Wing Lam and Venky Shankararaman................................................................................... 1

Chapter II
Success Factors and Performance Indicators for Enterprise Application Integration /
Alexander Schwinn and Robert Winter.................................................................................................. 23

Chapter III
... and the Social Matters / Amany R. Elbanna...................................................................................... 40

Chapter IV
Precontract Challenges: Two Large System Acquisition Experiences / Ayça Tarhan,
Çiğdem Gencel, and Onur Demirors..................................................................................................... 51

Section II
Business Process Management

Chapter V
Process Integration Through Hierarchical Decomposition / Ayesha Manzer and Ali Dogru................ 75

Chapter VI
Using a Standards-Based Integration Platform for Improving B2B Transactions /
Andrew P. Ciganek, Marc N. Haines, William (Dave) Haseman, and Lin (Thomas) Ngo-Ye............... 92
Chapter VII
The Changing Nature of Business Process Modeling: Implications for Enterprise Systems
Integration / Brian H. Cameron .......................................................................................................... 107

Chapter VIII
Business Process Integration in a Knowledge-Intensive Service Industry / Chris Lawrence ............ 119

Section III
Integration Methods and Tools

Chapter IX
A Systematic Approach for the Development of Integrative Business Applications /
Michalis Anastasopoulos and Dirk Muthig ........................................................................................ 139

Chapter X
Visual Environment for Supply Chain Integration Using Web Services / Guillermo Jiménez-Pérez
and Javier Mijail Espadas-Pech ......................................................................................................... 164

Chapter XI
A Framework for Information Systems Integration in Mobile Working Environments /
Javier García-Guzmán, María-Isabel Sánchez-Segura, Antonio de Amescua-Seco, and
Mariano Navarro ................................................................................................................................ 187

Chapter XII
Enterprise Application Integration from the Point of View of Agent Paradigm / Min-Jung Yoo ....... 212

Chapter XIII
Web Services Hybrid Dynamic Composition Models for Enterprises / Taha Osman,
Dhavalkumar Thakker, and David Al-Dabass .................................................................................... 225

Section IV
Enterprise Integration Case Studies

Chapter XIV
Case Study: Enterprise Integration and Process Improvement / Randall E. Duran ........................... 240

Chapter XV
Case Study Implementing SOA: Methodology and Best Practices / Gokul Seshadri ........................ 255
Chapter XVI
Application Integration: Pilot Project to Implement a Financial Portfolio System in a
Korean Bank / So-Jung Lee and Wing Lam ........................................................................................ 273

Chapter XVII
Case Study: Service-Oriented Retail Business Information System / Sam Chung, Zachary Bylin,
and Sergio Davalos ............................................................................................................................ 284

Chapter XVIII
Realizing the Promise of RFID: Insights from Early Adopters and the Future Potential /
Velan Thillairajah, Sanjay Gosain, and Dave Clarke ........................................................................ 306

Compilation of References .............................................................................................................. 319

About the Contributors ................................................................................................................... 333
Index ................................................................................................................................................... 341
Detailed Table of Contents

Detailed Table of Contents................................................................................................................... vi

Section I
Business Requirements and Organizational Modeling

This chapter examines the evolution of enterprise integration (EI) and its growing importance amongst
organizations. The chapter describes how organizational divisions and silos have a limiting effect on
business transformation. It gives an overview of how enterprise integration overcomes these limitations,
both from the technical and business perspectives. The challenges associated with enterprise integration
adoption are also discussed.

The effectiveness of information systems is closely related to the degree of integration between different
applications. This chapter examines five critical success factors for enterprise application integration
(EAI), namely, minimal project expense, optimal reuse of components, complexity reduction, optimal
coupling of applications, and minimal cost of EAI infrastructure. The concept of agility is proposed as
a confluence of these factors, which is defined as the extent to which a system is able to react to change.
To improve agility, each factor must be managed and measured separately.
Chapter III
... and the Social Matters / Amany R. Elbanna ..................................................................................... 40

This chapter explores how social and organizational aspects can affect ERP (enterprise resource plan-
ning) projects and their ability to integrate different parts of the enterprise. The chapter draws from a
successful case of a multinational ERP implementation in a large international organization. The socio-
logical theory of the actor network is used to analyse relationships and conflicts in the case. The chapter
concludes with the recommendation that one should examine the roles of all actors with the power to
affect not only the implementation project, but also the system being implemented.

Chapter IV
Precontract Challenges: Two Large System Acquisition Experiences / Ayça Tarhan,
Çiğdem Gencel, and Onur Demirors .................................................................................................... 51

This chapter discusses experiences in the acquisition of software-intensive systems prior to establishing a
contract. One significant challenge in this respect is the identification of functional requirements. Draw-
ing from two case studies of large-scale military applications, the authors contend that business process
modeling is an effective way to explicitly define requirements while creating visibility and consensus
among different stakeholders of major IT projects.

Section II
Business Process Management

Chapter V
Process Integration Through Hierarchical Decomposition / Ayesha Manzer and Ali Dogru ............... 75

Business processes are so complex that an engineering approach is often required to design and construct
them. This chapter presents an approach to constructing enterprise processes based on the integration of
component processes. In this approach, process representations at the logical as well as physical levels
are depicted in a hierarchy, and a graphical tool is used to support enterprise process construction.

Chapter VI
Using a Standards-Based Integration Platform for Improving B2B Transactions /
Andrew P. Ciganek, Marc N. Haines, William (Dave) Haseman, and Lin (Thomas) Ngo-Ye............... 92

In the past, B2B (business to business) has generally been adopted only by large organizations who can
afford the technology and business investment associated with it. This chapter explores, through a case
study, the use of XML (extensible markup language) and Web services in conjunction with an integration
broker to provide a B2B solution. The authors argue that existing B2B solutions, largely based around
EDI (electronic data interchange), present a high entry barrier to smaller organizations, and that the use
of XML and Web services provide an alternative lower cost B2B solution that may be more suitable.
Chapter VII
The Changing Nature of Business Process Modeling: Implications for Enterprise Systems
Integration / Brian H. Cameron .......................................................................................................... 107

Today, the information systems development life cycle is seeing increasing effort and emphasis being
placed upon front-end analysis rather than back-end development. This chapter provides an overview
of business process management, which is becoming an integral aspect of system analysis. The chapter
suggests that the growing maturity of business process management standards and technologies will
drive the transition to more service-oriented IT architectures in the future.

Chapter VIII
Business Process Integration in a Knowledge-Intensive Service Industry / Chris Lawrence ............ 119

This chapter describes the importance of metamodels, particularly in relation to knowledge-intensive

service industries. The key guiding principle is to define the process model at the logical level, free
from any technical implementation. Business process integration is then a matter of achieving the best
possible overall physical engine to implement that process model from available legacy applications,
applied investment opportunity, and expert development resources.

Section III
Integration Methods and Tools

This chapter presents a methodology for the creation of EAI solutions based on the concept of software
product-line engineering. In this approach, a designer builds not one system, but a family of systems,
taking into account all the possible different integration contexts in which the system might be used now
and in the future. This overcomes one of the weaknesses with existing enterprise application integration
tools that provide little methodological support.

Despite developments in supply chain management, there is relatively little in terms of tool support
for supply chain design and development. This chapter demonstrates a visual tool for automatic supply
chain integration. By clicking in the appropriate tables, functions, and fields, users can specify the data
needed for integration. Given these design inputs, integration code can then be automatically generated
in the form of Web services.
Chapter XI
A Framework for Information Systems Integration in Mobile Working Environments /
Javier García-Guzmán, María-Isabel Sánchez-Segura, Antonio de Amescua-Seco, and
Mariano Navarro ................................................................................................................................ 187

As data sources become more distributed, it is important for software applications to be able to access
data in a transparent manner despite the fact that the data are residing physically in different places. This
chapter presents an integration framework called DAVINCI aimed at providing mobile workers with
mobile software applications to query and update information coming from different and heterogeneous
databases. The chapter describes the trials developed using the DAVINCI architecture in different Eu-
ropean countries.

Chapter XII
Enterprise Application Integration from the Point of View of Agent Paradigm / Min-Jung Yoo ....... 212

This chapter describes the basic notions of intelligent agents and multiagent systems, and proposes
possible types of their application to enterprise integration. The agent-based approaches to enterprise
application integration are considered from three points of view: (a) It means using an agent as a wrapper
of an application or service execution, (b) it means constructing a multiagent organization within which
agents are interacting and providing emergent solutions to enterprise problems, and (c) it means using
the agent as an intelligent handler of heterogeneous data resources in an open environment.

This chapter describes an attempt to introduce semantics to workflow-based composition. A composition

framework is presented based on a hybrid solution that merges the benefits of the practicality of use and
adoption popularity of workflow-based composition, with the advantage of using semantic descriptions
to aid both service developers and composers in the composition process and facilitate the dynamic
integration of Web services into it.

Section IV
Enterprise Integration Case Studies

Chapter XIV
Case Study: Enterprise Integration and Process Improvement / Randall E. Duran ........................... 240

This chapter examines common EI challenges and outlines approaches for combining EI and process
improvement based on the process improvement experiences of banks in several different countries.
Common EI-related process improvement challenges are poor usability within the user desktop environ-
ment, a lack of network-based services, and data collection and management limitations. How EI affects
each of these areas is addressed, highlighting specific examples of how these issues present themselves
in system environments.
Chapter XV
Case Study Implementing SOA: Methodology and Best Practices / Gokul Seshadri ........................ 255

This chapter explores the gradual evolution of SOA (service-oriented architecture) through various
phases and highlights some of the approaches and best practices that have evolved out of real-world
implementations in regional retail banks. Starting from a step-by-step approach to embrace SOA, the
chapter details some typical challenges that creep up as the usage of SOA platforms becomes more
and more mature. Also, certain tips and techniques that will help institutions maximize the benefits of
enterprise-wide SOA are discussed.

Chapter XVI
Application Integration: Pilot Project to Implement a Financial Portfolio System in a
Korean Bank / So-Jung Lee and Wing Lam ........................................................................................ 273

This chapter describes a case study of application integration in a Korean bank. The case examines the
integration technology employed, and the adoption of the technology on a pilot project. The chapter
highlights some of the managerial implications of application integration and discusses the broader, orga-
nizational impact of application integration. Importantly, application integration efforts should be justified
by a sound business case and carefully introduced into the organization in an incremental fashion.

This chapter uses the example of a retail business information system to illustrate the concept of service-
oriented development and integration in a number of different scenarios. The chapter shows how using
a service-oriented architecture allows businesses to build on top of legacy applications or construct new
applications in order to take advantage of the power of Web services.

RFID (radio frequency identification) is gathering increasing interest from many organizations. This
chapter discusses the adoption and potential usages of RFID in the case of enterprise integration projects
such as supply chain management. Through electronic tagging, RFID can enable stocks to be monitored
in real time to a level that was previously not practical or cost effective. RFID can therefore be considered
an important component of an enterprise integration solution.

Compilation of References .............................................................................................................. 319

Preface

It is clear that we now live in a world where one expects everything to be connected, or for want of a
better word, integrated. For example, when I get onto the Web and do my Internet banking, I expect to
be integrated directly with my bank to see exactly how much money I have. Similarly, when I want to
book air tickets online, I expect to be integrated into the airline reservation system to see what flights
are available, and whether they are fully booked or not. Businesses too are demanding this kind of close
integration. A supermarket, for example, that wants to match demand and supply needs to integrate its
own stock control system with that of its suppliers so that goods being taken off the shelf are quickly
replenished.
Increasingly then, there is a need for organizations to provide services in an integrated fashion. This,
however, is easier said than done. Integration cannot be achieved unless the information technology used
by the organization is also integrated. Unfortunately, organizations have had a long history of creating
systems that operate in isolation from other systems. From conception, many of these systems have
been designed to address the specific requirements in a particular functional area such as accounting, or
personnel and stock control. This functional orientation, however, has tended to reinforce departmental
silos within the organization, resulting in an IT architecture characterized by numerous “islands of ap-
plications” that remain quite separate from each other (Sawhney, 2001).
Of course, integration is not an entirely new problem. Many organizations have undertaken specific
projects in the past where they had to integrate a number of different systems. The traditional approach
to integration, often referred to as point-to-point integration (Linthicum, 2001), has tended to involve
crafting custom interfaces between two systems, for example, System A and System B. However, when
System A needs to share information with System C, another set of interfaces needs to be created be-
tween System A and System C. Similarly, when System B needs to communicate with System C, then
another set of interfaces is created. In such an approach to integration, a new set of interfaces is created
for each pair of systems that need to communicate. Unfortunately, such a piecemeal approach does not
scale well when tens, even hundreds, of individual systems need to be integrated as is often the case in
large organizations. Organizations that have attempted to use the point-to-point approach for large-scale
integration have typically ended up with tangled webs of integration interfaces in which the high cost
of maintaining such a large number of interfaces has become a burden on IT budgets.
In short, the challenge faced by organizations today is to find scalable and economical solutions to
the problem of large-scale integration (Sharif, Elliman, Love, & Badii, 2004). This has given rise to the
term enterprise integration (EI), which denotes the need to integrate a large number of systems that may
be highly distributed across different parts of the organization.
xii

Past solutions

This is not to say that solutions to the challenge of large-scale integration have not been proposed in
the past. In the early ’90s, distributed objects and component architectures were mooted as the answer
to the challenge of integration (Digre, 1998). This was typified by the Common Object Request Bro-
ker Architecture (CORBA), which provided an open standard for distributed systems to communicate
(Vinoski, 1997). However, CORBA projects were perceived as technically very complex, requiring
significant development effort (Henning, 2006). Furthermore, industry support and standardization
efforts for CORBA proved problematic, leading to its slow demise. More recently, enterprise resource
planning (ERP) solutions, such as SAP and Peoplesoft, which involve replacing existing systems with
a suite of interconnected modular systems from a single vendor, were seen as the answer to systems
integration (Davenport, 1998). However, organizations soon realized that no single ERP system could
address all the requirements of an organization (Hong & Kim, 2002). In fact, an ERP system often needed
to coexist with existing systems, therefore heightening, rather than removing, the need for integration
(Themistocleous, Irani, & O’Keefe, 2001).
However, it is not just the scale of integration that is challenging. The integration of IT systems is
also severely hampered by the technical complexities of integration (Lam, 2004). For one, a particular
system may have been developed on a technology platform that is, at worse, incompatible with the
technology platforms used by other systems. In the ’70s and ’80s, for example, many systems were de-
veloped on what is now considered legacy mainframe technology, while the ’90s saw the adoption and
proliferation of Internet and Web-based technologies. Therefore, most organizations have, over time,
ended up with a portfolio of systems based on a diverse mix of technologies. It must also be mentioned
that many legacy systems were originally conceived to serve as stand-alone systems with little intent
for integration. Such systems, which represent a huge financial investment to the organization, tend to
become operationally embroiled within the organization, which makes them difficult to replace with
newer, more modern systems (Robertson, 1997).

Promising DeveloPments

Recently, however, there have been some promising developments within the IT industry that, going
forward, offer the potential for easing the technical challenge of integrating systems in the future. These
developments center on the adoption of Web services (Cerami, 2002) as a standard for open communi-
cation over the Internet. In short, Web services enable systems to communicate to other systems over
the Internet or, as the case may be, an intranet. For this to happen, systems must expose, as services, the
functionality they wish to make available to other systems. A stock system, for example, may expose
a “check current stock” service to other systems so that they can check, in real time, the current stock
levels of a particular product. One can imagine how this might help buyers and suppliers coordinate
the supply chain much more effectively. However there are several barriers, though insignificant, to
the adoption of Web services. One of these barriers is the immaturity of the standards (Bloomberg &
Schmelze, 2002). The standards relating to Web services are relatively new and continue to evolve at a
rapid pace. For obvious reasons, organizations are often loath to make substantial technology investments
relating to standards that may be quickly superseded. Other barriers include concerns over performance
and reliability. Because Web services rely on the Web, performance and reliability cannot be guaran-
teed, nor are Web services generally suitable for high-volume transaction processing. For these reasons
alone, Web services may not be a suitable technical solution to systems integration in mission-critical
xiii

business processing. In addition, while it might be useful to design new systems with Web services in
mind, existing systems may need to be substantially reengineered in order to conform to a Web services
model. So, while Web services are certainly a promising technical solution to systems integration, they
are by no means a complete one.
Another interesting development within the IT industry is that of the service-oriented architecture
(SOA). SOA (He, 2003) is something that has piggybacked off the Web services bandwagon, but in the
last 3 years or so, has gained a momentum of its own. In an SOA view of the world, systems expose
their functionality as a set of services, typically as a set of Web services. It does not matter which tech-
nology platform the system sits on or what development language the system has been written in as the
services are defined in a way that other systems can readily understand. In fact, other systems do not
need to worry or necessarily care about how these services are actually implemented. These services can
either be public or published in nature. If services are public, they are typically known to a limited set
of other systems, such as in the case of a corporate intranet. If services are published, however, details
of the services are registered in a directory from which other systems, including those external to the
organization, can discover and use the services. In essence, in an SOA, there is a network of loosely
coupled systems where a complex business function may be implemented by calling upon the services
offered by other systems.
With SOA, the issue of integration is no longer problematic so long as every system conforms to the
SOA model and is able to offer its functionality through a set of defined services. That, unfortunately,
is the point where SOA suffers the same adoption problems as Web services, with which it is closely
aligned. If organizations could start with a clean sheet again, they would probably develop their systems
to conform to an SOA model. In reality, however, organizations need to manage, and live with, at least in
the immediate and near future, the huge investments they have already made in existing legacy systems.
So SOA and Web services are not the silver bullets that will resolve all IT woes, although some would
like to believe otherwise. They clearly offer a pathway, or at a least a direction, for resolving many in-
tegration issues, but are not a solution that can be readily implemented by organizations today.

enterPrise aPPlication integration

Fortunately, what might serve as a more complete and holistic solution to enterprise integration are the
enterprise application integration (EAI) tools being marketed by integration vendors such as Webmethods,
TIBCO, IBM, Microsoft, Seebeyond, BEA, Mercator, and Vitria (McKeen & Smith, 2002). Such EAI
tools did not appear overnight but evolved from the message-oriented middleware (MOM) tools that
became popular as a means of providing high-volume, reliable communications between systems. In
general, EAI tools have three main components. The first is an integration broker that serves as a hub for
intersystem communication. The integration broker performs a number of functions such as multifor-
mat translation, transaction management, monitoring, and auditing. The second is a set of adapters that
enables different systems to interface with the integration broker. An adapter is essentially a gateway or
wrapper that provides the means by which packaged applications (such as SAP), database applications
(such as Oracle), legacy systems (such as mainframe), and custom applications (written in Java or an-
other programming language) can connect to the integration broker (Brodie & Stonebraker, 1995). The
third component is an underlying communications infrastructure, such as a reliable high-speed network,
which enables systems to communicate with each other using a variety of different protocols.
Although EAI has, until now, occupied a rather niche market, the growing importance of enterprise
integration can only mean that the size of the EAI market will expand. One can also observe a growing
xiv

sophistication and maturity in EAI tools. One area of interest, for example, is that of business-process
management (BPM). The reason for progress here is because the motivation behind many integration
projects is to support business processes that span across different parts of an organization. An e-busi-
ness transaction, for instance, may begin at the order-entry system, but such transactional information
may be passed onto an account-management, payment, logistics, and then eventually a delivery-order
system as part of broader business-process flow. Hence, the integration of these systems is driven by
business-process needs. Some EAI tools are therefore beginning to include BPM tools that enable the
modeling of business processes in a graphical format. These business-process models are subsequently
linked to calls or operations that initiate processing within a system. As it turns out, few organizations
have their business processes so rigorously defined and mapped out. The introduction of BPM tools
therefore provides a timely and pertinent reason for organizations to revisit their business processes.
Another related area of growing sophistication in EAI tools is that of business activity monitoring
(BAM). BAM is about monitoring the health of activities within a business process. If, for example, a
business process fails for some reason, this will be picked up by the BAM tool and an appropriate alert
can be raised. BAM can also be used to identify bottlenecks within a process by tracking throughput and
assessing the rate at which the different activities within a business process are successfully completed.
Clearly, BAM tools, and for that matter, BPM tools, are particularly well-suited to organizations that
have business processes that are, or are inclined to be, heavily automated.
So, EAI tools are themselves evolving, and what one is beginning to see is a closer alignment be-
tween technical integration, which relates to how systems talk to each other, and business integration,
which relates to why systems need to talk to each other. At the same time, business integration is being
facilitated by the increasing standardization within the business integration space and convergence by
EAI vendors in working toward these standards. Central to this effort is the business process modeling
language (BPML 1.0) standard, developed under the auspices of the Business Process Management
Initiative (http://www.BPMI.org), which provides a formal model for describing any executable end-
to-end business process. In theory, if all organizations described their business processes in BPML, they
would find it much easier to collaborate.

strategy

Aside from technology and process issues, the other important element of enterprise integration is the
strategic element. Spending thousands of dollars on EAI tools and teams of individuals modeling business
processes does not necessarily mean that organizations will solve their enterprise integration problems.
One missing piece from all this, like any other major endeavor, is the importance of strategic direction
and senior-management support (Lam, 2005). Enterprise integration is something that affects many dif-
ferent parts of the organization; the problem is not confined to one particular part of the organization.
As such, success can only be achieved if the various departments buy into enterprise integration and
share the same vision of how to achieve it. This, of course, is easier said than done, and there are several
challenges. One of the challenges is the fact that, in a large organization, individual departments may be
used to operating autonomously, with minimal interaction and engagement with each other. The notion
of working with other departments, or at least coordinating their technology strategies, is something
that may appear quite novel. At worst, the endeavor becomes a political battle, where certain divisions
are seen to be vying for control, encroaching on the space occupied by others. This, of course, is not
something that is peculiar to enterprise integration projects, but is seen any large project that involves
different divisions within an organization working in new ways.
xv

Importantly, each department must believe that there is a case for enterprise integration, either fi-
nancially in terms of reducing the costs of systems integration, or from a business perspective in terms
of enabling new business processes or enhancing business performance. Unfortunately, individual de-
partments, by their nature, have a localized view of their integration needs. Getting the bigger picture
of an organization’s enterprise integration needs is a message that must be communicated to individual
departments so that they understand the rationale for a strategic perspective. Of course, if one left each
department to its own devices to develop its own solution to its own set of integration problems, there
would be much reinvention of the wheel and wasted time and effort. A single strategic integration solu-
tion therefore makes much more sense, where an organization can address the integration requirements
in different parts of the organization in a cost-effective and controlled manner. It certainly does not make
sense for each department to purchase its own EAI tool, for example.
Another thing to bear in mind is that enterprise integration is not something that can take place over-
night. Enterprise integration is a long-term initiative that, in some cases, may take years to complete
depending upon the number of systems to be integrated and the complexity of the integration challenge.
Organizations therefore need to think carefully about how to plan and roll out the enterprise integration
initiative. One approach would be to identify the high-priority integration projects within the organization
where the urgency or potential business returns from integration are greater. Such successful projects
could then serve to reinforce the case for integration and perhaps even provide inspiration for further
integration projects. Another more risk-adverse approach would be to identify pilot projects that could
serve as the grounds for organizations to build up expertise and knowledge of enterprise integration
before tackling larger and more substantial projects. Such a more cautious strategy might suit organiza-
tions with little prior experience with enterprise integration. It might also be wise to consider integration
projects in parallel with other business improvement projects that, in turn, can help shape the integration
project. A good example is business-process reengineering, where it does not make sense to automate a
process that is intrinsically inefficient or problematic, but where an opportunity presents itself to make
broader organizational changes. In fact, from an organizational perspective, information systems integra-
tion involves changes in business processes, and more broadly, a realignment of technology goals with
business goals (Themistocleous et al., 2001).
To sum up, enterprise integration has become a strategic enabler for many of the business initia-
tives organizations are implementing or wish to embark on, whether it is supply chain management,
customer relationship management, e-business, or simply more efficient ways of business processing.
The traditional methods of systems integration have not proved to be scalable, so solutions are needed
that can address both the scale and complexity of integration. Enterprise integration, however, is not
just about technology integration, it is also about process and business integration, and so may involve
a reconceptualization of how organizations work and do business.

organization of the Book

This book is organized into four main sections, each of which has a number of chapters. The first section
is entitled “Managing Enterprise Integration” and contains the following chapters.
Chapter I examines the evolution of enterprise integration and its growing importance amongst or-
ganizations. The chapter provides a good overview of the benefits of enterprise integration and some of
the challenges associated with its adoption.
Chapter II looks at five critical success factors for enterprise application integration, namely, minimal
project expense, optimal reuse of components, complexity reduction, optimal coupling of applications,
xvi

and minimal cost of EAI infrastructure. The authors conclude that the success factors are closely inte-
grated, and they develop from this a number of hypotheses.
Chapter III explores how social and organizational aspects can affect ERP projects and their ability to
integrate different parts of the enterprise. The chapter draws from the successful case of a multinational
ERP implementation in a large international organization and concludes with the recommendation that
one should examine the roles of all actors with the power to affect not only the implementation project
but also the system being implemented.
Chapter IV discusses experiences in the acquisition of software-intensive systems prior to establish-
ing a contract. One significant challenge is the identification of functional requirements, and the authors
contend that business-process modeling is an effective way to explicitly define requirements while creat-
ing visibility and consensus among different stakeholders of major IT projects.

The second section is entitled “Business-Process Management” and contains the following chap-
ters.
Chapter V presents an approach to constructing enterprise processes based on the integration of
component processes. In this approach, process representations at the logical as well as physical levels
are depicted in a hierarchy, and a graphical tool is used to support enterprise process construction.
Chapter VI explores, through a case study, the use of XML (extensible markup language) and Web
services in conjunction with an integration broker to provide a B2B (business-to-business) solution.
The authors argue that existing B2B solutions, largely based around EDI (electronic data interchange),
present a high entry barrier to smaller organizations, and that the use of XML and Web services provides
an alternative lower cost B2B solution that may be more suitable.
Chapter VII provides an overview of business-process management. The chapter describes how
systems development has changed from being largely implementation oriented to now being analysis
oriented, and suggests that business-process management standards and technologies will drive the
transition to more service-oriented IT architectures in the future.
Chapter VIII describes the importance of metamodels, particularly in relation to knowledge-inten-
sive service industries. The key guiding principle is to define the process model at the logical level, free
from any technical implementation. Business-process integration is then a matter of achieving the best
possible overall physical engine to implement that process model from available legacy applications,
applied investment opportunities, and expert development resources.

The third section is entitled “Integration Methods and Tools” and contains the following chapters.
Chapter IX presents a methodology for the creation of EAI solutions based on the concepts of soft-
ware product-line engineering. The overall idea is to view the external applications with which a given
system wants to integrate as a family of systems. In this way, the flexibility required by EAI applications
can be assured.
Chapter X demonstrates a visual tool for automatic supply chain integration. By clicking on the ap-
propriate tables, functions, and fields, users can specify the data needed for integration. Integration code
can then be automatically generated using Web services.
Chapter XI presents an integration framework called DAVINCI aimed at providing mobile workers
with mobile software applications to query and update information coming from different heterogeneous
databases. The chapter describes the trials developed using the DAVINCI architecture in different Eu-
ropean countries.
Chapter XII describes the basic notions of intelligent agents and multiagent systems, and proposes
their possible applications to enterprise integration. Agent-based approaches to enterprise application
xvii

integration are considered from three points of view: (a) using an agent as a wrapper of an application
or service execution, (b) constructing a multiagent organization within which agents are interacting and
providing emergent solutions to enterprise problems, and (c) using the agent as an intelligent handler of
heterogeneous data resources in an open environment.
Chapter XIII describes an attempt to introduce semantics to workflow-based composition. A com-
position framework is presented based on a hybrid solution that merges the benefits of the practicality
of use and adoption popularity of workflow-based composition with the advantage of using semantic
descriptions to aid both service developers and composers in the composition process and facilitate the
dynamic integration of Web services into it.
The fourth and final section is entitled “Enterprise-Integration Case Studies” and contains the fol-
lowing chapters.
Chapter XIV examines common EI challenges and outlines approaches for combining EI and process
improvement based on the process improvement experiences of banks in several different countries.
Common EI-related process improvement challenges are poor usability within the user desktop environ-
ment, a lack of network-based services, and data collection and management limitations. How EI affects
each of these areas is addressed, highlighting specific examples of how these issues present themselves
in system environments.
Chapter XV explores the gradual evolution of SOA through various phases and highlights some of
the approaches and best practices that have evolved out of real-world implementations in regional retail
banks. Starting from a step-by-step approach to embrace SOA, the chapter details some typical chal-
lenges that creep up as the usage of an SOA platform becomes more and more mature. Also, certain tips
and techniques that will help maximize the benefits of enterprise-wide SOA are discussed.
Chapter XVI describes a case study of application integration in a Korean bank. The case examines
the integration technology employed and the adoption of the technology in a pilot project. The chapter
highlights some of the managerial implications of application integration and discusses the broader
organizational impact of application integration.
Chapter XVII uses the example of a retail business information system to illustrate the concept of
service-oriented development and integration in a number of different scenarios. The chapter shows how
using a service-oriented architecture allows businesses to build on top of legacy applications or construct
new applications in order to take advantage of the power of Web services.
Chapter XVIII discusses the adoption and potential usages of RFID (radio frequency identification) in
the case of enterprise integration projects such as supply chain management. Through electronic tagging,
RFID can enable stocks to be monitored at a level that was previously not practical or cost effective.

references

Bloomberg, J., & Schmelze, R. (2002). The pros and cons of Web services (ZapThink Report). Retrieved
from http://www.zapthink.com/report.html?id=ZTR-WS102
Cerami, E. (2002). Web services essentials. Sebastopol, CA: O’Reilly.
Davenport, T. A. (1998). Putting the enterprise into the enterprise system. Harvard Business Review,
76(4), 121-131.
Digre, T. (1998). Business object component architecture. IEEE Software, 15(5), 60-69.
xviii

He, H. (2003). What is service-oriented architecture. Retrieved from http://www.xml.com/pub/a/

ws/2003/09/30/soa.html
Henning, M. (2006). The rise and fall of CORBA. ACM Queue, 4(5). Retrieved from http://acmqueue.
com/modules.php?name=Content&pa=showpage&pid=396&page=1
Hong, K. K., & Kim, Y. G. (2002). The critical success factors for ERP implementation: An organiza-
tional fit perspective. Information & Management, 40, 25-40.
Lam, W. (2004). Technical risk management for enterprise integration projects. Communications of the
Association for Information Systems, 13, 290-315.
Lam, W. (2005). Exploring success factors in enterprise application integration: A case-driven analysis.
European Journal of Information Systems, 14(2), 175-187.
Linthicum, D. (2001). B2B application integration. Reading, MA: Addison Wesley.
McKeen, J. D., & Smith, H. A. (2002). New developments in practice II: Enterprise application integra-
tion. Communications of the Association for Information Systems, 8, 451-466.
Robertson, P. (1997). Integrating legacy systems with modern corporate applications. Communications
of the ACM, 40(5).
Sawhney, M. (2001). Don’t homogenize, synchronize. Harvard Business Review.
Sharif, A. M., Elliman, T., Love, P. E. D., & Badii, A. (2004). Integrating the IS with the enterprise: Key
EAI research challenges. The Journal of Enterprise Information Management, 17(2), 164-170.
Themistocleous, M., Irani, Z., & O’Keefe, R. (2001). ERP and application integration. Business Process
Management Journal, 7(3).
Vinoski, S. (1997). CORBA: Integrating diverse applications within distributed heterogeneous environ-
ments. IEEE Communications Magazine, 35(2), 46-55.
xix

Acknowledgment

First and foremost, the editors would like to thank all the authors who contributed chapters to the book,
without which this book would not have been possible. As writers ourselves, we know how difficult it is to
write a substantial piece of work and appreciate the considerable efforts that the authors have made.
Many of the authors also served as reviewers, and so deserve a double thank you. Reviewing someone
else’s work is not a trivial task, but many authors who contributed to the book have shown themselves
to be outstanding individuals with an in-depth understanding of the field. In addition, several other in-
dividuals served as reviewers only, and we thank them for their time and effort.
We would also like to thank our respective institutions, U21 Global and the Singapore Management
University, for allowing us the space to develop this book. As academics and academic administrators,
we have had to fit the editorial task of putting this book together with our other day-to-day duties. As
such, the support from our respective institutions for this project is greatly appreciated.
Finally, thanks also go to the staff at IGI Global, whose timely reminders have been instrumental in
completing what has been a long, and often tiring, project. We knew there was light at the end of the
tunnel, but without their patience and assistance, we may never have reached the end.

Wing Lam, Universitas 21 Global

Venky Shankararaman, Singapore Management University
March 2007
Section I
Business Requirements
and Organizational Modeling

Chapter I
Dissolving Organisational and
Technological Silos:
An Overview of Enterprise
Integration Concepts

Wing Lam
U21 Global, Singapore

Venky Shankararaman
Singapore Management University, Singapore

aBstract

Over the last few years, the importance of enterprise integration has grown significantly. As organizations
expand, become more distributed, and rely more on technology, there is a need to ensure both business
processes and technology systems are co-coordinated in a strategic rather than ad-hoc manner. In the
early days of IT, integration was viewed largely as a technical activity. Today, there is a much stronger
business focus. In fact, many of an organisation’s strategic initiatives such as e-business, customer re-
lationship management and supply chain management depend upon enterprise integration. There are
four basic integration architectures, namely, batch integration, point-to-point integration, broker-based
integration and business process integration. Each integration architecture represents varying levels
of enterprise integration maturity. Enterprise integration is a significant undertaking, and carries with
it significant technical and managerial challenges. Managing enterprise integration projects requires,
among other things, a strategic framework, senior management support and risk management. A clear
understanding of enterprise integration requirements is also crucial.

Copyright © 2007, IGI Global, distributing in print or electronic forms without written permission of IGI Global is prohibited.
Dissolving Organisational and Technological Silos

the enterPrise integration What is enterprise integration?

challenge
We define enterprise integration as “[t]he strategic
the integration challenge consideration of the process, methods, tools and
technologies associated with achieving interoper-
Most organisations today are highly depen- ability between IT applications both within and
dent upon information technology. In some external to the enterprise to enable collaborative
organisations, IT provides a competitive edge, business processes.”
although it is generally accepted that most large Importantly, enterprise integration is not
organisations require a basic level of IT simply purely about technology integration. Enterprise
to function. integration also includes a consideration of busi-
Over the years, organisations have invested ness processes that cut across various IT applica-
heavily in IT and, as a consequence, accumu- tions, and so provides the overarching basis for
lated large portfolios of IT systems comprising technology integration. Enterprise integration is
of hundreds, possibly even thousands, of separate therefore an activity that:
IT applications. Historically, individual IT ap-
plications were designed as stand-alone systems • Is business driven rather than technology
addressing specific functional domains such as driven
marketing, sales, personnel, billing, and manu- • Coordinates business processes with and
facturing. As business needs evolved, however, it across different parts of the enterprise
became necessary for individual IT applications • Involves multiple stakeholders
to be integrated in order to support new business • Adopts a strategic rather than tactical or
requirements, for example, the need for customer localized view
details to be automatically transferred from the
sales system to the billing system. Enterprise integration is not some new technol-
While such integration raised organisational ogy fad that will come and go, but an essential
efficiency through increased automation, it was feature of how IT solutions need to be designed in
tactical rather than strategic in nature. Individual order to address today’s business requirements.
IT applications were integrated only as the need Some of the generic kinds of business problems
arose, and creating custom interfaces between that enterprise integration can help solve include
individual IT applications was both expensive the following:
and time consuming. As a consequence of this
piecemeal approach, organisations realized their • Information aggregation: Aggregating,
IT architecture was riddled with a complex mass organising, and presenting information from
of custom interfaces often referred to as “spa- multiple IT sources in one single view
ghetti integration.” Not only was maintaining • Single point of data entry: Replacing the
such interfaces expensive, the need for increasing need for manual and duplicate data entry
levels of integration sophistication have forced into multiple IT applications with data entry
organisations to address their integration needs into a single IT application
more strategically, giving rise to the growing • Process inefficiency: Reducing the effort and
interest in enterprise integration. time required to complete business processes
and eliminating manual inefficiencies
• Web channel integration: Enabling Web-
based customers and partners direct access

Dissolving Organisational and Technological Silos

Figure 1.

E-Business
Integration
Technology Business
Focus Focus
Supply Chain
Systems Management B2B Commerce
Integration & Exchanges
ERP Integration

1990 1995 2000 2004

1998
1985 1993 2002

Real-Time Web Collaborative

Communication Integration Commerce
Customer
Relationship
Management

to the services provided by existing business in real time, thus providing immediate business
systems processing and responsiveness. Technology-
• Supplier integration and supply chain op- wise, middleware solutions based on messaging
timization: Enabling a supplier to integrate between applications and request brokers became
with a larger company’s business process or popular.
an electronic marketplace Throughout the ’90s, e-business integration
and the integration of back-end legacy IT appli-
from a technology focus to a cations with modern Internet and Web-centric
Business focus applications gained prominence. In the 2000s, we
are seeing collaborative commerce, and businesses
Enterprise integration can be seen as an evolu- are now exploiting the Internet to transact with
tionary concept, best viewed within the broader each other within a virtual value chain.
context of major IT trends and movements, as The perception of integration has therefore
depicted in Figure 1. shifted over time from tactical, low-business-value
In the ’70s and ’80s, a commonly used IT term technical plumbing to a strategic and high-value
was “systems integration.” This had a distinct enabler for achieving business competitiveness.
meaning and was often considered as the techni-
cal plumbing that went on behind the scenes to a cio and cto Priority
integrate different IT applications.
In the ’90s, real-time integration became more Enterprise integration is not an issue of concern
prevalent as integration prior to that period was solely for IT architects and designers. In fact,
based largely on a scheduled, non-real-time ba- enterprise integration has consistently been high
sis. Real-time integration referred to the ability on the list of chief information officer (CIO) priori-
of IT systems to communicate with each other ties. For example, in IDC’s Integration Drivers

Dissolving Organisational and Technological Silos

Study (2002), more than 80% of CIOs and CTOs assessing the need for
responded that integration was either mandatory enterprise integration
for addressing mission-critical activities or was a
key enabler for meeting business-critical needs. To some organisations, it may be obvious that
Furthermore, Gartner Research estimates that they are facing serious integration challenges
35% of all IT spending is for application inte- and that there is a clear business case for enter-
gration. This reflects the trend toward the use prise integration. On the other hand, the need for
of packaged IT applications offered by vendors enterprise integration may be less obvious. To
that are integrated with an organisation’s exist- quickly assess whether enterprise integration is
ing IT applications rather than developed from worth investigating further, organisations should
scratch. ask the following questions:

Figure 2.

Project Drivers

E-business
Benefits

Supply chain management Greater business

responsiveness
ERP Expansion
Improved customer
service and support
Customer self-service
Business process
Business intelligence automation

Shorter processing
Customer relationship management cycles

Reduced processing
Customer expectations errors

Process visibility
E-Government

Lower transaction
Knowledge management
costs
Enterprise
IT System Consolidation Integration Improved supply-chain
relationships

Organizational Closer business

Drivers partnerships

Corporate mergers, acquisitions Rapid introduction of

and partnerships new business services

Industry regulation
Future integration path

Industry deregulation Lower IT maintenance

costs
Globalization

Dissolving Organisational and Technological Silos

• Is there a requirement to collate information Organisational drivers are those that are
from several IT systems in real time to meet brought about by organisational change or transi-
specific business objectives? tion. (See Box 2.)
• Does the organisation have many IT sys-
tems that need to communicate with each Benefits of Enterprise Integration
other?
• Is there a need to key in and update the same Enterprise integration has a number of potential
details in separate IT systems? benefits to organisations. (See Box 3.)
• Is it difficult and time consuming to extract
information from several IT systems?
• Does the organisation batch upload informa- integration strategies
tion from one IT system to another?
• Is the same information duplicated across eai, B2Bi, and Web integration
many IT systems? Projects
• Is there an issue with data inconsistency
between IT systems? Most enterprise integration projects generally
fall into one of three project categories, namely,
If the answer is “yes” to several of the above enterprise application integration (EAI), busi-
questions, then it may well be worthwhile for ness-to-business integration (B2Bi), and Web
the organisation to look further into enterprise integration, as shown in Figure 3.
integration. An EAI project is concerned with integrating
the IT applications that reside within the organisa-
tion, for example, the integration of the customer-
motivations for accounts IT system with the order-management IT
enterPrise integration system. A Web integration project is concerned
with integrating an organisation’s IT applications
Drivers for enterprise integration with Web applications to provide a Web channel.
A B2B integration project, on the other hand, is
Organisations are under constant pressure to concerned with integrating an organisation’s IT
remain competitive in an ever-changing business system with those of its business partners or sup-
environment. Figure 2 shows some of the typical pliers such as in an extended supply chain. EAI,
business drivers for enterprise integration, and Web integration, and B2B projects are compared
the potential benefits that enterprise integration in Table 1.
can bring.
The drivers for enterprise integration generally integration timeliness:
fall into one of two categories: project drivers and asynchronous vs. real time
organisational drivers. Project drivers are those
projects that cannot be realized or delivered with- One of the main factors to consider when designing
out a significant amount of enterprise integration integration solutions is integration timeliness, or
work. Examples of some typical project drivers the manner in which IT systems communicate with
are given in Box 1. one another. In real-time integration, IT systems
communicate immediately with each other as and
when required, and there is no time delay in the

Dissolving Organisational and Technological Silos

Box 1.
Project Drivers
E-business
• Integrating legacy IT systems containing core business functionality with front-end Web-based systems such as
application servers and portals

Customer relationship management (CRM)

• Building a single, consolidated view of the customer by integrating customer data that are distributed across
different IT applications
• Integration of customer databases, and call-centre and Web-based customer service systems

Business intelligence
• The collation of data from a variety of IT applications and data sources into a data warehouse
• The mining of data from multiple sources to identify patterns and trends

Customer self-service
• Enabling customers to perform services traditionally performed by staff by integrating front-end customer
service applications with back-end IT systems
• Integrating customer service IT applications running over multiple channels (Web, digital TV, mobile)
• Using customer service workflow events to trigger IT system services and processing

Expansion of ERP (enterprise resource planning) systems

• The integration of ERP systems that provide core functionality with more specialised IT systems used within the
organisation

Supply chain management

• Integrating disparate IT systems for order management, manufacturing resource planning, scheduling, and
logistics
• The exchange of real-time information between buyers and suppliers to optimize the supply chain and
streamline workflow

Customer expectations
• Meeting customer expectations for immediate access to real-time services and information that require the
integration of IT systems
• Achieving straight-through processing (STP) for increased efficiency, particularly for those operating in the
financial-services sector

Knowledge management
• Real-time search and access to knowledge content that is distributed across multiple knowledge sources
• The management of knowledge assets within the enterprise

E-government
• Integrating legacy back-end government systems with front-end Web-based systems
• Enabling intra- and intergovernment agency workflows and data exchange

Dissolving Organisational and Technological Silos

Box 2.
Organisational Drivers

Consolidation, mergers, and acquisitions

• Consolidating or merging duplicate or overlapping IT systems that perform similar functionality

Globalisation
• The integration and consolidation of data from IT systems that reside in different countries and regions
• The enablement of business processes and workflows that cut across multiple organisational and regional units

Industry deregulation
• Forcing monolithic IT systems that supported a spectrum of business services to be broken up into smaller, more
manageable IT systems that are loosely integrated

Industry regulation
• Government and industry regulations that force systems to be integrated, for example, the United States Health
Insurance Portability and Accountability Act of 1996 (HIPAA), which seeks to establish standardized mechanisms
for electronic data interchange (EDI), security, and confidentiality of all health-care-related data

Box 3.

Benefits
Greater business responsiveness
It is easier to deliver real-time business services because the functionality and information of IT systems are immedi-
ately accessible.

Customer support and service

Customer service staff have a single, consistent view of the customer and immediate access to relevant customer
data, thus allowing for a higher level of customer service to be delivered. Customers can also self-service, enabling
them to take advantage of services anytime, anywhere.

Business process automation

Processes that were previously performed manually are now automated and streamlined.

Process visibility
Because business processes are automated, they can be more easily monitored and checked.

Shorter processing cycles

The time required to complete a business process is significantly reduced.

Reduced processing errors

Because less reliance is placed on manual processing, the scope for clerical errors is significantly reduced.

Closer business partnerships

The ability to exchange information with business partners in a dynamic and real-time fashion leads to closer and
more effective business partnerships.

Improved supply chain relationships

The exchange of up-to-date supply chain information leads to more optimized supply chains between buyers and
suppliers. Stock levels can be reduced and just-in-time (JIT) deliveries are possible.

Future integration path

With careful planning and design, the creation of a robust integration architecture will enable future IT systems to be
integrated more easily.

Rapid introduction of new business services

New business services can be rapidly introduced because IT systems are integrated.

Dissolving Organisational and Technological Silos

Figure 3.

Organization B

Organization A

Order
Web Customer Management Pay ments
Application CRM Accounts Application Application

Web Inte gration Enterprise Application Integration B2B Integration

Table 1.

EAI B2Bi Web Integration

Intra-organisation: Existing IT
Scope of Intra-organisation: IT systems Interorganisation: IT systems
systems with new Web-based
Integration within the organisation between different organisations
front-end applications

Operational efficiency,
Typical Project customer relationship Supply chain management, E-business, Web-channel
Drivers management, business-process B2B commerce services
automation

Key Business-process management, Document and data exchange Online security, transaction
Challenges workflow standards management

Dissolving Organisational and Technological Silos

communication. Imagine, for example, a Web Organisations need to decide whether their
site that communicates with a back-end stock- integration needs are for real-time integration
price system to provide users with up-to-date or asynchronous integration. Given the business
information about stock prices. However, where climate of short processing and faster turnaround
there is a time delay in the communication, the cycles, there has been a general move toward
integration is known as asynchronous. Imagine, real-time integration and the adoption of an
for example, a Web site that allows a customer to event-driven architecture. However, for some
reserve hotel rooms but can only confirm those organisations, the cost and feasibility associated
room reservations 24 hours later. with adopting an event-driven architecture may
Real-time integration typically relies on an be prohibitive.
event-driven architecture. In an event-driven
architecture: levels of integration

• Business events generate messages that are Another way of looking at integration is in terms
sent to all the appropriate IT systems of the level at which integration occurs. Integra-
• Upon receipt of the message, the IT systems tion can occur at five levels, namely, presentation,
update information held locally data, application, service, and process integration,
• A real-time (and typically sophisticated) as shown in Figure 4.
messaging infrastructure is used to support Each successive level of integration represents
communication between IT systems what might be considered a more advanced form
• Information between IT systems is kept up of integration.
to date
• Presentation integration: The aggregation
Many financial organisations, for example, of data from multiple IT systems within a
deploy event-driven architecture to enable real- single view. A Web portal that aggregates
time trading and transaction processing. For such and displays a customer’s stock portfolio
business applications, real-time processing is a taken from one IT system and bank account
necessity. Asynchronous integration, on the other balance from another IT system can be con-
hand, typically relies on an export-transfer-load sidered integration at the presentation level.
(ETL) architecture. In an ETL architecture: However, there is no direct communication
between the individual IT systems.
• Information from one IT system is exported, • Data integration: The synchronisation of
transferred, and loaded into another IT data held in different databases. For ex-
system ample, if two different databases hold the
• The process is batch based and takes place same customer’s address details, a change
at predetermined intervals of address in one database should also by
• Relatively simply query and file transfer synchronised in the other database. If this
routines are used to implement the ETL synchronisation takes place only after a
process period of time, a certain amount of data
• Data may be inconsistent between IT sys- freshness will be lost.
tems for a period of time until the next ETL • Application integration: Where applica-
process takes place tions make some of the functionality directly
accessible to other applications. Popular
packaged applications, for example, such

Dissolving Organisational and Technological Silos

Figure 4.

Process Integration Process 1 Process 1

Service Integration Service 1 Service 2

Application Integration

Data Integration

Presentation Integration
(Screen Scraping)

as SAP and PeopleSoft, often expose their To date, the integration efforts of most or-
functionality through well-defined applica- ganisations have largely been focused on the
tion programming interfaces (APIs). presentation, data, and application integration
• Service integration: A common set of levels. However, more organisations are now real-
reusable services that are made available to izing the benefits and potential for integration at
other applications. For example, a service to the service and process levels. This is evidenced
obtain a customer’s status may be created by the interest in service-oriented architectures
that can be called by any other application (SOAs), which we will discuss in more detail
within the organisation. Such services are later on.
usually built from a set of specific applica-
tion functions.
• Process integration: The definition of challenges in enterPrise
business-process or workflow models from integration
which reusable services are called. Process
integration is particularly relevant in collab- technical challenges
orative contexts, such as B2B, where there
business processes drive interactions and Enterprise integration cannot be achieved over-
transactions between business partners. night. Rather, it is a journey that may take an
organisation many years to achieve. Some of the

0
Dissolving Organisational and Technological Silos

Box 4.

Technical Challenges

Stand-alone design
• Legacy IT systems that were originally designed to stand alone
• Legacy IT systems that lack a published API or set of external interfaces

Internalised data models

• Packaged applications with internalised data models that are not meant to be shared with other IT systems
• No data access or sharing of data from interfaces

Heterogeneous technologies
• The fact that different IT systems use different platforms, applications, and programming languages
• The presence of multiple distributed computing paradigms, for example, COM, EJB, and CORBA (common
object request broker architecture)

Legacy engineering
• Legacy IT systems that use very old and possibly unsupported technology; original designers are no longer
available and system documentation is sparse
• Compatibility issues between old legacy technologies and modern Web-based technology

Lack of interfaces
• Many IT systems that lack published interfaces or APIs that provide other applications access to functionality
within the system
• Interfaces or APIs that are restricted in functionality, or mandate the use of a particular programming language
such as C++

Semantic mismatch
• Semantic differences in the interpretation of data within individual IT systems that complicate the exchange of
information
• Multiple business partners using proprietary business semantics and terminology

Unclear business processes

• Ill-defined and ad hoc business processes between organisational units

Standards
• Use of proprietary and organisation-specific standards for business data and documents
• Multiple business partners each with their own set of standards
• A lack of universally adopted standards, and new emerging interoperability standards such as XML (extensible
markup language) and Web services that have yet to stabilize

Security
• Providing a consistent level of security across all integrated IT systems
• Providing users with single sign-on (SSO), and integrating authentication and authorization policies used by
individual IT systems

technical challenges that make enterprise integra- management challenges

tion difficult are described in Box 4.
It is because of these barriers that the tech- As well as the technical challenges, there are
nologies employed in enterprise integration are several management challenges. Some of the
themselves both complex and diverse. management challenges associated with enterprise
integration are described in Box 5.

Dissolving Organisational and Technological Silos

Box 5.
Management Challenges

New collaborations
• Working across traditional organisational boundaries and silos
• A more intimate working relationship with external partners
• Overcoming differences in organisational policies, working practices, culture, and internal politics

Project scoping
• Satisfying the enterprise integration needs of multiple stakeholders
• Agreeing on a project scope that can be realistically achieved given limited resources
• Estimating project resources and timelines for a complex project

Continued stakeholder support

• Obtaining support from business stakeholders throughout the entire enterprise integration project life cycle,
including detailed requirements analysis, business-process modeling, and user testing

Data ownership
• Resolving data ownership issues in situations where data are spread across different organisational entities
• Determining the policies regarding who has permission to change what data

Time constraints
• The need to deliver enterprise integration solutions rapidly in order to meet time-sensitive business requirements

Cost constraints
• The need to deliver effective, value-for-money enterprise integration solutions
• Operating within a set budget that offers little, if any, flexibility for cost overruns

Migration
• The need to keep existing business-critical IT applications running while the enterprise integration solution is
being installed
• Executing migration plans that minimize downtime

Expertise
• Sourcing the necessary enterprise integration expertise, whether in house or externally

integration architectures the integration architecture largely depends upon

the business requirements for integration, and
the four integration architectures also on what can be achieved with the available
technology. Each kind of integration architecture
There are four basic kinds of integration archi- has its own capabilities and limitations. With a
tecture: (a) batch integration, (b) point-to-point batch integration architecture, the most simple
integration, (c) broker-based integration, and (d) type of integration architecture:
business-process integration. Each kind of inte-
gration architecture represents differing levels of • IT applications communicate asynchro-
sophistication, as illustrated in Figure 5. nously with each other
It is not always the case that an organisation • ETL is used to transfer data from one IT
should strive to achieve the most sophisticated application to another
integration architecture. The appropriateness of

Dissolving Organisational and Technological Silos

Figure 5.

ERP
Batch Integration

• No middleware or direct communication between

CRM Web IT applications.
• Batch files transferred from one IT to application.
• No real-time processing.
Legacy

Point-to-Point Integration ERP

• Point-to-point communication and interfaces

directly between individual IT applications. CRM Web
• High maintenance overhead if many IT
applications.
•Mix of real and non-real time processing.
Legacy

ERP Broker-based Integration

• Broker acts as an integration hub.

CRM Broker Web • Middleware between IT applications and broker
enables real-time processing.
• Broker houses messaging routing and data
transformation logic.
Legacy

Business Process Integration

ERP Process

• Extends broker-based integration with knowledge

of business process.
• Business process model captures workflow CRM Broker Web
between IT applications and humans, and
information sharing.
• Engine allows business processes to be executed, Legacy
monitored and managed.

• There is no business requirement for real- • Communication supported by these inter-

time processing faces may be real time or asynchronous
• The number of interfaces to be built rapidly
A batch integration architecture is often suit- grows as the number of IT applications
able for organisations that perform high-volume increases
back-end processing that is able to take place
overnight, weekly, or on a scheduled basis. A point-to-point integration architecture is
In a point-to-point integration architecture: most suited when the number of IT applications
to be integrated is small. However, as the number
• IT applications communicate with other IT of IT applications grows, the number of interfaces
applications through interfaces to be maintained becomes problematic, and a
broker-based integration architecture becomes

Dissolving Organisational and Technological Silos

more appropriate. In a broker-based integration background check is positive, and then sending
architecture, an integration broker acts as a hub a notification to the customer. Each step in the
for connecting IT systems. A good analogy is to business process involves communication with
view an integration broker as a major airport that different IT systems.
serves as a hub for connecting flights to smaller
cities. A broker-based integration architecture Why Business-Process modeling?
can only be implemented through tools offered by
companies such as TIBCO and WebMethods. In Once encoded inside IT systems, business rules
such tools, the main functions of the integration often become difficult to change. This prevents
broker are as follows: organisations from rapidly responding to new
business circumstances, what is often considered
• Message routing: Routing data from one a lack of IT agility. Greater business responsive-
IT system to another, for example, routing ness can be achieved through more flexible IT
banking transactions taken from the call architectures that allow business processes and
centre to the legacy banking system business rules to be defined explicitly rather than
• Schema translation: Translating data given hard-coded within the IT systems themselves.
in one format or schema definition into data This has given rise to tools that can capture and
in another schema definition, for example, model business processes, elements essential to
Siebel data fields mapped onto CICS re- the implementation of a business-process integra-
cords tion architecture.
• Business-rules processing: Applying busi-
ness rules based on the content of the data service-oriented architecture
or messages, for example, raising a warn-
ing flag if the account balance is less than A new development in the area of integration
zero architectures is that of SOA. In SOA, IT systems
• Message splitting and combining: Splitting expose business functionality as services that can
or combining messages be accessed by other IT systems, both internal and
• Transaction management: Managing a se- external to the organisation. A set of standards,
quence of messages as a single transaction known collectively as Web services, enables
services to be implemented in a standardized and
A broker-based integration architecture sup- consistent way, which allows them to be accessed
ports real-time integration. Such tools provide via an intranet or the Internet.
the basic integration broker and messaging in- In an SOA, organisations can treat services
frastructure, but adapters must be purchased to (whether provided internally or externally by
interface with the kind of IT systems that reside another organisation) as a kind of building block
within the organisation. from which they can compose new applications.
A business-process integration architec- Creating a service in the first place requires some
ture builds upon the broker-based integration initial development cost, but the cost is amortized
architecture by adding the concept of business when the service gets reused across multiple
processes that trigger the relevant messages to applications. In an SOA, IT systems are loosely
be sent to individual IT systems. For example, coupled and, with Web services, use a common
when a banking customer opens up a new ac- standardized protocol to communicate with each
count, the business process may involve doing other. This makes the job of integration much
a background check, creating an account if the easier and therefore potentially much cheaper as

Dissolving Organisational and Technological Silos

Figure 6.

Amazon.com, best known for its success in selling books online, uses Web Services to make
available certain business functionality to outside organisations. For example, an outside
organisation can, through Web Services, search for books in Amazon’s catalogue and display the
results in its own website.

no special tools or proprietary technologies are services. The need to write new code from
required. The defining characteristics of SOA scratch is kept to a minimum.
and how they are supported by Web services are • Lower development costs: The overall
shown in Table 2. costs of IT are lowered due to the reuse of
existing services.
advantages of soa • Simplified systems integration: IT systems
that expose their functionality as a set of
The potential advantages of SOA are as fol- services are more easily integrated with
lows. other IT systems that are able to tap into
those services.
• Shorter development cycles: An organisa- • Increased business agility: An organisation
tion is able to rapidly create IT applications can respond to changing business require-
from the reuse and composition of existing ments more effectively because it is able

Dissolving Organisational and Technological Silos

Table 2.

SOA Characteristics Web Services Support

IT applications expose services that Web services can act as a wrapper around
can be accessed programmatically by legacy and existing applications, exposing their
Service Exposure
other applications or services. functionality as Web services that can be accessed
by other IT systems.
Services are distributed and may re-
Web services can reside on servers within the
Distributed Services side either within the organisation or
organisation or anywhere on the Internet.
outside the corporate firewall.
A Web service represents a distinct piece of
Services are loosely, rather than
Loose Coupling business functionality that is loosely coupled in
tightly, coupled.
nature.
A set of services may not necessarily A Web service may be owned by the organisation,
Service Ownership belong to a single owner. its business partners, or its customers, or by
external third-party service providers.

Web services are described in WSDL (Web

Services are described and accessed services description language), published via
Open Standards using open, rather than proprietary, UDDI (universal description, discovery, and
standards. integration), and accessed over SOAP (simple
open access protocol).

The services are platform indepen- Web services on a J2EE platform can
Neutrality dent, and vendor and language neu- communicate with Web services on the .NET
tral. platform and most other platforms.

New applications, services, or trans-

actions can be created through the Web services can be called by other Web services,
Service Creation
assembly, composition, and chaining or strung together into a transaction.
of lower level services.

The underlying details of how a

service is implemented (low-level Web services hide back-end implementation and
Transparency transport, communications, platform, platform details from the IT applications that use
language, etc.) are hidden from the IT them.
applications that use the service.

Web services encapsulate business functionality

The reuse of services is encouraged
Reuse into reusable services that can reused by many
when possible.
different IT applications.

to create new services and IT applications Until the advent of Web services, it was dif-
more quickly. ficult to imagine how SOAs could be created and
• Improved quality of service (QoS): supported in a cost-effective manner using exist-
Customers and end users experience an ing technologies. However, the huge support for
improved level in the QoS because SOAs Web services from major technology vendors, in
allow poorly performing services to be easily terms of development tools and server software,
substituted with improved services without provide organisations with the necessary building
affecting other systems. blocks for creating SOAs.

Dissolving Organisational and Technological Silos

managing enterPrise may be developed each with their own associated

integration Projects development, implementation, maintenance, and
infrastructure costs. Instead, adopting a strategic
strategic framework view of enterprise integration can be likened to
managing multiple pieces of a large jigsaw. A
Organisations need to take a strategic view of strategic framework for enterprise integration is
enterprise integration if they are to maximize set out in Figure 7.
their integration efforts and achieve overall Crucially, enterprise integration is a major
success. This means understanding and coordi- program of change that will affect the way the
nating the integration projects within the entire organisation does business. Understandably, there
organisation at a strategic level. If integration are several major elements within the strategic
issues are addressed solely at the tactical level framework to consider:
of individual projects, the effort and cost of in-
tegration will be repeatedly incurred. Without • The organisation’s business strategy, busi-
a strategic view, multiple integration solutions ness directions, and consequently, the overall
business case for enterprise integration

Figure 7.

• Understanding the business

• Re-engineering existing
need.
processes for speed and
• Creating the business case. efficiency.
• Establishing the ROI. • Enabling new processes that
enable new levels of customer
• Exploring new business
• Identifying new ways service and responsiveness.
opportunities
of trading with existing
• Creating collaborative
and new partners. • Understanding customer’s
processes that span across
changing needs.
• Assessing the impact of traditional organizational silos.
new data exchange and • Monitoring industry trends
• Locating points of flexibility
industry standards. and movements.
for business agility.
• Exploring new alliances Strategy • Change management and
and outsourcing
process transition plans.
opportunities.
Business Business
Partners Processes
Enterprise
Integration
• Establishing the
architectural vision.
• Understanding portfolio
• Identifying stakeholders Projects Enterprise of current and future IT
and business objectives the Change Architecture systems and technology.
project serves. Management • Identifying integration
• Defining project scope strategies and
and requirements. technologies.
• Project planning and • Change management &
• Defining architectural
resource mobilization. transition plans.
standards.
• Analysis, design, testing • New organizational roles
• Creating a robust but
and rollout. and responsibilities.
flexible, responsive and
• Project evaluation. • Training and skill trusted technical
development plans. framework.

Dissolving Organisational and Technological Silos

• The way in which the organisation engages that employ a diverse mix of heterogeneous
and interacts with business partners technologies ranging from older mainframe
• Business processes within the organisation environments to modern Web-centric envi-
and how they span across units within the ronments.
enterprise • Legacy engineering: The project involves
• The enterprise IT architecture and portfolio work on or changes to legacy systems when
of existing IT systems those involved in the original design may
• The management of change associated with no longer be available.
the transition from nonintegration to integra- • Novel technologies: The project involves
tion the use of integration technologies, such as
• The integration requirements for individual messaging and integration brokers, that are
projects novel to the organisation and IT professionals
working within the organisation.
An enterprise integration initiative therefore • Lack of experience: The organisation lacks
needs to be seen as a program that provides a experience in implementing enterprise inte-
coordinated and controlled platform for integra- gration solutions and therefore approaches
tion that is capable of sufficing the integration the project without the benefit of lessons
requirements of specific projects within the learned or previous working practice.
organisation. • Shortfalls in specialist skills: Individuals
with the required skills set and expertise
Project risk required to complete large enterprise in-
tegration projects are not readily available
Estimates put forward by the Standish Group within the organisation or the market in
have suggested that 88% of enterprise integration general.
projects fail (either failing to deliver within a time • Lack of documented methodology and
frame or within budget). This is an alarming sta- best practice: Unlike for regular software
tistic, even against the background of high project development projects, there are few well-
failure rates within the IT industry in general. documented, tried, and tested methodologies
Enterprise integration projects tend to be high risk for enterprise integration projects within the
for one or more of the following reasons: literature.

• Complex, cross-unit business processes: coordinating multiple Projects

The project involves the comprehension of
complex business processes and business As argued, enterprise integration initiatives re-
requirements that span across multiple quire the coordination of multiple projects. A layer
organisations or organisational units. of program management that coordinates these
• Multiple stakeholder silos: The project individual projects so that they address specific
involves collaboration between multiple integration needs while avoiding duplicate work
stakeholders who each represent an organisa- effort is essential. One model for program man-
tion or organisational unit that owns parts agement is presented in Figure 8.
of the business process or IT systems that The program management model consists of
are pertinent to the business process. four main phases:
• Heterogeneous technologies: The project
involves the study of multiple IT systems

Dissolving Organisational and Technological Silos

Figure 8.

Establish the
Build the Business Vision
Business Case Monitor and Evaluate
1
Value Creation
Strategy
Establish Programme 4 Implement
and Project Framework Rollout Transition Plan
2
Planning
Manage Solution
Define Scope of Work 3 Release

Implementation
Define Organizational Test the
Structure and Mobilize Solution
Teams Model Business
Scenarios Design and Develop the
Integration Architecture
Gather Integration
Requirements from
Stakeholders

• Strategy: In this phase, the CIO, with added, or not, from previous enterprise integration
support from senior business stakeholders, rollouts tend to influence the strategic directions
formulates the strategic need for enterprise of upcoming enterprise integration projects. The
integration though the creation of a business cycle of strategy, planning, implementation, and
vision and business case. rollout is a pattern that applies to all enterprise
• Planning: The enterprise integration busi- integration projects, though the success of a
ness strategy is translated into a program project comes down to how well risks, both of
of work. Individual enterprise integration a managerial and technical nature, are managed
projects are identified, prioritised, and within each phase.
planned.
• Implementation: The project manager,
architects, and developers execute the en- unDerstanDing enterPrise
terprise integration project, working with integration requirements
stakeholders to gather requirements and
implement the enterprise integration solu- enterprise integration requirements
tion.
• Rollout: The enterprise integration solution Enterprise integration solutions can be large,
is rolled out into the live environment. complex, and costly. It is therefore important that
enterprise integration requirements are under-
The phases in an enterprise integration project stood before the organisation proceeds to design,
are generally cyclic in nature because the value develop, or procure an integration solution. A

Dissolving Organisational and Technological Silos

Figure 9.

Enterprise Integration Requirements

Connectivity Process Support Connectivity Security QoS

Business Process Data Systems
Access Control
Partners Modeling Tools Transformation Management
Messaging Process
Data Formats Encryption Service Levels
Infrastructure Standards
Application Execution and Document
Authentication Performance
Connectivity Management Formats
Message
Adapters Routing Auditing Reliability
Formats

SDKs Notification Scalability

Transaction
Interfaces
Management
Exception
Handling

framework for gathering enterprise integration to the project as a whole. Each major category of
requirements is shown in Figure 9. integration requirements is described in greater
The framework identifies five major categories detail next.
of integration requirements, key areas of require-
ments focus (the shaded boxes), and secondary connectivity requirements
areas of requirements focus that should follow on
from discussions on the key areas. The five major An enterprise integration solution may have the
categories of integration requirements are: following connectivity requirements:

• Connectivity • Connectivity to business partners who are

• Process support geographically dispersed and separated
• Data exchange through several layers of corporate fire-
• Security wall
• Quality of service • Ability to add new business partners, such as
new suppliers, and information about their
Most likely, an organisation will consider connectivity profile (e.g., types of business
procuring an enterprise integration tool from a interaction, data standards supported)
vendor such as TIBCO or WebMethods and look • Compatibility with the IT and communica-
to tailor that tool to their specific requirements. tions infrastructure of business partners
In addition, cost and time-to-deliver constraints • Minimal introduction of new IT and com-
must also be considered as requirements that relate munications infrastructure, for example,
dedicated lines such as with EDI

0
Dissolving Organisational and Technological Silos

• Reliable messaging infrastructure for the • Ability to change process models at a later
exchange of messages between partners time and link new actors and applications
that works across and supports a variety of • Environment for executing processes and
protocols, for example, HTTP (hypertext for maintaining the state of a process
transfer protocol), HTTPS, FTP (file transfer • Administration console that enables pro-
protocol), and MIME (multipurpose Internet cesses, and individual parts of each process,
mail extensions) to be controlled (stopped and started)
• Support for, and connectivity across, mul- • Monitoring tools that allow one to view the
tiple computing platforms including W2K, state of a process and collate statistics on
Windows XP, Unix, and Linux process performance
• Off-the-shelf adapters that enable immediate • Transaction support and management, in-
connectivity to a wide range of packaged cluding transaction recovery and rollback
applications (e.g., SAP, Siebel) without any • Support for predefined or industry-standard-
coding effort ized business processes, such as Rossetta-
• Adapters for legacy system connectivity Net
• Adapters for connectivity with database • Alerts when process exceptions or time-outs
management systems such as Oracle and occur
Informix
• Availability of software development kits Data exchange requirements
(SDKs) or adapter development kits (ADKs)
that allow adapters to be written in a widely An enterprise integration solution may have the
supported language such as Java or C++ if following data exchange requirements:
they are not available off the shelf (as in the
case of the bespoke applications) • Ability to handle files encoded in differ-
ent formats, which may be proprietary, for
Process support requirements example, iDOC (SAP format), .doc, or .rtf,
or open, for example, XML
An enterprise integration solution may have • Ability to transform files from one encoding
the following process support requirements: to another for consumption by another ap-
plication, for example, from XML to .doc
• Graphical modeling tool that enables busi- • Semantic mapping tools that enable data
ness processes to be defined diagrammati- fields defined in one schema to be mapped
cally, including the inputs and outputs of onto data fields defined in another scheme
individual processes • Validation of data inputs and outputs, for
• Scripting language that allows both simple example, to determine conformance to
and complex business rules to be defined, standards
for example, “IF stock_level < stock_reor-
der_level THEN SEND reorder_message” security requirements
• Ability to link portions of the business-pro-
cess model to either human actors or appli- An enterprise integration solution may have the
cations that are responsible for processing following security requirements:
in that part of the model
• Repository for storing process models
and different versions of the same process
model

Dissolving Organisational and Technological Silos

• Minimal violations or changes to existing conclusion

corporate security setups, for example,
firewalls Enterprise integration takes a strategic and coordi-
• Security administration console for defining nated view of an organisation’s integration needs.
users, roles, and access control properties In the past, these needs have been addressed on an
• Support for multiple authentication schemes, ad hoc and piecemeal basis, resulting in a prolif-
such as user names and passwords eration of interfaces and the high costs associated
• Support for digital certificates and pubic with their management and maintenance. This
key infrastructure (PKI) standards approach, however, has become unsustainable and
• Encryption of messages exchanged between a drain on IT resources. Enterprise integration is
business partners and applications suited where an organisation’s business require-
• Auditing, at multiple levels, from transaction ments dictate the need for the real-time processing
to database operations of complex business processes across different IT
• Single sign-on applications and parts of the enterprise. Enterprise
integration solutions typically involve some form
quality of service requirements of integration broker that coordinates the flow of
information from one IT application to another.
An enterprise integration solution may have Importantly, however, organisations should not
the following security requirements: underestimate the many technical and manage-
ment challenges that need to be overcome in order
• High performance and throughput to achieve enterprise integration success.
• Guaranteed delivery of messages between
applications through the use of appropriate
message storage and delivery architec-
tures
• Overall high reliability, achievable through
infrastructure redundancy and automated
fail-over
• Administration console for the ease of
systems management, for example, server
start and closedown, memory thresholds,
and database sizing
• Comprehensive suite of monitoring and
performance tools

Chapter II
Success Factors and
Performance Indicators for
Enterprise Application
Integration
Alexander Schwinn
University of St. Gallen, Switzerland

Robert Winter
University of St. Gallen, Switzerland

aBstract

The effectiveness and efficiency of information systems are closely related to the degree of integration
between applications. In order to support the management of application integration, five success fac-
tors are analyzed. For each success factor, appropriate performance indicators are proposed. Since the
analysis indicates that the success factors are closely interrelated, these dependencies are discussed
and hypotheses are derived.

introDuction Recently, some approaches have integrated the

design and management of IS architecture with
Design and management issues of information other architectures in an enterprise (e.g., Malhotra,
systems architecture are discussed from a prac- 1996; Martin & Robertson, 2000; McDavid, 1999;
titioner’s perspective (e.g., by Zachman, 1987) Youngs, Redmond-Pyle, Spass, & Kahan, 1999).
as well as from a scientific perspective (e.g., by Some of these approaches focus on technologies,
Krcmar, 1990; Österle, Brenner, & Hilbers, 1992). while others connect IS architecture to business
Architecture models help us to understand and requirements. This chapter addresses applica-
communicate enterprise architecture. They also tion architecture, one specific component of IS
support architecture design decisions. architecture. A company’s application architecture
describes applications (or application domains)

Copyright © 2007, IGI Global, distributing in print or electronic forms without written permission of IGI Global is prohibited.
Success Factors and Performance Indicators for Enterprise Application Integration

and their relations (or interfaces) on a conceptual other hand, the total application development and
level (Winter, 2003b). Application architecture is maintenance costs are significantly lower due to
designed and managed from a business rather than less application complexity. The question is how
technical point of view. The design and manage- to find an optimal balance between the number
ment of application architecture aim at minimizing of interfaces and the number of applications
integration costs. For achieving this goal, develop- in order to reduce the total costs of operations
ment-time integration costs as well as run-time and maintenance. These comprise (a) costs for
integration costs have to be considered. developing, maintaining, and running applica-
After this introduction, conceptual consider- tions, and (b) costs for developing, maintaining,
ations on the optimal level of application integra- and running interfaces. Figure 1 (Winter, 2006)
tion are used to identify general success factors. A illustrates this trade-off. Due to network effects,
broad literature review helps to identify specific we expect a nonlinear growth of the costs for
success factors for application integration. Then, applications and interfaces.
for every success factor, respective performance In real-life situations, the optimal degree of
indicators are proposed. As some of the success integration cannot be determined analytically
factors seem to be closely interrelated, their in- because the costs are not constant and often can-
terdependencies are examined qualitatively next. not be assigned directly to certain applications or
Finally, this analysis results in a set of hypotheses interfaces. Therefore, instruments are needed that
for successful application integration that have to control and manage the evolution of an applica-
be validated quantitatively in further research. tion architecture toward an approximated optimal
degree of integration. An evolutionary approach
(i.e., a bundle of IS projects that improve the degree
aPPlication integration of integration successively) is needed because
normally a revolutionary redesign of application
In contrast to their technical interpretation as architecture is not feasible due to immense costs.
containers of software artifacts (e.g., modules In order to measure the contribution of proposed
and/or data structures), applications represent projects toward the degree of integration, it is nec-
tightly interrelated aggregates of functionalities essary to define objectives and derive performance
from a business perspective. While tight couplings indicators. In the next section, success factors for
between certain functionalities lead to their aggre- application integration are analyzed.
gation into the same application construct, loose
couplings are represented by interfaces between
applications. The number of application constructs success factors for
depends on the definition of tight coupling. If a aPPlication integration
small number of (monolithic) applications are cre-
ated in application design, only a few interfaces Numerous approaches to application integration
have to be implemented. As a consequence, costs can be found in the literature, many of them in
for running and maintaining interfaces are low, the field of enterprise application integration
while the total costs for running and maintaining (EAI). We analyzed not only scientific contribu-
applications are high due to more difficult change tions, but also practitioner papers regarding the
management and higher complexity. If many small success factors mentioned. Table 1 summarizes
applications are created in application design, the results. The following success factors were
much more interfaces are needed, which implies mentioned most often:
higher operations and maintenance costs. On the

Success Factors and Performance Indicators for Enterprise Application Integration

Figure 1. Application vs. interface costs tradeoff (Winter, 2006)

• Minimal project expenses (time and costs) & Morello, 2004). The main goal of application
for integrating applications into the present architecture (re)design is to increase information
application architecture systems’ agility. The following sections intend
• Optimal reuse of software components and to identify indicators that influence this agility.
minimal functional redundancy Besides this proposed central success factor, many
• Reduction of complexity within the present other criteria are conceivable, for example, higher
application architecture customer satisfaction by application integration.
• Optimal coupling of applications (not tighter In the following we concentrate on the agility of
than needed, not looser than necessary) an information system, only.
• Minimal costs for and number of infra- Related work mostly proposes general rules
structure components (e.g., middleware for application integration, for example, achieving
components like message broker or object cost savings by reducing the number of interfaces
request broker, ORB) when using a bus architecture. Quantitative mea-
surements and the derivation of specific perfor-
Assuming that all these factors affect infor- mance indicators are usually not considered.
mation systems performance, we propose one Figure 2 illustrates the identified success
central figure that is analyzed in the upcoming factors, the focus success factor—agility of the
sections: the agility of an information system. information system—and the assumed interde-
Agility is defined as the ability to react to upcom- pendencies between these success factors. In the
ing changes effectively and efficiently (Ambrose following subsections, we describe and discuss

Success Factors and Performance Indicators for Enterprise Application Integration

Table 1. Success factors for application integration in related work

Minimal expenses

Minimal costs for

Optimal level of
Optimal reuse
of integration

Reduction of

infrastructure
complexity

coupling
projects
Approach (vertical) /
Success factor (horizontal)

Scientific Contributions
(Linthicum, 2000) X X X
(Zahavi, 2000) X X X X
(Kaib, 2002) X X X X X
(Ruh, Maginnis and Brown, 2001) X X X X X
(Cummins, 2002) X X X X X
(Fridgen and Heinrich, 2004) X X
(Themistocleous and Irani, 2001) X X X X
Practitioner Approaches
(Liske, 2003) X X
(Moll, 2003) X X X
(Kuster and Schneider, 2003) X X X X
(Bath, 2003) X X X X
(Endries, 2003) X X
(Gröger, 2003) X X X X
(Knecht, 2003) X X X
(Hofer, 2003) X X X
(Friederich, 2003) X X X
(Aust, 2003) X X X X

the identified success factors in more detail and to be supported). These requirements can be of
propose appropriate performance indicators. Later technical nature (e.g., exchanging an application
in the chapter, positive and negative interdepen- due to expired maintenance contracts), or they are
dencies are analyzed in detail. triggered by business decisions (e.g., outsourcing
decisions for certain business processes). Among
information systems’ agility the many factors that influence the agility of an
information system, application architecture is
The agility of an information system expresses of outstanding importance (Winter, 2003a). Until
the ability to react to upcoming new or changed the end of the 1980s, software development was
requirements (e.g., a new business function has dominated by creating monolithic applications in

Success Factors and Performance Indicators for Enterprise Application Integration

nearly all business areas—independent from the and reduce operations costs, most companies run
core competences of the company. A wide “infor- evolutionary application redesign programs.
mation systemization” of all business processes In addition, new business requirements trigger
was the main intention. After this first phase, the new applications that lead to even more integra-
trend of implementing standard software packages tion efforts. A survey by the Gartner Group
(COTS [commercial off the shelf], e.g., SAP R/3) shows that about 40% of IT budgets are spent
came up. These packages provide a broad range on implementing and maintaining interfaces
of functionalities. The rapid growth and business (Krallmann, 2003).
importance of the Internet triggered the addition The direct influence of the application architec-
of many more applications. In this phase, time to ture on the agility of the information system can-
market was much more important than a sustain- not be specified easily. A measurable coherence
able and cost-efficient application architecture. between the complexity of the interapplication
This led to redundancy as many functionalities relations and agility would be a precondition.
were reimplemented, not integrated. In general, however, agility is measurable. The
As a consequence of different application idea is to measure all extensions and changes to
development phases with changing design goals, the information systems in a certain period (C)
companies now struggle with an application ar- and compare this to the total expenses needed for
chitecture where functional silos, standardized the extensions and changes (E). If two periods
packages, and nonintegrated Internet applica- are compared, it can be checked whether exten-
tions coexist. In order to increase consistency sions and changes have been implemented more

Figure 2. Application integration success factors and their interdependencies

Minimum
expenses
for integration
within projects

Optimal reuse, Minimum cos ts

Minimum of Agility of the and complexity
functional information of infras tructure
redundancy s ys tem

R educing
complexity in the Optimal degree
application of coupling
lands cape

Success Factors and Performance Indicators for Enterprise Application Integration

efficiently. The comparison, however, cannot be of loosely coupled controlled links (i.e., links that
carried out on a project-by-project basis because are directly controlled by architecture manage-
architecture management is a long-term effort ment) between application domains is counted.
on an aggregate scale: “You can’t ‘cost-justify’ This figure has to be put in relation to the uncon-
architecture” (Zachman, 2001). trolled links between the domains. The quotient
As the figures C and E cannot usually be pro- represents the level of disintegration.
vided directly from IT controlling, we propose To measure these figures, existing tools like
figures for each success factor in the following. source-code analyzers or application repository
managers can be used.
application architecture complexity
Degree of coupling
Historically grown application architectures
comprising hundreds of applications (Linthicum, General rules for the degree of coupling are not
2000) cannot be managed as a whole. The com- useful because each application relation is dif-
plexity is too high and the dependencies are too ferent. Intuitively, tight coupling is appropriate
multifaceted. Therefore, it is necessary to control if two applications implement functionalities
the complexity by knowingly disintegrating the that belong to the same business process. If two
application architecture. In our context, complex applications implement functionalities of differ-
means that it is difficult to describe the behavior ent business processes, loose coupling would be
of the whole application architecture in any lan- appropriate. The degree of coupling has direct
guage even if we have detailed knowledge about influence on the agility of the information system:
each single application. To reduce the complexity, Tighter coupling necessarily will result in excess
the application architecture can be spilt up into expenses for implementing new requirements or
smaller defined components (building blocks). changing existing ones. If applications are coupled
Among these components we propose loose cou- too loosely, run-time overhead may arise and ad-
pling, and within the components tight coupling. ditional middleware components for integration
Loose coupling reduces dependencies among might be needed.
the components. This means that changes in one For each application relation, an appropriate
component will not affect the other component level of coupling has to be chosen. Since a com-
(Linthicum). mon methodology with objective criteria does not
One way to disintegrate the application ar- exist, it is difficult to derive measurable figures.
chitecture is to define application domains that A potential indicator could be the expenses for
comprise a defined set of applications (e.g., the implementing changes in dependent applications
applications of one business unit; Hagen & Sch- due to modifications of an independent applica-
winn, 2006). The number of application domains tion. High expenses indicate too-tight coupling.
should be small to keep the advantage of lower On the other hand, the run-time overhead has to
complexity. In a concrete case in the financial- be measured. A high run-time overhead would
service sector, the number of domains is about indicate too-loose coupling. However, it is diffi-
20 (Hagen & Schwinn, 2006). It is important that cult to exactly determine the run-time overhead.
applications within a domain can be modified It usually cannot be measured directly because it
without direct effects to other domains. is hidden in other maintenance or infrastructure
The most important figure is the degree of costs. Even if the run-time overhead could be
disintegration. To measure this figure, the number measured, the interpretation of measured values
is difficult as no benchmarks exist.

Success Factors and Performance Indicators for Enterprise Application Integration

As a consequence, a random sampling of appli- ance of a customer of a bank. One function or

cations and the measurement of modification costs service could be GetBalanceCustomerX(), which
induced by context changes seem to be the only is designated to one special customer X and
way to approximate the degree of coupling. therefore is very special. A very general service
would be QueryDatabase(DatabaseName, Query).
reuse and functional redundancy The potential for reuse of this service would be
very high as many applications have to access
The success factor of optimal reuse claims that databases. Considering our example, the benefit
every function is only implemented once by an of this service is pretty low as we still have to
application. If a function only has to be developed adapt the service so that it returns the account
and maintained once, lower development and balance of customer X. Obviously, a service like
maintenance costs should be achievable. Further- GetBalance(Customer) would satisfy most needs.
more, reuse supports the consistency, quality, and This example illustrates that it is very important to
flexibility of applications (Cummins, 2002). To consider the level of specialization when designing
achieve maximum reuse, powerful middleware new reusable functions or services.
is needed to deliver the centrally implemented For measuring reuse, one important figure
functionality to as many other applications as pos- is the average reuse per function, which means
sible that are running on different platforms. In the how many applications actually use a certain
design process, a framework is needed to ensure function. To measure this figure, repositories are
the future reusability of a component (design for necessary that document the utilization of func-
reuse). One important aspect is the granularity tions by applications. If there is a central server
of the function. If only large monolithic software (e.g., a CORBA [Common Object Request Broker
components are developed, the potential for reuse Architecture] server), it could be analyzed which
is high because broad functionality or parts of it applications are using which service.
can be reused. On the other hand, dependencies Another important indicator for the quality
are created as the frequency of changes is higher of the application architecture is the number
and release cycles are shorter. If the components and growth of public interfaces. A high amount
are too modular, the benefit of reuse is lower, and and quick growth could indicate redundancy as
run-time and maintenance overhead increases we believe all functionality should be covered
because many small functions have to be reused, by reusable functions at a time. However, fast
not just one. growth could also be the result of introducing new
Another aspect that should be considered technologies (e.g., service-oriented architecture).
when designing reusable software components is If so, the figure indicates the user acceptance of
the level of specialization. If only very special- the new technology.
ized components are developed, the potential
for reuse is low because only few applications or integration Project expenses
users need this very specialized function. If the
components too general, the potential for reuse It is problematic to determine integration costs
should generally be higher, but the benefit for the on a general level because integration effort is
next user is low as only a very general service not only dependent on business requirements
can be utilized. Furthermore, additional business (e.g., timeliness) and technology support, but
logic has to be implemented by the next user, also on time. For example, the first project that
which leads to redundancy again. An example uses a CORBA infrastructure has to pay for the
could be a service that checks the account bal- infrastructure while the following projects can

Success Factors and Performance Indicators for Enterprise Application Integration

reuse it, thereby receiving indirect sponsorship for specific requirements. On the other hand, a
by the initial project. Furthermore, an isolated basic set of technologies is necessary to imple-
application that only has some relations to other ment the requirements efficiently and to avoid
applications usually has lower integration costs work-arounds by simulating one technology by
than an application that needs information and means of another (e.g., using a message broker to
functions of many other applications (e.g., a implement a service-oriented architecture).
portal application). As a consequence of these Possible figures for measuring this factor are
problems, we do not consider single projects, but infrastructure costs, the number of deployed
entire project portfolios over a certain period to technologies and tools, standardization, or the
measure integration expenses. degree of fulfillment of project requirements by
Implications of the quality of integration standard technologies and tools.
aspects within the application architecture can
only be drawn if the integration problem and the
expenses are normalized. The integration costs success factor
depend on many factors (e.g., number of inter- interDePenDencies
faces, number of business units involved, quality
of existing documentation, etc.) that are hard It seems likely that the identified success factors
to determine. As it is very hard to measure the affect each other. Some of the success factors
integration complexity, we propose an indicator are complementary to each other, while others
that compares the entirety of integration efforts: are competing. In the following, all possible
We sum up all integration costs and divide them relations between success factors are analyzed.
by the overall integration complexity within a The derived hypotheses form a basis for further
certain period (e.g., 1 year). If we compare two quantitative research.
periods by dividing the quotient from the first
year by the quotient of the second year, the result Interdependencies Between Project Expenses
should be smaller than 1. That means that we have and Reuse (Figure 3)
implemented more integration complexity with Project expenses can be kept to a minimum if a
lower expenses. large number of components are reusable. On the
The only thing we can derive from this figure is other hand, project expenses are usually higher if
the cost efficiency. However, without benchmarks, there are no reusable components and the project
we cannot determine useful target values. has to implement new components. Implement-
ing a reusable component is expensive because
costs and complexity of the efforts are needed that would not be needed if a
integration infrastructure single-use component is implemented (Boehm et
al., 2000; Ruh et al., 2001), mainly due to qual-
The number of deployed integration technologies ity-assurance reasons.
or tools within a company has direct influence As we do not want to minimize short-term
on the IT expenditures. As a consequence, the single-project expenses, but instead want to
number of utilized tools has an (indirect) influ- minimize the total expenditures for the entire
ence on IT project costs. If only a few tools are project portfolio over a long period, the influence
used, they can be supported professionally. Higher of maximizing reusability should be positive.
numbers of tools lead to uncertainties as develop- The savings should be higher than the additional
ers have to decide which tool is most appropriate expenses for developing reusable components.

0
Success Factors and Performance Indicators for Enterprise Application Integration

Figure 3.

Project expenses

0% Optimal Reuse 100%

Figure 4.
Number of application domains
within a project

Costs for communication and application domain alignment

The earnings only can be realized when reusable Interdependencies Between Project Expenses
components are actually reused. The more often and Complexity (Figure 4)
a component is reused, the higher the savings are To minimize complexity, disintegration of
expected to be. However, the project costs will the application architecture (e.g., by separating
always have an initial effort to handle reusable manageable application domains) has been pro-
components. posed above. If development projects affect one
application domain only, no specific complexity

Success Factors and Performance Indicators for Enterprise Application Integration

Figure 5.

100%

Runtime-Overhead (too loosely coupled)

Optimal degree of coupling

Expenses for changes (too tighly coupled)

Project costs

Figure 6.

100%
Requirement fulfillment
Requirement fulfillment

Complexity

Optimal
Variety of technologies
Portfolio of technologies

influence is present. If a development project af- Interdependencies Between Project Expenses

fects more than one application domain, expenses and Degree of Coupling (Figure 5)
are expected to increase. The more application Optimal coupling claims to minimize de-
domains are involved in a development project, pendencies among applications and to avoid the
the higher the communication costs are expected run-time overhead. The more appropriate the
to be. Due to network effects, we expect nonlinear degree of coupling between applications, the
growth. less development and run-time overhead may be
expected (Linthicum, 2000). Both success factors
are complementary to each other.

Success Factors and Performance Indicators for Enterprise Application Integration

Figure 7.

100%

Complexity reduction

Optimal reuse 100%

Interdependencies Between Project Expenses and generality of reusable components is essential.

and Complexity of Infrastructure (Figure 6) In general, implementing reusable components
To reduce the costs and complexity of infra- has a positive influence on the complexity (Ruh
structure, the number of deployed infrastructure et al., 2001). However, an optimal reuse does not
components has to be restricted. This leads to a imply a minimized complexity.
limitation of applicable technologies within a
project (e.g., only CORBA services are supported, Interdependencies Between Reuse and Cou-
and Web service technology is not used). The pling (Figure 8)
limitation of technologies incurs lower expenses To realize a high potential of reuse, applica-
for infrastructure, but they might not be able to tions should be loosely coupled. A high potential
meet project requirements perfectly. Therefore, of reuse means that one component may be used
additional project costs might be incurred to meet by many applications. If all applications are
these requirements. Due to network effects, we coupled tightly, the expenses for changing one
expect nonlinear growth of the complexity as component would be excessive. Tightly coupled
more and more technologies have to be compared components should therefore not be designed for
against each other regarding whether they are reuse. The coupling of applications is necessary
appropriate within a project. to reuse components (Kaib, 2002).

Interdependencies Between Reuse and Interdependencies Between Reuse Costs and

Complexity (Figure 7) Complexity of Infrastructure (Figure 9)
Like for development projects, communica- If reusable components are developed inde-
tion and alignment problems between applica- pendently from any technologies, these success
tion domains occur when implementing reus- factors do not influence each other. If, however,
able components (used by different application reusable components are developed using a certain
domains). Choosing an appropriate granularity technology, the number of technologies within a

Success Factors and Performance Indicators for Enterprise Application Integration

Figure 8.

loosely
degree of coupling
Tightly

low Potential for reuse high

Figure 9.
many
Number of technologies used
some

low Potential for reuse high

Success Factors and Performance Indicators for Enterprise Application Integration

Figure 10.

100%
Reducing complexity

Optimal degree of coupling 100%

Figure 11.
Number of domains with

Infrastructure for inter-

domain communication
own infrastructure

low Complexity of infrastructure high

Success Factors and Performance Indicators for Enterprise Application Integration

Figure 12.

Basic technologies
enabling loose
coupling
hoch
Complexity of infrastructure
niedrig

tight Degree of coupling loose

company obviously affects the reusability: For Interdependencies Between Complexity Costs
each reusable component, it has to be decided and Complexity of Infrastructure (Figure 11)
which technologies should be used to develop the If the infrastructure is managed centrally (i.e.,
component (e.g., developing a CORBA service independently from application domains), both
and/or a Web service). The larger the number of success factors do not influence each other. If the
technologies, the more difficult these decisions infrastructure is managed for every application
are. Hence, a positive influence among reusability domain separately, the expenses and the complex-
and costs of infrastructure can be stated: The less ity grow nonlinearly with every managed appli-
technologies deployed, the higher the potential cation domain. Moreover, a centrally managed
for reuse (Kaib, 2002). Due to network effects, infrastructure is needed anyway for supporting
we expect nonlinear growth as it gets harder and interdomain communication.
harder to make a decision (about which technology
to use to develop a component). Interdependencies Between Coupling Costs and
Complexity of Infrastructure (Figure 12)
Interdependencies Between Complexity and If all applications are coupled tightly, infra-
Coupling (Figure 10) structure costs tend to be low as the applications
Forming many application domains leads to do not have to communicate via middleware.
many loosely coupled applications: Within appli- If, in contrast, applications are coupled loosely,
cation domains, a tight coupling dominates, but the distance between two applications has to be
multidomain applications are loosely coupled. If bridged. As a consequence, middleware is needed,
complexity is reduced, the influence on the degree for example, for transport, transformation, rout-
of coupling is positive. ing, and so forth. Since usually some loosely
coupled applications exist in every application
architecture, a standard set of middleware is

Success Factors and Performance Indicators for Enterprise Application Integration

needed anyway. If a set of middleware components Aust, H. (2003). Einführung von EAI bei der
is already available, the infrastructure costs and PostFinance. Proceedings of the St. Galler An-
complexity do not grow further. wenderforum, St. Gallen, Switzerland.
Bath, U. (2003). Web Services als Teil einer ser-
viceorientierten Architektur. Proceedings of the
conclusion
EAI Forum Schweiz, Regensdorf, Switzerland.
Based on a literature review and an analysis Boehm, B., Abts, C., Brown, A. W., Chulani, S.,
of current practices in companies, five success Clark, B. K., Horowitz, E., et al. (2000). Software
factors for application integration have been ana- cost estimation with Cocomo II. NJ: Prentice
lyzed: application architecture complexity, degree Hall.
of coupling, reuse and functional redundancy,
Cummins, F. A. (2002). Enterprise integration.
integration project expenses and costs, and the
New York: John Wiley & Sons.
complexity of the integration infrastructure. For
each success factor, performance indicators have Endries, T. (2003). Schenker AG: EAI. Proceed-
been proposed that allow such success factors to be ings of Integration Management Day, St. Gallen,
measured and ultimately managed. Furthermore, Switzerland.
the interdependencies among the success factors
Fridgen, M., & Heinrich, B. (2004). Investitionen
have been analyzed qualitatively.
in die unternehmensweite Anwendungssystemin-
The significance of the proposed success
tegration: Der Einfluss der Kundenzentrierung
factors and their influence on the agility of an
auf die Gestaltung der Anwendungslandschaft
information system have been thoroughly dis-
(Working paper). Augsburg, Germany.
cussed. However, neither the completeness of
the proposed system of success factors nor the Friederich, M. (2003). Zusammenspiel verschiede-
hypotheses for their interdependencies have been ner Integrationstechnologien und Werkzeuge bei
validated quantitatively. Developing hypotheses in der Züricher Kantonalbank. Proceedings of the
a top-down manner, but based on a similar system EAI Forum Schweiz, Regensdorf, Switzerland.
of success factors for application integration, two
Gröger, S. (2003). Enterprise application integra-
recent studies by Klesse, Wortmann, and Schelp
tion in the financial services industry. Proceed-
(2005) and Klesse, Wortmann, and Winter (2005)
ings of Integration Management Day, St. Gallen,
analyze dependencies quantitatively. Future work
Switzerland.
will therefore focus on integrating the bottom-up,
literature-based application integration manage- Hagen, C., & Schwinn, A. (2006). Measured Inte-
ment approach presented in this chapter with these gration: Metriken für die Integrationsarchitektur.
quantitative studies. In J. Schelp & R. Winter (Eds.), Integrations-
management (pp. 268-292). Berlin, Germany:
Springer.
references
Hofer, A. (2003). Projekt SBB CUS: EAI ermög-
licht eine Erhöhung der Kundeninformations-
Ambrose, C., & Morello, D. (2004). Designing
qualität im öffentlichen Verkehr. Proceedings
the agile organization: Design principles and
of the St. Galler Anwenderforum, St. Gallen,
practices. Gartner Group.
Switzerland.

Success Factors and Performance Indicators for Enterprise Application Integration

Kaib, M. (2002). Enterprise Application Integra- multi-model analysis. Proceedings of the Fifth
tion: Grundlagen, Integrationsprodukte, Anwen- CAiSE/IFIP8.1 International Workshop on Evalu-
dungsbeispiele. Wiesbaden, Germany: DUV. ation of Modeling Methods in Systems Analysis
and Design, Stockholm, Sweden.
Klesse, M., Wortmann, F., & Schelp, J. (2005).
Erfolgsfaktoren der Applikationsintegration. McDavid, D. W. (1999). A standard for business
Wirtschaftsinformatik, 47(4), 259-267. architecture description. IBM Systems Journal,
38(1), 12-31.
Klesse, M., Wortmann, F., & Winter, R. (2005).
Success factors of application integration: An Moll, T. (2003). Firmenübergreifendes EAI-Netz-
exploratory analysis (Working paper). St. Gallen, werk: Integrierte Umsetzung von Geschäftspro-
Switzerland: University of St. Gallen. zessen über einen Marktplatz als EAI-Hub.
Proceedings of Integration Management Day, St.
Knecht, R. (2003). Application architecture
Gallen, Switzerland.
framework UBS-WMBB. Proceedings of Integra-
tion Management Day, St. Gallen, Switzerland. Österle, H., Brenner, W., & Hilbers, K. (1992).
Unternehmensführung und Informationssystem:
Krallmann, H. (2003). Transformation einer
Der Ansatz des St. Galler Informationssystem-
industriell geprägten Unternehmensstruktur
managements. Stuttgart, Germany: Teubner.
zur einer service-orientierten Organisation.
Proceedings des Symposiums des Instituts für Ruh, W. A., Maginnis, F. X., & Brown, W. J.
Wirtschaftsinformatik “Herausforderungen der (2001). Enterprise application integration. New
Wirtschaftsinformatik in der Informationsgesell- York: John Wiley & Sons Inc.
schaft” (pp. 1-12).
Themistocleous, M., & Irani, Z. (2001). Bench-
Krcmar, H. (1990). Bedeutung und Ziele von marking the benefits and barriers of application
Informationssystemarchitekturen. Wirtschafts- integration. Journal of Benchmarking, 8(4),
informatik, 32(5), 395-402. 317-331.
Kuster, S., & Schneider, M. (2003). Banking Bus Winter, R. (2003a). An architecture model for
EAI-plattform der Raiffeisengruppe Schweiz. supporting application integration decisions.
Proceedings of Integration Management Day, St. Proceedings of 11th European Conference on
Gallen, Switzerland. Information Systems (ECIS), Naples, Italy.
Linthicum, D. S. (2000). Enterprise application Winter, R. (2003b). Modelle, Techniken und Werk-
integration. Reading, MA: Addison-Wesley. zeuge im Business Engineering. In H. Österle &
R. Winter (Eds.), Business Engineering: Auf dem
Liske, C. (2003). Advanced supply chain col-
Weg zum Unternehmen des Informationszeitalters
laboration enabled bei EAI. Proceedings of the
(pp. 87-118). Berlin, Germany: Springer.
St. Galler Anwenderforum, St. Gallen, Switzer-
land. Winter, R. (2006). Ein Modell zur Visualisierung
der Anwendungslandschaft als Grundlage der
Malhotra, Y. (1996). Enterprise architecture: An
Informationssystem-Architekturplanung. In J.
overview. @BRINT Research Institute. Retrieved
Schelp & R. Winter (Eds.), Integrationsmanage-
from http://www.brint.com/papers/enterarch.
ment (pp. 1-29). Berlin, Germany: Springer.
htm
Youngs, R., Redmond-Pyle, D., Spass, P., &
Martin, R., & Robertson, E. (2000). A formal
Kahan, E. (1999). A standard for architecture
enterprise architecture framework to support
description. IBM Systems Journal, 38(1), 32-50.

Success Factors and Performance Indicators for Enterprise Application Integration

Zachman, J. A. (1987). A framework for informa-

tion systems architecture. IBM Systems Journal,
26(3), 276-292.
Zachman, J. A. (2001). You can’t “cost-justify”
architecture. DataToKnowledge Newsletter (Busi-
ness Rule Solutions LLC), 29, 3.
Zahavi, R. (2000). Enterprise application inte-
gration with CORBA. New York: John Wiley
& Sons.

Chapter III
... and the Social Matters
Amany R. Elbanna
The London School of Economics and Political Science, UK

aBstract

This chapter introduces one of the social problems that could affect the integration of the implementation
team and highlights its effect on the integration capability of the ERP system. It adopts the sociologi-
cal theory of the actor network and develops the notion of organisational “othering” to make sense of
the raised intragroup conflict during implementation and to trace its effects on the final solution. The
chapter contributes to current understanding of the organisational complexity of ERP implementation
and the growing research on politics and intragroup conflicts.

introDuction face tremendous difficulties in implementing

ERP systems to the extent that their efforts were
Enterprise resource planning (ERP) systems have described by many authors as “the journey of a
received increasing attention from businesses, prisoner escaping from an island prison” (Ross
the press, and academia over the last few years. & Vitale, 2000), “mission critical” (Davenport,
It is presented to the market as one of the large 2000), and “the corporate equivalent of root-canal
integrated packaged software. Its market boomed work” (“SAP’s Rising in New York,” 1998).
and is expected to continue to grow, from $14.8 The complexity of ERP implementation is
billion in 1998 (Foremski, 1998) to $26.7 billion multidimensional with technical, organisational,
in 2004, with estimates of $36 billion by the end and social facets (Dong, 2000; Holland, Light, &
of 2008 (IDC, 2004). The top five vendors are Gibson, 1999; Krumbholz, Galliers, Coulianos, &
SAP, PeopleSoft, Oracle, Microsoft, and Sage.1 Maiden, 2000; Markus & Tanis, 2000). Previous
SAP is the market leader with a share of over research asserts that the social and organisational
30% of the ERP market (AMR Research, 2004; complexity has stronger effect on the implementa-
SAP AG, 2004). It nearly became the standard tion project performance than the mere technical
for doing business in many industries and the dimension (Xia & Lee, 2004).
de facto solution to replace the dispersed legacy There is a growing body of research on the
systems within organisations. Organisations technical side of the implementation including

Copyright © 2007, IGI Global, distributing in print or electronic forms without written permission of IGI Global is prohibited.
... and the Social Matters

research that focuses on the integration between occupied with unraveling the way societies come
ERP and other disparate systems that coexist with to accomplish certain goals (Latour, 1988). It
it (Themistocleous, Irani, & O’Keefe, 2001). The maintains a distinct view of society since it views
softer organisational and social issues involved it as a network of human and nonhuman actors.
in the implementation have not received much Since the social is nothing but chains of associa-
attention despite authors’ assertions that they tions between human and nonhuman actors, the
represent the major hurdle at the front of ERP theory keeps an analytically symmetrical view
implementation (Cadili & Whitley, 2005; Markus, of both of the social constituents (human and
Axline, Petrie, & Tanis, 2000; Mendel, 1999; nonhuman). It gained considerable attention in
Norris, 1998). the IS field, and many IS scholars have applied it
This chapter explores one of the social and in their work (Bloomfield, Coombs, Knights, &
organisational aspects that could affect the ERP Littler, 1997; Monteiro, 2000b; Walsham, 2001).
implementation project, causing delays and jeop- ANT views technology as a product of active
ardising its integration capability and potentials. negotiation and network building where society
It draws from a successful case of a multinational actively inscribes on the technology a certain
ERP implementation in a large international or- “programme of actions” (Monteiro, 2000a). It also
ganisation. Through the application of the actor- views technology as what holds society together
network theory’s (ANT) notion of translation and and renders it durable and relatively irreversible
the introduction of the concept of organisational (Latour, 1991).
“othering,” it unravels the problematic nature Translation is the dynamic by which an actor
of intragroup involvements in the implementa- recruits others into its project. It is a continuous
tion and how the organisation’s existing social process and “never a complete accomplishment”
logic could affect negatively the implementation (Callon, 1986). By and large, it describes how ac-
project. tors are bent, enrolled, enlisted, and mobilised in
The following section outlines the research’s any of the others’ plots (Latour, 1999). The word
informed theory and concepts. It briefly reviews itself keeps its linguistic sense: It means that one
ANT and in particular the notion of translation version translates every other (Latour, 1987). It
in addition to developing and introducing the does not mean a shift from one vocabulary to
new concept of organisational othering. This is another but “it means displacement, drift, inven-
followed by a brief section on the research set- tion, mediation, the creation of a link that did not
ting and methodology. The final two sections exist before and that to some degree modifies
are dedicated to the analysis of the case study’s two elements or agents” (Latour, 1999, p. 179). It
details, and the conclusion and implications of also has a “geometric meaning” that is moving
the findings. from one place to the other. Translating interests
means at once offering new interpretations of
these interests and channeling people in differ-
theoretical BackgrounD ent directions (Latour, 1987). The translation or
recruitment of entities toward a certain network
actor network theory could take place through implementing several
strategies. All would lead the actors in whatever
ANT was developed over the years in the field they do and whatever they are interested in to help
of science and technology studies (STS) through the network builders to pursue their interests.
the collaborative work of many scholars (Bijker Each network consists of more actors and
& Law, 1997; Latour, 1987; Law, 1992). ANT is intermediaries. At the same time, a network

... and the Social Matters

could be collapsed to represent a node in a wider and act on, different and sometimes competing
network. An actor, hence, is not only a member interests. One of the strategies that can distance
of his or her own local network, but this network actors from networks is therefore to exclude,
is part of a wider global network. Intermediar- label, name, and blacklist some groups in order
ies define the relationship between the local and to marginalise them. Othering and differing also
global network. serves as a tool by which the identity of a group
ANT does not expect the network to hold for- is assured against other groups. So, by other-
ever since it has no inertia. The network holds only ing and focusing on the differences between us
as long as the network builders involved invest and them, a group stresses its identity, creating
their efforts to lock actors in a certain transla- “symbolic boundaries” around it to keep it pure
tion and prevent them from joining in any other and keep intruders, foreigners, and all kinds of
competing ones. It is irreversible if the translation others away (Hall, 1997).
is able to suppress any other competitive transla- In these ways, others are identified and outcast
tion. On the other hand, a network could reverse as they are different from oneself. Hall (1997)
in front of a stronger competitive translation argues that, from many different directions and
that pulls the actors away from the previous one within many different disciplines, the question
(Callon, 1991). of difference and otherness plays an increasingly
important role. He explains that difference is
organisational othering ambivalent because it can play both positive and
negative roles. It is important for the production of
The notion of othering is implicitly embedded meaning, the formation of language and culture,
in ANT as the theory stresses differences and for social identities, and for a subjective sense of
creates a distinction between “them” and “us” the self; at the same time, it is threatening and a
through its attempts to translate and recruit ac- site of danger, negative feelings, splitting, hostil-
tors to a certain network, together with associated ity, and aggression toward the other.
attempts to distance or weaken the relationships Organisational othering is about the ways in
between these actors and other networks. Other- which some groups are perceived and categorised
ing is part of the competition between networks by others. It is to differentiate and to facilitate
that is needed to create sustainable boundaries, acting upon others. The labeling or stereotyping
space, and distance between the actors and other of others is carved and institutionalised over time,
networks. and it is often employed by a relatively powerful
The notion of othering itself is adopted from group as a means of defining other less powerful
anthropology and politics. It was developed to communities, mainly to stress the identity of the
understand how colonisers exercise power over powerful group over others (Beall, 1997). It is a
the colonised by naming, labeling, stereotyping, kind of encapsulation and fixation that is moved
and generally othering its subjects in order to around. Hence, othering is to identify stereotyped
divide and rule. The colonial ruler produces the notions about different entities and enact upon
colonised as a fixed reality that is at once an other them accordingly.
and yet entirely knowable and visible (Bhabha, It raises the question of how this othering could
1986). possibly be overcome in implementing ERP sys-
Othering, then, refers to the articulation of tems since the ERP systems’ logic is more about
differences. Yet, ANT is rather inclusive and integration, transparency, and coordination.
recognises that the constituents of networks have,

... and the Social Matters

research setting anD meth- the UK group (EUK) and the EUB group. This
oDology includes over 25 business units.
In 1998, Drinko announced the initiation of a
methodology “major Drinko-wide initiative unprecedented in
scale and cost” (CEO [chief executive officer] in the
This research belongs to the qualitative school of project inauguration speech) to implement a single
research in information systems (Kaplan & Max- system based on SAP technology. The project took
well, 1994). It adopts an interpretive case-study over 3 years and cost over £40 million. The project
approach since it explores the social aspects related was later narrowed down to focus on two major
to the ERP logic of integration. Interpretive case business units, namely the EUK business unit and
studies, by and large, are believed to be an appro- the EUB business unit. The EUB business unit
priate approach for enquiries aimed at exploring was, in general, sensitive toward whatever came
the nature of phenomena (Klein & Myers, 1998; from EUK and had a long history of rejecting
Orlikowski & Baroudi, 1991; Walsham, 1995). any sort of control coming from either the EUK
It does not aim to prescribe direct solutions but business unit or the corporate centre.
rather to highlight issues and invite reflections
and discussions.
Data collection took place between August analysis of the case stuDy
2000 and March 2001 in a sound large interna-
tional food and drinks organisation, anonymously organisational othering
Drinko, as part of a larger research project to study
the implementation of ERP in various organisa- Drinko EUB was for a long time othered within
tions. The system implementation project lasted Drinko. It was portrayed and stereotyped as
for 4 years and consisted of implementing five old-fashioned, with complacent staff who were
modules of SAP in two major business units (BUs) using the same procedures and concepts for
of the group located in two different European over 20 years, who had typically worked for the
countries. The researcher was allowed access to company for 15 years or more, and who had no
the prestigious organisation in the last three phases intention of changing, advancing, or modernis-
of the project. The data collection was based on ing their “historic style” (as expressed by many
interviews and document reviews. All quotes are EUK interviewees). In contrast, EUK perceived
from the field. When more than one source agrees its own staff as being dynamic, modern, “capable
on a particular view, only one quote is presented of doing things,” and able to face successfully the
without referring to the source. aggressive competition in the market.
Although EUK perceived EUB as being re-
the case study sistant and stubborn by rejecting any sort of idea
coming from EUK, and although EUB was behind
Drinko is a global food and drinks group that EUK in terms of business practices, structure,
owns many production, packaging, and sales sites, communication, and style, EUK had accepted
each of which represents a company or group of for a long time a fluid relationship with EUB
companies that operates locally. Drinko has major that allowed EUB to be distanced and separate
production operation in the United Kingdom and as long as EUB was “bringing the cash back”
another European country (disguised as EUB). (interviews with the executive manager and
The case will focus only on the business units of change manager).

... and the Social Matters

From EUB’s perspective, on the other hand, solution to the problem as it convinced EUB that
EUK unreasonably wanted to dominate, rule, and any other approach would be not only costly, but
control EUB. It did not find a reason for EUK’s also high risk considering the large number of
perceived superiority and so always tried to assert legacy systems in place in EUB. In doing this,
its identity and the fact that EUB was the powerful Drinko’s top management set the integrated SAP
part by providing the cash for the company, be- system as an obligatory passage point if EUB was
lieving that Drinko would have collapsed without to overcome its Y2K crisis.
its hard work. EUB felt that despite it providing However, Drinko’s senior managers were
a valuable intermediary for the EUK network, it concerned that this would not be enough to pull
was not correctly valued and positioned within the the EUB internal network toward EUK because
organisation. Hence, it liked to stress how much EUB was “typically suspicious” of the EUK. They
it supported the company’s whole network. were sure that the invisible network that the EUB
top management represented would render itself
how to integrate the other visible and problematic as the project became
effective. Hence, they decided to proceed with
In 1996, Drinko’s top management became con- recruiting more actors from the EUB network,
cerned with the cash flow (intermediary) that EUB namely, the “others’” location of EUB, and ad-
provided and feared that the increased competition opted it as the location of the project. In doing
may decline it further over time. It therefore felt so, and by expressing publicly that the choice
it needed to interfere in the “cash cow’s” (EUB’s) of location offers “significant resources” (CEO
internal network to change it toward becoming speech) because of the size of Drinko’s operations
more efficient and capable of meeting the increas- in EUB and the “available capabilities” (project
ing competition. However, management knew that director speech) that EUB could provide, they
EUB would be very sensitive toward whatever appeared to follow EUB’s explicit interests in
came from EUK and that no change programme bending the whole EUK network toward them,
would be accepted from there. This led Drinko’s including asking EUK team members to fly out
senior managers to identify a good opportunity to work from EUB (excerpts from the corporate
to align EUB with EUK in the notion of having announcement).
an integrated system, which would deal with Y2K
(Year 2000) issues. They saw that facing Y2K network reverse and Project Delay
compatibility issues offered a convincing excuse
to implement the integrated system that would EUK staff felt that they had been enrolled in EUB’s
interfere with EUB and connect it operationally internal network and that EUB was dominating
to EUK. The Y2K argument was a particularly the project. They first complained that the build-
powerful one for EUB since the sheer number of ings were “old…like all the buildings [in EUB].”
legacy systems it had to deal with was a serious However, the buildings were not actually that old,
problem. but had traditional corridors and closed offices
For this reason, the corporate-wide SAP system that were different to the open-plan layouts in
was presented to EUB top management as a way EUK buildings.
to solve the threatening situation and the danger The “old-fashioned” EUB offices and long
of a disastrous system collapse due to Y2K com- corridors were viewed by EUK staff as constitut-
patibility issues. This problematised the system ing part of EUB’s associations and networks, and
for EUB top management as a survival solution. hence part of the EUB identity that they strongly
It also cut off the route to any other possible IT opposed and othered. This othering perspective

... and the Social Matters

viewed the building’s internal layout as reflecting CEO, revealed that both EUB-dominated teams
a hierarchical, slow, undynamic way of working, and the project office preferred to share the same
“which is a common practice in EUB” (interviews building, while EUK teams and staff chose from
with a module manager, a change manager, and the start to be in the other building in EUB. It
different team members). Team members from mentioned that “the two buildings are taking on
the EUK refused to enter EUB’s network by, for individual characters [characteristics] and align-
example, sharing office rooms with each other ment which might result in gaps appearing in the
to try to translate the buildings in their way. As overall solution [system]” (consultants’ report).
an EUK manager expressed it, “Whenever [we] This was also supported by the EUK process
find a large room, they fit more than one person owners, who found it difficult to “conquer the
together to allow for ‘informal ways’ of working.” in-built prejudices and impacts of their location
Although EUB’s buildings were criticised for in designing and communicating a “shared vi-
enforcing a formal hierarchical relationship, the sion” with EUB. They preferred to work from
EUB business processes were later criticised as their EUK offices and kept blaming EUB for not
being too personal and informal, which reflects cooperating and overcoming “prejudices.”
the contradictions and opposing opinions from The top management thought another little
the EUK side that stemmed from viewing EUB detour for EUB was needed to move it away
as the “other.” from direct involvement in the project teams,
EUK staff continued to reflect their other- while keeping it broadly locked into the project
ing perception on everything else in the EUB network. Pulling the location out would have been
network. For instance, as the project manager quite risky as it represented EUB’s “actorship” in
was from EUB, the EUK staff did not “see a the project and was strongly associated with all
point” in being recruited into his network and actors in the EUB network. If the EUB locations
to exchange the agreed-upon intermediaries: were removed from the SAP project network, the
schedules, milestones, and progress against tar- associated EUB network would probably have
gets. For this reason, the project office lost track followed by withdrawing from the project net-
of some teams because it continued to have out- work. Drinko top management therefore found
dated information on their progress. The project that marginalising EUB required the creation of
manager’s invisible internal network was made an invisible detour: taking EUB away from the
visible when his aligned technical tools, such as centre to the periphery of the project without it
project management software and Gantt charts, realising the displacement. Hence, the top man-
were not allowed to operate because the data they agement asked Independent Consulting to give
had was out of touch with what was happening its input to this issue.
on the ground. After long discussions with Independent Con-
EUK complained several times to Drinko’s sulting, a joint report was compiled and issued
CEO about the uncooperative attitude of EUB, under the consultants’ authorship to convince EUB
pointing to it as the reason for delays and a poten- and justify the change. This explained the need for
tial threat to the system integration capabilities. the project to have “a business pull” rather than
EUK tried to translate the top management’s “the programme push” that had been taking place,
interests and channel them toward streamlining and justified the change by mentioning that “it is
the teams and enhancing their cooperation. The not unusual to change during a programme” and
top management commissioned a consultancy that the change proposed would be a way of going
firm (Independent Consulting) to investigate the forward with the SAP project (consultants’ report
issue. Its report, confidentially submitted to the and different presentations, a change manager

... and the Social Matters

interview, a consultant interview). The changes although the question of its location turned out
that were then suggested in effect marginalised to be problematic. EUK staff believed that it had
EUB actors while continuing to lock them into the to be in the EUK. They problematised the issue
project network. For example, the project’s new to top management by arguing that EUB did not
structure moved the managing director of EUB have the competences to operate it and the only
from the active post of sponsoring the sales and staff who know how to do that were in the EUK.
operations planning team to a more ceremonial Hence, they argued that any single shared services
post of being a member of the steering committee. centre should be located in EUK, not EUB.
The sponsors of the new teams were all located in The top management did not want any explicit
EUK. To ensure the locking in of EUB business manifestation of otherness and marginalisation
units, the new “release owner” post was created at this point, so they did not want to “take away
for each stream, with three owners representing everything” from EUB territory, which “would
the companies within the project’s scope: EUB, jeopardise the whole thing in such a critical
EUK (including the corporate centre), and Europe time” when the SAP configuration was being
sales. This ensured the EUB release owner was determined. Thus, top management decided to
responsible only for the businesses processes compromise the system and configured it awk-
in EUB, and the rest was left for EUK release wardly to have two shared services, one in EUB
owners. and the other in EUK, in order to ensure that an
These changes guaranteed that EUB staff integrated SAP system would still assure the
would not be in an effective powerful position, sovereignty of EUB and would not affect its right
although they would remain actors in the network, to be left alone, as before.
thereby ensured their loyalty to the project. Most At the same time, Drinko’s top management
of the newly appointed actors worked from EUK made it clear that this was a temporary solution
offices without any formal announcement of a and that it intended to move to a single shared
location change for the programme. Consequently, services centre somewhere else in the future,
the project returned back to the EUK, putting with the time and location being determined later
an end to the EUK staff’s feeling that it was after the implementation. By the end of 2001, and
being dominated by EUB in terms of staff and after the implementation, the company decided
location and the significant delay in the project to undo this “odd structure” and take away the
schedule. two shared services from the two countries to
amalgamate them in one shared service located
the organisational othering in a third European country. In so doing, it hoped
inscribed into the system to avoid any controversy concerning who will
“boss” whom.
The long othering of EUB was reflected in the
SAP system configuration. SAP recommends
and supports having one service centre for the Discussion anD conclusion
whole organisation, which is considered to be a
source of cost cutting and efficiency. However, Organisational integration is one of the key aims
the sensitivity of the EUK-EUB relationship and of the organisations implementing ERP and is
EUK’s full realisation that its othering of EUB was usually taken for granted as a technical capabil-
well-known on the EUB side, Drinko top manage- ity of the system that could be straightforwardly
ment had to take extra precautions. They believed delivered. This chapter focuses on organisational
that Drinko should have a single service centre, othering and how it could hinder this essential

... and the Social Matters

function of the system. It emphasises the im- (Sawyer, 2001b). This study reveals yet another
portance of understanding the social logic that aspect of the complexity of managing these teams
dominates the organisation when managing stemming from institutionalised prejudices and
ERP implementation projects. It doubts the no- othering. It demonstrates that careful monitoring
tion that ERP systems straightforwardly enable and managing of the political sensitivity of the
organisations to coordinate across geographically teams involved can overcome some of the conflicts
dispersed locations (Davenport, 1998) and sug- and avoid the configuration of isolated modules
gests that the implementation of ERP requires and isolated business units. In this regard, it agrees
organisations to do so. Along the same line, ERP with the remark that ERP project management
does not redefine previously known organisa- is deemed to fail if it does not account for the
tional boundaries (Brehm, Heinzl, & Markus, business politics that comprise the framework
2001; Foremski, 1998), yet it strongly requires within which the ERP project takes place (Besson
organisations to bridge their social, behavioural, & Rowe, 2001).
and structural barriers and prejudices. Studies on intragroup conflicts during IS de-
Through the notion of organisational othering, velopment tend to divide the nature of the conflict
the chapter reveals the historical and long-standing into relationship- and task-related conflicts and
social logic of othering embedded in the business focus on the task-related conflict and its effect
units’ relationships in Drinko and reveals that on performance (Besson, 1999; Besson & Rowe,
othering can be reproduced and inscribed in the 2001; Sawyer, 2001a). This study reveals that arbi-
system, resulting in unusual and costly configura- trary categorisation of the nature of conflicts and
tion. The reproduction of organisational othering the decision of ERP researchers’ to focus on one
and the subsequent creation of a separate structure aspect or another a priori (Besson & Rowe) could
for service centres despite the implementation cause one to miss the complexity of the encoun-
of the integrated ERP system agrees with Quat- tered conflict. The application of ANT provides
trone and Hopper’s (2005) observation that “ERP a vehicle to avoid any a priori categorisation and
reproduced existing structure,” yet Drinko’s leave it as an empirical matter for the actors in the
focus was on the effect of this on management field to decide upon. The concept of organisational
control and not on understanding how this hap- othering helps to unravel the historical roots and
pened. This explains what researchers sensitively fixed perceptions (relationship conflict) behind the
observed that organisation-wide integration is surfaced task-related conflicts. This concept adds a
not always feasible and could be problematic, new dimension to the politics of implementing IS
and that organisations, in many cases, reach a and the intragroup conflicts involved based on the
country-specific customisation of the system combination of organisational history, culture, and
within the ERP framework (Markus, Tanis, & institutionalised marginalisation of some groups
Fenema, 2000). within the organisation. The incorporation of
The team involved in ERP implementation nonhumans as actors in the organisational politics
tends to be large and heterogeneous, which makes and the revealing of their role in the conflict and
it a complex entity to manage (Kay, 1996; Ward its resolution contribute to the ongoing discussion
& Peppard, 1996). It involves staff from differ- on the politics of IS implementation (Brooke &
ent organisational units. Together, these people Maguire, 1998; Cavaye & Christiansen, 1996;
lead the decision making concerning how the Doolin, 1999; Markus, 1983).
organisation’s processes will be mapped or For the practice of implementing ERP systems,
reconfigured to take advantage of the integra- the findings invite practitioners to reconsider the
tive functionality embedded in the ERP system view that the technical integration capability of

... and the Social Matters

ERP can be straightforwardly materialised, cross- technical change (2nd ed.). Cambridge, MA: The
ing the previous organisational boundaries and MIT Press.
leading to a successful cooperation between previ-
Bloomfield, B. P., Coombs, R., Knights, D., &
ously isolated groups. Instead, they should be open
Littler, D. (Eds.). (1997). Information technology
to examining the roles of all actors, which have
and organizations: Strategies, networks, and
the power to affect not only the implementation
integration. Oxford University Press.
project but also the system being implemented.
Organisational othering should be accounted for, Brehm, L., Heinzl, A., & Markus, L. M. (2001).
monitored, and managed before it gets inscribed Tailoring ERP systems: A spectrum of choices
into the ERP system, which could result in repro- and their implications. Paper presented at the 34th
ducing organisational boundaries. At the same Hawaii Conference on Systems Sciences, HI.
time, practitioners can seize the opportunity of
Brooke, C., & Maguire, S. (1998). Systems de-
ERP implementation to loosen the established
velopment: A restrictive practice? International
organisational barriers and tackle prejudices
Journal of Information Management, 18(3), 165-
between different organisational groups.
180.
Cadili, S., & Whitley, E. A. (2005). On the inter-
references pretive flexibility of hosted ERP systems (Work-
ing Paper Series No. 131). London: Department
AMR Research. (2004). ERP market. Retrieved of Information Systems, The London School of
March 21, 2005, from http://www.amrresearch. Economics and Political Science.
com
Callon, M. (1986). Some elements of a sociology
Beall, J. (1997). Valuing difference and working of translation: Domestication of the scallops and
with diversity. In J. Beall (Ed.), A city for all: the fishermen of St Brieuc Bay. In J. Law (Ed.),
Valuing difference and working with diversity Power, action and belief: A new sociology of
(pp. 2-37). London: Zed Books Ltd. knowledge (pp. 196-233). London: Routledge &
Kegan Paul.
Besson, P. (1999). Les ERP a l’epreuve de
l’organisaton. Systemes D’Information et Man- Cavaye, A., & Christiansen, J. (1996). Under-
agement, 4(4), 21-52. standing IS implementation by estimating power
of subunits. European Journal of Information
Besson, P., & Rowe, F. (2001). ERP project
Systems, 5, 222-232.
dynamics and enacted dialogue: Perceived un-
derstanding, perceived leeway, and the nature of Davenport, T. H. (1998). Putting the enterprise
task-related conflicts. The Data Base for Advances into the enterprise system. Harvard Business
in Information Systems, 32(4), 47-66. Review, 121-131.
Bhabha, H. K. (1986). The other question: Dif- Davenport, T. H. (2000). Mission critical: Real-
ference, discrimination and the discourse of co- izing the promise of enterprise systems. Boston:
lonialism. In F. Barker, P. Hulme, M. Iversen, & Harvard Business School Press.
D. Loxley (Eds.), Literature, politics and theory
Dong, L. (2000). A model for enterprise systems
(pp. 148-172). Methuen & Co. Ltd.
implementation: Top management influences on
Bijker, W. E., & Law, J. (Eds.). (1997). Shaping implementation effectiveness. Paper presented at
technology/building society: Studies in socio- the Americas Conference on Information Systems,
Long Beach, CA.

... and the Social Matters

Doolin, B. (1999). Sociotechnical networks and Latour, B. (1988). The pasteurization of France
information management in health care. Account- (A. Sheridan & J. Law, Trans.). Harvard Univer-
ing, Management and Information Technology, sity Press.
9(2), 95-114.
Latour, B. (1991). Technology is society made
Foremski, T. (1998, September 2). Enterprise durable. In J. Law (Ed.), Sociology of monsters:
resource planning: A way to open up new areas Essays on power, technology and domination
of business. Financial Times, p. 6. (pp. 103-131). London: Routledge.
Hall, S. (Ed.). (1997). Representation: Cultural Latour, B. (1999). Pandora’s Hope: Essays on
representations and signifying practices. Sage the reality of science studies. Cambridge, MA:
Publications. Harvard University Press.
Holland, C. P., Light, B., & Gibson, N. (1999, June). Law, J. (1992). Notes on the theory of the actor-
A critical success factors model for enterprise network: Ordering, strategy, and heterogeneity.
resource planning implementation. Paper pre- Systems Practice, 5(4), 379-393.
sented at the the Seventh European Conference on
Markus, M. L. (1983). Power, politics and MIS
Information Systems, Copenhagen, Denmark.
implementation. Communication of the ACM,
IDC. (2004). Worldwide ERP application market 26(6), 430-444.
2004-2008 forecast: First look at top 10 vendors.
Markus, M. L., Axline, S., Petrie, D., & Tanis,
Retrieved June 9, 2005, from http://www.IDC.
C. (2000). Learning from adopters’ experiences
com
with ERP: Problems encountered and success
Kaplan, B., & Maxwell, J. A. (1994). Qualita- achieved. Journal of Information Technology,
tive research methods for evaluating computer 15, 245-265.
information systems. In J. G. Anderson, C. E.
Markus, M. L., & Tanis, C. (2000). The enterprise
Aydin, & S. J. Jay (Eds.), Evaluating health care
system experience: From adoption to success.
information systems: Methods and applications
In R. W. Zmud (Ed.), Framing the domains of
(pp. 45-68). Thousand Oaks, CA: Sage.
IT research: Glimpsing the future through the
Kay, E. (1996, February 15). Desperately seeking past. Cincinnati, OH: Pinnaflex Educational
SAP support. Datamation, pp. 42-45. Resources, Inc.
Klein, H. K., & Myers, M. D. (1998). A set of prin- Markus, M. L., Tanis, C., & Fenema, P. C. v. (2000).
ciples for conducting and evaluating interpretive Multisite ERP implementations. Communications
field studies in information systems. Retrieved of the ACM, 43(4), 42-46.
December 11, 1998, from http://www.auckland.
Mendel, B. (1999). Overcoming ERP projects
ac.nz/msis/isworld/mmyers/klien-myers.html
hurdles. InfoWorld, 21(29).
Krumbholz, M., Galliers, J., Coulianos, N., &
Monteiro, E. (2000a). Actor-network theory and
Maiden, N. A. M. (2000). Implementing enterprise
information infrastructure. In C. U. a. o. Ciborra
resource planning packages in different corporate
(Ed.), From control to drift (pp. 71-83). New York:
and national cultures. Journal of Information
Oxford University Press.
Technology, 15, 267-279.
Monteiro, E. (2000b). Monsters: From systems
Latour, B. (1987). Science in action: How to
to actor-networks. In K. Braa, C. Sorensen, & B.
follow scientists and engineers through society.
Dahlbom (Eds.), Planet Internet. Lund, Sweden:
Cambridge, MA: Harvard University Press.
Studentlitteratur.

... and the Social Matters

Norris, G. (1998). SAP: An executive’s compre- Sawyer, S. (2001b). Socio-technical structures in

hensive guide. New York: J. Wiley. enterprise information systems implementation:
Evidence from a five year study. Paper presented
Orlikowski, W. J., & Baroudi, J. J. (1991). Study-
at the IEEE EMS International Engineering Man-
ing information technology in organizations: Re-
agement Conference, Albany, NY.
search approaches and assumptions. Information
Systems Research, 2(1), 1-28. Themistocleous, M., Irani, Z., & O’Keefe, R.
M. (2001). ERP and application integration: Ex-
Quattrone, P., & Hopper, T. (2005). A “time-
ploratory survey. Business Process Management
space odyssey”: Management control systems
Journal, 7(3), 195-204.
in two multinational organisations. Accounting,
Organizations & Society, 30(7/8), 735-764. Walsham, G. (1995). The emergence of inter-
pretivism in IS research. Information Systems
Ross, J. W., & Vitale, M. R. (2000). The ERP
Research, 6(4), 376-394.
revolution: Surviving vs. thriving. Information
Systems Frontiers, 2(2), 233-241. Walsham, G. (2001). Making a world of difference:
IT in a global context. John Wiley & Sons Ltd.
SAP AG. (2004). SAP annual report 2004. Au-
thor. Ward, J., & Peppard, J. (1996). Reconciling the
IT/business relationship: A troubled marriage in
SAP’s rising in New York. (1998, August 1). The
need of guidance. Journal of Strategic Informa-
Economist.
tion Systems, 5, 37-65.
Sawyer, S. (2001a). Effects of intra-group con-
Xia, W., & Lee, G. (2004). Grasping the complex-
flict on packaged software development team
ity of IS development projects. Communications
performance. Information Systems Journal, 11,
of the ACM, 47(5), 95-74.
155-178.

Chapter IV
Precontract Challenges:
Two Large System Acquisition Experiences

Ayça Tarhan
The Bilgi Group Ltd., Turkey

Çiğdem Gencel
Middle East Technical University, Turkey

Onur Demirors
Middle East Technical University, Turkey

aBstract

The acquisition of software-intensive systems demands significant work on requirements prior to es-
tablishing the contract. Two significant challenges of the precontract phase are the identification of
functional requirements and the determination of an approximate budget. In this chapter, experiences
gained from the implementation of a business-process-based requirements-elicitation approach to two
large innovative military applications are presented. The requirements-elicitation process proposes the
determination of the requirements of a software-intensive system to be acquired from the business ob-
jectives and defined processes. In addition to the details related to the requirements-elicitation process,
management practices for coordinating the efforts related to the acquisition process and determination
of costs are also discussed.

introDuction During the acquisition of large and innova-

tive software systems, requirements elicitation
Acquisition cycles perceive requirements elici- entails more than obtaining and processing cus-
tation as the process to identify and understand tomer needs and involves major risks related to
needs and constraints of the customer. While cost, quality, scope, and schedule. Specifically,
generic approaches are successfully applied the acquisition of contracted software demands
to acquire manufacturing goods and services, significant work on functional requirements prior
software acquisition provides unique challenges to establishing the contract.
at this stage.

Copyright © 2007, IGI Global, distributing in print or electronic forms without written permission of IGI Global is prohibited.
Precontract Challenges

In most cases, large and innovative software Our tasks involved business process modeling,
systems have numerous stakeholders with con- requirements elicitation, size and cost estimation,
flicting and frequently unidentified stakes. The and the preparation of technical documents for
attributes of the system to be acquired might the acquisition of command, control, communica-
require unique methodologies to be utilized, and tions, computers, intelligence, surveillance, and
the characteristics of the acquisition organization reconnaissance (C4ISR) subsystems for Turkish
make a difference. Ideally, the acquirer needs to Land Forces Command (TLFC). The outcomes
understand the concept, the domain as a whole, of the implementations formed the major parts of
the technology to be utilized, and the technical the request for proposals (RFP) currently issued
and management constraints of the project. The by TLFC.
current business processes should be explicit and In this chapter, we focus on the implementa-
potential new technologies should be prototyped. tion of a business-process-based approach for
Only such an understanding creates a solid founda- requirements elicitation as well as on management
tion for the challenges of defining the functional practices for coordinating the efforts for RFP
contract requirements as well as to make realistic preparation. Based on the elicited requirements,
estimates of size, effort, and cost. the method used for estimating the size of the
Notations and tools developed primarily for software products of the projects is also briefly
business process modeling provide a natural discussed.
tool set for the establishment and transformation In the chapter, an overview of the literature on
of need from concept to system requirements. software-intensive system acquisition and busi-
Organizational processes facilitate better under- ness process modeling for requirements elicitation
standing of the system as a whole, depict potential is presented. Then the descriptions of the cases
stakeholder conflicts, enable the determination of are given. Next the chapter gives the summary
clear boundaries, and provide a natural medium of descriptions of the acquisition planning processes
communication. Once the organizational process and discusses the mapping between our approach
baseline is established, it can also be used as an and the C4ISR framework’s descriptive views.
enabler for technical processes. It can be used The details of the two challenging processes of
to estimate the size of the software system to be the precontract phase of software-intensive sys-
developed, which in turn is used to estimate the tem acquisition, system requirements elicitation,
effort and related costs. It can be used as a source and software size estimation are also discussed.
for software requirements specification. Both Finally, we provide lessons learned and present
forward and backward traceability can be easily conclusions.
established and partially automated. It is also pos-
sible to automate the generation of specifications
in natural language and software size estimation BackgrounD stuDies
in Mark II function points. In other words, busi-
ness process models, when used effectively, can There are several frameworks, models, and prac-
be a basis to respond to the several challenges of tices that guide agencies in acquiring software-
precontract phases. intensive systems. These include the software
During the last 3 years, we have implemented acquisition capability maturity model (SA-CMM;
an approach based on a business process model Cooper & Fisher, 2002), the supplier agreement
together with a unique set of notations and tools management process of capability maturity
(Demirors, Gencel, & Tarhan, 2003, 2006) to model integration (CMMI; CMMI Product Team,
guide two large military acquisition projects. 2001), IEEE’s (1998b) Recommended Practice for

Precontract Challenges

Software Acquisition, and the C4ISR architecture The Software Engineering Institute’s (SEI)
framework (Department of Defense [DoD] Ar- models and practices specified above describe
chitecture Working Group, 1997). what characteristics the acquisition process should
SA-CMM offers a framework for organiza- possess, and do not mandate how the acquisition
tional improvement, and it focuses on building process should be implemented or who should
the acquisition-process capability of an organiza- perform an action. In other words, neither of
tion. It defines five levels of software-acquisition them guides as an acquisition life cycle. IEEE’s
process maturity. (1998b) Recommended Practice for Software
The CMMI supplier agreement management Acquisition offers such a life cycle for a typical
process area is targeted to manage the acquisition software-acquisition process, which primarily
of products from suppliers for which there exists a includes planning, contracting, product imple-
formal agreement. It has a context for system and mentation, product acceptance, and follow-on
software acquisition, and remains more generic phases. IEEE defines and relates one or more
when compared to other models. It includes the steps to each of these phases, as given in Table 1.
practices for determining the type of acquisition It should be noted that these steps might overlap
that will be used for the products to be acquired, or occur in a different sequence, depending upon
selecting suppliers, establishing and maintaining the organizational needs.
agreements with suppliers, executing the supplier Another model, which was primarily devel-
agreement, accepting delivery of the acquired oped and has been used for military acquisitions
products, and transitioning acquired products to at the U.S. Department of Defense, is the C4ISR
the project.

Table 1. Software-acquisition phase milestones (IEEE, 1998b)

Phase Phase
Phase Initiation Completion Steps in Software-Acquisition Process
Milestone Milestone

1) Planning organizational strategy

Develop the
Planning Release the RFP 2) Implementing organization’s process
idea
3) Determining the software requirements

4) Identifying potential suppliers

RFP is 5) Preparing contract requirements
Contracting Sign the contract
released 6) Evaluating proposals and selecting the
supplier

Product Contract is Receive the

7) Managing supplier performance
Implementation signed software product

Software
Product Accept the 8) Accepting the software
product is
Acceptance software product
received

Software Software product

Follow On product is is no longer in 9) Using the software
accepted use

Precontract Challenges

Architecture Framework (DoD Architecture One of the primary reasons underlying the
Working Group, 1997). This framework provides definition of these models is to develop a mecha-
the rules, guidance, and product descriptions for nism to appropriately define the requirements
developing and presenting architecture descrip- of a software-intensive system, which will be
tions of the systems to be acquired. The aim of taken as a basis by both acquirer and supplier
this effort is to ensure building interoperable and organizations throughout the acquisition. Defin-
cost-effective military systems. ing software-intensive system requirements is
The DoD Architecture Working Group (1997) not straightforward; it requires extensive under-
defines an architecture description in the C4ISR standing of the domain and representing domain
architecture framework as “a representation, as knowledge formally and visually, not getting lost
of a current or future point in time, of a defined in the domain and skipping any point, as well as
domain in terms of its component parts, what those enabling the ease of understanding and health
parts do, how those parts relate to each other, and of validation. There are several approaches and
the rules and constraints under which the parts related techniques used to gather domain knowl-
function” (p. 2-1). There are three major views edge, including functional approaches such as data
that logically combine to describe architecture: flow diagrams (DFDs), scenario-based approaches
the operational, systems, and technical views. such as use cases, and business-process-oriented
Since each view provides different perspectives approaches such as business process modeling.
on the same architecture, DoD suggested using Business process modeling is a technique used
an “integrated” description that would provide to understand, depict, and reorganize business
more useful information to the planning, pro- processes of an organization. Davenport (1993)
gramming, and budgeting process and to the defines a process as “a specific ordering of work
acquisition process. Figure 1 shows the linkages activities across time and place, with a beginning,
that describe the interrelationships among the an end, and clearly defined inputs and outputs: a
three architecture views. structure for action” (p. 5). A business process

Figure 1. Fundamental linkages among the views (DoD Architecture Working Group, 1997)

operational view
Processing
and levels of (identifies information Processing and
information needs and warfighter inter-nodal
exchange levels of
relationships)
requirements information
exchange
requirements
Systems associations
Basic technology, to nodes, activities,
supportibility and needlines and
new capabilities requirements

Technical criteria governing

interoperable implementation /
procurement of the system view
technical view selected system capabilities
(relates capabilities and
(prescribes standards characteristics to
and conventions) Specific capabilities identified operational
to satisfy information requirements)
exchange levels and other
operational requirements

Precontract Challenges

defines how an organization achieves its purpose increase in customer and user participation
including its vision and goals. in the requirements-elicitation process
The analysis and design of business processes • Increases efficiency in determining deficien-
are the major tasks of business process reengineer- cies in the current business processes and
ing (Hammer & Champy, 2001; A. W. Scheer, modeling the target business processes
1994). Business process modeling has been • Helps in identifying business requirements
implemented by a large number of organizations as the knowledge is captured at a more
as part of business process reengineering during abstract, business-need level than many
the last decades (Davenport, 1993; Hammer & other specification approaches (Demirörs,
Champy). It is claimed that it adds the most value Demirörs, Tanik, Cooke, Gates, & Krämer,
when the application environment is complex and 1996; Wiegers, 1999).
multidimensional, and many people are directly
involved in using the system (Yourdon, 2000).
The analysis of business processes requires DescriPtion of the cases
understanding the current business processes of
the organization before designing the new ones. We have implemented the planning phase of the ac-
Especially in complex organizations, there is no quisition life cycle in the context of acquiring two
way to migrate to a new process without under- large innovative military applications for TLFC.
standing the current one. Existing business process TLFC is a part of the Turkish Armed Forces and
models enable participants to develop a common consists of four armies, one training and doctrine
understanding of the existing state, and are used command, and one logistic command.
to establish a baseline for subsequent business The projects targeted RFP preparation for two
process innovation actions and programs. The different but closely related C4ISR subsystems
design of business processes is performed before for TLFC. The Middle East Technical University
implementation of the system in order to translate (METU) Project Office, as depicted in Figure 2,
the requirements of the business process innova- counseled the TLFC Project Office for prepar-
tion into proposed system requirements. Existing ing the technical contract of the system to be
business processes are the foundation of this kind acquired.
of study for finding out the weak points. When Throughout the chapter, we code these projects
designing the new system, it is worthwhile to try to as A and B. Due to security constraints, names
describe the new processes based on the business and descriptions of the organizational processes
objectives to respond to business requirements are not provided. We briefly define the charac-
(Cummnis, 2002). The target process models teristics of the projects to provide insight on the
serve as the foundation for implementing the new implementations of the acquisition planning pro-
business processes and defining the requirements cess. The domains of Project A and Project B are
for new information technology systems. different but complementary with a high degree of
As a result, business process modeling brings data exchange requirements. There are four other
the following advantages to the requirements C4ISR subsystem projects that are planned to be
elicitation of software-intensive systems. integrated with these two. Therefore, not only
the functional requirements of each subsystem
• Brings broader view to business domain domain, but also the integration requirements of
• Creates a common language between ana- Project A and Project B with these projects had
lysts and customers or users, leading to an to be considered.

Precontract Challenges

Table 2. Information on case projects

Effort Number of Estimated

Duration
Project (person- METU Size
(months)
months) Staff (FP)

A 8 18 11 10,092

B 13 26.5 9 25,454

Figure 2. Projects organization

Both projects required taking a system view- for the acquisition planning process by the METU
point to map domain requirements to hardware, Project Office are given in Table 2. The effort uti-
software, and telecommunication components. lized by the TLFC Project Office is not included
Estimated sizes for the software components as the collected data were not consistent.
of these systems as well as the number of staff Both projects required various resources to
involved and the duration and total effort utilized be utilized including human resources, process

Precontract Challenges

modeling notations and tools, and domain-spe- Project Office, who are also domain experts. Not
cific materials such as books and guidelines. The all of the TLFC Project Office staff participated in
characteristics of the resources utilized in Project the workgroup meetings at the same time. They
A and Project B and their organizations were participated in an interchangeable manner. In
similar since not only the purpose of both of the addition, seven more domain experts, who are
projects was to acquire C4ISR subsystems, but the not members of the TLFC Project Office, and two
customer was TLFC in both cases as well. representatives of the organizational units where
Human resources included the Project Coordi- the system would be used joined the validation
nation Committee, the staff of METU and TLFC activities.
project offices, domain experts, and the current Other resources we utilized in the projects
executives and representatives of the military units included process modeling notations and tools,
where the system would be used. The organization and domain books and documents. We proposed
of the project staff is shown in Figure 2. in Demirörs et al. (2003) that the candidate tool for
The Project Coordination Committee coordi- business process modeling should support defini-
nated and monitored the tasks of the METU and tions for process, process flow, input and output,
TLFC project offices and was in coordination input and output flow, role, and responsibility
with the committees of other C4ISR subsystem entities at minimum. Specifically in these projects,
projects of TLFC in order to depict the system the architecture of integrated information system
interfaces. (ARIS) concept and ARIS tool set (A. G. Scheer,
The METU Project Office counseled TLFC 2003) were used as the modeling tool. ARIS is
for preparing the technical contract of the system frequently used by consultants and companies in
to be acquired within the boundary of the project creating, analyzing, and evaluating organizational
and included a project manager and software, processes for business process reengineering.
hardware, and telecommunication analysis teams. While modeling the business processes, orga-
Analysis teams modeled the business processes nizational charts, function trees, extended event-
and specified the software, hardware, and tele- driven process chain (eEPC) diagrams, access
communication requirements. diagrams, and network topology diagrams were
The TLFC Project Office executed the pro- used as basic process modeling notations. The
cesses of the project and included a project man- organizational chart reflects the organizational
ager, externally involved domain experts who units (as task performers) and their interrela-
have domain knowledge, executives, and current tionships, depending on the selected structuring
representatives of the military units who would criteria. Business processes consist of complex
use the system to be acquired. functions that are divided into subfunctions,
In Project A, the project staff consisted of and basic functions represent the lowest level in
seven part-time persons from the METU Project semantic function-tree diagrams. The procedure
Office, four graduate students of METU who have of a business process is described as a logic chain
military background, and five part-time persons of events by means of an event-driven process
from the TLFC Project Office. In addition, two chain. Events trigger functions and are the result
domain experts and four representatives of the of functions. By arranging a combination of events
organizational units where the system would be and functions in a sequence, eEPCs are created.
used joined the validation activities. We created 210 distinct diagrams in Project A
In Project B, the project staff consisted of and 295 in Project B to model existing business
nine part-time persons from the METU Project processes of different levels of organizational
Office and nine part-time persons from the TLFC units by using the eEPC notation.

Precontract Challenges

In Project B, in order to generate user-level acquisition Planning

functional system requirements with the KAOS Processes
tool (Su, 2004; Turetken, Su, & Demirors, 2004),
we derived and used a special notation while The processes we implemented for acquisition
modeling target business processes. This notation planning are shown in Figure 3. Summary descrip-
differed from Project A’s in the way that color tions for the processes of the acquisition planning
codes and specific rules for the naming of func- phase are as follows.
tions, inputs, and outputs were used.
Hardware components and their high-level • Planning and managing acquisition plan-
relations for each organizational unit were mod- ning project: A project management plan
eled by using the access-diagram notations. The was prepared at the start of the project in
assignment of software components to hardware order to describe the activities, responsibili-
components, and the domain users of these hard- ties, schedule, and effort as related to acquisi-
ware components were also modeled by using the tion planning. Throughout the projects, the
same type of diagram notations. Network-topol- performances of the projects were tracked
ogy diagram notations were utilized to represent and accordingly the plans were updated.
the system architecture. • Eliciting system requirements: We
Military books and instructions were among performed a business-process-based re-
the basic resources, especially when domain ex- quirements-elicitation approach to define
perts had uncertainties and disagreements related software-intensive system requirements
to the concept of the processes. Throughout the (Demirörs et al., 2003). We determined user-
requirements-elicitation processes of Project level functional requirements for software
A and Project B, 15 and 9 military books and components of the systems, nonfunctional
guidelines related to the domain were utilized, system requirements, commercial off-the-
respectively.

Figure 3. Acquisition planning phase

turkish land forces command - Project office

Planning and managing eliciting system estimating software size, Preparing Preparing
acquisition Planning requirements system Development statement of Work for request for Proposal
Project effort and cost system Development

Project Plan system Project statement of request for

requirements estimates Work Proposal

m etu informatics institute - Project offic e

Process Document Process flow inputs/outputs Participates in

Precontract Challenges

shelf (COTS) product requirements, and The Requirements-Elicitation Process

hardware and telecommunication infra- The requirements-elicitation process based
structure requirements for both systems. on business process modeling we implemented
• Estimating software size, and system de- is depicted in Figure 4. Since the projects were
velopment effort and cost: We estimated military, the C4ISR architecture framework
the sizes of the software components of the (DoD Architecture Working Group, 1997) also
systems based on the functional software influenced us while defining this process.
requirements elicited in the previous step and The process includes four technical subpro-
using the Mark II function points analysis cesses, namely, concept exploration, analysis, and
method (Demirörs & Gencel, 2004). Effort modeling of current business processes; model-
and cost for the system development were ing of the target system; system requirements
also estimated by using software size esti- definition; and the quality assurance activities
mates. of verification and validation.
• Preparing statement of work for system The C4ISR architecture framework provides
development: We described system and the rules, guidance, and product descriptions for
software development life cycles, which are developing and presenting architecture descrip-
to be applied by the supplier organizations, tions of the systems to be acquired. As discussed
together with engineering process steps in the background studies, there are three major
and their outputs. We used IEEE’s system views that logically combine to describe the ar-
and software engineering standards (IEEE, chitecture: the operational, systems, and technical
1998a, 1998c) and recommended practices views. In this process, we utilized an integrated
as a reference in describing the templates description. Table 3 demonstrates the mapping
for process outputs. between the C4ISR architecture views and the
• Preparing RFP: We gathered the system re- requirements-elicitation process we defined.
quirements, system development estimates, The practices were performed by the col-
and statement of work. Then we integrated laboration of the customer and contractor project
these with the acquisition regulations of the offices. The detailed steps of the requirements-
TLFC in the form of an RFP. We included elicitation process and, if any, the differences in
the acquisition schedule, management prac- the subprocesses of Project A and Project B are
tices, and deliverables; quality requirements explained in the following subsections.
for system and software development and
management processes; quality assurance Concept Exploration
requirements for the deliverables; and
qualifications of the system and software This process was performed to get knowledge
development and management staff in the about the domain and review previous documents.
RFP to be issued for the system develop- All the material, including military procedures,
ment. forms and guidelines, and related class notes, were
gathered. Those resources helped in the require-
In this study, we focused on the details of ments-elicitation process several times, such as
the two challenging processes of the precontract in describing business processes and developing
phase of software-intensive system acquisition: target conceptual and detailed design in the direc-
system requirements elicitation and software size tion of the business goals. The following activities
estimation processes. were performed to execute this process.

Precontract Challenges

Figure 4. Requirements-elicitation process

turkish land forces command - Project office

concept analysis and modeling of system

exploration current Business modeling the requirements
Processes v2 target v1 v2 Definition v1 v2
system

concept current target system

Documents Business Business requirements
Process Process
models models

metu informatics institute - Project office

v1: verificati,on
Process Document qa activity v2: validation Process flow inputs/outputs

• Concept documents for the projects had been Analysis and Modeling of Current
prepared prior to requirements-elici•tation Business Processes
contracts. The METU Project Office re-
viewed the concept documents in order to This process was performed to understand the
have a general understanding of the domain. current business processes with their business
The documents had mostly addressed flows, inputs, outputs, and responsible bodies,
current hardware and telecommunication as shown in Figure 5. Current business processes
infrastructure at an introductory level, so were modeled using the ARIS tool set, which
it was just used as a means to start domain provided the foundation for modeling the target
analysis. business processes. The activities performed to
• The TLFC Project Office attended sev- execute this process are discussed in the follow-
eral orientation meetings together with the ing paragraphs.
METU Project Office for the staff to get to
know each other, and it provided short pre- • Identifying organizational units of busi-
sentations about the domain and answered ness domain: People to be interviewed were
the questions of the METU Project Office. determined by the METU Project Office
During the life cycle, orientation meetings together with the TLFC Project Office. Then,
for the domain experts and representatives a schedule was made to hold these inter-
of the organizational units who will use the views. As a result of these interviews, the
system were also held. organizational units of the business domain
• Written resources such as books, instruc- were identified, and organization charts were
tions, forms, and reports were asked for by generated. In addition, the key stakeholders
the METU Project Office and provided by were identified and the stakeholder represen-
the TLFC Project Office when available. tatives, who would join the workgroups for

0
Precontract Challenges

Table 3. Mapping between requirements-elicitation process and C4ISR architecture views

Operational System Technical

Subprocess Name
View View View
Concept exploration √ √ √
Analysis and modeling of current business
√
processes
Modeling of the target system
Reviewing and enhancing current busi-
√
ness processes
Updating the data dictionary √
Identifying business processes that
√ √
need IT support
Identifying software components to
√
provide IT support
Assigning software components to busi-
√
ness processes that need IT support

Identifying hardware components √ √

Assigning software components to
√
hardware components
Identifying data transmission
√
requirements
Identifying telecommunication
√ √
infrastructure
Identifying system architecture √ √

System requirements definition √ √ √

determining the key business processes as analyzed the key business processes, and
well as analyzing and modeling the current further decomposed them into business sub-
business processes, were determined. processes. Decomposition was performed
• Identifying key business processes of up to several levels when required until the
organizational units: This study was the lowest level subprocesses did not involve any
foundation for more detailed business pro- nesting and had a simple flow of execution
cess analysis. Key business processes were from beginning to the end.
determined after a study of the workgroup. • Modeling lowest level business subpro-
Further modeling activities were based on cesses: Each lowest level business sub-
these identified key business processes. process model was constructed in terms
Then, the models of the key business proof processes, flow of processes, inputs and
cesses were produced. outputs of the processes, and the respon-
• Decomposing key business processes into sible bodies of the processes, which are all
business subprocesses: The workgroup supported by eEPC notation. Uncertainties

Precontract Challenges

Figure 5. Analysis and modeling of current business processes

and disagreements about the execution of • Creating data dictionary for business do-
the processes were discussed by domain main: Concepts and entities of the business
experts and stakeholder representatives, domain that were introduced during current
and resolved by referring to domain books business process modeling were described
and instructions where available. Ease of in a data dictionary that formed a basis for
understanding of the eEPC notation resulted developing a common language between the
in extensive contribution and feedback from TLFC Project Office and the METU Project
the customer. Feedback, including change Office. The entities put into the dictionary
requests taken at anytime, was reflected to included forms, reports, and instructions
the models by the staff of the METU Project related to the business domain.
Office.

Precontract Challenges

Modeling of the Target System be automated with a need for a workflow

management system to provide coordina-
This process was performed to describe the IT- tion. Some processes required decisions on
oriented target system, as depicted in Figure 6. intelligence in IT support such as decision-
In modeling process enhancements, defining support systems. The customer decided to
hardware and software components, and con- evaluate such requirements based on price
structing target business process models, we also and benefits to be detailed and suggested by
used the ARIS tool set. Target business process the supplier.
models provided the foundation for defining • Identifying software components to pro-
system requirements. The activities performed vide IT support: While identifying business
to execute this process are discussed in the fol- processes that need IT support, we had a
lowing paragraphs. clear insight on which software components
should cooperate in providing that support.
• Reviewing and enhancing current busi- Therefore, the software components of the
ness processes: Current business process system were determined, and high-level
models were revisited from the beginning relationships among these components were
for possible enhancements, or even redesign, set. The software components that are not
considering the business goals and needs. specific to the domain were determined basi-
The weaknesses, bottlenecks, and deficien- cally as the documents management system,
cies of the current business processes were reports management system, workflow man-
determined and removed wherever possible. agement system, geographical information
However, enhancements were limited due to system, and messaging system. Since the
strict policies and regulations of the military. projects had system contexts, hardware-
In addition, the TLFC Project Office gave interface and system-interface software
up some enhancements because of the long components were also included in the set.
approval cycles in the organization. • Assigning software components to busi-
• Updating the data dictionary: The current ness processes that need IT support: Dur-
data dictionary was updated to reflect the ing the two previous activities, we informally
changes in the concepts and entities of the performed the mapping between business
business domain, which appeared during the processes and software components. This
enhancement of current business process activity was performed differently in Project
models and construction of target business A and Project B.
process models. The data dictionary was
extended to include new concepts and enti- In Project A, the models of target business
ties whenever required. processes did not include the identification of
• Identifying business processes that need the IS infrastructure within the business process
IT support: Enhanced business process models since these were reflected in the system
models were reviewed to identify the busi- breakdown structure (SBS) that was prepared
ness processes that need IT support. It was simultaneously. At the end of this study, gaining
decided that all standard manual operations satisfactory domain knowledge, we could asso-
such as document recording and reporting ciate the system architecture with the business
were to be automated. Since the systems process models, which enabled us to determine
have strong interrelations with other sys- the requirements of the target system for each
tems, management operations were to organizational unit separately at a later stage.

Precontract Challenges

Figure 6. Modeling of the target system

Precontract Challenges

In Project B, we performed a careful analysis models, the data transmission requirements

on current business process models to transform were determined based on the data exchange
their organization-based structure into a system- requirements between organizational units
based structure. This was performed to obtain a as well as between other C4ISR subsystems.
unique and generic set of target business process The sizes and frequencies of transmissions
models for all organizational units rather than hav- determined the requirements related to
ing several sets of target business process models bandwidth and speed.
for different organizational units, which overlap • Identifying telecommunication infra-
in functionality. Simultaneously, we formalized structure: The telecommunication infra-
our insight on the relationships between business structures of the systems were determined
processes and supporting IT components by put- using the access diagrams showing the
ting corresponding assignments on current busi- hardware components, organizational units,
ness process models as to construct a unique set and data transmission requirements. The
of system-based target business process models. existing telecommunication infrastructure,
We connected each business process needing IT as well as new ones, and the related con-
support to the corresponding software to provide straints were analyzed. Then, the customer
that support while constructing target business evaluated the required bandwidth and speed
process models. This notation, which included requirements based on the performance of
business processes, software components, and the transmission media that can be supplied
their connections, formed a basis for defining and on the importance of the data to be
user-level functional system requirements at a transmitted. Accordingly, some decisions
later stage. were made. Due to some limitations on
basic technology supportability and orga-
• Identifying hardware components: nizational rules governing the implementa-
Hardware components of the system were tion of system elements, it was decided that
identified based on target business process some processes of the organizational units
models and the organization chart. Orga- were not to be automated. In addition, it
nizational units were analyzed to help us was decided that some data were to be sent
decide on hardware support. As a result of manually as in the current system.
this activity, hardware components and their • Identifying system architecture: This ac-
high-level relations were modeled by using tivity was simply the integration of the work
access diagrams for each organizational done up to this point. Software components
unit. In addition, the existing and the needed assigned to hardware components together
hardware were also depicted. with the telecommunication infrastructure
• Assigning software components to hard- constituted the system architecture. As a
ware components: The software compo- result of this activity, system architecture
nents to run on each hardware component diagrams, showing all hardware components
were identified. An access diagram, show- and software components at each organi-
ing the software components assigned to zational unit, and the telecommunication
hardware components with the domain user infrastructure among these units, were con-
types, was constructed for each organiza- structed. The system architecture diagram
tional unit. was constructed by using network-topology
• Identifying data transmission require- diagram type.
ments: By using the target business process

Precontract Challenges

System Requirements Definition In Project B, the requirements were generated

automatically from target business process models
This process was performed to generate the target using the KAOS tool (Su, 2004) developed specifi-
systems’ software, hardware, and telecommuni- cally to generate requirements in natural language
cation requirements, as shown in Figure 7. The from target business process models. We derived
activities performed to execute this process are and used a special notation while modeling target
discussed below. business processes, and generated a generic target
system model that involves all the processes of
• Preparing SBS: Using the information each organizational unit. The tool runs on that
on system architecture diagrams, an SBS notation to generate user-level functional system
including all IT components of the systems requirements with respect to system components
to the fifth level was prepared. assigned to each target process. After modeling
• Defining user-level functional system target business processes using the notation’s
requirements: User-level functional re- conventions at required detail, the tool benefited
quirements of the target system were elicited in time saving for requirements definition. The
based on processes, flow of processes, inputs, number of business process models was 295 and
outputs, and actors defined in the target they are instantiated by the KAOS tool; in total,
business process models. As we mentioned 1,270 user-level functional requirements were
previously, we generated the requirements generated. The generation took 30 minutes. On
manually from target business process the other hand, results showed that 517 generated
models in Project A, and automatically from requirements (40.7% of generated requirements)
target business process models using a tool required corrections, and they were corrected in
in Project B. 3.5 person-days.

Since the requirements were generated manu-

ally in Project A, a small organizational unit of the • Defining COTS requirements: COTS
domain (approximately 1/10 of the model system product requirements of the target systems
in terms of size) was selected as pilot, and its user- were largely determined based on the re-
level functional requirements were defined as a quirements of the Turkish Armed Forces,
trial by the whole workgroup. The experience of and many of the regarding make and buy
the pilot study was then used in planning the rest of decisions and cost analyses (Aslan, 2002)
the user-level functional-requirements-elicitation were skipped due to this reason. The types
efforts. Three teams were formed to define the of software components that were identified
functional system requirements for each organi- as COTS products included the operating
zational unit and worked in parallel for the rest system, database management system,
of the process, which benefited the workgroup in office programs, document management
defining a standard way of working and in time system, report management system, work-
saving. By using 210 business process models, the flow management system, and geographical
manual generation of the 10092 FP requirements information system.
document took 40 person-days. The functional • Defining nonfunctional system require-
system requirements filled about 400 pages, and ments: Nonfunctional system requirements
there were about 1,380 basic requirements, each were determined by analyzing implicit
composed of three subrequirements on average requirements of the target business process
(e.g., 1a, 1b, 1c). models as well as by discussing special

Precontract Challenges

Figure 7. System requirements definition

requirements and likely weaknesses, bottle- analyzing access restrictions of the actors to
necks, and deficiencies of the systems with processes, and process inputs and outputs.
the customer. ISO/IEC 9126 (ISO/IEC, 1991) Subjects and objects of the model systems
was used as a guideline while determining were identified and subject-object authoriza-
nonfunctional requirements. Function un- tion matrices were constructed.
derstandability, inherent availability, mean • Defining hardware and telecommunica-
time between breakdowns, mean time to tions infrastructure requirements: SBS,
repair, and the failure resolution rate were which included all IT components of the
defined and assigned target values for both systems and system architecture diagrams,
systems. In addition, security requirements showing IT components at each organi-
of the target systems were determined by zational unit, and the telecommunication

Precontract Challenges

infrastructure among these units, was used utilized to make software size estimations are
as a basis for the detail requirements of these given in Table 4.
components. Since the applications were Since the estimation method and the proce-
military, there were a lot of constraints put dure we followed were very similar in both of the
by rules and regulations while specifying the projects, we will only discuss the size estimation
hardware and telecommunication require- procedure of Project B in this chapter.
ments. In Project B, the user-level functional system
• Integrating system requirements: The requirements were generated from business
requirements for all system components, process models with respect to 11 different sub-
including functional and nonfunctional systems as shown in Table 5. Original names of
system requirements, COTS requirements, the subsystems and modules in the project are not
and hardware and telecommunications in- given due to security constraints.
frastructure requirements, were integrated While making the software size estimation,
at this activity to construct overall system some difficulties were faced as the Mark II FP
requirements. System requirements gener- method is designed to estimate size after the
ated as the end product of the requirements- software requirements specification is complete.
elicitation process were included in the The first one is the differences in the abstraction
RFP. levels of the system-level functional requirements.
Therefore, some assumptions on the kind of
software size estimation transactions and the number of data entity types
(DETs) had to be made while making the Mark
The size of the projects to be acquired was II FP estimation. The percentage of such transac-
estimated by using the Mark II FP method tions was about 60% overall. The accuracy of the
(United Kingdom Software Metrics Association method decreases as the abstraction level of the
[UKSMA], 1998). requirements gets higher. Another difficulty was
For both cases, as the user-level functional that, due to insufficient details of some require-
system requirements were generated from busi- ments, the method could not be used to size these
ness process models with respect to different requirements at all. Thus, we had to use expert
subsystems, the size of each subsystem was es- opinion to estimate their sizes. The percentage
timated and then summed to compute the sizes of the number of such requirements overall was
of the whole development projects. 2.2%, and the percentage size of the subsystems
The size estimates of the software components involving these requirements in the whole project
of the systems to be contracted for the develop- was found to be 14.1%.
ment projects, the number of staff, and the effort

Table 4. Summary of the estimations, effort, and number of staff used for estimations

Effort Needed to Make Estimated

Number of Staff
Project Size Estimation Size
(part time)
(person-hours) (MkII FP)

A 54 1 10,092
B 131 4 25,454

Precontract Challenges

Table 5. Size estimates of subsystems by Mark II

Subsystem Module Unadjusted FP

A1 2,886.64
A A2 4,882.10
A3 9,281.55
B 8.48
C 185.34
D 3,344.96
E 878.31
F 386.66
G 1,000.00
H 1,000.00
I 1,000.00
J 200.00
K 400.00
Total Project Size 25,454.04

lessons learneD to the required formalization in the organization,

the business process models created an excellent
Identifying domain experts and reaching them as baseline to discuss issues related to the integra-
scheduled were among the most critical tasks. Ori- tion of projects. The process models enabled
entation meetings at the start of the projects, and the representatives of other C4ISR projects to
regular progress meetings between the METU and visualize the whole picture in a short time and
TLFC project offices enabled effective commu- create an early consensus on how the data would
nication throughout the projects. These meetings be exchanged among these projects.
provided the opportunity to discuss conflicting Currently, the systems for which we com-
issues, to notify demands on resources, and to pleted acquisition planning have entered into
replan the work under progress. the development phase. The TLFC has decided
Modeling existing business processes took to integrate the development of Projects A and B
significant time and almost half of the total project since corresponding systems are complementary
effort, but other than being a baseline for require- and their requirements are redundant. The TLFC
ments specification, it helped the stakeholders has suspended the release of the RFP, and decided
to identify the bottlenecks and the improvement to complete the system and software requirements
points needed in the business processes. specification stages on its own, specifically by
The domains of Project A and Project B are assigning responsibility to one of its departments
different but complementary with a high degree that develops in-house systems and software.
of data exchange requirements. In addition, both The development group has used elicited system
Project A and Project B have numerous integration requirements as a basis for their planning as
points with seven other C4ISR subsystem projects well as for requirements specification. They are
of the TLFC. Therefore, during the execution of currently generating use-case specifications and
Project B, we organized coordination meetings scenarios based on user-level functional system
with other TLFC C4ISR subsystems’ project requirements.
committees. Although this task was difficult due

Precontract Challenges

Recently, the TLFC has contracted a new ating target business processes. Process-oriented
project to define integration requirements of all analysis also enabled extensive understanding of
nine C4ISR subsystems including Systems A and the domain. The determination of IS-supported
B using this approach. functions, new information flows, and changes in
Another challenging task was the orientation existing workflows were the results of the target
of domain experts for business process modeling. business modeling. Indeed, current and target
Domain experts needed assistance to think in business modeling were performed together to
terms of business processes, and to identify and some extent because bottlenecks, deficiencies,
decompose the key business processes using spe- and problems were already captured in current
cific notations. Almost all domain knowledge was business modeling. This activity was performed
documented in books, instructions, guidelines, differently in Project A and Project B. In Project
or reports. The existence of written resources A, the models of target business processes did
helped in understanding the context of the do- not include identification of the IS infrastructure
main in detail, and speeded up the orientation of within the business process models. Gaining
consultants to the domain. However, identifying satisfactory domain knowledge, we could asso-
and modeling business processes by the TLFC ciate the system architecture with the business
Project Office following these resources were process models and determine the requirements
stringent since the domain knowledge is captured of the target system. In Project B, we constructed
in terms of business work products rather than target business process models in order to gen-
business processes in these resources. In other erate user-level functional system requirements
words, there was confusion between preparing automatically.
a domain document and executing the processes During the requirements-elicitation process,
behind it. For example, documenting the sections we generated functional requirements manually
of a domain report actually requires executing from target business process models in Project A,
the steps of a business process that generates that and automatically from target business process
report. This confusion between business work models by using the KAOS Tool (Su, 2004) in
products and business processes slowed down Project B. For Project A, the size of which was
the modeling from time to time, and frequently estimated to be 10,092 Mark II FP, the manual
required elaboration of what business process generation of the requirements document took
modeling is. 2 person-months. After modeling target busi-
In both projects, orientation was provided via ness processes using the notation’s conventions
meetings and frequent discussions. However, at required detail, the KAOS tool generated the
regular formal training sessions might have been functional requirements of Project B, which was
better to save overall effort in such projects. Since 25,454 Mark II FP in size, in 30 minutes. Thus,
the TLFC Project Office had been staffed by the planning of the target system modeling and
domain experts, we needed to assist them in the functional-requirements-generation processes
details of business process modeling and system was made according to whether the require-
requirements elicitation throughout the projects. ments generation would be made manually or
This assistance was one of the most important automatically.
indicators of success, and was therefore provided Readers will notice that the ratio between the
with great care as to proceed within context but number of user-level functional system require-
not to restrict the expectations of the domain. ments and software size in Mark II FP in Project
Modeling and analyzing current business A is quite different from that in Project B. That
processes provided considerable guidance for cre- is, 10,092 Mark II FP were estimated from 1,380

0
Precontract Challenges

requirements in Project A, whereas 25,454 Mark since the number of functionalities, which each re-
II FP were estimated from 1,270 requirements quirement constitutes, would be very different.
in Project B. There were two reasons for this: During both projects, we maintained a project
The first one lies in the difference between the effort metric database. The team members entered
methods used while generating target business data related to the type of work, activity name, and
process models as a basis for requirements elicita- effort attributes into this database. This helped to
tion, and the second reason was the difference in reflect more realistic figures to the management
abstraction levels of the generated requirements plan as the projects progressed since we utilized
of the projects. this database to estimate the effort needed for
In Project A, we kept the organization-based modeling the remaining business processes.
structure of current business process models while
constructing target business process models, and
as a result, we had different sets of functional conclusion
requirements for different organizational units.
However, these sets had overlapping requirements The establishment and transformation of need
among organizational units due to similarities in from concept to system requirements can be
functionality, causing a greater number of require- supported by means of notations and tools devel-
ments. Among the organizational units, 1,156 oped for business processes reengineering. The
requirements of 1,380 were overlapping, which process-oriented approach not only helped the
constitute about 85% of the total requirements; organization to see the big picture, but it enabled
these overlaps in the requirements were handled us to focus on the required improvements to be
while performing software size estimation for able to utilize the acquired system as well.
Project A. By using this experience gained from Although business process modeling requires
Project A, in Project B, we transformed the or- significant effort, it brings various advantages. For
ganization-based structure of current business example, the automatic generation of software
process models into a system-based structure functional requirements as well as the consistent
while constructing target business process models. application of software size estimation meth-
As a result, we obtained a unique and generic set odologies was possible in Project B: Both have
of target business process models, and therefore great value, especially for large and innovative
user-level functional system requirements that projects. In addition, we observed that business
had no overlaps. process modeling is an effective way to explicitly
This resulted in a greater number of user-level define the requirements of a software system
functional requirements in Project A than in while creating visibility and consensus among
Project B, although the real number of function- different stakeholders of other systems that are
alities required were not so. This means that if to be integrated with each other.
the requirements had been organized in a system- We implemented our approach in two systems
structure-based manner, Project A would have to elicit the requirements of activity-based opera-
only 224 requirements. tions of two organizational units. However, not
Another point is that the abstraction levels of all technology solutions, such as highly graphi-
target business processes were higher in Project cal systems, embedded systems, and real-time
A than in Project B. If both projects had used a systems, are inherently activity based. We have
system-structure-based organization, the number no observation on the usability of our approach
of requirements would not have been comparable for such systems.

Precontract Challenges

There is no doubt that predevelopment pro- Demirörs, O., Demirörs, E., & Tarhan, A. (2001).
cesses need further research studies for the de- Managing instructional software acquisition.
velopment of systematic approaches (Demirörs, Software Process Improvement and Practice
Demirörs, & Tarhan, 2001). Specifically, exten- Journal, 6, 189-203.
sive research on predevelopment methodologies
Demirörs, O., & Gencel, Ç. (2004). A compari-
including processes, notations, and heuristics
son of size estimation techniques applied early
as well as tools and techniques to support such
in the life cycle. In Lecture notes in computer
methodologies are required. These methodologies
science: Vol. Proceedings of the European Soft-
should also link the development phases with the
ware Process Improvement Conference (p. 184).
work products of the predevelopment phases.
Springer.
Demirörs, O., Gencel, Ç., & Tarhan, A. (2003). Uti-
references lizing business process models for requirements
elicitation. Proceedings of the 29th Euromicro
Aslan, E. (2002). A COTS-software require- Conference (pp. 409-412).
ments elicitation method from business process
Demirörs, O., Gencel, Ç., & Tarhan, A. (2006).
models. Unpublished master’s thesis, Department
Challenges of acquisition planning. Proceedings
of Information Systems, Informatics Institute of
of the 32nd Euromicro Conference on Software
the Middle East Technical University, Ankara,
and Advanced Applications (EUROMICRO 2006)
Turkey.
(pp. 256-263). IEEE CS Press.
Capability Maturity Model Integration (CMMI)
Department of Defense (DoD) Architecture Work-
Product Team. (2001). CMMI-SE/SW/IPPD, v.1.1.
ing Group. (1997). C4ISR architecture framework,
CMMISM for systems engineering, software en-
version 2.0.
gineering, and integrated product and process
development: Staged representation (Tech. Rep. Department of Defense (DoD) General Services
No. CMU/SEI-2002-TR-004). Carnegie Mellon Administration. (2001). Federal acquisition regu-
University, Software Engineering Institute. lation.
Cooper, J., & Fisher, M. (2002). Software acqui- Hammer, M., & Champy, J. A. (2001). Reengi-
sition capability maturity model (SA-CMM®) neering the corporation: A manifesto for business
v.1.03 (Tech. Rep. No. CMU/SEI-2002-TR-010). revolution. Harperbusiness.
Carnegie Mellon University, Software Engineer-
IEEE. (1998a). IEEE software engineering stan-
ing Institute.
dards.
Cummnis, F. A. (2002). Enterprise integration:
IEEE. (1998b). IEEE Std. 1062: IEEE recom-
An architecture for enterprise application and
mended practice for software acquisition. New
systems integration. John Wiley & Sons.
York.
Davenport, T. (1993). Process innovation: Reen-
IEEE. (1998c). IEEE Std. 1220: IEEE standard
gineering work through information technology.
for application and management of the system
Ernst & Young.
engineering process.
Demirörs, O., Demirörs, E., Tanik, M. M., Cooke,
ISO/IEC. (1991). ISO/IEC 9126: Information
D., Gates, A., & Krämer, B. (1996). Languages for
technology. Software product evaluation: Quality
the specification of software. Journal of Systems
characteristics and guidelines for their use.
Software, 32, 269-308.

Precontract Challenges

Scheer, A. G. (2003). ARIS toolset, version 6.2.

Scheer, A. W. (Ed.). (1994). Business process
engineering: Reference models for industrial
enterprises. Berlin, Germany: Springer.
Su, O. (2004). Business process modeling based
computer-aided software functional require-
ments generation. Unpublished master’s thesis,
Department of Information Systems, Informatics
Institute of the Middle East Technical University,
Ankara, Turkey.
Turetken, O., Su, O., & Demirörs, O. (2004).
Automating software requirements generation
from business process models. Proceedings of the
First Conference on the Principles of Software
Engineering.
United Kingdom Software Metrics Association
(UKSMA). (1998). MkII function point analysis
counting practices manual, v.1.3.1.
Wiegers, K. E. (1999). Software requirements.
Microsoft Press.
Yourdon, E. (2000). Managing software require-
ments. Addison Wesley Publishing Company.

Section II
Business Process Management

Chapter V
Process Integration Through
Hierarchical Decomposition
Ayesha Manzer
Middle East Technical University, Turkey

Ali Dogru
Middle East Technical University, Turkey

aBstract

A mechanism is presented to construct an enterprise process by integrating component processes. This

approach supports the formation of value-added chains based on process models. Process represen-
tations in logical as well as physical levels are offered in a hierarchy as a graphical tool to support
process integration. An enterprise represents a complex process that needs to be constructed within an
engineering approach. Such construction is a matter of integration if component processes are made
available by smaller enterprises. Process integration is supported by task-system formalism that may
especially prove useful in the analysis of the preservation of process attributes during integration.
Approaches using the decomposition of the problem definition have matured for various engineering
disciplines in an effort to match definition pieces with previously built subsolutions. Among these dis-
ciplines, the techniques used in software engineering are exploited as this domain is closer to business
process construction than the others.

introDuction the business will also require modern technolo-

gies. Developing rapidly, software engineering
Businesses are complex organizations, therefore has become the closest discipline to enterprise
their formation requires some scientific guidance. engineering for the study of processes, the logical
Similar to the construction of any other structure, representation of any structure integration, and
the construction of an enterprise is expected to modeling. Similar leverage has been exploited
benefit from engineering practices. Similar to in other disciplines, but software technologies
the role of information technologies in shaping have used them most recently and effectively. In
the way we conduct our operations, structuring this chapter, some mechanisms used in compo-

Copyright © 2007, IGI Global, distributing in print or electronic forms without written permission of IGI Global is prohibited.
Process Integration Through Hierarchical Decomposition

nent-oriented software integration are adapted (Madachy & Boehm, 2006). Rather than designing
to enterprise engineering, namely, hierarchical the process from scratch, it is always faster and
decomposition and component integration. more reliable to reuse what was invented and tested
We will benefit from engineering practices, and before. Our goal is to utilize a number of existing
such rigorous techniques are crucial in achieving component processes in a smart integration for
dependable outcomes. However, we also need constructing the next enterprise-level process.
simplicity and understandability, especially Agility can be achieved through component-pro-
when it is a matter of preserving our intellectual cess replacement. Wherever a modification need
control over the business (Laguna & Marklund, arises in the system, one corresponding process
2004) through a mind not necessarily that of can be replaced with another that might satisfy the
an engineer’s. It is a fact that complex artefacts need. This replaceable part may correspond to a
require interdisciplinary teams. In other words, single process or to a set of neighboring processes
the big picture should not be neglected while in the hierarchy model.
low-level details and formalisms of engineering We treat enterprise engineering as a design
mathematics are accounted for. There is a rac- problem. Being applicable to any design area,
ing condition here; we want to understand the hierarchical decomposition has been proposed as
enterprise easily, and yet the enterprise needs to the fundamental algorithm (Simon, 1969). Applied
be engineered rigorously. to business processes, this means an enterprise
Another complicating factor is the need for engineer can think of the organization as a huge
agility. Our organizations, like our production process that can be decomposed into component
infrastructure, need to be flexible and dynamic processes. Assuming a top-down approach to
to meet the rapidly changing market demands designing a new process, as an initial step the

Figure 1. Decomposition in a hierarchy

System
abstraction
Abstraction level

Abstract Abstract
component component

Abstract Abstract Abstract

component component component

component component component component

Process Integration Through Hierarchical Decomposition

whole operation (system) can be modeled as an cently, the emergence of software-component

abstract process. Likewise, the immediate parts technologies has enabled the application of such
of the whole, the smaller processes, can be repre- mechanisms to practical and efficient engineering.
sented as logical entities in the decomposition. At Traditional approaches offer modeling techniques
the outset, we want to visualize the relative posi- for design that present various cross sections of
tions and perhaps interactions of the component the system with respect to different concerns.
processes in the system. Eventually, when suf- The outcome is a set of models that would not
ficient decomposition is done, the decomposition converge to a real system unless the designers
model will come closer to real processes: Process have the experience to combine the divergent
models that represent real business processes will information. Data, function, and other conceptual
take place at the bottom of the hierarchy. Figure dimensions were accommodated by such models.
1 depicts the decomposition model. For human cognition, structure is the best choice
Component processes are represented as boxes for a decomposition concern. Rather than other
that connect to others (integration) through links concepts, components, being structural units,
that carry information about material flow, re- facilitate the divide-and-conquer paradigm based
source allocation, and synchronization. A box can on the structure dimension. Structure corresponds
be modeled by any existing modeling technique to a chunk of software code that can contain other
that helps in ordering the activities, assigning constituents such as data, function, control, and
resources to activities, and organizing material so forth.
and product flows. In other words, a process in A purely component-oriented approach has
the system will be presented as an activity inside been proposed (Dogru & Tanik, 2003) that sug-
a process. This view not only allows for process gests starting with a decomposition of the problem
abstraction, that is, hiding the information inter- definition. The goal is to achieve a software ap-
nal to a process and viewing it as a black box so plication without having to develop a single line
that the big picture is easier to understand, but of new code. Rather, locating and integrating ex-
also, in cases of too many processes, it becomes isting components is the suggested methodology.
possible to understand the system by looking at This revolutionary thought is not an unfamiliar
it one region at a time. The region of focus could one: Other engineering disciplines have already
correspond to the whole enterprise when it is at discovered an attitude that is against reinventing
the top of the hierarchy, or to any other local con- the wheel. This approach is also analogous to
text. In the following sections, information about the outsourcing avenue to producing a complex
the related mechanisms in software engineering product or service.
and their adaptation to enterprise engineering A designer decomposes the system definition
will be presented with a process integration into abstract units that, preferably, correspond to
example. Also, a task-systems-based formal components that are anticipated to exist. A good
representation is included so that some process decomposition will present units that completely
attributes can be analyzed for their preservation correspond to existing components so that mini-
after integration. mal modification or development is necessary. We
want to develop software by integration rather than
similar experience: code writing. The software market is rapidly mov-
Decomposing software ing in this direction; component-ware and related
methodologies are maturing day by day.
Hierarchy and decomposition have always been
important issues in software development. Re-

Process Integration Through Hierarchical Decomposition

Process modeling definition, and for every different hospital, a tai-

lored software version will be created with ease,
As a recent and rapidly developing field, software even without having to compile the code.
engineering has already experienced different Recently, related concepts have evolved into
process approaches for developing software. Ex- the definition of businesses using newer languages
posure to such a variety in a short time, combined and tools. Also, services available as software
with the versatile infrastructure, has helped this operations that can be employed over the Internet
discipline to offer modeling mechanisms that have evolved into smoothly operating Web ser-
have transcended the software domain. A typi- vices. Business process definition languages are
cal process model represents tasks and material currently becoming capable of working with Web
or product flows in and out of these tasks, and services. As a result, the definition and enactment
resources can be modeled and assigned to tasks. of a new business process are available to users
Advanced tools allow simulations on these mod- of the correct software tool set.
els to run and expose bottlenecks in the business The business process execution language
conduct. (BPEL; Juric, Mathew, & Sarang, 2004) provides
Humphrey (1990) described the process as a language for the formal specification of business
“the set of tools, methods, and practices we use processes, and its newer form for Web services
to produce a software product.” We model the (BPEL4WS) also provides interaction protocols.
processes as an ordered set of tasks to conduct In this way, business transactions are enabled
a manufacturing or service operation. The pro- through the interaction protocols of the Web
cess concept soon became an important issue for services. This technology can facilitate process
enterprises to investigate. A new consulting field integration.
emerged in the form of business process reen- Business process modeling notation (BPMN,
gineering (BPR; Hammer & Champy, 1994). A 2004) is another graphical modeling framework
typical reengineering operation started with the that targets technical as well as business-oriented
modeling of the existing practices of an enterprise. users. With its abstract and formal mechanisms,
The experienced consultants could then improvise this tool supports interaction among businesses
a “to be” model for the enterprise that would most and also among different modeling media.
probably incorporate an important IT component.
Finally, the prescription to convert the operation
to the new process was coined. Substantial sav- Process DecomPosition
ings have resulted by applying BPR, and the topic moDel
enjoyed a sustained demand.
Workflow systems have also developed as a We view a process as a set of tasks ordered to ac-
new terminology. Process modeling was a close complish a goal (Curtis, Kellner, & Over, 1992).
concept, but the workflow concept has rap- There have been various approaches to modeling
idly attained the meaning of “executable process processes (Acuna & Juristo, 2005). The funda-
model.” Workflow engines are available today as mental ideas in our framework are applicable to a
components to integrate with business software. variety of modeling techniques. That idea is based
Workflow-engine-based hospital automation soft- on a recursive definition of a process: A process
ware, for example, will accept the definition of the can be made of smaller processes. An activity is
process in a specific hospital through a graphical traditionally regarded as a unit-processing element
user interface. Without having to develop any inside a process. Actually, in our perspective, an
further code, the system will adapt itself to this activity is defined similar to a process. However,

Process Integration Through Hierarchical Decomposition

Figure 2. Process modeling concepts in three dimensions

Infrastructure Activities

Communication

there is still a differentiation: If an activity is not intermediate products. Finally, communication

going to decompose to further tasks, we do not could be interpreted as any kind of information
call it a process. A process can be represented flow between activities and personnel, but, as a
by a complex model of its internals, but in our most important concept, this dimension is also
system of processes, it can be drawn as a black responsible for the ordering of the tasks. If syn-
box at logical levels in the hierarchy. Visualization chronization is required to signal the beginning or
of the interconnection of processes is important, the ending of the activities, it will be carried out
which reveals the synchronization and product through communication among the activities.
or material flows. To accommodate at least one
view to process modeling, we will present the abstraction
visual process modeling language (VPML; Dut-
ton, 1993) representation, which offers a generic Abstraction is a key concept in studying complex
foundation. The three dimensions of modeling structures. Our initial response to complexity is to
elements on which VPML is also based are de- employ divide-and-conquer tactics. Such division,
picted in Figure 2. however, should be guided in a hierarchy, meaning
The activity dimension is the main one, where that a group of the dividends should be represented
activities are basically situated. Unit actions that by a generalization concept. A generalized unit
make a process are usually modeled as activities. as a logical entity, hiding many enclosed details,
Sometimes these activities are composite; they allows us to concentrate on its relative position
are explained through lower level activities. The inside the system. In other words, observing from
infrastructure dimension actually stands for ma- a higher point of view, we can ignore the internal
terial and products, besides resources that alone details, thus reducing the complexity in our cog-
are traditionally more representative of the infra- nition process to aid in the understanding of the
structure concept. Nevertheless, activities produce whole rather than being required to view at the
products that could be either the final product or same time the internals of all parts: The whole

Process Integration Through Hierarchical Decomposition

Figure 3. Abstract and actual process representations

Abstract
Process

Actual
Process

is prohibitively complex to study with all details The opposite concept to abstraction is refine-
considered simultaneously; it is relatively easier ment. In the decomposition hierarchy, higher
to understand a part alone. We can study a system levels are more abstract and lower levels are more
at two levels: (a) the whole without details, and (b) detailed. Enhancing the model toward lower levels
parts with details, one at a time. Thus, abstraction, corresponds to refinement. In a case where an
combined with a hierarchical decomposition of a existing set of processes were already acquired
complex structure, helps us to manage complex and it is desired to predict how a system would
systems. Here our system is the combined process work that will be constructed through their future
of an enterprise, and its parts are the lower level integration, a bottom-up hierarchy of abstractions
processes. To study the integration, we introduce can be built. Conversely, starting with the goal
abstract processes that represent more than one represented at the top, the hierarchy can be built
component process. top-down through decomposition and eventually
The system under construction is treated as an a set of refined processes will be modeled. The
abstract process until the integration of the com- proposed hierarchy model can be used both in the
ponent processes is finished. A process engineer understanding of existing complex processes, and
decomposes this whole process into lower level in the design of new complex processes. In this
logical processes. Each newly identified abstract chapter, mainly the latter goal is exploited.
process is investigated: Is it specific enough for an
existing process to correspond to it? If not, this Building the hierarchy model
abstraction will need to be divided further. When
all the abstract processes are covered by one real Our goal is to propose a structure for complex
process, the decomposition activity is terminated. process models. Structures are not required for the
For the processes to be integrated into the model, operation of a system. They are, however, crucial
material flows and synchronization links should in our understanding of a complex system. Models
be finalized. Actually, such relations among in general are tools for understanding a complex
processes can also be represented in the higher system. What to include and what to exclude in
(abstract) levels. We can start with representing a model are therefore important. At any point
interactions in abstraction, whose details in terms during the development, a designer should make
of flows and synchronization will be defined later careful decisions regarding the main concern
in the lower levels. Figure 3 shows the graphical for understandability and should determine the
representation of processes. degree of detail accordingly.

0
Process Integration Through Hierarchical Decomposition

Figure 4. Elements of a process hierarchy diagram

Abstract
Process composition

Actual Material
Process flow

We have mentioned the representation of a can be declared after completing the whole system
process. Besides activities, their ordering (syn- decomposition, but some information (context)
chronization), assigning resources, and flow may be forgotten after concentrating on different
of material and products are involved. A super parts of the design. Figure 4 depicts the hierarchy
process of integrated processes is also a process, diagram elements.
and therefore it should also address all the issues Actually, the mechanism exists in most process
besides the activity dimension. Our main concern modeling tools: The composite-activity notion is
is the ability to design such a process. The main usually included. A composite activity is made
view promoted by our approach is decomposition of other activities and a detailed process model
where the activities are the important players. can be drawn for it. However, the concept of
Nevertheless, other constituents of the model composite activities as an implicit representation
can be added to the hierarchy diagram. The only of hierarchy is not very indicative of the complex
danger here is to populate the diagram with dif- process structure. Such a structure is better visu-
ferent concerns and reduce understandability. alized when displayed as a tree.
We suggest leaving the usual process modeling
details to the internal modeling of our process
nodes that are the component processes. If other an eXamPle Process
concerns such as resource assignment can be construction
appropriately represented at high levels, a copy
of the hierarchy diagram can be maintained to In this section, a decomposition of a business
study different concerns. process is demonstrated through an example.
One important reminder is to establish the English Text Doctor (Tanik, 2001) as an existing
connections among the nodes during the decom- electronic enterprise is decomposed into logical
position: The time during which a higher level processes and then integration is demonstrated.
process is being divided into its parts is the best This organization offers help in the proofreading
time to declare connections among the parts. and correction of written documents. There is
Considerations about splitting a process will a customer interaction part of the business that
share a similar context with the interaction view receives new texts and, when edited, returns
concerning the split parts. Of course, connections them. Customers are billed based on the number

Process Integration Through Hierarchical Decomposition

of pages. The other part of the business is like the design continues with the effort to decompose the
back office: A list of proofreaders is maintained enterprise process into further components.
and the proofreaders receive jobs based on a Next, the customer interactions process is
circular order; documents are ordered and as- perceived to comprise two important constituents:
signed to proofreaders, and finalized documents the receive and sell operations. We realize that
are collected and directed to the customer. There the two newly introduced kinds of operations
are criteria for evaluating the proofreaders; timely are not sequentially joined. They are under the
delivery, for example, is a critical issue in the cost customer interactions abstraction only logically
of the service. because they both interact with the customer.
This organization seems to have two main Actually, receiving the documents and selling
processes: one for customer interaction and the processed documents, process-wise, are very
the other for the actual service production. The different operations. This is the use of abstrac-
enterprise engineer can start with the top-level tions: They do not necessarily correspond exactly
decomposition of the operation as customer and to the real processes but they help us organize
office processes. Predicting further component the model (understand the system). In this way,
processes to consider later to do the actual jobs, although process-wise they are not related, two
these top-level subprocesses are determined to subprocesses are organized at some proximity
be of abstract type. Figure 5 shows the initial in the structure because of a logical relation. At
decomposition outcome. Other relations among the actual processes level, the detail may prevent
the processes are ignored at this point. The most a designer from understanding the model. The
important tool offered to the enterprise engineer opportunity to break down the structure based
is the divide-and-conquer mechanism. It is im- on a logical concern is regarded as better from a
portant to organize the complex operations as designer’s point of view. Once constructed, the
clearly separated units. position of the component processes in the hier-
At this point in the design, customers and archy diagram is immaterial for the enactment of
the documents flowing to and from them could the integrated process.
be entered in the model. The main concern is to Continuing with the decomposition, the de-
visualize the process structure, and for this prob- signer introduces the receive and sell processes.
lem, presenting the customer and the documents On the production side, there is a central process
are considered to be details at this phase. The that monitors the delivery from the proofreaders.

Figure 5. First-level decomposition of the process hierarchy

English Text Doctor

Customer Interactions Production

Process Integration Through Hierarchical Decomposition

Figure 6. Hierarchy diagram for English Text Doctor

English Text Doctor

Customer Interactions Production

Receive Sell H Hub

Actually, the incoming documents are tagged, hierarchy and a detailed process model—while
categorized, and then dispatched to proofreaders. refining the design to its maturity.
This central process is referred to as the hub pro-
cess. This simple enterprise is finally represented Component Processes
through three actual processes that are organized
under the abstract processes. Figure 6 shows Now that the skeleton of the system is defined, it
the final decomposition for the processes. The is time to concentrate on the functional modules.
fundamental operation is proofreading, which is This organization does not reveal any information
actually only an activity, and it is suggested that about what the receive, sell, and hub processes
it be allocated under the hub process. should look like. Their process models are to be
The top-down progress of the design would introduced next. Even if such models were existent,
naturally continue with forming the connections the hierarchy will still help in their integration and
among the bottom-level (actual) processes. Now related fine-tuning. Figure 7 depicts the process
that we have configured the structure that is the for the receive side of the organization.
part-whole relations, it is time to specify the Following the regular flow of the operation,
refinement. It is also possible to depart from the incoming documents are directed by the hub
hierarchy diagram and continue development with process. Figure 8 presents a model for the hub
the actual processes determined so far. This route operations. Here, documents are sorted, assigned
is easier for trivial processes, but any development IDs, and dispatched to proofreading groups and
activity in a complex enterprise would require the then to the customers.
preserving of the big picture through the hierarchy Finally, the sell side is where the edited docu-
diagram. It is possible to keep both views—the ment is directed to the customer. Figure 9 depicts
a process model for the sell side.

83
Process Integration Through Hierarchical Decomposition

Figure 7. A process model for the buy-side process of the English Text Doctor organization (Tanik,
2001)

customer

categorize pilot
documents interface
documents documents sent
from customer to interface

corrected documents
from proof reader

distribution of
documents

Figure 8. A process model for the central hub for English Text Doctor

Now it is time to integrate the identified ponent processes are where the integration should
component processes. Some modification to the start. The connection for these processes is more
individual processes is possible, hence distorting important than the internals of the processes. Such
the isolated views of the component processes in connections can be superimposed on the hierar-
the hierarchy diagram. Still, the hierarchy view chy diagram also. Next, the black-box views for
will remind us about where the components came the component processes will be considered and
from. Actually, the abstract versions of the com- their abstracted versions and connections will be

84
Process Integration Through Hierarchical Decomposition

Figure 9. The sell-side process model for English Text Doctor

from hub

determined. Once all the processes are integrated process. The logical organization of the hierar-
through connections, it is also possible to present chy, which assumes proximities for the processes
a combined process model for the system in detail. that are related to the customer, does not provide
For the complex processes that are the focus of the best layout in terms of the flow sequence of
this chapter, such a combined model will rarely operations. Positioning the hub between those
be used. The hierarchy diagram will be used processes would have resulted in a better picture.
as a map to direct the designers to the point of It should be remembered here that the hierarchy
interest, and that special area can be studied in diagram did its contribution in the determining
detail in the process models for the components. of the component processes. It is natural to have
An intermediate model, that is, the black-box different views in any modeling for visualizing
processes and their connections, can also be re- different concerns.
ferred to. Figure 10 presents the black-box view It is also possible to draw connections among
for the three actual processes. Here, details are the abstract processes in the hierarchy. This is use-
hidden, but the context of a process is presented: ful if an early idea is desired about the integration
Input, output, and related resources are shown before proceeding toward details. Again, it all
with the process. depends on what needs to be studied on the model.
The integration can be represented on the hier- Different copies of the hierarchy diagram can be
archy diagram with less detail on the connections maintained that present different views, even with
as shown in Figure 11. One point can be observed partial views. A diagram that only contains the
in Figure 11 about the different concerns between abstract levels, for example, is possible.
the hierarchy diagram and the actual integrated

Process Integration Through Hierarchical Decomposition

Figure 10. Actual processes and their connections

Customer

Documents
receive to hub
Documents
from
customer

Customer

Documents
from sell
proofreading
Final
Document

Documents Documents
from hub to sell
receive

Figure 11. Integration through connections in the hierarchy diagram

English Text Doctor

Customer Interactions Production

Receive Sell Hub

This much work seems to be sufficient in the hiding the details of a unit if its connections are
design of an integrated process. However, the enough to study a system of boxes. In this case, a
actual process model is also required due to the box corresponds to a process. An integration view
detailed modifications that will appear neither in that ignores where the processes came from (hi-
the hierarchy diagram nor in the black-box inte- erarchy diagram) and the internal details (process
gration diagram. The black-box concept means model for the component processes) is presented

Process Integration Through Hierarchical Decomposition

Figure 12. Integration of component processes

Documents
from
customer
Documents
receive to hub

Customer
hub

Documents
sell to sell
Final
Document

Figure 13. Integrated super process in detail

87
Process Integration Through Hierarchical Decomposition

in Figure 12. This view can be constructed by be technical or theoretical hurdles in composing
studying the component processes in their ab- the super process. Verification tools can detect
stract or black-box forms and their connections such problems. Also, the preservation of some
as shown in Figure 12. attributes of the processes is investigated for the
One point can quickly catch the eye: The cus- integration. Given the component processes with
tomer icon represented twice in Figure 10 is only their existing attributes, a forecasting capability
drawn once in Figure 12. This is an example of will indicate the attributes for the super process
the general statement that an integrated process to construct.
is not simply a gathering of component processes; For a more instrumental analysis of such issues
some modification may be necessary. Finally, in integration, more formal representations will
the combined process model for the integrated be required (Havey, 2005). This section proposes
processes is shown in detail in Figure 13. modeling processes and their attributes in task
systems (Delcambre & Tanik, 1998) that have
also historically provided a theoretical basis for
integration grounDWork operating systems. The preservation of some
process attributes can be investigated through
It is advantageous to support a graphical integra- this formal representation (Manzer, 2002). The
tion environment with further tools for inves- selected demonstrative set of process attributes
tigating various concerns. A process engineer comprises efficiency, repeatability, manageability,
can decompose a complex process logically, but and improvability. These attributes are indirectly
then locating existing processes and integrating mapped to task features such as determinacy,
them will have peculiar difficulties. There may deadlocks, mutual exclusion, and improvability.

Figure 14. Mapping process attributes to task features

Process Task
Attributes Mapping Features

Determinacy Mutual
Efficiency Repeatability Exclusion

Synchronization Deadlock
Improvability
Manageability

Mapping

Process Integration Through Hierarchical Decomposition

Figure 14 depicts the mapping of process attributes The following sections contain discussions
to task features where a process corresponds to about the task features (determinacy, deadlock,
one task in the formal system. Such a tool, while mutual exclusion, and synchronization). Since
being more adept for rigorous analysis, can be the ordering relations among the tasks in the ex-
utilized for higher level concerns with more ample are known, together with the input-output
subjective evaluation. These decision-supporting resources, articulation can easily be developed.
measures for integration can be a starting point for Also, comments are made about the process at-
the otherwise totally unsupported task of integra- tributes for the integrated organization based on
tion. Based on the decisions, specific component the task-features discussions.
processes will be acquired, or it will be possible
to assess the infeasibility of the goal. Determinacy
In the following sections, some process param-
eters are investigated and an assessment of their The super task system is determinate according
variance due to integration is discussed. It should to the following definition (Coffman & Denning,
be reminded that a mapping from the listed process 1973): “Task system C is determinate if for any
attributes to the addressed task features cannot given initial state s0, the resource-value sequences
be a perfect one, nor can the interpretations of the depend uniquely on the initial values in s0.”
model for high-level process attributes be perfect. In our example, the resource-value sequences
This approach equips the decision maker with a depend uniquely on the initial values in the initial
tool that will gain efficiency with experience. state. Every task in the super system is noninter-
fering as each task is either a predecessor or a
task systems successor of another task. Consequently, the super
system is determinate. In the super system, the
According to Coffman and Denning (1973), tasks of dispatching to groups and the proofreader
concurrently executing processes can interact in interface are indeterminate as the dispatching task
a number of undesirable ways if resources are depends on the completion of the proofreading. It
improperly shared or if there is a faulty commu- is stated that repeatability is partially dependent
nication of results (signals) between processes. on determinacy (Manzer, 2002). It can be stated
Generally, the problem is one of timing. that this process is repeatable.
To provide a better understanding of processes,
task systems were introduced that model a pro- Deadlocks
cess as C = (τ, <·), where τ is a set of tasks and <·
represents the partial order (precedence relation) In the super system, the threat of a deadlock is
of the tasks. If T is a task, the initiation of T is prevented by preventing circular wait: The circu-
denoted by T¯ and the termination of T is T_. A lar-wait condition is avoided for the proofreading
superscript bar is used to denote starting up, and task. There is a timer connection between the
a subscript bar denotes closing down. A task with tasks of dispatching to groups and the proofreader
no successor is a terminal task, and one with no interface. After the dispatcher sends the docu-
predecessor is an initial task. If task T is neither ments to the groups of proofreaders, 48 hours are
a successor nor a predecessor of T’, then T and allowed: If a proofreader does not return a docu-
T’ are independent. This section will not provide ment by that time, then the document is passed
a description of task systems in depth. Some of to the next proofreader in the same group. Since
its constituents will be included in the example resource usage is known in advance, deadlock can
process for an analysis of its composition. be avoided. Still, there is a risk of deadlock if the

Process Integration Through Hierarchical Decomposition

number of incoming documents (that is, requested conclusion

resources) is larger than the resources held (that is,
the number of proofreaders in a specific group). In Process modeling is an important task that organi-
order to avoid deadlocks, the number of people in zations will increasingly refer to. We can assume
various groups must be greater than the number that our world is in the information age simply by
of incoming documents from customers. There is observing the growing demand for software and
a high risk of experiencing an unsafe state if the the fact that information technologies are being
number of documents becomes greater than the employed as an inevitable component of any or-
number of proofreaders. In order to manage the ganization. This improvement is enabled through
process, the manager must know the resources engineering approaches; disciplined methodolo-
used in the process (Coffman & Denning, 1973). gies are very important for an efficient supply in
Since the number of used resources is known in an effort to address demand. Process notions can
advance, this process is manageable. be regarded as positioned at the heart of the disci-
plined approaches in any field, most dramatically
mutual exclusion and quickly felt in the fields of engineering related
to information. In addition, utilizing the Internet
The mutual-exclusion problem concerns the con- and other electronic means is gaining popularity
trol of a reusable resource so that it is never in in the forming or restructuring of organizations.
use by more than one task at a time. In the super We foresee an increasing demand for process
system, the reusable resource is the documents modeling and electronic enterprise engineering
sent to the proofreaders for correction. The sys- (Bieber et al., 1997) or virtual enterprises.
tem must confirm that the same document is not The proposed techniques can find many areas
sent to more than one proofreader. Similarly, the for application. One application is assuming the
document must not be sent to the proofreader if Internet for locating component processes in an
he or she is not available. It is obvious that mu- effort to build value-added chains (Manzer, 2002).
tual exclusion helps the traceability of resources. Verification can also be conducted on the process
Also, it indirectly promotes the efficient use of model, which can be integrated using the Internet.
resources. This implies the process attribute of This start may also find a smooth integration
efficiency. As has already been stated (Manzer into software development projects. A model
& Dogru, 2002), efficiency can be related to the introduced in the manner suggested can act as a
traceability of resources. requirements tool for any software development
to follow the enterprise design. Such develop-
synchronization ment will be necessary in the enabling of newly
founded organizations, and the super organization
Setting the time synchronizes the dispatching and can also provide a specific value-added chain. We
proofreading tasks in the super system. When may witness the quick formation of such chains
the document is sent to the proofreader, the task in an effort to exploit rapid changes in the market.
of dispatching to groups waits for 48 hours. If Tools such as the one proposed in this chapter
the corrected document is not received, then will aid in the design of these organizations. As
it is sent to the next available proofreader. By a summary, we expect to see agile organizations
achieving the timing requirement in this process, that can quickly shape, adapt, and function. As
performance of the process is improved. Hence, enabling technologies, practical yet sound tools
the process complies with the process attribute will be required for use in the formation of value
of improvability. chains and for verification of the outcome.

0
Process Integration Through Hierarchical Decomposition

references Humphrey, W. S. (1990). Managing the software

process. Reading, MA: Addison-Wesley Publish-
Acuna, S. T., & Juristo, N. (2005). Software pro- ing Company.
cess modeling: International series in software
Juric, B. M., Mathew, & Sarang, P. (2004). Busi-
engineering. Springer.
ness process execution language for Web services
Bieber, M., Bartolacci, M., Fierrnestad, J., Kurfess, BPEL and BPEL4WS. Birmingham, UK: Packt
F., Liu, Q., Nakayama, M., et al. (1997). Electronic Publishing.
enterprise engineering: An outline of an architec-
Laguna, M., & Marklund, J. (2004). Business
ture. Proceedings of the Workshop on Engineering
process modeling, simulation, and design. Pren-
of Computer-Based Systems, Princeton, NJ.
tice Hall.
Business Process Modeling Notation (BPMN).
Madachy, R. J., & Boehm, B. W. (2006). Software
(2004, May 4). Business process modeling no-
process modeling with system dynamics. Wiley-
tation (BPMN) information. Retrieved April 5,
IEEE Press.
2006, from http://www.bpmn.org
Manzer, A. (2002, June). Towards formal founda-
Coffman, E. G., & Denning, P. J. (1973). Op-
tions for value-added chains through core-compe-
erating systems theory. Englewood Cliffs, NJ:
tency integration over Internet. The Sixth World
Prentice-Hall.
Conference on Integrated Design and Process
Curtis, B., Kellner, M. I., & Over, J. (1992). Pro- Technology.
cess modeling. Communications of the ACM,
Manzer, A., & Dogru, A. (2002, April). Formal
35(9), 75-90.
modeling for the composition of virtual enter-
Delcambre, S. N., & Tanik, M. M. (1998). Using prises. Proceedings of IEEE TC-ECBS & IFIP
task system templates to support process descrip- WG10.1, International Conference on Engineering
tion and evolution. Journal of System Integration, of Computer-Based Systems, Lund, Sweden.
8, 83-111.
Tanik, U. (2001). A framework for Internet en-
Dutton, J. E. (1993). Commonsense approach to terprise engineering based on t-strategy under
process modeling. IEEE Software, 10(4), 56-64. zero-time operations. Unpublished master’s
thesis, Department of Electrical Engineering,
Hammer, M., & Champy, J. (2001). Reengineering
University of Alabama at Birmingham.
the corporation: A manifesto for business revolu-
tion. New York: HarperCollins Publishers.
Havey, M. (2005). Essential business process
modeling. O’Reilly Media Inc.

Chapter VI
Using a Standards-Based
Integration Platform for
Improving B2B Transactions1
Andrew P. Ciganek
Jackson State University, USA

Marc N. Haines
University of Wisconsin – Milwaukee, USA

William (Dave) Haseman

University of Wisconsin – Milwaukee, USA

Lin (Thomas) Ngo-Ye

University of Wisconsin – Milwaukee, USA

aBstract

This chapter presents a specific case in which a company explores the use of XML Web services in
conjunction with an integration broker. Several business-to-business (B2B) approaches are developed
to provide insight into the ability of modern integration technology to improve B2B interactions and
to allow a broader group of businesses to participate. Furthermore, technical details and integration
methodology principles are presented that can be used as points of reference for scenarios in which
the same or a similar set of technologies is applied to advance the efficiency and effectiveness of B2B
transactions. An evaluation of the B2B approaches is presented accompanied by a discussion of several
key lessons. This chapter then ends with some concluding remarks.

introDuction networks (VANs). Although EDI technology

has existed for quite sometime and is mature, a
Many organizations have introduced electronic large number of companies are still using manual
means to perform their business-to-business phone- or fax-based processes to transfer business
(B2B) transactions. These means include elec- information (e.g., purchase orders). The literature
tronic data interchange (EDI) via value-added suggests EDI is largely unattainable or at least

Copyright © 2007, IGI Global, distributing in print or electronic forms without written permission of IGI Global is prohibited.
Using a Standards-Based Integration Platform for Improving B2B Transactions

impractical for many small or even medium-size Business scenario

enterprises (Iacovou, Benbasat, & Dexter, 1995;
Teo, Wei, & Benbasat, 2003; Wigand, Steinfield, the company
& Markus, 2005). Larger businesses, on the other
hand, have widely adopted EDI and benefited from Midwest Manufacturing Company (MMC)2 is a
it, allowing them to grow at the expense of smaller manufacturer located in the Midwest of the United
organizations (Clemons & Row, 1988). Recently, States of America that supplies customers with
however, the use of the Internet in conjunction a diverse set of products on a global scale. Not
with technologies such as the extensible markup only are its customers geographically distributed,
language (XML) and XML Web services is being but they also differ largely in their technological
explored as a possible alternative to traditional capabilities and the means with which they order
EDI (Havenstein, 2005). As a result, businesses MMC’s products.
belonging to the “long tail” (Brynjolfsson, Yu, & While many of MMC’s customers, particularly
Smith, 2003) that were unable or reluctant to adopt larger organizations, employ EDI or use Web-
EDI may now have an opportunity to participate based purchase forms, the majority of its custom-
in electronic B2B transactions. ers still use a combination of fax and phone to
In this chapter, we present a specific case conduct purchases. In particular, exchanges using
in which a company explores the use of XML EDI account for 35% of the orders that customers
Web services in conjunction with an integration place. Another approach, an extranet where cus-
broker to drastically reduce, if not eliminate, the tomers log on and place orders using a Web-based
need for placing orders by phone or fax. A B2B application, accounts for 12% of orders. Lastly,
solution is developed that poses a much lower fax-based transactions account for the remaining
adoption threshold than previous B2B initiatives 53% of orders that customers place.
and provides greater flexibility. The fax- and phone-based approach requires
The purpose of this chapter is to provide the several steps in which the order information has
reader with insights into the ability of modern to transition from one system to another system.
integration technology to improve B2B interac- This requires manual interventions and thus cre-
tions and to allow a broader group of businesses ates opportunities for errors. To avoid some of
to participate. We first describe the business the problems inherent in the fax-based approach
scenario and provide an overview of the technol- and reduce the cost of business-to-business
ogy employed in the solution. We then present transactions, MMC is seeking solutions to fur-
three different approaches for placing purchase ther streamline and automate the process with a
orders electronically that were implemented in a flexible integration solution that would encourage
proof-of-concept system. The three approaches more customers to use direct electronic means for
are compared and evaluated based on their advan- purchase transactions.
tages and disadvantages in the given scenario, as Since MMC has already made a substantial
well as their relation to overall business strategy. investment implementing an SAP R/3 enterprise
Finally, we present important lessons learned in system, the new solution must leverage the func-
the process of implementing the solution and the tionality implemented in the enterprise system
options the company has moving forward with package. Therefore, MMC decided to explore
the implementation of a solution. developing a solution using the integration capa-
bilities of the SAP NetWeaver platform to improve
interaction with current customers and attract
new ones. In this case, the new approach may not

Using a Standards-Based Integration Platform for Improving B2B Transactions

only be viewed as an attempt to reduce costs, but order process, reduces the cost of placing orders,
also an attempt to create a competitive advantage and also provides a low-cost solution in terms of
for MMC by facilitating easier interaction with a implementation and maintenance may present
broader range of customers. enough incentive for these customers to adopt
it and move away from ordering via fax. Since
the order Process the recent SAP NetWeaver platform, particularly
the SAP Exchange Infrastructure (XI), supports
The customers placing orders by fax are running open standards and enables interoperability with
disparate legacy enterprise applications that a variety of disparate systems, MMC decided to
lack both application program interfaces (APIs) explore SAP NetWeaver for technical options for
to facilitate integration and a means to directly a solution to improve the order process.
communicate with MMC’s SAP enterprise sys-
tem. Therefore, the customer first enters an order
into his or her own enterprise system. Next, the technology overvieW
customer prints out the order in his or her native
language (e.g., English, German, French, and oth- At the center of the technical solution implemented
ers) and faxes it to MMC for further processing. at MMC is XI. XI is an integration broker and
After receiving this order by fax, staff at MMC business process management engine that consti-
manually translate and enter the order information tutes a key part of the SAP NetWeaver platform.
into the SAP system. There are several limita- The integration broker can leverage adapters
tions to this approach. Chief among them is the to connect to a diverse set of systems using a
significant amount of effort involved with placing variety of communication protocols. At its core,
these fax orders for both the customer and MMC. however, it uses XML and XML Web services
Furthermore, there is a relatively high amount of to exchange and manipulate messages. Internally,
errors in the orders placed by fax compared to data structures are defined using XML schema
orders placed via EDI or the Internet. Lastly, since definitions (XSDs), message transformations
there are manual steps involved in the process, can be performed using extensible stylesheet
there are increased lead times to the supply chain language transformation (XSLT), messages are
for these types of orders. Consequently, MMC exchanged in an extended SOAP3 format (XI
would like to move the fax order process to an protocol), and business processes can be defined
automated electronic process that is more cost using the Web services business process execution
effective and highly interoperable, that leverages language (WS-BPEL). To better understand the
its investment in SAP systems, and that presents potential solutions in this scenario, we provide
a practical solution that MMC’s customers can an overview of the key technologies: XML, Web
easily adopt. services, and XI.
The customers that currently send fax-based
orders have so far resisted joining the EDI VAN extensible markup language
and were also not signing on to the extranet solu-
tion to place orders despite discounts offered by According to the World Wide Web Consortium
MMC. This is partially attributed to a reluctance (W3C, 2005):
of customers to make significant investments
to update their legacy systems to allow them Extensible markup language (XML) is a simple,
to directly interface with MMC’s SAP system. very flexible text format derived from SGML (ISO
Consequently, an approach that improves the 8879). Originally designed to meet the challenges

Using a Standards-Based Integration Platform for Improving B2B Transactions

of large-scale electronic publishing, XML is also Web services. While XML Web services define a
playing an increasingly important role in the standard mechanism to exchange messages, none
exchange of a wide variety of data on the Web of its standards describe the format of the actual
and elsewhere. payload that is exchanged within the message
beyond requiring it to be formatted in XML.
XML is commonly used as the canonical data Therefore, for successful message exchanges, it
format in integration solutions. XML itself, how- is important that the involved parties agree on
ever, is a metalanguage and only prescribes a way a payload format (McAfee, 2005). This format
to construct XML-based markup languages (i.e., may be based on an industry-specific standard,
XHTML) that serve a specific purpose, including such as ACORD (insurance industry) or HL7
markup languages associated with XML Web (health care industry), or may be developed
services (i.e., SOAP). as a custom solution for a particular message
exchange.4
Xml Web services
saP netWeaver and the exchange
Even with XML, an important obstacle in the infrastructure
process of the integration of diverse systems
was the lack of a common message exchange The SAP Exchange Infrastructure is part of a suite
mechanism for distributed systems. While several of products that form the SAP NetWeaver platform.
technologies (e.g., DCOM, CORBA [common XI serves as an integration broker and business
object request broker architecture]) have been process management engine, which facilitates
developed in the past to connect distributed sys- building a service-oriented architecture based on
tems, they either were too focused on a specific XML Web services, or in SAP’s terminology, an
technology platform and lacked industry-wide enterprise service architecture (ESA). XI can be
support or they were too complex to become leveraged for internal application-to-application
a widely adopted and practical solution. XML data exchanges as well as in business-to-business
Web services have the potential to overcome scenarios. It also facilitates business process
this obstacle. Web services are based on a set of management across heterogeneous application
established core standards that are platform in- components. Interoperability is provided either
dependent and have broad industry support. The through the use of open standards (i.e., XML
essential standards for Web services are SOAP, Web services) or specialized adapters, which are
which describes the messaging protocol, and the available for a wide variety of systems and sup-
Web service description language (WSDL), which port proprietary APIs, databases, and messaging
describes the service interface. A third standard systems, such as IBM MQ Series.
often associated with Web services is universal The two key components for building an
description, discovery, and integration (UDDI), integration solution in XI are the integration
which describes the interaction with and the repository and the integration directory (see
structure of a registry for services. Additional Figure 1). The integration repository contains
Web-service-related standards have been or are data type definitions (XML schema), interface
still being developed that address orchestration definitions (WSDL), process definitions (WS-
(e.g., WS-BPEL), security (e.g., WS-Security), BPEL), interface and message mappings (XSLT
reliability (e.g., WS-Reliability and WS-Reliable or Java code), and context objects. There is a set
Messaging), and other aspects of Web services that of tools that can be leveraged to manipulate these
are important for the commercial applications of objects. All these definitions are abstract and do

Using a Standards-Based Integration Platform for Improving B2B Transactions

Figure 1. Building an integration solution in XI

Integration Repository Integration Directory

Integration Scenarios Integration Scenarios

Integration Processes Integration Processes

Mappings Routing Rules

XSLT or Java
Collaboration
Context Objects Agreements
XPath
Collaboration Profiles
Message Interfaces - Parties
WSDL - Services
- Communication
Data Types Channels
XSD

Abstract Definition Specific Configuration

not depend on specific execution-environment that may be used to connect to other systems
configurations. that require proprietary solutions; the integration
The integration directory contains integration engine, which handles message routing and trans-
scenarios and integration processes that leverage formation; and the business process engine, which
objects defined in the integration repository and executes cross-component business processes.
links them to actual execution environments. To interact with another SAP system, XI can
Collaboration profiles with parties, services, directly communicate using the XI protocol or
and communication channels are configured, SOAP if the other SAP system is running on a
and routing rules and collaboration agreements recent version of the SAP Web application server
are determined here. There is also a set of tools (WAS). Otherwise, either the SAP RFC (remote
that facilitate manipulating the objects in the function call) adapter or IDOC adapter has to
integration directory. The purpose of the inte- be used.
gration directory is to adapt abstract integration
content, as defined in the integration reposi-
tory, to a specific system configuration in an imPlementation of a
organization. Proof-of-concePt solution
The XI run time executes the scenarios and
integration processes defined in the integration MMC decided to implement a proof-of-concept so-
directory (see Figure 2). It consists of three layers: lution to get a better understanding of how XI and
the adapter engine, which manages the adapters

Using a Standards-Based Integration Platform for Improving B2B Transactions

Figure 2. Executing an integration solution in XI

XI Runtime

Business Process Engine

Integration Engine

Adapter Engine

SOAP RFC File

Web services can be leveraged to improve the sales of a new order file, converts it, and passes it on
order process. After investigating the technologies to the back-end enterprise system using the same
discussed previously, we decided to implement mechanisms as in the previous approach.
and compare three different approaches. The first The third approach excludes the integration
two approaches involve the integration broker, broker and involves developing a Web service
while the third approach directly leverages the directly on MMC’s enterprise system. As in the
Web services capabilities of the WAS on which first approach, we needed to install a Web service
the SAP R/3 system is running. adapter at the customer’s location to bridge the
The first approach uses XML Web services gap between the legacy applications and MMC’s
to expose the order functionality to the customer. Web service. Now, however, the Web service
Since the customer systems did not have Web adapter communicates directly with the SAP
services capabilities, we needed to develop a enterprise system.
Web service adapter that could bridge the com- The data that were used to design and test
munication between the customer’s legacy sys- these three solutions were provided by MMC and
tem and MMC’s Web service. The integration included orders from three different customers,
broker handles the SOAP message exchange here referred to as Customer UK, Customer DE,
with the customer, message transformation, and and Customer FR. These customers were each
the communication with the back-end SAP R/3 located in a different country, used different native
enterprise system. languages, and ran different legacy systems.
The second approach uses the file transfer These customers are wholly owned subsidiar-
protocol (FTP) instead of Web services to com- ies of MMC and operate primarily as aggregators
municate with the customer. Each customer is of orders for their respective countries. While
sending a data file (typically in a comma-separated each of their legacy systems was different, it was
value file format) to an FTP server located at MMC. determined that each system had the capability to
The integration broker then detects the presence produce comma-separated files, albeit using dif-

Using a Standards-Based Integration Platform for Improving B2B Transactions

ferent content formats. All three approaches used structures necessary for calling MMC’s
these files as the starting point for the electronic order Web service.
order process. The following is a more detailed 2. The adapter then sends a SOAP message to
description of each of the three approaches. the appropriate Web service endpoint on the
integration broker, as defined in the WSDL
Approach 1: Integration Broker and for MMC’s order Web service.
Web Services 3. MMC’s integration broker, SAP XI, receives
This approach involved MMC’s integration broker, the incoming SOAP message via its SOAP
in this case XI, and XML Web services to com- adapter. The SOAP adapter converts the
municate with customers. Since the customers’ incoming SOAP message into an XML-
current legacy systems do not directly support based SAP XI protocol message to match
Web services, a Web service adapter had to be the outbound interface structure.
developed for each customer. The Web service 4. Mappings in XI then transform the payload
adapters were implemented using Microsoft .NET. of the incoming message into the format
The following provides a step-by-step description matching the inbound interface structure,
of the message exchange between the customer which reflects the data structures required
and MMC using this approach (see Figure 3). by the receiving SAP R/3 system.
5. The XI RFC adapter is then utilized to send
1. The customer-specific Web service adapter the message to the SAP R/3 system.
detects and parses the flat files written by 6. The SAP R/3 system processes the order
the legacy system and produces the data using a custom function module developed
for creating and committing a sales order.

Figure 3. Approach 1: Integration broker and Web services

Customer UK Company A

Legacy Integration Server Enterprise System

System

SAP R/3
Response Order Outbound Inbound
Text File Text File Interface Interface

New Order
Files? XI XI RFC
WS SOAP Map Adapter RFC
Adapter Adapter
 

Customer DE
WS
Adapter
Z_BAPI_SALESORDER_CREATE
Customer FR

WS
Adapter

Using a Standards-Based Integration Platform for Improving B2B Transactions

Figure 4. XI messages

The response from the SAP R/3 system is format to an FTP server located at MMC. The
passed back into XI via the RFC adapter, again MMC’s integration broker then processes these
transformed, and returned via XI’s SOAP adapter files through a file adapter. The following pro-
to the calling customer’s Web service adapter. The vides a step-by-step description of the message
Web service adapter writes the response into a file exchange between the customer and MMC using
readable by the customer‘s legacy system. this approach.
The SAP NetWeaver environment provides
users with a number of tools to assist in the de- 1. The customer’s legacy system creates a text
velopment and administration of the integration file containing the order information.
solution, including the tracking of messages that 2. An FTP client at the customer location sends
flow through the system. Figure 4 depicts an ex- this text file to the FTP server at MMC. Since
ample of an actual message from the customer as the files reflect the data structures used in
it is processed in XI. The screenshots were taken the customer’s specific legacy system, they
from the message monitoring tool and show the have a different format for each customer. To
SOAP message from the customer’s Web service ensure confidentiality, each customer posts
adapter as well as the message passed on to the files to a private subdirectory on MMC’s
R/3 system. FTP server.
3. MMC’s integration broker leverages a file
Approach 2: Integration Broker and adapter to pull new order files from the FTP
File Transfer server and parses the file into an XML struc-
The second approach tries to leverage existing FTP ture corresponding to the outbound interface
capabilities available in the customers’ systems. for the customer. As the file format differs
Instead of using Web services to communicate for each customer, a different file adapter
with MMC’s integration broker, the customer and outbound interface must be configured
system sends files in a customer-specific file in XI for each customer. The file adapter

Using a Standards-Based Integration Platform for Improving B2B Transactions

Figure 5. Approach 2: Integration broker and file transfer

Customer UK Company A

Legacy Integration Server Enterprise System

System
XI
SAP R/3
 Outbound Interface Inbound
Order Customer UK Interface
Text File New
Order
Files? XI File XI RFC
Adapter Map Adapter RFC
FTP
Client 
 

Customer DE FTP
Server
FTP
Client
XI File Z_BAPI_SALESORDER_CREATE
Adapter Map
Customer FR 
FTP XI File Map
Client Adapter

detects new files by polling the FTP server process the response from the R/3 system and use
in specified time intervals. Each file adapter XI’s asynchronous message processing capabili-
has its specific conversion instructions to ties to write the message back to the FTP server,
transform the customer’s file format into an where the customer’s system, if it possesses
XML file representing the customer data. the ability, could retrieve the response file and
4. The XML message matching the outbound process it further. Figure 5 depicts the details of
interface is then mapped to the inbound in- this solution.
terface structure using a customer-specific
mapping. Approach 3: Using R/3 Web Services
5. The message matching the inbound interface The third approach eliminates the need for an
structure is then passed to the back-end SAP integration broker by directly communicating with
R/3 system using the RFC adapter. the SAP R/3 system using XML Web services.
6. The SAP R/3 system processes the order This approach takes advantage of the ability to
using a custom function module developed expose function modules as XML Web services
for creating and committing a sales order. directly from SAP R/3. This is only possible,
however, in the more recent version of SAP R/3
This approach was initially implemented as running on the SAP WAS.
a one-way exchange. It is possible, however, to

00
Using a Standards-Based Integration Platform for Improving B2B Transactions

Figure 6. Approach 3: Using R/3 Web services

Customer UK Company A

Enterprise System
Legacy
System
SAP R/3
WAS 6.40
Response Order

Text File Text File

New Order
Files?

WS Web
Adapter Service


Customer DE WS
Adapter Virtual Interface for
Z_BAPI_SALESORDER_CREATE
exposed as Web Service
Customer FR WS 
Adapter

For this approach, it is again necessary to tion server hosting the R/3 system. The Web
provide the customer with a Web service adapter service interface is different from the one
that can communicate with the customer’s legacy used in Approach 1 since this interface now
system. Instead of sending a SOAP message to the directly reflects the data structure used in
integration broker, the message is directly targeted the SAP R/3 function module.
at Web service interfaces on the SAP R/3 system. 3. The SOAP message is received by the Web
The following is a step-by-step description of each service on the SAP WAS at MMC that hosts
stage in this solution (see Figure 6). the SAP R/3 system.
4. Through a virtual interface defined in the
1. The customer-specific Web service adapter SAP R/3 system, the corresponding remote-
detects and parses the flat files written by enabled function module is invoked and the
the legacy system and produces the data order is processed in SAP R/3.
structures necessary for calling MMC’s
order Web service. The result returned from the function module
2. The customer’s Web service adapter then is passed back to the Web service via the virtual
sends a SOAP message to the appropriate interface. The WAS handles the creation and
Web service endpoint as defined in the sending of the SOAP response message back to
WSDL for MMC’s order Web service, which the Web service adapter at the customer site. The
is now located directly on the Web applica- Web service adapter writes the response into a file
readable by the customer’s legacy system.

0
Using a Standards-Based Integration Platform for Improving B2B Transactions

To create a Web service on the WAS that hosts the approaches. For both approaches involving the
the R/3 system, it is necessary to first define a so- integration broker, it is necessary to install and
called virtual interface for an existing function correctly configure XI. While this is a substan-
module in R/3. The second step is to provide the tial one-time effort, we focus our evaluation of
appropriate configuration that exposes this virtual the relative advantages of each approach on the
interface as a Web service on the WAS. For SAP implementation of a solution given a working XI
WAS Version 6.40 and up, the development tools system as this aspect has larger long-term business
provide wizard support to create the virtual inter- implications. Table 1 summarizes the evaluation
face and the Web service. In previous versions of of the three approaches.
the WAS, more extensive manual configuration
and programming are required to realize the Web Approach 1: Integration Broker and
service interface. Web Services
The current customer systems do not have Web
services capabilities. Consequently, for this ap-
evaluation proach MMC would be required to develop and
maintain a Web service adapter for each of its
After completing a proof-of-concept implemen- customers. While the adapter would be running
tation of the three approaches, we evaluated the on the customer’s site, it is MMC’s IT develop-
relative advantages and disadvantages for each of ment and maintenance burden to support a greater

Table 1. Evaluation of the three approaches

Approach 1: Integration Approach 2: Integration Approach 3: Using R/3 Web

Broker and Web Services Broker and File Transfer Services

High:
MMC Low: Low:
A separate file adapter and
System One common interface and Wizard tool creates Web service
outbound interface and mapping
Effort mapping interface (WAS 6.40)
for each customer

High: Low: High:

Customer Different Web service adapter Leverages existing FTP Different Web service adapter for
System for each customer location; capabilities; each customer location;
Effort Needs to be maintained and No additional software Needs to be maintained and
managed by MMC component needed managed by MMC

High:
Low:
High: Leverages XI capabilities such
Few interface design, routing, or
Leverages XI capabilities such as flexible interface design,
Flexibility mapping capabilities;
as flexible interface design, routing, and mapping;
Only direct point-to-point
routing, and mapping Leverages built-in XI file
connections
parsing capability

Locale of
Both on customer and MMC
Integration On MMC side only Both on customer and MMC side
side
Processing

0
Using a Standards-Based Integration Platform for Improving B2B Transactions

number of different IT platforms for larger num- In summary, although this approach provides
bers of MMC customers. In our case, we only high flexibility and scalability by leveraging the
developed a Web service adapter for the .NET capabilities of XI and Web services, and requires
platform. There is the possibility in the future a low implementation effort on MMC’s integration
that customer systems will directly support Web broker, it also constitutes a substantial develop-
services, thus eliminating the need for MMC to ment effort to enable customers to use the Web
develop a Web service adapter. service. Furthermore, the responsibility of MMC
The implementation effort on the integration for integration processing at its own site as well
broker is relatively low. With only one customer- as its customer’s site poses additional staffing and
facing interface, only one mapping needs to be management challenges.
developed as opposed to one for each customer in
Approach 2. Furthermore, the integration broker Approach 2: Integration Broker and
provides flexibility. This includes flexible routing File Transfer
and message mapping. The integration broker The key differences between the second approach
allows MMC to decouple the customer-facing out- and the first approach are a concern for the need
bound interface from the data structures required to develop and support integration processing
in the back-end SAP R/3 system. This translates (e.g., Web service adapter) on the customer’s
into a less complex interface for the customer, site and the number of interfaces and mappings
focusing only on the necessary data items. It also on MMC’s integration broker. In this approach,
provides the opportunity to make changes in the the customer leverages its existing capability to
back-end system without requiring changes for transfer files to MMC using FTP. This eliminates
the customer. Changing the function module in the need for MMC to develop and maintain any
SAP R/3 to process the orders, or moving to a integration processing (i.e., Web service adapter)
different SAP system and using a different inter- on the customer’s site. To facilitate communication
face (i.e., using the XI protocol rather than the with the customer, MMC only needs to set up a
RFC adapter) will only require the definition of secure FTP server, which poses only a marginal
a new inbound interface and adjustments to one effort.
mapping. The integration broker also provides More processing needs to be done in Approach
multiple options for securing and monitoring 2 within XI since the order information arrives
the message exchange. This provides MMC with at the integration broker in a customer-specific
technical flexibility while maintaining business format. The consequence is the need to imple-
continuity with the customer. ment and maintain a file adapter, an outbound
On the other hand, the Web service interface interface, and a specific mapping to the back-end
can be extended with relative ease to provide ad- interface for each customer. The XI file adapter
ditional business functionality without disrupting provides tools that facilitate the parsing of comma-
the existing one. In our case, this could include separated value format files, and mappings are
added functionality that allows a customer to supported with graphical mapping tools. A large
inquire about order status or to obtain a list of number of customers, however, may constitute
recent orders that were placed by the customer. a noticeable IT development and maintenance
Thus, the flexibility of the integration broker in burden. This solution is particularly problematic
combination with the use of Web services also in cases where customer interactions are ad hoc
contributes to increased business agility (Sam- and short lived. The advantage of this approach
bamurthy, Bharadwaj, & Grover, 2003). is that all development integration processing
occurs in XI at MMC, thus avoiding some of

0
Using a Standards-Based Integration Platform for Improving B2B Transactions

the potential management and staffing issues as bility for integration processing on the customer’s
noted in Approach 1. In comparison to writing a site. This approach becomes substantially more
Web service adapter, configuring a file adapter difficult for older versions of the SAP WAS (<
requires lesser effort. 6.40) as they lack the wizard support for creating
In summary, this approach also provides the Web service interface.
high flexibility and scalability by leveraging ca-
pabilities of XI. From a customer’s perspective,
Approach 2 is less invasive since no additional Discussion
software components are needed and it lever-
ages existing IT capabilities. On the other hand, The three approaches that were examined in
more work has to be done in MMC’s integration the proof-of-concept implementation provide
broker, but it eliminates the need for developing MMC with a number of options to go forward
a Web service adapter and it also allows MMC and implement a solution to improve the order
more direct and central control in comparison to process. The advantages and disadvantages of
Approach 1. each approach were outlined above. This section
details the integration issues encountered during
Approach 3: Using R/3 Web Services the development of the three approaches as well as
Approach 3 eliminates the need for an integration the key lessons learned that apply to integration
broker and it constitutes a point-to-point integra- scenarios involving Web services and integration
tion solution between the customer and MMC. brokers in general.
Similar to Approach 1, a Web service adapter is First of all, it is important that MMC assesses its
necessary, with similar implications for IT devel- specific situation and considers its strategic goals
opment, maintenance, management, and staffing before making a decision (Swanson & Ramiller,
for MMC. This solution has the least amount of 2004). Since MMC’s SAP R/3 system used for
flexibility in terms of routing, mapping, and in- production is not a current version that supports
terface abstraction. As a consequence, the Web exposing Web services directly, Approach 3 can
service interface is more complex as it reflects only be considered after an upgrade of the SAP
the interface defined in the SAP R/3 system. If R/3 back-end system. This and some of the other
an appropriate function module exists in R/3, a disadvantages associated with using direct Web
Web service interface can be quickly established services make it likely that MMC will choose
using the wizard tool provided by SAP. In our a solution involving an integration broker. The
particular example, however, we found that the choice between Approach 1 and Approach 2 hinges
WSDL created by the SAP tool for this interface largely on the ability of its customers to use Web
was not entirely compliant with the standard and services. This is an issue that any organization
had to be manually adjusted to work with the using Web services for B2B interactions needs to
.NET-based Web service adapter. consider. In MMC’s case, customer systems can-
In summary, this approach is the least flexible not currently leverage Web services, but this may
and scalable solution but perhaps the quickest to change in the future. Thus, MMC needs to look
implement, particularly if an XI integration broker ahead and make a prediction about the develop-
has not yet been implemented and configured. ment of its customers in terms of their integration
This approach is more invasive from a customer capabilities, especially related to Web services.
perspective than Approach 2 and faces the same This also encompasses tracking and understand-
potential management and staffing issues as en- ing the development of standards related to Web
countered in Approach 1 due to MMC’s responsi- services and their adoption. Independent of the

0
Using a Standards-Based Integration Platform for Improving B2B Transactions

integration solution vendor, it is important that The monitoring tools allow end-to-end tracking
MMC, or any other organization, understands and examination of messages throughout the
which standards are supported in a particular processing in the adapters and the integration
integration product. engine. Setting up XI, however, is a substantial
While MMC may go ahead with a single ap- effort, and our experience emphasizes the need
proach, it is quite reasonable to consider a combi- for experienced staff to configure XI correctly.
nation of a Web-services- and a file-transfer-based Furthermore, our experience revealed that sup-
solution. The flexibility and the tool support of the port for Web services is immature. For example,
SAP XI integration broker make this a feasible we needed to manually change the Web services
solution as it is a relatively small effort to provide endpoint in the WSDL documents generated by
the additional Web service interface along with the Web service definition wizard. In addition, the
the interfaces needed for file processing. Mul- WSDL generated for our scenario in Approach
tichannel access to information resources is a 3 was not WS-I compliant and needed further
valuable feature of integration brokers in general. manual adjustments to work with the .NET Web
If Web services become a ubiquitous integration service adapter.5
mechanism in future business applications (Hagel
& Brown, 2001), MMC and its customers could
benefit from the file transfer capabilities in the conclusion
short term, and in the long term transition to Web
services interactions once its customers’ systems As of the time this chapter was finalized, the
are Web service enabled. approaches and implementations examined in
Furthermore, the decision about whether XI our research remained proof-of-concepts while
should be obtained as an integration broker may MMC was weighing its options. Our prototype
not be influenced solely by considerations regard- implementation, however, demonstrates the
ing the integration of external systems with the opportunities for improving B2B transactions
SAP enterprise system. This decision will also using a standards-based integration platform
be driven by requirements for having XI avail- and clarifies the technical options that can be
able for internal SAP-to-SAP module integration. leveraged in MMC or other organizations facing
Already in the current release of SAP NetWeaver, similar B2B exchange problems and a similar IT
XI is required for communication between some environment. While no ultimate conclusion can be
SAP products, and statements by SAP indicate reported for this case, we believe that it provides
that this requirement is likely to affect a larger practitioners with relevant insights in the ability
set of components in future releases. of modern integration technology to improve B2B
The experience of implementing the proof-of- interactions and enhance competitive advantages
concept solution for MMC showed that XI provides by enabling a broader group of businesses to
a manageable, flexible, and scalable infrastructure participate. In addition, the technical details and
for integration that supports a number of integra- integration methodology principles presented in
tion mechanisms, including Web services and file this case may be used as points of reference for
transfer. The XI integration builder tool facilitated other scenarios in which the same or a similar set
the definition of Web services interfaces and of technologies is applied to advance the efficiency
development of file conversions. Mappings can and effectiveness of B2B transactions.
be visually developed with a graphical mapping
tool or can be provided as XSLT or Java code.

0
Using a Standards-Based Integration Platform for Improving B2B Transactions

references Teo, H. H., Wei, K. K., & Benbasat, I. (2003).

Predicting intention to adopt interorganizational
Brynjolfsson, E., Yu, H., & Smith, M. D. (2003). linkages: An institutional perspective. MIS Quar-
Consumer surplus in the digital economy: Esti- terly, 27(1), 19-49.
mating the value of increased product variety at
Wigand, R. T., Steinfield, C. W., & Markus, M. L.
online booksellers. Management Science, 49(11),
(2005). Information technology standards choices
1580-1596.
and industry structure outcomes: The case of the
Clemons, E. K., & Row, M. C. (1988). McKesson U.S. home mortgage industry. Journal of Manage-
Drug Company. A case study of Economist: A ment Information Systems, 22(2), 165-191.
strategic information system. Journal of Manage-
World Wide Web Consortium (W3C). (2005).
ment Information Systems, 5(1), 36-50.
Extensible markup language (XML) activity state-
Hagel, J., & Brown, J. S. (2001). Your next IT strat- ment. Retrieved March 10, 2006, from http://www.
egy. Harvard Business Review, 79(9), 105-113. w3.org/XML/Activity.html

Havenstein, H. (2005). Sabre replacing EDI with

Web services. Computerworld, 39(34), 12. enDnotes
Iacovou, C. L., Benbasat, I., & Dexter, A. S. (1995). 1
This research was supported in part by a
Electronic data interchange and small organiza-
grant by SAP Americas.
tions: Adoption and impact of technology. MIS 2
Midwest Manufacturing Company is an
Quarterly, 19(4), 465-485.
alias name used to disguise the identity of
McAfee, A. (2005). Will Web services really the company.
transform collaboration? MIT Sloan Management 3
SOAP used to stand for simple object access
Review, 46(2), 78-84. protocol, but according to the current SOAP
1.2 specification, the acronym SOAP is no
Meadows, B., & Seaburg, L. (2004, September
longer spelled out (Mitra, 2003).
15). Universal business language 1.0. OASIS. 4
There are also efforts to develop a universal
Retrieved February 14, 2006, from http://docs.
business language (UBL; Meadows & Sea-
oasis-open.org/ubl/cd-UBL-1.0/
burg, 2004) for core business documents,
Mitra, N. (2003, June 24). SOAP version 1.2 part such as purchase orders.
0: Primer. W3C. Retrieved June 10, 2004, from 5
This assessment was made using the WS-I
http://www.w3.org/TR/2003/REC-soap12-part0- test in the Mindreef SOAPscope tool and
20030624/ was also corroborated by SAP OSS notes
and articles found on the SAP Software
Sambamurthy, V., Bharadwaj, A., & Grover, V. Developer Network Web pages.
(2003). Shaping agility through digital options:
Reconceptualizing the role of information tech-
nology in contemporary firms. MIS Quarterly,
27(2), 237-263.
Swanson, E. B., & Ramiller, N. C. (2004). Inno-
vating mindfully with information technology.
MIS Quarterly, 28(4), 553-583.

0
107

Chapter VII
The Changing Nature of
Business Process Modeling:
Implications for Enterprise
Systems Integration

Brian H. Cameron
The Pennsylvania State University, USA

Abstract

Business process modeling (BPM) is a topic that is generating much interest in the information tech-
nology industry today. Business analysts, process designers, system architects, software engineers, and
systems consultants must understand the foundational concepts behind BPM and evolving modeling
standards and technologies that have the potential to dramatically change the nature of phases of the
systems development life cycle (SDLC). Pareto’s 80/20 rule, as applied to the SDLC, is in the process of
being drastically altered. In the past, approximately 20% of the SDLC was spent on analysis and design
activities with the remaining 80% spent on systems development and implementation (Weske, Goesmann,
Holten, & Striemer, 1999). Today, with the introduction of the Business Process Management Initiative
(BPMI), Web services, and the services-oriented architecture (SOA), the enterprise SDLC paradigm is
poised for a dramatic shift. In this new paradigm, approximately 80% of the SDLC is spent on analysis
and design activities with the remaining 20% spent on systems development and implementation. Once
referred to as process or workflow automation, BPM has evolved into a suite of interrelated components
for systems analysis, design, and development. Emerging BPM standards and technologies will be the

Copyright © 2007, IGI Global, distributing in print or electronic forms without written permission of IGI Global is prohibited.
The Changing Nature of Business Process Modeling

primary vehicles by which current systems portfolios transition to Web services and service-oriented
architectures (Aversano, & Canfora, 2002). The Business Process Management Initiative’s business
process modeling notation (BPMN) subgroup is currently finalizing a standardized notation for business
process modeling. Although the notation is still in working-draft format, system architects and designers
should consider incorporating the concepts of BPM into their current and future systems analysis and
design procedures.

Background new BPM technologies are fueling a renewed

interest in process thinking (Ettlinger, 2002). New
Adaptive organizations want to be able to BPM technologies promise business modelers
rapidly modify their business processes to and managers a visual dashboard to manage and
changes in their business climate including adjust, in real time, human and machine resources,
competitive, market, economic, industry, as well as information being consumed as work
regulatory and compliance, or other factors. progresses.
Meanwhile, enterprise architects within IT or- The business and IT worlds are taking more
ganizations have long dreamed of a repository strategic and holistic views of IT and how it sup-
for models that are interconnected and extend ports the business. IT strategy, business process
to support application delivery. No single tool improvement, and IT architecture are experi-
exists that enables enterprise architects to encing a renaissance. Enterprise architects have
connect the dots between high-level models tackled the technical architecture effectively.
geared toward a business audience and execut- Now, enterprise architects are looking to ex-
able code to instantiate the vision (Carlis & pand their efforts into the business architecture
Maguire, 2000). space. Enterprise business architecture (EBA) is
Business process modeling (BPM) is both a the expression of the enterprise’s key business
business concept and an emerging technology. The strategies and their impact on business functions
concept is to establish goals, define a strategy, and and processes (Adhikari, 2002b). Business archi-
set objectives for improving particular operational tecture efforts in most organizations are limited
processes that have significant impact on corporate to thematic project-level initiatives. Thematic
performance. It does not imply reengineering all business architecture artifacts generally fail to
business processes; rather, the focus is on busi- evolve once the projects are complete because
ness processes that directly affect some metric of little perceived value exists for keeping business
corporate success. Business performance manage- architecture content alive. However, emerging
ment and measurement emphasize using metrics standards show promise in keeping business ar-
beyond financial ones to guide business process chitecture and associated artifacts alive to serve
management strategies (Delphi, 2001). Metrics as key business strategy enablers.
related to customer value or loyalty are examples. The IT world is moving more toward a model
Business process modeling is becoming the central of integrating pieces or components vs. building
point of organization for many systems. BPM as from scratch (Adhikari, 2002a). Organizations
a concept is not new; multiple process manage- are looking to strategically optimize, automate,
ment methodologies such as six sigma and lean and integrate key processes to provide seamless
manufacturing have existed for years. However, service to more demanding customers in a mul-

108
The Changing Nature of Business Process Modeling

tichannel world. To do this effectively, systems thus process models created with BPMN will auto-
must be integrated at the process level as well as mate much more rapidly than is currently possible
the data level. Integrating systems at the process with any other modeling notation (Ewalt, 2002).
level has been a challenge that, when unmet, The business process query language (BPQL)
leads to data duplication and inconsistency, and has been introduced by the Business Process
functional overlap (i.e., inefficient processes and Management Initiative (BPMI) to query process
processing; Reingruber & Gregory, 1994). Many repositories, similar to the manner in which
companies are embarking on process improvement SQL is used to query data repositories. Several
initiatives in hopes of increasing the efficiency or concepts presented in BPMN should be considered
effectiveness of the organization. for immediate adoption by system designers and
Process improvement initiatives go by many integrators. First is the agreement on a standard
names, including ISO certification, enterprise notation and principle set for process modeling.
business architecture, business process improve- Many modeling tools are incorporating support
ment, six sigma, business process reengineering, for BPMN, BPEL4WS, and BPML.
and lean thinking, to name a few. Most of these Technical modeling standards (e.g., entity re-
initiatives utilize visual modeling techniques to lationship diagrams, unified modeling language)
understand current-state and future-state design. are being coupled with more business-oriented
Several accepted standards exist for visual model- modeling approaches (e.g., BPMN, swimlane
ing (e.g., integrated definition [IDEF], American diagrams) to converge business and IT model-
National Standards Institute [ANSI], event-driven ing. The goal of these efforts is to incorporate
process chains [EPCs]). None of these visual a set of standardized guidelines into all inter-
process modeling standards offers a seamless nal and external modeling initiatives. With
extension of visual models into executable script increased attention to process integration with
or source code. In response to this shortcoming, a supply chain partners, organizations are quickly
new modeling standard (business process model- moving to a standardized approach for process
ing notation, BPMN) is emerging that promises modeling to support intra-organizational and
this seamless model to code integration (BPMI. interorganizational development and integra-
org, 2005). This model to execute the goal is remi- tion initiatives.
niscent of the failed promises of computer-aided Software tools have long been used to automate
software engineering (CASE) tools. Advances in tasks and reduce manual interactions. Thus, it is
the fields of computer science and mathematics important to distinguish business processes from
are now making this goal attainable. BPMN offers IT applications. A business process is a sequence
a mechanism for true business- and IT-process of activities performed by people and machines
modeling convergence. Notations and methods necessary to produce a desired result (Adhikari,
for process improvement and modeling within 2002b). It is initiated by the arrival of work (such
the business are mature, as are the notations and as a phone call, faxed order, or timing event) that
methods for application development and delivery triggers the sequence of operational activities. An
within IT. However, the current business- and application is a logical grouping of tasks automated
IT-process models and methods fail to align well by a computer with the objective of reducing or
with one another (Adhikari, 2002b). augmenting human interactions. Thus, an applica-
BPMN is mapped to the business process tion is a subset of the tasks of a business process.
modeling language (BPML) and business process Many human-centric activities of a business
execution language for Web services (BPEL4WS),

109
The Changing Nature of Business Process Modeling

process have largely been unautomated (though Modeling Madness:

some organizations use workflow automation to A Brief History
manage electronic work queues).
A business process management suite (BPMS) System models have long been a part of the sys-
is a new development environment that enables tems analysis and design process, traditionally
business users to collaborate with IT professionals leveraging ANSI standard flowcharts to commu-
in the design and development of optimized busi- nicate logic flow. Modeling tools have evolved in
ness processes (not applications), thus reducing response to the changing needs of business and
the communication gap between business and advances in technology. Spreadsheets were (and
IT. Ideally, a business process management suite still are) the primary modeling tool for many or-
supports a business process modeling environ- ganizations. As a result, in many organizations,
ment that is shared by business analysts, process modeling has become a series of spreadsheets
engineers, IT architects, and programmers. The with what-if scenarios and is synonymous with
modeling surface or palette exposes different financial modeling. In the IT world, modeling
capabilities to support each of these roles. Un- has become synonymous with a variety of visual
like earlier code-generating tools, the modeling system modeling techniques, which include the
environment creates XML (extensible markup following.
language) metadata that describes how applica-
tion functionality and information, and human • Entity relationship diagrams (ERDs)
activities should interact and be instantiated at • ANSI standard flowcharts
run time. • Process models
The new run-time engines interpret the • Data flow diagrams
metadata at run time (Mangan & Sadiq, 2002). • Unified modeling language (UML) dia-
Increasingly, vendors are endorsing the busi- grams
ness process execution language (BPEL) as the • Network diagrams
standard process description language. Thus, • CRUD (create, read, update, and delete)
changing a business process requires changing matrices
the graphical model, regenerating the metadata, • IDEF charts
and redeploying process instances. This is a much • Engineering process control (EPC) charts
simpler and faster approach to changing how work
gets done. This faster rate of change to operational In both the business and IT worlds, models have
best practices and the ability to change activi- been used as mechanisms to describe complex
ties dynamically are what make an organization ecosystems. IT-oriented modeling has historically
adaptive. An adaptive organization can adjust its focused on logic flow and data elements while
operational business processes in near real time business-oriented modeling has focused on quality
to capitalize on opportunities, avoid threats, and and productivity metrics (e.g., cycle time, setup
maximize corporate performance. time, processing time, cost, and defect rates).
Differences in modeling standards adopted by
organizations have suboptimized the benefits of
visual modeling, especially in interorganizational
modeling efforts. A group of organizations, with
strong interests in modeling, have joined forces

110
The Changing Nature of Business Process Modeling

to leverage the collective best practices of the cal people. OMG recognizes that UML does not
member organizations to develop a common provide a facility that actively addresses the needs
notation for business process modeling (BPMN) of IT business modelers (Sadiq, Orlowska, Sadiq,
in the hope of unifying IT and business process & Foulger, 2004). OMG is currently considering
modeling (BPMI.org, 2005). BPMI’s BPMN to fill this void. A merger, alli-
Many of these best practices can and should ance, or convergence of the modeling standards
be incorporated into the organizational model- efforts of OMG with those of BPMI would be a
ing practice immediately. There should be an major advance for enterprise architecture. Joining
expectation that visual business models help BPMN with UML would do much to minimize
expose characteristics of the underlying busi- redundant questioning by IT organizations during
ness process. For example, a business process the system development life cycle (SDLC).
related to entering purchase orders should be One of the strengths of the BPMN standard
able to expose the underlying user interface is its capability to support more ambiguity in the
for all data entry points of the process, as well modeling environment. Events have traditionally
as expose the underlying data tables related to been undermodeled by business process modeling
the transaction. At a higher level of abstraction, teams, typically focusing on process triggers and
the business models should be linked to entity end states. BPMN distinguishes between begin-
relationship diagrams as well, which highlight ning, intermediate, and ending events, as well as
the overall table structure. event start and interruption. With prior modeling
Swim-lane diagrams are a process modeling techniques, intermediate event information is
technique that was popularized in the 1990s. This typically buried in text annotations or symbol
modeling technique graphically denotes respon- properties, essentially useless to the process
sibility for work with vertical or horizontal lanes modeler (BPMI.org, 2005). The BPMN standard
(lines of demarcation) and is almost universally contains several event types that are more com-
understood and accepted among process modelers. prehensive than most, if not all, other modeling
BPMN utilizes the concept of pools, which can standards. For example, exceptions are an event
contain lanes, to relate external entities. This func- type that exists in the real world and has posed
tionality is extremely important in a world where a great challenge to modelers. Earlier modeling
the linking and automating of processes between notations are not able to adequately represent and
customers and suppliers is essential (Aversano & handle exceptions. In order to address this short-
Canfora, 2002). Incorporating pools and lanes coming, BPMN was developed with a variety of
enables responsibility to be assigned and recog- event symbols related to exception handling.
nized throughout the supply chain. The concepts Process modeling is much more than simply
of lanes and pools are important components in drawing business processes. Modeling requires
visual modeling that clearly bound business areas adherence to standards when graphically depicting
and define ownership and responsibility. a process ecosystem, thereby allowing process
UML is maintaining its popularity as the mod- models to be used for automation, simulation,
eling language of choice for software development. integration, and refinement of existing processes
The Object Management Group’s (OMG) model- (Smith & Fingar, 2003a). Process modelers typi-
driven architecture (MDA) is gaining traction, cally have much discretion in modeling process
with the release of UML 2.0. However, UML was flows, which can lead to inconsistent modeling
originally designed by technical people for techni- practices with prior modeling standards. The

111
The Changing Nature of Business Process Modeling

BPMN standard is simple and flexible, and designed to appeal to both IT and non-IT mod-
enables consistent modeling of joins, forks, and elers of business processes. BPMN is gaining
decisions by formalizing process flow gates. For rapid acceptance; leading modeling-tool ven-
these reasons, BPMN is gaining wide acceptance dors support or plan to support BPMN (Smith
in the business and IT worlds. & Fingar, 2004). This feat is accomplished
by providing simple swim-lane diagramming
ability to non-IT modelers and enabling the
BPMN and UML subsequent addition of technical detail to the
same models as notational properties (i.e., the
UML, conceived in 1996, was designed to pro- gory details are hidden from the nontechnical
vide a common modeling language to support audiences within the tool).
software development. It was adopted and refined If BPMN is accepted into UML, even in part,
by OMG and 21 member companies. Since its BPMI’s efforts will be further legitimized. At
inception, it has become the de facto standard for present, much flux exists in the process model-
visual software development, spawning a host of ing language space. Two languages, BPML and
new products to increase developer productivity BPEL4WS, were viewed as competitors running
and augmenting the functionality of existing a head-and-neck race for market acceptance.
modeling tools. As UML and XMI (i.e., XML However, the broader vision of BPMI is to
metadata interchange, a standard enabling UML have a common modeling notation that gener-
model interchange) advanced, interoperability ates a process modeling language that can be
was made practical among tools traditionally used stored in a process management system, used
for business process modeling and enterprise ar- to manage automated process change within
chitecture, and those used for visual development and between organizations. If OMG adopts
environments (Carlson, 2001). Further advances BPMN, even in part, the likelihood of BPMN
in UML enabled modeling of more complex as the notational support for BPEL4WS dra-
software systems. matically increases.
UML, however, failed to provide the simplic- Long has been the vision of a modeled enter-
ity needed by non-IT business modelers. At best, prise that maintains linkages from the conceptual
a UML activity diagram could be created with business leaders to the operations. However, due
swim lanes to provide the functional equivalence to lack of standards and insufficient tool support,
of swim-lane diagrams; however, adhering to this vision has remained out of sight until now. As
UML standards might be overly burdensome to developers adopt service-oriented architectures
business modelers. OMG recognizes this and is (SOAs), they will continue to rely on UML. As
currently moving up the stack to provide the ap- enterprise architecture continues to evolve to in-
propriate level of standardized modeling language clude enterprise business architecture, enterprise
to enable business modelers to perform their architecture modeling will expand to include
needed tasks without undue effort. BPMN has business modeling. If BPMN is incorporated into
been mapped to the UML standard (Torchiano UML, simple business process models can rapidly
& Bruno, 2003). be extended to generate BPML, BPEL4WS, or ad-
BPMN was developed to provide a common ditional UML diagrams to extend down the MDA
modeling notation to support a common process stack (Frankel, 2003). The vision of an enterprise
modeling language. At the outset, BPMN was repository of accurate models becomes reality as

112
The Changing Nature of Business Process Modeling

UML and MDA enable automation with insurance 3GLs tended to be sequential in nature, lending
against technology obsolescence. themselves to rigid codification of business activ-
ity. Pi calculus enables systems to more closely
resemble real life by providing an environment
A New Paradigm for Process that is parallel, nondeterministic, and tolerant of
Modeling change and ambiguity. Pi calculus enables systems
to treat things as processes and relationships. It
With the introduction of BPMI, Web services, and changes the programming paradigm from pro-
SOA, the enterprise SDLC paradigm is poised cedural and deterministic to one of interrelated
for a dramatic shift. An SOA is a dynamic, gen- processes (Smith & Fingar, 2003b).
eral-purpose, extensible, federated interoperability This shift in thinking enables relationships
architecture. Designing for SOA involves thinking and processes to be automated in a manner that
of the parts of a given system as a set of relatively more closely resembles natural workflow (and in
autonomous services, each of which is (potentially) fact, how computers work at the machine level).
independently managed and implemented, that are Ironically, computers, at the machine level, are
linked together with a set of agreements and pro- well-suited for a pi calculus paradigm; machine
tocols into a federated structure (Clark, Fletcher, language, which manipulates operands within a
Hanson, Irani, & Thelin, 2002). For enterprise computer’s memory location based on the opera-
application architects and developers, composite tor selected, atomically resembles a pi calculus
applications will be based on the SOA principle of paradigm (Smith & Fingar, 2004). BPML is a
dynamic, extensible, and federated interoperability pi-calculus-based standard text language to
and will be enabled by XML-based technologies define and automate processes developed by
such as Web services (Shegalov, Gillmann, & the Business Process Management Initiative.
Weikum, 2001). BPEL4WS is a pi-calculus-based standard lan-
Mobile calculi, process algebras, and pi cal- guage for automating business processes as Web
culus are forms of mathematics that are of great services. This standard was jointly developed
importance to lines of business, IT professionals, by Microsoft and IBM.
and business architects. Process algebra and pi EBA is a creative process of future-state design
calculus are ushering in a new wave of process of business processes, functions, and organiza-
modeling and management systems. Pi-calculus- tions. Business architects rely heavily on visual
based systems are maturing and becoming the modeling to refine future-state design. Selected
new wave of software infrastructure to manage future-state business design must be implemented,
business processes (Smith & Fingar, 2003b). which usually includes a certain degree of auto-
These systems are being front-ended by BPMN. mation. One of the challenges of EBA has always
Enterprise business architects are embracing been keeping models alive through the system
BPMN because it brings life and longevity to development life cycle (including maintenance
their modeling exercises. and enhancement; Smith, 2003). However, with
Pi calculus systems are becoming prevalent, BPMN, keeping the models current is critical
supported by BPMN. With the advent of third-gen- to keeping the underlying BPMS functioning.
eration languages (3GLs), application developers Also, with BPMN, the underlying pi supports
adopted a paradigm that was procedural and de- simulation, an art returning to popularity within
terministic. This paradigm can be expressed with businesses.
a form of mathematics known as lambda calculus.

113
The Changing Nature of Business Process Modeling

The BPMI formed a subgroup to develop a no- technology suites will be the primary vehicles
tation to front-end its pi-calculus-based language, by which current systems portfolios are transi-
BPML. The BPMN subgroup recognized three tioned to service-oriented architectures (Smith
important things. First, modeling notations needed & Fingar, 2004).
to exist that were interpretable to business audi-
ences and could subsequently be used by solution
delivery specialists; the BPMN subgroup chose Process Modeling
a tiered approach, with the first tier resembling Challenges
swim-lane diagrams. Second, a more detailed
visual modeling notation needed to exist for sys- Faced with a rapidly changing business climate,
tem delivery; BPMN’s tiered approach maps the many organizations are seeking new methods to
swim-lane-like business process modeling nota- enable rapid systems development and modifica-
tion to a more precise technical notation. Third, tion. The promise of universal connectivity offered
the BPMN subgroup recognized that BPML and by Web services coupled with the promise of
BPEL4WS could merge, converge, or coexist, or technology-neutral systems offered by model-
BPML could be replaced by BPEL4WS; the BPMI driven development offers a compelling vision
proactively chose to map its visual notation to of the future of systems design, development,
both BPML and BPEL4WS. Business architects and integration. This not-so-distant future will
and technologists can design models with the be process oriented, with systems designed and
top-tier notation with business leaders, easily created by using a process model to direct the
passing the baton to delivery specialists after a interaction of various systems and human actors.
decision to proceed is made with little or no rework These systems will have their functions exposed
(Delphi, 2001). BPMN enables changing of the as services to achieve maximum accessibility.
visual notation per audience without losing the The process engine technology will capture the
requisite values, properties, or attributes neces- semantics of the business process at various levels
sary to extend to executable process language. (O’riordan, 2002).
This critical functionality was lacking or less Currently, most organizations use business
robust in previous attempts to standardize on a process automation in discrete areas, primarily
notation-to-execute modeling approach (Smith as part of their integration environments. Leading
& Fingar, 2003a). organizations will enable process development
The shift from the use of business process across organizational boundaries, but most will
automation technology as a departmental work- struggle with the business (rather than technologi-
flow and process tool to that of a facilitator of cal) issues associated with these activities. The
enterprise change requires a planned approach process model is becoming a standard part of the
for implementing processes that are aligned with developer tool kit, and standards-based engines
enterprise business strategy. Utilizing this new will shortly replace proprietary ones. Many orga-
paradigm and associated technologies, organiza- nizations are beginning to make advances toward
tions will be able to effectively orchestrate and this future vision, particularly those organizations
execute these processes and move beyond simple that are adopting service-oriented architectures.
automation to business process optimization. The issue of how to deal with the many challenges
Process automation, workflow, and business proof the interim states and advancing this vision
cess management technologies will evolve into incrementally presents a great challenge to the
fully integrated BPMSs in the near future. BPM IT organization.

114
The Changing Nature of Business Process Modeling

The first roadblock organizations encounter on Compounding this issue is the challenge of the
the path toward business process management is its ownership and stewardship of business processes.
basic value proposition. Although many projects Unless an organization has taken an aggressive,
using BPM tools have shown significant value (in process-oriented view toward its business, there
terms of return on investment [ROI]), much of often is a tremendous amount of confusion about
that value comes from the automation of manual process definition and ownership (Adhikari,
processes. These processes, typically those that 2002b). Because the processes whose automation
span organizational boundaries, involve manual can provide the most value often span functional
touches to information and manual decision areas, there are usually no individuals with re-
making that are not tracked through the formal sponsibility for the overall process. Instead, we
automation systems embodied in the enterprise have functional managers, each with individual
applications. The simplest means of creating value responsibility for the subprocess performed by
in this circumstance is to use process automation their areas. Effectively automating these pro-
to automate these manual processes and their cesses requires the creation of new channels of
interfaces to enterprise applications and systems communication as well as new decision processes
(Sharp & Mcdermott, 2001). This is useful since to enable the organizations involved to reach an
it creates automation for manual tasks and often agreement on how to handle the processes.
will significantly reduce the costs and errors in- Another issue affecting the achievement of
herent in those tasks. However, the scope of this this vision is that Web services are not complete.
automation is clearly not the complete process, Although substantial progress is being made re-
but only that portion of it that is reflected in these garding the standards for and interoperability of
manual steps. Web services, the practical use of Web services
Even in this limited-scope case, there can be within corporations is in its early stages (Charfi
significant challenges. The manual processes & Mezini, 2004). The universal connectivity
often are developed to address exceptions and that is required to link a process execution en-
inconsistencies in the formalized processes em- gine with the various actors and systems in the
bodied in the enterprise application portfolio. environment requires a substantial investment
These processes often are either incomplete as in integration technologies, and the minimal
implemented, or the business activities have integration among various components in the
changed yet the process assumptions on which infrastructure demands a substantial investment
the enterprise systems are based have not. In ei- in the software platform. There is little doubt
ther case, one finds a situation where the manual that creating business process models, deriving
parts of the process often are undefined or do not application code from those business models,
have clear rules, roles, or responsibilities. They and monitoring such models can create the
may even contradict logic that is embodied in the right level of organizational linkage between
formal systems. The BPM exercise will highlight IT and business executives. The problem is that
the weaknesses for interaction in the existing much of this is an afterthought in a world that
model (Ettlinger, 2002). Furthermore, many of contains a collection of ERR best in class, and
the manual parts of the process will retain manual legacy applications that are either not modeled
components since they primarily focus on excep- or modeled with multiple tools.
tion handling.

115
The Changing Nature of Business Process Modeling

Conclusion tions that have already committed to transforming

to a process culture. Organizations are looking
Business process modeling is quickly becom- to strategically optimize, automate, and integrate
ing the central point of organization for many key processes to provide seamless service to more
systems. Model-driven development frameworks demanding customers in a multichannel world.
are quickly becoming the preferred platform for To do this effectively, systems must be integrated
service-oriented architecture, and Web services at the process level as well as the data level (Sim-
composite application design, development, and sion, 2000). This environment requires system
deployment (Smith & Fingar, 2004). Business- architects, consultants, analysts, integrators, and
user-oriented modeling environments enable developers that have an organizational perspective
businesspeople to model the process as if it were and a diversified set of skills.
an assembly line of swappable components (tasks)
that can be reordered to achieve various results.
A business process management suite exposes References
these components as XML Web services. BPMN
will offer a common standard for enterprise process Adhikari, R. (2002a). 10 rules for modeling
modeling that has the potential to make the model- business processes. DMReview. Retrieved from
to-execute vision more viable. Business analysts, http://adtmag.com/article.asp?id=6300
process designers, system architects, software
Adhikari, R. (2002b). Putting the business
engineers, and systems consultants that utilize
in business process modeling. DMReview.
process modeling should begin their evaluation
Retrieved from http://adtmag.com/article.
and adoption of emerging business process man-
asp?id=6323
agement suites that utilize BPMN.
These IT professionals must understand foun- Aversano, L., & Canfora, G. (2002). Process and
dational BPM concepts as well as the emerging workflow management: Introducing eservices in
technologies and standards that enable these business process models. Proceedings of the 14th
concepts. With this foundation, they will be able International Conference on Software Engineer-
to better assess the importance of business agility, ing and Knowledge Engineering.
to better perform business process performance
BPMI.org releases business process modeling
analysis, and to model business processes and
notation (BPMN) version 1.0. (n.d.). Retrieved
systems in a manner that expedites development.
April 5, 2005, from http://xml.coverpages.org/
More than technology, becoming an adaptive
ni2003-08-29-a.html
organization requires leadership and change
management. The cross-boundary characteristic Carlis, J., & Maguire, J. (2000). Mastering data
of BPM initiatives creates a unique opportunity modeling: A user driven approach (1st ed.). Ad-
for the leaders of the initiatives to become the dison-Wesley.
enterprise change agents.
Carlson, D. (2001). Modeling XML applications
Corporations are beginning the transformation
with UML. Addison-Wesley.
to a process culture and the implementation of
business process management methodologies and Charfi, A., & Mezini, M. (2004). Service composi-
technologies (Smith, 2003). The first steps can be tion. Hybrid Web service composition: Business
problematic and political, even within organiza- processes meet business rules. Proceedings of

116
The Changing Nature of Business Process Modeling

the Second International Conference on Service Sadiq, S., Orlowska, M., Sadiq, W., & Foulger,
Oriented Computing. C. (2004). Data flow and validation in workflow
modeling. Proceedings of the Fifteenth Confer-
Clark, M., Fletcher, P., Hanson, J. J., Irani, R., &
ence on Australasian Database, 27.
Thelin, J. (2002). Web services business strategies
and architectures. Wrox Press. Sharp, A., & Mcdermott, P. (2001). Workflow
modeling: Tools for process improvement and
Delphi. (2001). In process: The changing role of
application development. Norwood, MA: Artech
business process management in today’s economy.
House.
Retrieved from http://www.ie.psu.edu/advisory-
boards/sse/articles/a4bd42eb1.delphi-ip-oct2001. Shegalov, G., Gillmann, M., & Weikum, M.
pdf (2001). XML-enabled workflow management
for e-services across heterogeneous platforms.
Ettlinger, B. (2002, March 5). The future
The VLDB Journal: The International Journal
of data modeling. DMReview. Retrieved
on Very Large Data Bases, 10(1).
from http://www.dmreview.com/article_sub.
cfm?articleid=4840 Simsion, G. (2000). Data modeling essentials:
A comprehensive guide to data analysis, de-
Ewalt, D. W. (2002, December 12). BPML prom-
sign, and innovation (2nd ed.). Coriolis Group
ises business revolution. Retrieved from http://
Books.
www.computing.co.uk/analysis/1137556
Smith, H. (2003, September 22). Business process
Frankel, D. S. (2003). Model driven architecture:
management 101. Retrieved from http://www.
Applying MDA to enterprise computing. Wiley.
ebizq.net/topics/bpm/features/2830.html
Mangan, P., & Sadiq, S. (2002). On building
Smith, H., & Fingar, P. (2003a). Business process
workflow models for flexible processes. Australian
management (BPM): The third wave (1st ed.).
Computer Science Communications, Proceedings
Meghan-Kiffer Press.
of the Thirteenth Australasian Conference on
Database Technologies, 24(2). Smith, H., & Fingar, P. (2003b). Workflow is
just a pi process. Retrieved from http://www.
O’riordan, D. (2002, April 10). Business process
fairdene.com/picalculus/workflow-is-just-a-pi-
standards for Web services: The candidates. Web
process.pdf
Services Architect. Retrieved from http://www.
webservicesarchitect.com/content/articles/orior- Smith, H., & Fingar, P. (2004, February 1). BPM is
dan01.asp not about people, culture and change: It’s about
technology. Retrieved from http://www.avoka.
Reingruber, M. C., & Gregory, W. W. (1994).
com/bpm/bpm_articles_dynamic.shtml
The data modeling handbook: A best practice
approach to building quality data models. Wiley Torchiano, M., & Bruno, G. (2003). Article ab-
& Sons. stracts with full text online: Enterprise modeling
by means of UML instance models. ACM Sigsoft
Software Engineering Notes, 28(2).
Weske, M., Goesmann, T., Holten, R., & Striemer,
R. (1999). A reference model for workflow ap-

117
The Changing Nature of Business Process Modeling

plication development processes. ACM Sigsoft

Software Engineering Notes, Proceedings of the
International Joint Conference on Work Activities
Coordination and Collaboration, 24(2).

118

Chapter VIII
Business Process Integration
in a Knowledge-Intensive
Service Industry
Chris Lawrence
Business Architecture Consultant, Old Mutual South Africa

aBstract

Knowledge-intensive administration and service activity has features favouring a particular architectural
approach to business process integration. The approach is based on a process metamodel that extends
the familiar input-process-output schema, and embodies the principle that the essential WHAT of a pro-
cess is prior to any empirical and/or physical HOW. A structure of interrelated concepts can be derived
from the metamodel. These can be used at logical level to define and analyze processes. They can also
be implemented at a physical level—as an achievable and ideal integrated process architecture, or as
a continuum of incremental control and integration improvements. Overall, the approach is to process
what double entry is to accounting and the relational model is to data.

introDuction for example), sharing important features of the

intended focus area.
The subject of this chapter is not business process The category is not arbitrary. There are things
integration in general, across all industries, but fundamental to knowledge-intensive service
only in the context of a particular but increasingly industries that make a particular architectural
important sector. The category of knowledge- approach to business process integration likely
intensive service industry covers most kinds of to succeed where others might fail.
administration: all financial services, and many A common obstacle to business process in-
areas and levels of government and civil admin- tegration in service industries is that application
istration, education, law, tourism, and so forth. systems are often incompletely process designed,
Although it excludes manufacturing and distribu- or not process designed at all. Related to this,
tion, even these have significant administrative the systems often encourage the view of “busi-
components (order processing and accounting, ness process” as primarily a string of activities

Copyright © 2007, IGI Global, distributing in print or electronic forms without written permission of IGI Global is prohibited.
Business Process Integration in a Knowledge-Intensive Service Industry

performed on or by those systems and therefore tional potential of integrated process architecture
defined in terms of those systems. A more “logi- starts to show.
cal” alternative view of business process as an Where appropriate, the diagrams shown use
ordered satisfaction of a customer’s need is often the emerging BPMN (Business Process Modeling
dismissed as unnecessarily pedantic, analytical, Notation) standard (Business Process Manage-
or purist—not “real world”. In very “real-world” ment Initiative [BPMI], 2004), as does Lawrence
terms, radical critique of the business design (2005). Although BPMN is more customarily used
implemented in an organization’s IT portfolio can for depicting physical processes, no constraint has
be unpopular if it looks an expensive direction. yet been expressed against extending its applica-
But, sometimes you have to swim upstream. tion to processes at a logical level. Indeed, part of
Today’s process-centric enterprise cries out for a the orthodoxy that this chapter challenges is that
logical metamodel to do for process what double process analysis and design begin and end at the
entry did for financial management and the rela- physical, empirical level.
tional model did for data.
This chapter outlines a metamodel that can
revolutionize knowledge-intensive service indus- ProBlem sPace
tries in particular because so much of their pro-
duction-line content is translatable into electronic administration
form. The key is to define the process model at a
logical level (“WHAT”) free from any technical We start by inquiring into the nature of admin-
implementation (“HOW”). For a process-centric istration work: processing applications, granting
enterprise, that logical process model is the core approval, carrying out instructions, and so forth in
of its business architecture. Business process sales, financial services, central and local govern-
integration is then a matter of achieving the best ment, education, tourism, and so on.
possible overall physical engine to implement Administration work typically involves carry-
that process model from available legacy applica- ing out an implicit or explicit “request” from, or
tions, applied investment opportunity, and expert on behalf of, a “customer.” It is usually governed
development resources. by rules. There are right ways and wrong ways
of doing things: rules about standard cases and
exceptions, about sequence and completeness
BackgrounD criteria.
Administration work is also increasingly
The process metamodel outlined here is essen- supported by computer systems. The people
tially the same as that articulated in Lawrence involved increasingly deal with exceptions and
(2005) and reproduced in part in Fischer (2005). special cases, and make rules rather than (just)
In 2004, Old Mutual South Africa adopted it as follow them.
the Old Mutual Business Process Methodology More analytically, we see that administration
(OMBPM). work can be treated abstractly without losing its
An important source of the metamodel is ex- essence. It can be translated into different formats
perience in designing and implementing the sort (e.g., digitized), and so can its rules.
of process-designed systems described in Jackson Take, for example, a life insurance policy. We
and Twaddle (1997). It is in implementation in could define this as a legal contract between a
particular where the full business-transforma- financial organization and another person or or-

0
Business Process Integration in a Knowledge-Intensive Service Industry

ganization in relation to one or more human lives. essential insurance claim process may currently
Almost everything about a life insurance policy operate and be supported.)
and its creation can be treated abstractly—in a A meaningful analogy can be drawn with data
translatable way. You could not say the same about analysis and design. We can decide to consider
making an armchair. only the actual physical databases an organization
A life insurance policy is an abstract entity, has, and what data entities and structures exist
translatable between formats. It must only exist on those physical databases (empirical:HOW).
as hard copy if the rules say so. An armchair is Or we can understand what logical entities are
a concrete object. It cannot be translated into important to the business, what the attributes
another format and stay an armchair. are of those entities, and what numerical and
modal relationships exist between those entities
(essential:WHAT).
analytical aPProach

administration Processes Process metamoDel

The approach starts with a fundamental decision: request and outcome

to see administration processes as things derived
from rules rather than just as things discovered The decision to see processes in this way has
to exist in an organization. It is a decision to see fairly far-reaching consequences.
administration processes as “essential” rather The “empirical” approach (found, for example,
than “empirical.” in many variants of business process reengineer-
To take the paradigm case of financial ser- ing) typically assumes an input-process-output
vices, we would see the business processes metamodel.
connected with, say, a life insurance policy as
derived from rules arising from the contractual input Process output
obligations contained within the product sold to
the customer—obligations that are themselves set There is nothing “false” or “wrong” about this
within an overarching regulatory and/or legislative model as there is nothing intrinsically false or
framework. The processes have a fundamentally wrong about empirically discovered information.
“essential” component and are therefore not just The issue is more one of incompleteness and the
things empirically discovered to exist inside architectural consequences of that incomplete-
the financial services company. (“Process” and ness.
“business process” will be used interchangeably What I have called the “essential” approach
throughout this chapter.) leads to a small but significant refinement.
The approach can be summarized as WHAT
is prior to HOW. In a context like financial ser-
request process outcome
vices, process architecture starts by defining and
analyzing essential business processes (WHAT)
so they can be optimally implemented in available In this metamodel, the process begins with a
or achievable application architecture (HOW). requirement to generate an outcome, and therefore
(A current HOW may of course be empirically to carry out a piece of work. A business process
discovered, for example, the way a contractually is the work needed to carry out something for a

Business Process Integration in a Knowledge-Intensive Service Industry

recipient. A computer system may or may not be

Stable
involved. state
The requirement is typically, but not neces-
sarily, a request or instruction from or on behalf
of a “customer.’ “Typically, but not necessarily” We shall now imagine the organization hit
here means that a process instigated by a customer with a request (from a “customer”) of the type it
request is a paradigm case: it provides the model. can carry out. It starts doing what it knows how
The process ends with an appropriate outcome. to do in conformance to its rules. Person A does
The appropriate outcome is normally the suc- x. This leads to Person B doing y, which needs to
cessful fulfillment of the request—in accordance be approved by Person C. This then means that
with the relevant rules. It could also be the for- Person A can contact the customer and tell him or
mal annulment of the original requirement, for her such and such until the request is either met
example, the cancellation of the original request, or cancelled in some well-formed way.
again in accordance with relevant rules. When that has happened, stability is re-
Example processes conforming to the model stored.
include the following:
request outcome

Processing a customer’s order to buy something

Handling a customer complaint Stable
Unstable state
Stable
state state
Processing an insurance claim
Processing an application to do the following
Join an organization The organization is now in the same state of
Open a bank account stability as before. The period in between (Person
Invest money A doing x, Person B doing y, etc.) was a period
Borrow money of “instability.”
...etc So this is another way of looking at the busi-
ness process.
Examples like these show why a process may
not have only one possible outcome. The goods request process outcome

the customer ordered may or may not exist, the

insurance claim may be honoured or rejected, Stable
Unstable state
Stable
state state
the loan company may accept or reject the loan
application, and so on.
The process is all the events and activities (x,
stable state and unstable state y, etc.) that take the organization (department,
system, etc.) from one state of stability to another:
We shall now look at the model in a different from the initial destabilising event to the restora-
light. tion of stability.
Imagine an organization (or department or
system) whose only role is to carry out one type instance level
of request. Imagine the organization in a state
where it has no request to carry out. It has noth- We are talking about one request—one instance.
ing to do. It is doing nothing. We shall call this The process is all the activities needed to restore
a “stable state.”

Business Process Integration in a Knowledge-Intensive Service Industry

stability in respect to that one initial destabilis- outcome is the thing requested, and the request
ing event. is for the intended outcome.
This thread of intentionality is part of what
one one one
it means to say the process is not arbitrary. The
customer has an intention, which is expressed in
request process outcome the request. The supplier intends to carry out the
request. At the logical level, this intentionality
Stable Unstable state Stable drives the process to completion.
state state

multiple Process instances

The complete description of the process may
include things only applicable to some instances. Now consider an order processing department.
The complete description of an insurance claim The example is deliberately chosen for simplicity
process might need to include sets of ifs. and familiarity, in preference to a more involved
scenario from, for example, financial services.
If the claim amount is more than £1,000, then inform a There will be many orders from many different
claims assessor. customers. The department as a whole will be in
a constant state of instability with respect to at
If the customer has a no-claims bonus, then calculate the least some orders. Individual process instances
bonus reduction. will be at different points. Some will have just
come in. Some will be awaiting credit check.
However, the process itself is not a “batch” Some will be matched against stock. Others will
thing. It is not all the insurance company’s claims, be waiting to be matched, or waiting to be fulfilled
or all the claims of a particular type, or all the or dispatched.
claims coming in on a particular day. I now want to make two fairly obvious as-
This definition of “process” is not arbitrary. sumptions explicit.
A process is not an arbitrary sequence of actions Assumption 1 is that a business area should be
that happen to produce some kind of output from well-managed. It is good to know where things
a particular set of inputs. It is everything that has are rather than not know. Order is better than
to be done to restore the original stability that the chaos.
event or request disturbed. If stability has not Assumption 2 is that it is good to be customer
been restored (if the request has not been met or centric. It is good to look at things from the
annulled), then the process has not finished. customer’s point of view, and to care about the
service customers are getting.
intentionality In a competitive, commercial environment,
these two assumptions are both obvious and
To start with a “request” rather than just an “in- obviously linked.
put,” and to end with a “well-formed outcome” We can now list some desirable features of a
rather than just an “output” is to see a thread of business area that lives by these assumptions. It
intentionality running through the process. An follows rules. It knows how to process different
input would not necessarily be described in the kinds of orders. It follows set procedures. It knows
same words as the resultant output. But, “request” where bottlenecks may occur, and manages its
and “outcome’ share an identity: The (principal) work to minimize bottlenecks.

Business Process Integration in a Knowledge-Intensive Service Industry

It will want to complete each process instance The boundaries between subprocesses often cor-
as fast as possible. This benefits the customer, who respond to bottlenecks, for example, x instances are
will get what he or she wants as soon as possible. awaiting authorisation, y instances are awaiting
It also benefits the business. It improves cash credit check, and so forth.
flow, and also the less work in progress, the less
queries, follow-ups, mistakes, and rework. So, it Subprocesses are not arbitrary collections of
will want to get through each process instance as actions, nor are they events only meaningful in
quickly as possible, and by as standard a route terms of a particular computer system. A subpro-
as possible. cess is something like “check customer’s credit
This brings us to the concept of “subprocess,” rating,” not “run job C123.” So, “subprocess” is
which is an important consequence of the concept not an arbitrary definition.
of “process” articulated so far. A subprocess is not primarily a piece of func-
tionality, either. It is the work needed to get from
subprocess one recognized status to the next, where status
can be described in purely business terms, and
A business process can normally be broken down where the transition from one status to the next
into a finite series of steps or subprocesses: is significant in business terms. Just as a process
is seen in terms of a (single) initiating request
request subprocess subprocess subprocess
outcome
leading to a (single) well-formed outcome, then a
subprocess will also be seen in those terms.
1 2 3

Destabilising
event
restoration
of stability
Take the order process in Figure 1. The notation
is the emerging BPMN standard (BPMI, 2004).
The symbols themselves need not concern us.
The following generic statements can be made The subprocess “check credit rating” is the
about this breakdown: work needed to get an order that has been “matched
against stock.” (See Figure 2.)
The subprocesses will be arranged in a fixed pat- In order to break the process down to a more
tern, typically sequential, although subprocesses granular level, we need a few more analytical
can also occur in parallel. concepts.

Subprocess 1, Subprocess 2, and so forth can be subject entity

described in purely business terms in relation to
what the process is about, for example, authorise This is the object or request moving through the
order, match against stock, and so on. Subpro- process. In the order process, it is the order itself.
cesses have to happen regardless of whether a See Figure 3.
computer system is used or what system is used. It is typically a request (implicit or explicit)
for something to be done. The “something to be
Boundaries between subprocesses often cor- done” is the work of the process.
respond to handoffs and/or break points where There will only be one subject entity per pro-
external interaction is needed, for example, cess instance, for example, Order Number 123.
missing input or authorisation. (Since subprocess It may be linked to a physical object (e.g., an
descriptions will be in business rather than system order form or an insurance claim form), but it
terms, the break points should also be dictated by does not have to be.
business rather than system constraints.)

Business Process Integration in a Knowledge-Intensive Service Industry

Figure 1.

process

Check credit Match against Authorise Despatch

Take order Check order
rating stock order order
+ + + + + +

subprocess

Figure 2.

Check credit Match against Authorise Despatch

Take order Check order
rating stock order order
+ + + + + +

Figure 3.

order order order order order order

Check credit Match against Authorise Despatch

Take order Check order
rating stock order order
+ + + + + +

It may be linked to a data record or data set is operating at (order, customer, portfolio, policy,
(e.g., a policy application, or the details of a switch benefit, etc.), it is important to define what level
request), but it is not primarily a collection of data. the request is at. (This may seem obvious in the
It is primarily an instance of work: a request to abstract, but it is remarkable how often processes
carry something out. are implemented at levels different from the ones
However, the subject entity (request) needs the defining requests are formulated at. This can
to be carefully defined to determine the relevant happen when standard indexing is applied in a
linked data set. To determine what level the process generic workflow implementation.)

Business Process Integration in a Knowledge-Intensive Service Industry

Workflow Status cesses and subprocesses are effectively rules in

graphic notation.
In the example order process, the only way to move There are rules about what processes need to
an order to the state of “awaiting Check order” is occur, rules about what subprocesses a process
by the subprocess “Take Order.” “Awaiting check consists of, rules about the sequence of subpro-
order” just means that point in the process where cesses, and rules about what happens inside a
the “Take Order” subprocess has happened, but subprocess. The “Check order” subprocess could
the check-order subprocess has not yet happened. include the following rules.
We shall call “awaiting Check order” a workflow
status (or process status). See Figure 4. All orders must be for a known customer.
Similarly, the subprocess “Check order” moves
the order from workflow status “Awaiting Check Items must be identifiable as goods the business
order” to workflow status “Awaiting Check credit trades in.
rating.”
Workflow status is expressed in business Quantities must be specified.
terms: “awaiting check order,” not “awaiting
Job C123.” It is not that processes and subprocesses come
The thing that has the workflow status is the first, and then we decide what the rules are. Rules
order: the subject entity. When we get to task come first. The definition of a process is a rule.
level (below), we will see that workflow status can To say where the process starts and stops, and
also be expressed as awaiting a particular task. how the process divides into subprocesses, is to
Since parallel processing is possible at a logical state rules.
level (even if unavailable in a particular physical However, some rules do fit inside other rules.
architecture), a subject entity can have more than There is the rule that you have to do x, and then
one workflow status at the same time. rules about how to do x.

Business rule task

Much of the discussion so far could be expressed “Process” and “subprocess” represent the first
in terms of business rules. The diagrams of pro- two levels of process analysis. Following the

Figure 4.

Check credit Match against Authorise Despatch

Take order Check order
rating stock order order
+ + + + + +

awaiting
awaiting check credit
check order rating

Business Process Integration in a Knowledge-Intensive Service Industry

Figure 5.

apply the …needed to do …and you get

concept of a… …to the the work in a the concept of a

Business rule + Workflow + subprocess task

Figure 6.

Check credit Match against Authorise Despatch

Take order Check order
rating stock order order
+ + + + + +

eg, in the subprocess ‘check order’:

rules about what all orders must be for a known customer

happens inside a items must be identifiable as goods the
subprocess business trades in
quantities must be specified
…etc.

discussion of subject entity, workflow status, and Every order would end up in one of two cat-
business rule, all the foundations are now in place egories: those that obeyed the rules and those that
for articulating the third level, the task. did not. The ones that obeyed the rules would
Task is a component of subprocess, just as go to the next subprocess: “check credit rating.”
subprocess is a component of process. Its place in See Figure 7.
the overall process architecture can be formulated But what about the ones that did not pass? Do
as in Figure 5. they get rejected and discarded? That would be
To explain this, consider the subprocess irrational. An order could fail for many reasons:
“Check order” and example business rules. See it may have been taken wrongly; it may have
Figure 6. gone to the wrong company; it may have one
Imagine these rules being run against the letter missing in the customer name or product
order “automatically”—by a computer program description; and so forth.
or by an employee whose only job is to validate In general, errors and anomalies would need to
the order against the rules. be sorted out “manually”—by using discretion to
see if there is any chance of correcting them and

Business Process Integration in a Knowledge-Intensive Service Industry

Figure 7.

Check credit Match against Authorise Despatch

Take order Check order
rating stock order order
+ + + + + +

no yes

x √

Figure 8.

automatic task:
running the rules and
getting the results

Check order

Automatic Check Match against Authorise Despatch

Take order
check credit rating stock order order
+ + + + +

Manual
correct errors
manual task:
correcting the
once the manual task has completed, the errors
order will need to be checked again against
the same business rules

saving the order. In contrast, applying the rules cess is actually contained within the tasks. The
themselves can be seen as “automatic” work. subprocess is only a container for the tasks, or
We call the two activities “tasks.” See Figure alternatively, an analytical concept required on
8. the way to defining the tasks. (We shall see later
Adding these two tasks to the “Check order” that “subprocess” is not essential at implementa-
subprocess (or, perhaps, more accurately, ana- tion level.)
lyzing the “Check order” subprocess into these Routing will depend on the attributes of the
two tasks) shows that all the work of the subpro- order:

Business Process Integration in a Knowledge-Intensive Service Industry

All orders will go through the automatic task. To reinforce this important development of
the metamodel, we shall repeat the analysis with
Perfectly correct orders will go on to the subpro- the next subprocess: “check credit rating.” Again,
cess of “check credit rating.” the analysis into tasks will depend on business
rules. But here the rules go beyond a simple pass
Imperfect orders will be routed by the automatic or fail.
task to the manual task. The manual task will We shall assume the rules are as shown in
then route them back to the automatic task for Box 1.
rechecking. The rules tell us what events and conditions
the subprocess needs to allow for.
The simple example above demonstrates an
important feature of process-architected design If the criteria of Rule 1 or Rule 2 are met, the
in support of business process integration. subprocess should be passed automatically.
Consider an extreme case of bad data: an order
failing every rule in the “Automatic check” task. Rule 3 needs the subprocess to include manual
It would not be able to move past the subprocess approval.
without every error being corrected. However, it
did get captured. The business does know about it. Rules 4 and 5 need the subprocess to include
It is not sitting around on someone’s desk—outside writing to the customer, and therefore recording
the system. The order has been rejected as data, and acting on the reply, and following up if no
but not rejected as work. reply is received.
This is important for control, measurement,
and completeness. A process designed in this way We could therefore model the subprocess as
may let “garbage in,” but it will not let “garbage in Figure 9.
through.” This is because it is based on a view of An initial automatic task would apply Rules
business process as primarily an ordered satisfac- 1 to 5. Any order passing Rule 1 or Rule 2 would
tion of a customer’s need, not a string of activities go to the next subprocess with workflow status
performed by system components. The “garbage “Awaiting Match against Stock.” An order failing
in, garbage out” design principle derives from Rules 1 and 2, and therefore meeting the criteria
system integrity priorities. There is nothing wrong of Rule 3, 4, or 5 would be routed to a manual
with system integrity, but system or component task.
design decisions should not dictate how business For simplicity’s sake, we shall assume the same
processes are conceived and therefore how process manual task allows for both approval (Rule 3) and
instances are recorded. writing to the customer (Rules 4 and 5).
The concept of task is no more arbitrary than An order that is now manually approved (Rule
that of process or subprocess. Whether a sub- 3) is routed back to the automatic task, which then
process is divided into one, two, or more tasks allows it to pass to the next subprocess.
is decided by the possible attribute values of the Rules 4 and 5 need a manual task for acting
subject entities and related data sets (cases), and on the reply (“manually record documents”) and
what needs to be done to move those possible an “Automatic follow-up” task to loop back if no
objects to the next subprocess. It is not that each reply is received after a fixed period.
of the two tasks represents roughly half the work It should now be clear what was meant by the
of the “Check order” subprocess. That would be formula:
arbitrary.

Business Process Integration in a Knowledge-Intensive Service Industry

Box 1.

Rule 1

IF
Customer has sent cash with order
THEN
Pass credit check

Rule 2

IF
Customer has not sent cash with order
AND
Amount of order not > total current unused credit
AND
Customer is not in arrears
THEN
Pass credit check

Rule 3

IF
Customer has not sent cash with order
AND
Customer is not in arrears
AND
Amount of order > total current unused credit
AND
Customer has enclosed a bank reference justifying the credit increase
THEN
Credit increase needs to be manually approved

Rule 4

IF
Customer has not sent cash with order
AND
Amount of order is not > total current unused credit
AND
Customer is in arrears
THEN
Write to customer requesting payment before accepting order

Rule 5

IF
Customer has not sent cash with order
AND
Customer is not in arrears
AND
Amount of order > total current unused credit
AND
Customer has not enclosed a bank reference justifying credit increase
THEN
Write to customer requesting bank reference before accepting order

0
Business Process Integration in a Knowledge-Intensive Service Industry

Figure 9.

Take order Check order Check credit rating

Match against Authorise Despatch

Manual take Automatic Automatic stock order order
order check credit check
+ + +

pass
or
Manual
correct errors
meets criteria
of , or
approved
(rule )

Manual credit
check

written to customer
(rule or )

Manual
Automatic record
follow up documents

apply the
concept of a… …to the
…needed to do
the work in a
…and you get
the concept of a
Process model
Business rule + Workflow + subprocess task
Having analyzed an individual process down as far
as we need to, we shall now complete the picture
The logic and functionality within a task can by going up in the opposite direction.
be analyzed further. However, this will not affect A trading organization is unlikely to have
workflow. Workflow is established at the task level. just an order process. There will be a number of
(The concept of task employed here makes this process types with relationships (interactions,
true by definition.) dependencies) between them: recording new
Workflow at the subprocess level comes from customers, handling customer data changes (bank
logical sequencing of process rules, ignoring the details, address), ordering stock, billing and set-
variety of individual subject-entity instances tling, recovering bad debts, and so on.
(cases). Workflow at the task level comes from the Many people in the organization will be in-
logistics of applying process rules to the variety volved in more than one process, and many data
of possible cases. entities will be relevant to more than one process:
customers; stock item; sales representative; and
so forth.

Business Process Integration in a Knowledge-Intensive Service Industry

Figure 10.

Business
(area)

Process Process Process

…etc
1 2 3

Subprocess
. Subprocess Subprocess
. .
+ +
M

Subprocess Subprocess
Subprocess . .
A . + +

Subprocess
.
+ Subprocess Subprocess
M . .
+ +
Subprocess
.
A
+
Subprocess . Subprocess
.
+

From a process-architectural perspective, a the initiated process); or one may determine or

business or business area can be analyzed into a influence the outcome of another process instance
finite set of processes. Each process can be ana- already begun by terminating it, suspending it, re-
lyzed into a finite set of subprocesses, and each leasing it from suspense; or creating, amending, or
subprocess can be analyzed into a finite set of deleting data the other process will operate on.
tasks—all following the rules of the business. The process model is ultimately a structure of
The number, nature, and routing of processes, rules. The rules identify a finite set of processes.
subprocesses, and tasks are determined by the The processes are typically the carrying out of
work needed to apply the rules to the attribute requests, which represent what the organization
values of possible cases, where the paradigm is there to do. The rules define possible interac-
“case” is a customer request. tions between processes: how each process breaks
This analysis is the process model (see Figure down into subprocesses, how each subprocess
10). breaks down into tasks, and the number, type,
The double-headed block arrow indicates and routing of those tasks.
that processes interact with each other. One may The process model can be depicted in many
initiate another (by creating the subject entity of ways, but it would typically be a combination of

Business Process Integration in a Knowledge-Intensive Service Industry

diagrams and text. Depending on how detailed value, particularly in management information,
(granular) it was, it could be a complete de- simulation, and so forth, and in implementing
scription of the business or business area at the traceability between a logical model and a physical
WHAT (rules) level. It can provide an overall model. But while physical process architecture
single framework for business analysis, change cannot work without process and task constructs,
implementation, change management, business it can work without a subprocess construct.
management, risk assessment—and computer But to focus on the undeniably necessary
system and architecture design. concept of “task,” what do we mean by saying
that Task X and the component or components
Process model and system Design implementing Task X are different things?
Component functionality implementing a task
The process model as conceived above is a struc- (“get customer details,” “get product details,” etc.)
ture of rules wholly at the WHAT level. It could is more concerned with the data set (e.g., the details
not be built using a concept of business process of the order or of the life insurance application)
as a sequence of activities performed on or by linked to the subject entity than with the subject
components of given physical systems. This is entity itself—the request. The subject entity, the
because those physical components are neces- request, is primarily concerned with intentionality
sarily at the HOW level. (monitoring stages in carrying out the intention),
This does not mean that systems cannot not functionality (what has to happen in order
be designed based on this concept of process carry out the intention).
model—precisely the reverse. Systems can be Keeping these domains separate at the logical
(and have been) designed, built, and implemented level is key to designing process-architected ap-
on the basis of logical process architecture, with plications. The result is that, within the boundary
all the logical concepts physically implemented of a particular system, the business process as
in solution architecture. Whether this option is implemented in that system can be the business
available to an organization is a different ques- process as business users and, where relevant,
tion, depending on that organization’s strategic customers understand it. This is because the con-
options and imperatives at the time. cepts of process, task, and (possibly) subprocess
However, the logical model can represent an will be physically implemented as generic design
attainable ideal, and can therefore be a yardstick constructs.
for evaluating current architecture and the degree So, the physical data model will have a Pro-
to which (and the manner and success by which) cessType entity and a ProcessInstance entity, a
“process” is implemented in that architecture. TaskType entity and a TaskInstance entity, and
Designing, building, and implementing possibly a SubprocessType entity and a Subproces-
process-architected systems awaken the realiza- sInstance entity as well. ProcessType will identify
tion that process components and functionality the processes the organization recognizes (order,
components are actually different things. Process customer creation, payment, etc.), and Proces-
components (process, subprocess, task) are transi- sInstance will record the current and historic
tions in the workflow status of a subject entity. process instances (of the various ProcessTypes)
Functionality components (object, program) are created in response to the received requests
what effect those transitions. (subject entities, cases). TaskType will include,
As mentioned earlier, “subprocess” is not strict- for example, Automatic check, Manual correct
ly necessary at implementation level, although it is errors, Automatic credit check, and so on, and
crucial in process analysis and design. It can have TaskInstance will hold the current and historic

Business Process Integration in a Knowledge-Intensive Service Industry

task instances (of the various TaskTypes) created The present author would claim the metamodel
in response to the rule-determined routing of the can guide and support process integration pre-
subject entity instances. cisely because it can define the target that process
The logical data model requirements are de- integration efforts should aim at. Regardless of
tailed in Lawrence (2005), which also includes a what technology outcome is actually feasible
full case study. However, from the snapshot given (by considering legacy constraints, investment
here, the reader should appreciate the generic and options, timescales, development resources, and
structured implementation of “process” which the development priorities), it is always possible to
approach entails. Because the implementation is define the thing that process integration is about:
generic, the process dynamics can be supplied the business process model.
by a generic process engine or workflow engine The metamodel can be used to define and
that understands the constructs and articulates analyze the processes that interact together to
each instance (of process, subprocess, and task) create the organization’s process model. What
as necessary. happens next will depend on business priorities
The required process or workflow engine is no and development opportunities. At one extreme,
different in principle to the generic functionality there could be a fully process-architected solution
many proprietary workflow packages contain. The encompassing the whole of the organization’s ac-
difference in practice is not so much the engine, tivities, driven and articulated by a single process
but the architectural positioning of proprietary engine. Somewhere near the other extreme will
workflow functionality as necessarily external to be a heterogeneous assortment of applications
an organization’s “administration” system(s)—an supporting the same breadth of activities, but in
often frustratingly inadequate response to the different ways and displaying different approaches
lack of process awareness in many legacy ap- to “process” (including ignoring “process” alto-
plications. gether). However, inroads can be made even in a
scenario like this, as in the following examples:

Process integration The subject entity concept is always useful to define

the level at which to implement a process.
The section immediately above indicates how
the metamodel can be used to guide the design Where a process implemented in one system initi-
of a process-architected system. Because systems ates a process implemented in another system, it
can be built from preexisting components rather may be beneficial to design the interface around
than purely from scratch, it can also guide the the subject entity generated by the one and pro-
reengineering of existing applications into a cessed by the other.
process-architected (or more process-architected)
result. Where a process implemented in one system
“Reengineering existing applications into a employs subordinate functionality in the other, it
process-architected result” and “process inte- may be possible and beneficial to define tasks in
gration” are not far apart. Whether one regards the one which are implemented and/or supported
them as identical or as overlapping areas on a by functionality in the other.
continuum will largely depend on one’s view of
process architecture and its role in operational Where one of the applications has generic pro-
and strategic business activity. cess-engine functionality, it may be possible and

Business Process Integration in a Knowledge-Intensive Service Industry

advantageous to extend its operation to control are frequently seen in terms of implemented
processes implemented in other applications. workflows. In theory, this is right. In practice,
however, the external positioning of proprietary
If an application with process-engine functionality workflow can constrain and frustrate.
initiates a process implemented in another sys- To base a process integration initiative on an
tem, also with process-engine functionality, then external workflow package is not an undertaking
it would be advantageous if possible to define to be considered lightly. Logically, it leads to an
subject entity instances as the formal integration outcome where the workflow package controls
objects between them. everything. All (or most) of the organization’s
functionality would end up logically “inside” the
These suggestions all have the same intention: workflow package, in the sense of being rearchi-
implementing control on the basis of identified tected into components called only by workflow
business processes. Administration systems very components, directly or indirectly. The workflow
often work against this, for example, by provid- package data model should be evaluated to ensure
ing rigid and automated processing of “standard” it is rich enough to reflect the constructs and rela-
cases but inadequate control over exceptions. (An tionships successful process architecture needs.
example is where the garbage in, garbage out The evaluation should presuppose a metamodel
design principle prevents exceptions from being like the one presented here.
captured at all.) Process integration by way of a “business pro-
Another familiar example is where different cess management system” (BPMS) is in principle
solutions (A and B) contain different portions the same as the workflow package route. The dif-
of the organization’s data model, but in order ference is more in the extent and sophistication of
to provide further automation to a process sup- the process management functionality. Admin-
ported by Solution A, access is needed to data istration functionality (the functionality compo-
contained in Solution B. Without an overall busi- nents contrasted earlier with process components)
ness process paradigm, the result can be ad hoc has to be supplied from somewhere: built from
local integration functionality or data replication. scratch, supplied by preexisting administration
The approach gets repeated and then rationalized systems and linked by more or less sophisticated
into sophisticated “interoperability” and “middle- integration, rearchitected from those preexist-
ware” solutions, which assume more and more of a ing administration systems into componentized
controlling role. The business process gets harder services; or combinations of these.
to discern, often only observable in “workflows”
implemented in external workflow packages that
focus primarily on routing links to digitized docu- future trenDs anD research
ments from one person to another.
Mention of external workflow packages brings Business process integration is an essentially
us to what may be the best practical option many practical exercise. Either you integrate processes
organizations will have for implementing or im- or you do not, and you can do it more or less
proving their business process integration. This extensively and/or tightly. Much of the decision
is not because external workflow packages are making about whether or not to use a particular
optimally architected, but because historically metamodel to guide process integration will be
they tend to enjoy an extensive footprint in both economic and logistical, depending on how costly
user and support communities. Business processes it is, how familiar or alien it is to established
development and support teams, and so forth.

Business Process Integration in a Knowledge-Intensive Service Industry

Considerations like these may be quite indepen- conclusion

dent of how sound the metamodel is. As argued
previously, process-architectural thinking is new, Knowledge-intensive administration and service
and established application architecture presents activity has features favouring a view of “business
challenging obstacles. process” as an ordered satisfaction of a customer’s
On the other hand, a significant groundswell need. This differs from, or enhances, a view
is building up in the BPMS and BPM industries. of “business process” as a string of activities
I have deliberately avoided these waters because I performed on or by the particular set of systems
have been intent on mapping the logical, business- an organization happens to have, and therefore
architectural terrain irrespective of technology or defined in terms of those systems.
product sophistication. Administration work can be treated abstractly
However, there is scope here for further naviga- without losing its essence. It is architecturally
tion, for example, whether a BPMS implementa- advantageous to view administration processes
tion needs an overarching process-architectural as essential rather than empirical. This view can
methodology, or whether it is better without, and be summarized as: WHAT is prior to HOW.
if so, why. A line of particular interest is about An empirical approach (as in, e.g., business
the BPMN standard: why it is so rarely used for process reengineering) typically assumes an input-
“logical” process modeling even though no obvi- process-output metamodel. The more essential
ous alternative candidate appears to exist. approach favours an enhanced metamodel where
There is also considerable apparent scope for “customer request” replaces “input,” and “appro-
investigating the relationship between rule-based priate outcome in terms of that request” replaces
process architecture as outlined here and the for- “output.” This enhanced model introduces an
midable business rules industry building up in the element of intentionality into the input-process-
IT environment (Date, 2000; Ross, 2003). output model.
The most intriguing question, though, con- This rule-based metamodel can then generate
cerns process architected systems themselves. a sequence of interrelated analytical concepts:
From personal experience of designing and process, subprocess, task, subject entity, workflow
implementing several of them, I can honestly status, process interaction, and process model.
say I have not yet come across a better paradigm. Where there is development and transition
Yet, why are they so rare? Is it immaturity of opportunity, these analytical concepts can trans-
process thinking in the IT community that causes late into physical design constructs to implement
suboptimal implementations, and therefore the integrated process architecture, on the basis of a
paradigm itself loses credibility? Is it the weight structured physical data model articulated by a
of established IT legacy, and the still-prevailing workflow or process engine.
investment principle of reuse, then buy, then Where less opportunity exists, the approach
build? Is it that, despite its comprehensibility still provides a continuum of possibilities includ-
and comprehensiveness at the logical level, true ing the evaluation of current application archi-
integrated process architecture resists translation tecture from a process perspective, pragmatic
into marketable product? recommendations and design patterns for the
allocation of control and incremental integra-
tion, and an ideal logical framework to serve as
a strategic target.

Business Process Integration in a Knowledge-Intensive Service Industry

references

Business Process Management Initiative (BPMI).

(2004). Business process modeling notation
(BPMN) specification (Version 1.0).
Date, C. J. (2000). What not how: The business
rules approach to application development.
Boston: Addison-Wesley.
Fischer, L. (Ed.). (2005). Workflow handbook
2005. Lighthouse Point, FL: Future Strategies
Inc.
Jackson, M., & Twaddle, G. (1997). Business
process implementation: Building workflow
systems. Harlow, England: Addison Wesley Long-
man Limited.
Lawrence, C. P. (2005). Make work make sense:
An introduction to business process architecture.
Cape Town, South Africa: Future Managers
(Pty) Ltd.
Ross, R. G. (2003). Principles of the business rule
approach. Boston: Addison-Wesley.

Section III
Integration Methods
and Tools

Chapter IX
A Systematic Approach for the
Development of Integrative
Business Applications
Michalis Anastasopoulos
Fraunhofer Institute for Experimental Software Engineering, Germany

Dirk Muthig
Fraunhofer Institute for Experimental Software Engineering, Germany

aBstract

Modern business applications consist of many subsystems (or components) potentially developed and
maintained by diverse organizations. Generally, there are three different points of view. First, organiza-
tions using business applications are interested in the unified look and feel of composed applications,
the maximum interoperability and synergetic features among subsystems, the high availability of all
subsystems, and quick and seamless updates after new releases or bug fixes. Second, organizations
providing single subsystems want, on the one hand, of course, to satisfy their customers and business
partners, but on the other hand, to minimize their overall effort. Third, organizations integrating single
subsystems aim at a uniform and cost-efficient integration architecture. This chapter takes the two latter
viewpoints and describes a methodology for organizations integrating their subsystems with many busi-
ness applications and all relevant types of subsystems, as well as with the whole family of subsystems
from different vendors. The methodology is a product-line approach optimally tailored to the needs of
such organizations. It views subsystems delivered by a single organization with all corresponding in-
tegration contexts and requirements as a family of similar systems, and engineers this family by taking
systematical advantage of common characteristics and proactively considering differences in antici-
pated future scenarios. The methodology is based on Fraunhofer PuLSE™ (PuLSE™ is a trademark
of the Fraunhofer Gesellschaft), a customizable product-line approach validated in practice by many
industry organizations since 1997. The integration methodology has been developed in the German
research project UNIVERSYS by tailoring Fraunhofer PuLSE™ together with industry partners to the
integration context described.

Copyright © 2007, IGI Global, distributing in print or electronic forms without written permission of IGI Global is prohibited.
A Systematic Approach for the Development of Integrative Business Applications

introDuction products are not affordable for SMEs, they mainly

focus on the technical realization of integrative
Modern business applications consist of many solutions and do not provide concrete method-
subsystems (or components) potentially devel- ological support. Additionally and maybe most
oped and maintained by diverse organizations. importantly, existing EAI frameworks explicitly
Consequently, installing such a business applica- deal neither with the different EAI viewpoints
tion includes a significant effort in integrating all nor with the flexibility expected from an EAI
required pieces, typically subsumed by the term solution. Therefore, the section “Related Work”
enterprise application integration (EAI). provides a survey of existing EAI methodologies
There are generally three different points of and identifies their support for the two viewpoints
view for looking at EAI solutions. First, organiza- addressed in this chapter.
tions using business applications are interested in The approach presented in this chapter ad-
the unified look and feel of composed applications, dresses explicitly the two different viewpoints
the maximum interoperability and synergetic discussed above, namely, the composition and
features among subsystems, the high availabil- the integration viewpoint, and furthermore pro-
ity of all subsystems, and quick and seamless vides a concrete methodology for the creation of
updates after new releases or bug fixes. Second, integrative software architectures. Finally, the
organizations providing single subsystems, on approach addresses the flexibility issue by view-
the one hand, want to satisfy their customers ing subsystems delivered by a single organization
and business partners; on the other hand, how- with all corresponding integration contexts and
ever, they also want to minimize their overall requirements as a family of similar systems. The
effort. Third, organizations integrating single approach engineers this family by taking system-
subsystems aim at a uniform and cost-efficient atical advantage of common characteristics and
integration architecture. proactively considering differences in anticipated
This article takes the two latter viewpoints future scenarios. The methodology is based on
and describes a methodology for organizations Fraunhofer PuLSE™ (Product Line Software
integrating their subsystems with many business Engineering), a customizable product-line ap-
applications and all relevant types of subsystems, proach validated in practice by many industry
as well as with the whole family of subsystems organizations since 1997. The section “Engineer-
from different vendors. The section titled “EAI ing Approach: Fraunhofer PuLSE™” introduces
Viewpoints” introduces the two viewpoints in the original approach; the section “Developing
more detail. Integrative Business Applications” then presents a
EAI solutions are of special importance to version of it tailored to the addressed viewpoints
small and medium-sized enterprises (SMEs), and scenarios.
which rarely can sell their products as isolated The section titled “Case Studies” then presents
single systems due to their special but limited two real case studies covering both viewpoints;
focus. By their very nature, SME applications are that is, each case study is described by one of the
favorably seen more as one element integrated two special viewpoints. The section “Conclusion
into bigger application suites. and Future Work” concludes the chapter with
Technically, EAI solutions are to date being re- some final remarks and a brief outlook on future
alized with the help of special EAI frameworks or activities.
tool infrastructures. There are numerous products
in this area. Apart from the fact that most of these

0
A Systematic Approach for the Development of Integrative Business Applications

eai vieWPoints along the lines of a well-defined process. In this

case, the composite application is being developed
Each EAI project can be seen either as a composi- with reuse. This means that the major interest lies
tion or as an integration project. The composition in the discovery and efficient selection of various
viewpoint approaches a single integrated system external applications. In other words, the com-
and focuses on customer satisfaction and the mini- posite application must specify the applications
mization of the effort needed for its construction. to be reused in a flexible way. An example of a
The integration viewpoint starts from a single composition is illustrated in Figure 1.
subsystem, which should be reused as often and
as efficiently as possible for creating integrated integration viewpoint
applications. Hence, the integration viewpoint
aims at a uniform and cost-efficient integration On the other hand, an integration project aims at
architecture. the realization of component applications. The
latter are developed for reuse. In this case, the
composition viewpoint interests lie in the creation of qualitative com-
ponents that are worth reusing as well as flexible
In this composition viewpoint, the composite ap- components that can be reused in many different
plication under development plays the role of an situations. Figure 2 illustrates the integration
aggregate that integrates external applications. A viewpoint.
typical example of a composite application is a
process orchestration application that coordinates
the interaction of various underlying applications

Figure 1. Composition viewpoint

application
boundaries

Composite
Application Component
reuse Application A
Alternatives
reuse Component
Application B

reuse
Component
Application C

A Systematic Approach for the Development of Integrative Business Applications

Figure 2. Integration viewpoint

application
Composite
boundaries Application A

make reusable

Component
Application
make reusable

Composite
Application B

relateD Work gineering Approach: Fraunhofer PuLSE™” and

“Developing Integrative Business Applications,”
In spite of the fact that EAI has gained much are not mutually exclusive. The following EAI
importance in the last years, the focus of the EAI approaches rely on rich experiences with EAI
community lies more in the technology and the solutions and therefore can be sensibly combined
technical realization and less in the methodol- with PuLSE™ DSSA, a customizable process,
ogy. There are numerous publications in the EAI which deals explicitly with variability and gen-
domain that provide insights into the principles, erally aims at a complete software engineering
patterns, and tools that can be employed without approach.
discussing engineering approaches to integra- Both of the subsequent approaches reflect the
tion problems. Often, EAI solutions are seen as typical way EAI problems are tackled. That is, the
an art and less as software engineering science composite and component applications are known
(Schmidt, 2002). up front and the resulting EAI architecture is built
Although the differences between a conven- up upon this knowledge. This is the major differ-
tional and an integrative software development entiation point from the PuLSE™ DSSA approach,
approach haven already been identified, none of which aims at engineering flexible, generic EAI
the existing EAI approaches has reached wide ac- solutions for varying composite or component
ceptance. In the following subsections, two of the applications (depending on the viewpoint).
most promising approaches will be presented.
The subsequent approaches and the PuLSE™
DSSA approach, discussed in the sections “En-

A Systematic Approach for the Development of Integrative Business Applications

enterprise integration methodology The approach provides valuable support with

respect to the technical realization of an EAI
The enterprise integration methodology (Lam solution. The lists of common EAI requirements
& Shankararaman, 2004) provides a practical, as well as the various guidelines are especially
step-by-step approach to enterprise integration helpful. However, some parts of the approach
problems. The approach comprises the follow- are not described very precisely. This applies in
ing phases. particular to the transition between phases as well
as to Phases 4 and 5 of the approach.
Understand the Business Process
In this phase, the envisioned business process openeai methodology
integrating various applications is being analyzed.
The respective stakeholders as well as the use The OpenEAI methodology (Jackson, Majum-
cases are specified. dar, & Wheat, 2005) has been derived from the
OpenEAI project, which aims at the analysis
Map onto Components and exploitation of common EAI practices and
After clearly specifying the collaborative business principles. The OpenEAI project defines among
process, the mapping of the activities contained other things a series of templates for the docu-
therein onto application components takes place. mentation of EAI solutions as well as a protocol
This phase can be seen as a feasibility study for the message exchange. All project results are
eventually leading to the adaptation of applica- freely available under the GNU Free Documenta-
tion components. tion License.
The OpenEAI methodology comprises the
Derive the Requirements following top-level steps, which are broken down
In this phase, the requirements on the application into more detailed activities.
components are being concretized. The method
provides checklists for typical technical charac- Analysis
teristics of an EAI solution (e.g., the selection The systems to be integrated are identified, and
of SOAP [simple open access protocol] for the the according analysis documentation templates
communication) that can be applied for each of are filled in, thereby specifying the necessary
the involved applications. data and control flows.

Produce the Architecture Message Definition

In this phase, the overall integration architecture The data flows from the previous step are refined
is being modeled. in terms of XML (extensible markup language)
documents.
Plan the Integration
Based on the integration architecture, the imple- Creation of the Message Objects
mentation steps to follow are being defined. This The XML messages from the previous step are
involves project management, infrastructure ac- automatically transformed into Java objects that
quisition, detailed architectural design, implemen- are optimized for the communication via the
tation, and eventually reengineering of existing Java message service (JMS; i.e., with the help of
applications, and finally quality assurance. tools made available by the OpenEAI application
programming interface [API]).

A Systematic Approach for the Development of Integrative Business Applications

Development engineering aPProach:

The JMS applications are implemented. At this fraunhofer Pulse™
point, the approach is flexible with respect to
the chosen implementation approach (including software Product lines
the provided OpenEAI API) and provides some
general guidelines. Software development today must meet various
demands such as reducing cost, effort, and time
Update the Documentation to market; increasing quality; and handling com-
The implementation results are documented using plexity and product size. Moreover, organizations
a series of available documentation templates. must address the need of tailoring software for
individual customers.
Deploy Organizations trying to comply with the above
The integration solution is deployed and launched. demands are often led to the development and
To this end, the methodology defines a set of maintenance of a set of related software products
deployment patterns illustrating different al- that have common features and differ in context-
ternatives for the physical structuring of the specific characteristics. However, the different
solution. software products are often developed separately.
This means that product variations are handled in
Monitoring an ad hoc way and product similarities are not fully
Monitoring is a continuous process that controls exploited. In other words, each product in such a
the evolution of the integration solution. Analysis family of products is developed as if it was a single
templates are used as the main instrument for one-of-kind system. This leads to uncontrolled
this phase. redundancy, unnecessary development overhead,
and finally failure in responding quickly to new
The main contribution of the OpenEAI meth- customer requirements and market needs.
odology is the variety of available documentation Software product-line engineering (PLE),
templates, which explicitly address the concerns which was originally introduced by Parnas,
of EAI projects. Yet, the respective documenta- promises to avoid these problems by handling
tion schemata are missing that would describe a family of software products as a whole. So,
how the different documents can be structured a software product line is defined as a family
and packaged. The absence of the schemata of products designed to take advantage of their
raises the effort for understanding the templates, common aspects and predicted variability. A
which in some cases are quite complex. Finally, product-line infrastructure aims at developing
it is difficult to estimate whether the proposed generic software assets that are flexible enough to
API brings advantages compared to other EAI cover at the same time various customer require-
programming frameworks since there are no ments. Therefore, these assets contain variability,
published experiences about the exposure to the which is resolved (or instantiated) upon creating
OpenEAI API. a customer-specific solution.
The OpenEAI methodology can also be com-
bined with PuLSE™ DSSA and in particular with Pulse™ overview
the documentation subprocess of the DSSA meth-
odology (see section titled “Documentation”). PuLSE™ is a method for enabling the conception
and deployment of software product lines within
a large variety of enterprise contexts. This is

A Systematic Approach for the Development of Integrative Business Applications

Figure 3. PuLSE™ overview

achieved via a product-centric focus throughout development. For that reason, PuLSE™ was
the phases of PuLSE™, the customizability of its designed to be customizable. The PuLSE™ ini-
components, incremental introduction capability, tialization phase shown in Figure 3 analyzes the
a maturity scale for structured evolution, and given product-line situation in an enterprise and
adaptations to a few main product development accordingly customizes the process. The main
situations (Bayer et al., 1999). idea behind the initialization phase consists in the
PuLSE™ consists of technical and support customization factors and decisions attached to the
components, which accompany its deployment individual technical components. The customiza-
phases as shown in Figure 3. Due to space tion factors are characteristics of great importance
limitations, we will concentrate only on the for the product line under development.
main issues here and especially on the pervasive
computing perspective. Readers more interested Pulse™ Dssa
in the PuLSE™ method are referred to PuLSE™
(2005). The architecture component of PuLSE™ is re-
alized by the PuLSE™ DSSA approach, which
Pulse™ customization integrates architecture development with the
analysis of existing systems in order to obtain a
Methodologies up to date are often criticized for reference architecture that takes optimal advan-
being too heavyweight by imposing, for example, tage of existing systems.
a lot of documentation burden that slows down

A Systematic Approach for the Development of Integrative Business Applications

The approach starts with the understanding of • Bottom-up recovery: Information from
the business goals and requirements for the new existing artifacts is first extracted and then
reference architecture as this will, together with abstracted to higher levels.
the scope of the product family, determine the • View-based architectures as interface:
functionality and qualities that have to be pro- Architectural views are a means of com-
vided. The information from existing systems and munication between design and recovery,
experiences made while developing them support and among stakeholders.
the design of the reference architecture. • Scenario-based reference architecture
This information is obtained by request- definition: The reference architecture of a
driven reverse architecture activities. To achieve product family is designed and evaluated
our goals, we apply the following underlying with the help of prioritized scenarios.
concepts. • Request-driven reverse architecture:
Analysis of the systems and their artifacts,
• Top-down design: The architecture is performed in a request-driven manner,
designed from the top level and detailed in means the right information is provided
several iterations. when it is needed.

Figure 4 illustrates the PuLSE™ DSSA ap-

proach.

Figure 4. The PuLSE™ DSSA approach

146
A Systematic Approach for the Development of Integrative Business Applications

PuLSE™ DSSA Customization Developing Integrative

Support Business Applications

As part of PuLSE™, the DSSA approach is also The proposed approach is based on the
customizable. There are cases in which standard PuLSE™ DSSA architecture presented in “Engi-
or predefined architectural views in a predefined neering Approach: Fraunhofer PuLSE™.” There-
view set are not fitting to the respective con- fore, the following subsections reflect the phases
text. Therefore, DSSA provides an approach of PuLSE™ DSSA. The reverse engineering part
for extending existing view sets that elicits and of the approach has been left out as it was not in
defines the views necessary in a given context the focus of this work.
based on an approach for view-based software
documentation. Stakeholder Analysis
The goal of the view customization activity
is to define an optimal set of architectural views The customization support of PuLSE™ DSSA
that are used to document the architectures of as described in the section “PuLSE™ DSSA
the planned products. There are cases in which Customization Support” is being employed for
an existing view set can be used without adapta- adapting the approach to the characteristics of the
tion. However, often the proposed views are not EAI domain. The following sections will therefore
sufficient to describe all relevant architectural elaborate on the qualities required by the involved
aspects. Then, a new view set must be defined. stakeholders and the respective views.
The process for customizing architecture views
is shown in Figure 5. To prepare the view set defi- Quality Model
nition, business and quality goals are elicited and
documented. These are, together with an existing The first step toward the customization of PuLSE™
view set that is to be extended, the input to the DSSA lies in the definition of a quality model.
actual view elicitation and definition activities. To this end, we employ the first step of the GQM

Figure 5. PuLSE DSSA customization process

147
A Systematic Approach for the Development of Integrative Business Applications

Table 1.

Goal ID G1
Analyze the architecture of a composite application
For the purpose of understanding
With respect to the reuse effect on the development effort
From the
the developer of a composite application
viewpoint of

Table 2.
Goal ID G2
Analyze the architecture of a composite application
For the purpose of understanding
With respect to the maintainability of the composition
From the
the developer of a composite application
viewpoint of

approach (Basili, Caldiera, & Rombach, 1994) for Q4. What was the effort connected to each inte-
the composition and integration scenarios. gration activity?

Composition Viewpoint Q5. What was the experience or background of

For the composition viewpoint, we can define the the involved developers?
following initial goal, which is related to the reuse
of an external application and to the effect of this Q6. How heterogeneous was the external ap-
reuse to the effort required for implementing a plication?
composite application. (See Table 1.)
For this goal, the following questions can be Q7. What was the visibility to the external ap-
formulated, which when answered indicate the plication (e.g., black box)?
degree of fulfillment of the above goal.
Q8. Which level of integration has been
Q1. Which external applications have been already reached?
integrated?
Apart from the effort of a composition project,
Q2. What was the role of the integrated applica- another important quality that must be considered
tions in the composite application? is the maintainability of the solution. Therefore, the
following goal can be defined. (See Table 2.)
Q3. What integration technologies are sup- This goal leads to these subsequent ques-
ported? tions.

A Systematic Approach for the Development of Integrative Business Applications

Q9. What is the impact of changing the interface Q15. Which component services are meant for
of the external application? integration with external applications?

Q10. What is the impact of changing the interface Q16. Which integration technologies are sup-
of the composite application? ported?

Q11. What is the impact of changing the business Q17. What was the effort connected to each in-
logic of the external application? tegration activity?

Q12. What is the impact of changing the business Q18. What was the experience or background of
logic of the composite application? the involved developers?

Q13. What is the impact of omitting the external Q19. How heterogeneous was the composite ap-
application? plication?

Integration Viewpoint Q20. What was the visibility to the composite

The goals and questions for the integration application (e.g., black box)?
viewpoint can be obtained in a similar way. (See
Table 3.) Q21. Which level of integration has been reached?
(See Table 4.)
Q14. Which composite applications are sup-
ported? The questions related to the latter goal are
identical to questions Q9 to Q12.

Table 3.

Goal ID G3
the architecture of a component application
Analyze
(i.e., a part)
For the purpose of understanding
With respect to the reusability of the component application
From the
the developer of a component application
viewpoint of

Table 4.
Goal ID G4
the architecture of a component application
Analyze
(i.e., a part)
For the purpose of understanding
With respect to the maintainability of the component application
From the
the developer of a component application
viewpoint of

A Systematic Approach for the Development of Integrative Business Applications

Required Views the definition of custom views. Furthermore, the

column EAI Layers relates the derived views to
Following the definition of the goals and ques- common EAI realization layers as described in
tions, we can derive the following minimum set of Themistocleous and Irani (2003). Finally, the
architectural views, which provides the required rightmost column maps the views to each of the
information for answering the above questions. EAI viewpoints that we consider. For instance,
The views proposed by the UML 2.0 (unified for the composition viewpoint, the activity view
modeling language) specification are used as a is recommended, while this view is not required
reference at this point. However, the selection of in the integration viewpoint.
the UML as the notation is not binding.
Table 5 contains a column on the tailoring Planning
required for explicitly addressing the goals de-
fined in the previous sections. This tailoring can In the planning phase, the goals of the EAI project
be accomplished by using the common UML are being refined in terms of scenarios. Here the
extensibility mechanisms through special fea- use-case templates proposed by Cockburn (2001)
tures of the employed modeling tool or through come into play. For the definition and refinement

Table 5. Required views for integrative development

Related Required EAI EAI

View
Questions Tailoring Layer Viewpoint

- Information on the
required effort
Q2, Q4, Q5,
Process
Activity Q7, Q10, Q11, Composition
- Information about automation
Q12
the involved devel-
opers

Transportation, Composition,
Deployment Q5, Q19 None
Translation Integration

- Information on con-
nectors

- Information on
translation between
Q1, Q3, Q4, heterogeneous data
Structure (class) Composition,
Q5, Q6, Q7, schemes
Connectivity
Q8, Q9, Q12-
Interaction Q21 Integration
- Information on the
required effort

- Information about
the involved devel-
opers

0
A Systematic Approach for the Development of Integrative Business Applications

of scenarios, the following scheme can be taken realization

into account.
In the realization phase, the requirements posed
• Data integrationscenarios: Scenarios that by the integration scenarios are realized by mak-
deal with integrating heterogeneous data ing the necessary design decisions. Here the EAI
sources approaches (as described in the introduction), com-
• Application-logic integration scenarios: mon architectural patterns, and design principles
Scenarios that deal with the invocation of can come into play. The EAI literature provides a
external application logic great amount of help in this regard. For example
• Process integration scenarios: Scenarios Themistocleous and Irani (2003) define the fol-
that deal with the development of collab- lowing layers, which should be part of every
orative business processes (i.e., across the integration solution.
boundaries of a single enterprise)
• Real-time enterprise scenarios: Scenarios • Process automation: Deals with the busi-
that deal with the synchronization of dif- ness processes that consist of activities
ferent business processes connected via a provisioned by the external system
collaborative process • Transport: Deals with the transport of
• Complex event processing scenarios: Sce- messages between heterogeneous systems
narios that deal with the handling of multiple • Translation: Deals with the translation
event streams arising from the integrated between heterogeneous data models
applications • Connectivity: Deals with the access to
external systems
After definition, the scenarios are prioritized
and mapped to the iterations that will follow. For Regarding EAI design decisions, Keller (2002)
prioritizing scenarios, PuLSE™ DSSA provides proposes the following schema.
some common heuristics like the economic value,
the typicality, or the required effort. The latter can • Communication models: Selection of
be supported by the above classification scheme. synchronous or asynchronous communica-
In general, it makes sense to start with data inte- tion
gration scenarios and to move on toward the more • Integration method: Integration over the
complex event handling scenarios. data layer, the graphical user interface, the
Scenarios developed in this phase will even- application interfaces, or over application
tually contain variability. In other words, the components
scenario descriptions can contain optional or • Infrastructure: Selection of a communi-
parameterized sections that will be selected or set cation infrastructure (e.g., object brokers,
according to the variability decision that will be message-oriented middleware, enterprise
made for a specific integration solution. Such a service bus; Chappell, 2004)
variability decision could be, for example, the type
of external system to be integrated. Furthermore, Finally, the literature (e.g., Chappell, 2004;
all unresolved variability decisions for a scenario Fowler, 2005; Hohpe & Woolf, 2004) proposes
are collected in the scenario’s decision model. a series of design patterns as well as workflow
On the other hand, the set of resolved decisions, patterns (Wohed et al., 2003) that are relevant for
which reflect a specific integration solution, are the realization phase.
collected in the scenario’s resolution model.

A Systematic Approach for the Development of Integrative Business Applications

Figure 6. Realization phase

Workflow
Activity patterns
View

Structural Interaction
EAI EAI
View View
structural design
patterns decisions

Deployment EAI
View deployment
patterns

Figure 7. Documentation process

Existing
documentation A vailable Tools
approaches

A nalyse
Necessary existing
V iew s schemata

documentation schema

A nalyze
Create
documentation
documentation plan
schema

The realization phase is also responsible for Documentation

fulfilling the variability, which is eventually con-
tained in the scenarios. In this case, the variable In the documentation phase, the design decisions
sections in the scenarios are to be transformed to made during the realization are documented
variable architectural models. In other words, the according to a documentation scheme, which is
resulting models also contain optional or param- derived as shown in Figure 7. The scheme defines
eterized sections, which must be set according to the types of documents to be produced as well
the scenario resolution models. as their structure and interrelations (cf Bayer,
Figure 6 depicts the ordering of activities in 2004). In other words, the scheme can be seen
the realization process as well as the according as a synonym of the view set discussed in the
patterns and models that can be used as input. section titled “PuLSE™ DSSA Customization
Support.” As shown in Figure 7, one of the inputs

152
A Systematic Approach for the Development of Integrative Business Applications

to the documentation process is the group of views assessment

mentioned in “Required Views.”
Since PuLSE™ DSSA is an iterative ap- In the assessment phase, the integration archi-
proach, the documents are to be updated and tecture is being judged against the integration
refined iteratively. For illustrating the variability requirements. In other words, the goal is to check
in the models, special notations can be used, for to which degree the delivered architecture meets
example, UML stereotypes or special coloring the scenarios of the planning phase as well as
(cf Flege, 2000). additional scenarios that reflect nonfunctional
The consistency and correctness of the pro- requirements like performance or robustness. The
duced documents can be checked by inspection latter can also comprise special interoperability
techniques as proposed, for example, in Software qualities as described, for example, in IEC TC
Inspektion (2006). Perspective-based inspections 65/290/DC (2002).
(Laitenberger, 2000) are especially of interest For the assessment, context-based architecture
at this point as they can enable the inspection evaluation methods such as SAAM or ATAM
of integration architectures from the special are typically used (Clements, Kazman, & Klein,
viewpoint of an EAI stakeholder (i.e., composite 2002). Furthermore, the GQM method discussed
application developer). In this case, the inspection in the section “Quality Model” can come again
process defines the different inspection scenarios into play by establishing a measurement program
based on perspectives and provides concrete that iteratively measures the satisfaction of the
guidelines. For example, the composite applica- composition or integration goals.
tion developer’s perspective could be described
as shown in Box 1.

Box 1.

Composite Application Expert

Introduction

Imagine you are the expert of the composite application under development. Your interest lies in the
efficient reuse of the integrated external applications.

Instructions

For each of the produced architectural documents, do the following.

• Determine the integrated external applications.
• Determine the design decisions made for the integration.

Identify defects in the architecture using the following questions.

• Are the available interfaces to the external applications fully exploited?
• Is there any customization interface of the external applications that has not been used?
• Is the translation between heterogeneous data types being considered?

A Systematic Approach for the Development of Integrative Business Applications

case stuDies which will be realized by the external applications.

For simplicity, the following list contains only a
introduction part of the collected scenarios.

This section will compactly demonstrate the ap- 1. Display the position of a selected object in
plication of the PuLSE™ DSSA approach for two a map obtained from the GIS.
of the cases, which arose in the context of this 2. Obtain the current values of a selected object
work. The first scenario reflects the composition from the PCS.
viewpoint and deals with an ERP (enterprise 3. Synchronize the ERP system data repository
resource planning) application that aggregates an with the repositories of the partner applica-
external GIS (geographical information system) tions.
and a PCS (process control system). The other
case takes the opposite view and deals with the Each of the scenarios contains variability,
integration of the PCS into the ERP system. which reflects the different types of external
systems that can be integrated. The first scenario,
composition viewpoint for instance, contains an optional step, which al-
lows setting the resolution of the returned object
The ERP system under consideration enables bitmap. The third scenario is the most generic
the management of human resources and ob- one as it provides for data synchronization with
jects within an organization. One central system any connected system.
feature is the observation and planning of tasks, After the scenario definition, the scenario
which are carried out on objects. Examples of prioritization took place. The third scenario
objects are devices, sensors, or actuators, and received the greatest priority since the content
examples of tasks are repairs, replacements, or integration on the basis of common metadata is
measurements. known as a foundational step in each integration
Since objects are often scattered on the orga- project (Martin, 2005). The realization of the
nization’s premises, the necessity of integrating third scenario requires the definition of a com-
the geographical information of the controlled mon metadata scheme, which is used in later
objects becomes apparent. This information can iterations for the other two scenarios. The latter
be integrated into the workflow subsystem, which have received equal priorities.
drives the task management and in so doing can In the following, we will focus on the data
facilitate the localization of an object. For the same synchronization scenario, which due to its prior-
reason, the ERP system aims at the integration of ity has been chosen for the first iteration of the
process control for accessing devices remotely and integration architecture. The variability of this
for avoiding costly and error-prone measurements scenario is captured in the following decision
(e.g., meter reading) or calibrations on devices. model. Only the variability that directly affects
the integration solution is listed here. For instance,
Composition Planning the scenario provides for manual or scheduled
initiation of the synchronization procedure. Yet,
During the planning phase, the functionalities of since this decision will be assumed by the ERP
the external applications have been captured in system and does not affect the external GIS or
terms of scenarios. These scenarios practically PCS, it is not listed in Table 6.
represent activities in the overall ERP workflow,

A Systematic Approach for the Development of Integrative Business Applications

Table 6.

ID Decision Possible Resolutions

GIS or
D1 Which external systems are connected?
PCS

What types of modifications can be synchronized Changes or

D2
between data sources? Deletions

Is the synchronization connection No or

D3
secured? Yes

Table 7.
Process Initiate synchronization, show the synchronization data to the user, and
Execution update the ERP repository.
Translate the extracted data to the ERP system environment (e.g., .Net
Translation
framework).
Transportation Transport the extracted data to the ERP system.
Connectivity Send synchronization requests to the external systems.

Composition Realization the diagram in Figure 8 is instantiated as in

Figure 9.
For facilitating the realization of scenarios, the As shown in Figure 9, the activity of initiat-
layers discussed in the section “Planning” come ing synchronization is nested (symbol in the
into play. Here scenarios are being refined as bottom-right corner). For the realization of this
shown in Table 7. The variability of the decision activity, the Web service pattern realization for
model comes into play again in the later phases of .Net has been selected. Therein, the activity iter-
the realization and therefore is not reflected in the ates over all external systems, against which the
table, which for that reason is variance free. synchronization is necessary, and for each case
The realization in the composition viewpoint it uses proxy objects for sending the according
concentrates on reusing external synchronization synchronization messages. The activity is shown
services. The first scenario relies on the creation in more detail in Figure 10. Again, the activity is
of the activity views. The latter are directly as- generic and can be instantiated depending on the
sociated with the process execution layer of the resolution of the decision D1.
previous section. The top-level activity model for Figure 10 contains a conditional node that
the synchronization scenario is depicted in the relates to the decision model discussed in “Com-
UML 2.0 activity diagram in Figure 8. As it can position Planning.” The activity in the if clause
be seen, the diagram is generic as it considers the examines the current resolution model, which is
open decision D1. an instantiation of the decision model where the
In the event of integrating both GIS and PCS according decisions have been resolved. As shown
(i.e., resolving decision D1 in GIS and PCS), in the picture, the resolution model is given as an

A Systematic Approach for the Development of Integrative Business Applications

Figure 8. Generic synchronization activity

Data synchronization

Resolution Model

<<Data store>>
ERP System

Data base

Initiate Synchronization

Update data base

while
External Partners

Import Partner Link

according to Resolution Model

do
Get Data

Figure 9. Synchronization workflow

<<Data store>>
Data base
ERP System

Initiate Synchronization
Update data base
GIS

Get Data
PCS

Get Data

A Systematic Approach for the Development of Integrative Business Applications

Figure 10. ERP system’s “initiate synchronization” activity

initiate synchronization «precondition»

Service Proxies are available
Resolution Model is available

«postcondition»
Service Proxies
Messages sent to external systems

while

Resolution Model Import Service Proxy Classes

according to Resolution Model

Instantiate
Web Service Proxy

if
Check whether
security is supported
in resolution model

Security
support
Get Data on
then Proxy Object

Create Client Certificates

Message

Add Client Certificates to

Web Service Proxy

input to the synchronization activity and must tion “Composition Planning.” The transport and
be available for the activity to be instantiated translation layers are not modeled in this case since
properly. The examination of the resolution model they are realized automatically by the underlying
returns a Boolean value denoting whether security infrastructure (i.e., .Net framework).
is supported in the current setting. If this is the In essence, Figure 11 specifies the remote
case, then the two activities in the then clause are synchronization service. The diagram can be used
being executed and certificates are being added to for deriving a more detailed service description
the service proxies, thereby securing the resulting (e.g., Web services description language, WSDL),
synchronizations. which must then be fulfilled by the external ap-
From the generic synchronization workflow, plications. In the context of this work, it has not
we can now derive the following excerpt of the been necessary to provide any additional trans-
ERP system architecture. The latter is also ge- lation logic that maps the above specification to
neric as it uses the generic ServiceProxy class the external systems. Yet, in many cases this step
that can be instantiated for the different types will be necessary.
of partner systems. Figure 11 provides insights For the implementation of the above architec-
into the connectivity layer discussed in the sec- ture in .Net, the developer must use an alternated

A Systematic Approach for the Development of Integrative Business Applications

Figure 11. Synchronization service specification

cld Partner System

remoteservice

getData

invoke
cld ERP System

serviceProxy
call has certificates
synchronizer clientcertificates
0..* getData 0..*

gisProxy PcsProxy

version of the typical Web service client develop- for the derivation of such scenarios, common
ment process with the .Net framework. The latter interoperability standards have been employed.
begins with the addition of a service reference to For example, the interoperability standard IEC TC
the client development project, followed by the 65/290/DC (2002) defines different compatibility
automatic generation of the proxy classes. For levels. The architecture presented in the section
the above genericness to be accomplished, the “Composition Realization” would fail to reach the
developer must first create the service descrip- fourth level of compatibility, which foresees data
tions and/or proxy classes, and then bound them transfer between heterogeneous applications. The
to concrete implementations. architecture developed so far has support only
for the exchange of object data and not for the
composition assessment exchange of the according data types. In other
words, if a new object type is created in the PCS, it
For the assessment of the synchronization archi- is not possible to synchronize the respective object
tecture, the design decisions that have been taken data across the PCS boundaries. Therefore the
must be evaluated against scenarios that reflect synchronization architecture had to be extended
the goals of the integration. As a starting point with additional operations for the exchange of

A Systematic Approach for the Development of Integrative Business Applications

metadata (i.e., object types), and furthermore a scenarios. Some of these scenarios are listed
common metadata scheme (i.e., common structure below.
of an object type) had to be defined.
1. Read and write access to PCS process vari-
integration viewpoint ables from the ERP system
2. Subscription to PCS events from the ERP
The PCS under consideration enables the remote system
monitoring and diagnostics of facilities (e.g., elec- 3. Read access to the PCS configuration from
tricity and water supply or long-distance heating the ERP system (the configuration contains
facilities). The core of the system is based on so- the set of objects to be monitored from the
called process variables. These are variables that PCS)
represent the status of the monitored facility and
the objects contained therein. An example of such For the same reasons as in the “Composition
a process variable is the fill level of a tank. Planning” section, the third scenario, which
Since the PCS provides low-level technical practically also deals with data synchronization,
information, the integration with high-level ap- received the highest priority. It is interesting to
plications is sensible. The technical information note here that although both synchronization
can be encapsulated and delivered as value-added scenarios have the same semantics, there is a
information to the end user. In particular, it defi- difference in the terminology. Such an issue can
nitely makes sense to support the integration with be addressed by semantic integration, which is
ERP systems, which thereby can reach a high an evolving discipline in the EAI area (Castano
degree of process automation and management. et al., 2005).
For that reason, the PCS aims at enabling the con- In the following, we will focus on the second
nectivity with various ERP systems including, of scenario, namely, the event handling across the
course, the ERP system presented in the section PCS boundaries. The decision model for this
“Composition Viewpoint.” scenario is given in Table 8.

Integration Planning Integration Realization

As prescribed by the methodology, the planning The refinement of the scenario to the EAI
phase included the derivation of integration layers is shown in Table 9.

Table 8.

ID Decision Possible Resolutions

Which external systems are con- ERP system or

D1
nected? ∅

ERP system accesses the PCS for subscribing to PCS

events or
How does the subscription take
D2 PCS accesses the ERP system for connecting PCS events
place?
(e.g., threshold value overrun on Object X) with high-level
ERP event definitions (e.g., Object X alert)

A Systematic Approach for the Development of Integrative Business Applications

Table 9.
Process
Notify subscribers about PCS events.
Execution
Translation Translate the event data to a common event scheme.
Transportation Transport the event data to the external system.
Connectivity Register the ERP system as a subscriber to the PCS.

Figure 12. PCS event service realization

cld PCS

cld Realization

event

Pcsserver eventserver

locallistener

eventservice

getEvents()
subscribe(Listener, ProcessVariable [])
<<optional>> subscribe(Listener, EventDefinitions, ProcessVariable [])
unsubscribe(ProcessVariable [])
getEventDefinitions
subs

y
notif
cr
ibe

cld Partner System

remotelistener

notify(EventObject)
<<optional>> notify(EventObject , EventDefinition)
<<optional>> getEventDefinitions()

0
A Systematic Approach for the Development of Integrative Business Applications

Table 10.

ID Decision Possible Resolutions

For which events can a partner All or

D3
application subscribe? Events marked as external

In the integration viewpoint, the realization of systems. In this way, the flexibility required by
concentrates on the development of a reusable EAI applications can be assured. The proposed
event service that can be used by many external PuLSE™ DSSA approach and its customization
applications. In this case, the activity view is to the EAI domain enables the creation of EAI
not necessary and the developers can focus on applications that are flexible and contain vari-
the service usage view, which is depicted as a ability decisions. The latter are resolved when a
structural diagram in the Figure 12. concrete EAI setting is at hand, thereby producing
Figure 12 contains stereotyped elements that a concrete member of the product family.
reflect the variability of the decision model. More- The application of the approach has shown that
over, the picture depicts the internal realization of the EAI domain is characterized by great variabil-
the event service, which if necessary can be hidden ity, which makes the explicit management of the
from the service user. The diagram provides the variations necessary. Moreover, the customization
connectivity view of the event service. of the PuLSE™ methodology has shown that the
EAI domain has special concerns with respect to
Integration Assessment architectural design, quality assurance, and imple-
mentation. While the implementation concerns
During the assessment of the event service re- enjoy adequate support in the EAI community,
alization, it was noticed that in some cases it is the architecture and quality assurance issues are
not feasible to subscribe an external application not systematically considered. The proposed ap-
to all PCS events, as the latter can be numerous. proach addresses these issues explicitly.
For that reason, it was decided to introduce an There are various research topics that are
additional variability decision. subject to our future investigations. The reverse
This in turn has led to the introduction of an engineering part of PuLSE™ DSSA must be
additional optional class to the design that repre- definitely incorporated in the approach. To this
sents external events (i.e., events that are visible end, the reflection model approach (Murphy &
to external applications). Notkin, 1995) for obtaining the architectures
of existing systems as well as for comparing
the realization of an EAI solution against the
conclusion anD future Work originally envisioned architecture can come into
play. For this, current reflection tools must be
This chapter has presented a methodology for the extended toward special EAI characteristics like
creation of EAI solutions based on the concepts asynchronous messaging or application-server-
of software product-line engineering. The overall based solutions. Furthermore, extending current
idea was to view the external applications with business process technologies like BPEL (busi-
which a given system wants to integrate as a family ness process execution language) with variation

A Systematic Approach for the Development of Integrative Business Applications

management support is also a challenge (see also Cockburn, A. (2001). Writing effective use cases.
Process Family Engineering in Service-Oriented Boston: Addison-Wesley.
Applications [PESOA], 2005). Finally, since EAI
Dumas, A. (2002). Select the best approach
applications are often seen as complex adaptive
for your EAI initiative (Sunopsis White Paper).
systems, it will be of great interest to investigate
Sunopsis, Inc.
whether the flexibility discussed in this chapter
can be completely shifted to the run time, thereby The European enterprise application integration
enabling the dynamic adaptation of EAI systems market. (2001). Frost & Sullivan Studies.
and composite applications in particular.
Flege, O. (2000). System family architecture de-
scription using the UML (Fraunhofer IESE Report
No. 092.00/E). Kaiserslautern, Germany.
references
Fowler, M. (n.d.). Patterns in enterprise software.
Basili, V. R., Caldiera, C., & Rombach, H. D. Retrieved November 2005 from http://www.
(1994). Goal question metric paradigm. Encyclo- martinfowler.com
paedia of Software Engineering, 1, 528-532.
Hohpe, G., & Woolf, B. (2004). Enterprise inte-
Bayer, J. (2004). View-based software documen- gration patterns. Addison-Wesley.
tation. In PhD theses in experimental software
IEC TC 65/290/DC. (2002). Device profile guide-
engineering (Vol. 15). Stuttgart, Germany: Fraun-
line. TC65: Industrial process measurement and
hofer IRB Verlag.
control.
Bayer, J., Flege, O., et al. (1999). PuLSE: A meth-
Jackson, T., Majumdar, R., & Wheat, S. (2005).
odology to develop software product lines. Pro-
OpenEAI methodology, version 1.0. OpenEAI
ceedings of the Fifth ACM SIGSOFT Symposium
Software Foundation.
on Software Reusability (SSR’99), 122-131.
Keller, W. (2002). Enterprise application integra-
Bayer, J., et al. (2004). Definition of reference
tion. Dpunkt Verlag.
architectures based on existing systems, WP
5.2, lifecycle and process for family integration. Laitenberger, O. (2000). Cost-effective detection
Proceedings of the Eureka Σ! 2023 Programme, of software defects through perspective-based
ITEA Project ip02009. inspections. In PhD theses in experimental soft-
ware engineering (Vol. 1). Stuttgart, Germany:
Castano, S., et al. (2005). Ontology-based interop-
Fraunhofer IRB Verlag
erability services for semantic collaboration in
open networked systems. In D. Konstantas, J.-P. Lam, W., & Shankararaman, V. (2004). An enter-
Bourrières, M. Léonard, & N. Boudjlida (Eds.), prise integration methodology. IT Pro.
Interoperability of enterprise software and ap-
Martin, W. (2005). Business integration 2005:
plications. Springer-Verlag.
Status quo and trends. Proceedings of EAI Com-
Chappell, D. A. (2004). Enterprise service bus. petence Days Road Show.
Sebastopol: O’Reilly and Associates, Inc.
Murphy, G., & Notkin, D. (1995). Software re-
Clements, P., Kazman, R., & Klein, M. (2002). flexion models: Bridging the gap between source
Evaluating software architectures: Methods and and high-level models. Proceedings of the Third
case studies. Addison-Wesley. Symposium on the Foundations of Software En-
gineering (FSE3).

A Systematic Approach for the Development of Integrative Business Applications

Process Family Engineering in Service-Oriented

Applications (PESOA). (n.d.). Retrieved November
2005 from http://www.pesoa.org
PuLSE™. (n.d.). Retrieved November 2005 from
http://www.iese.fhg.de/pulse
Schmidt, J. G. (2002). Transforming EAI from
art to science. EAI Journal.
Software inspektion. (n.d.). Retrieved March 2006
from http://www.software-kompetenz.de
Themistocleous, M., & Irani, Z. (2003). Towards a
novel framework for the assessment of enterprise
application integration packages. Proceedings
of the 36th Hawaii International Conference on
System Sciences (HICSS’03).
Wohed, P., et al. (2003, April). Pattern based
analysis of EAI languages: The case of the busi-
ness modeling language. Proceedings of the In-
ternational Conference on Enterprise Information
Systems (ICEIS), Angers, France.

Chapter X
Visual Environment for
Supply Chain Integration
Using Web Services
Guillermo Jiménez-Pérez
ITESM – Monterrey Campus, Mexico

Javier Mijail Espadas-Pech

ITESM – Monterrey Campus, Mexico

aBstract

This chapter presents a software tool to simplify application integration among enterprises. The visual
environment provides facilities to display in a graphical interface the structure of databases and ap-
plications. By clicking in the appropriate tables, functions, and fields, enterprises could specify the data
sources needed for integration. The details of the applications are extracted from WSDL and metadata
definitions. Once the fields for every access are specified, integration code is automatically generated
in either Java or C#. The chapter describes the visual tool and its use for automatic supply chain inte-
gration from metadata or WSDL descriptions. It describes how users specify the data elements and the
integration links and how the code integrating the specified elements is automatically generated. The
generated code uses Web services standards to integrate the specified sources.

introDuction that enterprises developed their applications in

an isolated way, with every department indepen-
Today, for a large number of companies, the dently developing their own applications and data
information systems landscape is a complex mix- storages. Currently, these companies confront the
ture of old and new technologies. Traditionally, necessity of sharing information among those
companies built heterogeneous applications for heterogeneous applications (commonly named
specific problems and took advantage of busi- legacy systems) and the new systems being de-
ness opportunities. The normal approach was veloped (Juárez Lara, 2001). The Internet brought

Copyright © 2007, IGI Global, distributing in print or electronic forms without written permission of IGI Global is prohibited.
Visual Environment for Supply Chain Integration Using Web Services

about an increased necessity for companies: the The chapter is organized as follows. The fol-
needs of Web presence and the integration of lowing section describes the PyME CREATIVA
their systems. project as an example of a project addressed to sup-
As more and more companies pursue the ben- ply chain integration, and presents an overview of
efits of electronic business through the Internet, electronic commerce and supply chain integration.
they face the need of enterprise integration (EI) Then the chapter describes the core technologies
as key technological enabler in transforming their used in implementing the visual tool—EAI, Web
business processes. A typical form of EI is Web services, and code generators—and presents the
integration. In this scenario, a company wants to analysis and design of a visual tool for enterprise
offer its existing products and services over the integration to a supply chain. Next it describes
Internet, so it builds front-end Web systems and a study case of supply chain integration using
integrates them with its back-end legacy systems. the infrastructure described. Finally, results and
A more complex scenario involves enterprise conclusions are given.
application integration (EAI). In this scenario,
the company links up its previously isolated and
separated systems to give them greater leverage the Pyme creativa Project
(Wing & Shankararaman, 2004). An emerging
EI scenario is business-to-business (B2B) inte- The creation of industrial networks to foster the
gration, which occurs when companies integrate competencies of small and medium enterprises
their own business processes with those of their (SMEs) needs integrated information services (e-
business partners to improve efficiency within a services) that enable coordination and cooperation
collaborative value chain. Examples of B2B ap- among the different SMEs, allowing them to share
plications include procurement, human resources, their technological resources, creating virtual or-
billing, customer relationship management ganizations. These e-services should be integrated
(CRM), and supply chains (Medjahed, Benatallah, in an open technological platform that is easy
Bouguettaya, Ngu, & Elmagarmid, 2003). Effec- to access, which is known as an e-hub (Molina,
tive and efficient supply chain integration is vital Mejía, Galeano, & Velandia, 2006). A main goal
for enterprise competitiveness and survival, and in the PyME CREATIVA project is to produce a
with the emergence of the e-business era, supply low-cost management and operational infrastruc-
chains needs to extend beyond the enterprise ture for value-added networks of SMEs. Several
boundaries (Siau & Tian, 2004). The need for steps are being applied to build the infrastructure
supply chain integration techniques and method- defined by a set of services. The first step is defin-
ologies has been increasing as a consequence of ing the business model of value-added networks.
the globalization of production and sales, and the Secondly, one needs to design the IT architecture.
advancement of enabling information technolo- The third step consists of designing the services
gies (Ball, Ma, Raschid, & Zhao, 2002). supporting the operation of the network. Lastly, it
This chapter describes the design and imple- is necessary to use a combination of open-source
mentation of a visual tool for automatic supply technologies to produce a low-cost implementa-
chain application integration by using Web ser- tion of the architecture. The e-hub tries to offer a
vices technologies within the PyME CREATIVA variety of integrated e-services that are necessary
project (explained later). The tool provides visual for dynamic market competition. This e-hub can
specification facilities and the capability of code be seen as a marketplace platform, where SMEs
generation for B2B integration of enterprises in can execute trading processes, purchase orders,
supply chains. supply chain management, request for quotations,

Visual Environment for Supply Chain Integration Using Web Services

and other types of e-services with other SMEs in plant configuration, client-supplier relation
the hub. For the PyME CREATIVA project, the management, and supply chain tracking.
following e-services are being developed and This electronic service is used later as study
integrated within the e-hub architecture. case of visual application integration.

• E-marketing: Integrates different technolo- Figure 1 shows the architecture of an e-services

gies for the development of customizable hub. Many technologies are involved, but the main
portals to allow SMEs to promote their components are a service-oriented architecture
products and services (SOA) and business process management (BPM)
• E-productivity: Incorporates technologies to control the workflow execution within the e-
for the SMEs’ diagnosing, planning, and services. The portal platform is accessible through
monitoring standard Web protocols (hypertext transfer proto-
• E-engineering: Engineering collaboration col [HTTP], Web services description language
that integrates design and manufacturing [WSDL]) and a servlet engine (J2EE). To access
technologies for integrated product develop- the e-services, SMEs deploy their own Web portal
ment that acts as an access point. The following section
• E-brokerage: Integrates technologies to describes the concepts and technologies involved
support the development of virtual organi- in implementing the e-services hub. Open-source
zations, enterprise industrial clusters, and technologies are used to implement the collabora-
so forth tion services to keep cost low for SMEs.
• E-supply: Implements technologies for the
integration of logistic services, industrial

Figure 1. E-services hub architecture

Visual Environment for Supply Chain Integration Using Web Services

Figure 2. Application integration problem domains (Linthicum, 2004)

involveD technologies and share information with other applications or

Web portals.
enterprise application integration Several technologies are available for ap-
plication integration. For example, RPC (remote
Application integration (AI) is a strategic approach procedure call) was one of the first technologies
for binding many information systems together, used to build distributed systems with server-
at both the service and information levels, sup- based applications. Another important technol-
porting their ability to exchange information ogy is RMI (remote method invocation), which
and leverage processes in real time. Application allows the communication between distributed
integration can take many forms, including in- Java objects. CORBA (Common Object Request
ternal application (EAI) or external application Broker Architecture) and DCOM (Microsoft
integration (B2B). AI involves a combination of technology) are component objects models for
issues. Each organization and trading community distributed systems and application interoper-
has its own set of integration issues that must be ability. A newer technology for integration is
addressed. Because of this, it is next to impossible service-oriented application integration (SOAI),
to find a single technological solution set that can which allows enterprises to share application
be applied universally. Therefore, each AI solu- services. Enterprises could accomplish this by
tion will generally require different approaches defining application services they can share. Ap-
(Linthicum, 2004). plication services can be shared either by hosting
For example, in Figure 2, a business process them on a central server or by accessing their
is represented as a set of steps. Each step may interapplication (e.g., through distributed objects
require information from different applications, or Web services; Linthicum, 2004).
and in some cases, applications need to interact

Visual Environment for Supply Chain Integration Using Web Services

Web services provider and invoke the service or interact with

service implementation.
A Web service is a software system designed The technology necessary for SOA implemen-
to support interoperable machine-to-machine tation relies on a common program-to-program
interaction over a network (Haas & Brown, communications model built on existing and
2004). Services are described by interfaces us- emerging standards such as HTTP, XML, SOAP,
ing a machine-processable format (specifically WSDL, and UDDI (universal description, discov-
WSDL). Other systems interact with the Web ery, and integration; Kreger, 2001).
service in a manner prescribed by its descrip- The wide support of core Web services stan-
tion using SOAP (simple object access protocol) dards by major enterprise software vendors is a
messages, typically conveyed using HTTP with key reason why Web services technology prom-
XML (extensible markup language) serialization ises to make application integration both within
in conjunction with other Web-related standards an enterprise and between different enterprises
(see Figure 3). significantly easier and cheaper than before.
In a typical service-based scenario, a service Standards mean that not only applications can be
provider hosts a network-accessible software implemented on different platforms and operat-
module (an implementation of a given service). ing systems but also that the implementations
Figure 3 depicts a service provider that defines a can be modified without affecting the interfaces
service description of the service and publishes (O’Riordan, 2002). To build integration-ready
it to a client or service discovery agency, through applications, the service model relies on SOA.
which a service description is published and As Figure 3 shows, SOA is a relationship of three
made discoverable. The service requester uses a kinds of participants: the service provider, the
find operation to retrieve the service description, service discovery agency, and the service requester
typically from the discovery agency, and uses (client). The interactions involve publishing, find-
the service description to bind with the service ing, and binding operations (Champion, Ferris,

Figure 3. Service-oriented approach (Adapted from Papazoglou, 2003)

Visual Environment for Supply Chain Integration Using Web Services

Newcomer, & Orchard, 2002). These roles and focus on software domains whose components
operations act upon the service artifacts: the ser- are not stand alone, and that are designed to be
vice description and the service implementation plug compatible and interoperable with other
(Papazoglou, 2003). components (Batory & Geraci, 1997).

code generators
visual integration tool
Software system generators automate the de- analysis anD Design
velopment of software. Generators automati-
cally transform specifications of target systems target overview
into actual source code, and rely on libraries
of parameterized, plug-compatible, and reus- PyME CREATIVA requires at least four types of
able components for code synthesis (Batory & integration with the e-services: common legacy
Geraci, 1997). The primary benefit of any code applications, .NET applications, J2EE applica-
generator is to reduce the amount of repetitive tions, and hub internal services. The goal of a
code that must be produced, thus saving time generator aimed at application integration is to
in the development cycle (Whalen & Heimdahl, produce code to integrate the e-services hub with
1999). Another benefit to this approach is the legacy applications and other platforms through
ability to extend the services generated, enabling Web services technologies.
the code generator to act as a force multiplier for Figure 4 shows an overview of the visual
programmers. Having a code generator synthesize tool and involved components. One component
complex code dealing with concurrency, replica- is a graphical user interface (GUI) for visual
tion, security, availability, persistence, and other specification of the integration requirements and
services for each server object will ensure that methods. Basically, the GUI consists of a set of
all servers follow the same enterprise rules. By forms or screens to introduce information related
using a code generator, developers can experiment to application integration. Another component
more rapidly with different architectures. Another performs XML data mapping of the visual speci-
benefit obtained when using a code generator for fication; this component creates an integration
the data layer of enterprise architecture may be its project for each enterprise. A third component is
ability to deal with evolving technology (Whalen the code generator; this component will produce
& Heimdahl). the necessary code to achieve the application
Generators are among many approaches integration through Web services technologies.
that are being explored to construct customized The generated Web services code is deployed in
software systems quickly and inexpensively the Web services container.
form reuse libraries. CORBA, for example, and For implementing a code generator for ap-
its variants simplify the task of building distrib- plication integration in a domain, it is necessary
uted applications from components; CORBA can to analyze and understand the domain processes
simplify the manual integration of independently and operations. Once operations are identified,
designed and stand-alone modules in a hetero- it is necessary to define access methods to the
geneous environment by generating proxies for information involved. Visual integration provides
client interaction with a server. Generators are the integration developer with the necessary
closer to tool kits, object-oriented frameworks, elements to specify the information sources. In
and other reuse-driven approaches because they this way, the integration developer just needs to

Visual Environment for Supply Chain Integration Using Web Services

Figure 4. Visual tool overview

Hub infraestructure

services
.NET

Web
e-Service
Java
Application
Integration
Legacy
apps
Visual
specification Data
mapping

Developer

Code
generator
Visual tool scope

Figure 5. Service-level integration

Web E-Services Hub

App Service Client Internet
Internet Web
Service

Service level
DB
DB

specify the operations in the domain processes environment for application integration into the
through visual selection of information sources e-services hub.
(remote operations). Figure 6 shows the information sources to the
The code generator produces two different visual integration tool: Web service descriptions
code packages: one for the application to be inte- and directives descriptions. From these and the
grated and another for the e-services hub; this is visual specification provided by the integrator,
depicted in Figure 5. The generated code allows the generated code is produced.
the e-hub and clients to interact through a Web In the following sections, the visual tool is
services mechanism such as SOAP messages. modeled using UML (unified modeling language)
The main purpose of a visual integration tool diagrams. The main user of the visual tool is an
is to provide integrators a simple configuration application integrator, in this case called the inte-

0
Visual Environment for Supply Chain Integration Using Web Services

Figure 6. Interfaces of application integration tool

Directives
Web Visual description
Application services Integration files

Code
generator

Database

Generated
code

Figure 7. Introduction of configuration data

gration developer, who is responsible for creating Use Case: Log-In

the integration between the e-services and the
external application. At the log-in step, the developer requires authen-
tication for a specific enterprise. The visual tool
use cases uses a Web service to retrieve the list of enterprises
that belong to the hub.
Use Case: Configuration of Generic Figure 10 shows the log-in screen, where the
Web Services tool shows the list of enterprises (1) belonging the
hub platform. The developer provides a project
In this use case, the developer configures the set name (2) for this specific integration.
of generic Web services, providing the required The developer also has to type a user name
information, which is stored and updated in an and password (3) for the selected enterprise. The
XML file (webservices.xml). authentication process is done by a Web service
Figure 8 shows the screen where this use case deployed in the hub platform, therefore the visual
is executed. The screen has a tree of the generic tool acts as a client of this Web service in order
Web services registered in the visual tool (1). In to secure the use of the information.
another area of the screen (2), it is possible to add
a new generic Web service or edit one.

Visual Environment for Supply Chain Integration Using Web Services

Figure 8. Screen of configuration of generic Web services

Figure 9. Log-in

Figure 10. Screen of log-in

Visual Environment for Supply Chain Integration Using Web Services

Use Case: Web Service and Operation Use Case: Code Generation
Specification
The last step consists of generating the necessary
The following step to achieve application integra- code for both the Web service and the programs
tion is specifying the generic Web service and the at the client side.
operation to be executed by the client program. The developer may independently generate the
Figure 12 shows the screen for this input. The integration code for any operation by returning
screen contains a tree of the generic Web services to the last screen (operation selection). The code
and its defined operations. The developer clicks generation component will take information from
on an operation in the tree and its definition is the generic Web service, operation description,
displayed (2). Then it is possible to select this and directives files associated with the operations
operation for integration (3) and continue with linked to the Web service and generate the code
the code generation step. for the Web service integration mechanism.
Figure 14 shows the screen for the code genera-
tion step. It is possible to generate clients in Java,

Figure 11. Web service and operation specification

Figure 12. Screen of Web service and operation specification

Visual Environment for Supply Chain Integration Using Web Services

Figure 13. Code generation

Figure 14. Screen for code generation

C#, or Visual Basic 6.0 programming languages class Diagrams

(1). The selection of the language involves the tem-
plate adaptations and the creation of the package In order to simplify the description of the main
with the generated source code: the Web service, classes of the visual tool, Figure 15 shows a pack-
the wrapper, and a client. Once the source code age diagram containing the classes belonging to
has been generated, the developer can compile each component and other utilities.
and deploy (2) the generated Web service into As Figure 15 shows, five main packages imple-
the Web services container. The visual tool also ment the software for the visual tool.
generates the proxy classes (3) that implement the
skeletons of the remote Web service and operation. • Visual specification: A set of classes that
Finally, the developer can compile and execute implement screens
(4) both the wrapper and the client in order to test • Code generator: Submodel classes for code
the integration between the client and the remote generation
Web service just created. • Data mapping: Classes for mapping infor-
mation to XML files

Visual Environment for Supply Chain Integration Using Web Services

Figure 15. Main packages of the visual tool

• Utils: Utilities for WSDL documents, where the user can select the generic Web service
project management, and I/O (input/output) corresponding to the e-service and the remote
classes operation for this Web service. The last screen is
• Templates: A set of files that represents the the GenerationForm where it is possible to select
templates assembled by the code genera- the programming language for the client of the
tor remote operation. This form also allows one to
compile and deploy the generated Web service
The following sections describe the class and compile both the wrapper and the client. For
diagrams for the three main components of the instance, in the case of the Java programming
visual tool: visual specification, data mapping, language, the GenerationForm uses Apache Axis
and the code generator. tools to generate proxy classes (stubs and locators)
from a WSDL document. Another screen related
Visual Specification to the PrincipalForm is the ConfigurationForm
where the set of generic Web services are con-
The visual specification package comprises a set figured using the visual tool.
of forms or screens where the developer introduces As Figure 17 depicts, the process to specify
information about the integration. Figure 16 shows the complete integration consists of three steps
the classes that implement the visual specification beginning with a log-in screen, followed by the
package from Figure 15. Web service and operation selection, and final-
The first screen showed by the visual tool is izing with the code generation form. The log-in
produced by the PrincipalForm class, allowing step uses some additional features that the visual
the developer to open or create an integration tool provides like a Web services deployed in the
project. After that, the visual tool shows the hub platform to retrieve a list of enterprises that
LoginForm where an enterprise is selected; belong to the hub platform and to authenticate
the project name, user name, and password are the user or developer who wants to integrate the
entered here. If authentication is successful, the enterprise. The operation selection step involves
visual tool shows the SpecificationForm screen, access to the XML configuration file (webser-

Visual Environment for Supply Chain Integration Using Web Services

Figure 16. Visual specification classes

Figure 17. Visual specification flow

User / Developer Select remote •Web Service

vices.xml) that declares where the generic Web the operation selection step. The code generator
services are deployed. Then, the screen shows a component is explained in the next sections.
tree of the generic Web services from which the
user can select a Web service and an operation Data mapping
through visual selection.
The following XML code is an example of the The data mapping classes implement the func-
webservices.xml file, which contains the declara- tionality to map information using XML directive
tion of a set of URI to WSDL documents. The files. These classes define operations that both
WSDL documents in Box 1 are definitions for the visual specification and code generation classes
generic Web services mentioned before. use to achieve the complete process of code gen-
The last step, code generation, involves a code eration for integration. Figure 18 shows the class
generation functionality to produce the neces- diagram for the data mapping package.
sary code, based on the specified operation in

Visual Environment for Supply Chain Integration Using Web Services

Box 1.

<webservicesbean>
<webservices name=“eSupplyWeb”>
<description>Web service for e-supply hub integration</description>
<WSDL>http://10.17.56.89:8080/axis/services/eSupplyWeb?wsdl</WSDL>
</webservices>
<webservices name=“eMarketingWeb”>
<description>Web service for e-marketing hub integration</description>
<WSDL>http://10.17.56.89:8080/axis/services/eMarketingWeb?wsdl</WSDL>
</webservices>
<webservices name=“eBrokerageWeb”>
<description>Web service for e-brokerage hub integration</description>
<WSDL>http://10.17.56.89:8080/axis/services/eBrokerageWeb?wsdl</WSDL>
</webservices>
</webservicesbean>

Figure 18. Data mapping classes

Visual Environment for Supply Chain Integration Using Web Services

At the top of the class diagram is the Projec-  Relative context of the WSDL (i.e.,
tHandler class that allows retrieving and saving a /axis/services/eSupplyWeb?wsdl)
project (directive files). Once the project is loaded • Operation to execute
or created, it is possible to manipulate its two  Type of data returned by the operation
attributes: the IntegrationInfo and Connection- invocation
Info classes. The IntegrationInfo class includes  Required parameters for the opera-
information for the integration process like the tion
operation and Web service. The ConnectionInfo  Name
class contains the enterprise, user name, and  Type
password for authentication. In order to load the
generic Web services stored in the webservices. Taking as example a service to retrieve work
xml file, the ServiceHandler class implements orders, the directive file for integration through
mechanisms to retrieve information from this Web services is as shown in Box 2.
file. The WSDLParser class reads information This directive specifies an operation named
from each WSDL document (specified in the getWorkOrders, modifying the date parameter
webservices.xml file) such as the set of opera- releaseDate. The operation returns a vector param-
tions, and their types and parameters. Then, the eter getWorkOrdersReturn. In this case, the opera-
ServiceHandler class stores this information in tion accesses a Web service that resides within an
a list of WebService classes. application server implementing HTTP at the IP
The directive files in the visual tool are seen address 10.17.56.89 through port 8080 in the /axis/
as project files because it is possible to open the services/eSupplyWeb context inside the applica-
XML files and recover or save directives. For a tion server. The complete URL (uniform resource
directive representing access to a remote param- locator) specification is http://10.17.56.89:8080/
eter through a Web service interface, the following axis/services/eSupplyWeb?WSDL.
information is required. These previous examples may give a general
idea of the tasks that should be performed by a
• Project name visual specification and integration tool using
• Information for authentication and connec- directive description files as input, and the output
tion that should be produced for service level integra-
 Enterprise to integrate tion. In order to deal with the heterogeneity of data
 User name types, WSDL documents are commonly deployed
 Password with general types that the visual tool converts
• Information for integration to specific types. Within the application systems,
 Language for client and wrapper parameters can be of the following data types.
 E-service to integrate
• WSDL of the generic Web service by in- • String: Data that represent a succession
cluding the URI where the Web service is of ASCII (American Standard Code for
located; is composed by Information Interchange) codes
 Transport protocol (HTTP, FTP [file • String[ ]: Data that represent an array of
transfer protocol], file, etc.) string types
 Host name or IP (Internet protocol) • Integer: Represents an integer quantity
address • Double: Represents a floating point value
 Port • Date: A time-stamp instance

Visual Environment for Supply Chain Integration Using Web Services

Box 2.

<project name=“project1”>
<connectionInfo>
<enterprise>ipacsa</enterprise>
<username>webservice</username>
<password>webservice</password>
</connectionInfo>
<integrationInfo>
<language>net</language>
<serviceInfo name=“eSupply”>
<WSDL>http:// 10.17.56.89:8080/axis/services/eSupplyWeb?wsdl</WSDL>
</serviceInfo>
<operation name=“getWorkOrders”>
<return-name>getWorkOrdersReturn</return-name>
<returnType>vector</returnType>
<inParameters name=“releaseDate” type=“date”/>
</operation>
</integrationInfo>
</project>

• Vector: An array of data objects WServiceGenerator and ClientGenerator. The

first one defines methods for the generation of
Directives represent the basic information a Web service adaptation and a subclass named
necessary to execute operations and their param- WServiceGeneratorJava that implements the
eters. For every access operation, it is necessary to generation functionality for a Web service in
define a set of directives to identify the parameters the Java language, including its deployment. The
involved and the way in which the operation will ClientGenerator subclass defines methods for the
be executed (Web service). In this way, directives generation of clients. There exist three subclasses
are a very flexible mechanism easy to adapt when of ClientGenerator. The ClientGeneratorJava
changes to parameter access are necessary. subclass implements functions for the wrapper
and client generation in Java. Both ClientGen-
code generator eratorCSharp and ClientGenerationVBasic imple-
ment functions for wrappers and clients in C# and
The package of the code generation represents a Visual Basic languages, respectively.
submodel for code generation facilities. The code generator component uses configu-
Figure 19 depicts an interface named Generator ration wizards’ techniques (Jiménez, 2003) to
that defines general methods for all subclasses. generate code based on specifications introduced
There exist two subclasses of the Generator class: through visual screens and stored in XML direc-

Visual Environment for Supply Chain Integration Using Web Services

Figure 19. Code generator classes

Figure 20. Code generator description

Code generator

Data Adapt service Create and

Parse directive •Web Service
mapping Adapt operation Copy files
•Wrapper
•Client

Template
Repository

tive files. This code generator uses a set of generic no-valid markup to compilation or execution, but
templates (known as wizlets) that are adapted once adapted by the visual tool, a new applica-
by the visual tool according to the visual speci- tion with the functionality already implemented
fication of the operation to integrate. The code is created.
generator takes as input an XML file and parses An example of a generic template is the Ja-
the directive file to obtain both integration and vaWrapper.temp template presented in Box 3.
connection information to adapt each template. In the code in Box 3, the no-valid markup (per-
Figure 20 shows the code generator of the visual cent symbols) is underlined; it defines identifiers
tool, which uses a template repository containing that will be replaced by valid code, according to
a number of files, mostly pseudo-applications, the specification in the XML directive. Taking
and some deployment descriptors. They have the example code and the work-orders example,

0
Visual Environment for Supply Chain Integration Using Web Services

Box 3.

//JavaWrapper.temp
import javax.xml.rpc.ServiceException;
import localhost.axis.services.%webservice%.*;
import java.util.*;

public class JavaWrapper {

static %Webservice% proxySOAP = null;
static {

try {
%Webservice%ServiceLocator my%webservice% = new %Webservice%ServiceLocator();
proxySOAP = my%webservice%.get%webservice%();

} catch (ServiceException e) {e.printStackTrace();}

}

public static %Webservice% getProxySOAP() throws Exception{

return proxySOAP;
}

public static void main(String[] args) {

try {
%Webservice% proxySOAP = JavaWrapper.getProxySOAP();
%vars%
//%type% = proxySOAP.%operation%(%params%);

%show_results%
} catch (Exception e) {e.printStackTrace();}
}
} //end of class

a possible output of the code generator could be • Web Service.temp: Template for the Web
the adapted code in Box 4. service that will be deployed
The code has been adapted and is ready to • JavaWrapper.temp: Template for a Java
compile and execute, and the non-valid markups wrapper that makes the connection with the
have been replaced by the appropriate code. The Web service created
most important templates are the following. • JavaClient.temp: Template that uses the
JavaWrapper in order to present an example
of how the integration is performed

Visual Environment for Supply Chain Integration Using Web Services

• Deployment Descriptors: Templates that able files, and XML files. These allow the code
are files for the Web service deployment generator to achieve the complete compilation,
within the Axis container (in the case of deployment, and execution of the new generated
Java) application (both Web service and the wrapper
and client).
There exist other templates such as wrappers
for other programming languages, shell execut-

Box 4.

// JavaWrapper.java
import javax.xml.rpc.ServiceException;
import localhost.axis.services.eSupplyWeb_montemayor_ project1.*;
import java.util.*;

public class JavaWrapper {

static ESupplyWeb_montemayor_ project1 proxySOAP = null;
static {
try {
ESupplyWeb_montemayor_ project1ServiceLocator myeSupplyWeb_montemayor_ project1 = new ESupply-
Web_montemayor_ project1ServiceLocator();
proxySOAP = myeSupplyWeb_montemayor_ project1.geteSupplyWeb_montemayor_ project1();

} catch (ServiceException e) {e.printStackTrace();}

}

public static ESupplyWeb_montemayor_ project1 getProxySOAP() throws Exception{

return proxySOAP;
}

public static void main(String[] args) {

try {
ESupplyWeb_montemayor_ project1 proxySOAP = JavaWrapper.getProxySOAP();
Vector result0 = proxySOAP.getWorkOrders();
for(int c=0;c<result0.size(); c++){String[] data=(String[])result0.get(c);for(int i=0;i<data.length;
i++)System.out.println(data[i]);}

} catch (Exception e) {e.printStackTrace();}

}

} //end of class

Visual Environment for Supply Chain Integration Using Web Services

stuDy case for e-suPPly kOrders operation and an UpdateWOQuantity

service integration operation. For this example, we will use service-
level integration and the visual tool will generate
The previous sections provide a general descrip- Java code.
tion of the technologies necessary for implement-
ing an e-services hub and how a visual environ- Defining Service-Level Integration
ment could be used to simplify interaction with
external applications. Although explanations were Service-level integration is similar to data-level
biased toward PyME CREATIVA requirements, integration. In this case, it is necessary to define
we believe a similar approach could be used to a basic data configuration that contains informa-
implement and integrate applications in other tion about the Web service interface (as described
domains. This section gives more details specific before, the integration will use already deployed
to the e-supply service in the PyME CREATIVA Web services). The use case of the introduction
context to clarify how the infrastructure described of the configuration specified the service-level
simplifies application integration. integration with parameters such as the Web
service, URL, context, and so on. In the same
Process Definition way as the data level, the Web service repository
(in our case the Apache Axis container) is hosted
Supply chain integration (in the PyME CRE- at the IP 138.178.16.3 within the /Axix/Services
ATIVA context) is necessary when a supplier context, accessed through the SupplyService
enterprise (member of the hub platform) wants interface that contains the integration methods.
to update the amount of work orders produced in Then, once this configuration data are specified,
their systems (could be legacy, .NET, or Java). This we can link them with the UpdateWorkOrders
might be necessary because the clients of the sup- process. The methods of the Web service interface
plier enterprise may want to track their purchase are then retrieved, thus the appropriate selection
orders (a purchase order is a set of work orders) of operation can be performed.
submitted through e-supply interfaces. For the retrieve operation, the specification
Figure 21 shows a UML activity diagram consists of the definition of the desired method
describing the steps involved. This process is provided by the Web service interface. The execu-
very simple but will serve as a useful example to tion of this remote method will retrieve work-order
describe the functionality of the visual tool. This information including the ID, requested quantity,
example involves two operations: a RetrieveWor- and quantity produced, and can be stored in a

Figure 21. A supply integration process

Visual Environment for Supply Chain Integration Using Web Services

local variable (i.e., a vector of string arrays) for similar to data-level integration, but the integra-
its manipulation. tion implementation differs in the technologies
For the update operation, using the retrieved used (database in the first case, Java code in the
work orders, it is possible to select the correct last case).
update remote method over the quantity produced
for a work order based in its ID. Similar to data-
level integration, it is necessary to specify two conclusion
parameters for the operation: the ID as a filter
and the new quantity for update. The integration of SMEs to build virtual organiza-
tions of supply chains requires direct access to their
generating and executing ai code databases or wrappers to link applications. Poten-
tially every SME has its own database managers
The specification of the code-generation use case and platforms, thus integration could become a
is similar to that of data-level code generation. nightmare. PyME CREATIVA implements a set
In this case, we need to specify the defined proof e-services for operating virtual organizations
cess, the location of the generated code, and the of SMEs, thus standard interfaces could be de-
platform. The visual tool will generate the same fined. To simplify the interaction of SMEs into
two classes as those for data-level integration the PyME CREATIVA infrastructure, a visual
(UpdateWorkOrder.java and ExceuteCode.java), tool to specify integration data and applications
but with different implementation in the first class is very helpful. By extracting metadata from SME
because this class uses Web services technologies databases or using standardized interfaces, the
to access the remote methods. integration code could be generated. This chap-
For example, a code snippet of the Update- ter described the aims of the PyME CREATIVA
WOQuantity method is as shown in Box 5. project, its architecture and supported e-services,
The second file (ExecuteCode.java) contains and the specific interoperability needs. The goal
the code to be executed for the instance of is to integrate hundreds of SMEs into the hub,
UpdateWorkOrder in its main method. This is thus it is important to simplify the integration

Box 5.

import axis.services.eSupplyServiceAccess.*; //code generated by wsdl2java Apache Axis tool

public class UpdateWorkOrder{

//connection code
public boolean UpdateWOQuantity(int newQuantity, int id){
ESupplyAccessServiceLocator myService = new ESupplyAccessServiceLocator();
ESupplyServiceAccess mySOAP = myService.geteSupplyServiceAccess();
boolean updateSucces = mySOAP.updateWOQuantity(100,3566121);
//exceptions handling
}
}

Visual Environment for Supply Chain Integration Using Web Services

process as much as possible. The simplest way is Champion, M., Ferris, C., Newcomer, E., &
obviously to have a tool able to generate the code Orchard, D. (2002). Web services architecture
for interoperation. Using the specification of the (Working draft). W3C. Retrieved from http://
databases or applications, the tool generates the www.w3.org/TR/ws-arch/
necessary code. A visual interface presents the
Guzmán Ruiz, F. (2001). Mecanismos de comu-
relevant data, thus by selecting the appropriate
nicación externa para un sistema integrador de
parameters, the code for interoperation is directly
comercio electrónico de negocio a negocio. Un-
generated.
published master’s thesis, Instituto Tecnológico y
Implementing visual generator tools is only
de Estudios Superiores de Monterrey, Monterrey,
possible in very constrained domains where all
Nuevo León, Mexico.
involved variables are known (Jiménez, 2003).
This is the case in PyME CREATIVA as all Haas, H., & Brown, A. (2004). Web services
services and the information interchange needs glossary. W3C. Retrieved from http://www.
are known in advance. Other more open domains w3.org/TR/ws-gloss/
may present more difficulties for automatic code
Jiménez, G. (2003). Configuration wizards and
generation.
software product lines. Unpublished doctoral
The examples presented here concentrate on
dissertation, Instituto Tecnológico y de Estudios
generating Java code for application integration.
Superiores de Monterrey, Monterrey, Nuevo
However, the generator component is based on
León, Mexico.
code templates to generate the integration code,
so with appropriate templates, it would be possible Juárez Lara, N. (2001). Integración visual de apli-
to generate code for different Web services plat- caciones en sistemas de comercio electrónico de
forms, such as Microsoft .NET, for instance. negocio a negocio. Unpublished master’s thesis,
Instituto Tecnológico y de Estudios Superiores de
Monterrey, Monterrey, Nuevo León, Mexico.
acknoWleDgment
Kreger, H. (2001). Web services conceptual ar-
chitecture. IBM Software Group. Retrieved from
The work described here was partially supported
http://www-106.ibm.com/developerworks
by a grant from the Interamerican Bank of De-
velopment for the PyME CREATIVA project and Linthicum, D. S. (2004). Next generation appli-
the ITEM-CEMEX research chair. cation integration. Addison-Wesley Information
Technology Series.
Medjahed, B., Benatallah, B., Bouguettaya, A.,
references
Ngu, A. H., & Elmagarmid, A. K. (2003). Busi-
ness-to-business interactions: Issues and enabling
Ball, M. O., Ma, M., Raschid, L., & Zhao, Z.
technologies. The International Journal on Very
(2002). Supply chain infrastructures: System
Large Data Bases, 12(1).
integration and information sharing. ACM SIG-
MOD Record, 31(1). Molina, A., Mejía, R., Galeano, N., & Velandia,
M. (2006). The broker as an enabling strategy to
Batory, D., & Geraci, B. J. (1997). Composition
achieve smart organizations. In Integration of ICT
validation and subjectivity in GenVoca Generatos.
in smart organizations. Idea Group Publishing.
IEEE Transactions on Software Engineering,
23(2).

Visual Environment for Supply Chain Integration Using Web Services

O’Riordan, D. (2002). Business process standards

for Web services. Web Services Architect. http://
www.webservicesarchitect.com.
Papazoglou, M. P. (2003). Service-oriented com-
puting: Concepts, characteristics and directions.
Proceedings of the Fourth International Confer-
ence on Web Information Systems Engineering
(WISE 2003), 3-12.
Siau, K., & Tian, Y. (2004). Supply chains integra-
tion: Architecture and enabling technologies.
Whalen, M. W., & Heimdahl, M. P. E. (1999).
On the requirements of high-integrity code gen-
eration. High-Assurance Systems Engineering:
Proceedings of the Fourth IEEE International
Symposium, 217-224.
Wing, L., & Shankararaman, V. (2004). An enter-
prise integration methodology. IT Professional,
6(2), 40-48.

Chapter XI
A Framework for Information
Systems Integration in
Mobile Working Environments
Javier García-Guzmán
Universidad Carlos III de Madrid, Spain

María-Isabel Sánchez-Segura
Universidad Carlos III de Madrid, Spain

Antonio de Amescua-Seco
Universidad Carlos III de Madrid, Spain

Mariano Navarro
TRAGSA Group Information, Spain

aBstract

This chapter introduces a framework for designing, distributing, and managing mobile applications
that uses and updates information coming from different data sources (databases and systems from dif-
ferent organizations) for helping mobile workers to perform their job. A summary of the state of the art
in relation to mobile applications integration is presented. Then, the authors describe the appropriate
organizational context for applying the integration framework proposed. Next, the framework components
and how the framework is use are explained. Finally, the trials performed for testing the mobile appli-
cations architecture are discussed, presenting the main conclusions and future work. Furthermore, the
authors hope that understanding the concepts related to the integration of mobile applications through
the presentation of an integration framework will not only inform researchers of a better design for
mobile application architectures, but also assist in the understanding of intricate relationships between
the types of functionality required by this kind of systems.

Copyright © 2007, IGI Global, distributing in print or electronic forms without written permission of IGI Global is prohibited.
A Framework for Information Systems Integration in Mobile Working Environments

introDuction state of the art

Many workers in current organizations perform Mobile computing devices (smart phones, PDAs
their activity in mobile environments. Sellers, (personal digital assistants), tablet PCs, or note-
architects, doctors, veterinarians, and so forth books) increasingly include integrated wireless
perform the most part of their work outside an of- capabilities. Wi-Fi (wireless fidelity, 802.11) access
fice, many of them in cities or at rural and remote points for wireless connectivity have appeared
areas. Moreover, in many cases, the information everywhere. Moreover, a growing number of
required for mobile workers comes from differ- complementary wireless networking standards,
ent information systems and databases owned such as wireless personal area networks (802.15)
by different organizations or providers, so it is and wireless metropolitan area networks (802.16),
necessary to provide mobile workers with devices has evolved. In this sense, the users, who take
(handhelds, pocket PCs [personal computers], their devices everywhere, expect their software
tablet PCs, etc.) with software systems that em- applications to run as they do in the traditional
ploy user interfaces appropriate for this kind of network environment available at their offices.
devices, and with the capabilities for accessing To achieve such functionality transparently,
and updating several information systems. however, these applications must meet a new
In order to solve this problem, an integration set of requirements and support a specific set of
framework, called DAVINCI, has been defined. capabilities related to the following.
DAVINCI is a framework for providing mobile
workers with mobile software applications to • Provision of intelligent roaming capabilities
query and update information coming from dif- to enable users to work without interrup-
ferent and heterogeneous databases. tion, even when network connections are
The DAVINCI project was first tested with disrupted
the main aim of developing a solution to help • Exploitation of multiple network interfaces
veterinarians performing in-field sanitary inspec- in a single device or the ability to select the
tions in cattle holdings across European Union most appropriate connection, for example,
countries; DAVINCI was tested by veterinarian when two or more connections are simul-
services from Spain, Bulgaria, Latvia, and Czech taneously available
Republic. • Synchronization of databases by caching
During these trials, we identified that one of contents to local devices through asynchro-
the main advantages of the DAVINCI architecture nous connections
is its capability to be integrated together with • Access to data and applications on diverse
different European databases for animal health devices through similar user interfaces
controlling (for instance, EUROVET in Bulgaria • Conservation of power at the operating-
or SIMOGAN in Spain registering cattle census system level and maximization of perfor-
and movements). DAVINCI also permits the mance
development of new data warehouse systems
compliant with the previously cited regulation, To implement mobile required functionality,
providing large economic costs savings. On the application architects and developers have at-
other hand, DAVINCI is easily adaptable to proce- tempted to work around such problems without the
dures in different countries, each with a singular benefit of development environments, application
culture and organizational structure regarding the programming interfaces (APIs), or third-party
responsibilities for livestock sanitary control. middleware solutions that are tailored for mobile
environments.

A Framework for Information Systems Integration in Mobile Working Environments

The tools that are available to application archi- cal user interface) in some cases, though
tects and developers to provide this functionality some handhelds are more like older text
are as follows. terminals than PCs. It includes breaking
the messages into smaller chunks, filtering
• Mobile-application architecture guides redundant information, and even logically
• Mobile-computing application servers compressing the data.
• Transaction services, in some cases includ-
mobile-application architecture ing multithreading for heavy volumes and
guides persistency
• Application programming-level interfaces
The purpose of mobile-application architecture with specialized communications proto-
guides is to provide basic principles to design cols
and develop mobile applications, facilitating the
understanding of the high-level issues around Actual implementations of an application
mobility and mobilized software architectures. server vary from one vendor to another. Some
This kind of guides identifies the primary application servers are generic Web servers with
capabilities required of mobile applications, such an SDK (systems development kit) or API capabil-
as efficient resource management, comprehensive ity to pull data from enterprise database systems
context management, encoding, view consistency, and send them to browser-based client software
extended policy and security functionality, du- on a handheld device.
rable storage, and reliable messaging. Depending on the heritage of the vendor and
Examples of mobile-application architecture its core expertise, you can categorize application
guides are the following: servers in the following broad classes.

• Intel® Mobile Application Architecture • Generic application servers with a Web-

Guide (Intel Corporation, 2006) based SDK, for example, Netscape, Micro-
• Mobile Applications: Architecture, Design, soft, Sun, SilverStream, and BEA, may have
and Development (Lee, Schell, & Sche- support for handheld devices and wireless
neider, 2004) networks strapped onto the basic application
server
mobile-computing application • Database vendors’ application servers, for
servers example, Oracle 9i and Sybase’s iAnywhere
application server
Mobile-computing application servers are soft- • Data synchronization vendors, for example,
ware programs that run in a server and provide Puma, Synchrologic, and Extended Sys-
the following functionality. tems
• Specialized Mobile or Web computing
• Application-level logic that handles business application servers, for example, IBM’s
functions involved in a particular organi- WebSphere
zation and its integration with back-end • WAP-centric application servers, like
database or business application systems Nokia’s WAP Server
• Presentation services for the mobile client • E-mail-centric application servers, for exam-
device (handheld computers, notebooks, ple, Microsoft’s mobile Information server
PDAs, etc.). This is also called GUI (graphi- and the EdgeMail application server

A Framework for Information Systems Integration in Mobile Working Environments

Davinci integration • Recovering automatically the inter-

frameWork’s main rupted data messages
characteristics • Selecting the optimal communication
channel depending on the available
Our work applies many of the principles presented bandwidth and the economic costs as-
in the mobile-applications architecture guides sociated
to provide a framework for information systems
integration in mobile working environments, pay- Moreover, the integration framework should be
ing special attention to some problems that are deployed in different technological infrastructure
not well-solved by commercial mobile application coming from different vendors.
servers, related to the following.

1. Provide standardized ways (independent integration frameWork

from the vendor) to accomplish the follow- Working conteXt
ing:
• Define the mobile application’s user Before beginning with the detailed description
interface and establish the data to be of the integration framework, it is necessary to
managed with this application. analyze some of the basic concepts of the working
• Ship the user interface definition and context related to information systems integration
data required to manage mobile ap- in mobile and remote settings. These concepts
plications. are the geographic area, zone of work, protocol,
• Process the user interface definition and campaign, and workers in the field.
data to present mobile applications to
the user. • Geographic area: This is a geographic zone
2. Facilitate the development of mobile ap- that includes geographic locations (repre-
plications that integrate data coming from sented as geographic coordinate points)
the following. where the information management tasks
• Different databases that are stored in are initiated. For example, in the business
different DBMSs (database manage- related to veterinarian control of pets and
ment systems) cattle, a geographic area could be a region
• Other existing systems that have been of a country. In the business of the popula-
programmed in different languages and tion censuses, a geographic area could be a
operative systems town or a district of a large city.
This reduces the time, effort, and cost re- • Work zone: This is a concrete point within
quired for the development phase. a geographic area that will be visited by
3. Optimize communications capabilities by the field workers to perform their concrete
accomplishing the following. tasks. For example, in the business related
• Reducing the size and number of the to veterinarian control of pets and cattle, the
messages interchanged between servers work zones could be each one of the cattle
and client devices holdings and farms to visit. In the business
• Increasing the possibility to adapt of the population censuses, the work zones
the mobile applications integrated to could be the streets or buildings of a town
several different communication ar- or a district of a large city.
chitectures

0
A Framework for Information Systems Integration in Mobile Working Environments

• Mobile workers: They are the people in Each DAVINCI application is composed of a
charge of performing concrete tasks in the set of tasks or activities linked using a precedence
assigned work zones. For example, in the sequence. Each one of these tasks is implemented
business related to veterinarian control of by a form that accesses (external and/or internal)
pets and cattle, the mobile workers will be databases and updates the pertinent informa-
the veterinarians employed to perform the tion through the mobile devices used by mobile
cattle and pet inspection on a farm. In the workers. The forms should be defined using the
business of the population censuses, the standard of XForms.
mobile workers will be the people employed The sequences of forms that define the cam-
to visit each family to fill in the census paign protocol configure the mobile user interface.
forms. Using this user interface, the mobile workers will
• Campaign: A campaign is the grouping be able to manage (querying, modifying, inserting,
of a set of tasks of the same type that will and deleting) the data concerning each protocol
be performed by mobile workers in several task. These data will be stored in local databases,
work zones and geographic areas using the physically located in the mobile devices. In order
same procedure. to relate the data shown by the form and the data
• Protocol: It is the work procedure used in stored in the database, a file, named modelmapper,
a work zone by a mobile worker to satisfy should be defined. These modelmappers define
the objectives established in the campaign the relation between each one of the fields of the
definition. In the scope of this integration form and the concrete field of the local database,
framework (DAVINCI), a protocol is imple- and the way (SQL statements) to access and
mented by means of a set of applications or update the data.
forms that the worker should complete or
execute.

Figure 1. DAVINCI mobile work concepts

A Framework for Information Systems Integration in Mobile Working Environments

According to the concepts presented below, forming several types of mobile work with-
the integration framework works with general out a strong effort in software programming.
concepts, so this architecture is able to be applied These applications are defined by means
to different business areas with very few enrich- of the user interface specification using
ments and/or modifications. XForms language (a standard for defining
The integration framework will only store multimodal and multidevice user interfaces),
generic data on geographic areas, work zones, and the specification of the information
and mobile workers: concretely, its internal identi- sources (server, database, table, and fields)
fier, name, description, and an identifier or code for each user interface element (labels, text
assigned in an external database that contains boxes, combo boxes, etc.) and the policy for
extended information related to the concrete selecting and updating the concrete data of
business area related to the tasks to be performed a form.
by the mobile workers. For example, the data to DAVINCI middleware also permits the use
gather by a veterinarian in a work zone (cattle and adaptation of several software compo-
holding) will be different than the data collected nents for accessing and integrating hetero-
by a questioner in a family house related to a geneous databases that could be merged for
population census. providing the information necessary for a
For access to these extended data that will be concrete mobile software application.
stored in external databases, DAVINCI uses a spe- This middleware also permits one to distrib-
cific data access module denominated DBSync. ute the assignments to each mobile worker
available, send the application and data for
using the software application to perform
integration architecture the work assigned, and receive the data
obtained as a conclusion of the work.
In order to provide support to this working context, c. Moreover, DAVINCI provides some client
the integration architecture suggested is based on components (currently developed for pocket
client-server architecture, with a main module of PCs) that permit the following.
communications and a message dispatcher, al- • The communication with the middle-
lowing the integration of any new service that is ware for receiving the information
designed for a concrete area of business through by the applications and data used and
its connection to the message dispatcher. Fol- updated
lowing this philosophy, DAVINCI’S integration • The use of DAVINCI mobile applica-
architecture is organized in three levels, as it is tions with voice and pointing interfaces,
shown in Figure 2. providing access to additional capabili-
ties related to location- and geographic-
a. DAVINCI provides a user interface (Web information-based services
interface) for defining the process that
should be used by the mobile workers and The following sections describe these three
the connection of this process with the mo- levels in detail.
bile software applications to be used for its
consecution. integration middleware
b. The core services are grouped in DAVINCI
integration middleware, which permits the The components that permit the definition of the
definition of mobile applications for per- user interface of the final integrated user applica-

A Framework for Information Systems Integration in Mobile Working Environments

Figure 2. Integration framework overview

tions (Mobile UI Designer) and the components to Web Interface

access heterogeneous databases (DBSync) should The Web interface provides the required function-
be customizable; that is to say, in the standard alities related to campaign design, the assignment
version of DAVINCI, the core functionalities of of work (in terms of geographic areas or work
these components are provided, but it is neces- zones) to each mobile worker, and controlling
sary to develop simple additional components to the advance of the work corresponding to a
provide the full functionality needed in the final campaign.
solution of the concrete sector. Next, the main functionalities of the Web
Other components with full functionalities, interface are presented in a detailed way.
related to the design of campaigns, the assignment
of individual work to the mobile staff, and the • Design of campaigns: The design of a
synchronization of data and applications between campaign consists of the specification of
the server and the mobile devices, are provided certain items.
in the standard version of DAVINCI, so they do  The tasks to perform

not have to be modified or enriched in any case.  The steps to follow for each task

 The selection of the geographic areas

Customizable Components and/or work zones where the mentioned

tasks should be performed
These components should be applied to adapt As we said previously, a protocol is imple-
and use the integration framework in a concrete mented by an application (or set of forms)
business environment. to complete or execute. Each application is
composed of forms, each of them represent-
ing a task of the protocol. The forms are pre-
sented in sequence, representing in this way

A Framework for Information Systems Integration in Mobile Working Environments

Figure 3. Campaign registration form

Figure 4. Workers’ assignment form

the precedence required among the protocol of the workers assigned to a campaign and
tasks. Once the forms are designed and the selecting the geographic areas or work
work assignments are planned, the forms and zones that mobile workers have to visit to
the related data are sent to mobile workers’ perform the campaign task. Moreover, the
devices. The above-mentioned forms are Web interface permits the campaign man-
designed using the XForms standard. The ager to fix the concrete dates to perform the
query and update functions to process the tasks, configuring the agenda of the mobile
data related to the forms are specified in the workers.
modelmappers files related to the forms. Once the work has been assigned to each
• Campaign work assignment: Once the available mobile worker, the campaign
campaign has been designed, it is possible manager should send the assignments ob-
to begin the assignment planning. The work tained to mobile workers; so, the integration
assignment consists of the determination framework sends, through a message-center

A Framework for Information Systems Integration in Mobile Working Environments

Figure 5. Work-zone selection form

Figure 6. Campaign query form

server component, to the mobile workers’ the mobile applications at the completion of
devices the forms definition, modelmappers each protocol task in every work zone and
files, and necessary data to perform the stored in the DAVINCI internal database.
campaign tasks. In addition, the integration framework allows
At any time, the allocations to the workers the placement of the mobile workers in order
can be modified as long as the work in the to control their availability to receive new
work zone to reassign has not begun yet. assignments. According to the accessories
Also, the planning of a campaign could be installed in the mobile workers’ devices and
consulted about at any time. the coverage of wireless communications
• Control of the state of the work: DAVINCI in the zones where they are, the location
offers the required functionality to control processing will be based on GPS (Global
the advance of the campaign work at any Positioning System) positioning algorithms
time. To achieve this aim, the work zones (without cell-phone coverage) or GSM pro-
assigned to each mobile worker is consulted vider positioning services (with cell-phone
and, for each one of them, the advance degree coverage).
is calculated through the information sent by

A Framework for Information Systems Integration in Mobile Working Environments

Figure 7. Work-zone selection form

Mobile UI Designer external systems. For example, if we are pro-

cessing work zones, which are the places where
The main purpose of this component consists of mobile workers perform their tasks, the DAVINCI
helping mobile-application integrators to design integration system only stores the identifier of the
mobile applications using the XForms standard, zone and the extended information; the proper-
preparing them for their introduction into the ties of the concrete business area are stored in an
DAVINCI integration framework. external system that is conveniently connected.
This component has not been developed yet. Moreover, DAVINCI applications will work
Temporarily, we are using any XML (extensible with data stored in external systems and databases
markup language) editor that is able to process for recovery and modification of the business area
XForm schema. Concretely, during DAVINCI’s information.
deployment in the European veterinarian sector, Next, DBSync’s main functionalities are pre-
the editor used has been XMLSpy. sented in a detailed way.
The activities required for this purpose are
as follows. • Get extended info: In this use case, ad-
ditional information is requested about any
1. Design of the forms of the mobile applica- of the DAVINCI main subjects.
tions following the XForms standard  Work zones
2. Creation of the modelmapper file containing  Geographic areas
the rules of insertion, modification, deletion,  Campaigns
and consultation of the information of each  Workers
form and each data item presented in it The DAVINCI data model holds very little
information about these elements in a generic
DBSync way. Applications may need to show to the
user more detailed data just for information
This module is in charge of the communication purposes. The data obtained by using this
and synchronization of data between the integra- use case is not modifiable by DAVINCI
tion framework (DAVINCI) and any other system middleware, and DAVINCI does not handle
to connect. them in any way but for showing it to the
DAVINCI works with a set of generic concepts Web interface user in the suitable place.
that are easily adaptable to concrete concepts in

A Framework for Information Systems Integration in Mobile Working Environments

Figure 8. DBSync architecture

DAVINCI PLATFORM EXTERNAL APPLICATION PLATFORMS

SQL queries
DBSync data
Connector RDBMS
es
eri
qu
configuration uery
XQ
ta
da

SQL queries
XQuery queries
XQuery queries DBSync data
DBSync Connector RDBMS
data
data server

XQ
ue
ry
qu
erie
s
da
ta SQL queries
DBSync data
Connector RDBMS

• Query data: Several DAVINCI middleware There is no limit on the number of DBSync
components will need to obtain data from connectors that can be used by the DBSync
the data sources integrated in order to send server.
it to the clients for showing and updating. • DBSync server: The DBSync server obtains
That data are queried in a generic way by the access data needed to reach the connec-
using this use case. tors from configuration, but the data can
• Update data: Several DAVINCI middleware also be obtained dynamically.
components will need to update or insert • DBSync connectors: A DBSync connec-
data in the data sources integrated in the tor is in charge of communicating with the
DAVINCI platform. That data usually come DBSync server and performs the required
from data capturing applications used by operation regarding data querying and up-
workers. A certain format is specified to dating. Each connector handles one RDMS
transfer data from clients through DAVINCI and can have its own policies about data
middleware to the original data sources. updating and handling.
The DBSync architecture is shown in
Figure 8. To integrate a new data source into the DA-
DBSync is composed of a server that in- VINCI platform, it is necessary to complete the
teracts with the other DAVINCI modules following steps.
needing data synchronization. The DBSync
server uses different DBSync connectors to 1. Define the data managing policies that will
access different data sources integrated with be used on the data source.
the DAVINCI platform. The data sources
can be located in geographically separated The data updating and querying policies to
points, and can make use of different rela- be used on each data source are to be defined
tional database managing systems (RDMS).

A Framework for Information Systems Integration in Mobile Working Environments

by the owner of the data source. The DAVINCI The data managing policies used by the
platform will provide new data and queries in connector to access its own data source are not
the format specified above through the DBSync restricted and are up to the particular implementa-
server, however it does not specify the way in tion of each DBSync connector.
which that data are to be updated and the queries The connector Web service must be acces-
are to be performed. sible from the DBSync server through HTTP
The following aspects are to be considered in (hypertext transfer protocol) or HTTPS. It can
order to design the data managing policies to be be deployed at any platform able to fulfill that
applied by the DBSync connector. requirement. There is no restriction about the
technologies (programming language, platform
• Data may be overwriting when new data that operating system, applications server, etc.) used
has been captured by DAVINCI clients are to implement and deploy the connector due to its
updated in the data source. The DAVINCI Web service (SOAP, simple open access protocol)
platform does not perform any data storing interface with the DBSync server.
or auditing, thus the DBSync connector An implementation using the same technolo-
should be able to manage data overrides in gies as the rest of the DAVINCI middleware is
a consistent way with the data source. For provided for reference. It is built using the Java
instance, critical data should not be over- programming language and deployable on any
written by new data if there is not a previous J2EE-compliant application server; JBOSS was
check, and historical data might be kept in used during the development stage.
order to roll back to previous states of the The DBSync module receives Xqueries in or-
data source. der to collect information from the database. That
• Security procedures might be implemented kind of queries achieves a high-level abstraction
in order to prevent unauthorized access to over SQL sentences in such a way that the same
data or modifications. This depends on sev- query could be applied over different types of
eral factors such as the physical location of databases (SQL Server, Oracle, etc.).
the data source, the connectivity of it with FLWR is the subset of the Xquery standard
external threats, or application security that will be used by DAVINCI modules. This
requirements. standard defines five operations that could be
• There may be the need to dynamically defined in Xquery.
modify the data access policies. If there is
that need, configurable mechanisms can be • For creates a variable that represents the
implemented for being able to change data table and associates it to a variable.
managing policies at run time. • Where filters the query using data from
tables selected in for expressions.
2. Implement and deploy a new DBSync con- • Return specifies the node set of the output
nector to enable the DBSync server to access document with variable references. After a
to data source. for-in expression completes the iteration,
return delivers the query result document.
A new DAVINCI DBSync connector module
must be implemented when a new data source is There is one more operation offered by the
integrated into the DAVINCI platform. FLWR standard, denominated let. However, this
The connector must expose a Web service in operation is not necessary to offer the functionality
order to communicate with the DBSync server. required by server modules of DAVINCI.

A Framework for Information Systems Integration in Mobile Working Environments

An example of a FLWR expression could be The DBSync module has an implementation of

as shown in Box 1. certain capacities of the FLWR standard. Through
The result of this FLWR expression through that implementation, a new connector developed
a parser would be this SQL sentence. for the DAVINCI platform will be able to trans-
form a FLWR request into an SQL sentence for
SELECT WR_ID FROM T_WORKER b, SQL Server Database.
T_DEVICE a WHERE b.WR_NAME
LIKE ‘Fran’ AND b.WR_ID != 0 fixed server components
AND a.DV_ID = 0
These components should be installed in a server
In this case, the FLWR parser has been devel- machine with a connection to the client devices.
oped for MS SQL Server Database in such a way They provide full capabilities of the integration
that the syntax of the SQL sentence is specific for framework, so they do not have to be modified
that database server. or enriched in any case.

Box 1.

A Framework for Information Systems Integration in Mobile Working Environments

Campaign Designer a geographic area the concrete person who

is going to visit each work zone.
This module encapsulates the functionalities for • Send the assigned tasks: Once the tasks
the management of campaigns and the protocols in the concrete work zones are assigned,
assigned to them. the integration framework provides func-
Next, the campaign designer’s main function- tions to send the assigned tasks to each
alities are presented in a detailed way. mobile worker. This information shipment is
composed of the mobile applications to run
• Campaign design: This functionality con- during the tasks in the work zones assigned,
sists of one of the following. the list of the mentioned work zones, and
 Selecting an existing campaign to the extended information that is required to
modify its geographic areas and pro- run the applications correctly.
tocols
 Creating a new campaign and selecting MobileUI-Server
the corresponding geographic areas
related to the campaign in which one This component receives the orders (initiated by
will work in that campaign. the user through the Web interface operations)
• Protocol design: This functionality consists sent by the campaign designer and work planning
of one of the following. components, transforming them into the messages
 Selecting an existing protocol, and add- adapted for its shipment to the corresponding
ing and/or deleting activities. Moreover, component in the mobile worker’s device.
for each activity, the application or form Moreover, MobileUI-Server processes the
to complete is able to be changed messages of data and requests sent by the cor-
 Creating a new protocol, defining the responding component in the client side of this
general information of each activity and integration framework.
the precedence between the protocol Next, the MobileUI-Server component’s main
activities, and assigning a mobile ap- functionalities are presented.
plication or form to each activity.
• Application shipment: This operation con-
Work Planning sists of looking for an application assigned
to the worker, assembling the message to
Next, the work planning component’s main func- notify the client of the need of this concrete
tionalities are presented. application, and sending the application to
the client, which is in charge of verifying
• Assign and unassign mobile workers to if this application is installed or not. If the
geographic areas: The first step in the work application is not installed, the client will
planning component consists of determining sent a new message asking MobileUI-Server
the workers who will perform tasks in each for the files corresponding to the new mobile
one of the geographic areas assigned to the application to install.
campaign. Moreover, this function collects the required
• Assign and unassign work zones to mobile extended data for running the application
workers: Once the workers are assigned to sent correctly, and sending them to the client
the different geographic areas, this function side by means of the appropriate messages
allows selecting from the mobile workers of in order to be stored correctly in the cor-
responding mobile databases.

00
A Framework for Information Systems Integration in Mobile Working Environments

• Forms request: When a mobile device asks communications server is the module that, in
for the installation of a new application, the server side, represents the mobile workers’
MobileUI-Server sends a message with the devices.
description of the XForms documents that When a server service sends a message to
compose the required application. another server component, MessageCenter-Server
• Modelmappers request: The process is redirects it considering that the information di-
similar to the comments for the forms re- rected to a mobile device will be redirected to
quest, being initiated by the same event of the communications server, which will send it to
the installation of new applications in the MessageCenter-Client (the message manager that
client side, but in this case, the files sent is continuously running in each mobile device).
correspond to the files that link the form In addition, the shipment of messages between
fields to the local database fields. modules can be programmed, so in this case, the
• Data request: The process is similar to the shipment is executed at a planned moment. In
comments for the modelmappers request, case of nonprogrammed messages, they will be
being initiated by the same event of the sent as rapidly as possible.
installation of new applications in the cli- MessageCenter-Server’s main functionalities
ent side, but in this case, the information are as follows:
sent corresponds to information items to
be inserted in the local database. • Send a programmed message
• Data modification: The purpose of this • Send a list of programmed messages
function consists of the synchronization of • Send an instant message to other server
already updated information by the server component
to the client in order to permit the use of • Send an instant message to a client compo-
undeprecated information by the mobile nent
workers to perform their tasks correctly. • Start MessageCenter-Server
• Register new service
In order to obtain this intention, whenever the
server detects the modification of information Communications Server
shared by several mobile devices, a message to
the affected devices, with the sentences to sub- This module is in charge of managing the com-
stitute the deprecated information with the valid munications between the client and server in the
one, is created. server side, handling a queue of messages to send,
reconstructing the messages received from the
eSignatureServer mobile devices, and sending them to Message-
Center-Server, which is responsible for redirecting
This module is responsible for verifying the them to the corresponding server service.
information signatures generated in the mobile The communications server’s main function-
devices to check their validity. alities are the following.

MessageCenter-Server • Send a message to a client

• Receive message from client
This module centralizes the communication
between the different modules installed in the
central integration server, considering that the

0
A Framework for Information Systems Integration in Mobile Working Environments

fixed client components MessageCenter-Client

These components should be installed in each This module centralizes the communication
mobile device to be used by a mobile worker. between the different modules installed in the
The client components provide full capabilities mobile device, considering that the communica-
for using and managing the mobile applications tions client is the module that, in the client side,
that are in the scope of the DAVINCI integration represents the central integration server.
framework, so they do not have to be modified or When a client component sends a message to
enriched in any case. another client component, the MessageCenter-
Client redirects it considering that the informa-
Communications Client tion directed to the server will be redirected to
the communications client, which will send it to
This module is in charge of managing the com- MessageCenter-Server (the message manager in
munications between the client and server in the the server part).
client side, handling a queue of messages to send, In addition, the shipment of messages between
reconstructing the messages received from the modules can be programmed, so in this case,
server, and sending them to the message center, the shipment is executed at a planned moment.
which is responsible for redirecting them to the In case of nonprogrammed messages, they will
corresponding component. be sent as rapidly as possible depending on the
Next, the communications client’s main func- amount of messages in the queue and the state of
tionalities are presented. communications channels.

• Send a message to the server: When the MobileUI-Client

message center has any message to send to
the server, the mentioned message is intro- The MobileUI-Client component is formed by
duced in a queue for its later shipment. five differentiated subcomponents.
The shipment will be made at any moment
depending on the availability of the commu- • Forms Viewer (XFormster)
nication channels of the device (Bluetooth, • Forms Server (MobileWebServer)
GPRS, wired connection, etc.) and on the • Forms Processor (XFormsModule)
priority of the message to send. • Data Access Control (MuiData)
Internally, the message queue is stored in a • Applications Controller (MuiDataMan-
database to avoid losses produced as a con- ager)
sequence of possible falls of the system.
• Receive message from the server: When The dynamic collaboration between these
the module of communications has received subcomponents, with the rest of the modules of
a message from the server, the messenger the side client, is shown in Figure 9.
center is notified of this circumstance and The interaction begins when the DAVINCI
is responsible for redirecting the message server sends to the mobile device the applica-
to the corresponding component. tions to be installed. As it has been described
previously, the messages interchanged among a
concrete client and servers are provided by the
communications client that is one of the services

0
A Framework for Information Systems Integration in Mobile Working Environments

Figure 9. MobileUI-Client collaboration diagram

Xformster mobileWebserv er

Worker

aPi x aPi y Xformsmodule

muiData Xforms modelmappers

DataBase

muiData

messagecenter client

Dav inciserv er iserv iceinterface iserv iceinterface

(communications-client) (muiDatamanager)

Figure 10. MuiData collaboration diagram

DataBase

muiData

messagecenter client

Dav inciserv er iserv iceinterface iserv iceinterface

(communications-client) (muiDatamanager)

0
A Framework for Information Systems Integration in Mobile Working Environments

handled by the message center, as it is shown in The mobile Web server works with a set of
Figure 10. APIs that processes different types of requests
When a message of a new application is re- created and initiated by Web pages. In this case,
ceived, ClientMessageCenter redirects it to Mui- the corresponding API to process requests of
DataManager, which is in charge of managing the XForm forms will be the XFormsModule. This
installations of new applications, the downloading module is in charge of gathering the data sent
of data from the server, and the modification of from the Web form to the Web server, searching
the updated data to the server. The forms (written the modelmapper file corresponding to the men-
in XForms) are stored in a specific repository, the tioned form, and updating the data in the local
data mapping files (modelmappers) are stored in database according to the rules specified in the
another separated repository, and finally the data modelmapper file.
are stored in a local database. Moreover, XFormsModule is also in charge of
For the management of the applications’ data, searching for the form that should be presented
an independent module called MuiData, which to the user as a consequence of any command
encapsulates the logic to manage data sources, is processes being used for this purpose, display-
used, so it is possible to change easily the format ing the new information according to the rules
of the data sources to another format (i.e., text specified in the modelmapper file of the new
files, XML files, etc.); replacing the MuiData form to show.
component with another makes it able to process The forms browser has the user interface
the new format. displayed in Figure 12.
On the other side, the mobile worker, when us- Navigation between the different forms will
ing DAVINCI mobile applications, interacts with depend on the specific design and the purpose of
the forms browser, called XFormster, to navigate each mobile application implemented.
between the forms that compose the mobile ap-
plication. This navigation implies interaction with eSignatureClient
a forms server, called MobileWebServer, which is
in charge of process the forms; this is illustrated This module is in charge of signing electroni-
in Figure 11. cally the data generated by the mobile worker

Figure 11. XFormster and MobileWebServer collaboration diagram

Xformster mobileWebserv er

Worker

aPi x aPi y Xformsmodule

muiData Xforms modelmappers

DataBase

0
A Framework for Information Systems Integration in Mobile Working Environments

Figure 12. XFormster user interface uses the Bluetooth port to communicate with the
printer in order to send the printing jobs.
When the user decides to print through XForm-
ster, the print manager extracts the information of
the labels and fields to be printed, and then prints
and transfers them to a flat text document.

Mobile Geographic Information Viewer

(Mobile GIS)

This module allows the visualization of carto-

graphic images and the presentation of informa-
tion relative to parcels or enclosures defined on
the shown cartographies.
Mobile GIS (Geographical Information Sys-
tem) is launched from the browser of MobileUI-
Client’s XFormster, but due to Mobile GIS’s
complexity and the size of the screen of some
pocket devices, the cartographic information
appears in a new window in order to not saturate
the XFormster window; otherwise, the window
during the protocol application in a work zone
to visualize GIS information would be totally
and sending the signature to the central server
unmanageable.
for its verification and storage.
Positioning Component (LBS)
VoiceUI
This component is responsible for obtaining and
The VoiceUI component is in charge of provid-
handling the geographic position, in terms of
ing the capability to handle XFormster forms by
coordinates, of DAVINCI mobile workers. This
means of voice processing; that is to say, using
positioning component allows one to handle geo-
the VoiceUI component, mobile workers are be
graphical, cartographic, and UTM coordinates,
able to handle the DAVINCI mobile forms using
and to work with WGS84 and ED50 data.
commands introduced by speaking.
A detailed diagram of DAVINCI integration
The voice processing interface allows the user
components is shown in Figure 13 using UML
to introduce values for form fields and execute
(unified modeling language) syntax.
the commands provided by command controls
provided by the form, even the activation of the
main functionalities offered by XFormster.
stePs to use the integration
frameWork
Print Manager
If an organization wants to use the DAVINCI
This module allows printing of any of the forms
integration framework for the management of
shown by the XFormster forms browser of the
the applications used by its mobile workers, it is
MobileUI-Client component. The print manager
necessary to perform the following tasks.

0
0
Mobile client Server

Printmanager
voiceui
mobile ui - Web interface campaign
Designer Designer

mobileui-client

Work control &

Planning

e-signature
Figure 13. Integration framework architecture

client
message- mobileui-serv er DB sync
center-client

communications-client communications- message-center-serv er e-signature

mobile gis serv er
serv er

Data
lBs

geoserv er mui - forms Data Base

(opengis)
A Framework for Information Systems Integration in Mobile Working Environments
A Framework for Information Systems Integration in Mobile Working Environments

1. Install and configure the server components 6. Define the protocols that are assigned to
of the integration framework in a server the campaigns, and assign a form to each
able to be connected to client devices with protocol activity.
the configuration. The server machine 7. Plan the work of each campaign, assigning
should have installed any J2EE-compliant the job to any available mobile worker.
application server and an RDMS. Our tri-
als were done using JBOSS and Microsoft Then, the applications and the required data
SQL Server (this database only manages are automatically sent to the mobile workers.
the internal data required by the integration As each mobile worker performs his or her job,
framework). the integration framework automatically updates
2. Install and configure the client components the information in the data source in accordance
in the devices that will be used by the mobile to the data managing policies established in Step
workers. The configuration is different de- 3 of this section.
pending on the mobile device’s capabilities. When a mobile worker has new assignments,
This is the most complicated task because the integration framework sends the new data and,
there are several exceptions and special cases if required, a new mobile application to enable
related to each device vendor and model. the worker to perform the job.
The effort of this task could be reduced by
using the same model of mobile device.
3. Define the data managing policies that will systems integration in
be used on the data source used to obtain euroPean veterinarian
and update the data managed by the mobile sector using Davinci
applications.
4. For each mobile application to deploy, it is trials Purpose
necessary to do the following.
• Define, design, and implement the forms The objectives that should be satisfied by means of
of the mobile applications using the the realization of DAVINCI trials and technology
XForms standard, preparing them for transfer activities consist of validating the im-
their introduction into the DAVINCI provements and technological innovations using
integration framework. This task DAVINCI in real working environments.
could be done with any XML editor The main aspects validated were as follows:
that can process XForms, for example,
XMLSpy. • Capability of integrating the data provided
• Define a modelmapper that contains by DAVINCI with Spanish and Bulgarian
the information of the graphical control cattle exploitations and livestock-movement
used to show any item of the informa- databases. This objective allows checking
tion, and the rules to query and update the effectiveness of DAVINCI for integrating
the mentioned data. information systems of different nature.
• Implement and deploy a new DBSync • Reduction of costs and effort spent in rela-
Connector to enable DBSync Server to tion to the new mobile applications develop-
access the data source. ment.
5. Design each company campaign using the • This validation was carried out by gathering
Web interface of the integration frame- related data on the necessary time to develop
work. mobile applications to help veterinarians

0
A Framework for Information Systems Integration in Mobile Working Environments

perform information retrieval, and updating Number 1760/2000 of the European Parliament.
tasks related to the cattle sanitarian control On the other hand, DAVINCI cannot use the
program. standardized systems of the Bulgarian GIS to
• Improvement of the ergonomics and vet- satisfactorily prove the GIS capacities provided
erinarians’ comfort when performing the by the project.
activities related to sanitary controls and
clinical inspections. To fulfill this purpose, Trials in Spain
the effectiveness, efficiency, and ergonomic
conditions for those carrying out the inspec- A voice recognition system was tested in a small
tions were analyzed in detail. This analysis ruminant bleeding activity because the time saved
was performed by the veterinarians complet- with small ruminants is by far greater than the
ing some evaluation questionnaires about time estimated for large ruminants. The voice
the subjective estimation of these aspects. recognition system will be useful for some vet-
erinary activities on the ground, but experience
trials scope shows that the time saved in a bovine bleeding
job using this technology is not as profitable as in
Trials have been performed in four European small ruminant practices. For this reason, sheep
countries (Spain, Latvia, Czech Republic, and control programs were selected for this trial.
Bulgaria) during the experimentation activities The bleeding of large animals will be done us-
of the European-Commission-funded project ing pocket PCs. There is a reason for this choice.
called Advanced Management Services for In- In the case of large animals, more activities have
spections and Sanitary Interventions in Cattle to be performed and the use of a pocket PC, with
Holdings through Mobile Technologies (IPS- all the functionality that it is able to provide,
2001-42057). facilitates the job for these activities. The objec-
The most efficient strategy for achieving the tive of this demonstration is not only the use of
trial objectives was performing separate trials and those devices on bleeding activities, but also to
technology transfer activities in Bulgaria, Spain, become conscious of the limits and capabilities
Latvia, and Czech Republic. of the use of technological devices on the ground
The reason for this separated approach is based in an unclean environment.
on the existing differences between the infrastruc-
tures already present in each country. Trials in Bulgaria, Czech Republic, and
In Spain, there is an information system for Latvia
cattle-exploitations registering and livestock
movements managed by each autonomous com- Bulgaria believes that the approach to separate the
munity and coordinated by the central govern- demonstration from the prototypes is reasonable
ment. The databases in the system satisfy the for a better evaluation of each one of them.
requirements in Directive Number 1760/2000 of The use of a voice recognition system, no
the European Parliament. Also, in Spain there are matter whether being used on small or large ru-
standard GISs that are accessible by the project, so minants, is of significant interest for us, but due
we will allow the checking of all of the project’s to some limitations on the languages that can be
required functionalities. used in such a system, the demonstration of the
In Bulgaria, although there are databases technology could be limited to Bulgarian project
for cattle exploitation and livestock movements, coordinators reviewing the Spanish prototype.
they are not standardized according to Directive

0
A Framework for Information Systems Integration in Mobile Working Environments

Figure 14. Trials execution in Spain

Figure 15. Trials execution in Czech Republic

Although the mobile mapping system was by DAVINCI. The necessary activities to meet
tested in Spanish trials, we believe that this the established trial objectives and the desired
component will be of significant importance for technology transference are the following.
us during the monitoring of culicids vectors on
bluetongue disease, a disease with great epidemio- 1. Definition of the trials scope
logical significance for Bulgaria and the region. 2. Determination of the region and holdings
Along with that, the application of restricting to be visited during the trials, looking for
measures could be tested for a geographical area concrete parameters
in case of a disease outbreak. All those activities 3. Selection of the participants in the prototype
could be done in a lab with all the data that we testing activity
have—digital maps, data from culicid traps, and 4. Configuration of the mobile devices’ hard-
so forth—and we believe they are going to be ware
sufficient for testing a prototype for the mobile 5. Preparation of trial evaluation materials
mapping system. 6. Performance of the cattle sanitary control
activities
trials activities 7. Trials evaluation

In order for the testing routines to be able to provide

a comparable set of conclusions, a common process
for the trial development has been established

0
A Framework for Information Systems Integration in Mobile Working Environments

Figure 16. Trials execution in Bulgaria

conclusion anD future Work tions in terms of the insertion, modification,

and consultation of data coming from a single
The main success factor of DAVINCI does not data source.
lie in obtaining a system that provides a highly • The economic costs needed to integrate mo-
optimized performance, but in the automation of bile applications with existing systems and
manual procedures, achieving acceptable perfor- databases for livestock sanitary information
mance. Moreover, it has been detected that the management has been reduced by 9.03%.
performance displayed is not optimal, but since • The average time to publish the data relative
it copes with minimal required performance, to a cattle holding has been reduced by up
the fundamental objectives of the project are to 2.6 days, decreasing from 64.84 hours in
fulfilled. the previous situation to 1.14 hours when
As a summary, it may be said that the results using DAVINCI.
obtained from the trials allow us to state that the • DAVINCI easily adapts to the field work-
main improvements brought about by DAVINCI ing proceedings of different countries,
are the following. with different cultures and organizational
structures.
• The effort necessary to develop mobile ap- • The DAVINCI framework should adapt
plications to gather and/or consult livestock easily to technology changes in communica-
sanitary information has been reduced by up tions or to new mobile devices being used
to 43.43%. The absolute value (in working to perform fieldwork.
hours) of this reduction will depend on the • The performance and easiness of mobile
size (measured in function points) of the device configuration is acceptable, allowing
intended application. the veterinarian to effectively carry out the
Nonetheless, it ought to be taken into ac- field tasks.
count that the success mentioned has been • The communication components of DAVIN-
produced in a limited context of a quite CI are adaptable to several different com-
restricted set of mobile applications based munication infrastructures, allowing one to
on simple formularies, without complex effectively resume interrupted messaging
displaying elements such as dynamic lists due to uneven communication coverage.
or tables, with simple access to databases Thus, the information transmitted through
not joining different data sources. the available bandwidth is optimized.
Thus, this effort reduction is so far applicable
to the development of simple mobile applica-

0
A Framework for Information Systems Integration in Mobile Working Environments

However, it is necessary to perform, in the references

immediate future, an optimization process of the
obtained solution, introducing, among others, the Application servers. (2006). MobileInfo.com.
following improvements. Retrieved April 17, 2006, from http://www.mo-
bileinfo.com/application_servers.htm
• To extend the set of available controls to
Baumgarten, U. (2004). Mobile distributed sys-
be used by DAVINCI mobile applications,
tems. John Wiley & Sons.
allowing the usage of more complex formu-
laries with complex information, displaying Boag, S., Chamberlin, D., Fernández, M. F., Flo-
elements such as dynamic lists and tables, rescu, D., Robie, J., & Siméon, J. (2005). XQuery
and allowing simultaneous access to differ- 1.0: An XML query language. W3C candidate
ent data sources (joins) recommendation. Retrieved November 3, 2005,
• To carry out, keeping in mind the improve- from http://www.w3.org/TR/2005/CR-xquery-
ments of the available controls for mobile 20051103/
applications, a larger set of studies to assess
the reduction of effort and time needed to Boar, C. (2003). XML Web services in the orga-
develop mobile applications within DA- nization. Microsoft Press.
VINCI Boyer, J., Landwehr, D., Merrick, R., Raman, T.
• To study and define algorithms allowing V., Dubinko, M., & Klotz, L. (2006). XForms 1.0
the broadening of coverage time, and thus (2nd ed.). W3C recommendation. Retrieved March
lowering the number of messages that have 14, 2006, from http://www.w3.org/TR/xforms/
to be resumed due to loss of communication
with the coverage currently offered in rural Intel Corporation. (2006). Intel® mobile appli-
environments by communication provid- cation architecture guide. Retrieved April 17,
ers 2006, from http://www.intel.com/cd/ids/devel-
• To improve the ergonomics and ease of use of oper/asmo-na/eng/61193.htm
the central components for in-field resource Lee, V., Schell, R., & Scheneider, H. (2004). Mobile
management applications: Architecture, design, and develop-
• To improve the ergonomics and ease of use ment. Hewlett-Packard Professional Books.
of the mobile applications developed under
DAVINCI, paying attention to those aspects Longueuil, D. (2003). Wireless messaging de-
related to input data validation and helping mystified: SMS, EMS, MMS, IM, and others.
with the completion of less common tasks McGraw-Hill.
• To provide the veterinarian with a mobile Mallick, M. (2003). Mobile and wireless design
device that allows her or him to perform the essentials. Wiley Publishing Inc.
fieldwork without the need to undergo con-
figuration changes, such as battery changes, Schiller, J. (2000). Mobile communications. Ad-
during the activities dison Wesley.
• To improve the performance of DAVINCI’s Siegal, J. (2002). Mobile: The art of portable
voice recognition system so that it consumes architecture. Princeton Architectural Press.
less resources and is less sensitive to noise
while not lowering the speed for voice pro-
cessing

Chapter XII
Enterprise Application
Integration from the
Point of View of
Agent Paradigm
Min-Jung Yoo
HEC (Ecole des Hautes Etudes Commericales), University of Lausanne, Switzerland

aBstract

The agent paradigm in general underlines the interaction phenomenon in a collaborative organization
while respecting the autonomy and self-interested features of individual components. Relevant use of
the agent paradigm will be one of the key factors to success in application integration projects in the
near future. This chapter describes the basic notions of intelligent agents and multiagent systems, and
proposes possible types of their application to enterprise integration. The agent-based approaches to
enterprise application integration are considered from three points of view: (a) using an agent as a
wrapper of applications or services, (b) constructing a multiagent organization within which agents
are interacting and providing emergent solutions to enterprise problems, and (c) using the agent as an
intelligent handler of heterogeneous data resources in an open environment.

introDuction erability between heterogeneous applications

providing application-to-application middleware.
Today’s business information systems are not Nevertheless, the complex business context of
isolated applications. Businesses are trying more nowadays requires higher level collaboration
and more to offer collaborative services, using an among applications in order to satisfy the proper-
open communication infrastructure, such as the ties of responsibility or agility, that is to say the
Internet, for the purpose of creating and operating following.
worldwide services.
The early stage of integration efforts mainly • Due to the responsibility, services required
addressed the problem of technical-level interop- by clients should be safely offered

Copyright © 2007, IGI Global, distributing in print or electronic forms without written permission of IGI Global is prohibited.
Enterprise Application Integration from the Point of View of Agent Paradigm

• Agility means continuously monitoring one of the key factors to success in the near future
market demands and quickly providing new in application integration projects.
products This is the reason why this chapter is dedi-
cated to reviewing some principle concepts of
Concerning the first point, a business should intelligent agents and multiagent systems. This
try to satisfy its clients even when it is impos- chapter is organized as follows. In the next section,
sible to offer a service because of some failures. principal concepts concerning intelligent agents
Searching for another service provider that is and multiagent systems are briefly discussed.
capable of offering a similar service may be a Then the chapter discusses the taxonomy of en-
possible solution in that situation. In long-term terprise application integration in general. Next,
vision, this strategy can better service clients. it presents agent-based approaches to enterprise
From the technological point of view, today’s Web application integration. Finally, a short summary
services standards may be useful for construct- and concluding remarks are given.
ing integrated networks of applications among
business partners. The environment of business
information systems is highly volatile. For this intelligent agents anD
reason, the creation, enactment, and management multiagent systems
of such collaborative networks require special
concerns. In many Web services composition First of all, it is necessary to give the definition
projects, one of the hot issues is how to provide of the term agent. The most widely accepted
an effective means of searching for appropriate definition could be the one given by Wooldridge
services and business partners. (2002, p.15): “An agent is a computer system
For the second point, the possibility of reus- that is situated in some environment, and that
ing existing components will be a key factor is capable of autonomous action in this environ-
for the successful development of new services ment in order to meet its design objectives.” The
within a short period of time. In that context, kinds of intelligent capabilities of agents are then
not only reusing one’s own data sources and ap- considered as follows.
plications, but also benefiting from applications
and services of other firms—through a certain • Reactivity: The ability to perceive the en-
form of collaboration and negotiation—will vironment and respond in a timely fashion
be helpful. to changes
In order to confront these problems, CIOs • Proactivity: The ability to pursue goals by
(chief information officers) should think of taking the initiative in order to satisfy design
progressively moving the abstract level of the objectives
interoperable medium from data handled by ap- • Social ability: The capability of interact-
plications to services guaranteed by businesses. ing with other agents in order to satisfy the
Rather than achieving integration, they should aim social goal
at constructing a collaborative organization that
provides the dynamic just-in-time interaction of The studies of agents are multidisciplinary
services. The agent paradigm in general underlines research results from the domains of artificial
the interaction phenomenon in a collaborative intelligence and logic, distributed computing,
organization while respecting the autonomy and psychology, social science, artificial life, ecology,
self-interested features of individual components. engineering and robotics, and so on. For this rea-
The relevant use of the agent paradigm will be son, it is always a debatable question of defining

Enterprise Application Integration from the Point of View of Agent Paradigm

what an agent-based approach to a certain problem resources, or information to solve a global

is. Meanwhile, if we are able to intelligently handle problem.
its diversity, there may be many ways of applying • Understanding social behavior through
the agent paradigm to application integration and collaboration between autonomous agents.
benefiting from it. DcAI can not only improve the intrinsic
The most commonly accepted view of agent power of the capabilities of each agent, but
studies is regarding it as research on distributed also model social behavior emerging from
artificial intelligence (DAI) or decentralized arti- the agent interactions. Since it is based
ficial intelligence (DcAI). DAI and decentralized on the framework of the interacting enti-
AI have slightly different characteristics while ties, it provides keys to understanding the
sharing some common interests in the intelligent interactions among intelligent beings that
behavior of distributed entities. may belong to various groups of interests
In DAI, a global task is initially defined, and or societies.
the problem is then to design the distributed
entities to enable the performance of this global As a result, the study of agents made its
task. Therefore, the main issue is to study the progress in the following issues providing related
distribution and the collaborative resolution of a outcomes.
given problem. The key problem to solve is how
to efficiently distribute the entire problem among • The issue of intelligent agents
collaborative entities through tasks and resource • The mechanisms of collaboration
allocation.
On the contrary, in DcAI, decentralized In both cases, common features that charac-
autonomous entities are initially defined. We terize agents are the facts that (a) the entities are
then study how these entities are able to achieve situated in an environment, (b) their rationality
tasks that may be personal or may interest sev- is expressed not only by their knowledge about
eral entities. Two important motivations in this the environment, but also through their actions
field of research are the following (Demazeau & in the environment, and (c) their collaboration is
Müller, 1989). not hardwired.

• Designing more powerful and autono- the issue of intelligent agents

mous agents that are capable of processing
incomplete and uncertain knowledge by This approach is characterized by constructing
communication with other agents. The DcAI intelligent autonomous entities, that is, intelligent
approach can provide insights into improv- agents, in a multiagent world. Constructing an
ing and increasing the reasoning and decision intelligent program has been the main goal of
capabilities of each agent. The agents may traditional AI and logic-based approaches. The
achieve their own goals in the society that main difference between the traditional AI and the
are compatible within the range of a global agent studies lies in how agents learn and handle
goal. The key aspect is thus the collaboration conditions and knowledge necessary for reason-
among multiple agents. In the approach to ing. Intelligent agents try to solve problems situat-
collaborative distributed problem solving ing in a partially known environment, whereas in
(CDPS) by multiagent systems, for example, traditional AI the environment or some mandatory
cooperation is especially necessary when conditions to problem solving are predefined.
no single node has sufficient expertise, Another difference is that the agent’s intelligence

Enterprise Application Integration from the Point of View of Agent Paradigm

concerns not only their knowledge level, which In any case, the agents have to communicate
is the case in traditional reasoning systems, but with each other for the purpose of collaboration. As
also the objective of their decisions. The reasoning for the communication mediums, agent systems
purpose of an intelligent agent is thus to decide on may use a rich set of communication technologies
an action, even though the agent has no sufficient for the purpose of data transfer between agent ap-
information about its environment. This chal- plications. The different communication mediums
lenge resulted in many agent architectures, such can be categorized into several types.
as the BDI (belief-desire-intention) architecture
(Georgeff et al., 1999) whose principle is based • Concerning data transfer: Shared memory,
on practical reasoning systems. such as blackboard architecture (http://www.
The purpose of practical reasoning is in fact bbtech.com/), or message passing
to direct the reasoning process toward action • Considering the types of communication
choices. The decision is based on two types of infrastructure: Wired or wireless
options: what the agent believes (the knowledge) • Considering the types of message distribu-
and what the agent desires or cares about. These tion: Point to point, multicast, broadcast
options can possibly be competing. In case there • Considering the modes of message ex-
is competition or conflicting considerations be- change: Synchronous or asynchronous
tween these options, the agent should weigh them message passing
to make a decision.
Particularly, the research issue of asynchro-
the issue of multiagent nous message passing entailed several outcomes
collaboration such as KQML (knowledge query and manipula-
tion language) and KIF (knowledge interchange
This approach is characterized by studies on the format; Finin et al., 1993), the FIPA (Foundation
collaborative organization of self-interested enti- for Intelligent Physical Agents, 1997) standard for
ties. In this approach, the relationship between the agent communication language, various ne-
agents and the environment, and the sphere of gotiation mechanisms for agent-based brokerage,
influence of agents to their environment are the and task allocation protocols such as Contract Net
primary considerations. The purposes of agent (Smith, 1980). A brief overview of some elements
collaboration are as follows. used for agent collaboration is given below.

• Sharing knowledge and intelligence among KQML and KIF

collaborative agents. In the case of enter-
prises, the knowledge may concern the The most important contribution of KQML is
specialty, strategies, business intelligence, the semantics of the communication protocols
or some data in the enterprises’ local data- (domain-independent part), which is separated
bases. from the semantics of enclosed message content
• Benefiting from the capability of other (which may be dependent on domain problems).
agents, which is in fact the actions and ser- The semantics of the high-level protocols, used
vices offered by other agents. It can be the by communicative agents, should be concise and
enterprises’ services. have only a limited number of primitive commu-
• Exchanging goals that allow agents to nicative acts. The communicative acts of KQML,
achieve the objective of a whole organiza- or “performatives” in other words, such as tell,
tion while satisfying the individual goals of ask-if, reply, subscribe, and so forth, enable you
self-interested entities.

Enterprise Application Integration from the Point of View of Agent Paradigm

to construct a virtual knowledge base between Intelligent Agent (http://www.agent-software.

heterogeneous software. com/), JADE (Java Agent Development Envi-
This part of knowledge is kept and managed ronment, http://jade.cselt.it/), ZEUS (http://labs.
by autonomous agents. The idea was that agents bt.com/projects/agents/zeus/), Agent Develop-
using KQML as a communication means might ment Kit (http://www.tryllian.com), and so on.
be implemented using different programming
languages and paradigms. Any information that
agents have may be internally represented in taXonomy of aPPlication
many different ways. Each agent is capable of integration
the following.
An enterprise can achieve its integration purpose
• Understanding the high-level message se- on its own terms, managing different technologies
mantics that are well-introduced in the other chapters. The
• Handling the content of messages as it is integration model can range from a simple and
required rapid integration to a more complex form. The
integration issues in general can be categorized
While KQML is an upper language that per- as follows (Linthicum, 2003; Vinoski, 2002; Yoo,
mits us the knowledge-level data description, KIF Sangwan, & Qiu, 2005).
was originally developed with the intent of being
a common language for expressing properties • Common data transfer
of a particular domain. KIF is closely based on • Database-level integration
first-order logic in recasting its representation in • Interface processing
a LISP-like notation. • Process-level integration
• Service-oriented integration
FIPA • Integration within a service organization

The Foundation for Intelligent Physical Agents In this section, each type of integration is
promotes technologies and specifications that fa- reviewed.
cilitate the end-to-end interoperating of intelligent
agent systems for individuals. Now, specifications common Data transfer
proposed by FIPA become de facto standards for
developing software agent platforms. The FIPA This is characterized by sharing text-based files
agent communication language (ACL) is one of between applications to be integrated, for example,
such standards. The FIPA ACL is very similar to using script languages such as Python or Perl
KQML, being composed of about 20 performa- in order to share information between different
tives. Apart from ACL, the FIPA specification natures of applications (Vinoski, 2002). By the
also includes agent management technologies possibility of rapid prototyping and easy exten-
concerning agent management and agent message sibility, this approach is often used by a large
transport. The agent organization is managed by a amount of communities for simple and short-term
standardized platform and agent directory facili- integration projects.
ties (yellow- or white-page services).
Already, a number of FIPA-compliant agent
platforms are publicly available, such as JACK

Enterprise Application Integration from the Point of View of Agent Paradigm

Database-level integration Concerning the agent paradigm, the possibility

of providing a unified interfacing mechanism with
This approach attempts to interconnect databases the help of a certain agent communication lan-
by database-to-database integration or construct- guage such as FIPA ACL can give interoperability
ing a federated database in order to share consis- among a high number of heterogeneous software
tent database content. Data replication is simply and hardware systems. This allows integrating ex-
moving data between two or more databases. isting software systems as required, for instance,
The databases can employ different models. for operating the manufacturing enterprise, hard-
Currently, many database-oriented middleware ware modules such as machines, or sophisticated
solutions provide the database replication service control mechanisms. FIPA particularly specifies
by transforming and adjusting heterogeneous da- as well the conditions to be satisfied for the agent
tabase elements. The implementation is relatively software integration by a wrapper agent that is
easy and cheap. needed in activating software systems.
Database federating tries to integrate multiple
databases and database models into a single unified Process–level integration
view by way of a federated virtual database. On
the contrary to data replication, which physically Process-level or business process integration deals
replicates data contents, data federation constructs with building enterprise-wide business processes
an additional virtual view of all databases that incorporating existing applications into those
comprise many real, physical databases. processes. This approach is characterized by
Considering that the ultimate purpose is to providing another layer of process management
share data resources, the common data transfer that resides on the top of other applications. This
and database-level integration can be compared layer supports the flow of information and control
with agent collaboration for sharing knowledge logic between existing processes. A workflow
resources. Nevertheless, in the case of agent col- management system (WFMS) is in this category
laboration for sharing knowledge resources, the of integration.
sharing decision is up to the agents. An agent can This level of integration allows the coop-
require some information and the other agent can erative work of several processes while sharing
decide whether to reject or accept it. the capability of processes. What will be the
difference in the case of agent collaboration?
interface Processing The WFMS controlling mechanism is based on
static process integration. Each process has no
This approach uses well-defined application in- autonomous decision capability concerning its
terfaces in order to provide a unified interface of engagement with a certain type of collaboration,
all internal application services. The purpose of and all processes should be analyzed, including
interfacing varies from the unification of informa- possible interfacing among them, during WFMS
tion to the unification of services, or both of them. analysis time. On the contrary, the collaboration
The interface layer can invoke local or remote within an agent organization is strongly based on
applications. For example, JCA (Java Connector the agent’s autonomy and self-interested strategy.
Architecture, http://java.sun.com/j2ee/connec- The collaboration relationship might well change
tor/) can be regarded as this type of integration, with time.
which provides the interface of different ERP
(enterprise resource planning) systems.

Enterprise Application Integration from the Point of View of Agent Paradigm

service-oriented integration service. Applications in a service-oriented integra-

tion are not aware of the other applications. The
Service-oriented integration allows applications characteristics of each service (i.e., the previously
to share common business logic or methods. Web- mentioned application logic) are visible only to
based services are good examples of services to the designer of an integrated service in the case
be integrated in this context. The main purpose of service-oriented integration. Contrarily speak-
is thus to provide end users with a unified service ing, in a collaborative service organization, each
infrastructure that is composed of many service service has the capability of understanding the
applications on the Web. By connecting to the service semantics of others. The knowledge about
composite application, a user can benefit from the other services make it possible for a service
the services offered by existing applications. In to require a necessary service at run time for the
this approach, the existing application logic is purpose of achieving its own objective, or to find
important from the point of view of the integrated and bind dynamically to other services.
services. The above discussions are not only showing
In fact, the notion of service is not a newly the variety of application integration, but also the
introduced concept. Meanwhile, the primary dif- direction of their evolution (Figure 1). Starting
ference in the case of older service offerings is from static integration between applications, the
that human intervention was previously required evolution goes toward dynamic interoperability
in order to access and use services. The modern between services in an open environment. The
view of services goes beyond the old definition service logic becomes more and more complex.
in terms of accommodating the openness of Web As pointed out by Singh and Huhns (2005), the
systems. This means describing services in a stan- services are meant to be used in multiple contexts.
dard manner, arranging for them to be discovered Their argument continues as follows (p. 87):
and invoking them in a standard manner (Singh That is, models for services apply both in terms
& Huhns, 2005). of how the services are implemented and how they
are used by others. For complex services imple-
integration within a service mentation, we would need to model the databases
organization and knowledge bases, applications, workflow, and
the organizational roles involved.
Many researchers now predict that the future At present, the integration means no more put-
direction of business information goes toward ting diverse concepts together, but rather matching
global integration, and this should be guided by the needs and preference of service consumers
each entity’s roles based on organizational analysis with the capacity and quality of services provided
(Basu & Kumar, 2002; Zambonelli, Jennings, by service providers.
& Wooldridge, 2000). The ultimate purposes
are twofold: constructing a unified view of an
enterprise, and getting these different business agent-BaseD aPProach to
services to collaborate to give each other value- aPPlication integration:
added service stemming from synergy effects. What for?
In that case, what is the difference between a
service organization and service-oriented integra- Until now, we have seen the basic notion of the
tion? Applications in a service organization know agent paradigm on the one hand, and the evolution
the semantics of other services as collaborative of enterprise application integration on the other
applications for the purpose of achieving its own hand. It is vital to explain where the agents are

Enterprise Application Integration from the Point of View of Agent Paradigm

Figure 1. The evolution of application integration

Application Application Application Process Service

Direct EDI XML & Message Workflow, Web services,

integration Oriented BPM service-oriented
Middleware architecture

Application Application Application Process Service

API Common Process level Service oriented

solution data transfer integration integration

useful in the context of application integration. Our The wrapper agent approach is comparable
primary concern in this section asks the question, to interface integration or service-oriented inte-
“What does it mean to use agents for enterprise gration considering the fact that it is to provide
application integration?” That is, we address the a unified access mechanism. Meanwhile, wrap-
category of agent-based approaches to enterprise per-based agent software integration not only
application integration. The discussions are based offers a unified interface by means of agent com-
on three points of view. munication languages, but also allows the service
logic of an application to be meaningful in the
• It means using an agent as a wrapper of integrated whole. This aspect enables an agent to
applications or service execution. understand the service semantics of other agents
• It means modeling enterprise applications in the organization. The agent messages used for
using an agent organization within which communication are more than the simple activa-
agents are interacting and providing emer- tion of other applications’ internal processes. The
gent solutions to enterprise problems. messages in ACL are the real means of expressing
• It means using agents as an intelligent han- the capacity or the preference of each agent ap-
dler of heterogeneous data resources in an plication, and they ultimately influence the action
open environment. of the other agents.
ExPlanTech presented in Pechoucek, Vokrinek,
agent as a Wrapper of and Becvar (2005) can be taken as an example.
heterogeneous software ExPlanTech is a framework for agent-based pro-
duction planning that offers technological support
This means using a standard agent architecture for various manufacturing problems. Users can
in order to integrate the functions of applica- assemble different components to develop a cus-
tions (Figure 2). The interoperability problem tomized system for decision support in production
addressed by Genesereth (1997) mainly concerns planning. The platform is built on top of JADE.
this issue. The approach helps encapsulate legacy software,
such as those for scheduling, parts management,

Enterprise Application Integration from the Point of View of Agent Paradigm

Figure 2. Wrapper agent approach

Agent communication Application
and collaboration interface
using ACL

Standardized application application

agent structure

and stock management, as JADE agents. Devel- particular capabilities of agents, agents can be
opers can benefit from a predefined agent core best used for enterprise solutions. Some examples
with already implemented control and message of such characteristics are that enterprise systems
transport protocols. This feature facilitates the are modular, decentralized, ill-structured, and
easy integration and rapid development of new complex. Rather than functional decomposition
and third-party components. that governs almost all enterprise applications,
With the help of using a standard agent archi- agent-based approaches follow physical decompo-
tecture such as FIPA, the applications can also sition. This aspect guarantees the modularity and
benefit from other services offered by the agent ill-structured nature of resulting systems, which
platforms in combination with Web services fits well to agent-based approaches to industrial
standards, ontology services, or security issues. application.
Web Service Agent Gateway, for example, enables In this approach, access to existing applica-
a connection between SOAP (simple object actions or databases is often needed for the purpose
cess protocol) messages and the FIPA-compat- of modeling the actions or internal resources of
ible ACLs. Already, several gateways have been agents. As firms have their own legacy software,
developed for different agent platforms. Such a we must recursively solve the problem of applica-
gateway service is accessible to both agents us- tion integration in general between agents and
ing FIPA ACL and Web service clients through the legacy software. Middleware solutions and
SOAP messages. The gateway makes it possible technologies for application integration, such as
to represent agent services as Web services, and data transfer, message-oriented middleware, and
the inverse, that is, to access Web services via XML-based standards, can be useful for the pur-
the agent communication. pose of agent-to-legacy software integration.
In the ANTS (Agent Network for Task Schedul-
agents as self-interested interacting ing) system (Sauter & Van Dyke Parunak, 1999),
entities within an organization a traditional ERP approach, which is often used
for supply chain management, is replaced by
This means modeling enterprise applications an agent-based system. In the organization of
using an agent organization within which agents a multiagency, a single step in the process plan
are interacting and providing emergent solu- (operation), resources such as machines, op-
tions to enterprise problems (Figure 3). As it is erators, material, and customers or suppliers are
underlined in Van Dyke Parunak (1999), if the separately modeled as small-grained agents. They
characteristics of domain problems require the are dynamically interacting using the contract net

0
Enterprise Application Integration from the Point of View of Agent Paradigm

Figure 3. Organization of small-grained multiagency

Multiagent organization

Agent
interaction and
collaboration

Agent-to-legacy
application
connection

application application application

protocol (Smith, 1980) with a view to solving the software agents (Berners-Lee, Hendler, & Las-
negotiation problem in task and resource alloca- sila, 2001). The agent is an intelligent consumer
tion among agents. of these interpretable resources.
The main purpose of this approach is to One of the mandatory conditions for using this
encompass some limitations due to traditional approach is that the resources should be ready to
centralized approaches that are too brittle in the be handled by a program, that is to say, written
face of the dynamic environment of real-world in particular semantic languages. Nowadays,
problems. Because the software environment semantic Web ontology languages such as RDF
becomes more and more complex, the successful (resource description framework) or OWL (Web
implementation of such software requires a huge ontology language) allow the expression of the data
budget and effort. In order to solve this problem, resource semantics using XML. A more special-
small-grained agent-based systems offer a promis- ized ontology for expressing service semantics,
ing alternative to monolithic software modules by OWL-S, is also available. OWL-S compliments
letting agents respond to their environment using current WSDL (Web services description lan-
simple reaction rules or directly interacting with guage) by providing the possibility of describ-
other agents through predetermined protocols. ing the properties and capabilities of a service.
Thanks to these features, agents can reason about
agent as an intelligent handler of the content of services and decide what services
Distributed Data resources to use to achieve their own goals.
There are already many commercial prod-
This means using agents as an intelligent handler of ucts that enable us to create and manage such
nonintegrated and independently developed data semantic documents. Oracle Spatial 10g, Altova’s
resources that are used in different enterprises. SemanticWorks 2006, or Cerebra Server are some
This approach is helpful when enterprises need to examples of these products. Oracle Spatial 10g
reach distributed resources and understand them (http://www.oracle.com/technology/products/
with a view to making a decision. The intelligent spatial/index.html) introduces an open, scalable,
program, the agent on the semantic Web, is in this secure, and reliable RDF management platform
category. The aim of the semantic Web is to make for industries. Based on a graph data model, RDF
the Web usable not only by people, but also by triples are persisted, indexed, and queried in a

Enterprise Application Integration from the Point of View of Agent Paradigm

Figure 4. Agents as semantic information consumers

Agents
accessing to,
interpreting,
and using
information
resources
Internet

Knowledge
sources on
the Web

similar way to other object-relational data types. contextual requirements for agents to monitor
Altova SemanticWorks 2006 (http://www.altova. business process performance. Different types
com/products_semanticworks.html) is a visual of agents ultimately monitor the overall business
RDF-OWL editor from the creators of XML- process and the performance of individual busi-
Spy. The system enables semantic Web instance ness activities based on multiple criteria.
documents, vocabularies, and ontologies to be
visually designed, and then outputs them in either
RDF-XML or N-triples formats. Cerebra Server conclusion
(http://cerebra.com/products/cerebra_business.
html) is a platform that can be used by enterprises This chapter described the basic notions of
to build model-driven applications and highly intelligent agents and multiagent systems, and
adaptive information integration infrastructure. proposed possible types of application to enter-
This platform also handles problems relating to prise integration. As we have seen, agents are
security, user management, auditing, notifications, not panaceas that can completely replace one of
logging, and user interface services. the current application integration technologies.
To summarize, the approach to intelligent Agents are rather methodological metaphors that
agents on the semantic Web facilitates both in- can be used with other technologies in order to
ter- and intra-enterprise knowledge integration. achieve synergy effects.
Enterprises can reduce the cost and complexity Today’s technologies can provide fast-to-
of data management and systems development. achieve solutions to integration problems.
Thomas, Redmond, Yoon, and Singh (2005) show However, they do not yet provide substantial
an example of knowledge management using se- architecture models or methodologies for open
mantic documents and agents. Without changing service organization. As for agent-based software
the existing business process, which is described solutions, in spite of the interest demonstrated,
in a standard language, their approach proposes there are not yet many products available that
giving some additional information, described are intended to encourage enterprise integration
in OWL, concerning performance criteria for particularly using an agent paradigm. If com-
business processes and activities. These OWL panies prefer buying an integrated package for
documents provide semantic descriptions of the agent solutions, then it would be better to wait

Enterprise Application Integration from the Point of View of Agent Paradigm

until the agent-based third-party products are Demazeau, Y., & Müller, J.-P. (1989). Decentral-
much more mature. ized artificial intelligence. Proceedings of the First
In the meantime, we can stimulate the technol- European Workshop on Modelling Autonomous
ogy advancement in two directions. On the one Agents in a Multi-Agent World.
hand, an agent-oriented organization model or
Finin, T., et al. (1993). Specification of the KQML
modeling methodologies can guide third-party
agent communication language: DARPA knowl-
tool developers toward the effective use of the
edge sharing initiative external interfaces work-
agent paradigm. In the agent-oriented modeling
ing group.
paradigm, a rich set of organizational structures
and interaction protocols are well-studied. Con- Foundation for Intelligent Physical Agents (FIPA).
comitantly, enterprises can learn from the experi- (1997). Agent communication language. In FIPA
ences in the agent domain and use the knowledge 97 specification, version 2.0. Geneva, Switzer-
for developing their private solutions to application land: Author.
integration. These experiences will be helpful for
Genesereth, M. R. (1997). An agent-based frame-
modeling global business information systems in
work for interoperability. In Bradshaw (Ed.),
today’s open environment.
Software agents. AAAI Press/MIT Press.
Georgeff, M., et al. (1999). The belief-desire-inten-
acknoWleDgment tion model of agency. In J.-p. Müller, M. Singh,
& A. S. Rao (Eds.), Lecture notes in artificial
The author would like to thank Professor François intelligence: Vol. 1555. Intelligent Agents V. Berlin,
Bodart from the University of Namur (Belgium) Germany: Springer.
for providing helpful suggestions and discussions
Goethals, F., Vandenbulcke, J., Lemahieu, W.,
on the subject.
Snoeck, M., De Backer, M., & Haesen, R. (2004).
Communication and enterprise architecture in
extended enterprise integration. Proceedings of
references
the Sixth International Conference on Enterprise
Information Systems, Porto, Portugal.
Akkiraju, R., Keskinocak, P., Murthy, S., & Wu,
F. (1998). A new decision support system for paper Inmon, W. H. (2000). A brief history of integra-
manufacturing. Sixth International Workshop on tion. EAI Journal. Retrieved October 2002, from
Project Management and Scheduling, Istanbul, http://www.eaijournal.com/applicationintegra-
Turkey. tion/BriefHistory.asp
Basu, A., & Kumar, A. (2002). Research commen- Jennings, N. R. (2001). An agent-based approach
tary: Workflow management issues in e-business. for building complex software systems. Commu-
Information Systems Research, 13(1). nications of the ACM, 44(4).
Berners-Lee, T., Hendler, J., & Lassila, O. (2001). Kishore, R., Zhang, H., & Ramesh, R. (in press).
The semantic Web. Scientific American. Enterprise integration using the agent paradigm:
Foundations of multi-agent-based integrative busi-
Chen, Q., Hsu, M., Dayal, U., & Griss, M. (2000).
ness information systems. In Decision support
Multi-agent cooperation, dynamic workflow and
systems. Elsevier.
XML for e-commerce automation. Fourth Inter-
national Conference on Autonomous Agents.

Enterprise Application Integration from the Point of View of Agent Paradigm

Linthicum, D. S. (2003). Next generation ap- Yoo, M.-J. (2004, October). Enterprise applica-
plication integration: From simple information tion integration and agent-oriented software
to Web services. Addison-Wesley Information integration. IEEE International Conference on
Technology Series. Systems, Man, and Cybernetics, The Hague,
Netherlands.
Pechoucek, M., Vokrinek, J., & Becvar, P. (2005).
ExPlanTech: Multiagent support for manufactur- Yoo, M.-J., Sangwan, R., & Qiu, R. (2005). En-
ing decision making. IEEE Intelligent Systems, terprise integration: Methods and technologies.
20(1). In P. Laplante & T. Costello (Eds.), CIO wisdom
II: More best practices. Prentice-Hall.
Sauter, J. A., & Van Dyke Parunak, H. (1999).
ANTS in the supply chain. Workshop on Agent Zambonelli, F., Jennings, N. R., & Wooldridge,
Based Decision Support for Managing the Inter- M. (2000). Organizational abstractions for the
net-Enabled Supply Chain, Agents 99, Seattle, analysis and design of multi-agent systems. In
WA. Lecture notes in computer science: Vol. 1957.
First International Workshop on Agent-Oriented
Singh, M. P., & Huhns, M. N. (2005). Service-ori-
Software Engineering. Springer-Verlag.
ented computing: Semantics, processes, agents.
John Wiley & Sons.
Smith, R. G. (1980). The contract net protocol. enDnotes
IEEE Transactions on Computers, C29(12).
1
http://www.bbtech.com/
Thomas, M., Redmond, R., Yoon, V., & Singh, 2
http://www.agent-software.com/
R. (2005). A semantic approach to monitor busi- 3
http://jade.cselt.it/
ness process performance. Communications of 4
http://labs.bt.com/projects/agents/zeus/
the ACM, 48(12). 5
http://www.tryllian.com
Van Dyke Parunak, H. (1999). Industrial and 6

practical applications of DAI. In G. Weiss (Ed.), 7

http://java.sun.com/j2ee/connector/
Multi-agent systems. Cambridge, MA: MIT 8
http://www.oracle.com/technology/prod-
Press. ucts/spatial/index.html
9
http://www.altova.com/products_semantic-
Vinoski, S. (2002). Middleware “dark matter.”
works.html
IEEE Distributed Systems Online. Retrieved April 10
http://cerebra.com/products/cerebra_busi-
24, 2007, from http://www.iona.com/hyplan/vin-
ness.html, last accessed September 2006
oski/pdfs/IEEE-Middleware_Dark_Matter.pdf
Walker, S. S., Brennan, R. W., & Norrie, D. H.
(2005). Holonic job shop scheduling using a mul-
tiagent system. IEEE Intelligent Systems, 20(1).
Wooldridge, M. (2002). An introduction to mul-
tiagent systems. John Wiley & Sons.

Chapter XIII
Web Services Hybrid
Dynamic Composition
Models for Enterprises
Taha Osman
Nottingham Trent University, UK

Dhavalkumar Thakker
Nottingham Trent University, UK

David Al-Dabass
Nottingham Trent University, UK

aBstract

Web services are used in enterprise distributed computing technology including ubiquitous and pervasive
computing and communication networks. Composition models of such Web services are an active research
area. Classified as static, dynamic, and semiautomatic composition models, these models address differ-
ent application areas and requirements. Thus far, the most successful practical approach to Web services
composition, largely endorsed by industry, borrows from business processes’ workflow management.
Unfortunately, standards subscribing to this approach fall under the static composition category, therefore
the service selection and flow management are done a priori and manually. The second approach to Web
services composition aspires to achieve more dynamic composition by semantically describing the process
model of the Web service and thus making it comprehensible to reasoning engines and software agents.
In this chapter, we attempt to bridge the gap between the two approaches by introducing semantics to
workflow-based composition. We aim to present a composition framework based on a hybrid solution
that merges the benefit of practicality of use and adoption popularity of workflow-based composition
with the advantage of using semantic descriptions to aid both service developers and composers in the
composition process and facilitate the dynamic integration of Web services into it.

introDuction called Web services composition and is feasible

to achieve because of the Web services advan-
The last decade has witnessed an explosion of tages of being platform and language neutral and
application services delivered electronically, loosely coupled.
ranging from e-commerce to information ser- The logic for composition mainly involves two
vice delivered through the World Wide Web, to activities: (a) the selection of candidate Web ser-
services that facilitate trading between business vices that fulfill the requirement in accumulation,
partners, better known as business-to-business and (b) the management of flow, which comprises
(B2B) relationships. Traditionally, these services control flow, the order in which Web services op-
are facilitated by distributed technologies such as erations are invoked; and dataflow, the messages
RPC (remote procedure call), CORBA (Common passed between the Web services operations.
Object Request Broker Architecture), and more The level of automation provided in performing
recently RMI (remote method invocation). Web these two activities classifies composition into
services are the latest distributed computing tech- static, semiautomatic, or dynamic categories.
nology. It is a form of remote procedure call like Static composition involves prior hard-coding
other distributed computing technology, but uses of the service selection and flow management.
XML (extensible markup language) extensively Performing selection and flow management on the
for messaging, discovery, and description. The use fly, in machine-readable format, leads to dynamic
of XML messaging makes Web services platform composition. In semiautomatic composition, the
and language neutral. Web services use SOAP service composer is involved at some stage (Thak-
(simple object access protocol; Gudgin, Hadley, ker, Osman, & Al-Dabass, 2005).
Mendelsohn, Moreau, & Nielsen, 2003) for XML
messaging, which in turn uses ubiquitous HTTP
(hypertext transfer protocol) for the transport WeB services comPosition
mechanism. HTTP is considered a secure protocol, aPProaches
thus it allows Web services to be exposed beyond
the firewall. The Web service messages and Workflow-Based Composition
operations with invocation details are described
using a platform-independent language WSDL Workflow-based techniques approach Web ser-
(Web services description language; Christensen, vices composition as a business process manage-
Curbera, Meredith, & Weerawarana, 2001). Web ment (BPM) solution. Business processes can be
services can be published and discovered using considered as the group of activities that carry
UDDI (universal description, discovery, and inte- out business goals (Leymann, Roller, & Schmidt,
gration protocol). The Web services architecture 2002). Business applications represent such ac-
centred on WSDL, UDDI, and SOAP is called a tivities in the business processes; for example, a
service-oriented architecture (SOA). customer order fulfillment process will include
To take advantage of Web services features, individual applications for the activities of a
network application services have to be developed customer placing an order, checking an account
as Web services or converted into Web services status, verifying an order, and dispatching an
using a wrapping mechanism. Moreover, multiple order. BPM deals with achieving the integration
Web services can be integrated either to provide of these individual applications to achieve a busi-
a new value-added service to the end user, or to ness process view.
facilitate cooperation between various business The main industrial standards to achieve such
partners. This integration of Web services is composition of Web services are WS-BPEL (Web

Web Services Hybrid Dynamic Composition Models for Enterprises

services business process execution language; semantic Web-Based composition

Andrews et al., 2003), WS-CDL (Web services
choreography description language; Kavantzas, The fundamental premise of the Semantic Web
Burdett, Ritzinger, & Lafon, 2004), and BPML is to extend the Web’s currently human-oriented
(business process modeling language; Van der interface to a format that is comprehensible to
Aalst, Dumas, ter Hofstede, & Wohed, 2002). software programs. Applied to Web services
These approaches use WSDL (declared operations composition, this can lead to the automation of
and data-typed messages) extensively to compile service selection and execution.
the composition scheme. All these standards fall The automation is achieved by describing the
under the static composition category; that is, Web services semantically, thus allowing software
the service selection and flow management are agents to reason about the service capability, and
done a priori and manually. However, commerce make all the decisions related to the composition
and industry remain loyal to the workflow-based on behalf of the user or developer. The decisions
composition for integrating services within the include the selection of appropriate services, their
enterprise (enterprise application integration), actual composition, and close examination of
and for forging B2B collaboration. how they meet the criteria specified by the user.
The prominent industrial standard, WS-BPEL, In contrast, in the static composition approach,
enhances and replaces existing standards XLANG the user or developer manually interprets the re-
from Microsoft and WSFL from IBM. Apart quirements for the required composition and the
from being based on WSDL, it uses workflow available service capability or functionality, and
management as the process model to achieve the makes decisions regarding how services can be
formalization for control flow and data flow. The interweaved to make a value-added service.
success of BPEL in the business community can DARPA’s OWL-S (ontology Web language for
be attributed to a number of factors. First, the Web services) is the leading semantic composi-
standards are built on top of workflow manage- tion research effort. OWL-S (Ankolekar et al.,
ment theory, making it ideal to model business 2001; Dean, Hendler, Horrocks, McGuinness,
processes’ interactions. The second factor is that Patel-Schneider, & Stein, 2004) ontologies pro-
BPEL and its derivatives are now mature standards vide a mechanism to describe the Web service’s
that provide a gamut of features for business pro- functionality in machine-understandable form,
cesses, such as transaction processing, support for making it possible to discover and integrate Web
state management with the use of callbacks and services automatically. An OWL-based dynamic
correlation sets, provision for exception handling, composition approach is described in Sirin, Hen-
and compensation fault processing features (Os- dler, and Parsia (2003), where semantic descrip-
man, Wagealla, & Bargiela, 2004) that are vital tions of the services are used to find matching
for the long-running and fault-vulnerable business services for the user requirements at each step
transactions. of composition, and the generated composition is
The adoption of BPEL as the Web service then directly executable through the grounding of
composition technology of choice has been re- the services. Other approaches use the artificial-
flected in the enthusiasm at large software houses intelligence (AI) planning technique to build a
in providing or including BPEL composition task list to achieve composition objectives: the
tools in their enterprise application servers, for selection of services and flow management for
instance, Oracle Application Server, Microsoft performing the composition of services to match
BizTalk Server, and the stand-alone tool from user preferences. McIlraith and Son (2002) use
IBM, BPWS4J. Golog, an AI planning reasoner, for automatic

Web Services Hybrid Dynamic Composition Models for Enterprises

composition, while in a similar spirit some other BriDging the Dynamic

approaches (Nau, Cao, Lotem, & Muñoz-Avila, comPosition gaP in BPel
1999; Wu, Parsia, Sirin, Hendler, & Nau, 2003)
have used the paradigm of hierarchical task net- the implementation scenario
work (HTN) planning to perform automated Web
service composition. We use the classic travel-agent problem (Thak-
Despite the enthusiasm of the research com- ker et al., 2005; White & Grundy, 2001) as the
munity about the semantic Web, there is still implementation scenario for our composition
some way to go for creating a unifying framework framework. The implementation is based on
facilitating the interoperation of intelligent agents the composition of real-world services from the
or reasoning engines and attempting to make airline, hotel, and car-rental businesses. None of
sense of semantic Web services. these applications interface to users through a
Web service, hence, Web service wrappers were
summary developed on top of their HTTP portals, and they
were then subscribed to a local UDDI and made
In large, efforts to facilitate automatic-composi- available for composition. For instance, wrap-
tion Web descriptions through semantic descrip- pers were developed for three airline services:
tions have been progressing in parallel, but also the EasyJet (http://www.easyjet.com/), WizzAir
in isolation, to developments in workflow-based (http://wizzair.com/), and FlyBmi (http://www.
standards preferred by the commercial organiza- flybmi.com/) portals. The parameters and field
tions. These organizations prefer a here-and-now names of particular Web services are maintained
and practical, albeit static, composition technique the same as on the Web portals.
that robustly supports their business needs to Our goal is to contribute to the automation
immature, research-biased, dynamic composi- of composing Web services using the BPEL ap-
tion techniques that are more focused on the proach. The automation should aid the service
automation factor rather than on business-specific composer in modeling a generic composition
requirements. scheme, and the service providers in adapting their
In this work, we attempt to bridge the gap application services to that scheme. The generic
between the two approaches by introducing se- composition scheme contains the composition
mantics to workflow-based composition. We aim logic that integrates the functionality of two or
to present a hybrid solution (Mandell & McIlraith, more Web services to achieve a common goal.
2003; Traverso & Pistore, 2004) that merges the In order to reduce the complexity of automation,
benefits of the practicality of use and adoption each composition scheme will be domain specific.
popularity of workflow-based BPEL composition This allows us to make the necessary assumptions
with the advantage of using semantic descriptions about the details of the application domain, that
to aid both service providers and composers in is, its process model, ontology, and so forth.
building the composition scheme and adapting In our approach, the service composer builds
new Web services to it. a BPEL-based scheme for the composition of ser-
vices belonging to specific application domains;
it is then the responsibility of the service provid-
ers to adapt their Web services, if necessary, to
the domain interface of the composition scheme.
One objective of this research is to make the
adaptation process as seamless as possible to the

Web Services Hybrid Dynamic Composition Models for Enterprises

service providers. The advantage to the service Figure 1. Domain-specific composition

composer is the ability to recompile and fire the
composition with different domain-specific Web
Hotel
services with minimal effort. AirLine
Domain Travel Agent BPEL Domain
For instance, our travel-agent application com- Process
poses services belonging to three domains: airline, WSDL Namespaces WSDL
PartnerLinks
hotel, and car rental. The travel agent prespecifies Variables
OWL OWL
the functionality (domain interface) that it expects Assignments
Process Logic
from each participant, for example, price quota-
tion for the user-specified flight details. A large WSDL
section of information engines and e-commerce
OWL
services that integrate different Internet-based
services through a unifying access interface fall
under the same category, for instance, loan provid- Car
Domain
ers (loan assessor, banks, insurance companies)
and shopping robots.
The following sections explain how the domain
interface is specified and how it is exploited to
facilitate the seamless, dynamic composition of formalized in terms of layers built on top of XML
Web services based on the BPEL approach. as XML alone provides only syntactical support
and has no notion for the meanings required
Specification of the Domain of for achieving goals for the semantic Web. RDF
services (resource description framework), RDFS, and
OWL are the specifications from the W3C (World
Central to the idea of grouping services in a Wide Web Consortium) to add semantics. These
domain is the presentation of a domain interface specifications provide language expressiveness
for the functionality expected from the service by and simulate human reasoning. OWL uses and
the service composer in a standard, unambiguous extends RDF to specify ontologies. Ontologies
format that is comprehensible by programs rather define common specifications of domain-related
than humans. The Web services standard WSDL concepts. Ontologies are like dictionaries, where
provides XML grammar to describe the working the meaning of a concept can be described in
of the Web services. WSDL can be used for defin- the form of unambiguous semantic descriptions.
ing the expected functionalities from a participant Another aspect of ontologies is that the reasoner
Web service for a particular domain. However, can be designed to interpret these conceptual
the problem with WSDL is that it is a syntactical meanings or derive deduction from the semantic
standard that is developed for human developers description, making the solutions program based
rather than program-based automation. and computer interpretable.
The recent trend in the area of Web automation In our suggested solution, we use ontologies
is initiated by the Semantic Web. A fundamental extensively. OWL is the most expressive knowl-
component of the Semantic Web is the markup of edge representation for the semantic Web so far.
the traditional World Wide Web to make it com- For designing the domain interface for expected
puter interpretable, user apparent, and agent ready functionality for a particular domain, WSDL
(McIlraith, Son, & Zeng, 2001). The approach files describing the domain functionality in XML
adopted by the semantic Web to achieve this is grammar are accompanied with a semantic de-

Web Services Hybrid Dynamic Composition Models for Enterprises

Figure 2. Domain-specific interface – WSDL file

<wsdl:definitions targetNamespace=“http://travelagent.ntu.ac.uk/
AirLineDomainService”>

<wsdl:types>

scription of the service parameters expressed in the departureFlightDate element of this airline
the OWL ontology. This allows the description of description is conceptually similar to the element
expected functionality to be inferred in unambigu- departure-date in Figure 3.
ous form. Figure 1 illustrates the application of the
above solution to our travel-agent example. Dynamic Pool for Domain-Specific
A snippet of such an OWL-WSDL domain in- Web services (DPDWs)
terface for the airline domain is shown in Figures
2 and 3. The WSDL file complex-type FlightQuery In the second phase of our framework, we attempt
of Figure 2 has been mapped into the OWL class to integrate the domain-specific Web services into
FlightQuery of Figure 3; hence, an OWL reasoner a dynamic pool, where the services can dynami-
can apply the class-relationship-based inference cally plug in and out of the composition scheme
to verify that the mapped message type contains without the need to recode the composition logic.
all required elements. As explained in the previous section, the prereq-
If a new domain-related Web service is to be uisite for domain membership is the availability of
created, the domain-interface files can be used a WSDL file describing the service functionality
to create a new Web service that adheres to the and an accompanying ontology file ensuring the
functionality expected by the service composer. compatibility of the service parameters to the
Otherwise, the service provider needs to edit the domain interface.
ontology file to overcome any mismatches in the
service descriptions (parameters and method Domain Membership Verification
names). In this case, the ontology can bridge the
semantic mismatch provided that conceptual A module has been created for verifying the mem-
meaning remains the same. Figure 4 describes bership of Web services to a particular domain and
an ontology file provided by one of the candidate ultimately the composition scheme. The module
airline services to overcome semantic mismatches verifies the above-mentioned prerequisite accord-
with the travel-agent domain interface. The on- ing to the following steps (the airline domain is
tology file in Figure 4 documents the fact that exemplified).

0
Web Services Hybrid Dynamic Composition Models for Enterprises

Figure 3. Domain-specific interface – OWL file

<owl:Ontology rdf:about="http://localhost/ntu/ac/uk/2005/
TravelAgent/AirLineDomain.owl">
</owl:Ontology>
<owl:Class rdf:about="http://localhost/ntu/ac/uk/2005/
onto/travelquery.owl#FlightQuery">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty
rdf:resource="http://localhost/ntu/ac/uk/2005/onto/travelquery.owl#noOfAdults" />
<owl:someValuesFrom>
<rdfs:Datatype rdf:about="http://www.w3.org/2001/XMLSchema#
int"/>
</owl:someValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty
rdf:resource="http://localhost/ntu/ac/uk/2005/onto/travelquery.owl#departure-date" />
<owl:someValuesFrom>
<rdfs:Datatype rdf:about="http://www.w3.org/2001/XMLSchema#
dateTime"/>
</owl:someValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>

1. Parse the OWL-WSDL files of the candidate the membership module stores the valid map-
Web services against the domain interface ping departure-date-> departureFlightDate
to check all the possible mappings between for the EasyJet service (see Figures 3 and
what is expected and what is provided by the 4).
candidate service. If the candidate service 2. If the service parameters match semantically,
description file (WSDL) has a different make the service available within the Airline
format from the domain description file, the DPDWS (Figure 5), that is, composition
supplied ontology is searched for a mapping ready; this involves storing a reference for
for this mismatch. If the ontology file has the the service with the composition-necessary
required mappings, the mappings are stored details: the target name space, mappings
for future use when the actual composition between required and provided elements,
with this service takes place. For instance, the operation name with corresponding

Web Services Hybrid Dynamic Composition Models for Enterprises

Figure 4. Ontology file for EasyJet airline service

<owl:Ontology rdf:about=“http://localhost/
ntu/ac/uk/00/EasyJet/easyjet.owl”>
</owl:Ontology>

<owl:DatatypeProperty rdf:about=“http://localhost/ntu/ac/uk/2005/ EasyJet/

easyjet.owl#departureFlightDate”>
<owl:equivalentProperty>
<owl:DatatypeProperty rdf:about=“http://localhost/
ntu/ac/uk/00/onto/travelquery.owl#departure-date”>
</owl:DatatypeProperty>
</owl:equivalentProperty>
</owl:DatatypeProperty>

Figure 5. Membership verification module for DPDWS

FlyBmi WizzAir
Membership
Verification

Dynamic Pool for Domain-Specific EasyJet Service

Provider
Web Services (DPDWS)

port types, message names, and message composition ready by following the membership
types. The verification module also creates verification algorithm.
the partnerLink name, partnerLink type, The next section details the mechanism for
and partnerLink role based on the service automating the dynamic selection of Web services
name for this service. These details can be from the dynamic pool and their integration into
used when the actual composition is carried the composition scheme.
out.
Dynamic BPel-Based service
Figure 6 is a snapshot of the implemented composition facilitated by DPDWs
airline domain membership verification module,
which implements this algorithm and is designed Overview
using Jena (2001), the Pellet (2004) ontology
reasoner, the DOM XML parser, and Java tech- In our framework, dynamically adding a Web
nology. The only input required from the service service from the domain pool constitutes plac-
provider is description and ontology files, and ing an instance of the service in the composition
our composition takes care of making the service scheme file. For example, to add the functionality

Web Services Hybrid Dynamic Composition Models for Enterprises

Figure 6. Airline domain membership verification

Box 1.

[<invoke name partnerLink=“EasyJetPL” portType=“ejet:EasyJetPortType”

operation=“checkReservation”
inputVariable=“inputEasyJet” outputVariable=“outputEasyJet”/>]

of retrieving a price quote for a specific journey and can add them throughout the composition
by the EasyJet airline service, the travel-agent scheme, making the creation of the process file
service composer will have to add the instance automatic and execution ready. This makes the
shown in Box 1 to the relevant execution segment scenario in Figure 7 possible, where services
of the BPEL composition file. from the domain can be plugged in and plugged
Such integration is automatically performed by out automatically.
our dynamic composition framework. Hence, the The target BPEL execution engine for our
BPEL process file does not have to be manually framework is Oracle’s BPEL Process Manager
edited and recompiled to integrate alternative (Oracle BPEL PM, 2005). It is worth mentioning
Web services into the composition scheme. Table that this particular implementation of BPEL also
1 shows how a BPEL process can be created with requires two additional files to be input with the
our programming-based framework. BPEL process file: a service wrapper WSDL file
This implies that the process file can be that contains information to make the service
created dynamically with the inclusion of the a partner in the business process, and a BPEL
new services from the particular domain. This configuration file that identifies the location of
programming-language-based tool can create the wrapper file and binds it with a particular
the service references by reading the WSDL file Web service partnerLink. For each new service

Web Services Hybrid Dynamic Composition Models for Enterprises

Table 1. Process file creation with Java

Required Corresponding
Composition Function Framework Method

public String setParetnerLinks(

Add partnerLinks for the airline
Document bpeldoc, String prefix,
service with particular values for
String partnerlink_name,
the new service
String partnerlink_type,
String partnerlink_role)

Set the process logic for the public void setPriceCheckInstance

airline service by placing (Document bpeldoc, String invar, String
partnerLink, which has the price- outvar, String portType,
check operation String operation,
String partnerlink_name)

participating in the composition, the bpel.xml file, reflecting the travel-agent composition
file is modified to include the new service. Our logic.
implementation creates the process file and wrap- 2. On the selection of an alternative domain
per file, and adds the entry in the bpel.xml file, service, generate a new BPEL file and other
making the process files composition ready and configuration files required by the BPEL
acknowledging the inclusion of the newly added execution engine. This is achieved as fol-
service. lows.
Following is the algorithm for DPDWS-fa- i) Retrieve reference for this service from
cilitated composition, which creates the BPEL the membership verification module.
process file automatically, allowing the services This will include all the details per-
to be dynamically selected from the domain. taining to the service and required
by the composition module including
Algorithm for DPDWS-Facilitated partnerLink details. Also retrieve
Domain-Specific Composition semantic mappings from the member-
ship verification module and use them
Our framework performs the following steps for wherever applicable during the process
facilitating the dynamic composition of domain- logic.
specific Web services. ii) Add the new service name space in
the root element for the newly created
1. Initialize the composition framework. This BPEL file.
will result in the DPDWS populated with the iii) Add partnerLinks for the new service,
services, which were verified by the mem- generate partnerLinks automatically,
bership verification module. An arbitrary and maintain uniqueness.
Web service from the domain pool will be iv) Map the messages of the Web service
selected to create a skeleton BPEL process to the variables; the variable names are

Web Services Hybrid Dynamic Composition Models for Enterprises

Figure 7. Travel agent composition facilitated by DPDWS

FlyBmi WizzAir

AirLine DPDWS Hotel DPDWS

Travel Agent
Composition
Module

Car DPDWS

generated automatically. Steps ii to iv 5. Bind the partnerLink details with the service
use the reference details created during wrapper file location and modify the existing
membership verification. bpel.xml file to reflect the integration of the
v) Build the process logic for the new ser- new service.
vice by placing all the service instances.
This includes the addition of the service The composition module algorithm is imple-
instance at all the places where the com- mented using Java technology and the DOM XML
position logic for a particular domain parser. Figure 8 illustrates the administration
is defined in the default skeleton BPEL interface of our composition framework. The
process file. Examples of such instances locations of process (BPEL skeleton files) and con-
can be invoking the service, assigning figuration files are necessary for the initialization
responses to intermediate variables and of the framework. The list of available services to
passing them for particular operations, each DPDWS is dynamically populated with the
and so forth. membership verification module detailed earlier.
3. Validate the newly generated BPEL file. The service composer can select any possible
4. Create the service wrapper file with the combination of services from domains for com-
partnerLink information defined for the position, and new process files with configuration
service reference and include a pointer to files are automatically created; the composed
the location of the WSDL file within the service is fired if required.
wrapper file.

235
Web Services Hybrid Dynamic Composition Models for Enterprises

Figure 8. Travel-agent composition

relateD Work service providers. This interface serves as the

prerequisite for joining the particular domain.
In recent years, the research community has Hence, we take a top-down approach by declaring
realized that the union of semantics with busi- expected requirements first and then populating
ness standards can be helpful in mechanizing domains with legitimate services (ones that fulfill
composition tasks. the requirements), unlike Mandell and McIlraith
Mandell and McIlraith (2003) propose a bot- (2003) who use OWL-S profiles for selecting ser-
tom-up approach for Web services interoperation vice partners based on service descriptions. Our
in BPEL4WS (BPEL for Web services); they approach also allows creating a general reusable
use OWL-S-based descriptions for the run-time programming framework for selecting services
binding of service partners. The implementation from a particular domain and composing them
collects the OWL-S profiles into a repository and automatically.
exploits the profile semantics to query partners for Traverso and Pistore (2004) represent an AI-
desired properties. This approach allows selecting planning-based technique to convert semantic
partners at run time otherwise selected at design (OWL-S) Web service process models into execut-
time according to the BPEL process model. able BPEL4WS processes. The implementation
The approach uses semantic Web technology translates the OWL-S profile models into partially
for automatic, meaningful service selection. How- observable state transition systems, which are
ever, the problem of making actual composition utilized for generating plans to reach the goals
automatic is not addressed as the composition for composition. Their approach uses semantics
logic is built manually for the inclusion of partner at the composition level and takes advantage of
services. the expressiveness and executable nature of low-
In our solution, we consider the composition level BPEL processes. The approach aims for the
from the service composer’s perspective. The composition of services to be automatic, while
service composer categorizes the possible service service discovery and selection is manual.
partners into domains and makes the domain- In our approach, we also use semantics at
specific interface (WSDL-OWL) available to the the composition level; however, we exploit the

Web Services Hybrid Dynamic Composition Models for Enterprises

BPEL process creation mechanism combined with unambiguous form and catering for any mis-
the domain concept to implement an automatic matches in the Web services description. A domain
composition programming framework rather than membership verification module was developed
using planning techniques. Our implementation that allows the service providers to adapt their
also allows the selection and removal of service application services to the domain interface and
partners for the composition to be automatic. make them with minimal effort.
Once a domain Web service is declared compo-
sition ready, our dynamic composition framework
conclusion transparently integrates the Web service into
the BPEL process file; that is, it is automatically
The aim of this work is to create a framework added to the pool of dynamic Web services for this
that alleviates the burden of dynamic Web ser- domain. The chapter describes the algorithm for
vices composition. We argue that despite the the dynamic population of the domain pool with
evident popularity of Web services as a secure Web services, thus allowing the service composer
distributed computing paradigm and the value- to effortlessly select any possible combination of
added dimension that composition adds to it, services from the composition domains and fire
the practical adoption of the technology is still the composed service.
hindered by the knowledge and effort required Work under progress aims to extend the de-
for the compilation of the composition process veloped framework to facilitate the automatic
and the manual adaptation of new and existing matchmaking of Web services according to user
Web services to it. criteria and the quality of the provided service.
After critical analysis of current approaches
to Web services composition, we concluded that
a practical and current solution should be based references
on a hybrid solution that merges the benefits of
the practicality of use and adoption popularity of Andrews, T., Curbera, F., Dholakia, H., Go-
workflow-based (BPEL-based) composition with land, Y., Klein, J., Leymann, F., et al. (2003).
the advantage of using semantic descriptions to Business process execution language for Web
aid the composition participants in the automatic services, version 1.1. Retrieved April 10, 2006,
discovery and interoperability of the composed from http://www-128.ibm.com/developerworks/
services. library/specification/ws-bpel/
The main premise of our approach is to aid
Ankolekar, A., Burstein, M., Hobbs, J., Lassila, O.,
the service composer in building a generic BPEL-
Martin, D., McIlraith, S., et al. (2001). DAML-S:
based scheme for the composition of services
Semantic markup for Web services. Proceedings
belonging to specific application domains, and
of the International Semantic Web Working Sym-
assist the service providers in adapting their ap-
posium (SWWS), 411-430.
plication services to the composition scheme. Web
services join the BPEL composition scheme by Christensen, E., Curbera, F., Meredith, G., &
subscribing to a specific domain interface. Weerawarana, S. (2001). Web services descrip-
The domain functionality described in WSDL- tion language version 1.1 (W3C recommenda-
XML grammar is accompanied by a semantic tion). Retrieved April 10, 2006, from http://www.
description of service parameters expressed in w3.org/TR/wsdl
the OWL ontology, allowing the description of
the expected domain functionality to be in an

Web Services Hybrid Dynamic Composition Models for Enterprises

Dean, M., Hendler, J., Horrocks, I., McGuinness, Oracle BPEL PM. (2005). Retrieved April 10,
D., Patel-Schneider, P. F., & Stein, L. A. (2004). Se- 2006, from http://www.oracle.com/technology/
mantic markup for Web services: OWL-S version products/ias/bpel/index.html
1.1. Retrieved April 10, 2006, from http://www.
Osman, T., Wagealla, W., & Bargiela, A. (2004).
daml.org/services/owl-s/1.1/
An approach to rollback recovery of collaborating
Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, mobile agents. IEEE Transactions on Systems,
J., & Nielsen, H. F. (2003). Simple object access Man, and Cybernetics, 34, 48-57.
protocol version 1.2 (W3C recommendation).
Pellet. (2004). Retrieved April 10, 2006, from
Retrieved April 10, 2006, from http://www.
http://www.minswap.org/2003/pellet/
w3.org/TR/soap/
Sirin, E., Hendler, J., & Parsia, B. (2003). Semi-
Jena. (2003). Retrieved April 10, 2006, from
automatic composition of Web services using
http://jena.sourceforge.net
semantic descriptions. Web Services: Modeling,
Kavantzas, N., Burdett, D., Ritzinger, G., & Lafon, Architecture and Infrastructure Workshop in
Y. (2004). Web services choreography description ICEIS.
language (WS-CDL) version 1.0. Retrieved April
Thakker, D., Osman, T., & Al-Dabass, D. (2005).
10, 2006, from http://www.w3.org/TR/2004/WE-
Web services composition: A pragmatic view of
ws-cdl-10-20041217/
the present and the future. Nineteenth European
Leymann, F., Roller, D., & Schmidt, M.-T. (2002). Conference on Modelling and Simulation: Vol. 1.
Web services and business process management. Simulation in wider Europe, 826-832.
IBM Systems Journal, 41(2), 198-211.
Traverso, P., & Pistore, M. (2004). Automated
Mandell, D., & McIlraith, S. (2003). Adapting composition of semantic Web services into ex-
BPEL4WS for the semantic Web: The bottom-up ecutable processes. Proceedings of Third Inter-
approach to Web service interoperation. Pro- national Semantic Web Conference (ISWC2004)
ceedings of the 2nd International Semantic Web (pp. 380-394).
Conference (ISWC2003).
Van der Aalst, W. M. P., Dumas, M., ter Hofstede,
McIlraith, S., & Son, T. C. (2002). Adapting Golog A. H. M., & Wohed, P. (2002). Pattern-based
for composition of semantic Web services. Pro- analysis of BPML (and WSCI) (Tech. Rep. No. FIT-
ceedings of the Eighth International Conference TR-2002-05). Brisbane, Australia: Queensland
on Knowledge Representation and Reasoning University of Technology.
(KR2002), 482-493.
White, P., & Grundy, J. (2001). Experiences
McIlraith, S., Son, T. C., & Zeng, H. (2001). Se- developing a collaborative travel planning ap-
mantic Web services. IEEE Intelligent Systems, plication with .NET Web services. Proceedings
16(2), 46-53. of the 2003 International Conference on Web
Services (ICWS).
Nau, D. S., Cao, Y., Lotem, A., & Muñoz-Avila,
H. (1999). SHOP: Simple hierarchical ordered Wu, D., Parsia, B., Sirin, E., Hendler, J., &
planner. Proceedings of the International Joint Nau, D. (2003). Automating DAML-S Web ser-
Conference on Artificial Intelligence (IJCAI-99), vices composition using SHOP2. Proceedings
968-973. of 2nd International Semantic Web Conference
(ISWC2003).

Section IV
Enterprise Integration
Case Studies
0

Chapter XIV
Case Study:
Enterprise Integration and
Process Improvement

Randall E. Duran
Catena Technologies Pte Ltd, Singapore

aBstract

Enterprise integration (EI) can be a major enabler for business process improvement, but it presents its
own challenges. Based on the process improvement experiences of banks in several different countries,
this chapter examines common EI challenges and outlines approaches for combining EI and process
improvement to achieve maximum benefit. Common EI-related process improvement challenges are poor
usability within the user desktop environment, a lack of network-based services, and data collection and
management limitations. How EI affects each of these areas is addressed, highlighting specific examples
of how these issues present themselves in system environments. The latter part of this chapter outlines best
practices for combining EI with process improvement in relation to the challenges identified. Guidelines
are provided on how to apply these practices in different organizational contexts.

introDuction by too many road signs or a rough road surface,

whereas processes may be hindered by high levels
Business process improvement and highway of complexity or user-unfriendly systems.
traffic flow optimization have several similari- Traffic planners and process improvement
ties. For example, both try to improve the total specialists have a wide range of techniques avail-
volume supported, increase rates of flow, and able to achieve improvement. Where a highway
decrease completion and journey time. Business planner might designate a car-pool lane or change
processes benefit from reducing the number of the speed limits, the process improvement special-
exceptions, and traffic flow from reducing the ist can eliminate handoffs or reallocate staff to
number of accidents. Likewise, both are affected reduce bottlenecks. Using these techniques, im-
by less tangible factors. Drivers may be distracted provements can often be made without significant
changes to the existing environment.

These minimal-impact approaches will im- Process imProvement

prove performance, but their overall effect will be
limited. Some advantage may be gained by using To appreciate the benefits that EI can provide, it
these techniques, but it may be the case that as is first necessary to understand the environment
much as 70% or 80% of the potential improvement within which process improvement is achieved.
still remains. Realizing these more significant The examples discussed are representative of
gains requires changes to how the outside world situations that banking business units encounter
interacts with these flows. In the case of optimizing across different functional areas in both the front
highway traffic, it may require building new con- office and the back office. Although the examples
necting roads, bridges, and on-ramps. For process are drawn from the financial services industry,
improvement, it often requires the development similar activities and processes are found in
of connectivity to the applications and systems many other industries. Thus, the discussion of the
that are used within the process. Enterprise in- process improvement environment will focus on
tegration (EI) can provide this connectivity and common considerations rather than specific details
is critical to the overall success of many process that might only be relevant to a single industry
improvement initiatives. or business area.
This chapter examines how EI can best support
process improvement. The examples presented the Process improvement
are primarily based on the experiences of three environment
financial service institutions based in the United
States, Japan, and Singapore. Each company Processes that manage information usually make
had a different focus—call center, retail bank- use of paper, software, or a combination of both
ing, and enterprise-wide processes—and is at paper and software. At one extreme, entirely
a different stage of implementation: between 6 paper-based processes may involve receiving
months and 3 years after starting to use EI for handwritten or typed information and combining
process improvement. However, the conclusions it with other printed information from paper-based
and lessons learned are not unique to the financial files or printouts from software systems. These
services industry; they are applicable to process process inputs can result in stacks of paper that
improvement in many different industries. The are physically moved between people who then
objective of this chapter is to help those planning check and verify information in the documents,
EI to better understand the context, perspectives, make calculations, and eventually approve or deny
and challenges of process improvement initiatives, the requests. While this type of processing may
and to help those planning process improvement sound terribly inefficient and anachronistic to IT
initiatives to understand how to best apply EI to professionals, it is an environment that still exists
help business processes achieve the significant in many business areas, such as loan application
productivity gains. processing.
The structure of this chapter is as follows. Given that it is now the 21st century, it is more
The first part discusses process improvement ap- often the case that at least some of the process
proaches and considerations, and how they relate information will be stored in and manipulated
to EI. The second part reviews common process through software applications. Unfortunately,
improvement problems and explains how EI can though, it is uncommon to find totally paper-
help. The third part outlines best practices for less business operations; both paper and soft-
applying EI to support process improvement. ware-based systems continue to drive business
processes. For example, a call center operation

Case Study: Enterprise Integration and Process Improvement

may use software-based customer relationship ing for the root cause of problems and potential
management (CRM) and core banking systems areas for optimization.
to fulfill the majority of customer call requests. The Six Sigma methodology (Pande, Neu-
However, paper will still be abundant in the call man, & Cavanagh, 2000) has been used by many
center processes. For example, printed copies of organizations to support process improvement. It
reference information for recent sales promotions provides a set of quantitative techniques that are
or tabular information that is used to support de- used for process improvement. Six Sigma’s define,
cision making may be tacked to cubicle bulletin measure, analyze, improve, and control (DMAIC)
boards, or paper forms may be used to initiate approach focuses on capturing and analyzing pro-
manual processes, such as special approvals cess execution information. Although significant
that may be required when a transaction amount effort may be involved with defining, analyzing,
exceeds a specified limit. and improving processes, often it is the collection
In more IT-focused organizations, some proof process data for the measure and control stages
cesses are entirely paperless. While eliminating that requires the most onerous effort. Moreover,
paper may sound like a panacea for process the amount and granularity of the data gathered
improvement, there is still a number of problems will affect both the quality of the analysis and
with which paperless processes often struggle. scope of the collection effort.
Two of the core problems are using too many Other, qualitative techniques, such as process
different software applications within a single flow analysis and value-added analysis (Har-
process, and using applications for purposes rington, 1991), focus on achieving performance
other than they were designed. The first problem gains by categorizing the process activities,
relates to the fact that there is usually no single identifying non-value-adding flows or activities,
monolithic application that will perform all the and then optimizing the flows to achieve gains.
functions required by a business process. The Improvements are often achieved by eliminating
second problem is caused by existing application handoffs between people or groups, reducing de-
functionality not fully matching the business’ lays, minimizing physical transport (i.e., moving
requirements. Functional differences may result stacks of paper around), reducing the likelihood
from using off-the-shelf software packages for of exception flows related to failure conditions,
more specialized functions; alternatively, existing eliminating bottlenecks, and reducing overall
software may not be enhanced to meet changing process complexity.
business requirements. In a business environment that is largely paper
based, there is usually a number of areas that can
Process improvement techniques be improved using these qualitative techniques.
However, after the initial optimization is com-
It is in this environment that process improvement pleted, further use of these techniques will yield
initiatives must achieve goals such as reducing limited results. Typically, to make further pro-
processing time, reducing processing effort, and ductivity gains, it will be necessary to automate
improving resource utilization. Fortunately, there the process steps using either business process
is a number of process improvement techniques management (BPM) technology (Khan, 2004)
that can help. Quantitative techniques use process or customized software applications.
execution measurements and statistical methods to Alternatively, in business environments that
help identify problem areas and verify improve- have achieved a higher degree of automation,
ment gains. Qualitative techniques review and where IT-based systems are more prevalent
analyze process flow steps and functions, search- than paper-based systems, the inefficiencies that

Case Study: Enterprise Integration and Process Improvement

qualitative analysis will uncover usually relate to prevalent in many business environments. While
the limitations of and incompatibilities between some CRM and enterprise resource planning
various IT systems involved in the process. In (ERP) vendors promote their systems as the
this situation, achieving productivity gains will single monolithic source of all information and
depend on being able to take advantage of EI. services, in practice this is rarely the case. The
limitations of core applications, the need for
specialized and customized applications, and the
challenges existence of legacy applications conspire together
to prevent the single-application promise from
Having reviewed some of the goals of and tech- being fulfilled.
niques for achieving process improvement in A significant downside of using multiple user
the previous section, this section will explore interfaces (UIs), from a process performance
common challenges that process improvement standpoint, is increased process complexity. Users
initiatives face involving EI. For each area, we must switch between applications within a single
will review the scope of the problem, examine spe- process. Also, when using multiple UIs, the user,
cific examples, and discuss how applying EI can that is, the process executor, may need to log in
yield material benefits for process improvement. multiple times and consequently remember and
The specific areas considered are poor usability manage multiple user accounts and passwords.
within the user desktop environment, a lack of In some cases, systems may automatically time
network-based services, and data collection and out user accounts after 10 or 15 minutes. Thus,
management limitations. it may be necessary to log in multiple times each
day. Another cost of having multiple UIs is that
Poor usability within the user the user may have to enter the same data several
Desktop environment times in different applications to execute a query
or enter a data record that is maintained, in part
There are three main reasons why desktop com- or in whole, across multiple IT systems.
puters do not help users execute processes as ef- Beyond the relatively simple consideration
ficiently as they could. First, it may be necessary of logging in, the user interfaces often differ
to use a large number of different applications dramatically in their look and feel and their
with different styles of interaction at various times manner of operation. Mainframe applications
throughout the process. Second, the applications will be often run in 3270 emulation windows,
may not have been designed for the purposes that using two- to four-letter typed commands as the
they are used within the process, and as a result, primary means of navigating between screens.
they are not user friendly. Third, all of the applica- Thick-client Windows or Java applications are
tion functions and screens are often accessible to normally menu driven, and in some cases the ap-
the user at any time without respect to the logical plications will support drag and drop semantics
flow of process steps and the functions that are and in other cases not. Thin-client, Web-based
required at different stages. In this section, we applications may have a click-through or tab
will address the first and second problems; the orientation and may use bookmarks. Even if the
third is an area that is best addressed using BPM applications in use are all of a single style, they
tools rather than EI. will often use different terminology, lay out the
The imposition of disparate applications on same information in different ways, or provide
business users is fundamentally an application the user with different idioms for interacting with
architecture issue. However, this situation is the system.

Case Study: Enterprise Integration and Process Improvement

It is not uncommon to have a combination of plified user environment will help reduce human
all of these types of applications as part of the error and, therefore, also improve process perfor-
desktop of a call center or back-office operation. mance by reducing the number of exception cases
Hence, when training staff on business processes, that must be handled. However, streamlining the
it is necessary to teach them the intricacies of each desktop environment requires that the required ap-
of the applications involved in the process. The plication data and services are readily accessible.
more applications involved in the process, the The technology behind providing a consolidated
greater the effort required by the users to learn and UI application framework is not challenging; it can
remember how to operate all of the applications. be implemented in a Web browser or thick-client
If a fully optimized user desktop environment application. It is providing the linkages from that
were available, the user would interact with only a consolidated UI to all of the other systems that
few applications, or possibly just one, to perform is a major challenge. This is where EI provides
all process steps, and all user interactions would an advantage.
have a consistent look and feel. Automation, another key process improvement
It is also the case that applications are used for aspect, is also highly dependent on EI. Decisions
purposes other than designed: General-purpose and calculations cannot be automated without be-
applications are sometimes used for very specific ing able to access the information that underlies
functions, and vice versa. As a consequence, the decision logic or arithmetic calculations in an
the user may have to perform many additional elemental form. Often, these values are locked up:
steps to complete a process task. For example, either embedded in screen displays, or stored in
one of the steps of the process may require the databases that are not readily accessible. EI is criti-
user to check to see whether a customer account cal in unlocking these data resources, enabling the
balance is above a specified limit. This single automation of process calculations and workflow
process step can then require the user to open to achieve process improvement.
the customer information system application, In examining the desktop environment, we
log in, navigate to the appropriate screen that touched on the need to access multiple IT systems
holds the account balance information, and then using EI. In the next section, we will examine
scan the information shown, which may be quite the technical challenges encountered with this
dense, to find the amount. Then, the user must undertaking.
compare the balance amount to a limit that may
be recalled from memory, read from a sheet of lack of network-Based services
paper, or looked up in another application. In a
fully optimized user desktop environment, only The follow-on challenge to improving perfor-
the relevant information—whether the account is mance by streamlining the user interface is to ef-
above or below the limit—would be shown. The fectively use EI to provide access from the desktop
user would not need to open and navigate through to the relevant IT systems. Ideally, a streamlined
the application to get one half of the information, UI would provide access to both existing and new
and would not have to do a manual comparison common network-based services using a common
of the balance and limit amounts. EI platform. Existing-system services encapsulate
Significant process improvement gains, and expose functions in existing IT applications.
through simplification and automation, can be Common services are synthesized functions that
achieved by the elimination of switching between can be used by a number of different processes,
different applications and by only displaying the contain business rules and validation logic, and
data relevant to the current process step. A sim- may combine functions of multiple different IT
systems.

Case Study: Enterprise Integration and Process Improvement

In business processes, applications are usually existing systems as customizations. For example,
accessed through their own proprietary UI. As part process-specific logic for performing decisions
of a process, the application may be referenced and calculations may be manually executed,
through instructions such as “If the customer based on written instructions in the form of tables,
qualifies, go to the ZY screen and check the ap- formulas, or worksheets. This business logic may
proved box,” and “Then go to the QQQ application relate to transaction limits, customer profiles, or
and initiate workflow #4 to send the request to the calendar schedules, and may frequently change
fulfillment department.” The process focuses on and so cannot be hard-coded into the IT systems.
the specifics of the applications rather than on the From a process improvement standpoint, the cen-
purpose and objectives of the business function. tralization and automation of these activities will
If the applications are changed, the processes yield significant benefits. By making the decision
must be redefined and users must be retrained. logic or calculations automated, the process flow
Ideally, in this case, process improvement would will be significantly simplified. The overhead of
limit the user effort to verifying approval criteria training users how to perform these sometimes
and signifying approval or rejection. The specific very complex steps is eliminated. Furthermore,
applications that are used to record approval and changes and updates to the business logic only
initiate the follow-on workflow activities should need to be made in one place, so the effort of
be hidden behind EI in the form of network-based accommodating changes to the business logic is
services to reduce the complexity. reduced. If an algorithm is changed, the common
In business process environments with lim- service can be changed rather than requiring new
ited EI, functionality that should be maintained instructions to be distributed and the users to be
in common services is often present as manual retrained. EI can help provide flexibility to enable
steps forming part of a workflow or embedded in these common services to be implemented in many

Figure 1. A typical software-driven process execution environment

CORBA
User Desktop Core Sys.

JMS
Appl. A Appl. B
CRM

Appl. D Appl. C SNA 0

Cust. Info.

JDBC

MIS

Case Study: Enterprise Integration and Process Improvement

different forms, including some that are easily is that the information is dispersed across a num-
updated by the business users themselves. ber of different business applications and data
Unfortunately, well-encapsulated, network- stores. Typically, as the complexity of a process
based services do not yet exist in many organiza- increases, so does the number of business ap-
tions, creating an impediment to the development plications and number of operational data stores
of a streamlined UI and limiting overall process involved. In some cases, the proliferation of data
improvement capabilities. To do integration with- stores is unavoidable, particularly in cases where
out such services, it is necessary to work with a proprietary, third-party applications have data-
mélange of different technologies to integrate bases embedded, which are not open for external
multiple IT systems within the scope of a single access. More often, however, is the case where
process. These technologies may include screen additional data stores, in the form of databases and
scraping, SQL queries, messaging through Web spreadsheets, are created in an ad hoc fashion to
services, JMS, COM, or CORBA, and mainframe meet tactical business or application needs. The
SNA operations. Many of the IT systems may also availability of low-cost, easy-to-use databases
be under the control of different departments, has fueled this trend.
creating further challenges. The net result is that Common reasons for the creation of new data
without a services model, even the initial inves- stores are the following.
tigation, definition, and specification of system
integration requirements can be a long and daunt- • New, business-specific applications are
ing task for process improvement initiatives. As a developed by the business units without
result, sometimes the effort involved to integrate the coordination of a central IT planning
IT systems may outweigh the benefits that would function. For example, business users may
be achieved for the process. want to keep track of the progress and/or
Having an EI strategy and making use of a ser- results of a process for either management
vice-oriented architecture (SOA; Krafzig, Banke, information purposes or so that other groups
& Slama, 2005) can help get past these hurdles. or customers can view the current state of
Network services, provided through EI, can enable the transactions.
process improvement specialists to focus on the • Limitations of existing, often-third-party
business abstractions and interfaces rather than systems require that information related
on the details of the technical connectivity and to new business requirements be stored in
application data structure. Additionally, services separate tables or databases.
can often be reused across different processes, • Obstacles, either technical or security
reducing the effort required to build new infra- related, to accessing existing data stores
structure as time progresses. If integration is done make creating new databases the path of
in an ad hoc fashion, there is normally little or no least resistance for business users.
reuse of integration technology.
Creating new data stores can provide tacti-
Data collection and management cal benefits, supporting the development of new
limitations systems, but it leads to strategic problems of
increased complexity, duplicated information,
The growth of systems over time, both in number and inconsistencies between different IT systems.
and complexity, often leads to difficulties in col- While, fundamentally, this is a system and data
lecting data required for process improvement and architecture problem, the near-term benefits of
management purposes. The root of the problem data aggregation are hard to quantify. Thus,

Case Study: Enterprise Integration and Process Improvement

there are often difficulties gaining funding for when failures occur. The benefits of leveraging
such efforts. EI for process improvement data collection are
Data warehousing projects tend to tackle that little or no human effort is required to capture
this problem from the management information the information, much larger sample sets can be
perspective. Data warehousing projects usually captured, and more dimensions may be captured
create an additional store that is a normalized and at the same time. The availability of a larger
aggregated subset of the information from many sample set improves the accuracy of statistical
different applications and data stores across the analysis done for process improvement purposes.
organization. The information available through The ability to capture more dimensions provides
data warehouses is normally suitable for manage- process improvement with more flexibility when
ment decision purposes, but is not adequate for defining the metrics to be analyzed.
process improvement. Likewise, information in Having examined some of the common process
a data warehouse is usually updated weekly or improvement problems and identified how EI can
once a day at best, eliminating the possibility be applied to them, the next section will outline
of using a data warehouse for real-time process best practices for applying EI to achieve process
monitoring. More importantly, the information improvement.
captured in data warehouses usually does not
provide the granularity required for process im-
provement analysis. Best Practices for comBining
Carrying on from the call center example Process imProvement anD ei
in the previous section, a process and improve-
ment initiative may want to capture information Whereas the focus of EI is technical, process im-
regarding how long the user was accessing each provement relates more to the world of people and
application, which functions were accessed, how organizations. For this reason, best practices for
long they took to complete, whether the systems combining process improvement and EI include
were always available online, and the patterns of both technical and organizational considerations.
system usage over time. While time and motion Just as the highway traffic planner has budget
studies may help produce this information, they limitations and cannot close thoroughfares to
are time and labor intensive and only provide tear up old roads and rebuild new ones, process
a sample of the true population. In this regard, improvement projects also have funding concerns
there is a risk that a sample may not capture rare and must ensure that progress is made in a way
but costly exception cases. Likewise, time and that is acceptable to all the relevant business
motion studies will be limited as to the number stakeholders. In this section, we will review four
of process variables, or dimensions, that can be best practices (BPs) for combining process im-
monitored and captured concurrently. provement and EI to yield the maximum benefits.
If EI is used to provide connectivity to IT For each of the best practices, we will consider
systems and data stores, the EI layer can also what it encompasses, why it is necessary, how it
be used to filter and reroute information about is implemented, and which organizational factors
events that are important to process improve- should be considered. General guidelines are
ment, such as the start and end times of certain provided on how best to apply these practices,
process steps. When these types of events occur, but the details of how they are implemented will
relevant information can be routed to a process very much depend on the business, technical, and
improvement database or a real-time monitoring organizational environment.
application, enabling processes to be reviewed

Case Study: Enterprise Integration and Process Improvement

BP1: combining top-Down and analysis plan. Bottom-up analysis also identifies
Bottom-up Process analysis tactical process changes that can be implemented
before, or in parallel with, more significant pro-
When applying qualitative techniques to process cess changes.
improvement, the analysis often takes a bottom- One danger of only doing bottom-up analysis
up approach. That is, it focuses on the details, or is that some of the most beneficial changes, such
micro aspects, of an existing process: the indi- as the application of EI, may not be identified.
vidual steps that make up the process. Bottom- Top-down process improvement analysis should
up analysis can help identify logistical changes review how IT systems are used within processes
that can be implemented to achieve quick wins. and how system access could be streamlined using
However, bottom-up analysis may miss higher EI. However, there is the risk that if only a top-
level, more comprehensive changes that could be down approach is used, fundamental limitations,
implemented. These macro changes often have such as the weaknesses of certain IT systems,
a more substantial impact on the overall process may be glossed over. Combining top-down and
performance. bottom-up views helps balance out high-level
Alternatively, qualitative analysis can take visions with low-level realities. Finding a good
a top-down approach. An existing process can balance between the two is critical.
be restructured and rationalized to produce a To apply this best practice, process improve-
fully optimized process with little regard for the ment teams should develop methodologies that
previous implementation. Top-down approaches incorporate both top-down and bottom-up ap-
focus on the macro considerations first, and only proaches. Ideally, different people or teams should
work down to the details in the final stages of perform the analysis from different directions,
analysis. This approach can be useful because and then combine their results and agree on a
it aligns the process structure with the strategic common set of changes that yield the greatest
business objectives, ignoring the tactical details benefits. EI and systems rationalization objectives
of the original process implementation, which should be defined within the top-down process
may no longer be relevant. Top-down analysis improvement analysis methodology. Top-down EI
is also useful for defining reusable, high-level analysis recommendations should then be com-
process abstractions, which bottom-up analysis pared with the bottom-up analysis to verify the
does not usually address. Top-down analysis has feasibility and benefits at the detailed level. The
the disadvantage, though, of not leveraging past process improvement benefits of implementing
lessons learned that have been incorporated into specific EI requirements can then be compared
the details of the existing process. Process steps to the cost so as to determine which are most
that may seem superfluous from a top-down critical and worth doing.
perspective may indeed be necessary for reasons From the organizational perspective, it is
that may be buried in the details. beneficial to include an EI specialist as part of
Combining these approaches enables the the process improvement analysis team. The EI
process improvement to achieve the benefits of specialist may be a permanent member of the team,
both. Top-down process improvement analysis or if there is an EI competency, an EI specialist
identifies major changes and restructuring that can be provided on loan to assist with process
can yield large-scale benefits. In parallel, bot- improvement analysis.
tom-up analysis helps discover any low-level
considerations that conflict with the top-down

Case Study: Enterprise Integration and Process Improvement

BP2: Develop an ei competency termine what existing EI system connectivity is

available and may be potentially reused.
After the process improvement EI requirements Since many EI tools contain workflow facili-
have been identified comes the much larger task ties, it is often the case that simple workflows can
of implementing the EI. Note, however, that per- be easily implemented within the context of EI
forming EI implementation is often outside the without involving a process improvement team.
responsibilities of a process improvement team. Likewise, many BPM tools have built-in facili-
Having a dedicated team for the implementation ties for accessing databases and Web services,
of EI allows specialists to focus on how best to bringing into question the need to make use of
provide access to existing systems and com- a separate EI competency to integrate external
mon services in a reusable form. This division data. These situations can create confusion and
of labor will allow the process improvement contention with regard to the interdependence of
specialists to consider process improvement these two areas. While it is difficult to define hard
without having to worry about the often very and fast rules that will apply equally well in all
complicated and technical details of how the EI situations, looking to the principles of consistency,
will be implemented. simplicity, and reusability will usually provide
There are several benefits to this approach. the best guidance. Involving another group or
While there will be some initial overhead incurred infrastructure platform may not be appropriate
in developing the EI competency and putting an if the integration or workflow effort is justifiably
SOA in place for the first project, the benefits small, does not need to be reused, and can be
will increase over time as additional projects are adequately implemented and supported by the
able to reuse the SOA system connectivity and EI host group. However, it is critical to review these
knowledge that has been amassed over previous situations carefully to ensure that a proliferation
projects. Beyond reusability, an EI competency of ad hoc solutions does not ensue.
will help ensure that EI is applied across all pro- Developing an EI competency is largely an
cess improvement initiatives in a structured and organizational exercise; much of the work relates
orderly way. EI knowledge and experience can be to determining the team structure that best fits
centralized and consolidated rather than having to with the organization’s and the process improve-
rely on the process improvement team members’ ment team’s structure. One approach is to set up a
EI knowledge, which may vary considerably. dedicated EI group, which is sometimes referred
There are several dangers of not developing to as the EI competency center. This approach
an EI competency. First, EI may not be put into facilitates specialization and provides focus, but
practice, even through it would yield significant usually requires that the group be instituted as a
benefits, because the process improvement team cost center that has sufficient funding to operate
does not have sufficient skills to implement the indefinitely. An alternative approach is to create
EI. The EI effort may be deemed too difficult or an EI function within the process improvement
risky. Second, if EI is implemented by process team. This approach has the advantage of directly
improvement initiatives on an ad hoc basis, there linking the EI focus to business-driven initia-
is the possibility of producing “spaghetti” integra- tives (and funding). However, it is important
tion. Loosely planned and managed integration to recognize that EI is usually not a one-time
can become a process hindrance itself, leading to exercise. Infrastructure and interfaces will need
unreliability, poor performance, and difficulties to be maintained over time. Process improvement
with maintenance. Lastly, without a centralized teams may not be organized to provide long-term
team specializing in EI, it can be difficult to de- support and maintenance functions. Hence, a

Case Study: Enterprise Integration and Process Improvement

separate, dedicated EI competency group may BP3: consolidate user interfaces

be a better option.
One challenge for the EI competency is that As discussed previously, eliminating the need for
the timing and volume of process-improvement- users to navigate between different applications
related implementation work can come in waves. and matching screen layouts to process purposes
This creates resource complications as many staff offers major potential for improvements. Provid-
may be required at times to handle peak loads ing a consolidated UI that minimizes the number
of integration work, while there may be periods of applications with which the user must interact
when little EI work is required, especially at the will also reduce the skills required and the train-
start and end of process improvement projects ing time for the process. Furthermore, the rate of
and between them. One solution is to outsource human errors can be reduced by not displaying
the low-level implementation and testing work to unnecessary information, and allowing the user to
ensure that EI implementation does not become a focus on exactly what is required at each step.
bottleneck for the process improvement projects. Besides streamlining data access and entry
However, the EI competency should keep the through a consolidated UI, this facility can also
process improvement EI analysis, API (applica- support data capture for process improvement
tion programming interface) design, and API and MIS purposes. For process improvement,
specification work in house so that this critical, the UI framework can be designed to record
high-level knowledge can be accumulated and when and how many times different screens are
leveraged over time. displayed and how long they are viewed. MIS

Figure 2. Example process execution environment with a consolidated UI and SOA

SOA EI Layer
User Desktop CORBA Core Sys.
Existing
Services
SOAP JMS
Consolidated
User Interface CRM

SNA 0

Common Cust. Info.

Services

JDBC
MIS

0
Case Study: Enterprise Integration and Process Improvement

information can be collected through process- Ideally, infrastructure-related efforts should be

completion screens that prompt the user to record addressed at the departmental or enterprise levels.
more qualitative information, as might be done The consolidated UI infrastructure should be ge-
manually with a tick sheet, about the transaction, neric and applicable to a wide range of business
such as the customer response rate to a recent processes across the organization. With respect
promotion. to funding, it may be most practical to combine
The risk of not consolidating the UI is that some the development of a consolidated UI infrastruc-
of the largest process improvement benefits will ture with multiple process improvement projects.
not be realized. Worse, if the number of desktop Rather than the infrastructure being viewed purely
applications is not decreasing, it may be increasing as a cost center, by combining it with process
and introducing further complexity. Ultimately, improvement opportunities, the development can
there can come a point when business users revolt be justified overall by the efficiency gains and
and refuse to accept new applications even if they cost reduction that is achieved.
are designed to improve efficiency, believing that Designing, implementing, and deploying the
that complexity of introducing a new desktop ap- infrastructure required for a consolidated UI
plication will only make things worse. and SOA requires significant time, effort, and
There are a number of different technologies money. There are many challenges that will be
available that support the implementation of a encountered and that must be overcome. Few
consolidated UI. Thin-client Web interfaces are organizations have the luxury of allocating un-
popular for their cross-platform compatibility and limited resources to a single project or process
minimal desktop support requirements. Thick- improvement initiative. However, it is possible
client Java or native Windows applications, Web to develop this infrastructure over the course of
portals, BPM, and CRM applications are also several projects while achieving tangible business
viable options. The technology chosen to provide benefits in the short and medium term. In BP4,
a consolidated UI will largely depend on the we will discuss how this gradual development
organization’s general business requirements, can be undertaken.
long-term technology focus, previous technology
investments, and expected use of BPM, CRM, or BP4: combine Process improvement
Web portal technology. and ei iteratively and interactively
Aside from the technology chosen, the orga-
nizational considerations will also be substantial. The waterfall project life-cycle model has been
Consolidating the user interface will probably dominant for many years. This model expends
strike a positive chord with many of the business extensive effort on defining requirements,
users, but unfortunately, they may not be suf- analysis, and design with the goal of minimizing
ficiently motivated to invest the time and effort the development and testing work that is done
required to develop a new, fully optimized inter- subsequently. This approach, however, is often
face. The screens layouts do not define themselves, not necessarily ideal for process improvement,
and only the business users can ultimately say and especially not for process improvement that
what will work best. involves EI.
Funding may also be a concern. Replacing mul- Process improvement streamlines activities for
tiple mission-critical application user interfaces people to make them more efficient. Following
can take years to complete, and at a significant the waterfall model, many assumptions may be
cost. Delivering projects of such large scope is made by either the process improvement analysts
often beyond the capacity of an individual team. or the business users about how particular changes

Case Study: Enterprise Integration and Process Improvement

would affect the user experience and improve system being delivered by the end of the project.
efficiency. However, sometimes these assump- This interaction will also help facilitate commu-
tions are not correct. Often, it is only when users nication, get the business users’ buy-in, and foster
try out a new approach can they definitively say ownership. Success with the prototype and further
whether the new implementation is an improve- real-world experience using the pilot system in a
ment, and what additional changes would yield production environment will lay the foundation
even greater benefits. for larger, more comprehensive projects.
Likewise, when process improvement is The risks of not moving forward incrementally
combined with EI, many assumptions are made can be illustrated as follows. The project might
about connectivity to various IT systems. These be going well until, near the end, integration test-
assumptions, as well as documented system ing identifies that the scope or the complexities
behavior that is relied upon for the EI design, of the EI were not fully understood. This added
may be incorrect. With the waterfall model, it is complexity requires redesign and/or rework, caus-
usually near the end of the project, during system ing major delays to the project. Alternatively, the
integration testing, that these faults are discovered. project may be going well, but the lack of visible
As a result, redesign and reimplementation may progress could cause the business sponsors to
be necessary, resulting in significant delays and lose confidence and support for the project over
cost overruns. The waterfall model’s failure to time. Another failure scenario is that the process
detect these problems early enough in the project improvement using EI may be delivered success-
life cycle makes the case for moving toward more fully, but unforeseen operational considerations
agile alternatives. may be discovered during testing or in production
A best practice for combining process im- use that make the process improvements unusable
provement with EI is to start small and gradually as implemented.
build upon experience and success. For the initial When beginning a proof-of-concept project,
delivery, identify the smallest scope that will pro- it is best to “time box” the exercise to facilitate
vide benefits to the process owners and improve scope control. The elapsed time for a proof of
overall understanding of the problem domain. It concept should be between 1 and 3 months.
is critical to set expectations regarding what will First, determine the process improvement and EI
be delivered and what fulfills those expectations; functions that will demonstrate the greatest near-
scope creep can easily undermine the goal of term results and test the most critical technical
producing results and gaining experience quickly. assumptions. Then, once the resource level for
Identifying key challenges and rooting out invalid the project is known, determine which of those
assumptions early in the project life cycle will functions can be delivered within the allocated
enable further efforts to be successful. time frame. It is critical to underscope the initial
Central to this approach is to demonstrate exercise. Expect that the scope will grow of its
functionality early in the project life cycle with own accord and that many things will be more
a proof-of-concept or prototype system to gain difficult than expected, causing delays.
support and to quiet the naysayers. The end users Most importantly, the proof-of-concept project
must be involved with testing the proof-of-concept should produce a system that can be rolled out as
system so that they provide feedback regarding a limited pilot to production users. Use in a pro-
any fundamental weaknesses and/or potential duction environment should clearly demonstrate
improvements. The feedback thus derived will the benefits of both the process improvement and
often require changes to be made to the original the EI. For the EI portion of the project, it is best
plan, but eventually result in a much more useful to perform integration with one of the process’s

Case Study: Enterprise Integration and Process Improvement

core IT systems, but only providing access to a allowed to get in the way of the process improve-
small number of system functions. During the ment gains that can be achieved using an iterative
proof-of-concept implementation, short, suc- approach. For the pilot project, it is necessary to
cessive iterations—2 weeks in length—should create a project team, of internal staff or external
be used to define requirements, implement a consultants, who have experience working this
working model, have users test the model, and way and will make it a success. Then, the experi-
then further refine the requirements. After a few ence and success can be extended to other project
cycles, the users should be able to verify that the areas in the future.
improvements planned for full implementation As a final note, it is important to understand
will provide the intended benefits. Similarly, basic that the iterative approach is not a substitute for
EI connectivity can be exercised and the behavior extended requirements and design efforts, but
of IT system interfaces verified through a series rather is a tool for developing them in a more
of short iterations; performance considerations dynamic manner.
can also be examined.
At the end of the pilot, identify lessons learned
and plan how to factor those considerations into fu- conclusion
ture phases of the project. The challenges encoun-
tered in the pilot phase are unlikely to be unique; For transportation planners, it may be simplest
rather, they are more likely to be representative to add lanes to existing highways and change
of common challenges that will be encountered the speed limits: The addition of connecting
again in the future. Leverage the success of the roads and on-ramps may be ignored because
pilot to perform a second phase project that yields they seem like too much work. Similarly, process
further process improvements and extends the EI. improvement specialists may choose to reduce
While the scope and time frame of this second exceptions and reallocate resources to reduce
phase should be greater, it should not exceed 6 bottlenecks, ignoring improvements that require
months. The second phase provides an opportunity EI. However, in both cases, the result of limiting
to deliver more significant business functionality, the improvement effort could be to forego 80%
and, if possible, develop the initial SOA and con- of the potential gains.
solidated UI frameworks. At the end of the pilot In this chapter, we have highlighted what to
phase or at the beginning of the second phase, expect when going after the gains that are possible
an overall road map of successive project phases by applying EI as part of process improvement.
should be developed. The road map defines the None of the challenges presented are extraordinary
process improvements that will be delivered by or insurmountable, but they are formidable and
each phase and the EI that must be implemented require consideration and planning to overcome.
to support those improvements. The best practices identified will help address
The iterative approach may be unfamiliar to these challenges. These practices may seem com-
some organizations. Many companies have long, monplace, but one or more are often not present
drawn-out project definition and approval cycles in many organizations. While it is best if all four
that do not necessarily fit with a pilot-project of the best practices can be combined, any one of
model. Likewise, business users and technolo- them can stand on its own and provide benefits.
gists may not be comfortable with a more inter-
active, short-delivery-cycle approach. However,
organizational, or personal, biases should not be

Case Study: Enterprise Integration and Process Improvement

references

Harrington, H. J. (1991). Business process im-

provement: The breakthrough strategy for total
quality, productivity, and competitiveness. New
York: McGraw-Hill.
Khan, R. N. (2004). Business process manage-
ment: A practical guide. Tampa, FL: Meghan-
Kiffer Press.
Krafzig, D., Banke, K., & Slama, D. (2005). En-
terprise SOA: Service-oriented architecture best
practices. Upper Saddle River, NJ: Prentice Hall
Professional Technical Reference.
Pande, P. S., Neuman, R. P., & Cavanagh, R. R.
(2000). The six sigma way: How GE, Motorola,
and other top companies are honing their per-
formance. New York: McGraw-Hill.

Chapter XV
Case Study Implementing SOA:
Methodology and Best Practices1

Gokul Seshadri
Architect, TIBCO Software Inc., USA

aBstract

SOA or service-oriented architecture is an innovative approach to enterprise application integration that

increases the benefits of EAI by means of standardizing the application interfaces. This chapter explores
the gradual evolution of SOA through various phases and highlights some of the approaches and best
practices that have evolved out of real-world implementations in regional retail banks. Starting from a
step-by-step approach to embrace SOA, the chapter details some typical challenges that creep up as the
usage of the SOA platform becomes more and more mature. Also, certain tips and techniques that will
help the institutions maximize the benefits of enterprise-wide SOA are discussed.

introDuction be highlighting the approach using a standard

example: A regional financial institution that at-
Service-oriented architecture or simply SOA is tempts to embrace SOA in a methodical manner
seen as the new face of enterprise application in- to realign its IT architecture with the business
tegration (EAI). By covering application-specific vision and goals.
touch points with business-oriented interfaces, International financial institutions have always
SOA is able to provide better design, agility, been plagued with EAI problems. They are one
reusability, and maintenance savings, and has of the earliest breed of business communities to
become the choice for the EAI approach. quickly embrace SOA concepts and theology, and
This chapter details various steps involved hence we chose this example. However, readers
in embracing the technology at an enterprise can quickly relate these examples and situations
level, right from conception to enterprise-wide to any business community or sector they are
implementation. Throughout the chapter, we will associated with.

Figure 1. Point-to-point interfaces for integration

Customer Information
Branch /
Teller Apps Deposits

Other Products / Services

Customer Loans
Relationship
…..

Trade Core Banking

System

aPProaches to integration With more and more applications seeking to

communicate across one another throughout the
Problems with traditional enterprise, the number of point-to-point interfaces
approaches also increased dramatically.
The last decade saw the growth of professional
Traditionally, financial institutions such as banks prepackaged vendor applications meant for spe-
have been part of the earliest business institutions cific lines of business like loans, trade, or trea-
to adopt computerization because of the obvious sury. These boxed applications, once again, had
benefits a mechanical computation machine brings to connect to existing applications and programs
to financial transactions. It is common to find in order to achieve their functionality. The choice
traditional monolithic applications and programs was, once again, point-to-point interfaces.
built using procedural languages like COBOL and Substantial numbers of these point-to-point
C in use in such institutions, even today. interfaces were batch programs, running at the
Since these business applications could not end of the business day or end of the business
function as independent silos, they had to com- week or month. Thus, when Application A up-
municate with each other. One required the data dated a particular customer record, this change
and semantics from another system in order was available to Applications B and C only the
to complete the desired business function. So, next day or next week.
point-to-point communications interfaces were As banks expanded their business horizons
established between the applications. By point-to- into other related areas like selling credit cards
point interface, we mean Application A directly and insurance products, the back-end applica-
hooking onto application B by means of whatever tions and systems also grew in number. With
communication protocol that can be adopted. the internationalization of business, every bank

Case Study Implementing SOA

Figure 2. Communications clutter in a typical retail bank

ATM

Customer Information
Branch /
Teller Apps Deposits

Risk
Managemen Products

Customer Loans
Relationship
…..
Treasury
Trade

Internet
Banking

had to invest in their regions of interest by means the loans and mortgage application failed to get
of acquisitions and opening offshore branches. an immediate real-time update of the deposit the
Needless to say, the net result was more point- customer made just a few minutes ago, it would
to-point interfaces. show an earlier record of the customer that might
If we were to draw a logical representation lead the lending officer to refuse the loan applica-
of all these communications happening across tion of the customer. For the customer, who has
different systems, we would end up with a huge no knowledge of how these back-end applications
communication clutter that is difficult to under- work, it is a frustrating experience because he
stand, comprehend, and manage. has just deposited a large sum and yet the bank
With the growth of real-time computing and is not providing the facility he wants. This results
communication technologies like the Internet, not only in loss of opportunity for the bank (to
batch interfaces were posing another challenge. sell a loan product), but also the threat of losing
When the latest information about a given business a good customer.
entity was not updated in all dependent systems, The challenges discussed above are quite com-
it resulted in a loss of business opportunity, mon to all enterprises and financial institutions.
decreased customer satisfaction, and increasing And almost all of them are looking to adopt some
problems. kind of architectural strategy alighted with their
For example, let us say a customer has depos- business vision to solve these problem areas.
ited $100,000 in his savings account and goes into
the loans and mortgage division of the bank. If

Case Study Implementing SOA

Figure 3. Enterprise messaging

Enterprise Messaging
ATM

Branch / Customer Information

Teller Apps
Deposits
Risk
Managemen Products

Customer Loans
Relationship
…..
Treasury
Trade

Internet
Banking

technical solutions to applications a common messaging protocol. This would

integration mean that when Applications C and D join the
bandwagon and are capable of talking the same
Technology companies around the world have protocol, then they could easily connect to Ap-
been coming out with various solutions to address plications A and B that are already exposed to
the problem of point-to-point communications the common protocol.
and application integration issues. The first and immediate problem with enter-
One of the first solutions to appear on the prise messaging were questions like, “What if
horizon was enterprise messaging. Application A or B was not capable of talking in
Messaging protocols are built on top of basic the enterprise messaging protocol?” Or, “What
transport protocols, and they offer better fea- can be done in order to make Application A or B
tures and flexibility. HTTP (hypertext transfer speak the common messaging lingo?”
protocol), TCP (transmission-control protocol), There were two solutions to this.
and UDP are examples of basic transport proto-
cols. IBM MQ Series® and TIBCO EMS® are • One was to enhance the existing application
examples of messaging protocols built on top of in one way or another so that it can commu-
basic transports. nicate in the common enterprise messaging
Messaging protocols advocated standardiza- lingo.
tion in the way applications talked to one another. • Another was to build a piece of software
For example, when Application A wants to talk that would stand as a bidirectional translator,
to Application B, both applications had to use speaking in the preferred communication

Case Study Implementing SOA

protocol of various applications on one end may expect data as a delimited string. So, when
and the common enterprise lingo on the other data was sent from Application A to B, the fixed
end. These eventually came to be known as strings had to be converted to delimited strings
application integration adapters. and vice versa.
The other problem was business and logical
Many enterprises accepted and started adopt- transformation. For example, in Application A,
ing this solution and to date it is very much in the key to identify a customer could be a 15-digit
prevalence. The need for application integration customer numeric code, whereas Application B
adapters became an opportunity for software ven- might expect an alphanumeric string. Thus, when
dors to prebuild third-party adapters for standard a customer update was sent from A to B, key in-
business applications. For example, TIBCO has formation had to be carefully managed in order to
adapters for more than 100 such standard enter- make the update successful. Such transformations
prise applications like Siebel, Peoplesoft, SAP, are called logical transformations.
Oracle Financials, J. D. Edwards, and so forth. Initially, these transformations had to be hosted
However, messaging could not solve all within the application integration adapters. But
problems. Enabling connectivity did not mean as the complexity of these transformations grew,
that Application A could talk to Application B a dedicated engine to design and host transfor-
straightaway. There was the data transformation mations came into being. Messaging became an
and formatting issue. For example, Application integral part of this engine.
A may impose that all its input and output data So far all solutions had been purely technical
be fixed format strings, whereas Application B solutions. Architecture was built around tech-

Figure 4. Semantic data transformation example

Data: , , A.LEE, ,A Enterprise Messaging

Comma delimited data format (above) is

changed to Fixed length format (below) Customer Information
when data passes from Core Banking to
Customer relationship. This is an example
semantic Transformation Deposits
Data: A.LEE
Products

Customer Loans
Relationship
…..

Case Study Implementing SOA

Figure 5. Role of transformation engine

Transformation Engine
ATM

Branch / Customer Information

Teller Apps
Deposits
Risk
Managemen Products

Customer Loans
Relationship
…..
Treasury
Trade

Internet
Banking

nologies advocated. At this stage, the inception soa: concePtual

of a new technology called Web services created unDerstanDing
a big impact on the traditional thought process
that would change the landscape of applications SOA is not a technology. It is an architectural ap-
integration forever. proach built around existing technologies. SOA
Web services advocated a standard XML (ex- advocates a set of practices, disciplines, designs,
tensible markup language) communication model and guidelines that can be applied using one or
and a simple HTTP transport. The simple object more technologies.
access protocol (SOAP) was a set of specifications SOA encourages developing services around
that advocated a standard XML structure for all existing business functions offered by an applica-
communications and standard methodology for tion. Other applications that want communication
binding transports. HTTP is the only ratified with this application would make use of one or
transport in the Web services world to date. more services to accomplish the desired busi-
While Web services in itself was looking like ness task.
another technical solution, IT architects around
the world captured a nice concept that was looking Service-oriented architecture is all about build-
beneficial beyond technology and specifications. ing standard interfaces to access different busi-
This was the concept of SOA. ness functions that are exposed by various core
We will pause for a moment and understand business backend systems. These functions could
what SOA is all about before proceeding fur- essentially be those that are frequently invoked
ther.

0
Case Study Implementing SOA

Figure 6. Bill-pay service example

SOA Platform
ATM

Branch / Customer Information

Teller Apps
Deposits

Products

Call Loans
“Pay Bill”
Service Pay
Bill Bill Payment System
Service

Internet
Banking

by other business systems within the enterprise • The date and time of payment
ecosystem. • The payment amount

When these standard interfaces are built for This function outputs the following param-
enterprise-wide usage and are used by many eters.
different backend and client applications span-
ning a wide variety of business and functional • The status of payment (success, failure, or
boundaries—we term such an implementation pending)
as Enterprise SOA. • The payment transaction’s reference num-
ber
For example, let us say Application A is a bill-
payment system. Applications B, C, and D need to For this situation, SOA advocates that Applica-
invoke a particular business function called pay tion A should build a service called the bill-pay
bill. This business function expects the following service and make it available to all applications.
input parameters. This service would consist of the following
parts.
• The bill’s customer reference number
• The service provider or the company whose • A definition of the exact input and output
bill is being paid data formats, preferably in the form of XML
• The account number of the customer from schemas, with details like mandatory and
which the amount needs to be debited optional data elements

Case Study Implementing SOA

Figure 7. SOA implementation cycle from conception to reality

Enterprise Conceives SOA Pilot “Selling” SOA to Initial Services / SOA

SOA potential projects Governance

1 2 3 4 5 6 7 8 BAU

Tools, Vendor ROI / Business paper Forming SCC / SOA Growth of Services /
Selection, POC presentation to Architecture Blueprint Maintenance / Reusability
Management Engagement Accountability and Growth

SOA Growth Cycle : In – years SOA reaches BAU Mode

• A definition of the transport protocol(s) by The definitive milestones commonly observed

the means of which this service could be in this journey are as follows.
invoked
• A service implementation, which is a piece • The enterprise conceives SOA as a defini-
of software that would accept the incom- tive strategy: This is where all the high-level
ing XML, invoke the necessary back-end talks about SOA begin in all enthusiasm and
application function on behalf of the caller, earnestness. The enterprise usually formu-
get back the response, format the response lates a task force constituting members from
in the service data format, and send it back various related departments to do enquiries
to the calling client about SOA implementation and select pos-
sible approaches and benefits. The SOA task
In short, this service will be an abstract repre- force begins to understand all the nuances
sentation of a given business function offered by of SOA from various books, vendors, and
Application A without implementation details analyst reports. This phase is characterized
of how this function is being executed. It is the by steep learning with few of the bank’s staff
responsibility of Application Clients B, C, and D emerging as champions in the race. These
to provide the necessary data inputs and receive champions eventually pioneer the rest of the
back the response. journey in SOA implementation.
• Tools, vendor selection, POC, and so forth:
sequential steps in approaching The SOA task force starts talking to various
enterprise soa known and unknown vendors about tools
and methodologies for SOA implementa-
An enterprise goes through various steps as it tion. Naturally, the preference usually goes
embraces SOA as the strategy for doing applica- to vendors with whom the enterprise has
tion integration.

Case Study Implementing SOA

already been dealing with, but a careful small portion of existing needs is made use
analysis of known market leaders is advised of to test the tools. The chosen pilot should
and it is best to keep personal preferences provide enough room to test the waters of
aside and take a pragmatic look at who is SOA like the speed of development, reus-
leading the pack in terms of integration and ability, business agility, and so forth. To
implementation methodologies. This phase the SOA vendor, it is a golden opportunity
is challenging as it is marked by considerable to highlight the strengths of the product
confusion caused by various vendors and and tools, and to showcase its professional
their interpretations about SOA. SOA, being services know-how. At the end of pilot, the
an architectural concept, is flexible enough task force should be in a position to decide
to lend itself to multiple definitions. Hence, whether SOA as well as the tools chosen for
it is the responsibility of the enterprise’s task SOA can work for enterprise-scale imple-
force to remain sane and look for things that mentations.
are fundamental to SOA success. One of the • Return on investments and business pa-
best methodologies to evaluate tools and per presentation to management: Once
vendor offerings is to have a POC solving convinced about the pilot project and taking
one of the organization’s problems. This measurable outputs from project experience,
approach helps the vendors to showcase the task force begins to prepare a busi-
their strengths against real-life issues and ness paper that puts forth the formal SOA
helps the task force to see the weaknesses proposal for management’s approval. This
of the tools instead of solely depending on is a complicated exercise as the task force
PowerPoint presentation data. More often needs to consider all the different aspects
than not, most enterprises face surprises of enterprise SOA implementation. A rock-
when it comes to POC: Their initial concep- solid understanding of current architecture,
tions, ideas, and thoughts on various tools transformed architecture (or the end goal),
and vendors usually undergo revisions. and various steps in achieving the desired
• SOA pilot or initial project(s) for SOA: At architecture should be spelt out clearly.
the end of the vendor evaluation, the task The overall budget of the enterprise-scale
force should be able to identify the vendor implementation in terms of hardware, soft-
with whom the enterprise wishes to part- ware licensing, professional services from
ner with. Having been convinced with the vendors, effort, and manpower required from
POC, now the task force is to host a small the enterprise are all worked out in detail,
environment within the enterprise itself and and a maximum budget is projected. It is
do a sort of small-scale SOA implementa- very important to project a correct figure and
tion so that it becomes a benchmark, and set the expectations right with the manage-
so the implementation can be showcased ment in the first place. The ROI graph to be
to convince other people within the enter- submitted along with the proposal should
prise. The chosen pilot project should be a be able to project how long it will take for
part of a business-critical, high-visibility the enterprise to realize the amount that is
project, but at the same time, it is best not being invested.
to complicate or burden the pilot with too • Selling SOA to potential project owners
many activities. In some organizations, a (or developing the SOA pipeline): As
full-blown enterprise project is set aside to enterprise SOA is approaching the stage of
try the SOA tools, whereas in others, only a becoming a reality, it is important for the

Case Study Implementing SOA

task force to develop a healthy pipeline of constituted within the enterprise, with fully
projects for which SOA can be made use of. dedicated and partially dedicated members,
It might require that the task force needs to that develops, owns, and maintains services
do some sort of internal marketing campaign on an enterprise scale. This body should have
within the enterprise to convince the project a head who directly reports to top manage-
owners to make use of incoming SOA for ment. It should have developers, architects,
their projects. With management’s approval, technologists with in-depth know-how of
it is best to make it absolutely mandatory enterprise internal systems, administrators,
for all new projects to make use of the new and infrastructure people. As far as possible,
SOA platform: Point-to-point connections all task force members should eventually be
or other proprietary means of connectivity integrated into SCC. The formation of the
requirements should not be encouraged un- SCC, its role, and its constitution are broad
less there are extraordinary situations. It is topics and are beyond the scope of current
natural to expect a lot of doubts, misunder- discussions.
standings, and other complications on the • SOA architecture blueprint engagement:
part of various project owners about SOA; The task force engages with the vendor’s
already, they have a host of risks to address, professional services team to deliver what
and SOA adds new doubts and risks on the is called an enterprise SOA blueprint. It
overall project, in their perception. It is the constitutes various architectural deliverables
duty of the task force to engage with them in like infrastructure design, services design,
a series of discussions so that these doubts load balancing and scaling, fail over and
are mitigated right in the initial stages. The fault tolerance, services monitoring, SLA
idea is to convince them about the overall measurement and management, and so on. It
enterprise scope of SOA, why it is better than is this engagement that lays down the overall
the current approach, and how management architecture for the entire SOA platform over
wants all projects to adopt this methodology. which services will be designed, hosted,
These risks are usually perceived to be very and maintained. It is critical to ensure all
high on the initial set of projects that will be party participation in this architecture ex-
using SOA, hence it will be good on the part ercise as it has a long-standing implication
of the task force to provide some form of on the overall success of SOA within the
incentives or concessions to the initial set of enterprise
projects (maximum of two) that decide to use • SOA governance: Along with the SOA ar-
SOA. This incentive can usually be charge- chitecture, the task force also needs to come
free development of the first 20 services or out with a set of guidelines that will govern
something similar to that. The overall idea the development, usage, and eventual retire-
is to provide a comforting feeling to those ment of various services. SOA spans across
with incoming projects so that they do not the enterprise and each service could have a
feel they are scapegoats and the favors are host of stakeholders. Hence, it is important
one sided: The task force may achieve this to lay down a set of guidelines and principles
by any means it deems fit. that will govern what should be done and
• SCC formation: Once the management ap- when. SOA governance includes topics
proval is obtained, the task force sets forth such as services life cycle management,
to form what is called an SOA competency stakeholders of SOA and their responsibili-
centre, or SCC for short. The SCC is a body ties, guidelines for project owners who use

Case Study Implementing SOA

SOA, service-level agreements (SLAs), and enters BAU, or business-as-usual mode, in

so forth. Strong SOA governance prevents 3 to 5 years time. Entering this mode signi-
misunderstandings across various teams in fies that SOA is already a part and parcel
the future and sets the expectations right of the overall enterprise IT architecture and
across various stakeholders. does not need to be treated as a strategic
• Delivery of services for initial project: The project anymore. Businesses already know
SCC starts working on developing services that they need to set aside a portion of their
for the initial set of projects. It is imperative project budgets for services development.
that all service designs confirm to certain A strong SOA platform provides room for
predefined standards and guidelines so that the enterprise to think more about process
all services share certain common grammar modeling, business process management
and theology. The SCC should be careful to (BPM), and complex events management.
bestow enough attention to various details
like how the new systems are going to con-
nect to SOA, what protocols they will use, soa imPlementation:
what will the XML format will be that they technical Best Practices
will use to connect, and so on.
• Reusability, accountability, and mainte- In the light of the topic under discussion, let us
nance: Ongoing activities include providing discuss certain recommendations, strategies,
a services catalogue for the entire enterprise guidelines, and best practices that have emerged
to find what services have been hosted, out of real-world implementation experience.
what can be reused, and so forth. Every
new requirement has to go through the SCC role of enterprise service
to ensure sufficient reusability. For each Specifications
service, there should be a developer and a
lead who should be made accountable for SOA defines a service specification for each
whatever services that are delivered. It is not service that details the data elements that are
possible to avoid perennial change requests expected as request input parameters and what
to existing services, and this should be care- will be provided as the request output. SOA best
fully managed because different projects practices indicate that this request and response
are using the same service. It is best to go structure should be inspired by the business func-
through some sort of version control for tion and business data models involved rather than
each service, and the services governance the specifics of the application that is offering
should dictate how many versions of a given the service.
service will be maintained, depreciated, and Coming back to the earlier example of the
eventually retired. bill-pay service, we discussed the XML request
• Achieving BAU mode: The eventual success and response formats that need to be defined
of SOA depends on the increased usage of so that calling clients can communicate with
the new platform for all integration needs the service. SOA best practice advocates that
within the enterprise. More services and these input parameters should not be influenced
more reusability help to bring down the just by the input and output parameters defined
overall cost of integration. With the right by Application A. A bigger level view of what
strategies and support, the SOA platform would be required for such a bill-pay service in
becomes well-integrated within the bank and the bank should be considered in designing the

Case Study Implementing SOA

service. This ensures that what is required by • It is best to adopt standardization while al-
the business is duly incorporated into the service locating name spaces to XML entities. Name
specs rather than being led by the specifics of a spaces are to XML entities what addresses
vendor application. For example, let us say the are to humans: They define a hierarchy in
bank’s practice advocates providing a seven-digit which the XML elements attach themselves.
requestor transaction reference for each financial The top-level name space could be something
transaction in the bank. Application A, which is like http://schemas.<enterprise-name>.com
providing the bill-pay service, does not require followed by other directory structures that
this parameter, but the service specs will incor- need to be adhered to.
porate the requestor transaction reference. This • Like the business requirements, enterprise
would ensure that if, at a later date, Application service specifications also do not remain
A is replaced by another application, H, then stagnant. As the requirements change, so do
the overall business functionality of the service the specifications. Hence, it is important to
remains unaffected and the clients can remain version-control various schemas and speci-
transparent about this change of application. fications. A particular service can support
Taking this a bit further, it will be realized that one version of schema and so on.
the enterprise data models that define the structure • It is best to maintain some form of XML
and entity relationships of various data elements of repository wherein all schemas can be
the bank should be duly considered while drafting hosted, uploaded, downloaded, and version-
the service specifications and contracts. In order controlled.
to achieve this effectively, it is best to involve the
expertise of the data management team within support for multiple Protocols and
the bank. It is a good practice to have one or two Data formats
representatives from the data management team
to be involved right from the start of designing Not all systems within the enterprise can be
enterprise service specifications. expected to support XML data formats or Web
The enterprise service specifications define service calls over HTTP. The SOA platform
the service contract between the service clients should be flexible enough to support clients with
and the SOA. It usually takes the form of XML fixed, delimited, and other kinds of data formats,
requests and responses, with standard headers and allow services to be accessed via different
and varying body parts. protocols.
The following points are noteworthy:
• The services should at least support the
• The enterprise service specification should following messaging or transport protocols:
not be confined by immediate project re- JMS (Java message service), HTTP(S), TCP/
quirements at hand. The enterprise data IP (Internet protocol), and MQ. Depending
models should help to understand the upon the specific enterprise architecture,
anatomy of underlying business entities. other protocols may be added or taken away
The specification represents an abstraction depending upon the requirements.
of the underlying business function: It is • It should be well-remembered that all these
important that this definition is well-under- different protocols have varying method-
stood by those involved in writing out the ologies for load balancing and scaling. The
specifications. service design should adequately take this
into consideration.

Case Study Implementing SOA

• In terms of supporting fixed, delimited, and currently running processes. One of the
other non-XML forms of data, the normal best methodologies to implement this is to
methodology is to have a layer that will do attach a version number to a service or a
the semantic transformation between the schema. As long as a given client is using a
non-XML and XML formats. This, however, service at a given version (which is already
incurs additional overheads. live), it should not be disturbed with future
changes unless the service is going to retire.
ensuring reuse across multiple Newer versions of the service could be used
applications and Projects by newer clients, but to existing clients this
should be transparent.
Services are originally conceived for specific • It is good to adopt a standard life cycle
projects and on top of specific applications. In policy for services. Just like any other IT
order to ensure that these services are reusable for asset, services also go through a cycle of
other projects in the long run, there are a number inception, growth, decay, and retirement. For
of disciplines that need to be enforced. example, when a newer and more efficient
version of a service is in place, the old service
• The first and foremost discipline is to not may no longer be attractive or useful. The
let the service design on enterprise service current users of the old service have to be
specification be led too much by the scope of given suitable time to migrate to the newer
immediate project needs. Thought processes version, and then the old service can retire.
should stand outside what is immediately ap- Evolving enterprise-wide policies for service
parent at the time of development. It is good life cycle management is beneficial.
to consult other existing (or potential) users
of the same service or business function. handling varying load conditions
• The other challenge is to align the enterprise for Different services
specifications closer to the core business
function offered by a given application rather SOA services are meant for enterprise-wide usage.
than to the semantics of the application itself. Service ABC could be used by Applications A
This would ensure reuse of services, even and B in the beginning, but over the passage of
if the boxed Application A is replaced by time, Applications C, D, and E might also start
another boxed Application B that offers a using the same service ABC. When Service ABC
similar function. was originally designed, let us assume that it was
• It is equally important to build enough flex- designed to handle five transactions a second at
ibility within the service itself so that it is its peak load. Now, however, with Applications C,
able to accommodate growing changes so D, and E also using the same service, the overall
its reusability increases. With every other throughput of the service has come down to two
change in schemas and specifications, it transactions per second because of the increase in
is not possible to deploy one more version load. Hence, Service ABC needs more muscles or
or instance of the service. That would be more process to achieve the original throughput
too expensive. Instead, service designers desired.
should build enough flexibility and adopt- More muscle does not necessarily mean more
ability within the core structure itself so hardware. The overall capacity of the machine
that changes to a given service can be added may still be sufficient, but Service ABC needs
on a continual basis without affecting the additional processes or handlers to handle the
increase in load.

Case Study Implementing SOA

Couple this with another scenario. When the • Monitor the service log files for any errors
fate of Service ABC is detailed as above, Service that might have happened. If such error
DEF is facing a different kind of problem. It was does occur, send an alert based on severity
originally designed to handle 20 transactions per levels.
second at its peak load, but in 2 years, it has been
observed that the peak load has not crossed four On top of this, SOA requires sophisticated
transactions per second. Hence, the processes monitoring covering the following aspects.
that have been attached to Service DEF need to
be scaled down so that the machine resources can • What is the service level of a given service
be saved and used elsewhere. instance in the last 1 hour? If it is not within
It is interesting to note that both of these the SLA, how many requests have gone past
services have been deployed in the same engine beyond the agreed service time? If more
run time. Adding hardware to this run time will than N number of calls has suffered from
result in the linear scaling of resources, whereas delayed response, then it might mean that
what is desired is a unit-level (service-level) scal- the service is experiencing load problems
ing manipulation. with insufficient resources for handling the
The right solution to the above problem would load.
be to have more than one process handler per • What is the correlation between the overall
service, and increase or decrease the process resource (CPU, memory, etc.) usage on the
handlers with the changes in requirements. machine, resources consumed by a given ser-
vice, and the jobs that were being completed
services monitoring using those resources? For example, when
a given service was consuming significant
The term monitoring usually represents a mecha- resources at some point in time, what was
nism that continuously monitors something it really doing? It is because of a higher
against certain fixed rules and reports the outcome number of requests that had hit the service
by means of alerts. For example, a monitoring at that point in time? Is it due to some kind
rule could say, “Please alert me when the CPU of housekeeping activity? Or is there any
(central processing unit) usage of the machine is problem within the software (memory leak,
above 95% for more than 5 minutes.” Another rule etc.) resulting in this problem?
could be, “Please alert me when the disk usage • Historically analyze overall service usage in,
has crossed 80%.” say, the last 6 months. How many services
Traditionally, monitoring tools have been have experienced peak load and for what
focusing heavily on hardware. With newer tech- amount of time? Are the current hardware
nologies like SOA and BPM offering newer per- resources sufficient enough to cater for
spectives into the IT infrastructure, newer breeds immediate projects or is new hardware
of monitoring tools have also come to play. required?
In SOA, the basic service monitoring should
cover the following aspects. SOA offers a unique perspective into busi-
ness that was previously unavailable: It offers a
• Is the service and supporting components real-time view of what is happening in terms of
up and running? If not, start them. If there transactions, usage, and so forth. This knowl-
are any troubles in starting, please send an edge can be capitalized by business to increase
alert. customer loyalty, identify newer opportunities,

Case Study Implementing SOA

and grow the business. The CEO (chief executive service-level agreements
officer) of the bank may want to know what is
happening today—right now—in the business, In the SOA world, the term SLA represents the
how the KPIs (key performance indicators) are agreement between the SCC, and service con-
doing, and so on. sumers and providers in terms of the availability,
This has emerged into a new area in comput- load handling capacity, and scalability of a given
ing and is called business activities monitoring. service.
A few examples of this application are provided A given service could be used by different
below. projects within the enterprise. Thus, the total load
on the service per day will be a cumulative sum
• An unusual trend is noticed in the pattern of all the individual loads imposed by the clients.
of withdrawal from a given customer’s ac- The SLA defines the requirements of the client
count. $1,000 has been withdrawn every in terms of overall turnaround time expected
day for the last 3 days, and this does not and total volume of transactions that can be ex-
match the existing usage pattern of the pected to be handled per day. The client should
customer. The system suspects some kind also project the overall increase in load expected
of fraud (ATM [automated teller machine] (if any) in the next 3 to 5 years. The SCC takes
card stolen, Internet password hijacked, these inputs while designing a given service and
etc.), alerts the customer, and suspends the evaluates whether the current infrastructure and
account temporarily. handlers are sufficient to handle the expected
• A new marketing campaign has been load. If not, the infrastructure or the number of
launched on the Internet that displays a new handlers for a given service needs to be scaled
banner after the customer has logged in. It up sufficiently.
is noticed that a given customer is spending The SOA platform depends on back-end
more time on the page than he or she normally systems to meet the SLA requirements. When a
does after logging in. The system suspects certain turnaround time is expected by the cli-
that the customer is reading the promo in ent, the SCC should evaluate what is the nominal
detail. A window pops up and says, “Are time that will be consumed by the back end and
you interested in this product? We have a add sufficient buffer for the time to be spent in
special promotion for the first 100 customers SOA. Normally, the time spent in SOA should be
and you could be one among them.” around 5% and not more than 10% of the overall
• The business lead of collateral and loans turnaround time.
of the Bank notices a trend from the past The SOA platform’s monitoring tools should
2-year history: There is a sharp rise in the help the SCC to ensure that all the promised SLAs
number of customers who are applying for are met. The monitoring infrastructure should
short-term loans at a given period in a year. continuously monitor the overall turnaround time
He suspects that there is some social reason taken by a given service and compare it with the
behind this trend and decides to introduce normal or average turnaround time. If abnormal
a new and innovative loan product during delays are encountered on a continual basis, then
the same period this year. The response it means some investigation is necessary. The
received from the customers for this new monitoring tools normally raise alerts in case
loan product is compared with the previous such exceptions happen, and interested parties
year’s data, and the current product is fine- can subscribe to these alerts by means of e-mail,
tuned to become a success.

Case Study Implementing SOA

pager, and so forth so that they can be aware of Unless there are exceptional reasons, no proj-
what is going on in the SOA platform. ect would be allowed to make independent
connections to various applications: They
have to go through the SOA platform and
soa imPlementation: need to adhere to the standards and practices
organizational Best it advocates.
Practices • The SCC team should proactively meet the
project leads of incoming projects, dispel
The following sections highlight organizational myths and assumptions if any, and ensure
best practices that have emerged out of successful that the new project leads are comfortable
SOA implementation stories. using SOA for their integration needs.

ensuring Widespread adoption of services Development: reusability

soa Drives the show

An initiative as big as SOA cannot be a success if One of the biggest promises of SOA is the re-
it is not understood and used by various business usability of services across multiple business
applications and projects across the enterprise. applications. It is one of the key drivers that
In big enterprises, it is common to find business will help the enterprise get proper return on its
and IT teams that are blissfully unaware of the investments and help to reduce the budgets of
existence of such a common infrastructure. individual projects.
The following measures are recommended to For example, let us say the bill-pay service
ensure a high degree of SOA platform usage. discussed earlier is initially built on top of Ap-
plication A for Project 1. Later on when Projects
• The key is communication. Communicat- 2 and 3, involving Applications B, C, and D,
ing the existence and relevance of SOA eventually need the same business function from
and ensuring that the knowledge of SOA is Application A, they can leverage on the existing
well-understood and used by independent service and reuse the same one possibly without
project teams would be a key to ensure any changes. This would mean significant sav-
the successful adoption of the scheme. ings for the bank. As more and more services are
Seminars, technology update sessions, and built on top of the existing Application A, the
other relevant means should be adopted on bank would eventually reach a stage where most
a continual basis to ensure that all the key if not all integration requirements are met with
stakeholders of IT are aware of SOA as existing services. This would drastically reduce
well as the immediate services that are in the money spent on application integration. With
development. more reuse, the amount spent to maintain a given
• Some enterprises have adopted the approach service would also drive down.
of putting an integration IT project council in The following points are noteworthy with
place. The task of the project council, which respect to reusability.
mainly consists of members from the archi-
tecture and engineering team of the bank, • During the service request evaluation pro-
is to review the integration requirements of cess, the SCC should evaluate the eventual
the immediate projects in the pipeline and benefit of building services for a given proj-
recommend the usage of relevant services. ect in the long term. Let us say Projects 1

0
Case Study Implementing SOA

and 2 are requesting 10 services each to be resemble production. Only UAT and production
built for their use. Let us assume the SCC will have hardware fail-over capabilities, and
has the budget for only one project. Now it only the SIT platform will have a connectivity
is the responsibility of the SCC to evaluate option with back-end host systems while the de-
what the level of reusability is between velopment platform will remain as a unit testing
these two projects if services were built. environment.
If more applications within the enterprise It is the responsibility of the operations centre
are expected to use the services of Project to ensure that the hardware and software required
2, then it should be given precedence over for various projects in the restructuring exercise
Project 1 requirements. are kept in tact. As various modules of a given
• It will be noticed that at least a few services project migrate from one environment to another,
of a given project are not highly reusable. the operations centre would promote the piece of
In the same example cited earlier, let us say code after suitable testing.
out of 10 services, 8 are reusable and 2 are The overall capacity of the hardware that
very specific to this project. It is the duty constitutes the new platform would be reviewed
of the SCC to agree to build all 10 services from time to time, and additional hardware would
because, just for the sake of 2 services, be added when necessary.
Project 2 cannot be allowed to establish
point-to-point or other proprietary means soa competency centre
of communications.
• Services would be developed against specific It is recommended that the task of developing,
project requirements. For example, among deploying, and maintaining services for various
the 100 business functions offered by Ap- project requirements be allotted to a dedicated
plication A, if only 10 are required for Project SOA competency centre, which will be a new
2, then only 10 services will be built. This constitution in the enterprise. This competency
would ensure that for every service that is centre could initially be funded as a strategic
being built and deployed into production, initiative until it reaches a stage where it can be
there will at least be one client. Later on, purely funded from project costs. In each project
if more functions are demanded by other that makes use of SOA, a budget needs to be al-
projects, more services would be developed located for services.
and deployed. The centre should be headed by a vice presi-
dent. There should be three to four SOA architects,
managing soa infrastructure a few project leads, and a bunch of developers
on the team. While initial projects can be devel-
Usually, a new hardware infrastructure is neces- oped by vendors themselves, the centre should
sary to host the SOA platform and its associated slowly take ownership of services in a gradual
tools. To support this new infrastructure, a dedi- manner.
cated team of system management people will
be required. We will call this the SOA operation Geographic Expansion of SOA Platform
centre in our discussions.
The operation centre needs to support at least If the enterprise is a regional or global entity with
four different flavors of environment: develop- major presence in more than one region, then it is
ment, SIT, UAT, and production. Disaster recovery natural to expect some form of regional expan-
could be added if required. UAT will closely sion of the SOA platform. There will always be

Case Study Implementing SOA

perennial expansions and increases in the scope of of by the nearest SOA infrastructure. Such SOA
applications in newer countries and regions. This infrastructures are usually called SOA hubs.
means that the SOA integration infrastructure has One more measure that can be put in place is to
to cater beyond local requirements. have one common development environment to be
Three major strategies are adopted to cater shared across multiple regions. This would mean
this need. that the enterprise needs to put up only the produc-
tion SOA infrastructure in various regions and
• The lowest common denominator is to put control the development activities from a single
up an SOA infrastructure that is similar to hub. There are pros and cons to this approach:
the current one in other regions. The obvious advantages are in terms of cost sav-
• Having a common SOA platform to service ings and the ease of maintaining one competency
multiple service clients and providers in centre, but certain problems can be anticipated
different regions in terms of supporting multiple infrastructures.
• Having different infrastructures in differ- A nicer balance would be to maintain a skeletal
ent regions, but establishing some form of SCC (of much smaller scale) in each region where
communication gateway between them and an SOA hub has been established and maintain
designing services that can talk to various the core SCC in the main region where the SOA
service providers in different regions initiatives are being pioneered.

It would be too expensive to put a dedicated enDnote

infrastructure in every other region where the
enterprise has a market. Rather, a careful evalu- 1
The content represents the views of the au-
ation of select regions where the customer base thor and not necessarily the views of TIBCO
is significant would give way to fewer platforms. Software Inc.
When the customer base in a given region is
small, the integration needs can be taken care

Chapter XVI
Application Integration:
Pilot Project to Implement a Financial
Portfolio System in a Korean Bank1

So-Jung Lee
JLee Consulting, Singapore

Wing Lam
U21 Global, Singapore

aBstract

This case describes a pilot project to implement a financial portfolio system (FPS) within Jwon Bank.
(The case is based on a real-life organisation, although the identity of the organisation has been dis-
guised at the organisation’s request.) A strategic IT review of Jwon Bank’s IT systems and architecture
revealed that a lack of integration between IT systems was hampering the bank’s capability to meet its
business vision. A key recommendation from the review was the development of an FPS that would enable
customers to manage all their financial assets and access financial services from a single place. How-
ever, creating an FPS meant that Jwon Bank had to develop a strategic solution to meet the integration
needs across the entire bank. Jwon Bank examined enterprise application integration (EAI) tools, and
embarked on a pilot project to develop a prototype FPS and test the robustness of an EAI solution. The
case highlights some of the management issues relating to integration projects of this nature, including
strategic planning for integration, EAI tool selection and evaluation, and understanding of business
process flow across divisional silos.

organisational BackgrounD that Jwon Bank would significantly diversify its

portfolio of financial services, enabling consumers
Jwon Bank is one of the fastest growing providers to meet their entire financial needs, from invest-
of financial services to consumers in South Korea. ments to insurance, through Jwon Bank. The CEO
Out of all the banks in Korea, it is recognized as believed that being able to provide customers
one of the most innovative and progressive. For with a holistic set of interlinked financial services
example, it was one of the first banks to offer In- would give Jwon Bank a significant competitive
ternet banking and mobile banking services. The advantage in the industry.
swiftness with which Jwon Bank has embraced
technology to differentiate itself is acknowledged
by industry analysts as one of the primary reasons setting the stage
for the significant increase in its customer base,
which has grown by 15% in the last 5 years to jwon Bank’s it architecture
about 5 million. The majority of Jwon Bank’s new
customers are young adults in the 20- to 30-year- Jwon Bank’s IT architecture is divided into
old age group, precisely those who are most likely separate clusters of IT systems that are owned by
to adopt Internet and mobile banking services. In individual business units (e.g., current accounts,
addition, Jwon Bank has been running a series of investments, mortgages, trading, and insurance)
successful marketing campaigns that has given it and support the specific business needs of that
a refreshingly youthful and vibrant image, unlike business unit. Each cluster has between 5 to 20
the conservative images associated with many of IT systems. For example, there are a total of 14 IT
the other Korean banks. systems in the credit-card cluster that collectively
Jwon Bank’s competitive strategy is three-fold. handle the management and processing of credit
First is to offer innovative financial services before cards for the credit-cards business unit. In total,
its competitors. The introduction of new global Jwon Bank has over 120 IT systems across all the
trading services is one example of this. Second different clusters.
is to use technology to deliver financial services Like many large organisations, Jwon Bank’s
in flexible ways. The investment the bank made IT architecture has evolved over a long period
in new IT systems during the period of 2000 to of time to include a diverse mix of IT systems
2002 is estimated at between $80 to 100 million. running on different platforms and employing
Furthermore, with the high IT literacy rates in diverse technologies. For example, many of the
Korea, the bank predicts that, within 5 years IT systems in the current accounts cluster are
time, 80% of its customers will be conducting the legacy systems based on older, mainframe tech-
majority of their banking through the Internet. nology such as CICS and MVS. Many of the IT
Third is to provide exceptional standards of cus- systems in the trading cluster are bespoke C++
tomer service to attract new customers and retain applications running on the UNIX platform that
existing ones. A major service-quality initiative have been custom built for Jwon Bank. On the
was recently launched by the vice president (VP) other hand, the IT systems in the Internet-banking
of customer services to monitor levels of service cluster are customized versions of packaged com-
quality across the entire bank. mercial off-the-shelf (COTS) systems running on
At the bank’s 2003 annual conference, the CEO the Windows platform. In addition, the IT system
(chief executive officer) of Jwon Bank articulated at the core of the customer services cluster is
his vision of being “Korea’s preferred provider developed around the COTS Seibel system. The
of financial services.” The CEO also announced increased use of COTS reflects a general trend

Application Integration

within the bank over the last few years of adopt- rently unable to fully support the CEO’s vision
ing a best-of-breed strategy to procure packaged of a holistic set of closely interlinked financial
COTS systems that were best in their class. services. While certain financial services were
interlinked, such as bank accounts and savings
2003 strategic information accounts, allowing the easy interchange of funds
technology review between the two accounts, a large number of other
financial services were unlinked. A customer,
In 2003, the VP of technology at Jwon Bank for example, could not easily interchange funds
undertook a strategic review of the bank’s IT between bank accounts and investment accounts.
systems. The main purpose of the review was to In many cases, there was no direct automation
ensure that the bank’s IT systems and technology or real-time transfer of information between IT
architecture was well-positioned to meet future systems. Instead, back-end processes were con-
business needs and aligned to the bank’s business ducted as daily batch jobs or, worse still, relied
strategy. The strategic IT review was carried out on some behind-the-scenes manual processing.
over a 4-month period by an independent team For example, when a customer applied to open
from one of the “Big Five” consulting firms. a trading account, information was captured in
The VP of technology was taken aback by the IT system handling the applications. If an
the findings from the strategic IT review, which application was accepted, much of this informa-
indicated that Jwon Bank had significant short- tion had to be manually rekeyed by the bank’s
comings in its IT systems and architecture. One back-office staff into the IT system that opened
of the key findings highlighted in the strategic trading accounts. Not only was this a manual and
IT review was the lack of integration between IT intensive process, there was also the possibility
systems. The strategic IT review identified many of administrative errors.
cases of how the lack of integration between IT Importantly, the strategic IT review high-
systems affected customers or potential customers lighted that the lack of integration between IT
of Jwon Bank. For example, if an existing Jwon systems hampered the development of customer
Bank customer wished to purchase an insurance relationships and opportunities for cross-selling.
policy from the bank, he or she had to fill out a For instance, if a customer was arranging his or
form and resubmit all their personal details again her mortgage through Jwon Bank, it was likely
to the bank even though the bank already held that he or she would also be looking to purchase
such information in their IT systems. Also, if a home insurance. However, the current IT systems
customer informed the credit-card unit of Jwon in the bank did not provide any automated alert
Bank about a change in address, the change in to identify such situations, so cross-selling op-
address would not be automatically updated else- portunities were lost. In short, each cluster of IT
where in the bank’s other clusters of IT systems. systems effectively operated within its own silo,
So, while credit-card statements would be sent reflecting in much the same way how the business
to the customer’s new address, bank statements units within Jwon Bank were operating. In many
would still be sent to the old address. In fact, situations, however, the integration of IT systems
the strategic IT review revealed that common is not only a technical activity, but a strategic
customer data were duplicated in many different enabler for new business models and processes
IT systems, thus leading to the possibility of data (Sharif, Elliman, Love, & Badii, 2004).
inconsistency.
The review also highlighted that the bank’s IT
systems and technology architecture were cur-

Application Integration

recommendations further impetus for the development of an FPS

at Jwon Bank.
The strategic IT review team made a number The strategic IT review indicated that the de-
of recommendations. One of the key recom- velopment of an FPS would require a significant
mendations was the development of a financial degree of integration between the IT systems in
portfolio system (FPS). The concept of an FPS Jwon Bank’s IT architecture, which currently
was to provide each customer of Jwon Bank with suffered from a lack of integration. Consequently,
a personalised financial portfolio, that is, a single, a further recommendation was that Jwon Bank
consolidated view of his or her financial assets should consider an enterprise-wide integration
and commitments with the bank. Through an solution that would meet the strategic integration
FPS, customers could manage their portfolios, for needs of the whole bank. An enterprise-wide
example, switch money in their savings account integration solution would be a better alternative
to a managed investment trust, through a single to having multiple localized integration projects
point of access rather than through many different that involved point-to-point integration between
interfaces. An FPS was seen as central to Jwon specific IT systems, as shown in Figure 1.
Bank’s competitive thrust toward providing its Although a point-to-point integration solution
customers with a means of holistically manag- represents how organisations have traditionally
ing their finances. The FPS was also seen as an integrated their IT systems, a major problem with
important customer relationship management this type of solution is that as the number of IT
tool through which opportunities for cross-sell- systems to be integrated grows, the cost of building
ing could be acted upon. In fact, a few of the and maintaining such a large number of interfaces
smaller banks in Korea had already begun to becomes prohibitively expensive and often results
offer portfolio-centric services, thus providing in “spaghetti” integration (Linthicum, 2001). With

Figure 1. Two integration solutions

Point-to-Point Integration Solution Enterprise-Wide Integration Solution

Integration Hub

IT System

IT Cluster

Application Integration

an enterprise integration solution, commonly by the business analysts with stakeholders from
known as an enterprise application integration the different business units within the bank. Use-
(EAI) solution, this problem is addressed by the case scenarios (Cockburn, 2004) were developed
deployment of an integration hub that serves as a to illustrate how the FPS would be used by the
central point for interapplication communication bank’s customers; the following are examples.
(Lee et al., 2003; McKeen & Smith, 2002). Because
each IT system need only be integrated with the • Changing the customer’s address and per-
hub, an EAI solution significantly reduces the sonal profile
overall number of interfaces that need to be built • Purchasing a life insurance policy
and maintained. The IT systems in an EAI solution • Transferring funds between current, credit-
communicate with other IT systems by sending card, trading, and investment accounts
messages along the messaging middleware via • Viewing a single consolidated summary of
the integration hub. Furthermore, an integration financial assets and commitments
broker is able to support additional functionality, • Transferring funds to and from mortgage
such as the translation of messages into different accounts
formats, transaction management, and the ability • Performing a financial health check
to apply business rules and logic. • Assessing the value of one’s financial assets
The recommendations of the strategic IT re- in a future period of time
view were taken with seriousness by the VP of
technology at Jwon bank, who initiated a project to Rather than develop the FPS from scratch,
look into both the development of an FPS and an the business analysts recognized the potential to
EAI solution within the bank. The FPS would be extending the bank’s existing Internet banking
one of the IT systems that used the EAI solution system. This would have the advantage of building
to draw information from the bank’s clusters of upon an existing IT system that was familiar to
IT systems. So, although the VP of technology many of the bank’s current customers. Further-
had initially considered treating the FPS and more, the Internet banking system was proven
EAI solution as two separate projects, he felt that to be a reliable and stable IT system. The busi-
combining them into a single project with a clear ness analysts therefore proposed making major
business objective was more purposeful. enhancements to the Internet banking system so
that it became the FPS rather than developing the
FPS completely from scratch.
case Details
feasibility study
requirements gathering
In parallel with the requirements gathering ac-
A project team was assembled within the bank tivity, the IT architects on the team were tasked
comprised of a project manager, three business with the job of evaluating different options for
analysts, and three IT architects. The business developing an integration solution, estimating
analysts were tasked with the job of establishing costs, and making recommendations. Two ex-
requirements for the FPS. Although the strategic ternal consultants with significant experience in
IT review had described the notion of an FPS, large-scale integration from the consulting firm
further analysis needed to be carried out to de- that had conducted the strategic IT review were
termine the specific functional requirements of also hired to work with the team as independent
the FPS. A series of interviews was carried out advice and guidance would be valuable.

Application Integration

To be as objective as possible, the team first ered a kind of sophisticated gateway or wrapper
looked at the feasibility of a point-to-point inte- (Brodie & Stonebraker, 1995), enabling packaged,
gration solution, where a set of programmatic mainframe, and other systems to be connected to
interfaces would be built directly between the the integration hub. Some adapters are prebuilt.
IT systems that needed to exchange information. For example, there is a prebuilt TIBCO adapter
In fact, several of the IT systems in certain clus- for the ERP application SAP R/3, which enables
ters had already been integrated in this manner. SAP R/3 to be connected to the TIBCO EAI tool.
However, after further examination, a point-to- At a technical level, adapters typically make use
point integration solution was rejected for the of interfacing technologies such as application
following reasons. programming interfaces (APIs), SQL queries and
even Web services. Where prebuilt adapters are
• A high level of custom development would unavailable, adapter development kits supplied
be involved. With around 120 individual by the EAI vendor can be used to create custom
IT systems in the bank, the number of in- adapters, which is typically required for custom-
terfaces that would need to have been built built IT systems.
was estimated at over 250.
• There was a high level of development risk. rfP and vendor selection
With so many legacy IT systems in Jwon
Bank’s IT architecture that used older tech- A request for proposals (RFP) was written by the
nology, it was unclear that robust and reliable team and sent to 12 of the major EAI vendors. EAI
interfaces could be built from scratch. vendors who were small in size or who lacked a
• It would take a very long time to develop strong Asian presence were excluded in the RFP.
all the interfaces from scratch. Estimates As a strategic mission-critical project for the
suggested a maximum build capacity of 40 bank, the VP for technology was adamant that the
interfaces per year, resulting in a project chosen EAI vendor would need to be sufficiently
that would take over 6 years. resourceful and provide strong local support.
• There was insufficient in-house capacity The RFP included information about the FPS
and expertise to undertake such a sizeable and Jwon Bank’s IT systems and architecture. In
project. addition, a number of key technical requirements
was highlighted in the RFP relating to reliability
The team agreed that a point-to-point integra- and resilience in the event of system failure. A
tion solution had too many high-risk elements, high level of security was also stipulated given
and turned its attention toward an EAI integration the sensitivity of financial transactions and in-
solution as suggested in the strategic IT review. formation. EAI vendors were explicitly asked in
As a starting point, the team identified the the RFP to indicate the extent to which the EAI
leading EAI tools currently on the market. This tool and adapters covered the diverse range of IT
included EAI tools from vendors such as TIBCO, systems at Jwon Bank. Eight replies to the RFP
IBM, WebMethods, SeeBeyond, BEA, Mercator, were received that were considered complete,
and Vitria. EAI tools are generally comprised of from which four EAI vendors were short-listed
an integration hub, messaging middleware, and by the team based on the RFP response.
adapters that connect IT systems to the messaging More in-depth face-to-face presentations and
middleware. An important consideration in the discussions were held between the remaining four
selection of EAI tools is the range of available EAI vendors. The VP of technology at Jwon Bank
adapters (Lam, 2005). An adapter can be consid- knew that selecting the right EAI vendor was as

Application Integration

much a business decision for Jwon Bank as it is FPS prototype would enable the team at Jwon Bank
was a technological one. The EAI vendor would to develop a proof of concept and, importantly,
not just be a vendor; it would become a strategic evaluate the utility, performance, and reliability
partner who would need to understand Jwon of the EAI solution that would address the bank’s
Bank’s business and work hand in hand with the enterprise-wide integration needs. Furthermore,
team at Jwon Bank to ensure project success. It the pilot project would provide an opportunity
became evident to the team that only two out of for Jwon Bank and Mekon to work together and
the four EAI vendors appeared suitable partners assess how well they partnered with each other.
for Jwon Bank. The other two EAI vendors had A 6-month time frame was agreed for the pilot
limited experience in working with clients in the project to see what could be achieved.
financial services domain and did not appear to Mekon fielded a team of four of its consultants
have as good an understanding of the domain as to work with the team from Jwon Bank to develop
compared with the two short-listed vendors. the FPS prototype. Mekon followed their recom-
The EAI tools for the two short-listed EAI mended methodology for implementing EAI solu-
vendors were closely matched in functionality. tions, which involved the following five steps.
However, a consensus was reached amongst the
team to work with Mekon, an EAI vendor with a 1. Identification of business goals
strong Asia-Pacific presence and an established 2. Business process modeling and improvement
track record working with financial institutions (BPMI)
on the implementation of large-scale EAI solu- 3. Mapping of business information flows
tions. The VP for technology at Jwon Bank agreed 4. Systems connection
with Mekon that as a trial, they should conduct a 5. Business process execution
pilot project based on a selection of the use cases
identified in the requirements gathering phase. The teams from Jwon Bank and Mekon agreed
If the pilot project was successful, it would lead on a project plan based on the above steps and
to the continued engagement with Mekon on the worked together to execute the project. As part
full project. of Step 1, further interviews were held with
stakeholders in the various business units at Jwon
Pilot Project Bank both to clarify the scope of the pilot project
and identify the ways in which each business unit
The main objective of the pilot project was to de- handled customer profile data. Further sessions
velop an FPS prototype with partial functionality followed during BPMI (Step 2), in which business
based on a selected number of use cases. It was process models were created with each business
decided that the FPS prototype would focus on unit. These described, for example, how custom-
the specific issue of the customer profile, ensur- ers changed their address and contact details, and
ing that consistent customer profile data existed the workflow that was involved in each business
across the different IT systems at Jwon Bank. unit. What became apparent during BPMI was
The FPS prototype was considered sufficiently that although each business unit had an intimate
challenging in that it involved integration between understanding of the business processes within
a significant number of IT systems across dif- their own business unit, the understanding of
ferent business units with Jwon Bank, and was business processes across business units was
nontrivial in nature. The intention was that the less well-understood. In other words, intrabusi-
FPS prototype would not be made immediately ness unit processes were well-defined, but not
available to Jwon Bank’s customers. Rather, the interbusiness unit processes. Such interbusiness

Application Integration

unit processes, however, were central to the de- custom adapters, so this work was outsourced to
velopment of an FPS. the development services group at Mekon who
The mapping of business information flows had done many such custom adapter development
(Step 3) involved establishing the flow of customer projects before and so were well-versed in this
data from one IT system to the next. The business type of specialized work. A development team at
information flows were modeled in the EAI tool Jwon Bank worked on the development of other
and it was determined how information would be aspects of the FPS prototype in conjunction with
sent via the integration hub from one IT system the work on the installation of the EAI tool and
to another. In some cases, data would be sent to custom adapter development. Extensions were
multiple IT systems. For example, if a customer added to the Internet banking system to create
changed his or her address, this information the FPS prototype.
would need to be propagated to the IT systems After 6 months, the original planned dura-
that held address information in other business tion of the project, it was clear that the prototype
units. Importantly, this step in the methodol- FPS was someway off being complete. The main
ogy also highlighted where customer data were reason for this related to the custom adapters that
duplicated across multiple IT systems, leading needed to be specifically developed to integrate
to possible data inconsistency. Furthermore, the bank’s custom IT systems. Unlike prebuilt
information was stored in individual IT systems adapters, custom adapters were like mini applica-
where the primary key was the account number tions in their own right and required their own
or policy number. Hence, it was difficult for Jwon life cycle of specifying, developing, and testing.
Bank to identify all the accounts or policies that The development services group at Mekon had
any particular individual held. This holistic view not originally anticipated that they would be so
of the customer was central to the development involved in the FPS prototype, so the manpower
of the FPS and Jwon Bank’s business strategy shortages on their side were also a constraining
in general. The team therefore designed the FPS factor. Without the custom adapters ready, the
around a database that captured a centralized team could not proceed to conduct full end-to-end
profile of each customer. testing of the FPS functionality. This delayed the
The systems connection step (Step 4) involved project a further 3 months, and it was only after 9
the installation of the EAI tool and the adapters months that the FPS prototype and EAI solution
that were needed to connect the bank’s IT systems were ready. Although the user interface of the FPS
to the integration hub. For some of the bank’s IT prototype was rudimentary, the main objective
systems, such as the call-centre system, which was to test the functionality of the FPS prototype
was based around the Seibel packaged system, and the robustness of the EAI solution. A suite of
prebuilt adapters already existed. However, for functional tests were run with satisfactory results.
several of Jwon Bank’s custom-built IT systems, Performance testing also revealed that response
prebuilt adapters were unavailable and so custom times of the FPS prototype under high loads was
adapters had to be developed. For example, the satisfactory for a system of this kind that would
Internet banking system was custom developed be accessed over the Internet.
using Java. The EAI tool included an adapter
software development kit (SDK) with a Java evaluation of Pilot Project
API that enabled a custom adapter to be created
for the Internet banking system. The IT staff at The VP of technology at Kwon Bank considered
Jwon Bank did not have the necessary techni- the pilot project a mild success. The EAI solu-
cal knowledge to undertake the development of tion proved to be robust and the prototype FPS

0
Application Integration

was a system that could be taken further into full of the resources and costs required to deliver an
development. Furthermore, the teams from Jwon FPS with full functionality. In particular, where
Bank and Mekon appeared to work well together custom adapters needed to be developed, costs
and complemented each other. The team at Jwon would increase significantly. The team estimated
Bank possessed the domain knowledge associated that every custom adapter would require about
with financial services and Jwon Bank’s business $60,000 in development, testing, and installation
processes, while the team at Mekon provided the costs. In comparison, the costs associated with the
EAI solution implementation know-how. licensing of the EAI tool were relatively minor.
However, the pilot project was not without
problems that the VP of technology knew posed
potential risks in moving forward with a full current challenges anD
project. The prototype FPS implemented only ProBlems facing the
about 10% of the full functionality of the FPS, organisation
yet took 9 months to develop, so an FPS with
full functionality could conceivably take over 90 Jwon Bank faces a number of challenges in going
months. It was clear, therefore, that the develop- beyond the pilot project and developing an FPS
ment of an FPS was a significant undertaking and with full functionality, and implementing a full
not something that could be delivered quickly. EAI solution to address their enterprise-wide
Rather, it was better to view the FPS as a project integration needs. One challenge is bridging
that would need to be divided into stages, with the organisational silos that have emerged as a
functionality released incrementally over a long consequence of having separate business units
period of time. Such an incremental approach responsible for different sets of financial services.
would also allow Jwon Bank to better manage Sawhney (2001) recognizes this as a significant
project risks. The team had already agreed that issue in many large organisations, where “islands
they should extend the Internet banking system to of applications” tend to emerge from business units
become the FPS. However, a challenge remained creating their own IT systems without thinking
in deciding what functionality of the FPS should about the broader needs of the organisation as
be implemented first. Although this was essen- a whole. In addition, the team discovered that
tially a matter of business priorities, each of Jwon intrabusiness unit processes, that is, business
Bank’s business units would claim that the FPS processes within a particular business unit,
functionality pertaining to their respective areas were well-understood, but not interbusiness unit
was high on the priority list. processes. However, it is the interbusiness unit
One of the most worrying aspects of the pilot processes that are central to the development of
project for the Kwon Bank team was the time and the FPS because it involves taking a customer
effort needed to develop custom adapters. Many view across multiple financial services. Until now,
of the IT systems in the IT architecture at Kwon there has been no specific unit or team within
Bank were custom developed, so it was clear that Jwon Bank that has examined interbusiness unit
a significant number of custom adapters would processes. Jwon Bank may consider addressing
need to be developed. The pilot project, however, this void by reviewing the organisational struc-
had demonstrated that the development of custom ture of the bank and creating a working group
adapters was probably the area that represented comprising of representatives from each of Jwon
greatest risk and effort. On the other hand, the Bank’s business units.
pilot project had been an extremely useful exer- A further challenge is managing a project
cise as it had given Jwon Bank some firm idea of this sheer scale. It took the team 9 months to

Application Integration

create a prototype FPS with 10% of the over- ing committee for this purpose and developing a
all functionality required. It has already been suitable governance structure.
recognized by Jwon Bank that a broader plan Jwon Bank must also pay close attention to
will need to be devised in which the functional- the management of project costs. IT projects
ity of the FPS will be rolled out in stages over are notoriously known for cost overruns (The
a period of time. Jwon Bank must determine Standish Group, 1994). The experience from
what functionality should be rolled out in which the pilot project has shown that significant costs
release, and the basis upon which this is to be (and risks) are associated with the development
determined. For example, is some functionality of custom adapters. Unlike prebuilt adapters that
considered more urgent than others in terms of can be installed and configured, custom adapters
business need? Should functionality that is simpler must be specifically developed for a custom IT
to implement be rolled out before functionality system and therefore treated like a mini project
that is more complex? Or is some functionality in its own right. Jwon Bank will need to identify
dependent upon other functionality already being which adapters need to be custom developed and
implemented? Jwon Bank must consider all such estimate development costs to formulate an ap-
issues in the formulation of a broader rollout plan propriate budget. If the functionality of the FPS is
for the FPS. There are also many other factors to be rolled out incrementally, then a budget will
that need to be taken into account, including staff need to be formulated for each release. Given its
availability at Jwon Bank, adapter development lack of in-house expertise, it would be sensible for
capacity at Mekon, the impact of other IT projects Jwon Bank to outsource custom adapter develop-
in the business units, and business priorities for ment to Mekon as an integral part of the overall
Jwon Bank. Furthermore, there are also potential partnership between the two organisations.
internal political sensitivities to navigate, where The partnership with Mekon is crucial to the
the choice of some FPS functionality over oth- success of the FPS project for two reasons. First,
ers may be construed as favourtism toward a the EAI tool of Mekon is the centerpiece of Jwon
particular business unit. Bank’s enterprise-wide integration solution.
It is clear that the development of the FPS Second, Jwon Bank lacks the in-house skills and
will require input and involvement from many expertise to undertake such a project alone. Hence,
different stakeholders, including representatives Jwon Bank is very much dependent on Mekon to
from the respective business units. There are es- provide much of the required expertise. While this
sentially many internal customers for the project, may be acceptable in the short term, Jwon Bank
all of which have their own requirements to be needs to think about building up its in-house skills
satisfied within the FPS. The management of and expertise and becoming less dependent upon
stakeholder expectations is therefore critical to Mekon in the longer term. In addition, although
the success of the project. Clearly, the amount the pilot project suggested that both teams at Jwon
of planning involved is significant, and a project Bank and Mekon worked well together, it remains
of this nature will require a significant level of to be seen whether this good working relationship
coordination. It may be sensible for Jwon Bank is one that will be maintained over the course of
to treat the development of an FPS as a program, time. One strategy that Jwon Bank may consider is
within which separate projects are organised and to institute a staff development and training plan
initiated. Within the umbrella of a program, some to build up in-house expertise. Another strategy
overall level of control can be maintained across is to consider a knowledge management initiative
projects and common standards applied. Jwon to capture, share, and disseminate knowledge and
Bank might consider establishing a program steer- best practices with the organisation (Davenport,
De Long, & Beers, 1999).

Application Integration

acknoWleDgment McKeen, J. D., & Smith, H. A. (2002). New de-

velopments in practice II: Enterprise application
The author wishes to thank employees at the real integration. Communications of the Association
Jwon Bank for their support and assistance in the for Information Systems, 8, 451-466.
writing of this case.
Sawhney, M. (2001). Don’t homogenize, synchro-
nize. Harvard Business Review.

references Sharif, A. M., Elliman, T., Love, P. E. D., &

Badii, A. (2004). Integrating the IS with the
Brodie, M., & Stonebraker, M. (1995). Migrating enterprise: Key EAI research challenges. The
legacy systems. San Francisco: Morgan Kaufmann Journal of Enterprise Information Management,
Publishers. 17(2), 164-170.

Cockburn, A. (2004). Writing effective use cases. The Standish Group. (1994). CHAOS report.
London: Addison-Wesley Professional. Retrieved from http://www.standishgroup.com/
sample_research/chaos_1994_1.php
Davenport, T. H., De Long, D. W., & Beers, M. C.
(1999). Successful knowledge management proj-
ects. Sloan Management Review, 39(2), 43-57.
enDnote
Lam, W. (2005). Exploring success factors in
enterprise application integration: A case-driven 1
The case is based on a real-life organization,
analysis. European Journal of Information Sys-
although the identity of the organisation
tems, 14(2), 175-187.
has been disguised at the organization’s
Linthicum, D. (2001). B2B application integration. request.
Reading, MA: Addison Wesley.

Chapter XVII
Case Study:
Service-Oriented Retail
Business Information System

Sam Chung
University of Washington, Tacoma, USA

Zachary Bylin
University of Washington, Tacoma, USA

Sergio Davalos
University of Washington, Tacoma, USA

aBstract

The primary objective of this case study is to discuss a retail business information system illustrating
an e-business integration example among a biometric attendance system, a surveillance system, and a
point-of-sale system. Using a service-oriented architecture allows businesses to build on top of legacy
applications or construct new applications in order to take advantage of the power of Web services.
Over the past years, Web services have finally developed enough to allow such basic architectures to
be built. Each of the components in the system will be designed and developed using a service-oriented
architecture that clearly illustrates how such cutting-edge systems can be put together. By designing
these components in such a fashion, this example will focus on applying service-oriented development
and integration techniques to the retail sector. The result of this project will be an integrated system that
can be used by businesses everywhere to learn how their organizations can benefit from service-oriented
architecture. Also, the application of the service-oriented development and integration to systems that
were previously stand-alone and heterogeneous is discussed. All previous experiences in object-oriented
architectures and design methodology are naturally streamlined with the service-oriented architecture,
supporting the loose coupling of software components.

introDuction applied to the development of software systems

for a retail business and the integration of the
The purpose of this case study is to discuss a retail software systems, this case study considers two
business information system (BIS) illustrating problems. The first problem is to propose how the
a service-oriented development and integration SODI can be defined without losing the valuable
example among a biometric attendance system, experiences of the developers in object-oriented
a surveillance system, and a point-of-sale (POS) analysis and design. The second problem is to
system. Various software systems typically used propose how the SODI can be applied to the
in businesses can be developed and integrated us- development and integration of a retail business
ing SOA (service-oriented architecture; Alonso, information system.
Casati, Kuno, & Machiraju, 2004; Erl, 2004). An Web service technologies are still relatively
SOA is a way of designing a software system to immature in comparison to other networking
provide services to either end-user applications protocols and technologies. At this time, the only
or other services through published and discover- relatively stable aspects of Web service technolo-
able interfaces. gies are the simple object access protocol (SOAP;
The three heterogeneous applications used in World Wide Web Consortium Extensible Markup
this case study are a system for keeping track of Language [W3C XML] Protocol Working Group,
how long an employee works called EAS (em- 2006), the Web service description language
ployee attendance system), one using surveillance (WSDL; W3C Web Services Description Work-
systems to monitor an establishment called 3S ing Group, 2006), and universal description,
(Smart Surveillance System), and a POS system. discovery, and integration (UDDI; Organization
They are typical applications that are found in a for the Advancement of Structured Information
majority of retail BISs. Unfortunately, each of Standards [OASIS], n.d.). Other standards such as
these applications is almost always used in isola- WS-Addressing (W3C Web Services Addressing
tion and is difficult for users to interact with since Working Group, 2006), WS-Policy (IBM, 2006b),
they have been developed by different software WS-Security (OASIS, 2006), and semantic Web
companies, and integration with other systems is services such as the Web ontology language for
not considered at the beginning of their designs. services (OWL-S; W3C Semantic Web Services
In many instances, these components are con- Interest Group, 2006b), Web services modeling
structed using different programming languages ontology (WSMO; W3C Semantic Web Services
and are very difficult to upgrade and integrate Interest Group, 2006c), semantic Web services
with newer systems. For example, many POS framework (SWSF; W3C Semantic Web Ser-
systems need to manage employees and need a vices Interest Group, 2006a), and Web services
secure access mechanism through a fingerprint semantic (W3C Semantic Web Services Interest
recognition system. Although EAS supports this Group, 2006d) are still being researched and are
functionality, EAS cannot be easily integrated not mature enough to be applied to real BISs yet
into the existing POS system. by using industry-supported platforms such as
This case study demonstrates some of the .NET or Java.
advantages of SOA-based development and SODI is a software development and integra-
integration, which we call service-oriented de- tion approach that is architecture centric, integra-
velopment and integration (SODI), to construct tion ready, evolution based, and model driven.
a loosely coupled information system that can be SODI is architecture centric and integration ready
effectively altered and upgraded as time passes. since three architectural patterns—three-layered
In order to demonstrate how the SODI can be architecture (Alonso et al., 2004), multitier archi-

Case Study: Service-Oriented Retail Business Information System

tecture (Alonso et al.), and SOA—are employed the 4+1 view and visual modeling. In the next sec-
for design and deployment, and the loosely tion, the application of the SODI approach to the
coupled software components using Web services retail BISs is illustrated with visual models. The
allow future integration to be ready even before application of the service-oriented development
the integration demands. Also, since a software and integration to the case study is analyzed and
development methodology called rational unified discussed in the last section, which also provides
process (RUP; IBM, 2006a) is used, which has also some conclusions in regard to the case study.
been used in the development of object-oriented
BISs, SODI is an evolutionary development and
integration where all experiences in object-ori- Previous integration efforts
ented software development can be employed. In
addition, since the RUP has been used in tradi- What were businesses using to integrate their
tional object-oriented software development with internal applications before Web services came
the 4+1 view model (Kruchten, 1995) and unified about (Linthicum, 2003a, 2003b)? The first
modeling language (UML; Object Management generation of application integration techniques
Group [OMG], 2007), the SODI approach using mainly included writing adapters that would take
the RUP is model driven. data from one application, adapt them for use in
A retail BIS that consists of a biometric at- another application, and then send these data off
tendance system, a surveillance system, and a to be used by another system. This first approach
point-of-sale system is developed and integrated was very tedious to develop, and the complexity
by employing the SODI approach. Based upon skyrocketed as new components were added.
the case study, the SODI approach is analyzed These troubles led to the second generation in
and discussed in addition to the integrated sys- application integration paradigms. This new
tem that can be used by businesses everywhere generation utilized third-party components that
to learn how service-oriented architectures can already had adapters available for purchase. While
benefit their organizations. The discussions of the this may have saved organizations some time, it
SODI approach on this case study shows to Web still required quite a bit of money. Piecing third-
services practitioners that Web service technology party components together using adapters saved
brings a BIS in which software components can developers a large amount of time over first-gen-
easily integrate with others since they are loosely eration techniques; however, the resulting system
coupled through Web services. Also, the BIS was still very complex to use. Trying to integrate
developers can adopt this emerging technology applications developed in house with third-party
of Web services naturally since their experiences components could be quite troublesome at times.
of the architectural patterns and the design meth- While some of these problems have been ironed
odology in object-oriented development can be out today, many still exist and remain a concern
seamlessly reused for service-oriented develop- for developers working on non-service-oriented
ment and integration. integration projects.
Next we will discuss some of the previous Up to now, the efforts for enterprise applica-
approaches to integrating enterprise application integration (EAI) and business-to-business
tions. Then, the three system components to be (B2B) integration have been much more costly
developed and integrated are discussed in more and time consuming than it would have been if a
detail. After that, the chapter provides the SODI service-oriented integration strategy were used.
approach, which consists of three architectural An integration approach using the electronic data
patterns and the SODI design methodology using interchange (EDI) format does not share opera-

Case Study: Service-Oriented Retail Business Information System

tions but only data, so the bandwidth between Once employees begin using EAS for finger-
heterogeneous software components is higher print recognition, managers can begin using the
than for SODI. Integration approaches using more advanced features of the system. Employee
distributed object-oriented computing paradigms schedules can be created and entered into EAS.
(Coulouris, Dollimore, & Kindberg, 2002) such Then, at any time, managers can generate reports
as remote method invocation (RMI) or Common that outline an employee’s actual work activity
Object Request Broker Architecture (CORBA) and compare it to the scheduled activity. These
need more effort from system developers and reports can also be used for tracking overtime
integrators compared to the service concept since work, people disobeying corporate policies, or
a tightly coupled lower level abstraction concept payroll systems. The employee information is
called distributed objects are used. a good example of data that can be shared with
other information systems.
Many businesses use surveillance systems
heterogeneous aPPlications for some reason. Typical uses are for monitoring
to Be integrateD customers and employees to (hopefully) prevent
theft. Another use is for monitoring property to
Three heterogeneous applications are developed, record break-ins. The major problem with these
and some of their functions are integrated as conventional security systems is that they often
Web services in other systems: EAS, 3S, and a run on relatively ancient hardware, storing footage
POS system. on VCR cassettes. The digital storage capabilities
EAS is a system that allows small businesses of computer hard drives have increased greatly
to monitor and record an employee’s attendance over the years. Today, it is even possible to see
at work (Kerner, 2000). Businesses need some systems with storage capacities of up to 1 terabyte
way to keep track of how long an employee has or 1,000 gigabytes in size. 3S will take advantage
worked for a given day or week. There are many of these large storage capacities. In addition,
solutions to this problem, and some are much the use of Web service technologies will enable
better than others. By better, it is implied that businesses to know anytime, anywhere when any
some systems are much less vulnerable to being unwanted activity takes place.
manipulated by unscrupulous employees. The final component is a newly designed point-
Instead of relying on arbitrary digits or strings of-sale system. Virtually every retail store now
for identification purposes, EAS in this case uses some kind of computer-aided POS system.
study uses an employee’s unique fingerprint to These systems allow products to be scanned using
identify an employee for purposes of signing in some kind of barcode device, allows the product
or out from work. While forging an identifica- prices to be totaled, and provides mechanisms
tion number may be trivial, forging a fingerprint for cashiers to perform various operations such
is exponentially more difficult. An individual’s as selling or returning goods. There is a wide
fingerprint consists of various loops and whorls spectrum of different POS applications on the
intermingling with each other on the surface of market today. There are off-the-shelf solutions
our finger pads. Within these elaborate designs, that can be purchased and customized, and there
one notices certain points that in combination are in-house solutions for a specific business. The
can be used to uniquely identify a given person. problem with the first set of systems is that they
To forge a fingerprint, one would have to make are often too generic where the latter systems are
a replica of the surface of a person’s finger, or too tightly coupled.
as a slightly more drastic measure, sever off a
person’s finger.

Case Study: Service-Oriented Retail Business Information System

service-orienteD The business logic in JavaBean or Code Behind

DeveloPment anD integration is executed at the third tier, while accessing the
database is executed on the fourth tier.
SODI is the software development and integration In the service-oriented architectural pattern of
approach that is architecture centric, integration Figure 1c, software can be considered as multiple
ready, evolution based, and model driven. The interactions of the service consumer, producer, and
architecture-centric property means that multiple broker if a software component can be declared as
architectural patterns—three layered, multitier, a Web service whose interface can be represented
and service oriented—are used for design, de- in a standard language, and can be discovered and
ployment, and integration. In the three-layered invoked through a standard protocol. Currently, a
architectural pattern, a software application is service producer can generate the interface of a
designed by a set of three separate horizontal software component in WSDL by using a SOAP
logical layers in which presentation, business, engine, and manually publish the Web service
and data logics are independently developed and information onto a UDDI service registry that
maintained, which is shown in Figure 1a. The is managed by a service broker. If a service con-
presentation logic layer contains user-interface- sumer needs the service, the service consumer
related constructs and features that end users of can discover the service from the service registry
the application may wish to know about. The manually or programmatically through a client
business logic layer contains the core business program, although this autodiscovery function is
logic for the applications being built. Lastly, the very limited. The discovered service is invoked
data logic layer contains database-related logic by the client and bound to the service through the
that manages and permits access to the database interaction protocol SOAP that is located at the
system of the application. service producer’s host.
In the multitier architecture, n subcomponents The integration-ready property means that
of an application cooperate with one other us- the integration of software applications using the
ing some protocols. Each tier is deployed on a multi-architectural patterns has built-in interoper-
separate host in a distributed network for security ability since components of each application are
and reliability. Figure 1b shows both the four-tier logically separated for better design, properly
architecture for a typical Web application and the distributed over the network, interfaced in a
three-tier architecture for a typical Windows ap- standard interface language, and invoked through
plication using client-server computing. Although a standard interaction protocol. Some objects,
a tier does not mean a host, multiple hosts are which may be reused internally or externally in the
used in developing such distributed applications. future, are designed, implemented, and deployed
Since the functions requiring similar execution as Web services that support interoperability for
environments can be located at the same tier and integration. Since interoperability is supported in
the location of functions to be deployed is known those components through Web services before
in advance, the multitier architecture has been the actual integration demands occur, it is possible
used along with the three-layered architecture. to plan for contingencies in the design phase of
For Web applications, client-side presentation the applications.
logic in HTML (hypertext markup language) can The evolution-based property means that the
be downloaded from the second-tier Web server knowledge and skills that have been adopted in the
and then executed on the first-tier client machine. traditional object-oriented software development
At the second tier, the server-side presentation can still be used with Web service technology.
logic in JSP or ASP can be located and executed. Since a Web service can be considered a class

Case Study: Service-Oriented Retail Business Information System

Figure 1. Multiple architectural patterns

Presentation Business Data

Logic Logic Logic
Layer Layer Layer

(a) Three-layered architectural pattern

Tier 1
(Web App.)

Tier 1 Tier 2
Tier 2 Tier 3 (Windows App.) (Application Server)
(Web Server) (Application Server)

Tier 3
Tier 4 (Database Server)
(Database Server)

(b) Multitier architectural pattern

Service
Discovery Broker Publish
(UDDI) (WSDL)

Service Service
Consumer Producer
Binding
(SOAP)

(c) Service-oriented architectural pattern

Case Study: Service-Oriented Retail Business Information System

with standard interface descriptions in terms of while activity diagrams help describe the basic
object orientation, the methodology for object- flow between application components. The user
oriented software development can be naturally requirements are viewed in terms of the three-
used. RUP is a process framework that has been layered architecture, and each layer is represented
used in traditional object-oriented software as a subsystem in the use-case diagrams. If a use
development (Booch, Rumbaugh, & Jacobson, case or a set of use cases needs more explanations,
1999; Jacobson, Booch, & Rumbaugh, 1999). The activity diagrams are drawn for them.
RUP is an iterative, incremental, concurrent, and During the elaboration phase, the design
visual model-driven design process based upon and process views are modeled based upon the
Kruchten’s (1995) 4+1 view. The 4+1 view model use-case or activity diagrams. The design view
describes the architecture of software-intensive model consists of class diagrams for a business
systems based upon multiple and concurrent logic layer and entity-relationship (ER) diagrams
views—the design view, implementation view, for databases (Connolly & Begg, 2005). Class
process view, deployment view, and use-case diagrams are used to model classes and their
view—representing logical or physical, and static relationships.
or dynamic properties of a software application When Kruchten’s (1995) 4+1 view model
that are interconnected by user requirements. was proposed, the object-orientation concept
Since Kruchten’s model was later incorporated was dominant at that time. Also, the concept of
into a famous computer-aided software engineer- software development within an organization
ing (CASE) tool, IBM’s Rational Rose Modeler was the main concern instead of the integration
that supports RUP and UML, SODI using RUP of heterogeneous software applications across
is naturally model driven. organizations. Additionally, the concept of pro-
In SODI, while a software project is being cess could not be clearly represented with the
developed through the inception, elaboration, conceptual building block object. Therefore, the
construction, and transition phases, the activi- process view was limited to methods in a class,
ties for analysis, design, implementation, and the states of an object, and interactions among
deployment are done iteratively, incrementally, objects. If a method of a class needs more ex-
and concurrently. The activities are modeled based planation, an activity diagram can be used to
upon Kruchten’s (1995) 4+1 view using UML explain the method. Also, the state change of an
diagrams. These visual models are used for model- object can be explained in a state-chart diagram.
ing, that is, visualizing, specifying, constructing, The interactions among several objects can be
and documenting the service-oriented software described in an interaction diagram that may be
development and integration. Table 1 shows SODI a collaboration or sequence diagram.
using the RUP framework and 4+1 views. Since a Web service can represent a business
At the inception phase, SODI practitioners process, and a special class called an interface can
bring the idea of using three architectural patterns represent the service, a class diagram can be used
to all workflows. During the inception phase, the to show the relationship between the Web service
use-case view is mainly modeled based upon the and a set of classes to implement the service. Class
given or collected case scenarios. The use-case diagrams mainly focus on the structure hidden
view model consists of use-case diagrams along behind the Web service interfaces. Using an activ-
with activity diagrams for more detailed coverage ity diagram, we can represent the collaboration
of use-case specifications. Use-case diagrams among services.
are generally used to describe the requirements During the construction phase, the implemen-
present throughout the design of the system tation view model is built by using component

0
Case Study: Service-Oriented Retail Business Information System

Table 1. SODI using the RUP framework and 4+1 views

Activities View and Phase Inception Elaboration Construction Transition

Use case scenarios


Requirements Three layered architecture

Use Case
Workflow SOA

View
 Use Case diagram
 Activity diagram for a use case within a layer

Three layered architecture


SOA

 Class diagram for classes and services
Analysis/  Activity diagram for methods
Design Design View  Statechart diagram for classes
Workflow Process View  Entity Relationship diagram for database
 Interaction diagrams fro object and atomic service
collaboration
 Activity diagram for composite service
collaboration*

Implementation SOA

Implementation
Workflow Multi-tier architecture

View
Component diagram


SOA

Deployment
Deployment Multi-tier architecture

Workflow
View  Deployment
diagram

* No service composition was employed at that time. A service consumer, which is either a Windows or Web application, only
invokes Web services located at remote platforms.

Case Study: Service-Oriented Retail Business Information System

diagrams. These diagrams are closely linked to There are various problems associated with
class diagrams but are a bit more physical in their the existing surveillance solutions, namely, the
existence. Component diagrams primarily focus systems can react to streamed video and perform
on defining dependencies between components some action. However, they are not proactive in
of any type for a layer on a tier. nature. The 3S implementation provides a better
During the transition phase, the deployment control layer for managers to use when interacting
view is modeled using deployment diagrams. with their security camera. 3S allows managers to
Deployment diagrams clearly illustrate how your schedule images to be taken at any interval from
system components should be deployed, and any period of time throughout the day. This fine-
exactly on what system they should be deployed grained control allows managers to see only what
to. These deployment diagrams are used to out- they want at any time. Providing faster access to
line the deployment of executable components security recordings improves productivity and
onto a platform equipped with various software allows for more accurate archiving of footage.
engines. These features could be used for being notified
with various images from around your store when
the store is supposed to open or close. This would
case stuDy: soDi anD retail be a very handy feature for small business own-
Biss of eas, 3s, anD Pos ers who want to make sure that their employees
open their shop in the mall on time and do not
Each of the individual applications has its own set skip out early at closing time. Figure 3 is of the
of unique diagrams that describe the requirements start-up screen for 3S. The screenshots have been
of the system, the structure of the system, and how selected as images a manager would see if he or
the system should be deployed. While some of the she wanted to schedule a set of snapshots to be
Web services and classes are shared, for the most taken and then view them remotely.
part, each application is fairly different from one The new POS system takes advantage of the
another in terms of implementation. The diagrams features of an SOA to decouple the application
that appear in this chapter are just a handful of the interface from its implementation. To enhance
many different diagrams developed to describe the robustness of the system, its database back
the three applications: EAS, 3S, and POS. end has been built to be fully compliant with the
specifications outlined in the proven Association
use-case scenarios for Retail Technology Standards (ARTS, 2003)
model standard. The ARTS model is an industry
The first task is to collect the use-case scenarios. standard database schema that can be used for
Although there are many other functions offered enterprise-level retail database applications. By
by EAS, the employment enrollment with a fin- using this standardized database back end, a
gerprint is discussed in this chapter. The image in pluggable interface, and a Web service middle
Figure 2 depicts a manager enrolling an employee’s tier, the POS is constructed in such a way that
personal information in EAS. The upper half of it is capable of being upgraded, extended, and
the form contains personal details while the bot- integrated as new technologies and new business
tom half contains job-related details. Once the demands emerge. The main focus in designing this
employee’s personal information is entered, his POS system was to create a basic interface and a
or her fingerprint must then be enrolled. Once set of Web services that the interface can use to
the fingerprint is enrolled, managers can begin handle most of its functionality. The screenshots in
creating schedules. Figure 4 show one example interface that could be

Case Study: Service-Oriented Retail Business Information System

Figure 2. Employee enrollment in EAS

Figure 3. 3S start-up screen

Case Study: Service-Oriented Retail Business Information System

Figure 4. POS start-up screen

used in conjunction with the Web services being system is responsible for enrolling employee fin-
developed. These are the screens that a cashier gerprints. The management system is designed to
would see after logging onto the system using a add, update, and delete employee information as
fingerprint when wanting to ring up a purchase. well as employee schedules. The report system is
This screen shows the main interface that cashiers responsible for generating the various reports that
use. Cashiers enter the product ID and the quantity, can be created once schedules have been entered.
and then click the Add Item button. The item is The final system is the database.
then added to the sales grid. The use-case diagram in Figure 5b illustrates
a store manager controlling employee schedules.
use-case view There are certain options that are presented to
the manager in the presentation layer. These op-
The core requirements for each application have tions such as updating schedules use the schedule
been described in use-case diagrams. Actors and management service in the business logic layer to
system components are first modeled using the accomplish its task. The schedule management
use-case diagrams. Next, the primary functional- service in turn uses the main EAS database and ac-
ity of each system is described in the three logic cesses the appropriate scheduling information.
layers in the diagrams. Figures 5 and 6 show the The use-case diagram in Figure 6a illustrates
use-case diagrams for EAS and 3S. a security person and a manager wanting to re-
Figure 5a illustrates the main functionality trieve a snapshot recording by using 3S. Security
of the EAS system, as well as the various sub- personnel can both delete and view snapshots
systems that have been identified and modeled. from the snapshot management service. The ac-
Within EAS, there are five main subsystems: four tivity diagram in Figure 6b depicts the process
that contain system functionality, and a database for viewing and deleting snapshots. First, the
system. The recognition system is responsible for snapshot service ensures that the snapshot actu-
matching employee fingerprints. The enrollment ally exists, and then the service either retrieves

Case Study: Service-Oriented Retail Business Information System

Figure 5. Use-case view of EAS

(a) Use-case view with a use-case diagram for EAS

(b) Use-case diagram with three-layered architecture for EAS

Case Study: Service-Oriented Retail Business Information System

Figure 6. Use-case view of 3S

(a) Use-case view with a use-case diagram for 3S

(b) Use-case view with an activity diagram for 3S

Case Study: Service-Oriented Retail Business Information System

Figure 7. Design view of the POS

the snapshot or deletes the snapshot depending Process view

on the input received. If the snapshot does not
exist, the service method returns. A collaboration diagram can represent the process
view by showing the interactions among objects
Design view and atomic Web services. An activity diagram
can represent the process view of a composite
The class diagram in Figure 7 shows a design view service by showing the interactions among Web
by showing the class hierarchy of the main form, services. In Figure 8, the recognition subsystem
which contains all the interfaces for the POS. The of EAS is not responsible for anything other than
main form uses two local classes, ReceiptInfo and recognizing fingerprints and contacting the ap-
Receipt, for managing receipts and receipt lines. propriate Web service FingerprintProcess with
Also, there is a payment form that allows cashiers the results. As such, it is much simpler than the
to enter the designated payment and calculate the other EAS components. The top class is a form;
change required. this class uses various other classes on the client
side within the same application.
The collaboration diagram in Figure 9 depicts
the relationship between a Web service object Ser-

Case Study: Service-Oriented Retail Business Information System

Figure 8. Process view of the recognition subsystem of EAS

Figure 9. Process views of 3S

Case Study: Service-Oriented Retail Business Information System

viceManager and other objects. ServiceManager code in C# behind page EmployeeHours.aspx.cs,

is a central class that is a Web service, and there two Web services used by the code behind pages
are various other classes and data sets that the UserValidation.asmx and EmployeeHours.asmx,
Web service class uses. There are data transport and the employee database used by both Web
classes such as ScheduleData and UserData as services EAS_DataBase.mdf.
well as normal data type classes such as Snap- Figure 11 depicts the dependencies that ex-
shotPack, which are generally found in the class ist in the 3S client application. The executable
library called ThreeSObjects. client depends on the Active X control called
AxisMediaControl.dll used to interface with
implementation view the camera. The MainForm that launches other
forms depends upon the 3S class library Three-
A component diagram can represent an imple- 3Objects.dll as well as a few other forms such
mentation view of a system by showing what as UserManagementFrm, ScheduleViewerFrm,
physical components are used and how they are SnapshotSelecterFrm, and so forth.
interrelated. Figure 10 contains a fairly simple
overview of the components of the Employee- Deployment view
Hours subsystem required to generate a simple
report containing information about how long an A deployment diagram can show which executable
employee worked for a given day. There is one components are deployed at which tier. Figure
Web form EmployeeHours.aspx, its corresponding 12 outlines which components are executable by

Figure 10. Implementation view of the EmployeeHours subsystem of EAS

Case Study: Service-Oriented Retail Business Information System

Figure 11. Implementation view of the 3S client

end users and where they are stored within the Figure 13 illustrates the four-tier architecture
EAS architecture. There are two types of client: used to deploy 3S. There is the actual camera
two client-side Windows applications called called Axis 2100, the 3S Windows application
EASRecognition.exe and EASAdministration. client called 3S.exe, the 3S database ThreeS_Data.
exe, and two server-side Web applications called mdf, the 3S server ThreeSSever.exe, and a service
EASLogin.aspx and EmployeeHours.aspa, ThreeS.asmx. Since the 3S sever can access the
which require network connections on both the remote camera through the Web service, the legacy
client and server sides, as well as the physical camera interface is hidden and any applicant can
fingerprint scanning device on the client side. access the camera easily.
Figure 12b shows the three-tier architecture for
the recognition component deployed, requiring
a client workstation, an application server, and analyses anD Discussions
a database server as well as an internal network
between each workstation. The service consumer One of the main goals of this project is to see
EASRecognition.exe invokes the FingerprintPro- the benefits of service-oriented architecture
cess.asmx Web service. by applying it in particular to the area of retail

00
Case Study: Service-Oriented Retail Business Information System

Figure 12. Deployment view of EAS

(a) Deployment view of all subsystems of EAS

(b) Deployment view of the recognition subsystem of EAS

0
Case Study: Service-Oriented Retail Business Information System

Figure 13. Deployment of 3S

business applications. This section describes the very often and need to be shared are designed as
main findings of this project that concern the ef- Web services. The POS project also benefited
fectiveness of SODI using SOA. The three systems from the use of Web services.
being built for this project were each developed When building the EAS project, Web services
in similar fashion overall, using similar modeling were used for virtually all core functionality, on
strategies and development schedules. However, both the input and output side. In addition to the
the main difference between these projects is the standard Windows forms classes and the Web
extent that Web services were used. services being used, a small class library was
developed that contained a few helper classes.
the role of Web services Since the main interface for EAS was written in
Visual Basic (VB) .NET, and some client-side
Using Web services for the EAS project was functionality was written in C#, this additional
beneficial but less so than for the 3S project. client-side functionality was stored in a class li-
With the EAS project, Web services were used brary as a proxy. A class library is just a collection
in a fashion similar to traditional middleware, of classes and interfaces bundled together into a
whereas the 3S project used Web services in new single file. The use of this library was mainly for
and interesting ways: Some functions that do not communicating with the Web service as a proxy
have to be changed very often are designed as a and reusing existing code built in C# that would
class library. Only functions that may be changed take too much time to convert to VB .NET. How-

0
Case Study: Service-Oriented Retail Business Information System

ever, for the most part, EAS was a true wrapper be required. Since this functionality already ex-
for various Web service methods. ists in a Web service, only minor modifications
In relation to the EAS project, 3S used around need to be made before the fingerprinting Web
50% less Web service calls and 75% more func- services are ready to be consumed in the POS
tionality stored in class libraries. Since the 3S application. Instead of depending on class librar-
project was supposed to be used remotely, making ies so much, the system interfaced directly with
long Web service calls frequently could have a the SQL server being used as the data store by
significant performance impact. Instead, some of adopting a tightly coupled approach so as not to
this prior Web service functionality was moved lose performance. This direct interface provided
into a class library. Then, instead of using this better transactional support then a series of Web
class library on just the client side as in EAS, this services could provide and allowed the interface
new library was used by both the Web services to react much more quickly to user input.
and the Windows client. Using the class library
in this fashion allowed the two main system com- lessons learned
ponents to share functionality without the worry
of versioning conflicts or the need to manually First of all, software developers and integrators
copy classes from project to project. In a vein can easily transition from object-oriented analysis
similar to Web services that are useful for sharing and design to service-oriented analysis and design
application logic between different systems, class since the valuable experiences of the develop-
libraries can also be used similarly. For example, ers in object-oriented architectures and design
in the EAS project, scheduling components were methodology are naturally streamlined with the
built directly into classes in the application. In the service-oriented architecture and design meth-
3S project, the scheduling components were built odology supporting loose couplings of software
to be more general and were stored in the class components. Both three-layered and multitier
library. If developers wanted to build an extension architectural patterns have been used to design
to EAS that used scheduling, they would have to and deploy object-oriented applications. The
copy the scheduling classes and manually rewrite service-oriented architecture simply enhances
and rename them to fit into the new project. By the interoperability of some components that
including the scheduling functions in a class li- may be integrated with other remote components
brary, all you need to do is reference the .dll file within organizations or across organizations
and start developing. This is very efficient and by allowing standard interfaces and interaction
a great way to increase productivity while Web protocols. Also, one of the design methods that
services are being used as the main integration have been adopted in object-oriented software
interfaces. developments, RUP, can be applied to service-
The POS project relied on Web services for oriented software developments with the revised
even less than the 3S project. Since the POS 4+1 view.
system is used heavily for input purposes, it is Secondly, SODI goes much smoother without
unlikely to be used from outside your local area having to rewrite the same code you had writ-
network; less benefit is gained from using Web ten before on previous projects. This is possible
services. However, Web services are still useful because the Web service technology brings a
for logging in cashiers and authorizing them to BIS in which software components can easily be
use the POS system, and reporting on items sold integrated with others (they are loosely coupled
and cashier activity. Without using a Web service, through Web services). You could just change
a rewrite of the EAS recognition system would your external interface for each situation, and

0
Case Study: Service-Oriented Retail Business Information System

then convert data into the formats supported by start describing the services with meaningful
the system’s Web services. semantic descriptions. Once service orchestration
SODI allows developers to separate the pre- languages start becoming feasible to implement,
sentation logic from the business logic in applica- orchestration tool kits could be developed specifi-
tions. A Windows desktop application or a Web cally for SODI systems. The composition of Web
application is located on the platforms of service services will bring more explicit process views to
consumers. The Web services are deployed onto the 4+1 view, and the dynamics of the integrated
the Web service platforms of service producers. system can be understood in terms of business
The presentation tier, a Windows desktop appli- process workflow.
cation or a Web application, interacts with Web
services that are located at remote Web service
platforms. The Web services interact with vari- references
ous business objects. Also, the Web service can
interact with other Web services that located at Alonso, G., Casati, F., Kuno, H., & Machiraju,
other platforms recursively. V. (2004). Web services concepts, architectures
Using Web services can explicitly represent the and applications. Springer Verlag.
process view, which describes dynamic features
Association for Retail Technology Standards
of a software system. If only atomic services are
(ARTS). (2003). Data model. Retrieved from
used (like this project), the services are considered
http://www.nrf-arts.org
special classes, that is, interfaces. The objects of
the interfaces are deployed onto a tier on which a Booch, G., Rumbaugh, J., & Jacobson, I. (1999).
Web service engine resides. Class and deployment The unified modeling language user guide. Ad-
diagrams are used to show the process view of the dison Wesley.
atomic services. If several atomic services can be
Connolly, T., & Begg, C. (2005). Database systems:
composed to a composite service, the composite
A practical approach to design, implementation,
service can be described in an activity diagram
and management (4th ed.). Addison-Wesley.
to show the process view.
Coulouris, G., Dollimore, J., & Kindberg, T.
(2002). Distributed systems: Concepts and design.
future Work Addison Wesley.
Erl, T. (2004). Service-oriented architecture: A
Web services allowed the vision of flexible inter-
field guide to integrating XML and Web services.
faces to become reality rather than remain in the
Upper Saddle River, NJ: Prentice Hall Professional
world of fantasy. The customization of business
Technical Reference.
information systems to reflect the brand of a busi-
ness will be of great benefit to anyone who runs a IBM. (2006a). Rational unified process (RUP).
business. Web services hold strong promise in the Retrieved from http://www-306.ibm.com/soft-
future of business and the future of our daily lives ware/awdtools/rup/index.html
as development on services progresses, taking us
IBM. (2006b). Web services policy framework
one step closer to a totally connected world.
(WS-Policy). Retrieved from http://www-128.
Future work on improving the SOA architec-
ibm.com/developerworks/library/specification/
ture can progress as soon as new technologies
ws-polfram/
are in place. As semantic description languages
for services become commonplace, people can

0
Case Study: Service-Oriented Retail Business Information System

Jacobson, I., Booch, G., & Rumbaugh. J. (n.d.). World Wide Web Consortium Extensible Markup
The unified software development process. Ad- Language (W3C XML) Protocol Working Group.
dison Wesley. (2006). Simple object access protocol (SIAP).
Retrieved from http://www.w3.org/2000/xp/
Kerner, L. (2000). Biometrics and time & at-
Group/
tendance. Integrated Solutions. Retrieved from
http://www.integratedsolutionsmag.com/Ar- World Wide Web Consortium (W3C) Semantic
ticles/2000_11/001109.htm Web Services Interest Group. (2006a). Semantic
Web services framework (SWSF). Retrieved from
Kruchten, P. B. (1995). The 4+1 view model of
http://www.w3.org/Submission/2004/07/
architecture. IEEE Software, 12(6), 42-50.
World Wide Web Consortium (W3C) Semantic
Linthicum, D. S. (2003a). Next generation ap-
Web Services Interest Group. (2006b). Web on-
plication integration. Addison-Wesley.
tology language for services (OWL-S). Retrieved
Linthicum, D.S (2003b). Where enterprise ap- from http://www.w3.org/Submission/2004/07/
plication integration fits with Web services.
World Wide Web Consortium (W3C) Semantic
Software Magazine. Retrieved from http://www.
Web Services Interest Group. (2006c). Web ser-
softwaremag.com/L.cfm?Doc=2003-April/Web-
vices modeling ontology (WSMO). Retrieved from
Services
http://www.w3.org/Submission/2005/06/
Object Management Group (OMG). (2007). Uni-
World Wide Web Consortium (W3C) Semantic
fied modeling language (UML). Retrieved from
Web Services Interest Group. (2006d). Web
http://www.uml.org/
services semantic (WSDL-S). Retrieved from
Organization for the Advancement of Structured http://www.w3.org/Submission/2005/10/
Information Standards (OASIS). (n.d.). Universal
World Wide Web Consortium (W3C) Web Ser-
description, discovery and integration (UDDI).
vices Addressing Working Group. (n.d.). Web
Retrieved from http://www.uddi.org/
services addressing (WS-Addressing). Retrieved
Organization for the Advancement of Structured from http://www.w3.org/Submission/ws-address-
Information Standards (OASIS). (2006). Web ing/
services security (WS-Security). Retrieved from
World Wide Web Consortium (W3C) Web Ser-
http://www.oasis-open.org/committees/tc_cat.
vices Description Working Group. (2006). Web
php?cat=security
services description language (WSDL). Retrieved
from http://www.w3.org/2002/ws/desc/

0
306

Chapter XVIII
Realizing the Promise of RFID:
Insights from Early Adopters and
the Future Potential

Velan Thillairajah
EAI Technologies, USA

Sanjay Gosain
The Capital Group Companies, USA

Dave Clarke
GXS, USA

Abstract

This chapter touches on some basics on RFID and covers business opportunities as well as some of the
relevant challenges to be faced. Although it is a new technology, standard obstacles of organizational
and technological barriers still have to be overcome and mediums crossed that were previously not
traversed as on warehouse and distribution center floors yield for challenging environments from a busi-
ness process as well as a technological adoption perspective. It provides a combined outlook sprinkled
with key lessons from early adopters and service providers close to some of the emerging trends and
implementations happening in the field. A range of benefits will evolve with the adoption of RFID within
an organization and especially across the entire supply network. For now, the value is only slowing
coming into focus. Various industry segments, like pharmaceutical and military applications, will provide
a smoother supply chain trail for others to follow.

Introduction ogy_Guide.pdf ), an important approach is to store

a serial number that identifies a product, along
Radio frequency identification (RFID) refers with other product information, on a microchip
to a set of technologies that use radio waves to that is attached to an antenna. The chip and the
identify and transmit information from tagged antenna together constitute an RFID transponder
objects. While there are several mechanisms or an RFID tag. The antenna enables the chip to
to identify objects using RFID (http://archive. transmit identification information to a reader.
epcglobalinc.org/new_media/brochures/Technol- Microchip-based RFID tags first started appear-

ing in the late 1980s, with initial applications in (line of sight) of a scanner, RFID tags can be read
areas such as access systems for office buildings remotely by a device up to 20 yards away, reduc-
and toll roads (http://archive.epcglobalinc.org/ ing the time and labor needed to recognize and
privacy_hearing.asp ). process objects. RFID tags can also be encoded
RFID technologies range from very-short- with data in addition to the basic identification.
range passive RFID and short-range passive RFID Some of the areas in which RFID tagging is
to active-beacon, two-way active, and real-time expected to improve supply chain performance
locating systems (RTLS; http://www.savi.com/ include the following.
rfid.shtml). Low-frequency (30 KHz to 500 KHz) Forecasting Information: RFID tagging has
systems have a short reading range and are com- significant implications for the generation of
monly used in asset tracking and security access better forecasts. Downstream data can be accu-
implementations. High-frequency (850 MHz to rately assembled and processed for use in driving
950 MHz, and 2.4 GHz to 2.5 GHz) systems offer multitier forecasting processes (Lapide, 2004).
long read ranges (greater than 90 feet) and high Such data can include warehouse inventories
reading speeds. The range of frequencies and their and withdrawals and inventory replenishments,
general distance ranges are noted in Figure 1. as well as product consumption. Retailers such
as Wal-Mart, which are pushing RFID technolo-
gies, are promising their suppliers information on
busIness opportunItIes products as they arrive and leave their warehouses,
stores, and store stockrooms, in addition to the
The opportunities from leveraging RFID tech- point-of-sale data.
nologies are varied and span a gamut of applica- On-Shelf Availability: Past research indicates
tion areas. For example, in retail settings, radio significant incidences of out-of-stock (OOS) issues
tagging can help to reduce theft and loss, more in retail settings. While a considerable proportion
easily locate items, provide suppliers with better of the problem occurs due to inadequate order
information on real-time demand for products, and processing, studies suggest a significant fraction
improve the speed of product distribution. While of OOS occurs when products are actually in the
conventional bar codes need to be passed in front store. According to a study conducted by Ander-

Figure 1. Source: http://www.electrocom.com.au/rfid_frequencytable.htm

307
Realizing the Promise of RFID

Table 1. Source: http://members.surfbest.net/eaglesnest/rfidspct.html

LF HF VHF UHF MICROWAVE

FREQUENCY
30-300KHz 3-30MHz 30-300MHz 300-1000MHz 1GHz and Up

Less than 2 meters Less than 1 meter 1-100 meters 1-100 meters 1-300 meters
Distance
1cm - 1.5m typical 1cm - .7m typical 1-3m typical 1-3m typical 1-10m typical

sen Consulting, 53% of OOS situations are based Improving Product Security: RFID tags can
on inefficiencies in the store ordering process. be used to ensure that a product is what it rep-
Another 8% of OOS situations happen while the resents itself to be and also to identify product
necessary supplies are in the backdoor inventory, movement. For example, in the pharmaceutical
but have not been shelved. Large retailers, such as industry, an EPC (electronic product code) and
U.K. supermarket chain Tesco, have begun using RFID pedigree system could enable authorized
RFID technology to track shipments of high-value users to automatically identify and account for
nonfood goods. To reduce OOS issues, the retailer each unit of authentic medicine in real time as
will attach RFID tags to its own shipping trays it enters and moves through the distribution
and dollies at its national distribution center before system. It could identify the current location of
they are loaded and sent through its supply chain all suspect products in the event of a recall, track
to retail stores. the disposal of damaged and out-of-date products,
Automating Proof of Delivery (PoD): Savings and allow law enforcement agencies full and ac-
for suppliers can also be found in the automation curate supply chain visibility if terrorists were to
of many administrative tasks associated with launch an attack using tainted medicine (Kontnik
product delivery (Kärkkäinen, n.d.). For example, & Dahod, 2004).
even crate-level tagging would enable automating Eliminating Stock Verification: RFID tags can
the proof of delivery and the invoicing process. automate the process of inventory verification.
Automatic proof of delivery would eliminate er- As an example, Mitsubishi’s high-tech library
rors caused by manual processes, thus reducing system utilizes Microchip’s MCRF450 13.56 MHz
costs associated with negotiating retailer claims tagging ICs that enable a library to monitor the
for incomplete deliveries. Also, the arrival of distribution of books, and video and audio mate-
tagged crates to the point of delivery could initi- rials; track sign-outs and due dates, log sign-out
ate an automatic invoicing process. The savings histories and hold requests for library patrons,
potential of automating invoice handling is much and prevent the theft of materials by identify-
larger than what is usually imagined. For example, ing each item in the library’s inventory with an
it is estimated to cost Procter & Gamble between irremovable RFID tag (“Mitsubishi Materials
$35 and $75 to process a customer invoice by Corporation,” 2003).
traditional means due to the high number of Incorporating Shelf Life of Products and
manual interventions needed with order, billing, Product Self-Management: Product recycling and
and shipment systems. reuse could be made easier and cheaper by shifting

308
Realizing the Promise of RFID

the responsibility for product management to the the chAllenges

product itself. That is, a combination of informa-
tion technology and product design could allow cost
products to more or less automatically manage
their end of life. RFID tags on products could be RFID reader costs can range from $100 to $3,000
read by garbage or recycling trucks at the same or more depending on the frequency and range.
time that the main can tag is being read. Using Companies would need hundreds to thousands of
such a configuration, the collection service could, readers to cover all their factories, warehouses,
for example, provide rebates for the recycling of and stores. Readers typically operate at one radio
items (Thomas, 2003). frequency, and there is no consensus standard.
Reducing Inventory Levels: RFID is expected If tags from three different manufacturers used
to lead to reduced inventory levels as firms have three different frequencies, a store might have
both the benefit of knowing what is on their to have three readers in some locations, further
shelves and better real-time forecasts based on increasing the cost.
accurate data. Thus, there is a reduced need for RFID tags are also fairly expensive—$0.50
buffer stocks. or more—which makes them impractical for
Mass Customization: RFID tags can be used to identifying millions of items that may cost only a
provide individual shoppers a customized product few dollars. RFID systems lack widely accepted
or service offering. As an example, Prada, an and implemented standards for communication
upscale clothing boutique, is planning an RFID and functionality, thereby limiting their practical
pilot at one store. It announced its flagship store usefulness and keeping their system costs too
in Manhattan would experiment with RFID at high for many applications. In order to achieve
that location (McGinity, 2004). Shoppers could significant item-level penetration within most
choose a blouse that, once brought into the dress- supply chain applications, transponders will need
ing room, would cause the associated RFID tag to be priced well under $0.05.
to trigger a fashion show displayed on a plasma These cost targets may be achieved only with
screen that shows the potential buyer exactly what a system-level approach that encompasses every
other items match that blouse, and what that blouse aspect of the RFID technology, from IC design
looked like on the runway on a model. to RF protocols, from reader design to back-end
Benefits from Component Tagging: At a data systems, and from IC manufacturing to an-
component level, tagging would allow better tenna manufacturing. The challenge has been to
management of work-in-process inventory and develop a complete open-standards-based system
also aid in the reverse logistics process. that enables the design and manufacture of low-
Integrated Forward Supply Chain Manage- cost RFID systems (http://archive.epcglobalinc.
ment: In some industries, where the ability to org/publishedresearch/MIT-AUTOID-WH-014.
supply a time- or application-sensitive product is pdf). Much of the focus surrounding RFID costs
a competitive advantage, tagging will allow sup- has been on chip or tag prices. However, imple-
pliers to manage customer inventories proactively, menting a fully functional system incurs multiple
thereby maintaining a competitive barrier to entry costs, including tags, readers, printers, middle-
and a strong value proposition for the customer. ware, infrastructure, consulting, research and
development, system changes, implementation,
training, change management, service-provider

309
Realizing the Promise of RFID

fees, and additional labor (Shutzberg, 2004). For Security and Privacy Issues
early adopters, it is likely that implementations
will prove more costly in the beginning stages RFID systems are different from other means of
given the likelihood of first-time mistakes and identification because RF communication requires
the lack of industry best practices. no contact and does not require a clear line of
sight, whereas other means of identification are
disproportionate Investments and either contact based or require line of sight. In
Benefits in Supply Chain other words, it is more difficult for the owner of
the RF tag to physically impede communication
Studies that have simulated the financial impact with the tag. Consumers have expressed con-
of RFID implementations suggest that in most cerns that they do not have a choice as to when
industries and scenarios, manufacturers will end or where the technology is used or as to how it
up losing money, especially those that produce will impact them.
low-value grocery-like products. This occurs A second major concern is that consumers
because they have to carry the cost of tagging believe that the system will be abused and that this
the products. A probable exception is the elec- will have a negative effect on them, especially in
tronics industry, where products have high value regard to their privacy. Consumers are also con-
relative to the cost of tags. For manufacturers, cerned about the health effects of the network’s
losses increase as the scenarios shift from case- radio waves, as well as shifts in employment
level tagging to blended tagging to item-level caused by these technologies (http://archive.
tagging, again with the exception of electronics, epcglobalinc.org/publishedresearch/cam-autoid-
where the manufacturers actually increase their eb002.pdf ).
gains (http://workingknowledge.hbs.edu/item. As an example, Italian clothier Benetton caused
jhtml?id=3651&t=dispatch ). a ruckus last January when it said its apparel would
Retailers, on the other hand, face a very dif- be fitted with RFID tags. “People will know when
ferent scenario. In almost all situations, large I shop! What I bought...what size I wear!” were
retailers are winners. As the scenarios shift from the kind of statements made by consumers. The
cases to blends to items, retailers tend to realize proponents of RFID tried to point out that this
a greater proportion of the gains. However, the information would only be available if someone
retailers experience a lot of risk as the required was holding a scanner to that tag, which would
capital expenditure of the blended and item only work inside a store. Still, given the public
scenarios approaches a half-billion dollars for outcry, Benetton discontinued the trial (McGin-
the $10 billion retailer model. Big distributors ity, 2004).
experience sizable gains, which are greatest in In terms of security, RFID tags are inher-
the items scenario, but their suppliers experience ently less secure, mainly because of the lack
even greater losses. Given this disparity in finan- of processing capacity on these tiny devices to
cial gains and required investments across supply handle much more than their core functions. A
chain players, mechanisms need to be developed somewhat compensating aspect is that most of the
for equitable redistributions that preserve incen- data transmitted by an RFID tag are not all that
tives for all players. meaningful unless they are considered in context.
However, as location-based or personal informa-
tion is linked in to that data, the possibility of a
security threat emerges.

310
Realizing the Promise of RFID

Information Sharing Issues associated standards and technologies. The first

key element is called the object name service
A significant challenge to RFID implementations (ONS). ONS points a computer to an address on
is the lack of clear standards or conventions for the the Internet where information about a product is
sharing of data with other firms. As an example, stored. The concept is based on the domain name
Pfizer Inc., maker of the much-counterfeited service, which points computers to the address of
Viagra, will place RFID tags on cases and retail particular Web sites on the World Wide Web.
packages of the impotence drug by the end of
next year. The company says it is in discussions Physical and Environmental
with wholesalers and retailers to work out hurdles, Challenges
including data sharing. That issue has been
one of the sticking points with the technology: Some implementations of RFID, in the food and
Manufacturers, wholesalers, and retailers are drug industries, for instance, may encounter
looking for ways to create a detailed pedigree of physical and environmental challenges corre-
the drugs’ shipment history while also guarding sponding to extremes in temperature, packaging
proprietary information, such as sales volume and constraints, labeling standards, and interactions
shipment frequency (Tesoriero, 2004). There are between products and RFID signals.
also industry-specific issues that may make some
organizations slow to adopt RFID, for example, Data Storage and Management
the need for regulatory approval of new technolo-
gies. In some cases, new labeling standards are The use of RFID technology will require the
emerging that may be in conflict with developing high-speed handling of very large data streams
RFID standards. from readers. The processing, storage, and man-
agement of these streams and aggregated large
Compatibility, Integration, and data sets will pose a new challenge for hardware
standardization and software vendors. Much of the data stream
will be repetitive information and can be ignored,
RFID implementations require new standards but processing algorithms must still be developed
to be agreed upon for identifying objects and to perform filtering operations, and these may be
linking them to other related information. The specific to applications or industries. Different
Auto-ID Center, initially a project based at MIT, industries may also have regulatory requirements
has proposed a universal standard for product that drive specific data processing and retention
license plates: the electronic product code. Like requirements that vary from other industries.
a bar code, the EPC is divided into numbers that
identify the manufacturer, product, version, and
serial number. Unlike the bar code, EPC uses an MovIng ForwArd
extra set of digits to identify unique items. The
EPC is the only information stored on the RFID Global Standards Under
tag’s microchip. This keeps the cost of the tag Development
down and provides flexibility since an infinite
amount of dynamic data can be associated with EPCGlobal, a member-driven organization, is
the serial number in a database. To help computer leading the development of industry-driven stan-
systems find and understand information about dards for EPC to support the use of RFID.
a product, the Auto-ID Center has developed

311
Realizing the Promise of RFID

Costs are Falling ocument). As more and more data become avail-
able in usable forms—particularly data generated
The costs of tags and readers are likely to fall in the after a product leaves the store—the information
future, particularly as standardization processes supply chain will begin to function as an inde-
gain greater momentum, creating economies pendent source of revenue, generating invaluable
of scale. However, integration costs may still data about product performance, consumer be-
be prohibitive until system integrators develop havior, and logistics. This will enable businesses
industry-vertical solutions they can replicate. to be more responsive to market trends and their
customers. Bundling information services with
Consumer Education physical products, such as smart appliances, will
be another key source of new value.
It appears that consumers’ concerns about privacy
can be overcome by the following (http://archive. Industry Adoption: Supplier Pains
epcglobalinc.org/publishedresearch/cam-autoid-
eb002.pdf ). Not all industries are expected to be equally likely
to adopt RFID technologies. Some industries (like
• Offering consumers greater control by consumer electronics, pharmaceuticals, and toys)
ensuring that they will be made aware of are likely to roll out their implementations earlier
when and where the network is being used due to suitable product attributes and category
and offering them an option to kill the tag economics.
• Creating governance mechanisms around In June 2003, Wal-Mart greatly advanced the
the use of the network through appropriate process of adoption when it announced that start-
guidelines, policies, regulations, or con- ing in January 2005, 100 of its top suppliers would
trols need to tag all pallets and cases going to some
• Offering information about the issues re- Wal-Mart warehouses. This mandate would be
lating to health effects and the impact on expanded throughout 2005 to include other parts
employment of its distribution network. Wal-Mart began its
RFID pilot on April 30, 2004. The eight suppliers
EPC RFID tag specifications specifically in- that started shipping a handful of RFID-enabled
clude the requirement that the tag will deactivate pallets were Gillette, Hewlett-Packard, Johnson
irrevocably if it receives a kill command (http:// & Johnson, Kimberly-Clark, Kraft Foods, Nestle
archive.epcglobalinc.org/privacy_hearing.asp). Purina PetCare, Procter & Gamble, and Unilever.
The Department of Defense (DoD), Target, and
The Information Supply Chain Albertsons announced their future RFID-tag-
ging requirements to their suppliers. For now,
RFID technologies herald the emergence of these mandates focus on pallets and cases, not
disposable computing that will offer new chal- on item-level tagging.
lenges in scalability, flexibility, and security of The U.S. Department of Homeland Security
the next generation as they create the possibility will soon begin using RFID technology at U.S.
of tracking millions of new transactions, sending border checkpoints. Internationally, officials in
and receiving small amounts of data that track the Great Britain are discussing proposals to embed
flow of goods and services throughout the supply tags in vehicle license plates. The U.S. Food
chain (http://cio-asia.com/pcio.nsf/unidlookup/ and Drug Administration (FDA) is pushing the
218EE519E41C886248256D8300484409?OpenD pharmaceutical industry to tag medicines by

312
Realizing the Promise of RFID

2007. Delta Airlines recently announced that it Need for Complementary Change in
will invest $25 million to deploy disposable radio Business Processes
tags to track and locate lost luggage, which costs
the airline $100 million annually. Las Vegas’ Mc- There is a clear need to integrate RFID technology
Carran International Airport has also announced within appropriate business processes. In some
that it will begin attaching radio tags this fall to cases, this requires significant change in how
all checked luggage (Swartz, 2004). companies manage processes such as ordering
Recently, several companies across the drug and inventory management. For example, moving
supply chain have been testing RFID deployment. from ordering to proactive replenishment would
Three drug makers announced plans for limited be needed to better leverage the power of in-
RFID rollouts. Closely held Purdue Pharma LP, stantaneous information availability. That would
maker of OxyContin, a potent opioid painkiller enable suppliers to respond quickly to changes in
that is often diverted to the black market, will ship demand instead of accumulating information to
100-tablet bottles with RFID tags to Wal-Mart form reasonably sized orders. The biggest value
and H. D. Smith Wholesale Drug Co. or impact will only result with a redesigned
Despite all of these announcements, the early business process flow that takes advantage of
adoption is not without pain for the participat- the newly available information, especially at the
ing companies. Wal-Mart’s suppliers are split edge locations. This traditionally is a notoriously
into two camps. About 30% of them are going slow and problematic process. It will be easier for
the whole nine yards and integrating RFID into new companies to start up in this mode then for
their infrastructures now. The rest are practicing existing companies to adopt it, and therein will
a method known as “slap and ship.” Essentially, to lie some of the disruptors who emerge as a result
meet Wal-Mart’s mandates, these companies are of this technology.
sticking an RFID tag on only a certain percentage
of cases and pallets in warehouses that are closest Think about Impact on Consumer
to Wal-Mart’s Texas distribution centers. Slap Value
and ship involves minimal data integration and
continues to leave the retail supply chain blind to RFID applications in many industries are being
product movement (Wailgum, 2004). It remains driven by consumer needs. In the automotive
to be seen what kind of cost-benefit outcomes are industry, where RFID applications are gaining
realized by the two sets of suppliers. traction, the deployment of RFID solutions prom-
ises clear new functional capabilities. Michelin is
starting to use tags in its tires, and there is great
lessons FroM eArly interest in next-generation consumer products,
IMpleMentAtIons such as passive keyless entry systems, theft-de-
terrent immobilizers, and parts-marking initia-
Based on the experience of companies that have tives. As in the infancy of any technology cycle,
been rolling out early pilot implementations, we it is difficult to ascertain whether car makers are
outline lessons for other companies considering overspecifying demand and technical product
RFID technologies. content prior to the need or development of the
real customer demand.

313
Realizing the Promise of RFID

Vertical Applications are the Key but as the world’s largest pharmaceutical manufactur-
a Current Weakness ers, wholesale distributors, and chain drugstores,
are working together as a group to explore key
An RFID solution consists of multiple components uses for EPC applications. This pharmaceutical
such as chips, tags, readers, antennas, software, industry group has also created three working
and vertical market applications. Industry experts teams to build a whole-industry perspective on
suggest that vertical market applications have issues relating to counterfeiting, shrinkage, and
been a weakness so far (Anonymous, 2003). Thus, theft. EPCGlobal and its associated working
greater effort needs to be expended in developing groups (hardware, software, and industry verti-
and deploying relevant business applications on cals) are collaborating and working through real-
top of the technology stack. One positive move- life scenarios on what is needed and laying the
ment in this direction is the attention that has been groundwork for realistic standards. An example
given to the pharmaceutical industry’s efforts with of such collaboration is the working group tasked
consumer packaged goods. with hammering out the specifics needed for EPC
information services (ISs). VeriSign also offers
Prepare for the Unexpected: a prototypical EPC IS to allow for research and
Bug Zappers Anyone? development efforts and increasing familiarity
with the EPC network.
As with all new technologies, RFID is expected Each new compliance driver, such as Wal-
to have its share of teething issues. For example, Mart, the DoD, and the FDA drug tracking,
IBM has tested RFID equipment in the backroom will both drive additional innovation and give
grocery sections of seven pilot Wal-Mart stores practical industry insight that will be beneficial
in support of the retailer’s RFID project. During for all parties.
the deployment, IBM consultants encountered
interference from handheld devices such as Explore Applications through Small
walkie-talkies, forklifts, and other devices typi- Pilots
cally found in distribution facilities. Nearby cell-
phone towers, which transmit at the high end of Organizations should start by directing their
the frequency band, sometimes leak unwanted implementations toward addressing specific goals
radio waves into the RFID readers. Bug zappers (e.g., POS [point-of-sale] visibility for a manu-
in the backrooms of the test stores also caused facturer, or inventory shrinkage for a retailer)
interference (Sullivan, 2004). Organizations need that create the most value for them and their
to be cognizant of such teething issues that may customers. Certain companies with a targeted
affect their implementations. Table 2 illustrates customer-service focus may find item-level RFID
an early sampling of the RFID spectra with the has operational cost savings. Marks and Spencer
potential for interference. guarantees that it will have every size of pants
and suit so that the customer will always find his
Galvanize Industry Collaboration or her required size. It does a nightly inventory
of each item sold and replenishes accordingly.
The lack of industry standards can be a significant Automating inventory tracking would mean a
roadblock to the use of RFID technologies. Some reduction in the operational cost impact as well
industries have taken a collaborative approach to as an improvement in the percentage of having all
this issue. The major pharmaceutical players, such stock on hand. The driver for Marks and Spencer

314
Realizing the Promise of RFID

Table 2. Source: http://members.surfbest.net/eaglesnest/rfidspct.htm

Spectrum Characteristics for RFID

UHF
LF HF VHF MICROWAVE
FREQUENCY 300-
30-300KHz 3-30MHz 30-300MHz 1GHz and Up
1000MHz

Reflection / Nulling None Low High Higher Highest

“Skip” Interference
None High Low Lower None
Tropo Ducting

Electrical
Very High High Medium Med to Low Low
Interference

Less than 2 meters Less than 1 meter 1-100 meters 1-100 meters 1-300 meters
Distance
1cm - 1.5m typical 1cm - .7m typical 1-3m typical 1-3m typical 1-10m typical

Regulations Part 15 Part 15 Part 15 Part 15 Part 15

Data Rate 1-10KB/s 1-3KB/s* 1-20KB/s 1KB-10MB/s 1KB-10+MB/s

* (Depends on regulations and distance. At very close spacing like smart cards, higher data rates are possible.)
Reflection is signal reinforcement or cancellation (nulling) due to direct and reflected signals being in or out of
phase based on the distance between the source and target and the length of the reflected path. Enhancement is
usually only 3 to 9 dB, while nulling can be total. Nulls can be -10 to -30 dB; however, signal fill from multiple
reflections in most indoor environments will generally reduce nulling losses to -6 to -12 dB or so.

Blocking (not in the chart), on the other hand, can be total in some locations. Blocking occurs when an object
larger than half a wavelength gets between the source and the target and shadows the target completely from the
source. This will be more of a problem at higher frequencies (microwave) than at lower frequencies (LF, HF, or
VHF).

Skip Interference/Tropo Ducting refers to out-of-area signals that may arrive at levels quite strong compared to
the desired local signal due to refraction from the earth’s ionosphere (HF) or tropospheric ducting (VHF/UHF).
Tropospheric ducting occurs along the boundary between air masses of different temperatures. Consult the
ARRL VHF Manual or RSGB VHF/UHF Manual for more complete descriptions of these propagation modes.

(http://members.surfbest.net/eaglesnest/rfidspct.htm )

315
Realizing the Promise of RFID

is its business rule requirement, designed to please observAtIons And conclusIon

the customers. With a business objective clearly
defined, organizations should then focus their Analysts and end users agree that the required
early pilots on tracking pallets and cases before functions, such as EPC commissioning and central
even thinking of putting a tag on an item. data routing, reader management, data routing,
One of the most popular ways for piloting high-volume data management, advanced integra-
is limiting the magnitude and number of SKUs tion, and filtering, will get easier. Readers and
(stock-keeping units). Unfortunately, a key aspect, related devices will get smarter and smaller, and
the business improvement process—identifying will more easily incorporate RFID or tag data
and mapping out changes that can have dramatic into edge and enterprise systems (ERP [enterprise
improvements—may not always surface or be- resource planning], SCM, and WMS).
come visible in these pilots. Early and/or limited Enterprises will look for more flexible busi-
rollouts will definitely assist with learning how ness processes and evolve beyond the initial static
to use the information within and beyond orga- applications that allowed for RFID entry, integra-
nizational boundaries. tion, and implementation. Natural evolutionary
The pharmaceutical industry has some specific steps will be tools like trading-partner manage-
needs that allow for an easier road map for requirement, process automation, and data management,
ments implementation, but only on a state-by-state which are critical components for developing and
basis. There are certainly state differences, but managing more dynamic composite business
there is an overall robust set of requirements for applications.
product tracking and traceability in CFR 21, as The military’s use of active RFID in their
administered by the FDA. The FDA is often very supply chain in field operations yields some
cautious with respect to new technologies and will ideas for standard commercial use. In one such
likely be quite slow in approving a new RFID implementation, large payloads, such as shipping
standard for product tracking. That said, there is containers, have been outfitted with $70 to $100
a clear mandate in the pharmaceutical industry of large-size active RFID units. With a battery-
for better tracking and supply chain integration powered signal that can be read up to 100 feet,
that will make RFID attractive once some of the the system uses the bin or RFID number to look
challenges are addressed. up the contents of the bin from the central reposi-
The pedigree directive (2129) from the state tory database. In a theatre of operations, quickly
of Florida is an example of a relatively simple assessing which container has the necessary sup-
record-keeping form for shipped drugs. RFID plies and accessing it are critical for supporting
technologies could simplify and improve the pro- the mission. Similarly, as the most critical and
cess and reliability of tracking drug pedigrees by vulnerable parts of supply chains are identified,
providing records of point of origin and destina- both within an enterprise and across enterprises,
tion, which are required to comply with state and RFID will evolve to provide cost savings, robust-
federal laws. Manufacturers are hoping for clearer ness, and operational improvements to current
overall mandates from the FDA that will point the implementations of these vital processes.
way for a consistent approach across all states, There will be an obvious tendency to rely on
rather than requiring manual or semiautomated the large providers and vendors because of their
processes for individual states. knowledge of the Fortune 1000 companies’ busi-
ness and back-end processes. An enterprise-wide

316
Realizing the Promise of RFID

SAP infrastructure will tend to lean toward an tags and the EPC network and as we learn more
SAP RFID extension or an SAP-centric RFID add- about changes in customer behavior patterns.
on. The ongoing investment in and acquisition of The increased visibility potentially offers new
smaller companies in the space are indicative of value-creation opportunities that will leverage
the desire and needs of larger companies to expand targeted marketing and enhance the overall cus-
their skill set in delivering expertise where there tomer experience.
is not enough to go around. Different vendors are The challenge of integrating new technologies
choosing various investment paths and associated with existing business processes, or alternatively
road maps. Microsoft, as one example, is making changing those business processes, will prove
some early attempts to create or forecast the need daunting if not prohibitive to many early adopters
for an RFID services platform that will fit nicely of RFID. As market channels begin to develop,
within their technology stack. BizTalk and .NET including system integrators and enterprise soft-
provide the underlying fundamental components ware vendors who package industry solutions that
while Microsoft Business Solutions provides they can scale and replicate, these challenges will
ancillary components that can be driven through diminish somewhat. In the interim, the big wins
Axapta. Overall, Microsoft hopes to capitalize on with RFID may belong to the disruptors who
the medium-size business entities as they enter learn how to leverage this technology to challenge
the RFID space after the market has matured an industry and its dominant players. Who will
overall and the price points are manageable for emerge as the Southwest Airlines or Amazon.
the second-tier companies. com of the RFID world? This may be the most
The use of RFID information locally or at the interesting development to watch.
edge should provide some real-time operational
efficiency benefits. Limiting certain types of
SKUs to certain dock doors or warehouse loca- reFerences
tions with immediate notification when a rule is
violated will minimize errors in shipping and http://archive.epcglobalinc.org/new_media/bro-
routing. Time intervals for expected reads can chures/Technology_Guide.pdf
also help to qualify when expected shipments
http://archive.epcglobalinc.org/privacy_hearing.
and movements should occur within an internal
asp
supply chain view.
Various tools have already been designed and http://www.electrocom.com.au/rfid_frequency-
other components are evolving that filter, alert, table.htm
and transform RFID data reads to make intelligent
http://members.surfbest.net/eaglesnest/rfidspct.
use of the data for decision choices or controls that
htm
may have previously not been available. Initial
deployments will help to pinpoint best practice http://www.savi.com/rfid.shtml
and future uses of additional information being
http://archive.epcglobalinc.org/publishedre-
collected, as well as how to optimally view, filter,
search/MIT-AUTOID-WH-014.pdf
and act upon these data being made available
on the edge (shop floor, warehouse, distribution ht t p://work i ng k nowle d ge.hbs.e d u /it e m.
center, etc.). jhtml?id=3651&t=dispatch
It will prove interesting as the supply and
demand chain converge with the use of EPC

317
Realizing the Promise of RFID

http://archive.epcglobalinc.org/publishedre- McGinity, M. (2004). RFID: Is this game of tag fair

search/cam-autoid-eb002.pdf play? Communications of the ACM, 47(1), 15.
http://archive.epcglobalinc.org/publishedre- Mitsubishi Materials Corporation selects micro-
search/cam-autoid-eb002.pdf chip technology RFID tagging IC for high-tech
library system. (2003). Assembly Automation,
http://archive.epcglobalinc.org/privacy_hearing.
23(1), 91.
asp
Shutzberg, L. (2004). Early adopters should be
http://cio-asia.com/pcio.nsf/unidlookup/
wary of RFID costs. InformationWeek, 1012,
E519E41C886248256D8300484409?OpenDoc 98.
ument
Sullivan, L. (2004). IBM shares RFID lessons.
http://members.surfbest.net/eaglesnest/rfidspct. InformationWeek, 1011, 64.
htm
Swartz, N. (2004). Tagging toothpaste and tod-
Anonymous. (2003). Swatch group makes Soky- dlers. Information Management Journal, 38(5),
mat an automotive offer it can’t refuse. Frontline 22.
Solutions, 12(2), 13.
Tesoriero, H. W. (2004, November 16). Radio ID
Kärkkäinen, M. (n.d.). RFID in the grocery supply tags will help monitor drug supplies. Wall Street
chain: A remedy for logistics problems or mere Journal, p. D9.
hype? Retrieved from http://www.ecr-academics.
Thomas, V. M. (2003). Product self-management:
org/partnership/pdf/award/Kaerkkaeinen%20-
Evolution in recycling and reuse. Environmental
%20ECR%20Student%20Award%202002%20-
Science & Technology, 37(23), 5297.
%20Bronze.pdf
Wailgum, T. (2004). Tag, you’re late: Why Wal-
Kontnik, L. T., & Dahod, S. (2004). Safe and se-
Mart’s suppliers won’t make the Jan. 1 deadline
cure. Pharmaceutical Executive, 24(9), 58-66.
for RFID tagging. CIO, 18(4), 1.
Lapide, L. (2004). RFID: What’s in it for the
forecaster? The Journal of Business Forecasting
Methods & Systems, 23(2), 16-20.

318

Compilation of References

Acuna, S. T., & Juristo, N. (2005). Software process language for Web services, version 1.1. Retrieved April
modeling: International series in software engineer- 10, 2006, from http://www-128.ibm.com/developer-
ing. Springer. works/library/specification/ws-bpel/

Adhikari, R. (2002a). 10 rules for modeling business Ankolekar, A., Burstein, M., Hobbs, J., Lassila, O.,
processes. DMReview. Retrieved from http://adtmag. Martin, D., McIlraith, S., et al. (2001). DAML-S:
com/article.asp?id=6300 Semantic markup for Web services. Proceedings of
the International Semantic Web Working Symposium
Adhikari, R. (2002b). Putting the business in business
(SWWS), 411-430.
process modeling. DMReview. Retrieved from http://adt-
mag.com/article.asp?id=6323 Anonymous. (2003). Swatch group makes Sokymat an
automotive offer it can’t refuse. Frontline Solutions,
Akkiraju, R., Keskinocak, P., Murthy, S., & Wu, F. (1998).
12(2), 13.
A new decision support system for paper manufacturing.
Sixth International Workshop on Project Management Application servers. (2006). MobileInfo.com. Retrieved
and Scheduling, Istanbul, Turkey. April 17, 2006, from http://www.mobileinfo.com/ap-
plication_servers.htm
Alonso, G., Casati, F., Kuno, H., & Machiraju, V. (2004).
Web services concepts, architectures and applications. Aslan, E. (2002). A COTS-software requirements elicita-
Springer Verlag. tion method from business process models. Unpublished
master’s thesis, Department of Information Systems,
Ambrose, C., & Morello, D. (2004). Designing the agile
Informatics Institute of the Middle East Technical Uni-
organization: Design principles and practices. Gartner
versity, Ankara, Turkey.
Group.
Association for Retail Technology Standards (ARTS).
AMR Research. (2004). ERP market. Retrieved March
(2003). Data model. Retrieved from http://www.nrf-
21, 2005, from http://www.amrresearch.com
arts.org
Andrews, T., Curbera, F., Dholakia, H., Goland, Y., Klein,
J., Leymann, F., et al. (2003). Business process execution

Aust, H. (2003). Einführung von EAI bei der PostFi- ference and working with diversity (pp. 2-37). London:
nance. Proceedings of the St. Galler Anwenderforum, Zed Books Ltd.
St. Gallen, Switzerland.
Berners-Lee, T., Hendler, J., & Lassila, O. (2001). The
Aversano, L., & Canfora, G. (2002). Process and work- semantic Web. Scientific American.
flow management: Introducing eservices in business
Besson, P. (1999). Les ERP a l’epreuve de l’organisaton.
process models. Proceedings of the 14th International
Systemes D’Information et Management, 4(4), 21-52.
Conference on Software Engineering and Knowledge
Engineering. Besson, P., & Rowe, F. (2001). ERP project dynamics
and enacted dialogue: Perceived understanding, per-
Ball, M. O., Ma, M., Raschid, L., & Zhao, Z. (2002).
ceived leeway, and the nature of task-related conflicts.
Supply chain infrastructures: System integration and
The Data Base for Advances in Information Systems,
information sharing. ACM SIGMOD Record, 31(1).
32(4), 47-66.
Basili, V. R., Caldiera, C., & Rombach, H. D. (1994). Goal
Bhabha, H. K. (1986). The other question: Difference,
question metric paradigm. Encyclopaedia of Software
discrimination and the discourse of colonialism. In
Engineering, 1, 528-532.
F. Barker, P. Hulme, M. Iversen, & D. Loxley (Eds.),
Basu, A., & Kumar, A. (2002). Research commentary: Literature, politics and theory (pp. 148-172). Methuen
Workflow management issues in e-business. Information & Co. Ltd.
Systems Research, 13(1).
Bieber, M., Bartolacci, M., Fierrnestad, J., Kurfess, F.,
Bath, U. (2003). Web services als teil einer serviceori- Liu, Q., Nakayama, M., et al. (1997). Electronic enterprise
entierten architektur. Proceedings of the EAI Forum engineering: An outline of an architecture. Proceedings
Schweiz, Regensdorf, Switzerland. of the Workshop on Engineering of Computer-Based
Systems, Princeton, NJ.
Batory, D., & Geraci, B. J. (1997). Composition validation
and subjectivity in GenVoca Generatos. IEEE Transac- Bijker, W. E., & Law, J. (Eds.). (1997). Shaping technol-
tions on Software Engineering, 23(2). ogy/building society: Studies in sociotechnical change
(2nd ed.). Cambridge, MA: The MIT Press.
Baumgarten, U. (2004). Mobile distributed systems.
John Wiley & Sons. Bloomfield, B. P., Coombs, R., Knights, D., & Littler,
D. (Eds.). (1997). Information technology and organi-
Bayer, J. (2004). View-based software documentation. In
zations: Strategies, networks, and integration. Oxford
PhD theses in experimental software engineering (Vol.
University Press.
15). Stuttgart, Germany: Fraunhofer IRB Verlag.
Boag, S., Chamberlin, D., Fernández, M. F., Florescu,
Bayer, J., et al. (2004). Definition of reference architec-
D., Robie, J., & Siméon, J. (2005). XQuery 1.0: An
tures based on existing systems, WP 5.2, lifecycle and
XML query language. W3C candidate recommenda-
process for family integration. Proceedings of the Eureka
tion. Retrieved November 3, 2005, from http://www.
Σ! 2023 Programme, ITEA Project ip02009.
w3.org/TR/2005/CR-xquery-20051103/
Bayer, J., Flege, O., et al. (1999). PuLSE: A methodology
Boar, C. (2003). XML Web services in the organization.
to develop software product lines. Proceedings of the
Microsoft Press.
Fifth ACM SIGSOFT Symposium on Software Reusability
(SSR’99), 122-131. Boehm, B., Abts, C., Brown, A. W., Chulani, S., Clark, B.
K., Horowitz, E., et al. (2000). Software cost estimation
Beall, J. (1997). Valuing difference and working with
with Cocomo II. NJ: Prentice Hall.
diversity. In J. Beall (Ed.), A city for all: Valuing dif-

0
Compilation of References

Booch, G., Rumbaugh, J., & Jacobson, I. (1999). The uni- Capability Maturity Model Integration (CMMI) Product
fied modeling language user guide. Addison Wesley. Team. (2001). CMMI-SE/SW/IPPD, v.1.1. CMMISM for sys-
tems engineering, software engineering, and integrated
Boyer, J., Landwehr, D., Merrick, R., Raman, T. V.,
product and process development: Staged representation
Dubinko, M., & Klotz, L. (2006). XForms 1.0 (2nd ed.).
(Tech. Rep. No. CMU/SEI-2002-TR-004). Carnegie Mel-
W3C recommendation. Retrieved March 14, 2006, from
lon University, Software Engineering Institute.
http://www.w3.org/TR/xforms/
Carlis, J., & Maguire, J. (2000). Mastering data modeling:
BPMI.org releases business process modeling notation
A user driven approach (1st ed.). Addison- Wesley.
(BPMN) version 1.0. (n.d.). Retrieved April 5, 2005, from
http://xml.coverpages.org/ni2003-08-29-a.html Carlson, D. (2001). Modeling XML applications with
UML. Addison-Wesley.
Brehm, L., Heinzl, A., & Markus, L. M. (2001). Tailoring
ERP systems: A spectrum of choices and their implica- Castano, S., et al. (2005). Ontology-based interoperability
tions. Paper presented at the 34th Hawaii Conference on services for semantic collaboration in open networked
Systems Sciences, HI. systems. In D. Konstantas, J.-P. Bourrières, M. Léonard,
& N. Boudjlida (Eds.), Interoperability of enterprise
Brodie, M., & Stonebraker, M. (1995). Migrating legacy
software and applications. Springer-Verlag.
systems. San Francisco: Morgan Kaufmann Publish-
ers. Cavaye, A., & Christiansen, J. (1996). Understanding IS
implementation by estimating power of subunits. Euro-
Brooke, C., & Maguire, S. (1998). Systems development:
pean Journal of Information Systems, 5, 222-232.
A restrictive practice? International Journal of Informa-
tion Management, 18(3), 165-180. Champion, M., Ferris, C., Newcomer, E., & Orchard, D.
(2002). Web services architecture (Working draft). W3C.
Brynjolfsson, E., Yu, H., & Smith, M. D. (2003). Con-
Retrieved from http://www.w3.org/TR/ws-arch/
sumer surplus in the digital economy: Estimating the
value of increased product variety at online booksellers. Chappell, D. A. (2004). Enterprise service bus. Sebas-
Management Science, 49(11), 1580-1596. topol: O’Reilly and Associates, Inc.

Business Process Management Initiative (BPMI). (2004). Charfi, A., & Mezini, M. (2004). Service composition. Hy-
Business process modeling notation (BPMN) specifica- brid Web service composition: Business processes meet
tion (Version 1.0). business rules. Proceedings of the Second International
Conference on Service Oriented Computing.
Business Process Modeling Notation (BPMN). (2004,
May 4). Business process modeling notation (BPMN) Chen, Q., Hsu, M., Dayal, U., & Griss, M. (2000). Multi-
information. Retrieved April 5, 2006, from http://www. agent cooperation, dynamic workflow and XML for e-
bpmn.org commerce automation. Fourth International Conference
on Autonomous Agents.
Cadili, S., & Whitley, E. A. (2005). On the interpre-
tive flexibility of hosted ERP systems (Working Paper Christensen, E., Curbera, F., Meredith, G., & Weer-
Series No. 131). London: Department of Information awarana, S. (2001). Web services description language
Systems, The London School of Economics and Politi- version 1.1 (W3C recommendation). Retrieved April 10,
cal Science. 2006, from http://www.w3.org/TR/wsdl

Callon, M. (1986). Some elements of a sociology of Clark, M., Fletcher, P., Hanson, J. J., Irani, R., & Thelin,
translation: Domestication of the scallops and the fish- J. (2002). Web services business strategies and archi-
ermen of St Brieuc Bay. In J. Law (Ed.), Power, action tectures. Wrox Press.
and belief: A new sociology of knowledge (pp. 196-233).
London: Routledge & Kegan Paul.

Compilation of References

Clements, P., Kazman, R., & Klein, M. (2002). Evaluat- Davenport, T. H., De Long, D. W., & Beers, M. C. (1999).
ing software architectures: Methods and case studies. Successful knowledge management projects. Sloan
Addison-Wesley. Management Review, 39(2), 43-57.

Clemons, E. K., & Row, M. C. (1988). McKesson Drug Dean, M., Hendler, J., Horrocks, I., McGuinness, D., Patel-
Company. A case study of Economist: A strategic in- Schneider, P. F., & Stein, L. A. (2004). Semantic markup
formation system. Journal of Management Information for Web services: OWL-S version 1.1. Retrieved April 10,
Systems, 5(1), 36-50. 2006, from http://www.daml.org/services/owl-s/1.1/

Cockburn, A. (2001). Writing effective use cases. Boston: Delcambre, S. N., & Tanik, M. M. (1998). Using task
Addison-Wesley. system templates to support process description and
evolution. Journal of System Integration, 8, 83-111.
Cockburn, A. (2004). Writing effective use cases. London:
Addison-Wesley Professional. Delphi. (2001). In process: The changing role of busi-
ness process management in today’s economy. Retrieved
Coffman, E. G., & Denning, P. J. (1973). Operating sys-
from http://www.ie.psu.edu/advisoryboards/sse/articles/
tems theory. Englewood Cliffs, NJ: Prentice-Hall.
a4bd42eb1.delphi-ip-oct2001.pdf
Connolly, T., & Begg, C. (2005). Database systems:
Demazeau, Y., & Müller, J.-P. (1989). Decentralized
A practical approach to design, implementation, and
artificial intelligence. Proceedings of the First Euro-
management (4th ed.). Addison-Wesley.
pean Workshop on Modelling Autonomous Agents in a
Cooper, J., & Fisher, M. (2002). Software acquisition Multi-Agent World.
capability maturity model (SA-CMM®) v.1.03 (Tech.
Demirörs, O., & Gencel, Ç. (2004). A comparison of size
Rep. No. CMU/SEI-2002-TR-010). Carnegie Mellon
estimation techniques applied early in the life cycle. In
University, Software Engineering Institute.
Lecture notes in computer science: Vol. Proceedings of
Coulouris, G., Dollimore, J., & Kindberg, T. (2002). the European Software Process Improvement Confer-
Distributed systems: Concepts and design. Addison ence (p. 184). Springer.
Wesley.
Demirörs, O., Demirörs, E., & Tarhan, A. (2001). Manag-
Cummnis, F. A. (2002). Enterprise integration: An ing instructional software acquisition. Software Process
architecture for enterprise application and systems Improvement and Practice Journal, 6, 189-203.
integration. John Wiley & Sons.
Demirörs, O., Demirörs, E., Tanik, M. M., Cooke, D.,
Curtis, B., Kellner, M. I., & Over, J. (1992). Process Gates, A., & Krämer, B. (1996). Languages for the
modeling. Communications of the ACM, 35(9), 75-90. specification of software. Journal of Systems Software,
32, 269-308.
Date, C. J. (2000). What not how: The business rules
approach to application development. Boston: Ad- Demirörs, O., Gencel, Ç., & Tarhan, A. (2003). Utilizing
dison-Wesley. business process models for requirements elicitation. Pro-
ceedings of the 29th Euromicro Conference, 409-412.
Davenport, T. (1993). Process innovation: Reengineering
work through information technology. Ernst & Young. Department of Defense (DoD) Architecture Working
Group. (1997). C4ISR architecture framework, version
Davenport, T. H. (1998). Putting the enterprise into the
2.0.
enterprise system. Harvard Business Review, 121-131.
Department of Defense (DoD) General Services Admin-
Davenport, T. H. (2000). Mission critical: Realizing the
istration. (2001). Federal acquisition regulation.
promise of enterprise systems. Boston: Harvard Busi-
ness School Press.

Compilation of References

Dong, L. (2000). A model for enterprise systems imple- Fowler, M. (n.d.). Patterns in enterprise software. Re-
mentation: Top management influences on implemen- trieved November 2005 from http://www.martinfowler.
tation effectiveness. Paper presented at the Americas com
Conference on Information Systems, Long Beach, CA.
Frankel, D. S. (2003). Model driven architecture: Apply-
Doolin, B. (1999). Sociotechnical networks and informa- ing MDA to enterprise computing. Wiley.
tion management in health care. Accounting, Manage-
Fridgen, M., & Heinrich, B. (2004). Investitionen in die
ment and Information Technology, 9(2), 95-114.
unternehmensweite anwendungssystemintegration: Der
Dumas, A. (2002). Select the best approach for your EAI einfluss der kundenzentrierung auf die gestaltung der
initiative (Sunopsis White Paper). Sunopsis, Inc. anwendungslandschaft (Working paper). Augsburg,
Germany.
Dutton, J. E. (1993). Commonsense approach to process
modeling. IEEE Software, 10(4), 56-64. Friederich, M. (2003). Zusammenspiel verschiedener
integrationstechnologien und werkzeuge bei der Züricher
Endries, T. (2003). Schenker AG: EAI. Proceedings of
Kantonalbank. Proceedings of the EAI Forum Schweiz,
Integration Management Day, St. Gallen, Switzerland.
Regensdorf, Switzerland.
Erl, T. (2004). Service-oriented architecture: A field
Genesereth, M. R. (1997). An agent-based framework
guide to integrating XML and Web services. Upper
for interoperability. In Bradshaw (Ed.), Software agents.
Saddle River, NJ: Prentice Hall Professional Technical
AAAI Press/MIT Press.
Reference.
Georgeff, M., et al. (1999). The belief-desire-intention
Ettlinger, B. (2002, March 5). The future of data model-
model of agency. In J.-p. Müller, M. Singh, & A. S. Rao
ing. DMReview. Retrieved from http://www.dmreview.
(Eds.), Lecture notes in artificial intelligence: Vol. 1555.
com/article_sub.cfm?articleid=4840
Intelligent Agents V. Berlin, Germany: Springer.
Ewalt, D. W. (2002, December 12). BPML promises busi-
Goethals, F., Vandenbulcke, J., Lemahieu, W., Snoeck,
ness revolution. Retrieved from http://www.computing.
M., De Backer, M., & Haesen, R. (2004). Communica-
co.uk/analysis/1137556
tion and enterprise architecture in extended enterprise
Finin, T., et al. (1993). Specification of the KQML agent integration. Proceedings of the Sixth International
communication language: DARPA knowledge sharing Conference on Enterprise Information Systems, Porto,
initiative external interfaces working group. Portugal.

Fischer, L. (Ed.). (2005). Workflow handbook 2005. Gröger, S. (2003). Enterprise application integration in
Lighthouse Point, FL: Future Strategies Inc. the financial services industry. Proceedings of Integration
Management Day, St. Gallen, Switzerland.
Flege, O. (2000). System family architecture description
using the UML (Fraunhofer IESE Report No. 092.00/E). Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J.,
Kaiserslautern, Germany. & Nielsen, H. F. (2003). Simple object access protocol
version 1.2 (W3C recommendation). Retrieved April 10,
Foremski, T. (1998, September 2). Enterprise resource
2006, from http://www.w3.org/TR/soap/
planning: A way to open up new areas of business.
Financial Times, p. 6. Guzmán Ruiz, F. (2001). Mecanismos de comunicación
externa para un sistema integrador de comercio elec-
Foundation for Intelligent Physical Agents (FIPA). (1997).
trónico de negocio a negocio. Unpublished master’s
Agent communication language. In FIPA 97 specification,
thesis, Instituto Tecnológico y de Estudios Superiores
version 2.0. Geneva, Switzerland: Author.
de Monterrey, Monterrey, Nuevo León, Mexico.

Compilation of References

Haas, H., & Brown, A. (2004). Web services glos- IBM. (2006a). Rational unified process (RUP). Retrieved
sary. W3C. Retrieved from http://www.w3.org/TR/ws- from http://www-306.ibm.com/software/awdtools/rup/
gloss/ index.html

Hagel, J., & Brown, J. S. (2001). Your next IT strategy. IBM. (2006b). Web services policy framework (WS-
Harvard Business Review, 79(9), 105-113. Policy). Retrieved from http://www-128.ibm.com/devel-
operworks/library/specification/ws-polfram/
Hagen, C., & Schwinn, A. (2006). Measured integration:
Metriken für die integrationsarchitektur. In J. Schelp & IDC. (2004). Worldwide ERP application market 2004-
R. Winter (Eds.), Integrationsmanagement (pp. 268-292). 2008 forecast: First look at top 10 vendors. Retrieved
Berlin, Germany: Springer. June 9, 2005, from http://www.IDC.com

Hall, S. (Ed.). (1997). Representation: Cultural represen- IEC TC 65/290/DC. (2002). Device profile guideline.
tations and signifying practices. Sage Publications. TC65: Industrial process measurement and control.

Hammer, M., & Champy, J. (2001). Reengineering the IEEE. (1998a). IEEE software engineering standards.
corporation: A manifesto for business revolution. New
IEEE. (1998b). IEEE Std. 1062: IEEE recommended
York: HarperCollins Publishers.
practice for software acquisition. New York.
Harrington, H. J. (1991). Business process improvement:
IEEE. (1998c). IEEE Std. 1220: IEEE standard for ap-
The breakthrough strategy for total quality, productivity,
plication and management of the system engineering
and competitiveness. New York: McGraw-Hill.
process.
Havenstein, H. (2005). Sabre replacing EDI with Web
Inmon, W. H. (2000). A brief history of integration. EAI
services. Computerworld, 39(34), 12.
Journal. Retrieved from http://www.eaijournal.com/ap-
Havey, M. (2005). Essential business process modeling. plicationintegration/BriefHistory.asp
O’Reilly Media Inc.
Intel Corporation. (2006). Intel® mobile application
Hofer, A. (2003). Projekt SBB CUS: EAI ermöglicht architecture guide. Retrieved April 17, 2006, from http://
eine erhöhung der kundeninformations-qualität im www.intel.com/cd/ids/developer/asmo-na/eng/61193.
öffentlichen verkehr. Proceedings of the St. Galler An- htm
wenderforum, St. Gallen, Switzerland.
ISO/IEC. (1991). ISO/IEC 9126: Information technology.
Hohpe, G., & Woolf, B. (2004). Enterprise integration Software product evaluation: Quality characteristics
patterns. Addison-Wesley. and guidelines for their use.

Holland, C. P., Light, B., & Gibson, N. (1999, June). A Jackson, M., & Twaddle, G. (1997). Business process
critical success factors model for enterprise resource implementation: Building workflow systems. Harlow,
planning implementation. Paper presented at the the England: Addison Wesley Longman Limited.
Seventh European Conference on Information Systems,
Jackson, T., Majumdar, R., & Wheat, S. (2005). Ope-
Copenhagen, Denmark.
nEAI methodology, version 1.0. OpenEAI Software
Humphrey, W. S. (1990). Managing the software process. Foundation.
Reading, MA: Addison-Wesley Publishing Company.
Jacobson, I., Booch, G., & Rumbaugh. J. (n.d.). The unified
Iacovou, C. L., Benbasat, I., & Dexter, A. S. (1995). software development process. Addison Wesley.
Electronic data interchange and small organizations:
Jena. (2003). Retrieved April 10, 2006, from http://jena.
Adoption and impact of technology. MIS Quarterly,
sourceforge.net
19(4), 465-485.

Compilation of References

Jennings, N. R. (2001). An agent-based approach for Khan, R. N. (2004). Business process management: A
building complex software systems. Communications practical guide. Tampa, FL: Meghan-Kiffer Press.
of the ACM, 44(4).
Kishore, R., Zhang, H., & Ramesh, R. (in press). Enter-
Jiménez, G. (2003). Configuration wizards and software prise integration using the agent paradigm: Foundations
product lines. Unpublished doctoral dissertation, Instituto of multi-agent-based integrative business information
Tecnológico y de Estudios Superiores de Monterrey, systems. In Decision support systems. Elsevier.
Monterrey, Nuevo León, Mexico.
Klein, H. K., & Myers, M. D. (1998). A set of principles
Juárez Lara, N. (2001). Integración visual de aplicaciones for conducting and evaluating interpretive field studies
en sistemas de comercio electrónico de negocio a negocio. in information systems. Retrieved December 11, 1998,
Unpublished master’s thesis, Instituto Tecnológico y de from http://www.auckland.ac.nz/msis/isworld/mmy-
Estudios Superiores de Monterrey, Monterrey, Nuevo ers/klien-myers.html
León, Mexico.
Klesse, M., Wortmann, F., & Schelp, J. (2005). Erfolgsfak-
Juric, B. M., Mathew, & Sarang, P. (2004). Business toren der applikationsintegration. Wirtschaftsinformatik,
process execution language for Web services BPEL and 47(4), 259-267.
BPEL4WS. Birmingham, UK: Packt Publishing.
Klesse, M., Wortmann, F., & Winter, R. (2005). Success
Kaib, M. (2002). Enterprise application integration: factors of application integration: An exploratory analy-
Grundlagen, integrationsprodukte, anwendungsbei- sis (Working paper). St. Gallen, Switzerland: University
spiele. Wiesbaden, Germany: DUV. of St. Gallen.

Kaplan, B., & Maxwell, J. A. (1994). Qualitative research Knecht, R. (2003). Application architecture framework
methods for evaluating computer information systems. In UBS-WMBB. Proceedings of Integration Management
J. G. Anderson, C. E. Aydin, & S. J. Jay (Eds.), Evaluating Day, St. Gallen, Switzerland.
health care information systems: Methods and applica-
Kontnik, L. T., & Dahod, S. (2004). Safe and secure.
tions (pp. 45-68). Thousand Oaks, CA: Sage.
Pharmaceutical Executive, 24(9), 58-66.
Kärkkäinen, M. (n.d.). RFID in the grocery supply
Krafzig, D., Banke, K., & Slama, D. (2005). Enterprise
chain: A remedy for logistics problems or mere hype?
SOA: Service-oriented architecture best practices. Upper
Retrieved from http://www.ecr-academics.org/partner-
Saddle River, NJ: Prentice Hall Professional Technical
ship/pdf/award/Kaerkkaeinen%20-%20ECR%20Stude
Reference.
nt%20Award%202002%20-%20Bronze.pdf
Krallmann, H. (2003). Transformation einer industriell
Kavantzas, N., Burdett, D., Ritzinger, G., & Lafon, Y.
geprägten unternehmensstruktur zur einer service-ori-
(2004). Web services choreography description language
entierten organisation. Proceedings des Symposiums des
(WS-CDL) version 1.0. Retrieved April 10, 2006, from
Instituts für Wirtschaftsinformatik “Herausforderungen
http://www.w3.org/TR/2004/WE-ws-cdl-10-20041217/
der Wirtschaftsinformatik in der Informationsgesell-
Kay, E. (1996, February 15). Desperately seeking SAP schaft” (pp. 1-12).
support. Datamation, pp. 42-45.
Krcmar, H. (1990). Bedeutung und ziele von informati-
Keller, W. (2002). Enterprise application integration. onssystemarchitekturen. Wirtschaftsinformatik, 32(5),
Dpunkt Verlag. 395-402.

Kerner, L. (2000). Biometrics and time & attendance. Kreger, H. (2001). Web services conceptual architecture.
Integrated Solutions. Retrieved from http://www.inte- IBM Software Group. Retrieved from http://www-106.
gratedsolutionsmag.com/Articles/2000_11/001109.htm ibm.com/developerworks

Compilation of References

Kruchten, P. B. (1995). The 4+1 view model of architec- Lawrence, C. P. (2005). Make work make sense: An in-
ture. IEEE Software, 12(6), 42-50. troduction to business process architecture. Cape Town,
South Africa: Future Managers (Pty) Ltd.
Krumbholz, M., Galliers, J., Coulianos, N., & Maiden, N.
A. M. (2000). Implementing enterprise resource planning Lee, V., Schell, R., & Scheneider, H. (2004). Mobile
packages in different corporate and national cultures. applications: Architecture, design, and development.
Journal of Information Technology, 15, 267-279. Hewlett-Packard Professional Books.

Kuster, S., & Schneider, M. (2003). Banking bus EAI- Leymann, F., Roller, D., & Schmidt, M.-T. (2002). Web
plattform der raiffeisengruppe schweiz. Proceedings of services and business process management. IBM Systems
Integration Management Day, St. Gallen, Switzerland. Journal, 41(2), 198-211.

Laguna, M., & Marklund, J. (2004). Business process Linthicum, D. (2001). B2B application integration.
modeling, simulation, and design. Prentice Hall. Reading, MA: Addison Wesley.

Laitenberger, O. (2000). Cost-effective detection of soft- Linthicum, D. S. (2000). Enterprise application integra-
ware defects through perspective-based inspections. In tion. Reading, MA: Addison-Wesley.
PhD theses in experimental software engineering (Vol.
Linthicum, D. S. (2003). Next generation application
1). Stuttgart, Germany: Fraunhofer IRB Verlag
integration: From simple information to Web services.
Lam, W. (2005). Exploring success factors in enterprise Addison-Wesley Information Technology Series.
application integration: A case-driven analysis. European
Linthicum, D.S (2003b). Where enterprise application
Journal of Information Systems, 14(2), 175-187.
integration fits with Web services. Software Maga-
Lam, W., & Shankararaman, V. (2004). An enterprise zine. Retrieved from http://www.softwaremag.com/
integration methodology. IT Pro. L.cfm?Doc=2003-April/WebServices

Lapide, L. (2004). RFID: What’s in it for the forecaster? Liske, C. (2003). Advanced supply chain collaboration
The Journal of Business Forecasting Methods & Systems, enabled bei EAI. Proceedings of the St. Galler Anwender-
23(2), 16-20. forum, St. Gallen, Switzerland.

Latour, B. (1987). Science in action: How to follow sci- Longueuil, D. (2003). Wireless messaging demystified:
entists and engineers through society. Cambridge, MA: SMS, EMS, MMS, IM, and others. McGraw-Hill.
Harvard University Press.
Madachy, R. J., & Boehm, B. W. (2006). Software process
Latour, B. (1988). The pasteurization of France (A. modeling with system dynamics. Wiley-IEEE Press.
Sheridan & J. Law, Trans.). Harvard University Press.
Malhotra, Y. (1996). Enterprise architecture: An over-
Latour, B. (1991). Technology is society made durable. view. @BRINT Research Institute. Retrieved from
In J. Law (Ed.), Sociology of monsters: Essays on power, http://www.brint.com/papers/enterarch.htm
technology and domination (pp. 103-131). London:
Mallick, M. (2003). Mobile and wireless design essentials.
Routledge.
Wiley Publishing Inc.
Latour, B. (1999). Pandora’s Hope: Essays on the reality
Mandell, D., & McIlraith, S. (2003). Adapting BPEL4WS
of science studies. Cambridge, MA: Harvard University
for the semantic Web: The bottom-up approach to Web
Press.
service interoperation. Proceedings of the 2nd Interna-
Law, J. (1992). Notes on the theory of the actor-network: tional Semantic Web Conference (ISWC2003).
Ordering, strategy, and heterogeneity. Systems Practice,
5(4), 379-393.

Compilation of References

Mangan, P., & Sadiq, S. (2002). On building workflow McDavid, D. W. (1999). A standard for business architec-
models for flexible processes. Australian Computer Sci- ture description. IBM Systems Journal, 38(1), 12-31.
ence Communications, Proceedings of the Thirteenth
McGinity, M. (2004). RFID: Is this game of tag fair play?
Australasian Conference on Database Technologies,
Communications of the ACM, 47(1), 15.
24(2).
McIlraith, S., & Son, T. C. (2002). Adapting Golog for
Manzer, A. (2002, June). Towards formal foundations for
composition of semantic Web services. Proceedings
value-added chains through core-competency integration
of the Eighth International Conference on Knowledge
over Internet. The Sixth World Conference on Integrated
Representation and Reasoning (KR2002), 482-493.
Design and Process Technology.
McIlraith, S., Son, T. C., & Zeng, H. (2001). Semantic
Manzer, A., & Dogru, A. (2002, April). Formal modeling
Web services. IEEE Intelligent Systems, 16(2), 46-53.
for the composition of virtual enterprises. Proceedings
of IEEE TC-ECBS & IFIP WG10.1, International Con- McKeen, J. D., & Smith, H. A. (2002). New develop-
ference on Engineering of Computer-Based Systems, ments in practice II: Enterprise application integration.
Lund, Sweden. Communications of the Association for Information
Systems, 8, 451-466.
Markus, M. L. (1983). Power, politics and MIS implemen-
tation. Communication of the ACM, 26(6), 430-444. Meadows, B., & Seaburg, L. (2004, September 15).
Universal business language 1.0. OASIS. Retrieved
Markus, M. L., & Tanis, C. (2000). The enterprise system
February 14, 2006, from http://docs.oasis-open.org/ubl/
experience: From adoption to success. In R. W. Zmud
cd-UBL-1.0/
(Ed.), Framing the domains of IT research: Glimpsing
the future through the past. Cincinnati, OH: Pinnaflex Medjahed, B., Benatallah, B., Bouguettaya, A., Ngu, A.
Educational Resources, Inc. H., & Elmagarmid, A. K. (2003). Business-to-business
interactions: Issues and enabling technologies. The Inter-
Markus, M. L., Axline, S., Petrie, D., & Tanis, C. (2000).
national Journal on Very Large Data Bases, 12(1).
Learning from adopters’ experiences with ERP: Problems
encountered and success achieved. Journal of Informa- Mendel, B. (1999). Overcoming ERP projects hurdles.
tion Technology, 15, 245-265. InfoWorld, 21(29).

Markus, M. L., Tanis, C., & Fenema, P. C. v. (2000). Mitra, N. (2003, June 24). SOAP version 1.2 part 0:
Multisite ERP implementations. Communications of the Primer. W3C. Retrieved June 10, 2004, from http://www.
ACM, 43(4), 42-46. w3.org/TR/2003/REC-soap12-part0-20030624/

Martin, R., & Robertson, E. (2000). A formal enterprise Mitsubishi Materials Corporation selects microchip
architecture framework to support multi-model analysis. technology RFID tagging IC for high-tech library system.
Proceedings of the Fifth CAiSE/IFIP8.1 International (2003). Assembly Automation, 23(1), 91.
Workshop on Evaluation of Modeling Methods in Systems
Molina, A., Mejía, R., Galeano, N., & Velandia, M.
Analysis and Design, Stockholm, Sweden.
(2006). The broker as an enabling strategy to achieve
Martin, W. (2005). Business integration 2005: Status smart organizations. In Integration of ICT in smart
quo and trends. Proceedings of EAI Competence Days organizations. Idea Group Publishing.
Road Show.
Moll, T. (2003). Firmenübergreifendes EAI-netzwerk:
McAfee, A. (2005). Will Web services really transform Integrierte umsetzung von geschäftsprozessen über ei-
collaboration? MIT Sloan Management Review, 46(2), nen marktplatz als EAI-hub. Proceedings of Integration
78-84. Management Day, St. Gallen, Switzerland.

Compilation of References

Monteiro, E. (2000a). Actor-network theory and in- Osman, T., Wagealla, W., & Bargiela, A. (2004). An
formation infrastructure. In C. U. a. o. Ciborra (Ed.), approach to rollback recovery of collaborating mobile
From control to drift (pp. 71-83). New York: Oxford agents. IEEE Transactions on Systems, Man, and Cy-
University Press. bernetics, 34, 48-57.

Monteiro, E. (2000b). Monsters: From systems to actor- Österle, H., Brenner, W., & Hilbers, K. (1992). Unterneh-
networks. In K. Braa, C. Sorensen, & B. Dahlbom (Eds.), mensführung und informationssystem: Der ansatz des
Planet Internet. Lund, Sweden: Studentlitteratur. St. Galler informationssystem-managements. Stuttgart,
Germany: Teubner.
Murphy, G., & Notkin, D. (1995). Software reflexion
models: Bridging the gap between source and high-level Pande, P. S., Neuman, R. P., & Cavanagh, R. R. (2000).
models. Proceedings of the Third Symposium on the The six sigma way: How GE, Motorola, and other top
Foundations of Software Engineering (FSE3). companies are honing their performance. New York:
Graw-Hill.
Nau, D. S., Cao, Y., Lotem, A., & Muñoz-Avila, H. (1999).
SHOP: Simple hierarchical ordered planner. Proceed- Papazoglou, M. P. (2003). Service-oriented computing:
ings of the International Joint Conference on Artificial Concepts, characteristics and directions. Proceedings of
Intelligence (IJCAI-99), 968-973. the Fourth International Conference on Web Information
Systems Engineering (WISE 2003), 3-12.
Norris, G. (1998). SAP: An executive’s comprehensive
guide. New York: J. Wiley. Pechoucek, M., Vokrinek, J., & Becvar, P. (2005). Ex-
PlanTech: Multiagent support for manufacturing decision
O’Riordan, D. (2002). Business process standards for
making. IEEE Intelligent Systems, 20(1).
Web services. Web Services Architect. http://www.
webservicesarchitect.com. Pellet. (2004). Retrieved April 10, 2006, from http://www.
minswap.org/2003/pellet/
Object Management Group (OMG). (2007). Unified
modeling language (UML). Retrieved from http://www. Process Family Engineering in Service-Oriented Ap-
uml.org/ plications (PESOA). (n.d.). Retrieved November 2005
from http://www.pesoa.org
Oracle BPEL PM. (2005). Retrieved April 10, 2006,
from http://www.oracle.com/technology/products/ias/ PuLSE™. (n.d.). Retrieved November 2005 from http://
bpel/index.html www.iese.fhg.de/pulse

Organization for the Advancement of Structured Infor- Quattrone, P., & Hopper, T. (2005). A “time-space odys-
mation Standards (OASIS). (n.d.). Universal description, sey”: Management control systems in two multinational
discovery and integration (UDDI). Retrieved from organisations. Accounting, Organizations & Society,
http://www.uddi.org/ 30(7/8), 735-764.

Organization for the Advancement of Structured Informa- Reingruber, M. C., & Gregory, W. W. (1994). The data
tion Standards (OASIS). (2006). Web services security modeling handbook: A best practice approach to build-
(WS-Security). Retrieved from http://www.oasis-open. ing quality data models. Wiley & Sons.
org/committees/tc_cat.php?cat=security
Ross, J. W., & Vitale, M. R. (2000). The ERP revolution:
Orlikowski, W. J., & Baroudi, J. J. (1991). Studying Surviving vs. thriving. Information Systems Frontiers,
information technology in organizations: Research 2(2), 233-241.
approaches and assumptions. Information Systems Ross, R. G. (2003). Principles of the business rule
Research, 2(1), 1-28. approach. Boston: Addison-Wesley.

Compilation of References

Ruh, W. A., Maginnis, F. X., & Brown, W. J. (2001). Sharif, A. M., Elliman, T., Love, P. E. D., & Badii, A.
Enterprise application integration. New York: John (2004). Integrating the IS with the enterprise: Key EAI
Wiley & Sons Inc. research challenges. The Journal of Enterprise Informa-
tion Management, 17(2), 164-170.
Sadiq, S., Orlowska, M., Sadiq, W., & Foulger, C. (2004).
Data flow and validation in workflow modeling. Pro- Sharp, A., & Mcdermott, P. (2001). Workflow modeling:
ceedings of the Fifteenth Conference on Australasian Tools for process improvement and application develop-
Database, 27. ment. Norwood, MA: Artech House.

Sambamurthy, V., Bharadwaj, A., & Grover, V. (2003). Shegalov, G., Gillmann, M., & Weikum, M. (2001). XML-
Shaping agility through digital options: Reconceptual- enabled workflow management for e-services across
izing the role of information technology in contemporary heterogeneous platforms. The VLDB Journal: The Inter-
firms. MIS Quarterly, 27(2), 237-263. national Journal on Very Large Data Bases, 10(1).

SAP AG. (2004). SAP annual report 2004. Author. Shutzberg, L. (2004). Early adopters should be wary of
RFID costs. InformationWeek, 1012, 98.
SAP’s rising in New York. (1998, August 1). The
Economist. Siau, K., & Tian, Y. (2004). Supply chains integration:
Architecture and enabling technologies.
Sauter, J. A., & Van Dyke Parunak, H. (1999). ANTS in
the supply chain. Workshop on Agent Based Decision Siegal, J. (2002). Mobile: The art of portable architecture.
Support for Managing the Internet-Enabled Supply Chain, Princeton Architectural Press.
Agents 99, Seattle, WA.
Simsion, G. (2000). Data modeling essentials: A compre-
Sawhney, M. (2001). Don’t homogenize, synchronize. hensive guide to data analysis, design, and innovation
Harvard Business Review. (2nd ed.). Coriolis Group Books.

Sawyer, S. (2001a). Effects of intra-group conflict on Singh, M. P., & Huhns, M. N. (2005). Service-oriented
packaged software development team performance. computing: Semantics, processes, agents. John Wiley
Information Systems Journal, 11, 155-178. & Sons.

Sawyer, S. (2001b). Socio-technical structures in enter- Sirin, E., Hendler, J., & Parsia, B. (2003). Semi-automatic
prise information systems implementation: Evidence composition of Web services using semantic descriptions.
from a five year study. Paper presented at the IEEE EMS Web Services: Modeling, Architecture and Infrastructure
International Engineering Management Conference, Workshop in ICEIS.
Albany, NY.
Smith, H. (2003, September 22). Business process
Scheer, A. G. (2003). ARIS toolset, version 6.2. management 101. Retrieved from http://www.ebizq.
net/topics/bpm/features/2830.html
Scheer, A. W. (Ed.). (1994). Business process engineer-
ing: Reference models for industrial enterprises. Berlin, Smith, H., & Fingar, P. (2003a). Business process man-
Germany: Springer. agement (BPM): The third wave (1st ed.). Meghan-Kiffer
Press.
Schiller, J. (2000). Mobile communications. Addison
Wesley. Smith, H., & Fingar, P. (2003b). Workflow is just a pi
process. Retrieved from http://www.fairdene.com/pical-
Schmidt, J. G. (2002). Transforming EAI from art to
culus/workflow-is-just-a-pi-process.pdf
science. EAI Journal.
Smith, H., & Fingar, P. (2004, February 1). BPM is not
about people, culture and change: It’s about technology.

Compilation of References

Retrieved from http://www.avoka.com/bpm/bpm_ar- Themistocleous, M., & Irani, Z. (2001). Benchmarking the
ticles_dynamic.shtml benefits and barriers of application integration. Journal
of Benchmarking, 8(4), 317-331.
Smith, R. G. (1980). The contract net protocol. IEEE
Transactions on Computers, C29(12). Themistocleous, M., & Irani, Z. (2003). Towards a
novel framework for the assessment of enterprise ap-
Software inspektion. (n.d.). Retrieved March 2006 from
plication integration packages. Proceedings of the 36th
http://www.software-kompetenz.de
Hawaii International Conference on System Sciences
Su, O. (2004). Business process modeling based comput- (HICSS’03).
er-aided software functional requirements generation.
Themistocleous, M., Irani, Z., & O’Keefe, R. M. (2001).
Unpublished master’s thesis, Department of Informa-
ERP and application integration: Exploratory survey.
tion Systems, Informatics Institute of the Middle East
Business Process Management Journal, 7(3), 195-204.
Technical University, Ankara, Turkey.
Thomas, M., Redmond, R., Yoon, V., & Singh, R. (2005).
Sullivan, L. (2004). IBM shares RFID lessons. Informa-
A semantic approach to monitor business process per-
tionWeek, 1011, 64.
formance. Communications of the ACM, 48(12).
Swanson, E. B., & Ramiller, N. C. (2004). Innovating
Thomas, V. M. (2003). Product self-management: Evolu-
mindfully with information technology. MIS Quarterly,
tion in recycling and reuse. Environmental Science &
28(4), 553-583.
Technology, 37(23), 5297.
Swartz, N. (2004). Tagging toothpaste and toddlers.
Torchiano, M., & Bruno, G. (2003). Article abstracts
Information Management Journal, 38(5), 22.
with full text online: Enterprise modeling by means of
Tanik, U. (2001). A framework for Internet enterprise en- UML instance models. ACM Sigsoft Software Engineer-
gineering based on t-strategy under zero-time operations. ing Notes, 28(2).
Unpublished master’s thesis, Department of Electrical
Traverso, P., & Pistore, M. (2004). Automated composi-
Engineering, University of Alabama at Birmingham.
tion of semantic Web services into executable processes.
Teo, H. H., Wei, K. K., & Benbasat, I. (2003). Predict- Proceedings of Third International Semantic Web Con-
ing intention to adopt interorganizational linkages: An ference (ISWC2004) (pp. 380-394).
institutional perspective. MIS Quarterly, 27(1), 19-49.
United Kingdom Software Metrics Association (UKS-
Tesoriero, H. W. (2004, November 16). Radio ID tags will MA). (1998). MkII function point analysis counting
help monitor drug supplies. Wall Street Journal, p. D9. practices manual, v.1.3.1.

Thakker, D., Osman, T., & Al-Dabass, D. (2005). Web Van der Aalst, W. M. P., Dumas, M., ter Hofstede, A. H.
services composition: A pragmatic view of the present M., & Wohed, P. (2002). Pattern-based analysis of BPML
and the future. Nineteenth European Conference on (and WSCI) (Tech. Rep. No. FIT-TR-2002-05). Brisbane,
Modelling and Simulation: Vol. 1. Simulation in wider Australia: Queensland University of Technology.
Europe, 826-832.
Van Dyke Parunak, H. (1999). Industrial and practical
The European enterprise application integration market. applications of DAI. In G. Weiss (Ed.), Multi-agent
(2001). Frost & Sullivan Studies. systems. Cambridge, MA: MIT Press.

The Standish Group. (1994). CHAOS report. Retrieved Vinoski, S. (2002). Middleware “dark matter.” IEEE Dis-
from http://www.standishgroup.com/sample_research/ tributed Systems Online. Retrieved from http://dsonline.
chaos_1994_1.php computer.org/0210/d/wp5midd.html

0
Compilation of References

Wailgum, T. (2004). Tag, you’re late: Why Wal-Mart’s Winter, R. (2003a). An architecture model for supporting
suppliers won’t make the Jan. 1 deadline for RFID tag- application integration decisions. Proceedings of 11th
ging. CIO, 18(4), 1. European Conference on Information Systems (ECIS),
Naples, Italy.
Walker, S. S., Brennan, R. W., & Norrie, D. H. (2005).
Holonic job shop scheduling using a multiagent system. Winter, R. (2003b). Modelle, techniken und werkzeuge
IEEE Intelligent Systems, 20(1). im business engineering. In H. Österle & R. Winter
(Eds.), Business engineering: Auf dem weg zum unter-
Walsham, G. (1995). The emergence of interpretivism
nehmen des informationszeitalters (pp. 87-118). Berlin,
in IS research. Information Systems Research, 6(4),
Germany: Springer.
376-394.
Winter, R. (2006). Ein modell zur visualisierung der
Walsham, G. (2001). Making a world of difference: IT
anwendungslandschaft als grundlage der informations-
in a global context. John Wiley & Sons Ltd.
system-architekturplanung. In J. Schelp & R. Winter
Ward, J., & Peppard, J. (1996). Reconciling the IT/ (Eds.), Integrationsmanagement (pp. 1-29). Berlin,
business relationship: A troubled marriage in need of Germany: Springer.
guidance. Journal of Strategic Information Systems,
Wohed, P., et al. (2003, April). Pattern based analysis
5, 37-65.
of EAI languages: The case of the business modeling
Weske, M., Goesmann, T., Holten, R., & Striemer, R. language. Proceedings of the International Conference
(1999). A reference model for workflow application on Enterprise Information Systems (ICEIS), Angers,
development processes. ACM Sigsoft Software Engi- France.
neering Notes, Proceedings of the International Joint
Wooldridge, M. (2002). An introduction to multiagent
Conference on Work Activities Coordination and Col-
systems. John Wiley & Sons.
laboration, 24(2).
World Wide Web Consortium (W3C) Semantic Web
Whalen, M. W., & Heimdahl, M. P. E. (1999). On the
Services Interest Group. (2006a). Semantic Web ser-
requirements of high-integrity code generation. High-As-
vices framework (SWSF). Retrieved from http://www.
surance Systems Engineering: Proceedings of the Fourth
w3.org/Submission/2004/07/
IEEE International Symposium, 217-224.
World Wide Web Consortium (W3C) Semantic Web
White, P., & Grundy, J. (2001). Experiences developing
Services Interest Group. (2006b). Web ontology lan-
a collaborative travel planning application with .NET
guage for services (OWL-S). Retrieved from http://www.
Web services. Proceedings of the 2003 International
w3.org/Submission/2004/07/
Conference on Web Services (ICWS).
World Wide Web Consortium (W3C) Semantic Web
Wiegers, K. E. (1999). Software requirements. Microsoft
Services Interest Group. (2006c). Web services modeling
Press.
ontology (WSMO). Retrieved from http://www.w3.org/
Wigand, R. T., Steinfield, C. W., & Markus, M. L. (2005). Submission/2005/06/
Information technology standards choices and industry
World Wide Web Consortium (W3C) Semantic Web
structure outcomes: The case of the U.S. home mortgage
Services Interest Group. (2006d). Web services semantic
industry. Journal of Management Information Systems,
(WSDL-S). Retrieved from http://www.w3.org/Submis-
22(2), 165-191.
sion/2005/10/
Wing, L., & Shankararaman, V. (2004). An enterprise
World Wide Web Consortium (W3C) Web Services
integration methodology. IT Professional, 6(2), 40-48.
Addressing Working Group. (n.d.). Web services ad-

Compilation of References

dressing (WS-Addressing). Retrieved from http://www. Yoo, M.-J., Sangwan, R., & Qiu, R. (2005). Enterprise
w3.org/Submission/ws-addressing/ integration: Methods and technologies. In P. Laplante &
T. Costello (Eds.), CIO wisdom II: More best practices.
World Wide Web Consortium (W3C) Web Services
Prentice-Hall.
Description Working Group. (2006). Web services de-
scription language (WSDL). Retrieved from http://www. Youngs, R., Redmond-Pyle, D., Spass, P., & Kahan, E.
w3.org/2002/ws/desc/ (1999). A standard for architecture description. IBM
Systems Journal, 38(1), 32-50.
World Wide Web Consortium (W3C). (2005). Extensible
markup language (XML) activity statement. Retrieved Yourdon, E. (2000). Managing software requirements.
Addison Wesley Publishing Company.
March 10, 2006, from http://www.w3.org/XML/Activ-
Zachman, J. A. (1987). A framework for information
ity.html
systems architecture. IBM Systems Journal, 26(3),
World Wide Web Consortium Extensible Markup Lan- 276-292.
guage (W3C XML) Protocol Working Group. (2006).
Zachman, J. A. (2001). You can’t “cost-justify” archi-
Simple object access protocol (SIAP). Retrieved from
tecture. DataToKnowledge Newsletter (Business Rule
http://www.w3.org/2000/xp/Group/
Solutions LLC), 29, 3.
Wu, D., Parsia, B., Sirin, E., Hendler, J., & Nau, D. (2003).
Zahavi, R. (2000). Enterprise application integration
Automating DAML-S Web services composition using
with CORBA. New York: John Wiley & Sons.
SHOP2. Proceedings of 2nd International Semantic Web
Conference (ISWC2003). Zambonelli, F., Jennings, N. R., & Wooldridge, M. (2000).
Organizational abstractions for the analysis and design
Xia, W., & Lee, G. (2004). Grasping the complexity of
of multi-agent systems. In Lecture notes in computer sci-
IS development projects. Communications of the ACM,
ence: Vol. 1957. First International Workshop on Agent-
47(5), 95-74.
Oriented Software Engineering. Springer-Verlag.
Yoo, M.-J. (2004, October). Enterprise application
integration and agent-oriented software integration.
IEEE International Conference on Systems, Man, and
Cybernetics, The Hague, Netherlands.

About the Contributors

Wing Lam is an associate professor at Universitas 21 Global, a leading online graduate school, where
he is also program director for the master’s in management in information technology. In addition to
academic positions in universities in Singapore and the United Kingdom, Dr. Lam has held consultancy
positions with Logica-CMG, ICL (now Fujitsu), and Accenture. His current research interests include
enterprise integration, knowledge management, and software engineering management. Dr. Lam has
over 80 publications in peer-reviewed journals and conference proceedings, and currently serves on the
editorial boards of several journals.

Venky Shankararaman is a practice associate professor at the School of Information Systems,

Singapore Management University, Singapore. His current areas of specialization include enterprise
architecture, enterprise integration, service-oriented architecture, and business-process management. He
has over 14 years of experience in the IT industry in various capacities as a researcher, academic faculty
member, and industry consultant. Shankararaman has designed and delivered professional courses for
governments and industries in areas such as enterprise architecture, technical architecture, enterprise
integration, and business-process management. He also worked as a faculty member at several universi-
ties in the United Kingdom and Singapore, where he was actively involved in teaching and research in
the areas of intelligent systems and distributed systems. He has published over 50 papers in academic
journals and conferences.

***

David Al-Dabass holds the chair of intelligent systems in the School of Computing and Informatics,
Nottingham Trent University, UK. His research work explores algorithms and architecture for machine
intelligence.

Antonio de Amescua-Seco holds a BS in computer science and a PhD in computer science from the
Polytechnic University of Madrid. He has been a full professor in the Department of Computer Science

at the Carlos III Technical University of Madrid since 1991. Previously, he worked as a researcher at
the Polytechnic University of Madrid from 1983 to 1991. He has also been working as a software en-
gineer for the public company Iberia Airlines, and as a software engineering consultant for the private
company Novotec Consultores. Amescua-Seco’s research in new software engineering methods has
appeared in published papers and conferences. He was the research project leader for the development
of the Information System Development Methodology for the Spanish Administration and participated
in other projects sponsored by the European Union.

Michalis Anastasopoulos is a member of the Department of Product Line Architectures at the

Fraunhofer Institute for Experimental Software Engineering (IESE). Since 2000, he has been involved
in technology transfer projects in the fields of product line architectures and implementation, as well as
configuration and variability management. He received a diploma in mathematics from the University
of Patras, Greece, and in software engineering from the Technical University of Dresden.

Zachary Bylin received his AA degree the same day he graduated from Auburn High School. He
then received his BS degree at the University of Washington, Tacoma (UWT), just 2 years later in 2003.
He received his master’s degree in computer software systems on his 21st birthday from the University of
Washington, Tacoma, in June of 2004. He then went on to work for the Boeing Company as a software
engineer until he passed away at the age of 22 on July 3, 2005, in Brewster, Washington. Mr. Bylin was
an excellent student and software developer while he was working with Dr. Chung’s Intelligent Service
Oriented Computing Research Group.

Brian H. Cameron is an assistant professor of information sciences and technology at The Penn-
sylvania State University. Prior to joining Penn State, he was director of information technology for
WorldStor, Inc., a storage service provider (SSP) in Fairfax, Virginia. He has also held a variety of
technical and managerial positions within IBM and Penn State. His primary research and consulting
interests include enterprise systems integration, storage networking, emerging wireless technologies,
and the use of simulations and gaming in education. He has designed and taught a variety of courses
on topics that include networking, systems integration, storage networking, project management, and
IT consulting.

Sam Chung currently teaches at the Institute of Technology. Prior to joining the UWT faculty, he
taught at Pacific Lutheran University and the University of Texas of the Permian Basin. His main re-
search interests are in intelligent service-oriented computing.

Andrew P. Ciganek is approaching the final stages of his PhD program at the University of Wis-
consin, Milwaukee. His research focus is on the adoption, diffusion, and implementation of service-
oriented architectures (SOAs) and other Net-enabling initiatives, mobile computing devices, knowledge
management systems, and the role that the social context of an organization has in information systems
research. He has published works in a number of refereed conference proceedings and has manuscripts
under various stages of review with scholarly IS journals.

Dave Clarke is a senior executive with more than 20 years of experience in information technology,
manufacturing, product development, emergency management, and strategic planning. He has exper-

About the Contributors

tise in several industries, including pharmaceutics, automotives, chemicals, biotechnology, electronics,

information technology, consumer products, and nonprofit. Prior to joining Tatum, Mr. Clarke served
as CTO of the American Red Cross and CIO (chief information officer) for multiple business units at
General Motors, where he propelled GM to a world leadership position in the use of high-performance
computing for product engineering and created the governance framework for GM North America’s $1
billion annual outsourcing deal with EDS. He was the first-ever CIO and chief knowledge officer for W.
L. Gore & Associates and was instrumental in developing a knowledge- and technology-based product
development strategy that doubled corporate revenues in just 3 years. Mr. Clarke was also a consultant
and project manager with IBM. He has published articles in CIO and Computerworld, and his work has
been featured in CIO, Computerworld, Forbes, and Fast Company. He is a recognized thought leader
on collaboration, knowledge management, vendor management, innovation, and project management.
Mr. Clarke is an adjunct professor of organizational development and knowledge management at the
George Mason University School of Public Policy and has also lectured at the University of Virginia.
He is president of the Washington Area CTO Roundtable and serves on the advisory boards of several
organizations. Mr. Clarke earned his BS in electrical engineering from the University of Kentucky and
his MS in computer science from The Johns Hopkins University.

Sergio Davalos currently teaches at the Milgard School of Business. Prior to joining the UWT fac-
ulty, he taught at Portland State University, the University of the Virgin Islands, and the University of
Portland. His main research interests are in the organization and management of information systems
and the application of machine learning and evolutionary computing.

Onur Demirörs is an associate professor and the chair of the Department of Information Systems at
the Middle East Technical University (METU). He is also the strategy director of Bilgi Grubu Ltd. He
holds a PhD in computer science from Southern Methodist University (SMU). He has been working in
the domain of software engineering as a consultant, academician, and researcher for the last 15 years.
His work focuses on software process improvement, software project management, software engineer-
ing education, software engineering standards, and organizational change management.

Ali H. Dogru is an associate professor of computer engineering at METU. His current research is
mostly in the component orientation area. He took part in large-scale software development projects
and technological training for engineering organizations in different countries. Dr. Dogru obtained his
BS and MS in electrical engineering from the Istanbul Technical University and from the University of
Texas at Arlington, and his PhD in computer science from SMU in 1992.

Randall E. Duran is the CEO (chief executive officer) of Catena Technologies Pte Ltd., a consulting
firm geared toward business-process automation and enterprise integration architectures. Over the past
15 years, Duran has worked with financial institutions in the United States, Europe, Asia, Australia, and
Africa, designing and implementing enterprise solutions. Prior to founding Catena Technologies, he led
solution consulting at TIBCO Finance Technology Inc. and Reuters PLC. Duran was been awarded BS
and MS degrees by the Massachusetts Institute of Technology (MIT) in computer science.

Amany R. Elbanna is an associate research fellow in the Department of Information Systems, The
London School of Economics. She holds a PhD in information systems from The London School of Eco-

About the Contributors

nomics in addition to an MBA and MS in the analysis, design, and management of information systems.
She has conducted research on the implementation of enterprise resource planning (ERP) systems and
presented her work at several conferences including ECIS, IFIP 8.6, and Bled. Her research interests
include the interaction between technology and organizations, the management of large IS projects, and
the management of change associated with the adoption and appropriation of ICT.

Javier M. Espadas-Pech is a postgraduate student and research assistant in information technology

at the Instituto Tecnológico y de Estudios Superiores de Monterrey (ITESM) in Monterrey, Nuevo León,
México. He is also the project technical leader of the electronic services platform. His current interests
are software architectures, service-oriented architectures, and application integration technologies.

Javier García-Guzmán received an engineering degree and PhD in computer science at Carlos III
University of Madrid. He has 7 years of experience as a software engineer and consultant in public and
private companies. He has participated in numerous research projects, financed with public (European
and national) and private funds, in relation to software process improvement and its integration with
organizational business processes. García-Guzmán has published books and international scientific
papers related to software engineering and collaborative working environments. His research interests
are collaborative working environments, the formal measurement of processes improvement, software
process maturity assessments, software capacity rapid audits, and knowledge management related to
process improvement, software engineering, and systems integration. He belongs to the Collaborative
Working Environments Expert Group (Collaboration@Work), a task force founded by the European
Commission (EC) Directorate General of Information Society Technologies and Media, in charge of
defining the main research lines related to collaborative working environments for the definition of
goals related to European research and development work programs.

Çiğdem Gencel works as a part-time instructor at the Department of Information Systems at Middle
East Technical University. She holds a PhD degree in the same department with a focus on software
size measurement. She has been working in the domain of software engineering as an academician for
5 years and as an instructor for 1 year. Her research interests involve software metrics, software size
estimation, and software requirements elicitation.

Sanjay Gosain is a Wes strategy analyst for the Capital Group in their California offices. Previously,
he was an assistant professor of information systems at the Robert H. Smith School of Business, Uni-
versity of Maryland, College Park. His research interests are in the area of the integration of enterprise
information systems. He has consulted with companies on integration issues and taught MBA-level
courses on e-business-process integration and information technology.

Marc N. Haines is an assistant professor in the School of Business Administration at the Univer-
sity of Wisconsin, Milwaukee. His research has been published in the International Journal of Human
Computer Interaction, Information Resources Management Journal, Journal of Data Warehousing,
Computers and Operations Research, and other publications. He is chairing the HICSS minitrack
on service-oriented architectures and Web services. He is also a member of the Organization for the
Advancement of Structured Information Standards (OASIS). His research interests include the adop-
tion and impact of integration standards and technologies such as Web services, organizational issues

About the Contributors

concerning the implementation of enterprise systems (ERP), and the development and application of
XML-based (extensible markup language) vocabularies.

William D. Haseman is the Wisconsin distinguished professor and director of the Center for Tech-
nology Innovation at the University of Wisconsin, Milwaukee. He received his PhD from the Krannert
Graduate School of Management at Purdue University and served previously on the faculty at Carnegie-
Mellon University. His research interests include groupware, Web services, decision support systems,
services-oriented architecture, and emerging Internet technologies. Dr. Haseman has published a book
and a number of research articles in journals such as Accounting Review, Operations Research, MIS
Quarterly, Decision Support Systems, Information Management, Information Systems, and Database
Management. He was conference chair for the Americas Conference on Information Systems (AMCIS)
in 1999 and is the conference chair for the International Conference on Information Systems (ICIS)
for 2006.

Guillermo Jiménez-Pérez has a PhD in computer science and currently is a professor of software
engineering at ITESM in Monterrey, Nuevo León, México. His current interest is in applying compo-
nent-based software development and software product-lines techniques in systems integration.

Chris Lawrence, a business architecture consultant, has designed and implemented solutions in the
United Kingdom, United States, and Southern Africa over a 25-year career in financial-services IT. He
has addressed conferences in the United Kingdom and United States, specializing in the area where
process architecture meets holistic delivery and transition methodologies. In 1996 he left England for
Cape Town to cofound Global Edge, a strategic business-enablement competency employing a version
of Sungard’s Amarta architecture to support financial-services group Old Mutual’s international expan-
sion. He based his book Make Work Make Sense (Future Managers, 2005) on the process-architectural
delivery methodology he developed for Global Edge. Chris studied philosophy at Cambridge and London
University. He and his wife Wendy have one son, Joe.

So-Jung Lee is principal of JLee Consulting. Mr. Lee has been providing IT consultancy services
to financial services providers such as banks, brokerage houses, and insurance firms within the ASEAN
(Association of Southeast Asian Nations) region for over 20 years. After spending many years working
for various large consultancies, he recently established his own consultancy firm with an emphasis on
strategic IT consulting. His expertise spans a number of different areas that includes systems integration,
business-process analysis, and IT security. His is currently writing a book on the role of technology in
globalization.

Ayesha Manzer earned her PhD in July 2002 from the Computer Engineering Department of Middle
East Technical University, Ankara, Turkey. Her research and publications are related to software en-
gineering, personalization for e-commerce, virtual enterprises, and process integration. Manzer holds
MS and BS degrees in computer science from Gomal University, Pakistan, and from Jinnah College
for Women, Pakistan, respectively.

Dirk Muthig heads the Department of Product Line Architectures at the Fraunhofer IESE in Kai-
serslautern, Germany. He has been involved in the definition and development of Fraunhofer’s PuLSETM

About the Contributors

(Product Line Software Engineering) methodology since 1997, as well as in the transfer of product-line
and architecture technology into diverse industrial organizations. Muthig received a diploma and a PhD,
both in computer science, from the University of Kaiserslautern.

Mariano Navarro graduated as a telecommunications engineer at the Universidad Politécnica de

Madrid 15 years ago. He is currently working as the technological innovation department manager.
For the last 5 years, he has been working in forestry-related projects. He has been working also in
traceability projects related to different product chains for 6 years. He belongs to the EC expert group
Collaboration@Work and collaborates frequently with the Directorate General of Information Society
Technologies and Media in defining the main research lines of European research and development
work programs. At the present moment, he is working on the Strategic Innovation Plan for the next 5
years in the Tragsa Group, MAFF, and ME.

Lin T. Ngo-Ye is a PhD candidate at the University of Wisconsin, Milwaukee. He has a Master of
Science in information management from Arizona State University. His research interests include the
issue of software licensing, pricing and maintenance, service-oriented architectures, Web services, and
electronic commerce. He has published a number of refereed conference proceedings and has several
manuscripts under various stages of review.

Taha Osman is a senior lecturer at the Nottingham Trent University, United Kingdom. He received
a BS honors degree in computing from Donetsk Polytechnical Institute, Ukraine, in 1992. He joined
the Nottingham Trent University in 1993 where he received an MS in real-time systems in 1994 and a
PhD in 1998. His current research investigates fault tolerance in open distributed systems.

María-Isabel Sánchez-Segura has been a faculty member of the Computer Science Department in
the Carlos III Technical University of Madrid since 1998. Her research interests include software engi-
neering, interactive systems, and usability in interactive systems. María-Isabel holds a BS in computer
science (1997), an MS in software engineering (1999), and a PhD in computer science (2001) from the
Universidad Politecnica of Madrid. She is the author of several papers related to the improvement of
virtual environments development from the software engineering point of view, published recently in
journals such as Software Practice and Experience, Interacting with Computers, and Journal of Systems
and Software. She is also the author of more than 20 papers presented at several virtual-environments
and software engineering conferences. Maria-Isabel is one of the instructors, joint Carnegie-Mellon
and Technical University of Madrid researchers, at tutorials held at the ACM CHI conference, Vienna,
April 2004, and the IEEE ICSE conference, Edinburgh, May 2004.

Alexander Schwinn was a research assistant at the Institute of Information Management at the
University of St. Gallen (HSG), Switzerland, for 4 years after studying computer science and economics
at Ludwig-Maximilians University in Munich, Germany. His research topics included EAI, enterprise
architecture, and IT management. He wrote several journal publications and spoke at a number of
conferences. He completed his doctoral studies successfully with a thesis titled Designing Integration
Architectures for Information Systems in April 2006.

About the Contributors

Gokul Seshadri is an architect with TIBCO Software Inc. His primary role is to design EAI (enter-
prise application integration) solutions and SOA middleware for large-scale enterprise customers based
on his experience and best practices in the industry. Gokul has designed regional SOA architectures of
significant magnitude spanning multiple geographic locations. He also plays a strategic advisory role
to various customers, advising them on the right enterprise-wide architectural and technical strategies
to adopt and in identifying areas of IT investment for the long-term growth and evolution of the orga-
nization. Gokul carries nearly 13 years of industry experience, the better part of which was spent in
the financial services industry in retail, corporate, and investment banks, and in brokerage houses and
stock exchanges. He is an avid author and has written many articles and a textbook. He has presented
papers at various industry conferences as well.

Ayça Tarhan works for Bilgi Group Ltd. She is a part-time instructor at the Department of Software
Management and a PhD candidate at the Department of Information Systems at Middle East Techni-
cal University. She has been working in the domain of software engineering as an academician for 7
years and as consultant and instructor for 3 years. She pursues her studies on software quality, software
measurement, and software engineering standards. She has an MS degree in computer science.

Dhavalkumar Thakker obtained his master’s degree in data communication systems at Brunel
University, London. He also received his BE from Gujarat University, India. He is a PhD candidate at
the School of Computing and Informatics, Nottingham Trent University, United Kingdom. His current
research interests are distributed computing technologies, Web services composition, Semantic Web,
and ontologies.

Velan Thillairajah is the founder and CEO of EAI Technologies (http://www.eaiti.com). Mr. Thillai-
rajah has 20 years of experience, ranging from management consulting to information technology,
telecommunications, and Web-based solutions. He has worked with or for PriceWaterhouseCoopers,
Hewlett-Packard, Network Solutions, AOL, Verizon, BMC, VeriSign, KPMG, and Agilent. He studied
operations research and industrial engineering at Cornell University, and then received an MBA at
the University of Rochester’s Simon School of Business, where he was featured in Forbes’ “Best and
Brightest.” EAI Technologies leverages its clients’ existing investments in enterprise-level (ERP, CRM
[customer relationship management], e-commerce, supply chain, and e-marketplace) systems by inte-
grating data and applications with Web services. Also, as an active board member of the Integration
Consortium (http://www.integrationconsortium.org), Mr. Thillairajah speaks and represents the con-
sortium at numerous conferences and events such as Gartner and contributes to content related to EAI
best practices and strategies.

Robert Winter is a full professor of information systems at HSG, director of HSG’s Institute of Infor-
mation Management, and academic director of HSG’s executive MBA program in business engineering.
He received master’s degrees in business administration and business education as well as a doctorate in
social sciences from Goethe University, Frankfurt, Germany. After 11 years as a researcher and deputy
chair in information systems, he was appointed chair of information management at HSG in 1996. His
research interests include business engineering methods and models, information systems architectures
and architecture management, and integration technologies and integration management.

About the Contributors

Min-Jung Yoo is an assistant professor at HEC (Ecole des Hautes Etudes Commerciales), The
University of Lausanne. Yoo’s research interests include multiagent systems, extended enterprises, dy-
namic scheduling in collaborative supply chains, the semantic Web, and Web services. Her research is
focused on the application of multiagent systems and other related technologies to designing practical
enterprise information systems and e-learning environments as well. She received MS and PhD degrees
in computer science from the University of Paris 6 (Pierre et Marie Curie, France) in 1999.

0
341

Index

A integration (B2Bi) 5, 165, 286

relationship 226
abstraction 79–80 transaction 92–106
acquisition domain 60
cycle 51 information system (BIS) 285
planning 58 process
actor network theory 41 integration 119–138, 217
agent paradigm 212 management (BPM) 166, 226, 242
agility 15, 25 modeling 54, 107–118
American National Standards Institute 109 language (BPML) 109
application reengineering (BPR) 78
integration 9, 167, 273 rule 126
programming interface (API) 10, 94, 188
architecture 145 C
artificial-intelligence (AI) 227
ATAM 153 C4ISR 52
automation 244 call center 241
campaign 191, 193
B designer 200
chief information officer (CIO) 3
batch integration 12 COBOL 256
best practice (BP) 247–248 code generator 169
bottleneck 123 commercial off the shelf (COTS) 27, 274
broker-based integration 12 communication infrastructure 215
browser 205 computer-aided software engineering (CASE) 290
business CORBA 95, 167, 226
-process integration 12 correctness 153
-to-business (B2B) coupling 28

customer entity relationship diagram (ERD) 110

centric 123 event-driven process chain 109
relationship management (CRM) 242 ExPlanTech 219
customization 145, 309 extensible markup language (XML) 94, 260

D F
data file transfer protocol (FTP) 97
analysis 121 financial portfolio system (FPS) 273, 276
collection 246 fixed server component 199
dictionary 62 Food and Drug Administration (FDA) 312
entity type (DET) 68 forecasting 307
entry 2 Foundation for Intelligent Physical Agents (FIPA)
exchange 21 216
flow diagram (DFD) 54 Fraunhofer 140, 142, 144, 147
integration 9
management 311 G
storage 311 generic 144, 155
transfer 215, 216 geographical information system (GIS) 154
DAVINCI 188–211 GQM 147
DBSync 196–197 graphical user interface (GUI) 169
decentralized artificial intelligence (DcAI) 214
decision model 154, 159 H
design pattern 151
desktop 243 herarchical decomposition 75–91
distributed artificial intelligence (DAI) 214 heterogeneous application 287
documentation 152 hypertext
domain markup language (HTML) 288
interface 229 transfer protocol (HTTP) 258
membership 230
Drinko 43 I
information
E aggregation 2
e- sharing 311
brokerage 166 systems integration 187–211
engineering 166 inspection 153
marketing 166 instance level 122
productivity 166 integrated definition 109
signature 201 integration 256, 286
supply 166 architecture 12–14, 192
electronic data interchange (EDI) 92, 286 challenges 10
employee attendance system (EAS) 285 levels 9–10
engineering process control (EPC) 110 middleware 192–193
enterprise timeliness 5
application integration (EAI) 5, 23– integrative business application 139–163
39, 140, 142, 212–224, 255, 273 intelligent agents 214–215
business architecture (EBA) 108 Internet protocol 266
distributed computing technology 225–239 interoperability 153, 158
engineering 76 inventory reduction 309
integration 2–22, 240–254
resource planning (ERP) 40, 154, 159, 243

342
Index

K PuLSE™ 139, 144

PyME CREATIVA 165
knowledge
-intensive service industry 119–138 Q
interchange format (KIF) 215
sharing 215 quality model 147
Korea 274 quality of service (QoS) 16

M R
message radio frequency identification (RFID) 306
routing 14 rational unified process (RUP) 286
splitting 14 reactivity 213
Midwest Manufacturing Company (MMC) 93 refinement 80
mobile reflexion 161
-application architecture 189 remote method invocation (RMI) 226, 287
-computing application 189 request for proposal (RFP) 52, 278
geographic information viewer (mobile GIS) 205 retail business 284–305
worker 191, 200 return on investment 263
working environment 187–211 reusability 265, 270
multiagent collaboration 215 reusable software 29
multithreading 189 reuse 29
reverse
O architecting 146
engineering 161
object request broker 25 roaming 188
OpenEAI 143 routing 14, 128
organisational silo 1–22
outsourcing 26 S
OxyContin 313
security 21–22, 198, 308
P semantic integration 159
Semantic Web 227
personal computer (PC) 188 service
point-of-sale (POS) 285 -level agreement (SLA) 265
point-to-point -oriented
communication 256 architecture (SOA) 112, 255–272
integration 12 development and integration (SODI) 285
interface 256 integration 218
presentation integration 9 retail business information system 284–305
privacy 312 integration 10
proactivity 213 services monitoring 268
process servlet engine 166
-level integration 217 shelf life 308
control system 154, 159 Six Sigma methodology 242
decomposition model 78 small and medium-sized enterprise (SME) 140, 165
improvement 240–254 social
integration 10, 75–91 ability 213
model 133 behavior 214
product line engineering 144 software
project expense 25 decomposition 77
proof of delivery (PoD) 308 development kit (SDK) 280

343
Index

engineering 75 W
product lines 144
size estimation 68 Wal-Mart 307, 312
South Korea 274 Web
stable state 122 integration 5
stakeholder 264 interface 193
analysis 147 services 164–186
silo 18 Wi-Fi 188
stock verification 308 workflow
subject entity 124 management system (WFMS) 217
supply chain integration 164–186 patterns 151
swimlane diagram 109 status 126
synchronization 154–155 system 78
system wrapper agent approach 219
architecture 65
Y
design 133
systems Y2K 44
development life cycle (SDLC) 107
integration 15

T
technological silo 1–22
telecommunication infrastructure 65
third-generation language (3GL) 113
traffic
flow 240
planner 240
transaction management 14
transmission-control protocol (TCP) 258
travel-agent problem 228

U
unified modeling language (UML)
110, 150, 155, 170
unstable state 122
user interface (UI) 190, 243

V
value-added network (VAN) 92
variability 144, 154
vendor selection 262
visual
environment 164–186
modeling 109
VoiceUI 205

344

Enterprise Architecture
100% (11)
Enterprise Architecture
154 pages
AW Patterns For API Design
No ratings yet
AW Patterns For API Design
545 pages
Enterprise Architecture Visualization Tool Survey 2014
No ratings yet
Enterprise Architecture Visualization Tool Survey 2014
417 pages
Disney Enterprise Architecture
No ratings yet
Disney Enterprise Architecture
51 pages
Enterprise Architecture
No ratings yet
Enterprise Architecture
157 pages
Archimate Model
100% (1)
Archimate Model
6 pages
It Service Management Configuration
No ratings yet
It Service Management Configuration
3 pages
FSA Guidance Document - As Published 08.03.2019 1.0
No ratings yet
FSA Guidance Document - As Published 08.03.2019 1.0
31 pages
Handbook of Enterprise Systems Architecture in Practice
100% (3)
Handbook of Enterprise Systems Architecture in Practice
499 pages
Enterprise Architecture
83% (12)
Enterprise Architecture
365 pages
IM Systems Integration and Architecture 1
No ratings yet
IM Systems Integration and Architecture 1
102 pages
Design of Architecture Enterprise Model Information System Academic and Student Administration Bureau Using Togaf Adm
No ratings yet
Design of Architecture Enterprise Model Information System Academic and Student Administration Bureau Using Togaf Adm
9 pages
TDT4252 Modelling of Information Systems Advanced Course: Sobah Abbas Petersen
No ratings yet
TDT4252 Modelling of Information Systems Advanced Course: Sobah Abbas Petersen
65 pages
Module 3 - Information Systems Architectures PDF
No ratings yet
Module 3 - Information Systems Architectures PDF
15 pages
Careers in EA
No ratings yet
Careers in EA
19 pages
Enterprise Architecture Tool Selection Guide v4.2
No ratings yet
Enterprise Architecture Tool Selection Guide v4.2
20 pages
1 Intro To Enterprise Architecture
No ratings yet
1 Intro To Enterprise Architecture
76 pages
A Day in The Life of An EA
No ratings yet
A Day in The Life of An EA
35 pages
Enterprise Architecture Principles
100% (3)
Enterprise Architecture Principles
5 pages
Enterprise Architecture Modeling
100% (2)
Enterprise Architecture Modeling
138 pages
The Enterprise Architect: of Tomorrow
No ratings yet
The Enterprise Architect: of Tomorrow
14 pages
Designing Enterprise Architecture Frameworks - Integrating Business Processes With IT Infrastructure (PDFDrive)
100% (6)
Designing Enterprise Architecture Frameworks - Integrating Business Processes With IT Infrastructure (PDFDrive)
355 pages
Enterprise Architecture
No ratings yet
Enterprise Architecture
13 pages
Jordan E-Government Enterprise Architecture: Reserved
No ratings yet
Jordan E-Government Enterprise Architecture: Reserved
51 pages
EA Patterns
100% (1)
EA Patterns
274 pages
EA Learning Sessions 1st Sem 2022 23
No ratings yet
EA Learning Sessions 1st Sem 2022 23
3 pages
Microservices Reference Architecture For Insurance Companies
No ratings yet
Microservices Reference Architecture For Insurance Companies
25 pages
IASA IT Architecture Foundation 101v1
0% (1)
IASA IT Architecture Foundation 101v1
3 pages
Enterprise Architecture
100% (3)
Enterprise Architecture
179 pages
TOGAF ADM Phase A
No ratings yet
TOGAF ADM Phase A
35 pages
Enterprise Architecture Framework
100% (1)
Enterprise Architecture Framework
112 pages
Introduction To Enterprise Architecture
No ratings yet
Introduction To Enterprise Architecture
25 pages
Structure of The TOGAF Document Downloads Frequently Asked Questions
No ratings yet
Structure of The TOGAF Document Downloads Frequently Asked Questions
7 pages
The Value of Enterprise Architecture
No ratings yet
The Value of Enterprise Architecture
28 pages
ARCHIMATE
No ratings yet
ARCHIMATE
8 pages
DR Pallab Saha - EA & Public Health
No ratings yet
DR Pallab Saha - EA & Public Health
24 pages
Enterprise Integration Patterns1
100% (1)
Enterprise Integration Patterns1
3 pages
Solutions Architecture
100% (3)
Solutions Architecture
252 pages
Evaluate Enterprise Architecture Frameworks Using Essential Elements
No ratings yet
Evaluate Enterprise Architecture Frameworks Using Essential Elements
31 pages
Enterprise Architecture and Innovation Management Ebook
100% (3)
Enterprise Architecture and Innovation Management Ebook
164 pages
Enterprise Architecture
100% (2)
Enterprise Architecture
318 pages
An Enterprise Architecture Design Build Approach - Innovate Vancouver
100% (5)
An Enterprise Architecture Design Build Approach - Innovate Vancouver
37 pages
Building Effective Enterprise Architecture (EN) PDF
No ratings yet
Building Effective Enterprise Architecture (EN) PDF
12 pages
Enterprise Architecture Quality Attributes: A Case Study
No ratings yet
Enterprise Architecture Quality Attributes: A Case Study
12 pages
Ahlemann Et Al. 2012 Strategic Enterprise Architecture Management Ch1 2 4-7
100% (1)
Ahlemann Et Al. 2012 Strategic Enterprise Architecture Management Ch1 2 4-7
178 pages
TOGAF and Archimate
No ratings yet
TOGAF and Archimate
16 pages
BiZZdesign Second Edition
From Everand
BiZZdesign Second Edition
Gerardus Blokdyk
No ratings yet
Enterprise Systems Architecture Aligning Organisational Business
100% (2)
Enterprise Systems Architecture Aligning Organisational Business
196 pages
Solution Architecture
No ratings yet
Solution Architecture
17 pages
Enterprise Architecture Tool Selection Guide v6.3
No ratings yet
Enterprise Architecture Tool Selection Guide v6.3
25 pages
Delivering EA With Togaf and AM PDF
No ratings yet
Delivering EA With Togaf and AM PDF
150 pages
The Role of An Architect
100% (1)
The Role of An Architect
3 pages
Enterprise Architecture Mid Term
No ratings yet
Enterprise Architecture Mid Term
19 pages
Dynamic Business Rule Engine
No ratings yet
Dynamic Business Rule Engine
19 pages
Requirements Management in Enterprise Architect
No ratings yet
Requirements Management in Enterprise Architect
50 pages
Sparx Enterprise Architect Guidelines
No ratings yet
Sparx Enterprise Architect Guidelines
19 pages
WA Enterprise Architecture Framework - 0
No ratings yet
WA Enterprise Architecture Framework - 0
59 pages
TOGAF Business Scenarios
No ratings yet
TOGAF Business Scenarios
24 pages
Chapter 01 - Introduction To Ea
No ratings yet
Chapter 01 - Introduction To Ea
18 pages
Evaluation of The Risk and Security Overlay of ArchiMate To Model Information System
No ratings yet
Evaluation of The Risk and Security Overlay of ArchiMate To Model Information System
11 pages
Cloud Paradigm: Cloud Culture, Economics, and Security.
From Everand
Cloud Paradigm: Cloud Culture, Economics, and Security.
Tony Adams
No ratings yet
Enterprise architecture planning Complete Self-Assessment Guide
From Everand
Enterprise architecture planning Complete Self-Assessment Guide
Gerardus Blokdyk
No ratings yet
Competition Tribunal On Sasol and Engine
No ratings yet
Competition Tribunal On Sasol and Engine
214 pages
Condeco 3.2 User Manual
No ratings yet
Condeco 3.2 User Manual
41 pages
Map Ward 8
No ratings yet
Map Ward 8
1 page
Leribisi Lodge Three-Course Dinner For Two: Use This Voucher by 08.06.2015
No ratings yet
Leribisi Lodge Three-Course Dinner For Two: Use This Voucher by 08.06.2015
1 page
Artifacts
No ratings yet
Artifacts
298 pages
Sabonet Report No 26 Seed Plants Southern Tropical Africa Families and Genera
No ratings yet
Sabonet Report No 26 Seed Plants Southern Tropical Africa Families and Genera
497 pages
Qumbu Magqubu Ntombela
No ratings yet
Qumbu Magqubu Ntombela
5 pages
SAP® HANA Essentials
No ratings yet
SAP® HANA Essentials
286 pages
Research Report On Growth of Indian Telecom Sector: (Regulatory and Policy Initiatives)
No ratings yet
Research Report On Growth of Indian Telecom Sector: (Regulatory and Policy Initiatives)
20 pages
The Impact of Gamification On Students' Learning, Engagement and Behavior Based On Their Personality Traits
No ratings yet
The Impact of Gamification On Students' Learning, Engagement and Behavior Based On Their Personality Traits
11 pages
2024 Barcelona Conference Program-Nov. 7
No ratings yet
2024 Barcelona Conference Program-Nov. 7
24 pages
Renewable Energies: DL Solar-L
No ratings yet
Renewable Energies: DL Solar-L
1 page
Avalon Pellet Stove
No ratings yet
Avalon Pellet Stove
37 pages
Final Project Proposal
No ratings yet
Final Project Proposal
3 pages
Fe-92ba047-01 Reseting HNAS
No ratings yet
Fe-92ba047-01 Reseting HNAS
14 pages
Schonberger - ChatGPT in Higher Education The Good The Bad and The University
No ratings yet
Schonberger - ChatGPT in Higher Education The Good The Bad and The University
8 pages
English Sample Unit: Pictures Tell The Story! Stage 2
No ratings yet
English Sample Unit: Pictures Tell The Story! Stage 2
18 pages
Quick Guide VIO 200 S: Necessary Operating Steps
No ratings yet
Quick Guide VIO 200 S: Necessary Operating Steps
2 pages
Manual For Xioami XL Inventer
No ratings yet
Manual For Xioami XL Inventer
112 pages
Semiconductor KRC101S KRC106S: Technical Data
No ratings yet
Semiconductor KRC101S KRC106S: Technical Data
7 pages
Detailed Lesson Plan
No ratings yet
Detailed Lesson Plan
4 pages
Smart Bridge - Automatic Height Increase During Flooding
No ratings yet
Smart Bridge - Automatic Height Increase During Flooding
12 pages
All Organizations Merged
No ratings yet
All Organizations Merged
46 pages
Exploring OpenFOAM PDF
No ratings yet
Exploring OpenFOAM PDF
20 pages
Wiggins Vr300 Non Pressurising Ultra Fast Fil Diesel Refuelling Systems
No ratings yet
Wiggins Vr300 Non Pressurising Ultra Fast Fil Diesel Refuelling Systems
3 pages
Change MGMT
No ratings yet
Change MGMT
15 pages
JobAdvertisement 198486
No ratings yet
JobAdvertisement 198486
3 pages
Adham Adel Makroum: Objective
No ratings yet
Adham Adel Makroum: Objective
2 pages
Cdi5 WK8
No ratings yet
Cdi5 WK8
5 pages
CS602 Finalterm Solved MCQs With References by Moaaz
100% (1)
CS602 Finalterm Solved MCQs With References by Moaaz
40 pages
Real-Time Inventory Management With RFIDash
No ratings yet
Real-Time Inventory Management With RFIDash
10 pages
Fundamental of Programming Chapter 1
100% (2)
Fundamental of Programming Chapter 1
46 pages
Newton Cotes Integration Method: Prepared By:-Pabari Shashikant
No ratings yet
Newton Cotes Integration Method: Prepared By:-Pabari Shashikant
23 pages
Crutchfield
No ratings yet
Crutchfield
12 pages
Garuda Indonesia TBK
No ratings yet
Garuda Indonesia TBK
12 pages
Field-Installation-Guide-Cisco-HCI-UCM
No ratings yet
Field-Installation-Guide-Cisco-HCI-UCM
31 pages
Programming Principles and Practice Using C 1st Edition Bjarne Stroustrup all chapter instant download
92% (13)
Programming Principles and Practice Using C 1st Edition Bjarne Stroustrup all chapter instant download
60 pages