Lesezeit ca. 15 Min.

In sieben Schritten zum modernen Enterprise-Architekturmanagement


Logo von Computerwoche
Computerwoche - epaper ⋅ Ausgabe 34/2022 vom 18.08.2022

Norbert Gronau vom Lehrstuhl für Wirtschaftsinformatik der Universität Potsdam beschreibt eine Unternehmensarchitektur als die strukturierte und aufeinander abgestimmte Sammlung von Plänen für die Gestaltung der Prozess- und IT-Landschaft eines Unternehmens. Die Definition enthält keines der von Analysten und Beratern gern verwendeten Schlagwörter. Dennoch ist sie wichtig für jedes größere IT-Projekt, da Unternehmensarchitekturen bei IT-Veränderungen immer zu berücksichtigen sind. Doch auch die Risiken sind beträchtlich: Unternehmen gerieten in einen „tiefen Joghurt“, wenn das Verarbeiten von Veränderungen länger dauere als die Phase, in der sich Veränderungen manifestieren, schrieb John Zachmann schon 1994.

Egal ob serviceorientierte Architektur (SOA), Big Data, Cloud-Service, Virtualisierung, Internet of Things, Industrie 4.0, Robotic Process Automation (RPA) oder künstliche Intelligenz, die ...

Artikelbild für den Artikel "In sieben Schritten zum modernen Enterprise-Architekturmanagement" aus der Ausgabe 34/2022 von Computerwoche. Dieses epaper sofort kaufen oder online lesen mit der Zeitschriften-Flatrate United Kiosk NEWS.
Weiterlesen
epaper-Einzelheft 10,99€
NEWS Jetzt gratis testen
Bereits gekauft?Anmelden & Lesen
Leseprobe: Abdruck mit freundlicher Genehmigung von Computerwoche. Alle Rechte vorbehalten.
Lesen Sie jetzt diesen Artikel und viele weitere spannende Reportagen, Interviews, Hintergrundberichte, Kommentare und mehr aus über 1000 Magazinen und Zeitungen. Mit der Zeitschriften-Flatrate NEWS von United Kiosk können Sie nicht nur in den aktuellen Ausgaben, sondern auch in Sonderheften und im umfassenden Archiv der Titel stöbern und nach Ihren Themen und Interessensgebieten suchen. Neben der großen Auswahl und dem einfachen Zugriff auf das aktuelle Wissen der Welt profitieren Sie unter anderem von diesen fünf Vorteilen:

  • Schwerpunkt auf deutschsprachige Magazine
  • Papier sparen & Umwelt schonen
  • Nur bei uns: Leselisten (wie Playlists)
  • Zertifizierte Sicherheit
  • Freundlicher Service
Erfahren Sie hier mehr über United Kiosk NEWS.

Mehr aus dieser Ausgabe

Titelbild der Ausgabe 34/2022 von Mit mehr Offenheit Hackern das Handwerk legen. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Mit mehr Offenheit Hackern das Handwerk legen
Titelbild der Ausgabe 34/2022 von Forbes Top-100-Ranking: Das sind die heißesten Cloud-Startups. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Forbes Top-100-Ranking: Das sind die heißesten Cloud-Startups
Titelbild der Ausgabe 34/2022 von Drei Tage in der Woche: Apple beordert Mitarbeiter zurück ins Büro. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Drei Tage in der Woche: Apple beordert Mitarbeiter zurück ins Büro
Titelbild der Ausgabe 34/2022 von Einfallstor Google-Account: So wurde auch Cisco gehackt. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Einfallstor Google-Account: So wurde auch Cisco gehackt
Mehr Lesetipps
Blättern im Magazin
Einfallstor Google-Account: So wurde auch Cisco gehackt
Vorheriger Artikel
Einfallstor Google-Account: So wurde auch Cisco gehackt
Acht Enterprise -Storage -Trends: So speichern Sie in der Zukunft
Nächster Artikel
Acht Enterprise -Storage -Trends: So speichern Sie in der Zukunft
Mehr Lesetipps

... Betrachtung der zugehörigen IT-Architektur war und ist immer relevant. Nur dann kann ein Unternehmen sicherstellen, dass es nicht „im Joghurt“ stecken bleibt und den Wandel beherrscht. Architekturmanagement gehört dazu, ob man es so nennt oder nicht.

Der theoretische Hintergrund ist also nicht neu. Bereits Ende der 60er-Jahre entwickelte Duane Walker bei IBM mit der Business-Systems-Planning(BSP)-Methode eine formalisierte Vorgehensweise für das Architekturmanagement. Darauf aufbauende Frameworks wie PRISM, Zachman, NIST, EAP, TAFIM und TOGAF folgten in den Jahren danach. Eigentlich sollte sich das Architekturmanagement in den zurückliegenden Jahrzehnten, mit den vielen Fortschritten in Theorie und – bezüglich der Werkzeuge – auch in der Praxis etabliert haben. Leider ist das nicht so.

