Informationsbedarf der Enterprise Architektur – Teil 2

In diesem Teil geht es konkret um die benötigten und anfallenden Informationen bei der Ausübung der Praktiken der Enterprise Architektur.

Teil 1 gab Überblick und Motivation für das Thema und kann hier gelesen werden.

Der ganze Beitrag ist in dem Buch „Erfolgsfaktor Informations Management“ (ISBN 978-3-00-053730-1) enthalten und kann hier bestellt werden.

Informationsbedarf der Enterprise Architektur

Einleitend möchte ich darauf hinweisen, dass es sich bei den folgenden Betrachtungen um die vollständige, maximale Informationsmenge handelt, wie sie von TOGAF beschrieben ist. Diese Vollständigkeit ist oft unnötig und nicht trivial in ihrer Verwaltung. Welche Informationsbereiche, zu welchem Zeitpunkt, in welcher Form abgebildet und verwaltet werden, hängt von den spezifischen Anforderungen in der Organization ab und kann nicht allgemein beantwortet werden.

Prinzipien, Leitlinien, Referenzarchitekturen und -modelle

Schon die erwähnten Leitsätze, die sogenannte Unternehmensprinzipien, und die Unternehmensstrategie selbst sind Bestandteil der Information die verwaltet und kommuniziert werden müssen. Daraus abgeleitet werden die Architekturprinzipen, welche wiederum maßgebend sind für Referenzarchitekturen und Architekturleitlinien, sogenannte Guidelines.

Des weiteren muss sich die Architektur an bestimmte Unternehmens- oder Industrie-Standards halten und teilweise komplexe regulatorische Auflagen erfüllen.

Architekturbeschreibungen

Bei der Planung der Architektur werden verschiedene Architekturbeschreibungen erstellt, überarbeitet und abgenommen. Im Idealfall enthält die Architekturbeschreibung weniger „Prosa“ als Artefakten, wie Diagramme, Aufzählungen und Tabellen. Diagramme sind eine wertvolle, wenn nicht die wertvollste, Repräsentation der Architektur. Sie sind leichter zu verstehen und vereinfachen die Kommunikation wesentlich. Zusätzlich läßt sich die strukturierte, mit einem Datenmodell unterlegte, Architekturbeschreibung leichter elektronisch verarbeiten als unstrukturierte textuelle Erklärungen.

Für verschiedene Gruppen von Beteiligten bei der Planung, der Umsetzung und dem Betrieb der Architektur gibt es eigene Artefakte mit spezifischem Inhalt. Dieser spezifische Inhalt wird als Blickpunkt (Viewpoint) auf die Architektur bezeichnet. General hat ein Viewpoint einen Zweck, eine damit verbunden Nutzergruppe (Stakeholders) sowie eine Abstraktionsebene die mehr oder weniger  viele Details der Architektur beinhalten. Die Verwendung von Viewpoints erlaubt den Blick auf die für die Nutzergruppe wesentlichen Informationen. Zur Steigerung der Effizienz werden nicht benötigte Informationen und Detailierungsebenen ausgeblendet.

Die Open Group bietet mit ihrer offenen EA Modellierungssprache „ArchiMate“ einen Lösungsvorschlag zur Standardisierung der Viewpoints, inklusive ihres Zweckes, Detailierungsgrades, der damit verbundenen Nutzergruppe sowie dem Inhalt.

Dabei wird der Zweck grob in drei Kategorien eingeteilt:

1. Entwerfen (Designing)
   Unterstützt primär Architekten bei der Planung der Architektur, sowie Experten und Entwickler bei der Umsetzung.
2. Entscheiden (Deciding)
   Unterstützt Projekt- und Linien-Management beim Entscheidungsprozess durch Aufzeigen von abteilungsübergreifenden Beziehungen und spezifischen Auswirkungen. Oft werden dabei alternative Entwürfe verglichen um die jeweiligen Vor- und Nachteile sowie Risiken zu erörtern.
3. Informieren (Informing)
   Unterstützt jegliche Nutzergruppe beim Verständnis der System-Architektur und erhöht die Unterstützung aller Beteiligten sowie deren Verbundenheitsgefühl zur Architektur.

Der Detailierungsgrad wird in drei Ebenen unterteilt:

1. Details
   Unterstützt das tiefgreifende Verständnis von Geschäftsprozesse, Informationsflüssen sowie deren Einfluss auf die Anwendungs-, Daten- und Technologie-Architektur.
