Zum Inhalt springen

Leitfaden zum Aufbau einer integrierten Enterprise Architektur

Schlüsselaussagen

  • Eine Enterprise Architektur liefert die zentrale Basis zur strategischen, operativen und (IT-)technischen Planung in Unternehmen und Behörden.
  • Enterprise Architekturen bieten nachhaltigen Nutzen, wenn deskriptive Inhalte mit automatisch erfassten operativen Daten verknüpft werden.
  • KI basierte EA-Analysen liefern nur dann individuelle Erkenntnisse, wenn eigene Modelle als Datenbasis aufgebaut werden.
  • Ausschließliche Cloud-Lösungen sind aus Datenschutz- und Kostengründen ungeeignet für den Aufbau einer integrierten Enterprise Architektur.
  • On-Premises Lösungen (zumindest für eigene operative Daten) sind erforderlich um das Wissen der eigenen Organisation zu schützen.
  • Open-Source Technologien stellen kostengünstige Lösungen bereit.

In der heutigen Geschäftswelt, die durch rasante technologische Entwicklungen und permanente Veränderungen geprägt ist, müssen Unternehmen effizient und flexibel agieren. Das bedeutet, schnell auf Marktanforderungen reagieren, interne Abläufe optimal steuern und die passenden Technologien effizient integrieren. Hier setzt Enterprise Architektur Management (EAM) an. Mit einem strukturierten Ansatz unterstützt EAM nicht nur die Optimierung von Geschäftsprozessen, IT-Systemen und Infrastruktur, sondern treibt auch die strategische Planung und Umsetzung von Innovationen voran. Laut Gartner ist Enterprise Architecture „ein umfassendes Framework, das Technologie, Daten, Prozesse und organisatorische Strukturen auf strategische Ziele ausrichtet. Durch die einheitliche Sicht ermöglicht es fundierte Entscheidungen, optimiert Ressourcen und bewältigt die Komplexität des digitalen Zeitalters.“ Die Definition von 2024 unterscheidet sich in ihrem Kern kaum von der Vision, die John Zachman – Schöpfer des Zachman-Frameworks – bereits 1987 formulierte: „Eine Unternehmensarchitektur ermöglicht es, Komplexität und Veränderungen zu beherrschen. Ohne Unternehmensarchitektur ist ein Unternehmen in einer zunehmend komplexen und sich verändernden Umgebung nicht überlebensfähig.“ Man könnte meinen, im Enterprise Architektur Management hat sich in den letzten 40 Jahren wenig verändert. Aber eine moderne EA ist keineswegs mehr die statische „Diagramm-Wüste“ von früher. Heute trägt eine EA entscheidend dazu bei das ein Business-IT-Alignment gelingt.

Business-IT-Alignment und EAM: Verbindung von Strategie, Operations und IT

Business-IT-Alignment beschreibt die Verzahnung von Geschäftsstrategie, operativen Tätigkeiten und IT-Infrastrukturen. Ziel ist es, IT als integralen Bestandteil der Organisation zu etablieren, der nahtlos mit den geschäftlichen Zielen und Abläufen zusammenwirkt. Ein starkes Business-IT-Alignment ermöglicht schneller auf Marktveränderungen zu reagieren, die Effizienz umfassend zu steigern und das Potenzial für Innovationen in der IT voll auszuschöpfen. Ob Digitalisierung, Data-Mesh, Cloud-Computing, Edge-Computing oder Künstliche Intelligenz – Business-IT-Alignment spielt bei jedem IT-Thema eine Rolle. Bei der Umsetzung werden stets Informationen aus einer Enterprise-Architektur benötigt. Auch wenn dies nicht immer ausdrücklich so genannt wird.

Die Informationen für Business-IT-Alignment lassen sich in vier Hauptbereiche unterteilen:

  • Strategische Inhalte umfassen die langfristigen Ziele, Visionen und Richtlinien des Unternehmens. Sie dienen als Leitplanken für Geschäfts- und IT-Entscheidungen und geben vor, wie Geschäfts- und IT-Prozesse gestaltet werden, um die übergeordneten Unternehmensziele zu unterstützen. Beispiele sind die Business-Planung, strategische Mittelfristplanung sowie Vision- und Mission-Statements.
  • Fachliche Inhalte beschreiben die Struktur der Geschäftsabläufe und enthalten Modelle, die das Unternehmen in seiner Funktionsweise detailliert abbilden. Sie bilden die Grundlage für die (fachliche) Anforderungsdefinition an IT-Systeme, etwa in Form von Prozessmodellen und Organisationsplänen.
  • Operative Inhalte beziehen sich auf die alltäglichen Geschäftsprozesse, die zur Erreichung der strategischen Ziele erforderlich sind. Sie umfassen die Daten zur konkreten Durchführung von Geschäftsaktivitäten, wie etwa das Ressourcenmanagement und die Prozessoptimierung (z.B. Inhalte des Process Mining oder ITSM).
  • Technische Inhalte beschreiben die Anwendungen und IT-Infrastrukturen, die zur Unterstützung der fachlichen und operativen Prozesse eingesetzt werden. Sie definieren technische Architekturen und Standards, die die Zuverlässigkeit und Effizienz der IT-Systeme sicherstellen. Beispiele hierfür sind IT-Architekturen, IT-Portfolios und technische Vorgaben.