Stiefkind Enterprise-Architektur

Die folgenden Situationen treten in Unternehmen und Behörden immer noch zu oft auf:

Im Rahmen der Einführung einer unternehmensweiten Standardsoftware ist keine aktuelle Dokumentation der Schnittstellen zu Drittsystemen inklusive der technischen Datenstruktur aufzutreiben.

Beim Erstellen eines Business-Continuity-Plans sind die Beziehungen zwischen Informationen, IT-Systemen und den Geschäftsprozessen meist nicht verfügbar, obwohl sie im Rahmen der DSGVO-Arbeiten schon einmal dokumentiert sein sollten.

Das Process-Mining-Projekt gerät in einen unvorhergesehenen „Steinschlag“, da von der Software gelieferte Informationen nur die halbe Wahrheit zeigen, wenn sie nicht mit analogen Prozessschritten verknüpft werden.

Im RPA Projekt „baut“ jeder seinen Service selbst, wodurch ein unübersichtlicher Zoo von automatisierten Mini-Aktivitäten die Übersicht zwischen Prozessen und angebundenen IT-Lösungen verdeckt.

Ähnliche Situationen kennt im IT-Geschäft wohl jeder, und sie alle haben eine Gemeinsamkeit: Das Architekturmanagement hat nicht funktioniert. Damit stellt sich die Frage, warum diese Aufgabe in vielen Unternehmen nicht stärker priorisiert wird. Leider muss man sagen, dass die Akteure selbst daran nicht unschuldig sind. Zu oft wurden unnötige Detaillierungen erzwungen und die Bedürfnisse der Praxis nicht beachtet. Doch die Zeiten, in denen diese Formen des Architekturmanagements betrieben werden konnten, sind endgültig vorbei. Anhand der folgenden sieben aufeinander aufbauenden Schritte soll dargestellt werden, welchem Wandel das Architekturmanagement ausgesetzt ist und wie Unternehmen darauf am besten reagieren:

1. Inhalt – von der globalen zur projektbezogenen Betrachtung

Mit einer Enterprise Architecture die Organisation vollständig zu beschreiben und seine ganzheitliche Weiterentwicklung zu planen und voranzutreiben war lange Zeit das primäre Ziel im Architekturmanagement. Wer ganzheitlich dachte, hatte dabei neben den Inhalten rund um die IT-Architektur auch betriebswirtschaftlich-operative und grundlegende strategische Aspekte im Auge. Das erforderte einen zentralen Blick auf die gesamte Organisation.

Der theoretisch lobenswerte Ansatz hat allerdings einen erheblichen Schönheitsfehler: Durch den Anspruch einer globalen Dokumentation entstehen fortwährend Konflikte im Zusammenhang mit einzelnen Projekten, die auf Inhalte aus dem Architekturmanagement zurückgreifen. Aus Sicht eines Projektverantwortlichen ist die umfassende organisationsweite und global korrekte Erfassung, Dokumentation und Fortschreibung einer Unternehmensarchitektur im Zweifel irrelevant. Projekte stehen unter Zeitdruck und müssen mit begrenzten Ressourcen ein definiertes Ergebnis in einer festgelegten Zeit abliefern. Da stören die Architekturmanager, die es sich zur Aufgabe gemacht haben, alle relevanten Inhalte des Unternehmens in einen übergeordneten Zusammenhang zu bringen.

Im besten Fall ignorieren die Projektverantwortlichen das Architekturmanagement, werden sie doch am fristgerechten Abschluss ihres Vorhabens gemessen. Im schlimmsten Fall sabotieren sie die „Kollegen im Elfenbeinturm“ sogar und bekämpfen die Disziplin als unnötige Geldverschwendung. Fatal ist diese Situation, weil beide Seiten auf ihre Art recht haben. Die einen treiben die Projekte voran, die anderen sorgen für die langfristige Weiterentwicklung der Organisation.

In den vergangenen Jahren haben in diesem Spannungsfeld meist die Projektmanager „gewonnen“. Sie müssen konkrete Probleme des Tagesgeschäfts lösen und kurzfristig einen operativen Effekt liefern, der sich oft auch schnell zeigt. Dagegen werden die positiven Effekte des Aufbaus einer integrierten Architektur erst in der Zukunft sichtbar. Diese Aufgabe geht in der hektischen, zahlengetriebenen Unternehmenswelt leicht unter. Und das gilt nicht erst, seitdem agile Methoden den Fokus auf schnelle Ergebnisse und Anwenderakzeptanz verschoben haben.

