An Isomorphic Architecture for Enterprise Information

Systems Integration

Mingxin Gan

†

, Lily Sun

∗

, Botang Han

†

School of Management and Economics

Beijing Institute of Technology, China

∗

Informatics Research Centre

The University of Reading, UK

Abstract. Enterprise information systems often face difficulties in linking

various components and external systems. Interoperability among collaborating

participants is hard to tackle in both business and IT domains. These call for

effective architectural solutions that coordinate powerful technologies with

business applications to enable seamless inter-organizational integration. The

inter-organizational integration of information systems needs to be considered

from an architectural point of view on issues around business, organization and

information technology. In this paper, an isomorphic architecture for systems

integration (IASI) is proposed with a focus on supply chain management

systems. This architecture allows integrating the business agility and IT

infrastructure by consolidating processes between these two domains, and

facilitates business changes with simultaneous evolution of the IT infrastructure.

1 Introduction

The supply chain is based on an integrative philosophy to manage the total flow of a

channel from the earliest supplier of raw materials to the ultimate customer and

beyond, including the disposal process [3]. So a number of functions are needed to be

integrated into the total process throughout the supply chain to support the

management of inter-organizational business. The effort of integration has been

propelled and driven by the rapid development of information technology (IT) and

information system (IS).

Workflows and different software components have been developed independently

and changed over time. Information systems integration focuses on the inter-

organizational linkages of different systems. The integration is achieved through

architecture so that the overall system continuously provides useful information

Gan M., Sun L. and Han B. (2005).

An Isomorphic Architecture for Enterprise Information - Systems Integration.

In Proceedings of the 1st International Workshop on Requirements Engineering for Information Systems in Digital Economy, pages 70-78

DOI: 10.5220/0001423100700078

 SciTePress

services to the organization within which it functions. In the IT domain, information

systems architecture represents the structure of the components, their relationships,

principles and directives with the main purpose of supporting business as well as its

integration.

Normally, an integrated architecture can be divided into three levels: information

(or data) architecture which describes main data types required by business operators;

application architecture which defines applications needed for data management and

business support; and technological architecture which represents the main

technologies used in applications implementation and the infrastructures that provide

an environment for IS deployment. Structural coherence in the architecture can be

achieved through the adoption of common data, process and technology definitions

[6].

Integration architecture provides a generic framework for information exchange and

coordination among a variety of existing software systems [12]. In this sense, an

information system architecture can be divided into four levels in a horizontal

integration. Communication services such as Communication Standards (ISO/OSI-

layers 4-7) are required for inter-process integration to ensure that all aspects of the

communication are identical among systems. Syntax which is a data level integration

such as EDIFACT and ANSI is required to define the order, length and the type of

data being exchanged. But it is not sufficient for an automated integration of system.

Semantics as object level integration such as EAN and D&B is needed to assign real

world subjects and notions to the transmitted characters. Pragmatics as process level

integration (workflows etc.) is a feature of sophisticated workflow systems which

makes sure that not only transmitted data has been understood but that subsequent

actions are triggered in an integrated system.

To motivate the need for enterprise information systems integration in a supply

chain environment, an Isomorphic Architecture for System Integration (IASI) based

on Model Driven Architecture (MDA) is examined. IASI is described to address the

issues of inter-organizational integration between domains of IT and business based

on a convergent architecture, which can help produce a flexible, well-structured

integrated system with coherence.

The rest of the paper is structured as follows. Section 2 presents the MDA-based

architecture called convergent architecture (CA), Section 3 describes the IASI built

for integrated enterprise information systems based on CA, Section 4 concludes the

paper with discussion on directions for future research.

2 The Architectures for Information System Integration

2.1 Related Work

Although an inter-organizational infrastructure is important to enable flexible supply

chains and theory to guide its development [18], research on the details of structuring

inter-organizational relations and infrastructure has not been given due attention [17].

Methods and tools have been introduced to address the issues for integration such as

CoopWARE integration architecture [12], Distributed Processing Architecture [1],

Integration Infrastructure [19], Horizontal Integration [7], EAI-architecture [14],

Enterprise Integration Architecture [8], B2B Integration [11], and the method of

Robert Bosch Group [13]. Although these architectures as well as methods succeed in

