Enterprise Architecture - ein integrierter Ansatz

Einleitung

In diesem Beitrag soll es um das Thema Enterprise Architecture gehen, und zwar darum, mit welchen Ansätzen Enterprise Architecture erfolgreich in Unternehmen und Organisationen angewendet bzw. eingeführt werden kann. Konkret soll es darum gehen, von welchen gedanklichen Ausgangspositionen sich typischerweise die Architekturexperten in einer Organisation dem Thema Enterprise Architecture annähern. Außerdem möchte ich beleuchten, welche Vor- und Nachteile die verschiedenen Ansätze haben können und warum es so wichtig ist, sich im Kontext Enterprise Architecture nicht von Dogmatismen lenken zu lassen, sondern diese sofern vorhanden abzulegen. Daher empfehle ich, den Beitrag nicht ausschließlich aus rein architektur-methodischer Sicht zu betrachten. Vielmehr ist es sinnvol immer zu reflektieren, dass Enterprise Architecture für die meisten Organisationen und Unternehmen ein Mittel zum Zweck ist und entsprechend eine Adjustierung des Architekturansatzes an sich ändernde Rahmenbedingungen und Anforderungen des Unternehmens möglich sein muss.

Zielgruppe des Beitrages sind Enterprise Architekten die mit ihrem Schaffen den höchstmöglichen Mehrwert im Unternehmen generieren wollen. Zur Zielgruppe gehören aber auch Entscheidungsträger und Business-Verantwortliche welche die grundsätzliche Herangehensweise an das Thema Enterprise Architecture verstehen möchten und ihre Anforderungen und Rahmenbedingungen im Dialog mit den Architekten festlegen und dokumentieren möchten.

Herangehensweisen

Typischerweise lassen sich Experten zum Thema Enterprise Architecture anhand von drei Herangehensweisen an das Thema charakterisieren und je nach Ausprägungsgrad der Ansätze auch klassifizieren. Daher empfehle ich den Architekten unter Ihnen im ersten Schritt zu reflektieren, welcher der drei Ansätze am ehesten ihrer persönlichen methodische Herangehensweise entspricht. Den Business-Verantwortlichen unter Ihnen empfehle ich, sich bewusst zu machen, welcher der drei Ansätze am ehesten der aktuellen Herangehensweise in ihrem Unternehmen entspricht.

Ich möchte die drei verschiedenen Herangehensweisen als

1. den klassischen Ansatz,
2. den revolutionären Ansatz und
3. den evolutionären Ansatz

bezeichnen und im folgenden näher ausführen.

Der klassische Ansatz

Der klassische Ansatz ist vor allem dadurch geprägt, dass die jeweiligen Architekten im Unternehmen entweder auf Basis ihrer eigenen Expertise oder aufgrund von Unternehmensvorgaben ein konkretes Architekturrahmenwerk (zum Beispiel das TOGAF) identifiziert haben und dieses Rahmenwerk die Leitlinie des methodischen Handelns und zugleich unbedingte Vorgabe im Umgang mit Architekturen darstellt.

Gründe die für dieses Vorgehen sprechen sind dass Architekturrahmenwerke per se good practice bündeln und daher helfen, typische Fragestellungen sachgerecht zu behandeln. Außerdem geben sie Handlungs- und Interpretationssicherheit, wie Architekturen im Unternehmen erarbeitet, verstanden und verwendet werden sollen.

Nachteilig kann sich auswirken, dass die als good practice im Rahmenwerk enthaltenen Standardmethoden und -verfahren im Regelfall nicht hinreichend auf die konkreten Business-Anforderungen des Unternehmens abgestimmt sind, beziehungsweise abgestimmt sein können. Daher muss bei Verwendung des klassischen Ansatzes immer ein gewisser Spagat zwischen Nutzen und Nutzbarkeit des jeweiligen Frameworks vollbracht werden.

Anwendung findet der klassische Ansatz oftmals in Organisationen welche Enterprise Architecture für sich als ein wertvolles Konzept identifiziert haben und über das Framework Hilfestellung und Leitlinien bei der Umsetzung im Unternehmen finden.

Der revolutionäre Ansatz

