Architecture of Interoperable Information Systems

Last updated
Architecture of Interoperable Information Systems Architecture of Interoperable Information Systems.gif
Architecture of Interoperable Information Systems

The Architecture of Interoperable Information Systems (AIOS) is a reference architecture for the development of interoperable enterprise information systems. If enterprises or public administrations want to engage in automated business processes with other organizations, their IT systems must be able to work together, i.e. they need to be interoperable. The AIOS represents a generic building plan for these organizations to develop interoperable information systems by systematically adjusting and extending their internal information systems. The AIOS was described in a doctoral thesis and is based on the results of various research projects on interoperability. [1] It is independent from specific products or vendors but describes generically the different layers, views, relationships and technical means needed to efficiently establish interoperable information systems. To this aim it combines concepts from service-oriented architecture, Collaborative Business and Business Process Modelling. It can be seen as complementary to ARIS, a well-known architecture for internal information systems and business processes.

Contents

Definition

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.

Background and Application

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.

Structure

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

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.

  1. The private view comprises the only internally visible information system elements.
  2. 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. This public view describes the information system boundaries of an organization to its collaboration partners and connects internal and external information systems, thereby also providing the content of the Business Interoperability Interface of an organization.
  3. The global view can be used to correlate and connect the public views of different systems.

Enterprise dimensions

Illustration of the Architecture of Interoperable Information Systems / Enterprise Dimensions AIOS Enterprise Dimensions.JPG
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 AIOS Levels of technical detail.JPG
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.

Related Research Articles

<span class="mw-page-title-main">Interoperability</span> Ability of systems to work with each other

Interoperability is a characteristic of a product or system to work with other products or systems. While the term was initially defined for information technology or systems engineering services to allow for information exchange, a broader definition takes into account social, political, and organizational factors that impact system-to-system performance.

Enterprise architecture (EA) is a business function concerned with the structures and behaviours of a business, especially business roles and processes that create and use business data. The international definition according to the Federation of Enterprise Architecture Professional Organizations is "a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes."

<span class="mw-page-title-main">Architecture of Integrated Information Systems</span>

The ARIS concept by August-Wilhelm Scheer aims to ensure that an enterprise information system can completely meet its requirements.

<span class="mw-page-title-main">Department of Defense Architecture Framework</span> Enterprise architecture framework

The Department of Defense Architecture Framework (DoDAF) is an architecture framework for the United States Department of Defense (DoD) that provides visualization infrastructure for specific stakeholders concerns through viewpoints organized by various views. These views are artifacts for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through tabular, structural, behavioral, ontological, pictorial, temporal, graphical, probabilistic, or alternative conceptual means. The current release is DoDAF 2.02.

A federal enterprise architecture framework (FEAF) is the U.S. reference enterprise architecture of a federal government. It provides a common approach for the integration of strategic, business and technology management as part of organization design and performance improvement.

<span class="mw-page-title-main">Systems architecture</span> Conceptual model of a system

A system architecture is the conceptual model that defines the structure, behavior, and more views of a system. An architecture description is a formal description and representation of a system, organized in a way that supports reasoning about the structures and behaviors of the system.

The British Ministry of Defence Architecture Framework (MODAF) was an architecture framework which defined a standardised way of conducting enterprise architecture, originally developed by the UK Ministry of Defence. It has since been replaced with the NATO Architecture Framework.

<span class="mw-page-title-main">Enterprise architecture framework</span> Frame in which the architecture of a company is defined

An enterprise architecture framework defines how to create and use an enterprise architecture. An architecture framework provides principles and practices for creating and using the architecture description of a system. It structures architects' thinking by dividing the architecture description into domains, layers, or views, and offers models – typically matrices and diagrams – for documenting each view. This allows for making systemic design decisions on all the components of the system and making long-term decisions around new design requirements, sustainability, and support.

<span class="mw-page-title-main">Business architecture</span> Business discipline

In the business sector, business architecture is a discipline that "represents holistic, multidimensional business views of: capabilities, end‐to‐end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders."

