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
Copyright
c
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],
71
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
72
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.
73
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
gy
Pro
j
ect Com
p
onent
Intra-or
g
anization 1
Technolo
gy
Pro
j
ect Com
p
onent
Process Resource
Organization
Intra-or
g
anization 2
Integration
Inter-organizational business
Technologies for integration
IT domain
Business domain
74
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
75
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
76
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.
77
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.
78