Dem gegenüber steht ein Ansatz, den ich als den sogenannten revolutionären Ansatz bezeichnen möchte. Der revolutionäre Ansatz ist dadurch geprägt, dass auf Basis des im Unternehmen implizit oder explizit vorhandenen Architektur Know How die entsprechenden Architekturkonzepte von Grund auf neu entwickelt und speziell an die Anforderungen der beteiligten Akteure angepasst werden.

Gründe die für dieses Vorgehen sprechen sind natürlich die grundsätzliche Möglichkeit der passgenauen Adaption der jeweiligen Verfahren auf die Anforderungen des Unternehmens und die durch den hohen Grad an Selbstverwirklichung bei der Eigenentwicklung von Konzepten und Verfahren hohe intrinsische Motivation der eingesetzten Mitarbeiter*innen.

Nachteilig kann es sich auswirken, dass Eigenentwicklungen dazu führen können, dass Rad jedes mal und in jedem denkbaren Umfang neu zu erfinden. Zudem führt der revolutionäre Ansatz zu einer hohen Abhängigkeit von der Expertise einzelner Methodenexperten sowie einer immanenten Gefahr das konzeptionelle Grundsatzarbeit im Business mehr als akademischer Selbstzweck und weniger als sachgerechtes Mittel zum Zweck im Sinne der Unternehmensanforderungen verstanden wird.

Der evolutionäre Ansatz

Als dritten methodischen Ansatz an das Thema Enterprise Architecture möchte ich den evolutionären Ansatz beschreiben. Diese Herangehensweise basiert auf der Annahme, dass sich alle Sachverhalte über ein einfaches zueinander in Beziehung setzen von Objekten (zum Beispiel über eine generische N3 Notation) darstellen lassen und dass diese Art der Darstellung auch ein sinnvoll im Kontext Enterprise Architecture angewandt werden kann.

Die N3 Notation macht es sich hierbei vereinfacht ausgedrückt zunutze, das für die Darstellung der Beziehungen zwischen jeglicher Menge an Objekten (zum Beispiel von Systemen) grundsätzlich ein Satz von Tripeln der Struktur Objekt 1 – Beziehung – Objekt 2 genutzt werden kann. Die Semantik, welche die Bedeutung der Objekte und Beziehungen definiert, kann hierbei evolutionär und somit nach und nach erweitert beziehungsweise spezifiziert werden. Einer gewissen Beliebtheit erfreut sich dieses Vorgehen vor allem in Organisationen welche zum Beispiel aufgrund ihrer verhältnismäßig geringen Größe die Möglichkeit haben, dynamisch zu agieren und mit Pragmatismus an die Herausforderungen der strukturierten Planung und Dokumentation heranzugehen.

Gründe die für dieses Vorgehen sprechen sind dessen bestechende Einfachheit in der Grundform sowie seine immense Flexibilität bezüglich Erweiterbarkeit und Adaption an sich ändernde Rahmenbedingungen.

Nachteilig kann es sich auswirken, dass die Gefahr besteht, komplexe Zusammenhänge extrem vereinfacht darzustellen oder dass mit zunehmender Erweiterung und Adaption zum Beispiel durch die Spezifikation von Semantiken die Komplexität drastisch zunimmt. Diese Gefahr besteht insbesondere in der mehrfachen Abbildung gleicher semantischer Konzepte. Zudem können die hohen Freiheitsgrade in der Nutzung und Fortschreibung ungewollt dazu führen, unkoordiniert und fließend aus dem evolutionären in den revolutionären Ansatz zu wechseln.

Grundsätzliche Überlegungen zu den betrachteten Herangehensweisen

Unabhängig davon welchen der drei Ansätze Sie als den in ihrem Unternehmen praktizierten identifiziert haben, lässt sich auch beobachten, dass einer der Gründe die bei bestimmten Akteuren innerhalb eines Unternehmens zur Nichtakzeptanz von Enterprise Architecture führen ist, dass im Unternehmen keine Konsistenz bezüglich der Architektur-Methodik besteht. Dieser Effekt tritt häufig in großen Organisationen auf, in denen häufig folgende typische Entwicklung beobachtet werden kann.

1. Revolutionärer Ansatz: dedizierte Methodenexperten versuchen im Sinne des revolutionären Ansatz alle Modelle und Methoden selbst zu entwickeln
2. Klassischer Ansatz: Erkenntnis, dass zum Beispiel TOGAF als Rahmenwerk einen deutlich höheren Reifegrad hat als die Eigenentwicklungen
3. Evolutionärer Ansatz: Erkenntnis, dass alle Rahmenwerke viel zu kompliziert und wenig nutzbar sind und das eine einfache und flexible Herangehensweise als einzig vielversprechender erscheint