IT domain by giving an IT infrastructure to facility the integrated architecture, the

consolidated linkage with business domain has not been reached well. Most of the

practices in supply chain integration focus on the inter-organizational linkages

triggered by IT infrastructure from technology point of view since the role of the IT

infrastructure in responding to and shaping business options with agility is recognized

as critical [15];[10].

However, most of these methods pay a great deal of attentions on a single level of

integration separately. These practices bring concept divergence to the dynamic

supply chain integration, although they can bring the idea of collaboration and

integration technology into enterprises. When change happens either in business

domain or IT domain especially in the various collaboration settings, one has to face

difficulties to match the other.

Most designs of information systems for integration have not been deployed well in

an integrated manner, which leads to an unmatched phenomenon called concept

divergence in domains. Many advantages of leading technologies are therefore

sacrificed. Consequently this phenomenon will be magnified when changes occur

continuously in business domain particularly in a dynamic supply chain environment.

As we know, a small divergence in a static condition will become larger in a dynamic

condition. This phenomenon will be magnified in inter-organizational integrated

information systems. Business in such a complex environment will be not only

dynamic but also expands from an individual enterprise to inter-organizational. Thus

the development and maintenance of such information systems will face much more

difficulties to cope with the change of the businesses especially when enterprises

collaborate with others. So Information systems among enterprises need to be

integrated well to support collaborative business. Information system architectures in

supply chain integration therefore need to focus on the relationship between IT and

business domains in an individual enterprise as well as in inter-organizational

connections.

2.2 Convergent Architecture

Model Driven Architecture (MDA) is a standardization initiative and architectural

direction of the OMG (Object Management Group). It offers a full life cycle approach

for solving the problems of developing, deploying and integrating existing distributed

systems. Emerging technology, assembling virtual enterprises can therefore span

multiple companies and implementing business intelligence solutions and enterprise

information portals in a multi-vendor environment. Technology projection is a feature

of an MDA-centric approach as well as an IT-architectural style which transforms a

model to another model or as a final step, maps a model to an executable system

infrastructure.

Convergent engineering (CE) is introduced by Taylor (1995) as a design vision with

a methodology which aligns business and IT systems through a set of design patterns

and design techniques based on the object paradigm. Convergent architecture (CA) is

a MDA-based IT-architectural style which leverages the benefits of agile development

and convergent engineering in practice as well as signifies the alignment of business

and IT model into one common, synchronized model and takes a holistic approach to

project, business and system design. CA provides a practical, architecture driven

MDA process and techniques enabling business and software design to become a

consolidated effort. The key technologies and theories are as follows [9]:

• Three pillars of the holistic architecture are defined in the MDA-oriented

convergent architecture being concerned with simplifying the development of

effective IT systems by achieving synergies with each other: business design;

project design which defines how to achieve project design using modern

modeling and convergence techniques; and system design which defines how

to achieve system design using MDA techniques.

• RASC (reduced abstraction set computing) represents the core component

abstractions and corresponding architectural layers to achieve the goals of

convergent engineering, through which the three pillars of the holistic

architecture are consolidated together. As an example of RASC, OPR

(organization, process and resource) are the three core abstraction of RASC

and are verified to be the minimum sets of the formal structural components

through which the business model can be transformed to IT system.

This solution leads design of different systems to a synchronized process as well as

isomorphic concepts structures to avoid the divergence in systems. Systems which are

designed using the concepts of CE are supposed to be understandable, maintainable

and easily modified in response to the changing business conditions.

2.3 Problems and Challenges

Systems designed using CA will face difficulties in a supply chain in inter-

organizational collaboration where business changes are not only inside an enterprise

but also expand to inter-organizational scope. These information systems are designed

as a logic structure using CA in one enterprise. They have to change to meet the need

of new business which is controlled by more than one enterprise. They will also face

continuous changes under a more complex environment. Thus, the logic structure will

be brought an inconsistency into the inter-organizational system. IT infrastructure

which mapped to business domain has to add new business logic components to the

origin one. The reason is that isomorphic structure is not fully developed by CA for

inter-organizational collaboration.

Practically supply chain processes are derived from integration of enterprise

processes, so performances such as flexibility and agility will be derived from both