Das IT-Architekturmanagement muss darauf reagieren, indem es anerkennt, dass Projekte der Treiber in der täglichen Unternehmenspraxis sind. Seine zentrale Aufgabe wird es zukünftig sein, dokumentierte Projektinhalte zu konsolidieren, zu verknüpfen und wo nötig zu ergänzen. Es ist damit primär dafür verantwortlich, den Klebstoff zwischen den projektindividuellen Inhalten zu liefern. Das hat Konsequenzen für die zur Detaillierung von Inhalten vom Architekturmanagement eingesetzten Methodik.

Fazit: Projekte sind zukünftig die primären Quellen für Inhalte im Architekturmanagement und steuern wesentlich dessen Ausrichtung.

2. Detaillierung – von der starren zur flexiblen Methodik

Wesentlich für die Erfassung von Inhalten einer Architektur sind die Konventionen, die zur Detaillierung definiert sind. Das Architekturframework TOGAF listet in den „Architectural Artifacts“ auf, welche Inhalte in den Domänen Business-, Daten-, Anwendungen- und Technologie-Architektur erfasst werden sollten, leistet aber keine Hilfestellung, wie das zu erfolgen hat. Damit stehen IT-Architekten vor der Herausforderung, dass zwar Vorgaben existieren, welche Inhalte zu dokumentieren sind, aber nur wenige Informationen angeboten werden, wie das idealerweise erfolgen sollte.

Aus praktischer Sicht ist das verständlich, denn oft findet sich in den Unternehmen nur das allgemeine Ziel, mithilfe des Enterprise-Architekturmanagements die (IT-)Landschaft zu gestalten und zu steuern. Die individuellen Anforderungen unterscheiden sich indes meist deutlich. Übergreifend lassen sich anwendbare Vorgaben kaum formulieren. So stellt das Architekturmanagement in einem über viele Jahre gewachsenen Industrieunternehmen komplett andere Anforderungen als das in einem Internet-Startup.

Das führt dazu, dass jedes Unternehmen das von Rob Davis aufgestellte Postulat „Know when you have done enough“ (siehe Generally Accepted Modelling Principles) auf sich beziehen muss. Allerdings ist das leichter gesagt als getan. Denn mit dem Ziel vor Augen, die übergreifende Entwicklung eines Unternehmens steuern zu müssen, greifen viele zum klassischen Ansatz, der eine einheitliche und vergleichbare Architekturbeschreibung in der gesamten Organisation voraussetzt.

Damit gehen einheitliche Vorgaben hinsichtlich der Detaillierung zwingend einher. Diese müssen bei der Dokumentation innerhalb des Unternehmens übergreifend eingehalten werden, egal ob sie im Rahmen der konkreten Projektsituation erforderlich sind oder nicht. Nur dann funktioniert der klassische Ansatz und erlaubt die Inhalte verschiedener Domänen des Architekturmanagements zu vergleichen.

Problematisch ist dabei, dass der Aufwand für die Dokumentation exponentiell mit der Detaillierungstiefe steigt. Wird die Forderung aufgestellt, in jedem Projekt die globalen Vorgaben zur Erfassung der Architektur zu beachten, ist die Basis für das Scheitern bereits gelegt, denn:

Projektbeteiligte beachten die Anforderungen des Architekturmanagements meistens nur dann, wenn diese mit ihren individuellen Informationsbedürfnissen im Einklang stehen. Eine übergeordnete globale Perspektive kann aus Zeit- und Kostengründen durch ein Projekt in der Regel nicht verfolgt werden.

Projektbeteiligte haben wenig Interesse, dem Architekturmanagement bei der Sammlung oder Aktualisierung von Inhalten über den eigentlichen Informationsbedarf hinaus zu helfen. Vielmehr definieren sie eigene Methoden und Notationen, die unter Zeit-, Qualität- und Kostengesichtspunkten das Projektziel am besten unterstützen. Wenn diese nicht den Vorgaben des Architekturmanagements entsprechen, wird das in der Regel billigend in Kauf genommen.

Der Umstand, dass Projekte mit ihren individuellen Methoden und Notationen die Gestalt und den Umfang von Unternehmensarchitekturen zukünftig bestimmen, mag nicht jedem gefallen, muss aber akzeptiert werden. Unerheblich ist dabei, welche der Enterprise-Architektur-Domänen betrachtet wird. Zum Beispiel ist es unsinnig, alle Geschäftsobjekte eines Unternehmens bis zur technischen Datenstruktur vollständig zu beschreiben, wenn etwa für die Migration einer Anwendung nur einzelne Inhalte benötigt werden. Aber selbst bei ausschließlicher Betrachtung des Architekturmanagements wird deutlich, dass die flexible Detaillierung von Inhalten zur effizienten Umsetzung beiträgt. Eine detaillierte Beschreibung der Kommunikationen jeder Instanz einer Anwendungssoftware auf diversen Endgeräten wird niemand erstellen. Die Beziehungen der zugehörigen Server-Kommunikation aber wahrscheinlich schon.

