Home
Back
Enterprise Systems

Contributions of Systems Theory to Enterprise Systems: a Review

Song Wang1, Kanliang Wang2

1Xian Jiaotong University, Xian 710049, China
2Renmin University of China, Beijing 100872, China

 

Systems theory and system thinking have emerged as a meta-discipline and a meta-language which can be used to address issues in information systems, enterprise architecture and enterprise integration. So far research on enterprise architecture and enterprise integration has achieved both theoretical progress and practical results with the guidance of systems theory and its analysis framework. This paper reviews the contribution of systems theory to enterprise architecture and integration, summarizes methods or tools at the systems level, and explores how some crucial concepts of systems theory are applied into the enterprise integration activities. Some new prospects in enterprise architecture and integration are also presented to tackle the increasing complexity and changing requirements faced by modern enterprises.

Keywords: systems theory, systems thinking, enterprise information systems, enterprise architecture, enterprise integration

1. Introduction

Systems theory and system thinking are part of the foundations for natural science, social disciplines and engineering practice (Schoderbek et al. 1985, Xu and Li 1989). As the basis for information systems (IS), systems theory and system thinking have been applied to support information systems research (Xu 2000).

In practice, enterprise information systems (EIS) have been used to address some of the crucial challenges faced by enterprises. As systems become more complicated with time, systems theory and its applications in enterprises systems integration will receive more attention (Xu 1995). However, although a lot of studies on EIS, EA (Enterprise Architecture) and EI (Enterprise Integration) have provided us with both theoretical results and empirical findings, the impact of systems theory and/or systemic thinking has not been adequately investigated in literatures. To enhance the research in this area, this paper reviews the contribution of systems theory to EIS, EA and EI, and describes how systems theorists or systems developers view the enterprise information systems.

2.   Evolution of enterprise information systems

Information systems discipline has been established since Börje Langefors firstly introduced the concept of “Information Systems” in 1965 (Janis and Ingemar 2005).  Nowadays information systems have been widely adopted and used by enterprises in all industrial sectors to support business processes and maintain competitive advantage.  

Enterprise information systems (EIS) as complex systems have spanned almost half a century to become the infrastructure of enterprise or companies (Cragg 1995, Chen 1999, Mukherji 2002, Brancheau and Wetherbe 1987, Waldner 1992, Xu 1992, 1995). To help understand the evolution of EIS, the author briefly summarizes the evolution history of EIS in Table 1.

Table 1.   A brief evolution history of EIS

Decade

Main content / Instruments

Approach

1960s~
1970s

Mainframe computers were used, Computers and data were centralized Systems were tied to a few business functions: inventory, billing etc. (MRP)

focus is to automate existing processes

Programming in COBOL
(Information Island)

1980s

PCs and LANs are installed, Departments set up own computer systems (MRPII)

focus is to automate existing processes

Supported by PC
(Basic Networking)

1990s

Wide Area Networks (WANs) become corporate standards Senior management looks for system integration and data integration.
No more isolated information systems. (ERP)

focus is central control and corporate-level management of inventory, manufacturing and distribution

Network supported, Database administration
(Systems Integration)

2000s

Wide Area Networks expand via the Internet to include global enterprises and business partners – supply chain and distribution; Senior management looks for data sharing across systems. (ERPII)

focus is efficiency and speed in inventory, manufacturing, distribution and shift to global decision making

Network supported,
Information architecture to support operation and strategy decision
(Systems Integration)

As you can see from the table, every phase in the past 50 years has its own representative enterprise information systems. Material Requirement Planning (MPR), Manufacturing Resource Planning (MRPII) and Enterprise Resources Planning (ERP) systems have been implemented respectively to control production and planning activities in modern manufacturing enterprises (Enns 2001, Lenny and Saad 2006). They become the central systems in manufacturing environments in which production data such as demand, supply, product, inventory, and accounting, lead-time and routing are stored in an integrated manner.