Abbildung 1 veranschaulicht die Struktur dieser Bereiche – von strategisch bis operativ und von fachlich bis technisch. Jeder Kasten repräsentiert einen Inhaltsbereich. Zwischen den Bereichen existieren Überschneidungen, da eine klare Abgrenzung oft nicht möglich ist. Die gezeigten Inhalte sind exemplarisch und erheben keinen Anspruch auf Vollständigkeit.

Abb. 1: Unterteilung der EA-Bereiche inkl. exemplarischer Inhalte

Wer sich ernsthaft mit Business-IT-Alignment auseinandersetzt, erkennt schnell, dass dieser Ansatz weit über eine Abstimmung zwischen Fachbereichen und IT hinausgeht. Bastian Seebacher bringt es im CIO-Artikel „Die harte Wahrheit über Business-IT-Alignment“ auf den Punkt: „Business Applications sind in die Geschäftsprozesse des Unternehmens integriert. Das bedeutet umgekehrt: Die Geschäftsprozesse der Organisation sind um ihre Geschäftsanwendungen herum aufgebaut. Die Informationstechnologie […] ist in das Geschäft integriert, ob es jemandem gefällt oder nicht. Warum sollte man glauben, dass es gut gehen könnte, wenn die IT-Organisation lediglich aligned ist?“

Business-IT-Alignment und EAM: Mehr als Abstimmung von Fachbereich und IT

Aktuell häufig genannte Einsatzfelder des Enterprise Architektur Managements für Unternehmen und Behörden sind:

Synchronisation von Geschäfts- und IT-Strategie: Durch die gezielte Abstimmung von IT-Ressourcen, Projekten und Entscheidungen mit den strategischen Zielen des Unternehmens stellt das Enterprise Architektur Management sicher, dass IT nicht isoliert agiert. Stattdessen unterstützt sie aktiv die Wertschöpfung, Geschäftsentwicklung, Effizienzsteigerung und Innovation. Diese enge Verzahnung ermöglicht eine agile Reaktion auf Marktveränderungen und nutzt die IT als strategischen Hebel für den Geschäftserfolg.

Einführung neuer (Informations-)Technologien: Mit einer strukturierten Übersicht der gesamten IT-Landschaft erleichtert die Enterprise Architektur die Einführung neuer Technologien und die Optimierung bestehender Systeme. Sie fördert eine kohärente Gestaltung aller Innovationsinitiativen und stärkt die Agilität des Unternehmens.

Realisierung von KI- und ML-Lösungen: Enterprise Architektur liefert die Grundlage, um Künstliche Intelligenz (KI) und Machine Learning (ML) nahtlos in bestehende IT-Landschaften und Geschäftsprozesse zu integrieren. Sie identifiziert betroffene Unternehmensbereiche und relevante Datenquellen zur Entwicklung und kontinuierlichen Verbesserung von KI- und ML-Modellen. Zudem unterstützt sie die Skalierung und Anpassung von KI Lösungen, um auf veränderte Geschäftsanforderungen flexibel zu reagieren.

Aufbau von Data Meshes und Data Governance: Daten gewinnen im Geschäftsalltag zunehmend an Bedeutung. Eine moderne Datenverwaltung erfordert klare Strukturen und einheitliche Standards. Mit einer Enterprise Architektur wird die Datenverantwortung auf Domänen verteilt und Data-Governance-Richtlinien konsistent angewendet. So wird eine hohe Datenqualität, Sicherheit und Compliance sichergestellt. Die Integration von Data Meshes in die fachliche und technische Architektur schafft flexible, skalierbare Dateninfrastrukturen, die den Anforderungen datengetriebener Unternehmen gerecht werden.

Einbindung des Internets der Dinge (IoT) in Geschäftsprozesse: Enterprise Architekturen unterstützen die reibungslose Integration von IoT-Technologien in bestehende Geschäftsprozesse, indem sie strukturierte Informationen über zugrundeliegende IT-Infrastrukturen und Prozesse bereitstellen. Sie erleichtern die Gestaltung und Implementierung von Schnittstellen für einen sicheren und effizienten Datenaustausch zwischen IoT-Geräten und zentralen Systemen. Innovative IoT-Geschäftsmodelle können so gezielt verwirklicht werden.

Erstellung und Nutzung von Digital Twins: Eine Enterprise Architektur stellt die fachliche und technische Grundlage für den Aufbau von Digital Twins. Basierend auf EA-Inhalten werden operative Anforderungen, die betroffene IT-Infrastruktur und erforderliche Datenquellen konzeptionell verknüpft. So kann der Echtzeit-Datenfluss von physischen Systemen in virtuelle Modelle leichter synchron gehalten werden. Der Einsatz von Digital Twins zur Prozessoptimierung und Verbesserung von Produkten und Dienstleistungen wird dadurch erheblich vereinfacht.

Aufbau von Business-Impact- und IT-Risikomanagement-Systemen: Mit ihrer ganzheitlichen Sicht auf Geschäftsprozesse und die IT-Landschaft unterstützt eine Enterprise Architektur die Identifizierung kritischer Systeme und Prozesse für die Business Impact Analyse und das Risikomanagement. Transparente fachliche und technische Abhängigkeiten erlauben Risiken frühzeitig zu erkennen. Eine besondere Bedeutung liegt auf der Integration operativer Daten, die eine pro-aktive Risikominderung fördert und die Resilienz des Unternehmens steigert.