Besonders offensichtlich wird das bei der Prozessmodellierung in der Business-Architektur. Wer kennt sie nicht, die prozessualen Hochhäuser mit ihren gefühlt unendlich vielen Ebenen, deren Erstellung Monate und manchmal Jahre gedauert hat? Oft enthalten sie Beschreibungen von Arbeitsabläufen bis zu einem letzten, nicht mehr sinnvoll zu zerlegenden Arbeitsschritt. Meiner Erfahrung nach werden diese Prozessdokumentationen in den Unternehmen kaum genutzt.

Es existieren etliche Fälle, in denen bis zu 80 Prozent der erfassten Inhalte auf den unteren Ebenen einer Prozessmodellierung wenig bis nie verwendet werden. Bestenfalls schaut einmal im Jahr ein Auditor nach, ob auch alles ordnungsgemäß aufgeschrieben wurde. Aber ist dieser Ansatz den zu betreibenden Aufwand für das Erstellen und Aktualisieren des Modells wirklich wert? Als Argument für diesen Ansatz dient häufig, dass seltene Arbeitsabläufe dadurch sicherer ausgeführt werden oder die Einarbeitung neuer Mitarbeiter schneller erfolgen könne. Das stimmt. Aber bedenkt man den exponentiell ansteigenden Aufwand für die Dokumentation und kontinuierliche Pflege bei allgemein sehr seltener Nutzung, dann lässt sich dieser Ansatz nicht rechtfertigen.

Als Konsequenz ergibt sich die Anforderung, die in einzelnen Projekten erstellten Inhalte unterschiedlicher Detaillierungstiefe variabel in Beziehung zu setzen. Ein modernes Enterprise-Architekturmanagement verbindet dazu die Inhalte jedes einzelnen Vorhabens zu einem Ganzen.

Fazit: Nach festen Vorgaben erstellte Dokumentationen verlieren an Bedeutung und werden ersetzt durch variable Dokumentationen mit individuellem Detaillierungsgrad.

3. Topologie – von der Insel zum Netz

Durch die Verschiebung von einem globalen zu einem projektbezogenen Ansatz in Verbindung mit einer flexiblen und individuellen Detaillierung erhöht sich zwangsläufig die Heterogenität der erfassten Inhalte einer Architektur. Die Kombination von projektindividuellen Schwerpunkten, mit unterschiedlichen Inhalten in den Domänen selbst, führt zu einer heterogenen Dokumentation.

Zum Beispiel liefert ein Projekt rund um die fachliche Optimierung der Auftragsabwicklung primär Inhalte der Business- und Daten-Architektur vom Auftragseingang bis zur Auslieferung. Andere fachliche Bereiche werden mit hoher Wahrscheinlichkeit nicht in Betracht gezogen – schon um Ressourcen zu sparen. Damit wird deutlich, dass der starke Projektfokus zu einer fragmentierten Beschreibung in Form von individuellen „Architektur-Inseln“ führt. Aber individuelle Ansätze über eine integrierte Architektur zu verbinden war doch schon immer Aufgabe des IT-Architekturmanagements? Das ist richtig. Nur erfolgte das meistens über einen Ansatz, der auf übergeordnet vorgegebenen Methoden und Notationen basierte.

Der Theorie nach ist der „alte“ Weg richtig, führt er doch zu einer möglichst homogenen Beschreibung. Leider funktioniert er aufgrund des meist hohen Dokumentationsaufwands in der Praxis nur unzureichend. Erschwerend kommt hinzu, dass Projekte zunehmend vorgeben, was dokumentiert werden soll und was nicht. Das Enterprise-Architecture-Management wird dadurch gezwungen, unterschiedliche Inhalte zusammenzuführen. Operativ orientierte Projekte folgen nur noch bedingt allgemein gültigen Architekturvorgaben, da diese eine agile und effiziente Abwicklung behindern. Zwangsläufig entstehen immer mehr heterogene Beschreibungen, die ein modernes Architekturmanagement konsolidieren, integrieren und auswertbar aufbereiten muss. Und das geschieht bei gleichzeitigem Kontrollverlust über die zugrunde liegenden Methoden und Notationen für die Detaillierung.