internal enterprise and the connections between enterprises [5]. Both the intra-

organizational and inter-organizational performances have close relationship with

each other. The linkage between the single system and inter-organizational system has

not been addressed effectively.

In a stable environment, an enterprise may have chosen to forge highly specific and

efficient process linkages and information exchange mechanisms with select partners,

but in the dynamic environment, enterprises need to develop more robust and

reconfigurable linkages that can deal with changes in the business environment [4].

The most obvious difficulties in drawing an integrated architecture lie in two aspects

as expansion of business which is the objective and the IT correspondence with the

wider business. Furthermore, dynamic business causes the difficulties severe with

which IT infrastructure faces challenges to cope with business.

3 Isomorphic Architecture for Inter-Organizational Information

Systems Integration

3.1 The Components in Isomorphic Architecture

In an integrated architecture as described in Figure 1, highly specific and efficient

process linkages and information exchange mechanisms are built for enterprise to

propel and drive the collaboration with selected partners in a stable environment.

Furthermore, more robust and reconfigurable linkages which can deal with changes in

a dynamic business environment are explained through a method introduced in this

architecture.

Fig. 1. Integration between business scopes in both business and IT domains

As the main design processes in information system development, business design

and system design have responsibility to be illustrated with the correlation through a

specific and coherent way to produce an IT system with rapidly tracking to business

in a supply chain environment. Figure 1 also illustrates the modules in IASI and their

relationship when organizations integrate. Each business scope in IASI indicates the

scope of single organization before integrating. The component which is called

technology project component above the upper broken line belongs to IT domain,

which comes from the inspiration of MDA-centric approach and will be mapped to

technologies as a certain component reflecting an IT-architectural style. And those

below the other broken line belong to business domain, each of which individually

represents the three key elements of OPR being a certain case got from RASC in CA.

Here OPR is emphasized to explain the integrated architecture.

The arrow labeled as integration between the two broken lines as well as between

business scopes shows how the business objects are mapped to IT domain when

integration, whose realization will be explained in detail in Figure 2. The main

proposed solution for the interaction between domains is shown in Figure 2, which

illustrates the mapping between business and IT domains in inter-organizational

integration.

Process Resource

Organization

Technolo

Pro

ect Com

onent

Intra-or

anization 1

Technolo

Pro

ect Com

onent

Process Resource

Organization

Intra-or

anization 2

Integration

Inter-organizational business

Technologies for integration

IT domain

Business domain

Fig. 2. Model for mapping business and IT domains in inter-organizational integration

Business integration happens at the overlap of the OPR. The arrowhead among OPR

shows the reaction of these elements. When collaboration happens in supply chain,

resources which will be mapped by technology projection component expand from

one single enterprise to multi-organizational scope and obtain more dynamical

characteristics than before. Processes in the enterprise will utilize and generate much

more resources of the wider scope and extend into the suppliers and buyers with

which enterprise is collaborating. The scope of organization is also different from

before where enterprises cooperate to manage some core business processes and

resources together.

While the integration in IT domain happens among technology project components

and mapped to technologies for integration. Technologies supporting IASI to solve the

challenge of integration in IT field function at different levels. XML substantially

facilitates information exchange and real time distribution in an integrated supply

chain and conveys specific display instructions as well as depicts a variety of file

types. Middleware component technologies as CORBA, DCOM, Enterprise Java

Beans make information to communicate effectively, lead the supply chain system to

more scalable, compatible, standardized reusable and better equipped, regardless of

platforms or programming languages. Semantic Web is for data standardized and

machine processable; Web Services facilitates interoperability across platforms and

languages as well as component technologies and as a framework delivers features to

developers in a simple, reliable and scalable fashion so as to allow the interaction and

collaboration at a service level.

Business domain

IT domain

Logic Structural Module

Pragmatics

Semantics

Syntactic

Business

Logic Module

Structural

Configuration

Describe the structure of

components and their pattern

Put architecture

style into practice

Technologies

for Integration

System

Goals

Realize

Value transformation

Interface1

Interface3

Interface4

Interface2

3.2 Interoperability-An Architectural Interaction in Intra-Organization

Each intra-organisation should have the integrated architecture that would enable

inter-organizational system having flexibility and agility. These performances come