Für alle Anwendungsfälle ist eine fundierte Informationsbasis unerlässlich. Dazu muss der strategische Rahmen, das operative Umfeld (z.B. Geschäftsprozesse) und die technische Umsetzung (z.B. Infrastruktur) ganzheitlich und vernetzt dokumentiert werden. Eine rein manuell erstellte Enterprise Architektur kann das nicht mehr leisten. Stattdessen ist ein hybrider Ansatz gefragt, der manuelle und automatische Ansätze intelligent verbindet, um den Nutzen einer Enterprise Architektur optimal auszuschöpfen. Dabei git es zu entscheiden, welche Informationen manuell und welche automatisiert zu erfassen sind.

Tabelle 1 zeigt eine beispielhafte Übersicht von Business-, Applikations-, Daten- und Infrastruktur-Inhalten und ordnet diese nach ihrer primär Erfassung (manuell oder automatisiert). Ggf. sind Inhalte mehrfach aufgeführt, wenn diese je nach Ausprägung unterschiedlich zugeordnet werden können.

EA-Ebenei.d.R. manuell erfasste Inhaltegut automatisiert zu erfassende Inhalte
BusinessDigitalisierungsroadmapOrganisationsbeschreibungenBusiness Continuity VorgabenProzessmonitoring-InhalteMensch-Maschine-Interaktionen
DatenRisikokatalogefachlichen DatenstrukturenITSM Ticketinhalteimplementierte Datenstrukturen
ApplikationenArchitektur-Potential-AnalyseBetriebswirt. IT-Infrastrukturen
InfrastrukturArchitektur-Potential-AnalyseDienste-ModellDigitalisierungsarchitektur (technisch)Technische IT-Infrastrukturen
Tab. 1: exemplarische Zuordnung von EA-Inhalten nach Erfassungstyp (manuell o. automatisiert)

Eine effektive Enterprise Architektur basiert auf der Kombination aus manuell und automatisch erfassten Inhalten. Nicht alle relevanten Daten sind direkt in IT-Systemen verfügbar oder lassen sich automatisiert auslesen. Ein gutes Beispiel dafür ist die Digitalisierungsroadmap. Zwar werden bei ihrer Erstellung Computer genutzt, doch die strategische Planung selbst erfordert kreative menschliche Arbeit – auch in Zeiten von KI. Auf der anderen Seite gibt es zahlreiche Inhalte, die in digital verwertbarer Form vorliegen und automatisch in eine Enterprise Architektur integrierbar sind.

Integration in der EA: Manuell und automatisiert erfasste Inhalte verbinden

Im allgemeinen Sprachgebrauch bedeutet „integrieren,“ Verschiedenartiges miteinander zu vereinen. Auf eine Enterprise Architektur übertragen geht es darum, verschiedene Inhalte zu verknüpfen – von manuell erstellten Informationen bis zu automatisch aus digitalen Systemen extrahierten Daten.

Der klassische Ansatz ein EA Modell manuell zu erstellen, funktioniert heute nicht mehr. Die Menge an zu berücksichtigenden Informationen ist zu umfangreich. Ohne Computerunterstützung sind Aufbau und langfristige Wartung kaum mehr möglich. Gleichzeitig sind manuelle Schritte in begrenztem Umfang aber weiterhin notwendig, um einen strukturellen Rahmen zu schaffen. Dieser lässt sich nicht vollständig automatisieren. Das betrifft insbesondere Inhalte die nicht digital bereitgestellt werden, wie z. B. geplante zukünftige Architekturstrategien oder fachliche Beschreibungen von Geschäftsprozessen. Um den Pflegeaufwand zu minimieren, sollten diese aber auf ein Minimum reduziert werden. Stattdessen ist es sinnvoll, Inhalte wann immer möglich automatisch in die Architektur einzubinden.

Eine integrierte Enterprise Architektur verfolgt diesen Ansatz und adressiert so zwei zentrale Punkte:

  1. Die Zerlegung des gesamten EA-Modells in kleine, überschaubare „Einzelteile“, die von verschiedenen Teams wie Fachbereichsmitarbeitern, Architekten und Entwicklern gut beherrscht werden.
  2. Die automatische Einbindung von (ggf. externen) Inhalten aus diversen Informationsquellen wo immer möglich – kurz gesagt „Generieren statt Modellieren.“

Im Ergebnis entsteht eine Enterprise Architektur, die deskriptive (meist manuell erfasst) mit operativen (meist automatisiert erfasst) Inhalten verbindet. Methodisch wird der Ansatz durch die Anwendung der Bounded Context-Idee aus dem Domain Driven Design (DDD) auf die EA-Modellierung übertragen.

DDD und Enterprise Architektur: Struktur für klare Kontexte schaffen

Domain Driven Design (DDD) ist ein Ansatz zur Softwareentwicklung, der den Fokus auf das Verständnis und die Modellierung der zentralen Fachdomänen einer Organisation legt. DDD fördert die Aufteilung komplexer Systeme in klar abgegrenzte Domänen und Subdomänen, die jeweils unabhängig gestaltet und entwickelt werden. Durch gutes DDD wird sichergestellt, dass eine Softwarelösung präzise auf geschäftliche Anforderungen zugeschnitten und langfristig wartbar ist. Darin stellt ein „Bounded Context“ eine eindeutig definierte Einheit, in der Begriffe und Konzepte klar und konsistent verwendet werden (z. B. alle IT-Funktionen zur Kontoverwaltung einer Bank). Dadurch wird die Modularität gesteigert und die Entwicklung sowie Wartung von Software vereinfacht.