Der klassische Ansatz, die Architekturdomänen einer Organisation global und mit starren Methoden und Notationen zu erfassen, ist nicht mehr zeitgemäß. Vielmehr wird von einem modernen Architekturmanagement gefordert, Inhalte projektbezogen und flexibel in Form eines Netzwerks zu konsolidieren und in Beziehung zu setzen. Um das umzusetzen, müssen die Dokumentation möglichst einfach ausfallen, die Erhebung automatisiert und mit grafischen Visualisierungen gearbeitet werden. Gleichzeitig ergibt sich die Möglichkeit, verstärkt freie Software einzusetzen, wodurch zusätzlich eine Kostenreduktion erreichbar ist. Diese Handlungsoptionen sehen wir uns in den folgenden Punkten näher an.

Fazit: Durch die Verknüpfung mit projektindividuellen Inhalten entwickelt sich das Architekturmanagement vom Urheber zum Integrator des Architekturwissens einer Organisation.

4. Beschreibung: von der grafischen zur abstrakten Darstellung

Beim Erfassen der Business-, Daten-, Anwendungs- und Technologiearchitektur sind diverse Inhaltstypen zu berücksichtigen. Die Businessarchitektur beschreibt in einer Organisation unter anderem Im klassischen Architekturmanagement ist es üblich, diese Inhalte grafisch in Diagrammen zu modellieren. Eingesetzt wird dazu eine Vielzahl unterschiedlicher Notationen. Allein TOGAF definiert zur Beschreibung der Business-, Daten-, Anwendungs- und Technologiearchitektur 18 Kern- und 16 Erweiterungsdiagramme. Zusammen mit der ArchiMate-Notation, jeweils Standards der Open Group, entstehen bereits viele Visualisierungen. In der Praxis müssen häufig zusätzlich Inhalte, vom unstrukturierten Text bis zu grafischen Darstellungen, konsolidiert werden. Die nachvollziehbare Heterogenität führt dazu, dass Inhalte konsolidiert werden müssen, um ein integriertes Gesamtbild der Architektur zu erstellen.

Prozesse,

Aufbauorganisation,

Rollen,

geografische Strukturen,

fachliche Dienste,

Leistungsindikatoren und

Ziele.

Die Datenarchitektur betrachtet unter anderem

fachliche Geschäftsobjekte,

konzeptionelle und logische Datenstrukturen,

Datensicherheit

Migrationsinformationen und

Inhalte zum Lebenszyklus von Daten.

Die Applikationsarchitektur beschreibt

die Anwendungslandschaft,

technische Kommunikationsbeziehungen,

interne funktionale Strukturen der Anwendungen und

extern angebotene technische Dienste.

Die Technologiearchitektur dokumentiert

die eingesetzten technologischen Standards und das zugehörige Portfolio der Hardware sowie

Netzwerk- und Low-Level Kommunikationsbeziehungen.

Die Aufzählung erhebt keinen Anspruch auf Vollständigkeit. Sie zeigt aber, dass im EAM ein umfangreiches Spektrum an Inhalten zu beschreiben ist. Die Abbildung auf Seite 14 stellt eine mögliche Ontologie zur Definition der zugehörigen Objekttypen und Beziehungen dar. Zum Beispiel kann die Frage, welche Geschäftsprozesse und Anwender vom Ausfall einer bestimmten Hardware betroffen sind, durch eine übergreifende Betrachtung der Technologie-, Anwendungs- und Businessarchitektur beantwortet werden. In der gezeigten Beispiel-Ontologie sind dafür folgende Zellen und deren Beziehungen auszuwerten:

Rollen/Stellen,

Sub-Prozesse/fachliche Detailprozesse,

Fachanwendungen/logische Schnittstellen und

Infrastrukturinstanzen.

Wenn neben inhaltlichen auch notationsspezifische Aspekte zu berücksichtigen sind, steigt die Komplexität der erforderlichen Harmonisierung und Aggregation erheblich an. Ein besserer Weg ist es, bei der Konsolidierung zunächst auf die grafische Dokumentation zu verzichten und Inhalte nur abstrakt und ohne grafische Darstellung zu dokumentieren. Das erfordert lediglich ein Metamodell der Gesamtarchitektur, welches die inhaltliche Erfassung der Elemente, der zugehörigen Attribute und der Beziehungen zueinander definiert, und eine darauf basierende Datenbank, in der Inhalte abgelegt und in Beziehung gesetzt werden. Die Abbildung auf Seite 15 zeigt exemplarisch die Überführung von Prozessdiagrammen, Organigrammen, Datenmodellen und Applikationsbäumen in ein abstraktes Graphen-Netzwerk.