Diese Entwicklung kann wie in der folgenden Grafik dargestellt zu einem unproduktiven Kreislauf werden.

Wiederkehrende Phasen in der Anwendung der Architeckturansätze

Die Klippe die es an dieser stelle zu umschiffen gilt ist es, die gegebenenfalls vorhandene Anfälligkeit im eigenen Unternehmen zu genau diesem Effekt klar anzusprechen und entsprechend sicherzustellen, dass Ihre Organisation sich nicht in einen nicht endenden und hochgradig destruktiven Kreislauf hinein manövriert.

Der integrierte Ansatz

Keiner der dargestellten Ansätze kann per se als schlecht oder nicht sachgerecht bezeichnet werden. Vielmehr hat es sich in der Praxis bewährt, eine Kombination aus den drei Ansätzen anhand der Unternehmensanforderungen und -zielsetzungen bezüglich Enterprise Architecture zu entwickeln und zu dokumentieren und dieses integrierte Vorgehen als gemeinsamen Ansatz im Unternehmen zu kommunizieren.

Meine Empfehlung ist es dabei, sich im Sinne des klassischen Ansatzes über ein konkretes Architekturrahmenwerk diesem gemeinsamen Verständnis zu nähern. Dies können dann wie bei einem Werkzeugkasten auch nur einzelne sachgerechte Aspekte des Rahmenwerks sein, zum Beispiel die good practice bezüglich Methoden und Vorgehen zu Architekturentwicklung und -nutzung aus dem TOGAF (also die ADM). Der Vorteil dieses Vorgehens, also den klassischen Ansatz als Startpunkt zu wählen, ist es, dass Sie so möglichst früh von good practice aus dem ausgewählten initialen Architekturrahmenwerk profitieren und zudem auch alle gängigen Architekturrahmenwerke entweder implizit oder explizit den integrierten Ansatz also das Einbeziehen evolutionärer und revolutionärer Aspekte unterstützen.

Integrierter Ansatz an Enterprise Architecture

So wären im nächsten Schritt und im Sinne einer evolutionären Weiterentwicklung des methodischen Verständnisses der ADM aus TOGAF das Einbeziehen der Sichten aus weiteren Architekturrahmenwerk möglich, um von bewährten Templates zu profitieren, welche dabei helfen, die unterschiedlichen Blickwinkel und Akteure des Unternehmens zu dokumentieren.
Ein Rahmenwerk dass ich Ihnen an dieser Stelle und zu genau diesem Zweck empfehlen möchte, ist das nicht-proprietäre NATO Architecture Framework (NAF) welches trotz seiner militärischen Herkunft wirklich sehr durchdachte und auch von vielen Architekturwerkzeugen unterstützte Templates zur Modellierung der unterschiedlichsten Stakeholderinteressen auch in nicht-militärischen Anwendungsfällen anbietet.

Basierend auf der Methodik aus TOGAF und den Sichten des NAF könnten Sie dann entscheiden, dass Sie Ihre Architekturen mit einem der gängigen Architekturwerkzeuge modellieren möchten und daher auf das sehr ausgereifte Metamodel des NAF zurückgreifen wollen. Im Sinne des revolutionären Ansatzes hätten Sie über die offene Dokumentation dieses Metamodels die Möglichkeit dieses bei Bedarf an die Anforderungen ihres Unternehmens anzupassen. Mit diesem Vorgehen hätten Sie eine Herangehensweise definiert, mit der zumindest die Architekten in Ihrem Unternehmen arbeiten können und die vorgegebenen Unternehmensanforderungen basierend auf good practice nachhaltig umsetzen können.

Was im Sinne des integrierten Ansatzes jedoch noch fehlt, ist die Brücke von den Architekturen zu allen anderen Akteuren in der Organisation und im Unternehmen. Daher empfehle ich dringend zugunsten von Akzeptanz und Nachhaltigkeit im Dialog mit diesen Akteuren jenseits aller Modellierung ergänzend zur Faszination einer strukturierten Dokumentation mitteles Enterprise Architecture den Aspekt der sach- und zielgruppengerechten Visualisierung der erzielten Konzepte und Ergebnisse nicht zu vernachlässigen. Dieser Aspekt kann nach meiner Erfahrung nicht oft genug betont werden, da die Kernkompetenz aller Akteure in einem Unternehmen mit Ausnahme der Architekten, nicht das Lesen und Verstehen von mehr oder weniger kryptischen Architektur-Diagrammen ist, sondern die Umsetzung des jeweiligen Tagesgeschäfts bezogen auf das Geschäftsmodell des Unternehmens.

