Architektur interoperabler Informationssysteme

Die Architektur interoperabler Informationssysteme (AIOS) ist eine Referenzarchitektur für die Entwicklung von interoperablen Informationssystemen. Wenn Unternehmen oder öffentliche Verwaltungen organisationsübergreifende Geschäftsprozesse implementieren wollen, müssen die IT-Systeme der Organisation in der Lage sein zusammenzuarbeiten; in anderen Worten: Die Informationssysteme müssen interoperabel sein. Die AIOS dient als Bauplan, der es Organisationen ermöglicht, interoperable Informationssysteme systematisch zu entwickeln.

Architektur interoperabler Informationssysteme

In AIOS werden etablierte Prinzipien aus Wirtschaftsinformatik und Interoperabilitätsforschung kombiniert, insbesondere aus Service-orientierter Architektur und kollaborativem Geschäftsprozessmanagement. AIOS wurde zuerst in einer wissenschaftlichen Arbeit beschrieben und spezifiziert unabhängig von Produkten oder Herstellern die verschiedenen Ebenen, Sichten und technischen Artefakte, die benötigt werden, um interoperable Informationssysteme zu erstellen. Mit ihrem Fokus auf organisationsübergreifende Geschäftsprozesse kann die AIOS als komplementäre Ergänzung von ARIS, einer Architektur zur Abbildung interner IT-Systeme und Geschäftsprozesse, gesehen werden.

Definitionen

Ebenso wie die Automatisierung von internen Prozessen, ist die Automatisierung von organisationsübergreifenden Prozessen eines der wichtigsten Ziele des digitalen Zeitalters. Dabei streben die zusammenarbeitenden Organisationen eine lose Kopplung ihrer Informationssysteme an, aber keine enge Integration; die beteiligten Informationssysteme sollen in der Lage sein zusammenzuarbeiten, gleichzeitig sollen sie so viel Selbstständigkeit wie möglich behalten. Diese Eigenschaft wird auch Interoperabilität genannt, beziehungsweise, im Kontext von zusammenarbeitenden Organisationen, Business Interoperability.

Informationssysteme sind Systeme, die Informationen verarbeiten, d. h. sie dienen der Erfassung, der Verarbeitung und Ausgabe von Informationen. In der Wirtschaftsinformatik umfasst der Begriff des Informationssystems üblicherweise nicht nur die Hard- und Software eines Unternehmens, sondern auch die damit verbundenen menschlichen Akteure, Geschäftsfunktionen, Prozesse und Organisationsstrukturen. Dieses Verständnis wird zum Beispiel auch durch Zachman Framework vertreten.

Architektur wird definiert als „die grundlegende Organisation eines Systems, seiner Komponenten, ihrer Beziehungen zueinander und zur Umwelt, sowie die Prinzipien für seine Konstruktion und Evolution“. Sinz definiert eine Informationssystem-Architektur als Bauplan eines Informationssystems, im Sinne einer Spezifikation und Dokumentation der Komponenten und deren Beziehungen, die alle relevanten Sichten und Konstruktionsregeln für die Erstellung des Bebauungsplans enthält.

Dementsprechend kann Architektur interoperabler Informationssysteme definiert werden als Bauplan eines organisationsübergreifenden Informationssystems, das es Unternehmen ermöglicht, Geschäftsprozesse miteinander auszuführen.

Hintergrund und Anwendung

Die Architektur interoperabler Informationssysteme wurde 2010 veröffentlicht als Referenz für die Erstellung von lose gekoppelten, interoperablen Informationssystemen, wobei ein modellbasierter Ansatz zur systematischen Entwicklung von kollaborativen Geschäftsprozessen verfolgt wird. Die AIOS zielt in erster Linie auf Interoperabilität zwischen großen Unternehmen und beschreibt so, wie deren interne Informationssystemelemente systematisch mit den Informationssystemen von Partner-Organisationen verbunden werden können.

Die Arbeit ist im Kontext verschiedener Forschungsprojekte im Themenspektrum Interoperabilität zu sehen, die ihr vorausgingen.

Die wichtigsten Elemente der AIOS sind:

• Beschreibung der Elemente von interoperablen Informationssystemen sowie deren Beziehungen. Hier wird der statische Teil der Architektur beschrieben, bzw. ihre Struktur. Es wird insbesondere beschrieben, welche Informationssystem-Elemente Unternehmen an ihre Kooperationspartner kommunizieren müssen und wie diese öffentlichen Elemente optimal mit internen, privaten Elementen korreliert werden können; Beispiele für solche Informationssystem-Elemente sind fachliche Funktionen und Services, Nachrichten-Formate, Interaktions-Sequenzen sowie beteiligte Rollen.
• Beschreibung möglicher Entwicklungswege für Neuerstellung oder Anpassung interoperabler IT-Systeme. Dies wird auch als der dynamische Teil der Architektur bezeichnet. Er beschreibt das Vorgehen bzw. die Methode, mit der Unternehmen die Elemente der statischen Architektur sukzessive entwickeln können.
• Konzept für die technischen Komponenten, die zur Implementierung der Architektur benötigt werden, zum Beispiel Design-Tools sowie Repositories für private und geteilte Informationssystem-Elemente.

Im letztgenannten Punkt wird auch ein Konzept zur Implementierung eines „BII-Repository“ beschrieben, in dem eine Organisation ihr Business Interoperability Interface (BII) an Kooperationspartner publizieren kann. So wird eine Sicht auf Informationssystem-Elemente implementiert, die innerhalb der Kollaboration veröffentlicht werden sollen. Im BII-Repository werden die für die Partner relevanten Prozesse, Services, Rollen und Nachrichtentypen auf verschiedenen Ebenen technischer Granularität beschrieben, so dass Partner-Organisationen bspw. sowohl nach fachlich als auch nach technisch beschriebenen Artefakten suchen können. Im Gegensatz zum herkömmlichen SOA-Ansatz mit einem zentralen Repository, sind hier also verschiedene Partner-spezifische Repositories implementiert.

Struktur

Der statische Teil der Architektur basiert auf drei orthogonalen Dimensionen: Unternehmenssichten, Grad technischer Granularität und kollaborative Sichten.

Kollaborative Sichten

Das von Datenbanken bekannte Konzept, mit Hilfe von Views bestimmte Datenbereiche sichtbar zu machen, wird auch für Geschäftsprozesse und Workflows genutzt, um bestimmte Prozessteile sichtbar bzw. unsichtbar zu machen. In Verallgemeinerung dieses Konzepts werden in der AIOS drei Sichten auf Informationssysteme unterschieden:

1. Die private Sicht umfasst Informationssystem-Elemente, die ausschließlich innerhalb einer Organisation sichtbar sein dürfen.
2. Die öffentliche Sicht umfasst die Elemente eines internen Informationssystems, die innerhalb einer Kooperation für Partnerorganisationen sichtbar sein sollen (und dazu ggf. im Business Interoperability Interface der veröffentlichenden Organisation enthalten sind). Die Sicht repräsentiert damit die Schnittstelle zwischen internen und externen Systemen; sie dient als Schutz der internen Systeme und als logische Entkopplung zwischen Kooperationsgeschäft und internen Prozessen.
3. Die globale Sicht wird verwendet, um die öffentlichen Sichten verschiedener Systeme zu verknüpfen und ein gemeinsames bzw. innerhalb der Kooperation „globales“ Verständnis über geteilte Informationssystem-Elemente sicherzustellen.

Unternehmenssichten

Illustration of the Architecture of Interoperable Information Systems / Enterprise Dimensions

Um Geschäftsprozesse umfassend zu beschreiben, beinhaltet diese Dimension vier Sichten:

1. In der Datensicht werden für die Zusammenarbeit relevante Dokumenttypen definiert sowie deren Verhältnis zu internen Dokumenttypen.
2. In der Organisationssicht wird ein gemeinsames Verständnis über die in der Zusammenarbeit relevanten Rollen sichergestellt. Beispielsweise werden für das Partnerunternehmen sichtbare Rollen und Abteilungen beschrieben sowie deren Abbildung auf nur unternehmensintern genutzte Rollen.
3. In der Funktionssicht werden einzelne Geschäftsfunktionen beschrieben, die Teil der Kooperation sind.
4. In der Prozesssicht werden die Prozesse, die eine Organisation an Partnerorganisationen anbietet, beschrieben; ebenso wird hier das Verhältnis dieser veröffentlichten Prozessschnittstellen zu internen Prozessen beschrieben.