2. Zusammenhang (Coherence)
   Zeigt deutlich die Beziehungen der Geschäftsprozesse zu Akteuren, Ereignissen, Informationen, Anwendungen, Kommunikationswegen und der Infrastruktur.
3. Übersicht (Overview)
   Zeigt logische Gruppen von Geschäftsfunktionen (Services), den Austausch und die Verwaltung von Geschäftsobjekte (Business Objects) sowie die grundlegende Anwendungs- und Infrastruktur-Architektur.

Die folgende Tabelle zeigt die Relation der Detailierungsebene und dem damit verbundenen Informationsbedarf der jeweiligen Nutzergruppe.

	Architektin	Analystin	Ingenieurin / Technikerin	Nutzerin	Managerin	Exekutiv Ebene
Details	X	X	X			(X)
Coherence	X	X	X	X	X	(X)
Overview	X	X	X	X	X	X

 

Die Tabelle zeigt eine Vereinfachung der Nutzergruppen. Die System-Architektur wird heute üblicherweise in vier Domänen aufgeteilt. In Business-, Daten-, Applikation- und technische Architektur. Analystin bezieht sich auf die Business-Analyse zum Zwecke des Anforderungsmanagements. Das Management umfasst Projekt- und Linienfunktionen. Zur Exekutiv-Ebene gehören CIO (Chief Information Officer), CTO (Chief Technology Officer) sowie Lead- und Enterprise-Architekten. Enterprise Architekten sollten aber auch ein ausreichendes Verständnis auf Detailebene besitzen um CIO/CTO wesentlich bei der Architektur-Steuerung zu unterstützen.

Wir halten also fest, dass eine Menge von Architektur-Informationen in unterschiedlicher Detailebenen und Versionen, einzeln oder in Beziehung zu einander, erstellt, überarbeitet und verwaltet werden müssen.
Ausserdem muss die Architektur-Information zumindest allen Stakeholdern gegenüber veröffentlicht werden. Hierbei ist zu Beachten, dass die Detailebene nicht über den Bedarf hinausgeht.
Frederic Vester, deutscher Systemforscher und Pionier des „Vernetzen Denkens“, zeigte mittels des nebenstehenden Bildes, dass eine grobe Detailebene in der Übersicht hilfreich ist. Vester gibt zu bedenken, dass auch wenn alle Details der Kästchen, wie Farbwert, Größe und Beschaffenheit, bekannt und korreliert sind, kann der gezeigten Staatenlenker nicht erkannt werden. Nur durch die Übersicht und einen gewissen Abstand ist hier das Konterfei von Abraham Lincoln zu erkennen.

Architektur-Steuerung (Governance)

Aufgabe der Governance ist die Begleitung der Implementierung. Dies erfolgt anfänglich mit dem vermitteln der grundlegenden Prinzipien, Richtlinien und Standards und setzt sich fort mit der Untersuchung der Konformität der Umsetzung zu den Entwurfsmustern. Auch die Qualitätssicherung der Planung und Implementierung sind typische Aufgaben der Architektur-Steuerung.

Die Erkenntnisse zur Konformität und Qualität der Implementierung werden regelmäßig in Zusammenfassung an den CIO/CTO, bzw. an ein Architektur-Gremium (Architecture Board)  unter deren Vorsitz, berichtet. Dabei werden Maßnahmen zur Unterstützung positiver und zur Gegensteuerung negativer Einflussgrößen diskutiert, beschlossen und begleitet.

Je nach Reife der Architektur-Funktion im Unternehmen, ist die Governance-Funktion objektivierbar. Im Idealfall basiert die Governance ganz auf den gleichen Prinzipen, Richtlinien und Standards, welche dem Planungs- und Implementierungs-Team zur Verfügung stehen. Es wird aber auch immer ein gewisses Maß an Ad-Hoc Goverance notwendig sein. Wichtig ist hierbei, dass auch die Ad-Hoc Governance ihre Entscheidungen veröffentlicht muss. Dies fördert die Nachvollziehbarkeit und erhöht die Wahrscheinlichkeit, dass Organizationsweit eine frühere Konformität zu den Ad-Hoc Entscheidungen entsteht, auch ohne eine Richtlinie, beziehungsweise vor deren Veröffentlichung. Ebenfalls Teil der zu publizierten Informationen aus der Governance sind die Ausnahmegenehmigungen oder Aufschübe für die Umsetzung der Konformität.

Je nach Größer der System-Landschaft und der Anzahl von Planungs- und Implementierung-Projekten, benötigt man einen „Fahrplan“ um die Governance-Funktion zur rechten Zeit am rechten Ort zur Verfügung stellen zu können.