Übertragen auf eine integrierte Enterprise Architektur bedeutet der DDD-Ansatz, dass das EA-Modell unterhalb der Inhaltsklassen und Architektur-Ebenen in eindeutig abgegrenzte Kontexte strukturiert wird. Ähnlich wie im DDD werden Bereiche definiert, die einen Sachverhalt vollständig beschreiben (z. B. ein Kontext für alle BIA-Themen). Es ist zunächst unerheblich, ob ein Kontext manuell, automatisch oder durch eine Kombination beider Methoden befüllt wird. Entscheidend ist, die Kontexte so disjunkt wie möglich zu halten. Die Gesamtarchitektur entsteht durch „Zusammensetzen“ der Kontexte, die wie Puzzleteile automatisch zu einem Gesamtbild kombiniert werden. Auf diesem Weg ermöglicht eine integrierte Enterprise Architektur, ein vollständiges Bild der Architektur zu generieren und etwaige Inkonsistenzen mathematisch zu identifizieren. Im Ergebnis wird nicht nur die Erstellung vereinfacht, sondern die automatische Gewinnung übergreifender Erkenntnisse aus den EA-Inhalten erst möglich.

Das folgende Vorgehen hat sich in der Praxis für den Aufbau einer integrierten Enterprise Architektur bewährt. Es handelt sich nicht um einen „Grüne-Wiese-Ansatz“; auch bestehende „klassische“ Architekturen lassen sich auf diese Weise in eine integrierte Enterprise Architektur weiterentwickeln.

  1. Aufbau eines soliden EA-Fundaments: Schaffung einer stabilen Basisstruktur für die Architektur.
  2. Anbindung von (externen) Datenquellen: Integration zentraler (häufig auch externer) Informationsquellen.
  3. Erstellung (automatisierter) EA-Analysen: Aufbau von Analysen, die automatisch Erkenntnisse aus der Architektur generieren.
  4. Kommunikation der EA-Inhalte: Darstellung der Architekturinformationen, z. B. über Dashboards und generierte Visualisierungen zur Förderung der Transparenz und Entscheidungsfindung.
Aufbau eines soliden EA-Fundaments

Ein stabiles EA-Fundament ist die Voraussetzung, da es eine konsistente Basis für alle nachfolgenden Arbeiten bildet. Das Fundament legt zentrale Prinzipien, Standards und Strukturen fest, die die Architektur leiten und sicherstellen, dass die Inhalte harmonisch zusammenpassen. Dadurch wird die Komplexität verringert, Kommunikationsbarrieren werden abgebaut und das Risiko von Fehlentwicklungen oder Redundanzen minimiert. Zu unterscheiden ist dabei zwischen der Strukturdefinition (d. h. der Festlegung von Methoden und Notationen) und der Erfassung grundlegender Inhalte. Beides gehört zum Entwurf des EA-Fundamentes.

Es empfiehlt sich, mit einem einfachen aber flexiblen Meta-Modell zu starten. Das senkt die Einstiegshürden und ermöglicht erste Erfolge in kurzer Zeit. Erfasst werden die Inhalte des Fundaments in der Regel mithilfe eines Modellierungswerkzeugs. Ein rein manuell erstelltes Fundament ist jedoch nicht vollständig. Oft wird der Eindruck erweckt, dass mit der deskriptiven Beschreibung (z.B. in LeanIX, Orbus, BIC oder PlaningIT) bereits eine Enterprise Architektur vorliegt. Das ist jedoch nicht der Fall. Um Nutzen aus einer Enterprise Architektur zu ziehen muss die „reale Welt“ kontinuierlich berücksichtigt und das Modell laufend aktualisiert werden. Das ist mit einer klassischen, rein manuellen Modellierung nicht wirtschaftlich zu realisieren. Diese Herausforderung lässt sich durch die Anbindung operativer Datenquellen und eine automatische Erfassung lösen.

Anbindung von (externen) Datenquellen

Die Anbindung von Datenquellen ist essenziell für die kontinuierliche Aktualisierung einer Enterprise Architektur. Strategische, fachliche und technische Änderungen werden so automatisch in der Architektur berücksichtigt. Entscheidungen lassen sich dann auf Basis aktueller Informationen treffen. Zusätzlich trägt die Integration externer Datenquellen dazu bei, dass die Enterprise Architektur den dynamischen Anforderungen des Unternehmensumfelds stets gerecht wird. Operative Anwendungen wie SAP, Salesforce oder ServiceNow verfügen über REST-basierte Schnittstellen, die digital verwertbare Formate bereitstellen. Eine Integration ist in den meisten Fällen einfach möglich. Es ist aber entscheidend, automatisch erfasste Daten flexibel mit manuell dokumentierten Inhalten in einem Gesamtmodell zu verknüpfen. Technisch ist diese Verbindung einfach mit einem Open-Source-Ansatz auf Basis einer Graph-Datenbank zu realisieren. Die schemafreien NoSQL Funktionalitäten von Graph-Datenbanken bieten eine Flexibilität, die es erlaubt nahezu alle – auch heute noch nicht bekannte – Inhalte direkt im EA-Modell zu ergänzen. Kein proprietäres EA-Tool bietet aktuell die Flexibilität, Funktionalität und Offenheit, um Datenquellen in einer vergleichbar kostengünstigen Form zu integrieren. Abbildung 2 zeigt exemplarisch das Zusammenspiel von operativen Datenquellen mit einer Graph-Datenbank als EA-Data-Hub.