On the other hand, due to intensive global competition, enterprises are compelled to do their work in a unified way in order to achieve the expected goals including minimizing delays and lowering costs such as inventory costs, production costs, transportation costs and delivery costs. New forms of organizations such as extended enterprises or virtual enterprises (Mowshowitz 1997, O'Leary et al.1997, Wu et al. 2009, Xu et al. 2008, 2009) have also emerged. Today’s business enterprises can be viewed as a network of multiple heterogeneous information sources over which various complex business procedures are executed. Various information systems have been built to automate existing data-intensive business functions such as scheduling and billing which were performed manually in the past. By automating these functions separately, oftentimes an enterprise ends up with many stand-alone systems which do not share relevant information with one another. As a result, it is important to eliminate the so-called “information Islands” in the global competition context.

It is noted that current research and practice in enterprise information systems have not provided business modellers or system architects with a formal system perspective from which business processes can be analyzed in an open, continuous and systematic manner. To close the gap, systemic analysis needs to be conducted.  Systemic analysis is essential for learning about the effect of changes on enterprise architecture, enterprise process logic and business performance measures. Moreover, an underlying formalism would help the enterprise system architect generate holistic views of the enterprise using various levels of abstraction.

Conventional knowledge points to the fact that business results are tied to physical processes by which resources are converted to products that satisfy market demand. However, contemporary enterprise modelling approaches do not adequately reflect the interrelationships between business and production engineering. For example, engineering approaches generally focus on physical conversion at one end of the process spectrum, while business approaches focus on market and financial strategies at the other end. To effectively reflect the interrelationships between business and production engineering, researchers need to look at process design, control, and demand management under the enterprise architecture.

3. Systems theory and systems thinking in enterprise information systems

3.1. Using system theory as a basis to support enterprise information systems

System thinking provides important insights into the role of information systems in the information process that changes data to knowledge. Information systems are often used to serve other systems or support users. When one system is used to serve others, it is necessary to carefully define the nature of the system being served (Checkland 1981, 1999) because how we perceive the system being served will affect the system that provides the service. For instance, an information system that facilitates the accounting process will be quite different from a system that supports the manufacturing operation.

Due to the important role people play in information systems, a systems-based methodology named soft systems methodology (Checkland 1999, Checkland 2000, Checkland 2001, Ackoff 2006) is put forward to address real world problems.  Seven stages were proposed in the methodology:

  1. To enter a situation considered problematical (unstructured);
  2. Express the problem situation;
  3. Formulate root definitions of relevant systems of purposeful activity;
  4. Build conceptual models of the systems named in the root definition;
  5. Compare models with real-world actions;
  6. Define possible changes that are both desirable and feasible; and
  7. Take action to improve the problem situation.

Based on this methodology, an “enterprise information system” can be viewed as a “knowledge attribution system” in which people can select certain data, get them processed and make them meaningful in enterprise contexts to support people engaged in purposeful actions. Therefore, one crucial factor for successful EIS is to provide people with purposeful actions in EIS development and implementation. Kamogawa and Okada (2005) pointed out that enterprise architecture effectiveness should concern the following perspectives especially in e-business context:

  1. Creating a Governance model is a central success factor since not only in-house enterprise but also inter-enterprises should maintain the integrity of their business processes with each other.
  2. Developing flexible architecture for business information architecture is necessary since e-business requires high performance and ability to process high data volumes.
  3. Driving Enterprise Architecture cognition for senior management level is a high priority. Taking into account the membership involved in EIS development is essential since activities for developing Enterprise Architecture are conducted thorough inter-enterprises as wet1 as in-house enterprise, and since it is hard to communicate with the related parties, including corporate executives like CEO, COO, and CIO.

Therefore, the seven-stage soft systems methodology may be a useful reference when people participate in the enterprise information systems integration.

3.2. Approach Shift in Enterprise information System Development

Traditional systems development approaches (bottom-up, structural design and analysis) have a great impact on the construction methodologies of Information Systems Development (ISD). Such views seemed slightly old-fashioned because it believes that ISD should be accomplished in a systematic manner and tasks should be accomplished in a natural and logical order. Therefore, ISD work is usually divided into a set of manageable phases and steps in order to build and shape new IT systems. Each phase requires different types of expert knowledge. The conventional systems approach has been regarded as a core theory in ISD field.

Due to rapid changes in software, hardware and commercial environments (formation of global supply chain, trans-organization cooperation and emerging of virtual enterprise combine), the distributed and network approach has evolved and become increasingly important in ISD, which is testified and verified by industrial utilization in business or public administration (Li et al. 2008, Xu et al. 2008, Xu et al. 2009). To some extent, the network approach can be seen as a special systemic approach.

In addition,  it is noted that information systems and relevant business processes can be regarded as a complex and multidimensional super-system. For example, human-centric processes (Customer Relationship Management, CRM) or specifications outside of enterprise boundary (Supply Chain Management, SCM) have an influence on ISD too. Thus, this multi-perspectives view will become a generic approach within which systemic and network thinking serve as the basis. Hereby, the so-called multi-perspectives approach can be seen as an extension of conventional systems development.

4. Systems perspectives on enterprise architecture

Enterprise architecture as a framework or systemic design methodology is widely exercised across many fields. According to Rohloff (2005), the term "enterprise" refers to the scope of the architecture which deals with an organization as a whole or multiple agencies rather than a certain organizational part or individual components and/or projects (Versteeg and Bouwman 2006). The term "architecture" is based on the statements how an enterprise exploits IT to save operational cost and to enhance responsiveness. Thus, the strategic aspects of IT systems provide the contexts for the architectural design choices and decisions. Architecture aims at creating some kind of structures in a chaotic environment using systematic approaches (Armour and Kaisler 2001). Enterprise Architecture is often considered to be an organizing logic for business processes and IT infrastructure and reflects the integration and standardization requirements of the firm’s operating model (Weill 2007).

4.1. Synthesis

System theories are concerned of the relationship between parts and the whole. For an organization, departments and business units or service providers are the parts and the corporation itself is the whole (Xu 1992, Xu 1995, Lee et al. 2005, Vinay and Sreedhar 2006, Repoussis et al. 2009). Although a system may be composed of separate parts, the function of a system can not simply achieved by the sum of functions provided by each part or subsystems. That means that the whole enterprise system can accomplish certain functions which individual parts of the system cannot. This phenomenon is called the whole affectivity in enterprise systems. According to systems theory, synthesis of EIS with enterprise scope has two fundamental facets:

For instance, many manufacturers use Computer-Integrated Manufacturing Systems (CIMs) (Chalmers 1999, Ng et al. 1998, Waldner 1992, Thacker 1989, Hsu et al. 1995) to facilitate their operation and decision. CIMs typically entails multiple information systems. Each system itself needs to meet its own functional requirements while collectively these systems must work together and form an integrated environment for the enterprise as a whole.

The EA identifies the scope of individual systems (or subsystems, services, applications) and the boundaries between them. EA is essentially a planning activity rather than a development activity, whereas the distinctions between these two activities are often overlooked in practice. Oftentimes, organizations focus on the wrong sets of issues in developing enterprise architecture. As a result, organizations get little value from it. In practice, two basic problems in synthesis actions often occur:

Thus, organizations often pay too much attention to the functionality of individual systems rather than the interconnections between them. Therefore, the balance between the cost of EA deployment and the efficiency EA could provide should be considered during the EA planning stage.

4.2. Mapping and abstraction

Traceability is challenging in many respects of EA development regardless of its lifecycle phase. The challenge of mapping the objectives (which we define as business needs, risks, system issues, change cases, and nonfunctional requirements) to specific architectural elements is unmanageable. We need a simpler way to ensure that the architecture meets its objectives (Patankar and Adiga 1995, Iyer and Gottlieb 2004, Tyree and Akerman 2005, Bala et al. 2005, David and Ali 2007). To alleviate the challenge, the operation of enterprise systems can be defined as the "Management Domain". The underlying IT/IS can be defined as the "IS Domain". The Domain of Mapping thinking can be utilized to guide the Enterprise Architecture efforts ranging from analysis, design and evaluation of EA and EI.


Management Domain composes of particular activities or processes penetrating operation of enterprises including various functionalities, different management means or processes, message communication mechanism, decision procedures and monitoring-feedback mechanism etc. Management Domain is the platform on which logistics, capital and information circulate. IS Domain means the hardware infrastructure, software architecture, and functional models, which is the conceptual and logic reality of the enterprise based on information technology.  The mapping between these two domains can be realized through abstraction.

4.3. Hierarchy and granulitization

Hierarchy are always one of the most import issues in EA. EA designers and information systems developers should not only be aware of the existence of subsystems and interactions, but also be able to identify the types and hierarchical functionalities of subsystems and interactions among them to confirm their level of abstraction. However, it is difficult for developers and users to outline application systems and understand the details of managing these systems (Xu 1987, Stamatelopoulos and Maglaris 1999, Shafiei and Sundaram 2004, Lam-Son and Alain 2005, Chen et al. 2008). For example, when value chains are extended beyond an enterprise and supplier and customer systems have their own information architectures, data are distributed over a multitude of heterogeneous platforms and the communication among these platforms become harder to be tracked. To settle this issue, a traditional way is to divide the enterprise and its stakeholders using a layered framework which includes conceptual layer, business layer, technology layer, etc. With the rapid transformation in the organizational structure, a horizontal integration of the layers is required to support the business processes effectively (Hasselbring 2000).

Enterprise architecture provides ways to deal with the complexity including work (who, where), function (how), information (what) and infrastructure (how to) (Janssen and Kuk 2006). From the novel hierarchical perspective, enterprise architecture can accommodate inter-organizational processes, integrate independent ERP via some messaging approach to achieve higher performance without discarding the legacy systems. The hierarchical layers provide modeling mindset which is helpful not only on developing enterprise information system but also on evaluating performance of EA (Zachman 1997, Kaetker and Geihs 1997, Checkland 1999, Peristeras and Tarabanis 2000, Lerina et al. 2001, Alain and Otto 2003, Chu et al. 2002).

From the systemic perspective, granulitization means to extract notable characters by screening the features of lower levels and thus to form a new interpretation or vision of the system. The granulitization approach has become the implicit design method or analysis guideline (Zachman 1987, 1997). With respect to the idea of EA, granulitization plays a fundamental role on the creation of architectural principles, imposed constraints upon the organization, and the decisions in support of realizing the business strategies.

4.4. Framework and modeling

Enterprise framework specifies how information technology is related to the overall business processes and outcomes of organizations, and describes relationships among technical, organizational, and institutional components of the enterprise (Fayad et al. 2000, Richardson et al. 1990, Yang et al. 2005). Enterprise framework also provides methodological support to model activities within enterprise architecture. Some systemic views of framework are listed below:

    1. Functional View is used to describe functional specifications (e.g. user behavior and application requirements). System architecture refers to the architectural model adopted. In the case of EIS, multi-tiered client-server models are described. Services provided by each application tier (called modules) are also defined. User behaviours are modelled through user profiles which define the behaviour of different user groups and their performance requirements.
    2. Topology View facilitates the definition of system access points and the resource allocation and replication. The term ‘site’ is used to characterize any location (i.e. a building, an office, etc.). A site is a composite entity which can be further divided into sub-sites. Functional and topology views are related.
    3. Physical View refers to the aggregate network (hardware instruments or interfaces). Network nodes are either workstations allocated to users or server stations running server processes. Topology and Physical views are interrelated.

    Below are several other enterprise architecture frameworks as well:

4.5.    Adaptivity of complex system

The core idea of Complex Adaptive Systems (CAS) rests on a perspective of systems composed by individual adaptive agents that interact with each other and communicate with their environment in dynamic fashion (Auyang 1998, Railsback 2001, Tiwari and Mondal 2002). Most of the work in CAS has been conducted in highly abstract and artificial systems (Ackoff 2006). Furthermore, Desai (2005) proposed "adaptive complex enterprise (ACE)" to differentiate between Holland’s complex adaptive systems (Holland 1996). ACE depicts that many human-designed systems and processes are not complex and the focus should be on the complexity of non-designed processes, interactions and relationships in addition to systems. The emphasis on the untraditional processes reflects the reality of practice in enterprise systems architecture; it informs that those service or processes outstripping traditional enterprise scope should be taken into account under the complexity framework.


Adaptability of EA means the ability of an EIS to cope with changes in local systems. Adaptability can be measured by determining the effort that is required to modify the EIS design and structure to cope with these changes. The less effort is required, the more adaptable the EIS is (Fazlollahi et al. 2006, Oreizy et al. 1999, Graham et al. 2003; Sanchez 1999, Baldwin and Clark 2000, Bernus 2003, Koh and Gunasekaran 2006, Arroyo et al. 2008). Flexibility of EA means that an EIS can satisfy the changing requirements from different levels of enterprise. As for the holistic enterprise, response to rapidly changing environment requires flexibility in strategic processes supported by flexible infrastructures (Evans 1991, Mark et al. 2000, Tiwari and Mondal 2002, Carlos et al. 2008). However, the costs of flexibility are not well identified (Desai 2005, Eardley et al. 1997). Thus, if an organization wants to acquire the benefits of a complex adaptive system, the configuration of its enterprise architecture has to meet the balance between excessive control and zero control, and allow both flexibility and adaptability.

5.   Enterprise integration and the application of systems theory

Thacker (Thacker 1989) defines integration as ‘the information required by each activity available on a timely basis, accurately, in the format required, and without asking’. Petrie (1992) implicitly assumes a broader concept of integration in the following definition: ‘EI is the task of improving the performance of large complex processes (Patankar and Adiga 1995, Petrie 1992, Dennis et al. 2002).

5.1.    Integration modes

Enterprise information systems can be viewed as the federal aggregation of multiple components (such as applications, services or modules even sub platform). From the systemic perspective, the mode via which these components communicate and exchange information is a proactive activity. According to some literature (Gudivada and Nandigam 2005, Bauer et al. 2008, Camarinha-Matos et al. 1999, Vinoski 2002, Lankhorst 2004, Martin et al. 2005, Zhou et al. 2005, David and Ali 2007, Contreras and Sheremetov 2008, Repoussis et al. 2009, An et al. 2008, Song et al. 2008, Tan 2008), three basic integration modes can be acquired (see Figure 1). (a) Peer-to-peer integration: P-to-P communication between individual IT applications; (b) Broker-based integration: broker acts as an integration hub with middleware between IT applications and broker enables real-time processing; (c) business-process integration: extend broker-based integration with knowledge of business process. Business process model captures workflow between IT applications and humans. Obviously, each kind of integration mode has its own capabilities and limitations.

a3_image01

Figure 1. Three basic integration modes

5.2. Fashions and platform selection

Enterprise integration can be approached in various ways (Vernadat 1996, Iyer and Gottlieb 2004, Ng et al. 1998, Ross et al. 2004, Carlos et al. 2008). CEN TC310 WG1 has recognized three levels of integration:

  1. Physical Integration (interconnection of devices, NC machines, etc via computer networks);
  2. Application Integration (dealing with interoperability of software applications and database systems in heterogeneous computing environments); and
  3. Business Integration (coordination of functions that manage, control and monitor business processes).

Chen and Vernadat (2004) consider that integration can be achieved in terms of (1) data (data modelling), (2) organization (modelling of systems and processes) and (3) communication (modelling of computer networks, for example the 7-layer OSI model). Integration can also be achieved by unification (the possible standards are methods, architectures, constructs and reusable partial models) or by federation (the possible standards are interfaces, reference models or ontology).


From the view of systems development, a layered integration framework is more useful and practical (See Table 2). Integration activities in an enterprise could be demarcated into the following categories: Business integration; Application integration and Data integration.

5.3.    Diagram and mechanism
5.3.1.   Synergy and interoperability

The aggregation of enterprise information systems is widely used to resolve the problem of “Information Islands”. Based on the synergic theory, the aggregation framework of enterprise information systems should be able to emerge with the holistic functionality beyond what the subsystems could provide individually. Thus, a rational systemic approach is to build the enterprise integration platform (EIP). The inner synergy needs to build EIP to aggregate the information from different resources, to keep the seamless linkage between varied processes and applications in lower levels, and to facilitate the complex services in higher levels. The final outcome of EIP is the modules. All of these calls for EIS to ensure the interoperability that penetrates most of the computing actions and business partners.

Table 2.   The layered integration fashions and platforms

Integration
objectives

Integration mechanisms/
Platform architecture

Strategy level

Scope

Cross Organization

Collaborative Software,
Strategy Information System

Strategic Layer

a3_image02

Inter-organizational Decision

Collaborative Software, DSS KM System, SOA

Processes
(internal & external to enterprise)

OLAP, Workflow, Enterprise Reference Architectures,
CORBA, COM, SOA, SCM, CRM, Web Service

Tactical Layer

a3_image03.jpg

 

Applications (Services)

Inter-processes Communication,
Remote Procedure Calls,
Data Warehouse, OLAP, CORBA, SOA, ERP, Web services

Operational Layer

Data

Data Dictionaries, Database, XML

Interoperability can be defined as the ability for information systems and the business processes they support to exchange data and enable sharing of information (Papazoglou and Georgakopoulos 2003, Dennis et al. 2002, Graham et al. 2003, Daniel et al. 2007, Song et al. 2008). They are faced with programs (software or applications) at different levels (vertical) and different functions (horizontal) of information governing. IDABC advanced the European Interoperability Framework (Puschmann and Alt 2001), which suggested that the solution to the interoperability problems should follow the same standardized framework for organizational, semantic and technical interoperability. From the systems perspective, technical interoperability plays fundamental role in integration. It requires functional or technical compatibility among protocols or interfaces of primary specifications on data and applications. Interoperability can be easily realized if stakeholders perform imilar functions. On the other hand, semantic interoperability (focusing on what to integrate) is different from technical interoperability (focusing on "how" to do integration). The IEC standard (IEC 2000) confirmed the concept of interoperability in the context of software engineering as a level of compatibility. According to this standard, interoperability should be realised if the interaction can exist in at least one of the three levels: data, functionalities and process (behaviour) (Izza 2009).

5.3.2.   Heterogeneity and connectivity

Generally speaking, integrating information systems means bridging communication among these systems. It is better to view EIP as an infrastructure in terms of supporting inter-applications communication and generic shared services. To provide a unified and consistent vision of these data entities and to provide information connectivity across multiple platforms (Lyman 1995, Siegel and Madnick 1991), a systemic analysis on the applications needs to be considered in the platform selection:

  1. Homogeneous with one instance: One process is supported by one application and one data base. This model avoids the problems emerging from redundant data storage and asynchronous data exchange between separated applications.
  2. Homogeneous with several instances: Several identical processes in different business units are supported by several identical applications that run on different computers and rely on logically separated data bases.
  3. Heterogeneous: Several different processes in different business units are supported by several different applications.

Integration of EIS is important to most large and dynamic industrial enterprise. Thus, Integration of EIS must deal with heterogeneity which involves multiple software applications in the settings of enterprise level information systems. A feasible systemic thinking is to decompose all these applications to their real ontology and interactive relationship. Izza (2009) focused on some semantics-based approaches that promote the use of ontologies such as OWL-S service ontology. The results show that the service-oriented approach can be a flexible way to facilitate integration with respect to dynamism.


As for the connectivity, middleware typically serves to connect or mediate between two separate existing programs (Charles 1999, Geihs 2001, Bougettaya et al. 2006). Many companies are now developing enterprise-wide information systems by integrating previously independent applications, which are legacy applications. A legacy application can only be accessed via its specific interface, and cannot be modified. Furthermore, the cost of rewriting a legacy application is high. On the other hand, many systems are composed of various devices interconnected by network, where each individual device performs a function that involves both local interaction with the real world and remote interaction with other devices of the system. In these situations, applications can use middleware and communication protocols to ensure that applications can be easily composed, reused, ported. A common application of middleware is to allow programs written for access to a particular database to access other databases. Typically, middleware programs provide messaging services so that different applications can communicate with one another.

5.3.3.   Reusability and scalability

There are two types of software systems:

Scalability is a common requirement for ERP systems. An enterprise information system must be able to facilitate the strategic development of a company for many years. Scalability is needed to accommodate expanded management functions. A scalable system is essential for enterprises to meet rapidly expandable requirements and also needs to be flexible for economic downturn (Kishore et al. 2006, Panetto and Molina 2008, Chen et al. 2008, Lankhorst 2004, Bernus 2003, Radha 2005, Mirja et al. 2007).

5.3.4.   Agility

As a view of information systems, agility represents new ways of running businesses. Agility is a never-ending quest to do things better than the competition (Gunasekaran and Yusuf 2002, Sharp et al. 1999, Koh and Gunasekaran 2006, Vinay and Sreedhar 2006). Agility should meet different demands or emergent events and should have many facets as follows:

  1. Proactivity, which means an entity has the ability to take steps before the change and the ability to response to the change. SOA architecture has some potential on this facet (Daniel et al. 2007).
  2. Reactivity, which is the most common interpretation of agility, defined as the ability to adapt to unexpected impacts or changes.
  3. Learning, which is the most distinct attribute of agility (Goldman et al. 1995, Mark et al. 2000, Erol et al. 2010).

A way for systemic thinking to enhance the whole agility of EIS is to ascribe the proactivity, reactivity and leaning ability to its basic and elementary components. With the software architecture stepping into SOA and the adoption of radio frequency identification (RFID), events processing can be embedded in enterprise information systems to facilitate event aggregation into high level actionable information and eventually improve the total responsiveness of EIS.

5.4.    Dimension and technical issues

Dimensions of the integration standards and specifications are crucial problems in EI. The dimensions can be identified along the lines of three orthogonal dimensions:

  1. Business logic dimension - implementing the business rules that regulate the business processes of an application system.
  2. Applications logic dimension - offering the ability to manage the interactions between an application system and its various presentation interfaces such as web browsers, mobile computing devices, clients and terminals.
  3. Data logic - providing the capability to access and map data into a form (or data structure) that can be managed by business logic.

The dimension issues of EI are closely corresponded to the EA hierarchical design. (Chari and Seshadri 2004). Meanwhile the implementation of enterprise integration planning (EIP) requires a systematic approach to represent business, applications (services), and technology perspectives. A systematic approach should provide specific tactical solutions including budgets, project plans, and a comprehension of infrastructure issues such as processors, storage, networking, data management etc.


To acquire more distinct relationship between the technical issues, the author present an integration model on EIP (Figure 2) based on literature review (Lee et al. 2005, Daniel et al. 2007, Song et al. 2008). Requirements and regulations confirm the business drivers and enactments and are critical to the development of the EI. Each functional and non-functional requirement (Connectivity, Process support, Data exchange, Security, QoS) should be traced to one or more business drivers (Hong et al. 2007). Organizations are becoming more aware of the need for capturing and managing requirements due to fierce competition. Control integration deals with different rules of messaging between applications and how these messages are managed based on different communication modes and protocols. Connectivity refers to data, workflow and service linkage and how these linkages are handled by application bridges and gateways, message-handling services, and other communication protocols. Quality attributes involve architectural decisions that influence quality characteristics such as performance, dependability, and security. Quality attributes span several aspects of the integration model.

a3_image04.jpg

Figure 2. Overall integration model of EIP

6.   Conclusions

A major challenge in EA and EI is to conquer systems complexity (Computing Research Association 2003). Meeting this challenge requires a reform throughout all levels of enterprise, ranging from design mindset to implementation activities in practice. The systems theory and systems thinking as primary theoretical basis can provide a multidimensional and hierarchical vision and methodology for the EA and EI, which is the major objective of this paper. This paper demonstrates that systems theory can provide concrete support to EA and EI activities. Building better enterprise systems requires us to put the enterprise back into enterprise systems (Davenport 1998). This means that both researchers and practitioners should adopt a systemic view to make decisions.


The growing popularity of e-Commerce, internet technology and the phenomenon of globalization have increased the demand for collaborative and extended enterprise applications. Hence, an enterprise architecture which can span across the entire value chain to provide value-added services is in great need. Additionally, a robust but adaptive enterprise system with cogent agility will be welcomed in the future. As for the conventional systems architecture, innovations that can exploit the legacy systems and reduce the cost of integration will be greatly needed. In summary, all of the above requirements in novel EA and EI development require further application of systems theory into enterprise information system.

Acknowledgements

This work is partially supported by National Natural Science Foundation of China (NSFC) under the grant #70890080, 70890081 and #70971107.

References