Ein attraktives Produkt zu einem attraktiven Preis produzieren bzw. anbieten zu können, hört sich einfach an, aber die dauerhafte Bereitstellung der dafür nötigen Mittel, die Wahrung der Produktqualität sowie Vermarktung, das gesamte Zahlungs- und Berichtswesen sowie die Einhaltung zahlreicher Vorgaben bilden ein extrem komplexes Gefüge für jedes Unternehmen. Was passiert, wenn die ‚digitale Disruption‘, sich verändernde Märkte, „Cyber-Security“, die Globalisierung sowie ständige regulative Veränderungen hinzukommen? Diese Gesamtkomplexität, die damit verbundenen Risiken, aber auch Möglichkeiten für das Unternehmen, müssen stetig verstanden und bewertet werden. Hier kommt die Enterprise Architecture (EA, Enterprise Architektur, Unternehmensarchitektur) ins Spiel.
Die Enterprise Architektur wurde dafür entwickelt, die Komplexität von Unternehmen versteh- und beherrschbar zu machen, mittels geeigneter Perspektiven, die wiederum Aufschluss über Abhängigkeiten und Auswirkungen aller relevanten Aspekte im Unternehmen bieten.
Die Herausforderung ist hierbei eben diese Aspekte sowie die damit verbundenen Bausteine, wie bspw. Prozesse oder Applikationen, eindeutig beschreiben, klassifizieren und katalogisieren zu
können. Diese Beschreibungssystematik muss nicht nur umfassend, sondern auch erweiterbar und flexibel bleiben. Unternehmen wollen nicht immer das Rad neu erfinden müssen, sobald Veränderungen im Markt, Geschäftsbetrieb, oder durch Mitarbeiterwechsel, eintreten. Hierfür wurden Rahmenwerke (Frameworks) für die Enterprise Architecture entwickelt.
Was ist ein Enterprise Architecture Framework?
Ein EA-Framework umfasst den Bezug sogenannter Architekturbausteine zur Organisation und dem Geschäftsmodell sowie klare und verständliche Definitionen dieser Bausteine, ein eindeutiges System zu Klassifizierung und Katalogisierung sowie Methoden und Handlungsanleitungen. Ebenso muss es
möglich sein, Einflussfaktoren und Ergebnisse, Zwecke und Ziele – die sogenannte
Motivationsebene – beschreiben und mit Architekturbausteinen verknüpfen zu können.
Wie wählt man ein geeignetes Framework aus?
Nach dem Commitment zu einem Framework-Einsatz, stellt sich unmittelbar die Frage: welches?
Es gibt eine Vielzahl solcher für die unterschiedlichsten Organisationen geeigneten Rahmenwerke, deshalb gilt es zu verstehen, wie und warum diese entstanden sind.
„Godfather“ der EA-Rahmenwerke: Zachman Framework
Häufig, wenn ein Framework für Enterprise Architecture-Frameworks gesucht wird, fällt der Name John Zachman, der 1987 während seiner Zeit bei **** das nach ihm benannte „Zachman Framework“ entwickelte. Dies ist jedoch kein voll ausgeprägtes Rahmenwerk, sondern eher eine Klassifizierung von modellhaften Darstellungen, die in ihrer Gesamtheit eine Enterprise Architektur beschreibt, orientiert an den klassischen „W-Fragen“: Wer, Was, Wann, Wie, Wo, Warum.
Das gängigste Rahmenwerk für EA heute: TOGAF
Während der letzten 30 Jahre hat insbesondere ein Rahmenwerk die größte Bekanntheit erlangt: Das TOGAF (The Open Group Architecture Framework, geschützte Marke The Open Group), aktuell in der zehnten Version. Das bekannteste und am meisten verwendete Element dieses Rahmenwerkes ist ADM (Architecture Development Method). Hierbei handelt es sich um ein zyklisches Vorgehensmodell für die Entwicklung von Architekturen, welches abgeleitet von der Architekturvision, die einzelnen Planungs- und Umsetzungsphasen sehr detailliert beschreibt und für jede Phase klare Ergebnistypen definiert. ADM behandelt auch Aspekte des Change-Managements und der Steuerung. Das Anforderungsmanagement ist zentraler Bezugspunkt für alle Phasen.
Somit bietet das TOGAF sehr gute Anleitungen und Hilfestellungen für die Entwicklung, oder den Ausbau von Architekturen. Dies muss jedoch an die jeweilige Unternehmenssituation angepasst werden.
Weitere häufig genannte Rahmenwerke:
- SPEWAK: 1992 entwickelt von Steven Spewak mit einem Schwerpunkt, der nicht in der EA-Planung, sondern auf den Auswirkungen für das Unternehmen liegt. Nicht die Anforderungen stehen im Zentrum der Architekturentwicklung, sondern die Geschäftsziele, aus denen sich das dafür nötige Informationsmodell ableitet und danach die nötigen Informationssysteme und Applikationen, aus denen sich wiederum die notwendige, technologische Infrastruktur ableiten lässt
- MERISE: Entwickelt in Frankreich, ist es bis heute positiv konnotiert in der Branche. Es wurde vor allem in den 70er Jahren bis in die frühen 80er verwendet, um die zunehmende „Computerisierung“ von Unternehmen zu unterstützen. Merise trennt Daten und Prozesse, wobei Daten auf drei Ebenen beschrieben werden: Konzeptionell, logisch, physisch. Auch für Prozesse gibt es diese drei Sichten, nur hier heißen sie konzeptionell, organisatorisch, operativ. Das Vorgehensmodell enthält die Phasen: Strategische Planung, Vorstudie, Detailstudie, Entwicklung, Einführung und Wartung / Pflege
- UML: Die Unified Modeling Language (UML) wurde 1994 - 1995 entwickelt und später von der Object Management Group (OMG) übernommen. Eigentlich ist es nicht wirklich ein Rahmenwerk, sondern „nur“ eine Modellierungssprache“. Zweck ist eine standardisierte Beschreibung von Softwaresystemen anhand vordefinierter Sichten oder Diagramme. Tatsächlich wird aber Unternehmensarchitektur gelegentlich sehr Software-lastig aufgefasst, so dass UML hier auch erwähnt werden soll
- Hinzu kommen weitere Frameworks, die hier nicht weiter erläutert werden, aber deren Betrachtung erwähnenswert ist: DODAF, The Common Approach, FEAF, MODAF, DNDAF, NAF, UAF.
Jedes Framework hat seine klare Existenzberechtigung – ist für einen oder mehrere spezifische Zwecke bestimmt. Die Wahl eines Frameworks erfolgt immer im Hinblick auf das Ziel der Organisation. Es gilt einen standardisierten, verständlichen und konsistenten Rahmen zu schaffen für die Entwicklung einer Enterprise Architektur.
Industriespezifische Frameworks
Nahezu jeder Industrie- oder Wirtschaftsbereich hat seine eigenen Rahmenbedingungen, Regularien und damit Anforderungen. Hierfür gibt es Frameworks, die diese branchenspezifischen Anforderungen für die Enterprise Architektur adressieren. Im Nachfolgenden einige Beispiele hierzu:
- ACORD (Association for Cooperative Operations Research and Development) für die Versicherungsbranche
- BIAN (Banking Industry Architecture Network) primär für die Finanzbranche entwickelt
Business Architecture Framework
Das Unternehmen, welches sich auf die Business Architecture (Geschäftsarchitektur) spezialisiert hat, ist die Business Architecture Guild (The Guild). The Guild hat hierfür das BIZBOK entwickelt, das „Business Architecture Body of Knowledge“. Dies bietet ein umfassendes Rahmenwerk für die Entwicklung und die Unterstützung von Geschäftsarchitekturen im Allgemeinen aber auch grundlegende, eher industrie- bzw. branchenspezifische Referenzmodelle, die relativ leicht anzuwenden sind.
Es gibt viele unterschiedliche Rahmenwerke – wie und wo starten?
Eine Enterprise Architektur zu etablieren ist eine anspruchsvolle Aufgabe, bei der vorbereitete Rahmenwerke helfen können, insbesondere in der Anfangsphase. Nur wenige Unternehmen nutzen solche Rahmenwerke jedoch vollumfänglich. Wozu auch? Dieses Vorhaben wäre langwierig, aufwendig und damit teuer und der Erfolg wäre fraglich. Es bleibt nicht bei der initialen Schulung und Einführung aller Dimensionen des Rahmenwerkes - es muss nachhaltig bedient und ggf. weiterentwickelt werden.
Die meisten Unternehmen suchen sich daher ein Rahmenwerk, dass nahezu passend erscheint und adaptieren es auf ihre spezifischen Belange. Oder sie treffen eine Auswahl aus Elemente mehrerer Frameworks und bauen sich sozusagen ein eigenes Rahmenwerk.
Wichtig ist, zu verstehen:
- wofür die Enterprise Architektur im Unternehmen dienen soll und damit auch das Framework
- welche Personen bzw. Rollen im Unternehmen, das ausgewählte oder entwickelte Rahmenwerk im Unternehmen am Leben halten / betreiben würden
- welche schon vorhandene Rahmenwerke man nutzen bzw. adaptieren könnte, ihr Ursprung, Motivation und Zweck sowie die beteiligten Akteure
Agile Enterprise Architektur & die veränderte Rolle der Enterprise Architekten
Einer der größten Kritikpunkte an Enterprise Architektur ist, dass sie zu starr und kompliziert und damit nicht flexibel genug ist, um mit technologischen Entwicklungen Schritt zu halten.
Die Entwicklung agiler Methoden und Vorgehensweisen zwingt stärker als alle anderen Trends die EA zu Veränderungen. Lesen Sie mehr in unserem Blog-Artikel: Wie EA die Agilität stärkt
Geschäftsmodelle verändern sich heute häufiger und schneller als früher, eben durch die Einführung neuer Technologien, neuer Fähigkeiten, oder der daraus resultierenden Notwendigkeit, den Kunden stärker in den Fokus zu rücken und seine Customer Journey (Reise des Kunden entlang allen Berührungspunkten mit dem Unternehmen).
Die Automatisierung von Architekturprozessen ist hierfür entscheidend. Enterprise Architects gewinnen aktuell mehr Zeit das zu tun, was sie eigentlich tun sollten – Architekturen entwerfen,
Alternativarchitekturen vergleichen und damit der Unternehmensleitung Handlungsspielräume aufzeigen können. Ganz im Gegensatz zu dem ‚reinen‘ Abrufen der aktuellen IT-Informationen. Sie sind bspw. involviert in die Beurteilung aufkommender Technologien, durch ihre Kenntnisse über Zusammenhänge und Wirkungsketten im Unternehmen. Rein technisches Wissen ist dabei nicht mehr ausreichend, wohl aber Urteilsvermögen darüber wie die Technologie das Geschäftsmodell unterstützen kann sowie welche Chancen und Risiken sich daraus ergeben.
Weiterführende Links zu den Themen, die für Sie interessant sein könnten:
- Sehen Sie hier (in unserer Infografik) auf einen Blick, wie sich die
Rolle des Enterprise Architekten verändert - Lesen Sie hier, wie Agile@Scale bzw. das SAFe (Scale Agile Framework) integriert und die
bereichsübergreifende Zusammenarbeit unterstützt werden kann, ganz im Sinne der agilen Produktentwicklung
Ist die traditionelle Enterprise Architektur am Ende?
Unternehmen werden immer Enterprise Architecture benötigen, aber natürlich muss sich auch die EA kontinuierlich anpassen an neue Organisationsformen, Managementstile und insbesondere an neue Verfahrensweisen zur Produktentwicklung. Kundenorientierung und modulares Design bedeuten eine höhere „Time-to-Value“. Somit müssen dann auch Rahmenwerke für Enterprise Architecture erweiterbar sein. Risiko- und Compliance-Management sind fast gänzlich neue Aspekte und es zeigt sich, dass deren Einbeziehung die Weiterentwicklung von EA-Frameworks aktuell deutlich beschleunigen kann.
Risiken müssen korrekt den Architekturbausteinen zugeordnet werden, um dann auf Systeme, Prozesse, Fähigkeiten, Organisation, Produkt aggregiert werden zu können. Dasselbe gilt für regulative Anforderungen - insbesondere die DSGVO leistet hier derzeit Vorschub. Es muss verstanden werden, welche Daten wie und von welchen Bausteinen (Prozesse oder IT-Systeme) verarbeitet werden. Compliance- und Risiko-Management sind daher eigentlich integraler Bestandteil der EA.
Traditionelle Frameworks für Enterprise Architecture
müssen erneuert werden
Traditionelle Frameworks müssen erneuert werden und Agilität, Risiko- und Compliance-Management, Innovation sowie Disruption berücksichtigen bzw. stärker einbeziehen. Ebenso müssen sie die Entwicklung von Minimum Viable Architectures unterstützen, also Architekturen, die „nur“ bieten was nötig ist, aber eben nicht mehr. MEGA International ist Mitglied der OMG (Object Management Group) und arbeitet aktiv mit an der Entwicklung eines EA-Frameworks, das all diese Aspekte berücksichtigt.
Lesen Sie hier: Unterstützung aller relevanten Frameworks in HOPEX