Abb. 2: Graph-DB als EA-Data-Hub zur neutralen Konsolidierung verschiedener Inhaltstypen
Erstellung (automatisierter) EA-Analysen

Die einfache und kostengünstige Erstellung von Analysen ist zentraler Bestandteil einer zeitgemäßen Enterprise Architektur. Erst dann lassen sich wertvolle Erkenntnisse auf Basis der eigenen Daten ableiten. Das umfasst beispielsweise die Identifizierung von IT-Redundanzen, die Bewertung der Ausrichtung von IT-Systemen an Geschäftsprozessen, Risikoanalysen hinsichtlich möglicher Systemausfälle oder Sicherheitslücken sowie Business-Impact-Betrachtungen und deren Auswirkungen auf die Organisation.

Ein kurzer Exkurs zum Einsatz künstlicher Intelligenz (KI) im Umfeld von EA-Analysen ist an dieser Stelle angebracht. Die Hersteller von EA-Tools verbinden den Begriff „künstliche Intelligenz“ mit einer Vielzahl unterschiedlicher Funktionen – von einfachen Assistenten zur Erledigung standardisierter Aufgaben bis hin zur automatischen Inhaltserstellung basierend auf öffentlich zugänglichen KI-Modellen wie ChatGPT. Solche Funktionen können durchaus hilfreich sein. Sie bieten aber keine Lösungen für spezifische Anforderungen an die Auswertung der eigenen Daten. Das ist nur möglich, wenn die KI mit den eigenen Daten trainiert wird. Ob man nun sensible Daten zur Verbesserung von KI-Assistenten an externe – meist US-amerikanische – Unternehmen übermittelt bleibt jedem selbst überlassen. Wer jedoch ChatGPT oder andere Cloud-basierte Assistenten nutzt, muss sich darüber im Klaren sein, dass seine Daten an externe Anbieter übertragen werden. Laut einer aktuellen Studie des Marktforschungsunternehmens IDC wird nicht zuletzt deshalb der rechtssichere Einsatz von Microsoft-Diensten wie Microsoft 365, MS Fabrics oder MS Power BI zunehmend kritisch gesehen (IDC). Für einen wirklich nützlichen KI-Einsatz in der EA ist es aber unerlässlich, eine Analyse auf Basis eigener Daten durchzuführen – und das ohne die Kontrolle über schützenswertes Wissen zu verlieren. Das geht nur, wenn das zugrundeliegende KI-Modell selbst verwaltet wird und kein wertvolles internes Wissen abfließt.

Und es gibt noch einen Grund, warum bei einer integrierten Enterprise Architektur ein lokaler Ansatz sinnvoll ist: Kosten. Immer mehr Unternehmen stellen fest, dass die versprochenen Kosteneinsparungen durch Cloud-Anbieter nicht eintreten. In den letzten Monaten zeigt sich ein klarer Trend, bei dem Unternehmen bestimmte Services wieder in On-Premises-Umgebungen zurückverlagern. Besonders Public-Cloud-Lösungen erweisen sich dabei häufig als Kostenfaktor. Jetzt noch KI-Funktionalitäten an externe Dienstleister auszulagern, wenn diese auch intern sicherer und kostengünstiger betrieben werden könnten, erscheint zunehmend fragwürdig. Die Ankündigung von Microsoft, die Preise des Analysewerkzeuges PowerBI um bis zu 40% zu erhöhen unterstreicht diese Entwicklung (Heise).

Kommunikation der EA-Inhalte

Enterprise Architekturen entfalten ihren vollen Mehrwert, wenn die Inhalte einer breiten Basis an Nutzern zur Verfügung gestellt werden. Dynamische Dashboards spielen dabei eine zentrale Rolle, da sie komplexe Daten und Zusammenhänge in Echtzeit visuell aufbereiten und die Informationsbasis für fundierte Entscheidungen liefern. Solche Dashboards versetzen Anwender in die Lage, auf Veränderungen unmittelbar zu reagieren. Durch Echtzeit-Visualisierungen wird die Architektur nicht nur als strategisches Werkzeug genutzt, sondern leistet auch im Tagesgeschäft wertvolle Unterstützung. Dynamische Dashboards können mit einem rein statischen EA-Modell aber nicht erzeugt werden. Erst durch die Verbindung mit operativen Systemen wird ein echter Informationsmehrwert geschaffen.

Beispiel: BIA und IT-Risikomanagement auf Basis einer integrierten Enterprise Architektur

Das folgende Beispiel zeigt anhand einer fiktiven Bank, wie mit Hilfe einer integrierten Enterprise Architektur eine dynamische Business-Impact-Analyse (BIA) sowie ein IT-Risikomanagement aufgebaut werden kann. Zur besseren Nachvollziehbarkeit fokussiert das Beispiel nur auf Inhalte, die für den Aufbau der BIA und der IT-Gefährdungsanalyse erforderlich sind. Das beschriebene Vorgehen ist aber universell und kann auf alle zuvor genannten Anwendungsfälle angewendet werden.

Im Beispiel kommt das kommerzielle Modellierungswerkzeug BIC der GBTEC Software AG, die Open-Source Version der Graphdatenbank Neo4j der Neo4j Inc., zwei öffentlich zugängliche Web-APIs und ein Open-Source Dashboard zum Einsatz. Die Auswahl der Werkzeuge ist exemplarisch – das Vorgehen lässt sich auch mit alternativen Tool-Kombinationen umsetzen, etwa mit BOC Adonis, SAP Signavio, SAP LeanIX, Sparx Enterprise Architect, ArangoDB oder OrientDB.