Architektur-Funktion

Eine Architektur entsteht und verändert sich durch das Zusammenspiel verschiedener Tätigkeiten. Im (theoretischem) Idealfall ist das Resultat der Architektur-Funktion deterministisch. Gleiche Anforderungen und Rahmenbedingungen führen zur gleichen Architektur und Implementierung.  Dies setzt Prozesse, Rollen und Organization voraus. Die Architektur-Funktion einer Enterprise läßt sich, wie jeder andere Verbindung aus Prozessen, Akteuren und Organization, als eigenständige Architektur entwerfen, dokumentieren und publizieren. Dabei fallen die oben beschriebenen Architektur-Artefakte an.

Zusätzlich gibt es Informationen zur Ontologie der Fachbegriffe der Architektur-Funktion, Vorlagen für die Architekturbeschreibungen (View Point Library) und Beschreibungen der Rollen inklusive der Definition benötigen Kompetenzen.

Auch das verwendete Architektur-Rahmenwerk (Framework) sowie deren Zuschnitt auf die individuellen Gegebenheiten der Organization können als Information verwaltet und veröffentlicht werden.

Das „Architecture Repository“

Es werden verschiedenste Informationen bei der Planung, der Implementierung, dem Betrieb und der Evolution von Software-Architekturen benötigt und erzeugt. Wenn diese Informationen auf einem Daten- bzw. Meta-Modell basieren, kann man sie leichter elektronisch verwalten und und in Beziehung setzen.

Das folgende Diagramm zeigt das „Architecture Repository“ und dessen Umgebung, wie es von TOGAF vorgeschlagen wird:

Architecture Landscape

Hier wird ist die Beschreibung der gesamten Enterprise Architektur verwaltet.

Dies sind Architektur-Beschreibungen, welche eine Architektur einzeln und im Bezug zu anderen Architekturen in der Enterprise repräsentieren.

Beispiele sind:

• Zuordnung von Geschäfts-Funktionen, -Objekten und Akteuren zu Anwendungen
• Informations- und Datenflüsse zwischen Anwendungen
• Integration der Anwendungen (Schnittstellen, Protokolle, Technologien)
• Technische Infrastruktur für den Betrieb der Applikationen
• Meta Informationen wie Phase im Lebenszyklus oder Eigentümerschaft

Dabei wird auch die Historie bzw. die Veränderung der Enterprise Architektur verwaltet und repräsentiert. Auch zukünftige Versionen einer Enterprise Architektur lassen sich hier modellieren zum Zwecke der Planung und Simulation.

Die drei Detailierungsebenen im Architecture Repository, „Strategic“, „Segment“ und „Capability“, können den Detailierungsebenen der ArchiMate View Point Library zugeordnet werden.

Reference Library und Standards Information Base

Hier sollten alle Prinzipien, Standards, Leitlinien Referenz-Modelle und -Architekturen enthalten sein, welche für eine Architektur-Planung maßgeblich sind.

Dazu zählen beispielsweise:

• Auflagen des Gesetzgebers und der Aufsichtsorganen
• Industrieweite Kommunikationsmodelle (z.B. SWIFT und EDIFACT)
• Organizations- und Industrie-Richtlinien (Best Practices)
• Technologie Kataloge (Standard Technology-Stack)
• Vorlagen für die Architektur-Beschreibungen
• View-Point-Library

Die Reference Library und die Standards Information Base erlauben es den Architekturbeteiligten schon im Vorfeld für sie verpflichtende sowie hilfreiche Informationen zu identifizieren. Weiterhin ist die Governance-Funktion gut zu objektivieren, da zur Bestimmung der Konformität die gleichen Informationen herangezogen werden können wie bei der Planung.

Governance Log

Das Governance Log enthält Informationen welche bei der Steuerung der Architektur benötigt werden, beziehungsweise anfallen. Überwiegend ist die Governance-Funktion begleitend zur Implementierung aktiv um sicherzustellen, dass sie der Planung entspricht.

Dazu benötig man zuerst die Information über das Projekt selbst. Name und Umfang des Projekts sowie die verantwortlichen Ansprechpartner in ihren jeweiligen Rollen (Projektleitung, Architekt, Betrieb usw.).

Die getroffenen Entscheidungen bei Lösungsalternativen sowie die Abweichungen vom Standard sind wesentliche Informationen um die Architektur-Evolution nachvollziehbar zu machen und Verantwortlichkeiten zu dokumentieren.

