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 gerne 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 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 1994.

Egal ob Service-orientierte Architektur (SOA), Big Data, Cloud Service, Virtualisierung, Internet of Things, Industrie 4.0, Robotic Process Automation (RPA) oder Künstliche Intelligenz, die 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.

Digitalisierung ist wahrlich nicht neu

Den Begriff "Digitalisierung" habe ich bei der Aufzählung bewusst vermieden. Es ist schwer ersichtlich, was an Digitalisierung wirklich neu ist, schließlich digitalisieren wir seit den 60er Jahren. Die Einführung des ersten Geldautomaten in Deutschland im Jahr 1968 und der flächendeckende Ausbau seiner vernetzten Nachfolger ab 1978 veränderte die Geschäftsprozesse und IT-Architekturen von Banken umfänglicher als manches derzeit heiß gehandelte Trendthema. Die fachlichen und technischen Anpassungen für den Aufbau und Betrieb der mehr als 68.000 Geldautomaten in Deutschland wäre ohne ein umfassendes Architekturmanagement undenkbar gewesen.

Der theoretische Hintergrund ist also nicht neu. Bereits Ende der 1960er 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 dieser Aufgabe in vielen Unternehmen keine stärkere Position eingeräumt wird. Leider muss man sagen, dass die Akteure selbst daran nicht unschuldig sind. Zu oft wurden unnötige Detaillierung erzwungen und die Bedürfnisse der Praxis nicht beachtet. Doch die Zeiten, in denen diese Form des Architekturmanagements betrieben werden konnten, sind endgültig vorbei. Anhand der folgenden sieben aufeinander aufbauenden Schritten soll dargestellt werden, welchem Wandel das Architekturmanagement ausgesetzt ist und wie es darauf am besten reagiert:

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.

Lesetip: 8 Tipps - So retten Sie gefährdete IT-Projekte

In den vergangenen Jahren haben in diesem Spannungsfeld meistens die Projektmanager "gewonnen". Sie müssen konkrete Probleme des Tagesgeschäftes lösen und kurzfristig einen operativen Effekt liefern, der sich meistens 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 in der vom Architekturmanagement eingesetzten Methodik.

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, liefert 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 darüber 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, mit Hilfe 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 Anforderung, 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 Generaly 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 exponenziell mit der Detaillierungstiefe steigt. Wir 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 haben 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 Zustand, 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 udn 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 exponenziell ansteigenden Aufwand für die Dokumentation und kontinuierlichen Pflege bei allgemein sehr seltener Nutzung, dann lässt sich dieser Ansatz nicht rechtfertigen.

Lesetipp: End-to-End-Modellierung im BPM - Wie ein stabiles Prozessmodell entsteht

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.

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 die 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 imme rmehr heterogene Beschreibungen, die ein modernes Architekturmanagement konsolidieren, integrieren und auswertbar aufbereiten muss. Und das geschieht bei gleichzeitigem Kontrollverlust über die zugrundeliegenden Methoden und Notationen für die Detaillierung.

Der klassische Ansatz, die Architektur-Domä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 graphischen 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.

Lesetipp: Was ist Datenvisualisierung?

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

4. Beschreibung: von der graphischen zur abstrakten Darstellung

Beim Erfassen der Business-, Daten-, Anwendungs- und Technologiearchitektur sind diverse Inhaltstypen zu berücksichtigen.

Die Business-Architektur beschreibt in einer Organisation unter anderem

• Prozesse,

• Aufbauorganisation,

• Rollen,

• geographische Strukturen,

• fachliche Dienste,

• Leistungsindikatoren und

• Ziele.

Die Daten-Architektur betrachtet unter anderem

• fachliche Geschäftsobjekte,

• konzeptionelle und logische Datenstrukturen,

• Datensicherheitsaspekte,

• 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 Technologie-Architektur 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 Enterprise Architecture Management ein umfangreiches Spektrum an Inhalten zu beschreiben ist. Die Abbildung oben stellt eine mögliche Ontologie zur Definition der zugehörigen Objekttypen und Beziehungen dar. Zum Beispiel kann die Frage, welche Geschäftsprozesse und Anwender von dem Ausfall einer bestimmten Hardware betroffen sind, durch eine übergreifende Betrachtung der Technologie-, Anwendungs- und Business-Architektur 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.

Im klassischen Architekturmanagement ist es üblich, diese Inhalte graphisch in Diagrammen zu modellieren. Eingesetzt wird dazu eine Vielzahl unterschiedlicher Notationen. Alleine TOGAF definiert zur Beschreibung der Business-, Daten-, Anwendungs- und Technologie-Architektur 18 Kern- und 16 Erweiterungsdiagramme. Zusammen mit der ArchiMate-Notation, jeweils Standards von der Open Group, entstehen bereits viele Visualisierungen. In der Praxis müssen häufig zusätzlich Inhalte vom unstrukturierten Text bis zu graphischen Darstellungen konsolidiert werden. Die nachvollziehbare Heterogenität führt dazu, dass Inhalte konsolidiert werden müssen, um ein integriertes Gesamtbild der Architektur zu erstellen.

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 graphische Dokumentation zu verzichten und Inhalte nur abstrakt und ohne graphische Darstellung zu dokumentieren. Das erfordert lediglich ein Meta-Modell 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 folgende Abbildung zeigt exemplarisch die Überführung von Prozessdiagrammen, Organigrammen, Datenmodellen und Applikationsbäumen in ein abstraktes Graphennetzwerk.

Durch den zunächst vorgenommenen Verzicht auf graphische 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 Meta-Modell definierten Artefakten und deren Beziehungen. So entsteht, losgelöst von den Vorgaben graphischer Notationen, ein inhaltlich integriertes Gesamtmodell. Selbstverständlich ist für die Kommunikation auch die graphische Visualisierung wichtig. Wir kommen darauf im übernächsten Punkt zurück.

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 zugrundeliegende Meta-Modell 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 Meta-Modelle zur Sicherheit umfangreicher gestalten, so dass in der Folge mehr Inhalte zu erfassen sind. Es könnte ja sein, dass eine zusätzliche Information irgendwann 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 Meta-Modell 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 folgende Abbildung zeigt exemplarisch Quellen, die Inhalte zum abstrakten Modell liefern. Durch den Verzicht auf eine graphische 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 graphische 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 graphischen Informationen im Modell enthalten sind, müssen diese bei inhaltlichen Veränderungen auch nicht berücksichtigt werden.

Wie bereits erwähnt, ist die graphische 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.

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

Graphisch 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 ist eine zeitaufwändige 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 Lasten- oder 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 graphischen 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 folgende Abbildung 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 mit Hilfe 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.

Graphische 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 Architektuce 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 wesentlichen 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 mathematischen Analyseverfahren der Graphentheorie und der künstlichen Intelligenz, die direkt auf die Architekturinhalte angewendet werden können, stehen meist automatische Visualisierungen zur Verfügung. Die folgende Abbildung 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 alleine 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.

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

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. (bw)