from intra-organization as well as inter-organization. So intra-organizational

architecture should support the realization of the inter-organizational one not only by

its own structure, but also by the interfaces it offers to link the external system. Thus

every part of the single system also will have the ability to be agile and flexibility

against the change with this structure.

Transaction loss comes from the rarely understanding of the mapping between the

concepts in business analysis and IT solutions, although some practice is intended to

assist with this problem by connecting these two different aspects of the system in a

precise, automated way through integrating process, assets, and deliverables. As a

whole logical structure, IASI has three layers as from pragmatics, semantics to

syntactic according to the semantic point of view. Each layer describes its own logical

relation separately.

Figure 2 illustrates five key modules in one enterprise system with integrated

architecture style in IASI, which is the core processes of the integrated architecture

and through which how business objects are mapped to IT configuration through logic

structural module is described. The assumption that each module can be abstracted as

sets of signs enables the functions of interfaces being regarded as transforming signs.

The above module which is labelled as Logic Structural Module can help the signs in

the modules follow a same structure to organize the relationship of signs within each

one. Thus, whenever change happens in one context, others can correspond by

following the new logic structural module which is always the first one to reflect the

change. The definitions and interactions of them in IASI are as follows:

• Logic structural module which refers to the pattern how resources, processes

and organizations are organized is considered as an important issue in

architecture design. It is not only used for building close relationship with

business domain through explaining, abstracting and refining the core business

processes and corresponding resources in a logic way, but also affect the

configuration of IT domain through the way how the business objects are

mapped to technological components hierarchically. Thus it connects both of

the domains together with a union logic structure and let components in both

domains interact with each other. It also affects the performance such as

flexibility of the whole system and the ability of tracking of IT significantly.

There are three levels of realization for the logic structural module as: Syntax

which refers to the data level integration which is required to define the order,

length and type of data being exchanged; Semantics which refers to object

level integration which is needed to assign real world subjects and notions to

the transmitted characters; and Pragmatics as process level integration, which

is a feature of sophisticated workflow system ensuring the understanding of

transmitted data and the subsequent actions being triggered.

• Business Logic Module as normal objects that contain only business logic

without having knowledge of any other layers as we know is the way of

continual logical process in an organization, which will obtain logic inspiration

from Logic Structural Module and also communicate with it. Thus it can be

described by the module called Structural Configuration in IT domain through

Logic Structural Module and realizes System Goals Module through interface3

which is the value transformation process.

• Structural configuration describes the structure of IT components and their

communication patterns. It comes from the Logic Structural Module and gives

inspiration to the module as well. Architecture style can be obtained through

abstracting from this module.

• Technologies for integration refer to the leading technologies which will

realize the architecture style as well as integration as a whole. System Goals

describe the business goals of an enterprise and further it will be extended to

the alignment of supply chain partners. These two modules seem to belong to

quite different fields in practical, but in this figure they can be linked together

through being transformed by each interface to the same logic structure. It

shows that the businesses domain and IT domain has close relationship with

each other. Later, the detailed description of the four interfaces in IASI will be

obtained, each of which represents a certain interchangeable process in

different context by applying meta-model to map different models based on

this figure.

4 Discussions and Future Work

An integration architecture called IASI is designed to support common features of

collaboration among enterprises with the function of enabling different levels of

flexibility, isomorphic structure and process integration. In IASI, concept isomorphic

not only needs to be realized in an individual enterprise, but also in an integrated

architecture for multi-organizations to obtain the seamless integration among them.

In IASI, interoperability is gained by the utilization of logic organizational way

module. When collaboration happens among partners, this module will be changed to

a new structure. For example, when procurement happens between manufacturer and

supplier, the module which is a whole logic picture in manufacturer will be changed

to a new one with a linkage as the input process from the supplier. Consequently the

business processes will be added to some new processes as parts of them while the

structural configuration in IT domain will also expand to a wider scope, although

some technologies can realize the collaboration on different platform. If the

architecture of one enterprise is built as IASI described, the collaboration will be

obtained with more flexibility and reliability. Thus the seamless integration is

achieved easily.

The change of organization, process and resource in a single enterprise as well as in

an inter-organizational scope means combining new pieces of structures to the