In Kombination mit den kollaborativen Sichten werden mit den Unternehmenssichten korrelierte private, öffentliche und globale Sichten auf Daten, Funktionen, Prozesse und Rollen ermöglicht.

Ebenen technischer Granularität

AIOS Levels of technical detail

Auch unternehmensübergreifende Informationssysteme sollten auf verschiedenen Ebenen technischer Granularität beschrieben werden: von der fachlichen, über eine technische bis zur Ausführungs- bzw. -Code-Ebene. Damit wird einerseits eine systematische Konstruktion von interoperablen Informationssystemen unterstützt, andererseits kann ein ganzheitliches Bild von bestehenden Systemen an Partner kommuniziert werden, damit die beteiligten Systeme sowohl fachlich als auch technisch aufeinander abgestimmt werden können. Ähnlich wie zum Beispiel ARIS und OMGs modellgetriebene Architektur werden in der AIOS hierzu drei Ebenen verwendet:

1. Fachliche Ebene: Hier werden die Informationssysteme auf einer technikunabhängigen Ebene beschrieben. In der MDA-Terminologie wird diese Ebene auch als CIM-Ebene (Computational-Independent) bezeichnet. Beispielsweise können die an der Zusammenarbeit beteiligten Geschäftsfunktionen und Geschäftsprozesse hier mit EPK definiert werden.
2. Technische Ebene: Hier wird das DV-Konzept der Informationssysteme beschrieben. Dafür werden die Modelle aus der ersten Ebene technisch angereichert und ggf. umstrukturiert; beispielsweise werden anstelle von Geschäftsfunktionen Komponenten bzw. Services (im Sinne von SOA) beschrieben, die die Funktionen technisch abbilden. Weitere Beispiele für diese Ebene sind Beschreibungen von Datenstrukturen mit UML-Klassendiagrammen oder Prozessbeschreibungen mit BPMN.
3. Implementierungsebene: Während die ersten beiden Ebenen primär der Abstimmung zwischen menschlichen Akteuren oder der Generierung von Artefakten der Ausführungsebene dienen, sind die Artefakte der dritten Ebene auf Maschineninterpretierbarkeit ausgerichtet. Die hier erstellten Artefakte können dann zur Laufzeit, bei der Ausführung von organisationsübergreifenden Prozessen, verwendet werden. Dies sind beispielsweise WSDL-Beschreibungen von internen oder externen Services, XSD-Beschreibungen der ausgetauschten Datentypen oder BPEL-Beschreibungen der beteiligten Prozesse.

Einzelnachweise

1. Jörg Ziemann: Architecture of Interoperable Information Systems - An enterprise Model-based Approach for Describing and Enacting Collaborative Business Processes. Logos, 2010. Eine Zusammenfassung findet sich unter J. Ziemann: Architecture of Interoperable Information Systems - Reference Architecture for Collaborations between Public Administrations. In: H. Krallmann, A. Zapp (Hrsg.): Bausteine einer vernetzten Verwaltung. Erich Schmidt Verlag, Berlin 2012, ISBN 978-3-503-13878-4, S. 165.
2. Jörg Becker, Reinhard Schütte: Handelsinformationssysteme -Domänenorientierte Einführung in die Wirtschaftsinformatik. 2. Auflage. Redline Wirtschaft, Frankfurt 2004, ISBN 3-478-25590-2, S. 33.
3. Roland Gabriel: Informationssystem. In: Enzyklopädie der Wirtschaftsinformatik. Online-Lexikon. Oldenbourg Wissenschaftsverlag, München 2008.
4. IEEE: IEEE Std 1471 Frequently Asked Questions (FAQ). (Memento vom 28. August 2011 im Webarchiv archive.today) Version 5.0, 19. Juli 2007, abgerufen: Mai 2009.
5. E. J. Sinz: Architektur von Informationssystemen. In: P. Rechenberg, G. Pomberger (Hrsg.): Informatik-Handbuch. 3. Auflage. Hanser, München 2002, ISBN 3-446-21842-4, S. 1055–1068.
6. Interop NOE (2004 bis 2007 Projekt-Nummer IST- 2004-508011), ATHENA (2004 bis 2007, Projektnummer IST- 2004-507849), R4eGov (2006 bis 2009, Projekt-Nummer IST- 2004-026650)