Bei Erreichung bestimmter Meilensteine im Projektverlauf kann eine Bewertung der Konformität zu den geltenden Standards und Richtlinien zum Zwecke der Qualitätssicherung durchgeführt werden. Diese wohldefinierten Kontaktpunkte zwischen Projekt und Governance-Funktion werden durch einen Kalender planbar.

Bei der Einführung oder Änderung von Unternehmensarchitekturen kann es vorkommen, dass neue Fähigkeiten im Unternehmen benötigt werden. Seien es nun geschäftliche, technische oder planerische Fähigkeiten. Bei der Umsetzung der Architektur ist es Aufgabe der Governance-Funktion den Status der Einführung neuer Fähigkeiten regelmäßig zu erfassen und an die Führungsebene rückzumelden.

Ebenfalls regelmäßig wird die Leistungsfähigkeit und Vitalität der Architektur-Funktion innerhalb der Organization überwacht. So kann das „Architecture Charter“ die Leistungen und Reaktionszeiten der Architektur-Funktion selbst vorgeben. Die Erhebung von Soll- und Ist-Werten erlaubt es organisatorische Flaschenhälse früh zu erkennen und diesen Gegenzusteuern.

Architecture Capability und Metamodel

Die Fähigkeiten der Architektur- und Governance-Funktion ist ebenfalls im „Architecture Repository“ beschrieben. Hier werden die Strukturen und Prozesse hinterlegt, welche bei der Planung und der Umsetzung von Architekturen benötigt werden. Besonders Augenmerk liegt dabei auf der Zuordnung von Fähigkeiten zu Rollen. Um eine Rolle innerhalb der Architektur-Funktion zu erfüllen, wie zum Beispiel die Rolle des Daten-Architekten, wird ein spezifisches Wissen vorausgesetzt. Diese Zuordnung kann auch gezielt eingesetzt werden um das spezifische Wissen im Unternehmen oder in einer Behörde durch Schulungen aufzubauen.

Das im vorherigen Abschnitt erwähnte „Architecture Charter“, zu deutsch „Architektur-Vereinbarung“, ist ebenfalls Bestandteil der Dokumentation der Architektur-Funktion. Hier werden die Sponsoren (meist CIO), der Nutzen, die Ziele, sowie Beschränkungen und wichtige Anforderungen an die Architektur-Funktion dokumentiert.

Schließendlich befindet sich im „Architecture Repository“ auch das Meta-Model, welche die Datenstrukturen und ihre Beziehungen für den Inhalt des Repository selbst beschreibt.

Wechselwirkungen

Die oben aufgezeigten Elemente des „Architecture Repository“ stehen miteinander in Beziehung. Einige davon wurden bereits erwähnt, etwa die Wechselwirkung zwischen „Reference Library“ und „Standards Information Base“ mit der Architektur- und Governance-Funktion. Daraus ist ersichtlich welchen Verpflichtungen die Architektur erfüllt bzw. erfüllen muss.

Im weiteren gibt es auch Beziehungen zu Elementen ausserhalb des „Architecture Repository“.

Diese sind:

• Solution Repository
  Hier wird eine Beziehung zwischen der Architektur und der Software-Lösung hergestellt in einer Weise, dass feststellbar ist welcher Software-Baustein durch welchen Architektur-Baustein repräsentiert ist. Dies fördert die Wiederverwendung von Lösungen bei gleicher oder ähnlicher Architektur.
• Requirements Repository
  Anforderungs-Management wird in jeder Phase der Architektur-Funktion benötigt. Änderungen in den Anforderungen führen meist zu Änderungen der Architektur, deshalb gibt es eine starke Wechselwirkung zwischen Anforderungs-Management und „Architecture Repository“. Die Governance-Funktion überprüft die Konformität zu bestimmten Anforderungen oder formuliert eigene Anforderungen (Auflagen).
• Externe Quellen
  Standards und Referenzen von externen Quellen haben einen hohen Stellenwert, da sie den industrieweiten Datenaustausch begünstigen sowie bewährte Praktiken beschreiben. Auch Auflagen, zum Beispiel des Gesetzgebers, sind den externen Quellen zuzuordnen.
• Architecture Board
  Dieses Gremium übernimmt die Exekutive bei der Architektur-Steuerung und benötigt dabei Informationen aus dem „Architecture Repository“. Im Besonderen die strategische Perspektive der „Architecture Landscape“ und das „Governance Log“.

---

 

Im folgenden und letzten Teil geht es dann um die Unterstützung durch Werkzeuge.