original structure. When the whole structure is isomorphic, the new information in the

three elements will become an isomorphic structure as well and obtain new place

easily in the original one. At the same time the whole structure won’t be broken into

pieces without logic with IASI.

The ideal situation is that the enterprises have got an isomorphic structure with OPR

before their collaboration so that their architectures needn’t be abstracted and

arranged from different disorder structures to an isomorphic one. In further work,

some agents with different functions enabling the agents to transfer their different

isomorphic structures will be introduced into one generic isomorphic structure.

References

1. Bond, A., Buddy, K., Raymond K., 1998. Distributed Processing: DCE, CORBA, and Java,

In Bernus, P., Mertins, K. and Schmidt, G. (Eds), Handbook on Architectures of Information

Systems. Springer.

2. Chehade, F., 2000. Viacore Works to Become Supply-Chain ’Dial Tone’, Electronics Supply

& Manufacturing, October 19.

3. Cooper, M.C., Lambert D.M., Pagh J.D., 1997. Supply chain management: more than a new

name for logistics. the International Journal of Logistics Management, Vol. 8 No. 1, 1-14.

4. Dyer, J.H., 1996. Effective Inter-Firm Collaboration: How Firms Minimize Transaction

Costs and Maximize Transaction Value. Strategic Management Journal, Vol. 18 No. 4, 535-

556.

5. Gosain, S., Malhotra A., El Sawy O.A., 2004-2005. Coordinating for Flexibility in E-

Business Supply Chains. Journal of Management Information Systems, No. 3, 7-45.

6. Hamilton, D., 1999. Linking Strategic Information Systems Concepts to Practice: Systems

Integration at the Portfolio Level. Journal of Information Technology, Vol. 14, 69-82.

7. Hasselbring, W., 2000. Information System Integration. Communications of the ACM, Vol.

43 No. 6, 33-38.

8. Sandoe, K., Corbitt G., Boykin R., 2001. Enterprise Integration. John Wiley & Sons.

9. Hubert R., 2001. Convergent Architecture: Building Model-Driven J2EE Systems with UML.

John Wiley & Sons.

10. Konicki, S., 2002. Shopping for Savings. Information Week, July 1, 37-55.

11. Linthicum, D.S., 2001. B2B Application Integration: E-Business – Enable Your Enterprise.

Addison-Wesley Longman.

12. Mylopoulos, J., Gal A., Kontogiannis K., 1996. A Generic Integration Architecture for

Cooperative Information Systems, In Proceedings of 1st IFCIS International Conference on

Cooperation Information System, Brussels, 208-217.

13. Puschmann, T., Alt R., 2004. Enterprise Application Integration Systems and Architecture-

the Case of the Robert Bosch Group. The Journal of Enterprise Information Management,

Vol. 17 No. 2, 105-116.

14. Ruh, W., Maginnis F., Boykin R., 2000. Enterprise Application Integration: A Wiley Tech

Brief. John Wiley & Sons.

15. Sambamurthy, V., Zmud, R. W., 2000. Research Commentary: the Organizing Logic for An

Enterprise’s IT Activities in the Digital Era - A Prognosis of Practice and A Call for

Research. Information Systems Research, Vol. 11 No. 2, 105-144.

16. Siau, K., Tian Y., 2004. Supply Chains Integration: Architecture and Enabling Technologies.

Journal of Computer Information Systems, Spring, 67-72.

17. Sobrero, M., Schrader S., 1998. Structuring Inter-Firm Relationships: A Meta-Analytic

Approach. Organization Studies, Vol. 19 No. 4, 585-615.

18. Weill, P., Broadbent M., 1998. Leveraging the New Infrastructure: How Market Leaders

Capitalize on Information. Boston: Harvard Business School Press.

19. Weston, R., Coutts, I., Clements P., 1998. Integration Architecture for Agile Manufacturing,

In Bernus, P., Mertins, K. and Schmidt, G. (Eds): Handbook on Architectures of Information

Systems. Springer. www.ConvergentArchitecture.com

20. Zeng, A.Z., Pathak B.K., 2003. Achieving Information Integration in Supply Chain

Management through B2B E-Hubs: Concepts and Analysis. Industrial Management & Data

Systems, Vol. 103 No. 9, 657-665.