Basis-Struktur für die BIA und ein IT-Risikomanagement

Im ersten Schritt wird das EA-Fundament für die BIA und das IT-Risikomanagement in den Bereichen Business-, Daten-, Applikations- und Technologie-Architektur aufgebaut. Ziel ist es, die grundlegenden Verbindungen zwischen dem operativen Geschäft der Bank und den zugehörigen IT-Strukturen zu erfassen. Das entstehende Netzwerk an Beziehungen bildet die Basis der integrierten Enterprise Architektur und dient als Ausgangspunkt für weitere Analysen. Abbildung 3 zeigt die – für das Beispiel reduzierte – Struktur der erfassten Inhalte und Zusammenhänge.

Inhaltstypen zur automatischen Erstellung einer BIA und IT-Risikobewertung (Beispiel)
Abb. 3: Inhaltstypen zur automatischen Erstellung einer BIA und IT-Risikobewertung (Beispiel)

Im Rahmen der Business-Architektur werden zunächst Business Capability Maps für die Bank erstellt. Diese Landkarten beschreiben die Fähigkeiten, welche die Bank benötigt um strategische Ziele zu erreichen und Geschäftsprozesse erfolgreich auszuführen. Business Capabilities werden nach Kategorien gegliedert und dienen – neben der strategischen Planung – der Ermittlung welche Leistungen bei IT-Ausfällen nicht mehr erbracht werden können. Abbildung 4 zeigt die mehrstufige Visualisierung der Business Capabilities der fiktiven Bank, dokumentiert mit dem Werkzeug BIC. Da sich Business Capabilities nicht ständig ändern, ist eine manuelle Erfassung in einem deskriptiven Modellierungswerkzeug vertretbar.

Business Capability Maps im Bereich Banking
Abb. 4: Business Capability Maps im Bereich Banking

Im nächsten Schritt werden den Business Capabilities – wo sinnvoll – Kernprozesse und detaillierte Geschäftsprozesse zugeordnet. Zur Modellierung empfiehlt sich eine Darstellung mittels Business Process Model and Notation (BPMN). Abbildung 5 zeigt ein exemplarisches BPMN-Diagramm im Bereich Kundenmanagement (inklusive Detailausschnitt). Neben der Dokumentation des Sequenzflusses werden auch die verarbeiteten Informationen bzw. Geschäftsobjekte und die zur Prozessausführung benötigten IT-Systeme erhoben.

BPMN-Beispiel „Create new Customer“
Abb. 5: BPMN-Beispiel „Create new Customer“

Im Rahmen der Datenarchitektur werden Geschäftsobjekte je nach Bedarf detailliert und zusammengesetzte Data Products (z.B. BIA Dashboard) aggregiert. Das EA-Fundament stellt im Ergebnis eine Bibliothek der Geschäftsobjekte und die „Baupläne“, wie Data Products aus diesen Objekten zusammengesetzt werden bereit. Abbildung 6 zeigt die exemplarische Beschreibung des Datenobjekts „Loan Application“ und des Data Product „BIA Dashboard“ im Modellierungswerkzeug BIC. Natürlich ist auch die Anbindung alternativer Werkzeuge zur Datenmodellierung möglich.

Details zum Geschäftsobjekt „Loan-Application“ und BIA Dashboard Entwurf
Abb. 6: Details zum Geschäftsobjekt „Loan-Application“ und BIA Dashboard Entwurf

Die Dokumentation von Anwendungssystemen erfolgt im Rahmen der Applikations-Architektur. Falls bereits eine zentral gepflegte Applikationsverwaltung existiert, kann auch ein IT-Portfolio-Werkzeug angebunden werden. Entscheidend ist, dass zu jeder Applikation die im EA-Kontext erforderlichen Informationen in das Fundament übertragen werden. Abbildung 7 zeigt einen Ausschnitt aus der Applikationsbibliothek: links manuell in BIC erfasst – rechts automatisch aus CMDB-Daten über eine REST API importiert und generiert.

Beispiel eines Eintrags der Applikations-Bibliothek (manuell erstellt bzw. importiert)
Abb. 7: Beispiel eines Eintrags der Applikations-Bibliothek (manuell erstellt bzw. importiert)

Die Technologie-Architektur ergänzt zu jeder Applikation die zugehörigen IT-Komponenten. Eine IT-Komponente ist ein eigenständiges Element der IT-Infrastruktur, das spezifische Funktionen oder Dienstleistungen bereitstellt und mit anderen Komponenten interagieren kann (z.B. Hardware, System-Software, Netzwerkelemente). Durch die generische Abbildung als „IT-Komponente“ lassen sich auch komplexe Zusammenhänge einfach visualisieren (siehe Abbildung 8). Im Beispiel wird die IT-Komponentenlandschaft direkt aus den Daten einer CMDB visualisiert. Die Verbindung zwischen der CMDB und BIC erfolgt im Beispiel zur Laufzeit, sodass die Ansicht immer aktuell ist und automatisch visualisiert werden kann.

Abb. 8: IT-Komponenten der Applikation SAP FS-CML S/4 HANA