Durch den zunächst vorgenommenen Verzicht auf grafische Darstellungen wird die (teil-)- automatische Dokumentation erheblich vereinfacht, da es nicht mehr erforderlich ist, auch die visuelle Darstellung zu konsolidieren. Der Fokus liegt dann ausschließlich auf den im Metamodell definierten Artefakten und deren Beziehungen. So entsteht, losgelöst von den Vorgaben grafischer Notationen, ein inhaltlich integriertes Gesamtmodell. Selbstverständlich ist für die Kommunikation auch die grafische Visualisierung wichtig. Wir gehen darauf im übernächsten Punkt noch weiter ein.

Fazit: Die abstrakte, notationsneutrale Konsolidierung aller Inhalte in einem Modell führt Architekturwissen effizient zusammen.

5. Erhebung – von der manuellen zur automatischen Erfassung

Zu den größten Fehlern im Enterprise-Architecture-Management gehört es, den Begriff „Enterprise“ wörtlich zu nehmen. Es geht nicht darum, die gesamte Organisation zu dokumentieren. Vielmehr sind nur Inhalte zu erfassen, die zur strukturierten Planung und Gestaltung der (IT-)Landschaft einer Organisation benötigt werden. Dieses Ziel kann das Architekturmanagement nur dann mit vertretbarem Aufwand erfüllen, wenn das zugrunde liegende Metamodell in der Lage ist, die notwendigen Erkenntnisse zu liefern.

Es ist extrem schwer, ex ante zu definieren, welche Inhalte zukünftig benötigt werden. Dieser Situation begegnen viele Architekturprojekte, indem sie Metamodelle zur Sicherheit umfangreicher gestalten, sodass in der Folge mehr Inhalte zu erfassen sind. Es könnte ja sein, dass irgendwann eine zusätzliche Information benötigt wird. Dann ist es doch gut, sie schon einmal „auf Vorrat“ erfasst zu haben. Auch wenn der Ansatz nicht besonders effizient ist, ist alles in Ordnung, solange die vorhandenen Kapazitäten in der Lage sind, die anstehenden Erfassungsarbeiten durchzuführen. Meistens ist das aber nicht der Fall, und irgendwann entstehen „weiße Flecken“ in der Datenbasis. Das ist ein gefährlicher Zustand für das Architekturmanagement. Denn wenn das Metamodell mehr verspricht, als es inhaltlich halten kann, leidet das Vertrauen der Nutzer in die Datenbasis. Diese Situation gilt es unter allen Umständen zu vermeiden.

Hier kommt die Automatisierung der Datenerfassung ins Spiel. Wo immer möglich, sollten Inhalte des Architekturmodells durch automatisierte Prozesse erhoben werden. Die Abbildung auf Seite 16 zeigt exemplarisch Quellen, die Inhalte zum abstrakten Modell liefern. Durch den Verzicht auf eine grafische Visualisierung sinkt der Aufwand zur „Übersetzung“ der Ausgangsdaten in das abstrakte Modell innerhalb der Integrationsschicht erheblich. In manchen Fällen wird die Konsolidierung durch den Verzicht auf grafische Informationen überhaupt erst möglich.

Das gilt nicht nur für die initiale Erfassung. Auch die langfristige Pflege und Aktualisierung profitiert von diesem Ansatz. Der Lebenszyklus der Architekturbeschreibung, von der Anlage und Änderung bis zur Löschung, ist durch die Reduktion auf die abstrakten Zusammenhänge deutlich einfacher zu automatisieren. Da keine grafischen Informationen im Modell enthalten sind, müssen diese bei inhaltlichen Veränderungen auch nicht berücksichtigt werden.

Wie bereits erwähnt, ist die grafische Kommunikation der Erkenntnisse des Architekturmanagements aber unverzichtbar. Auch wenn es auf den ersten Blick nicht so scheint, ist die abstrakte Form der Dokumentation in einem integrierten Modell auch dabei vorteilhaft. Benötigte Diagramme werden einfach generiert.

Fazit: Automatische Verfahren zum Sammeln, Aufbereiten und Speichern von Architekturwissen helfen, komplexe individuelle Informationen langfristig mit vertretbarem Aufwand zu dokumentieren und zu konsolidieren.

6. Visualisierung – vom Modellieren zum Generieren

Grafisch aufbereitete Informationen wirken überzeugender als Textbeschreibungen. Das gilt besonders dann, wenn die Ergebnisse des Architekturmanagements Führungskräften gezeigt werden. Über eine Darstellung als Grafik lassen sich komplexe Sachverhalte deutlich einfacher kommunizieren, und Muster, Trends und Zusammenhänge sind besser zu erkennen. Das Durchsuchen von Tabellen ist dagegen nicht praktikabel, da das menschliche Gehirn eher durch eine gute Visualisierung als durch Text oder Zahlen angesprochen wird. Eine gute Visualisierung ist also die beste Investition in die langfristige Unterstützung des Architekturmanagements in der gesamten Organisation.

