Architecture of Interoperable Information Systems

Similar to the automation of processes inside organizations, the automation of cross-organizational business processes is an important trend. In this endeavor, collaborating organizations rather strive for a loose coupling of their information systems instead of a tight integration: the collaborating information systems should be able to work together but retain as much independency as possible. This characteristic is also called interoperability, or in the context of collaborating organizations, Business Interoperability, i.e. the capability of autonomous organizations to execute a collaborative business process among them.

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 for example also embodied by the Zachman Framework.

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 can be defined as the building plan of a cross-organizational information system, which enables organizations to execute a collaborative business process among them.

Following the work on interoperable information systems conducted in European Research Projects[5] in 2010 the Architecture of Interoperable Information Systems (AIOS) was published as a reference for the construction of loosely coupled, interoperating information systems and for the systematic, model-based enactment of collaborative business processes.

The AIOS aims primarily at large organizations that want to interoperate with each other. To this aim it describes how internal information system elements can be systematically connected with the information systems of collaboration partners. The main elements of the AIOS are:

1. Description of the different data types comprised in interoperable information system as well as their relationships. This is also called the static part, or the structure of the architecture. It tells organizations which information elements (e.g. descriptions of messages, exchange sequences, roles and services) they have to provide to collaboration partners and how they can optimally correlate these to internal elements.
2. Description of different building paths for implementing or adjusting interoperable information systems. This is also called the dynamic part of the architecture. It tells organization, how to iteratively develop the elements mentioned above.
3. Concept for the technical components needed to implement the architecture, for example design tools, internal and externally visible repositories.

One element comprised in the third category is a "BII-repository", in which each organization publishes the content of its Business Interoperability Interface (BII) to collaboration partners. Since it comprises external views on information system elements, it provides publishing and discovery functionalities as needed in service-oriented architecture: In the BII, the externally relevant processes, services, organization structures etc. are described on various levels of technical granularity, enabling other organizations to search also for business-level elements and not only for technical artifacts. Here, different from the traditional SOA approach, instead of one central service directory, various partner-specific repositories are implemented.

The static part of the architecture builds on three orthogonal axes: Enterprise Dimensions, Levels of technical Granularity and Colloborative Views.

Enterprise dimensions

Illustration of the Architecture of Interoperable Information Systems / Enterprise Dimensions

To describe business processes comprehensively this axis provides distinct views on processes, functions, data, and organizational elements.

1. In the organizational 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.
2. In the data dimension, document types used in the collaboration are defined and related to internally used document types.
3. In the function dimension, business functions and services offered in the collaboration are described.
4. 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.

Thus, in combination with the axis "collaborative views", private, public and global views on processes, functions, data, and organizational roles are provided.

Levels of technical granularity

AIOS Levels of technical detail

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, thereby also a multi-dimensional interoperability description is provided, facilitating the synchronization of collaborating systems on each level. Similar to for example ARIS and OMG's 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 be used during runtime in the execution of processes.