Zum Abschluss werden die Business Capabilities, Geschäftsprozesse, Geschäftsobjekte, Data Products, Applikationen und IT-Komponenten automatisch zu einem umfassenden EA-Graphen zusammengefügt. Abbildung 9 zeigt für die Applikation SAP FS-CML S/4 HANA die automatisch erstellte Kontext-Darstellung. Wichtig ist, dass nur Inhalte mit hoher zeitlicher Stabilität manuell erfasst werden. Inhalte die sich kontinuierlich ändern, werden automatisch eingebunden und visualisiert (generiert).

Abb. 9: Kontext des Bereichs „Kreditprüfung“

Damit ist das EA-Fundament für die geplante Business-Impact- und IT-Gefährdungsanalyse vollständig.

Anbindung ITSM und IT-Security Systeme

Wie oben erläutert, entsteht erst durch die Anbindung dynamischer Informationsquellen eine integrierte Enterprise-Architektur, die stets aktuelle, geschäftskritische Informationen liefert. Im Beispiel der Bank werden dafür Incident-Meldungen aus einem ITSM-System und IT-Gefährdungsmeldungen aus einer Vulnerability Database in Echtzeit abgerufen und dynamisch mit dem EA-Fundament verknüpft.

Incidents bilden das Rückgrat jeder BIA. Öffentliche Vulnerability-Datenbanken liefern Informationen über Schwachstellen in gängigen Software- und Hardwarekomponenten. Beide zusammen erlauben es, stets aktuelle Auswirkungen von Incidents auf das operative Geschäft darzustellen und kontinuierlich die Applikationslandschaft auf neue IT-Risiken zu überprüfen. Da IT-Landschaften in Unternehmen und Behörden kompliziert und vielschichtig sind, ist es nahezu unmöglich diese Prüfungen manuell zu geringen Kosten umzusetzen.

Für ein möglichst realitätsnahes Beispiel werden Meldungen aus dem Incident-Management-System von DigitalOcean und Gefährdungsdaten aus der Vulnerability Database des National Institute of Standards and Technology (NIST) integriert. Beide Datenquellen sind über frei zugängliche REST-APIs abrufbar und liefern JSON-Daten, die ohne manuelle Nachbearbeitung in das EA-Fundament eingebunden werden. Bei der Verknüpfung handelt es sich nur um ein Beispiel zur Verdeutlichung der Vorgehensweise. Die fiktive Bank und die angezeigten Echt-Daten haben keinen realen Hintergrund zu DigitalOcean oder dem NIST.

Aktuelle Inhalte zu DigitalOcean Incidents und NIST CVE-Daten für „Microsoft Dynamics 365“ finden Sie als JSON-Stream unter folgenden URIs:

DigitalOcean Incidents: https://status.digitalocean.com/api/v2/incidents.json

NIST CVE Database: https://nvd.nist.gov/vuln/search/results?form_type=Basic&results_type=overview&query=Microsoft+Dynamics+365&search_type=all&isCpeNameSearch=false

Hinweis: die Abfrage kann einige Sekunden dauern, da umfangreiche Daten abgerufen werden

Grundsätzlich lassen sich alle Datenquellen, die per REST-API verfügbar sind ohne zusätzliche Programmierung oder Software einbinden – sei es SAP ERP, Salesforce, ServiceNow, JIRA, Confluence und viele mehr. Es ist nicht erforderlich Schnittstellen zu programmieren oder zu kaufen.

Vielmehr reichen Standardfunktionen der Open-Source-Graph-Datenbank Neo4j, um relevante Artefakte direkt aus dem JSON-Stream zu extrahieren und in das EA-Modell zu integrieren. Abbildung 10 veranschaulicht die Anbindung der Datenquellen an die Neo4j-Datenbank.

Datenquellen des exemplarischen EAM-Beispiels
Abb. 10: Datenquellen des exemplarischen EAM-Beispiels

In wenigen Schritten wird das EA-Fundament gemeinsam mit den dynamisch eingebundenen Inhalten zu einer umfassenden, integrierten Enterprise-Architektur. Neo4j übernimmt die Aufbereitung aller Inhalte. Abbildung 11 zeigt beispielhaft die strukturierte Ausgabe der NIST-CVE-Abfrage zu „Microsoft Dynamics“, die nahtlos in das EA-Modell eingebunden wird.

Aufbereitete Inhalte der NIST-CVE-Datenbank
Abb. 11: Aufbereitete Inhalte der NIST-CVE-Datenbank

Da Neo4j Funktionen zur Verarbeitung externer Daten bietet, ist die Integration von Drittsystemen in kürzester Zeit möglich. Auf proprietäre Schnittstellen zwischen einzelnen Werkzeugen kann verzichtet werden, was die Kosten der technischen Integration massiv senkt. Gleichzeitig erhöht sich die Flexibilität der integrierten Enterprise-Architektur. Jede REST-basierte Anwendung kann direkt in das Gesamtmodell eingebunden werden. Zukünftig lassen sich so weitere Datenquellen problemlos hinzufügen, solange sie über REST-Schnittstellen zugänglich sind.

Definition BIA und IT-Risikoanalyse