Allerdings ist das Erstellen von Diagrammen eine zeitaufwendige Angelegenheit. Betrachten wir als Beispiel Prozessbeschreibungen mit der Business Process Model and Notation (BPMN) in einem hohen Detaillierungsgrad. Die BPMN-Notation erlaubt es, Arbeitsabläufe exakt zu beschreiben, zum Beispiel zur Konzeption eines Systems für die Automatisierung von Prozessen in einer IT-Lösung. Auch als Zusatz von Vertragsunterlagen beim Erstellen von Lastenoder Pflichtenheften sowie für das Harmonisieren und Optimieren von Prozessen liefert die BPMN wertvolle Beiträge. Im Zweifel ist ein BPMN-Diagramm widerspruchsfreier als eine textuelle Prozessbeschreibung. Verbringt ein Unternehmen viel Zeit mit dem Erfassen und Dokumentieren von Prozessen, obwohl die Ergebnisse später nur für wenige Fragestellungen benötigt werden, ist die unternehmensweite Dokumentation von detaillierten Arbeitsabläufen mit BPMN im Architekturmanagement nur Geldverschwendung.

Gleiches gilt für die anderen Domänen des Architekturmanagements. Besser ist es, manuelle Arbeiten zur grafischen Dokumentation auf die Bereiche zu beschränken, in denen die kreativ-intellektuelle Leistung eines Menschen zur visuellen Abbildung erforderlich ist. In allen anderen Fällen ist die automatische Generierung von Diagrammen vorzuziehen. Die Abbildung auf Seite 17 zeigt ein auf Basis eines abstrakten Modells automatisch erstelltes Daten-Applikation-Flussdiagramm, welches inklusive Layout mit frei verfügbarer Software erstellt wurde. Die abstrakte Ablage von Inhalten in einer Datenbank erzeugt mithilfe von Algorithmen qualitativ hochwertige Visualisierungen. Dadurch wird der Aufwand im Architekturmanagement, zusätzlich zu den bereits durch die automatisierte Erfassung erzielten Verbesserungen, nochmals deutlich reduziert.

Für den Aufbau des integrierten Architekturmodells und die automatische Generierung visueller Darstellungen ist noch nicht einmal teure Software anzuschaffen. Die zentralen Funktionen lassen sich mit freier Software realisieren.

Fazit: Grafische Visualisierungen werden auf Basis eines abstrakten agnostischen Modells generiert und nicht mehr modelliert.

7. Werkzeuge – von Suites und Best of Breed zu Hub and Spoke

Wie in anderen Bereichen der Informatik auch, stehen sich bei der Auswahl von Software für das Architekturmanagement zwei Lager gegenüber. Auf der einen Seite steht der Suite-Ansatz, der versucht, mit einer einzigen Softwarelösung die gesamte IT-Unterstützung des Architekturmanagements abzubilden. Gartner Peer Insight listet allein 29 Softwareanwendungen auf, die Unternehmensarchitekten und andere IT-Stakeholder bei der strategischen Planung, Analyse, Gestaltung und Umsetzung des Architekturmanagements unterstützen. Aber selbst wenn die Hersteller von Enterprise-Architecture-Software etwas anderes behaupten, bislang ist es noch keinem Anbieter gelungen, eine Software-Suite auf den Markt zu bringen, die so umfassend ist, dass sie alle Anforderungen des Architekturmanagements in einer Lösung verbindet.

Auf der anderen Seite stehen die Vertreter des Best-of-Breed-Ansatzes, die für unterschiedliche Problemstellungen die jeweils am besten geeignete Software einsetzen. Beispiele dafür sind:

Werkzeuge für die Prozessmodellierung fachlicher Arbeitsabläufe in der Business-Architektur, Datenmodellierungswerkzeuge in der Daten-Architektur und Software zur Erfassung der Infrastruktur-Architektur (Data Center Infrastructure Management = DCIM).

In der Praxis ist ein Mix aus diversen Werkzeugen nahezu immer die Realität. Die operativen Bereiche einer Organisation werden für ihre Arbeit spezialisierte Werkzeuge nutzen, mit denen sie im Rahmen der Möglichkeiten ihre Aufgaben am besten erfüllen können. Das gilt umso mehr, als – wie ausgeführt – die operativen Projekte wesentliche Zulieferer für Inhalte im Architekturmanagement geworden sind. Der Wandel vom globalen zu einem flexiblen, projektgetriebenen Ansatz hat massiven Einfluss auf die im Architekturmanagement eingesetzten Werkzeuge.

