Architecture of Interoperable Information Systems

This is an old revision of this page, as edited by ISresearcher (talk | contribs) at 10:01, 17 June 2012 (Reference Architecture). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

This sandbox is in the article namespace. Either move this page into your userspace, or remove the {{User sandbox}} template.

Architecture of Interoperable Information Systems

An Architecture of interoperable information systems describes how interoperating information systems can be efficiently designed and implemented. Since the invention of information system many concepts were created to foster interoperability between different kind of information systems. In 2010, under the name "Architecture of Interoperable Information Systems" (AIOS) a reference architecture for interconnecting enterprise information system was published[1]. It combines concepts from Service-oriented Architecture, Collaborative Business and Business Process Modelling. Regarding the last aspect it be seen as complementary to the Architecture of Integrated Information Systems, which is a wide-spread architecture for describing information systems and business processes inside one organization.

Definition

Interoperability

The automation of cross-organizational business processes is one of the most important trends of the information age. lnstead of a tight integration however, collaborating organizations rather strive for a loose coupling of their information systems. The information systems should be able to work together but retain as much independency as possible. This characteristic is also called interoperability. In the context of collaborating organizations, the term Business Interoperability was proposed. In comparison to technical interoperability notions, this term refers to the capability of autonomous organizations to execute a collaborative business process among them.

Information System

Information systems are systems that process information, i.e. they capture, transport, transform, store and offer information. Following the conception prevailing in information systems research, an information system comprises not only the hardware and software of an enterprise, but also the related human actors, business functions and processes as well as organization structures.[2]. This broad understanding is also embodied by the often-referenced Zachman Framework.

Architecture of Interoperable Information System

Architecture is defined as the “fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution”[3]. Sinz defines an information system architecture as the building plan of an information system in the sense of a specification and documentation of its components and their relationships covering all relevant viewpoints as well as the constructions rules for the creation of the building plan[4]. Accordingly, an Architecture of Interoperable Information Systems is the building plan of an cross-organizational information system, which enables the organization to execute a collaborative business process among them.

Reference Architecture

 
Architecture of Interoperable Information Systems

Following the work concucted in European Research Projects (e.g. [5]) on interoperable information systems, in 2010 the Architecure of Interoperable Information Systems (AIOS) was published [6] as a reference for the construction of loosely coupled, interoperating information systems and for the systematic, model-based enactment of collaborative business processes.
At the core of the architecture lies the Business Interoperability Interface, which describes the information system boundaries of one organization to its collaboration Partners and connects internal and external information systems. The architecure builds on three orthogonal axes: Enterprise Dimensions, Colloborative Views and Levels of technical Granularity.



Enterprise dimensions

To describe business processes comprehensively this axis provides distinct views on processes, functions, data, and organizational elements. In the organization dimension, roles, units and other organization elements relevant for the collaboration are described and related to internal elements. This ensures for example, that the collaboration partners have a common understanding of the interacting roles. In the data dimension, document types used in the collaboration are defined and related to internally used document types. In the function dimension, business functions and services offered in the collaboration are described. In the process dimension, the processes that each organization offers are described as well as how these public processes are related to adjacent processes of partner organizations.

Collaborative views

Similar to private, public and global views as known from business process and workflow modeling, in the AIOS, corresponding private, public and global views on information system elements are provided. The public view acts as an interface to the internal, private system elements; it protects internal systems and enables interoperability without the need for a significant change to the internal systems. The global view can be used to correlate and connect the public views of different systems.

Levels of technical granularity

The description of system elements on different levels of technical granularity supports a systematic development of collaborative information systems, starting with the business requirements definition and going all the way down to the code level. Apart from the construction aspect, a multi-dimensional interoperability description is also provided; describing the interacting systems on different levels of technical granularity enables the synchronization of the collaborating systems on each level. Similar to for example ARIS and MDA three levels are used:

  1. Business Level: Here the processes to be automated are described from a technique independent level. In MDA this level is referred to as CIM level.
  2. Technical Level: Here the IT concept is described. Therefore, the models from the first level are technically enriched, for example, instead of business functions now components are described, but still on a coarse-grained, conceptual level. Since the models on the second level represent the basis for an automated generation of executable code, they might have to be further adapted to fit implementation level constraints.
  3. Execution Level: Here the models are machine interpretable and can used during runtime in the execution of processes.

References

  1. ^ Ziemann (2010): Architecture of Interoperable Information Systems - An enterprise Model-based Approach for Describing and Enacting Collaborative Business Processes
  2. ^ Compare BECKER & SCHÜTTE (2004), p. 33, and GABRIEL (2008)
  3. ^ IEEE (2007)
  4. ^ Compare SINZ (2002), p. 1055.
  5. ^ R4eGov, ATHENA, Interop NOE
  6. ^ Ziemann 2010