Wenn Architekturen unabhängig vom gewählten Ansatz, egal ob klassisch, revolutionär, evolutionär oder integriert, allgemeine Akzeptanz im Unternehmen finden sollen, dann muss die Umsetzung des Konzepts Enterprise Architecture zum einen Mehrwert für alle beteiligten Akteure generieren und zum anderen müssen diese Mehrwerte im Sinne einer ansprechenden nutzbaren und gegebenenfalls auch angepassten Visualisierung von allen Akteuren verwendet werden können. Dies kann für Techniker im Falle einer Systemarchitektur die Überführung der Ergebnisse in einen Schaltplan sein, dies kann für das C-Level Management aber auch die Überführung der Ergebnisse in eine belastbare Entscheidungsvorlage oder aber für die Beschaffungsabteilungen die Dokumentation als Liste von gemeinsam zu beschaffenden Systemkomponenten sein. Wichtig ist in jedem Fall, die Art der Darstellung und Visualisierung zu finden und zu wählen, mit welcher die angesprochenen Zielgruppen am besten und effektivsten weiterarbeiten können.

Zusammenfassung

In diesem Beitrag zum integrierten Ansatz an Enterprise Architecture habe ich Ihnen drei Herangehensweisen an das Thema Architekturen vorgestellt.

1. den klassischen Ansatz welcher dadurch gekennzeichnet ist, dass ein konkretes Architekturrahmenwerk als Leitlinie für Enterprise Architecture genutzt wird und in der extremen Ausprägung keine weiteren Ansätze genutzt werden beziehungsweise genutzt werden dürfen.
2. den revolutionären Ansatz welcher dadurch gekennzeichnet ist, dass Konzepte, Modelle und Methoden von Grund auf im Unternehmen selbst entwickelt werden und in der extremen Ausprägung die mehrfache Neuerfindung des Rades bewusst in Kauf genommen wird.
3. den evolutionären Ansatz welcher dadurch gekennzeichnet ist, dass in seiner extremen Ausprägung Sachverhalte in vereinfachter Form dargestellt werden und damit der Komplexität anspruchsvoller Aufgabenstellungen nicht in sachgerechten Umfang Rechnung getragen werden kann.

Basierend auf diesen drei Ansätzen habe ich mit Ihnen besprochen, dass eine sachgerechte Annäherung an die Umsetzung von Enterprise Architektur im Unternehmen über einen sogenannten integrierten Ansatz erfolgen sollte. Zum Beispiel kann im Sinne des klassischen Ansatzes mit good practice zu vorgehensmodellen und verfahren aus einem konkreten Rahmenwerk gestartet werden. Über eine Annäherung an den evolutionären Ansatz mit Templates zu Stakeholder-Interessen und Metamodellen für die Modellierung kann hinzu unternehmensspezifischen Anpassungen an Verfahren und Modelle im Sinne des revolutionären Ansatz fortgefahren werden.

Final habe ich Ihnen empfohlen, den Fokus darauf zu richten, dass Architekturen keinen Selbstzweck darstellen sondern die Ergebnisse im Sinne der Akzeptanz, Nutzbarkeit und erzielte Mehrwerte für das Unternehmen zielgruppenspezifisch visualisiert werden sollten, da die Mehrzahl der Akteure in einer Organisation mit diesen Ergebnissen etwa in Form von Schaltplänen, Listen oder Entscheidungsvorlagen Unterstützung für das jeweilige Tagesgeschäft erwartet und weder die Zeit noch die Aufgabe hat, sich in eine architekturspezifische Fachnotation aus Diagrammen etc. einzuarbeiten.

Dies beendet den Beitrag zum integrierten Ansatz und ich würde mich freuen, wenn die vorgestellten Konzepte und Erfahrungen Ihnen helfen, Enterprise Architecture sachgerecht in Ihrem Unternehmen umzusetzen.