Architektur-Frameworks

Dr. Rudolf Hauber ist bei der Hood Group für Aerospace und Defense zuständig und betreut als Senior Consultant das Thema Modellierung. Bertil Muth ist ebenfalls Senior Consultant, seine Schwerpunte: Einführung von Architekturprozessen und Modellierung

Selbst innerhalb eines Unternehmens existieren in verschiedenen Projekten häufig unterschiedliche Ansätze zur Beschreibung von Architekturen. Dies behindert die Kommunikation zwischen Teams und erschwert Entscheidungen. Wenn für ein Unternehmen die Notwendigkeit besteht, mit Zulieferern zu kooperieren, bekommt eine effiziente Kommunikation zusätzliches Gewicht.

Ein Architektur-Framework liefert die einheitliche Basis für die Beschreibung zahlreicher System-architekturen. Ziel ist zum einen, eine gemeinsame Sprache für Architekturbeschreibungen zu schaffen. Zum anderen soll eine Methode vorgegeben werden, wie man zu einer konkreten Architekturbeschreibung gelangt. Die gemeinsame Sprache hilft dabei, die Kommunikation zwischen Architekten, Managern, Zulieferern und anderen Stakeholdern zu verbessern. Geschäftliche Ziele können einfacher in Zusammenhang mit Architekturentscheidungen gebracht werden, was wiederum die Investitions-entscheidung erleichtert.

Neben den einheitlichen Architektursichten sollte ein Framework Vorgaben zu den verwendeten Tools machen. Standards und Produkte, die zur Implementierung der Komponenten beitragen können, zählen ebenfalls dazu. Langfristig kann der Einsatz eines Architektur-Frameworks die Portfolio- und Kostenplanung verbessern, Fehler bei der Vertragsgestaltung verringern und die Integration der Systeme verbessern.

Kernelemente des Frameworks

Da ein Architektur-Framework flexibel genug sein muss, viele auch unterschiedliche Systemarchitekturen zu erfassen, müssen zahlreiche Aspekte beschreibbar sein. Dies sind u.a.:

- die funktionale Architektur mit den angebotenen Systemfunktionen,
- der Aufbau des Systems aus logischen Subsystemen und deren Schnittstellen
- sowie die physikalische Architektur.

Verschiedene Sichten (Views) adressieren dabei die einzelnen Aspekte und wie diese zusammenhängen. Darüber hinaus erfassen viele Architektur-Frameworks nicht nur die eigentliche Architektur, sondern zum besseren Gesamtverständnis auch die Einbettung des Systems in seine operationelle Umgebung sowie die Geschäftsprozesse, die durch das System unterstützt werden sollen.

Das DoDAF-Beispiel des US-amerikanischen Verteidigungsministeriums (siehe Abbildung unten) zeigt exemplarisch typische zentrale Elemente eines Architektur-Frameworks: Es existieren verschiedene Sichten, zum Beispiel Operational Activity View, Organizational Context, System Function View, System Data View, System Interface View und zahlreiche mehr.

Um die Gesamtarchitektur beurteilen zu können, ist es entscheidend, dass die Sichten nicht nur einzeln für sich betrachtet werden, sondern explizit in ihrer Wechselwirkung untereinander. Im DoDAF existieren beispielsweise folgende Zusammenhänge zwischen den wichtigsten Architekturelementen: Auf Geschäftsprozessebene wird erfasst, welche operationellen Aktivitäten (Geschäftsprozesse) von welchen Rollen durchgeführt werden und welche Informationen dazu benötigt werden bzw. entstehen. Darüber hinaus wird erfasst, welchen Organisationseinheiten die Rollen zugeordnet sind und an welchen Standorten (Operational Nodes) die Aktivitäten durchgeführt werden.