In information systems, applications architecture or application architecture is one of several architecture domains that form the pillars of an enterprise architecture (EA).

<span class="mw-page-title-main">ArchiMate</span> Enterprise architecture modeling language

ArchiMate is an open and independent enterprise architecture modeling language to support the description, analysis and visualization of architecture within and across business domains in an unambiguous way.

<span class="mw-page-title-main">View model</span>

A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of the whole system from the perspective of a related set of concerns.

<span class="mw-page-title-main">Operational View</span> Component of Departement of Defense Architecture Framework

Operational View (OV) is one of the basic views defined in the enterprise architecture (EA) of the Department of Defense Architecture Framework V1.5 (DoDAF) and is related with concept of operations. Under DODAF 2, which became operational in 2009, the collections of views are now termed 'viewpoints' and no longer views.

<span class="mw-page-title-main">TAFIM</span>

Technical Architecture Framework for Information Management (TAFIM) was a 1990s reference model for enterprise architecture by and for the United States Department of Defense (DoD).

<span class="mw-page-title-main">NIST Enterprise Architecture Model</span> Reference model of enterprise architecture

NIST Enterprise Architecture Model is a late-1980s reference model for enterprise architecture. It defines an enterprise architecture by the interrelationship between an enterprise's business, information, and technology environments.

<span class="mw-page-title-main">ISO 19439</span> International standard for enterprise modelling and enterprise integration

ISO 19439:2006 Enterprise integration—Framework for enterprise modelling, is an international standard for enterprise modelling and enterprise integration developed by the International Organization for Standardization, based on CIMOSA and GERAM.

Enterprise interoperability is the ability of an enterprise—a company or other large organization—to functionally link activities, such as product design, supply chains, manufacturing, in an efficient and competitive way.

A business interoperability interface (BII) is an interface that enables business interoperability between organizational systems. The term was coined by the European Commission in the European Interoperability Framework where such interfaces are recommended to improve the interoperability of public administrations that internally use different standards.

<span class="mw-page-title-main">Praxeme</span>

Praxeme is a methodology for enterprise architecture which provides a structured approach to the design and implementation of an enterprise information architecture.

Model Driven Interoperability (MDI) is a methodological framework, which provides a conceptual and technical support to make interoperable enterprises using ontologies and semantic annotations, following model driven development (MDD) principles.

References

  1. Ziemann (2010): Architecture of Interoperable Information Systems - An enterprise Model-based Approach for Describing and Enacting Collaborative Business Processes. Logos, 2010. Logos was so kind to permit the free download of a copy here. A summary can be found here: Ziemann (2012): Architecture of Interoperable Information Systems - Reference Architecture for Collaborations between Public Administrations. In: Krallmann, H., Zapp, A. (Eds.): Bausteine einer vernetzten Verwaltung. Berlin, Erich Schmidt Verlag, 2012, pp. 165.
  2. Compare for example Becker & Schütte (2004, p. 33): Handelsinformationssysteme – Domänenorientierte Einführung in die Wirtschaftsinformatik 2nd Edition, Redline Wirtschaft, Frankfurt or Gabriel(2008): Informationssystem. Enzyklopädie der Wirtschaftsinformatik, Online Lexikon. Oldenbourg Wissenschaftsverlag, Germany.
  3. IEEE (2007): IEEE 1471 Website, IEEE Std. 1471 Frequently Asked Questions (FAQ) - Version 5.0, 19 July 2007. http://www.iso-architecture.org/ieee-1471/ieee-1471-faq.html Archived 2011-08-28 at the Wayback Machine , ac-cessed: May 2009
  4. Sinz (2002): Architektur von Informationssystemen. In: Rechenberg, P., Pomberger, G. (eds.): Informatik-Handbuch. 3rd Edition, Hanser, München, pp. 1055-1068
  5. Interop NOE (2004 to 2007, project number IST-2004-508011), ATHENA (2004 to 2007, “Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Application”, project number IST-2004-507849) or R4eGov (2006 to 2009, project number IST-2004-026650)