Um die verschiedenen Quellen integrieren zu können, hat sich ein Hub-and-Spoke-Ansatz bewährt, der relevante Inhalte verschiedener Domänen so einfach wie möglich in einem zentralen Repository in Beziehung setzt, automatisch aktualisiert, flexibel auf strukturelle Änderungen und Erweiterungen reagiert und eine möglichst umfassende Analyse ermöglicht. Hier kommen native Graph-Datenbanken ins Spiel, die Inhalte direkt in einer Netzstruktur verwalten. Durch die Möglichkeit, individuelle Erweiterungen aufgrund des schemalosen Designs von Graphen-Datenbanken ohne großen Umbau zu ergänzen, bieten sie sich als zentrales Architektur-Repository geradezu an.

Darüber hinaus bieten die mittels Graphen verknüpften Inhalte umfassende Analyse- und Auswertungsmöglichkeiten. Neben den mathe-matischen Analyseverfahren der Graphen-Theorie und der künstlichen Intelligenz, die direkt auf die Architekturinhalte angewendet werden können, stehen meist automatische Visualisierungen zur Verfügung. Die Abbildung auf Seite 18 zeigt Inhalte eines Prozessmanagement-Werkzeuges (im Beispiel Inhalte aus BIC Process Design) in Kombination mit einem integrierten Architekturmodell auf Basis der Graphen-Datenbank Neo4j. Dadurch werden Analysen ermöglicht, die mit einem Prozessmanagement-Werkzeug allein nicht möglich sind. Sie reichen von der Identifikation methodischer Optimierungspunkte im Modell über die Generierung von End-to-End-Diagrammen bis hin zur Identifikation zentraler Prozessabläufe, Applikationen, Schnittstellen oder Geschäftsobjekte aus Sicht der gesamten Organisation. Durch die Nutzung von KI lassen sich diese Erkenntnisse oft ohne zusätzliche Ergänzung der Ausgangsdaten ableiten.

Zusätzlich erlaubt die standardisierte Datenstruktur, Inhalte flexibel an Drittwerkzeuge zu übergeben, zum Beispiel für das Reporting an JasperReports oder Microsoft Power BI. Graphen-Datenbanken und statistische Datenanalyse-Tools stehen oft als freie oder Community-Lösungen zur Verfügung, wodurch zusätzliche Lizenzkosten vermieden werden.

Fazit: Schemalose Graphen-Datenbanken und Analysetools ermöglichen es, individuelle Architekturinhalte flexibel zu verbinden, gezielter auszuwerten und einfacher zu kommunizieren.

(hv)

Die Unternehmensarchitektur – vom Aufbau bis zum Refactoring

Es mag so scheinen, als ließen sich die vorgestellten Veränderungen nur dann vollständig umsetzen, wenn das Architekturmanagement in einer Organisation erst noch aufgebaut werden muss. Dem ist aber nicht so. Vielmehr bringt die Integration der zentralen Architekturinhalte in einem Hub-and-Spoke-Ansatz sowohl auf der „grünen Wiese“ als auch bei partiell vorhandenen Architekturen und letztendlich auch bei einer bereits umfassenden Architekturdokumentation Vorteile. Ist in einer Organisation noch kein Architekturmanagement etabliert, erlaubt unser Ansatz einen kostengünstigen Einstieg auf Basis eines schnell zu implementierenden leichtgewichtigen Fundaments. Es müssen keine teuren Enterprise-Architecture-Werkzeuge beschafft werden, und erste Ergebnisse lassen sich direkt auf ihre Verwendbarkeit testen. Wenn sich abzeichnet, dass doch eine spezialisierte Softwarelösung für das Architekturmanagement benötigt wird, sind wesentliche Vorarbeiten zu deren Implementierung bereits erledigt. Sollten bereits Architekturinhalte in Teilen gesammelt, aber noch nicht umfassend zusammengeführt sein, dann ermöglicht der Ansatz eine Integration ohne große Kosten. Meistens stellt sich dabei heraus, dass die Lösung stabil genug ist, um bereits umfassende Auswertungen zu erlauben. Sie ist für einen längerfristigen Betrieb nutzbar, zusätzliche Investitionen in weitere Enterprise-Architektur-Software können entfallen. Und selbst wenn eine umfassende Architektur in einem Enterprise-Architektur-Werkzeug vorliegt, erweitern sich durch die Integration der Inhalte in einer Graphen-Datenbank die Auswertungsmöglichkeiten erheblich. Es ist egal, ob eine Organisation bereits Enterprise-Architecture-Management betreibt oder nicht. Wer die vorgestellten Veränderungen im Architekturmanagement aktiv angeht, vermeidet auf jeden Fall – frei nach Zachman –, mit beiden Beinen im Joghurt zu stehen.