Für die Business Impact und IT-Risikoanalyse benötigt die Bank maßgeschneiderte Auswertungen, um potenzielle Auswirkungen von IT-Ausfällen auf die kritischen Geschäftsprozesse zu bewerten. Dazu gehört die Identifikation von Abhängigkeiten zwischen IT-Systemen und geschäftlichen Funktionen sowie die Analyse von Bedrohungen und Schwachstellen in der IT-Infrastruktur. Um bei der pro-aktiven Schwachstellenanalyse Datenschutz- und Sicherheitsrisiken zu vermeiden, führt die Bank sämtliche Auswertungen innerhalb ihrer eigenen IT-Umgebung durch. Das ist möglich, da das integrierte EA-Modell vollständig unter der Kontrolle der Bank liegt. Auf diese Weise erhält die Bank präzise Risikoeinschätzungen und kann Maßnahmen zur Risikominderung und Notfallplanung gezielt ableiten – alle kritischen Daten bleiben in ihrer sicheren Umgebung. Der Clou: Neo4j stellt die erforderlichen Algorithmen kostenfrei bereit.

Abbildung 12 zeigt den Knowledge-Graph aus deskriptiven und operativen Daten, der zum lokalen Training der Analyse-Algorithmen verwendet wird.

Abb. 12: Visualisierung des erzeugten EA-Modells als Knowledge-Graph

Im Beispiel werden anhand von Incidents aus dem ITSM-System sowie der Inhalte aus BIC die operativen Prozesse proaktiv auf Verbesserungspotenziale untersucht. Abbildung 13 hebt die identifizierten Optimierungsmöglichkeiten farblich hervor. Selbst trainierte KI-Algorithmen konnten diese Ergebnisse direkt aus dem integrierten Modell ableiten. Rot markierte Prozesse sind in Bezug auf die Applikations-, Daten- oder Organisationsgestaltung nicht optimal und sollten einer weitergehenden Betrachtung unterzogen werden.

Algorithmisch analysierte Geschäftsprozesse unter Einbezug dynamischer Daten aus der ITSM- und Risikoanalyse
Abb. 13: Algorithmisch analysierte Geschäftsprozesse unter Einbezug dynamischer Daten aus der ITSM- und Risikoanalyse
Aufbau BiA und IT-Gefährdungsanaylse Dashboard

Damit auch operative Stakeholder von der integrierten Enterprise Architektur profitieren, müssen verständlich aufbereitete Informationen bereitgestellt werden. In der fiktiven Bank kommt ein TypeScript-basiertes Open-Source-Dashboard zum Einsatz, das Inhalte aus BIC, Neo4j und den angebundenen externen Quellen dynamisch zusammenführt und automatisch darstellt. Besonders hervorzuheben ist, dass alle Analysen aus dem vorherigen Schritt (u.a. die KI Auswertungen) direkt im Dashboard ausführbar sind – eine Überführung in ein weiteres Tool ist nicht notwendig. Abbildung 14 zeigt beispielhaft die dynamische Visualisierung der Business-Impact-Daten für einzeln selektierbare Incidents.

Abb. 14: Dynamische Visualisierung der Business Impact Analyse

Die verknüpften Daten zeigen, dass z.B. ein Ausfall des Service „App Platform and Container Registry in NYC“ zu Einschränkungen der IT-Komponente „Container Registry – NYC3“ führen und in der Folge die Komponente „PS Linux App Kubernetes Platform 02“ nicht mehr ordnungsgemäß arbeitet. Dies bedeutet, dass die interne Applikation „ABC Online (internal)“ nicht mehr verfügbar ist, was den Ausfall der Geschäftsprozesse „New Customer creation“, „Customer auditing“ und „Customer startup“ zur Folge hat. Diese Auswertung wird vollständig automatisiert erstellt.

Neben dynamischen Ad-hoc-Analysen lässt sich ein kontinuierliches Monitoring mit automatischer Auslösung von Ereignissen bei Eintritt vordefinierter Zustände mit Bordmitteln der Neo4j-Datenbank umsetzen. Abbildung 15 zeigt die Ausgangsdaten, die aus der NIST Risiko-Datenbank ermittelt und auf die IT-Infrastruktur der Bank projiziert werden. Im Beispiel werden sämtliche IT-Systeme der Bank kontinuierlich auf IT-Risiken überprüft und zu jeder Applikation (wenn erforderlich) Gegenmaßnahmen angezeigt.

Abb. 15: Abgleich der internen Applikationslandschaft mit extern erkannten IT-Risiken

Alle Analysen basieren auf dem integrierten EA-Modell inkl. der Daten aus operativen Systemen. Wo immer möglich, werden visuelle Darstellungen generiert, anstatt manuell modelliert. Dies vereinfacht die Verwaltung der Enterprise Architektur und verbessert die Datenqualität, da Inhalte immer aktuell bereitgestellt und Fehlerquellen minimiert werden. Die Kosten für das Enterprise-Architektur-Management sind dann dauerhaft optimal gestaltet. Zentrales Motto ist immer: „Generierung vor Modellierung“.

Fazit

Eine moderne Enterprise Architektur erfordert einen integrierten Ansatz, der deskriptive und operative Inhalte flexibel verknüpft. Dabei sollten wenig wertschöpfende manuelle Arbeiten (wie zum Beispiel die manuelle Modellierung) im Enterprise Architektur Management auf ein Minimum reduziert werden. Architekten können sich dann auf strategische, operative und IT-Optimierungen konzentrieren und echten Wert für die Organisation schaffen. Durch die Verbindung „klassischer“ Enterprise Architekturen mit operativen Daten ist es möglich, zu geringen Kosten eine zukunftsweisende Enterprise Architektur umzusetzen.

Der Artikel „So funktioniert der Knowledge Graph von Leoni“ im CIO Magazin beschreibt den integrierten Ansatz an einem realen Beispiel.