Enterprise Architektur Management im (post-) agilen Zeitalter

Enterprise Architektur Management zu Zeiten vor der agilen Bewegung

Enterprise Architekturmanagement (EAM) gehört schon seit vielen Jahren zum Standardrepertoire der IT-Bereiche mittlerer und großer Unternehmen.
Es entstand mit dem Vordringen von IT-Unterstützung in nahezu alle Unternehmensbereiche. Mit der Verfügbarkeit kostengünstiger und vernetzbarer Arbeitsplatzrechner war das bisherige Modell des Großrechners als zentrale Plattform für alle Unternehmensanwendungen an technische, fachliche und organisatorische Skalierungsgrenzen gelangt. Anstelle neue Großrechneranwendungen für neue Aufgabenbereiche zu erstellen, wurden nun spezialisierte Client-Server- Lösungen genutzt, die meist auch in Form von Standardsoftware auf Grundlage offener Systeme am Markt verfügbar waren. Die IT-Landschaft der Unternehmen war nun mit einer Vielzahl von sehr heterogenen Systemen und Komponenten konfrontiert, die es in der Entwicklung und im Betrieb zu beherrschen galt. Die gewonnene Flexibilität und kürzere Time-to-Market gegenüber dem Großrechnermodell hat auf der anderen Seite zu einer höheren Komplexität und in der Konsequenz zu höheren Aufwänden für Personal, Wartungs- und Betriebskosten geführt. Eine weitere Herausforderung bestand in der Vernetzung und Abstimmung der Arbeitsteilung zwischen den spezialisierten Anwendungen, um zusätzliche, die Produktivität hemmende, manuelle Aufwände auf Seiten der Anwender zu vermeiden.
Das traditionelle Enterprise Architekturmanagement entstand deshalb in erster Linie aus der Notwendigkeit heraus, diesen Herausforderungen zu begegnen und als deren Korrektiv die entstandene Komplexität zu managen. Hierbei lassen sich fünf wesentliche Aufgabenbereiche traditionellen EAMs identifizieren:

1. Begrenzung der betrieblichen Komplexität durch Standardisierung und Konsolidierung der im Unternehmen genutzten Betriebs- und Anwendungsplattformen und Prozesse. Maßgeblichen Einfluss für das Streben nach möglichst hoher Standardisierung hatte und hat die Betriebskomponente. Für den Eigenbetrieb der Infrastruktur- und Anwendungsplattformen sind oft hoch spezialisierte Skills notwendig, was in der Konsequenz einen sehr großen Einfluss auf die vorzuhaltende Personalstärke und damit unmittelbar auf die Betriebskosten hat.
2. Systematische Erfassung der vorhandenen Anwendungen und deren Relationen untereinander (Schnittstellen) und zu den durch sie genutzten Betriebsplattformen in toolgestützt in zentralen Repositorien
3. Zentrales Management der Änderung an der Anwendungslandschaft durch zeitliche Entkopplung in Zielbildern und Bebauungsplänen
4. Zentrale Umsetzungsplanung innerhalb eines gemeinschaftlichen IT-Projektportfolios
5. Allokation und Verteilung der dazu notwendigen Ressourcen aus einem zentralen IT-Budget

Die EAM-Funktionen waren und sind meist als klassische Stabsfunktion innerhalb der ITOrganisation direkt an den CIO angebunden. Auch wenn erteilte Mandate und Entscheidungskompetenzen in verschiedenen Unternehmen recht unterschiedlich ausgeprägt sind, folgt der traditionelle EAM-Ansatz, speziell in eher betriebsseitig dominierten IT-Organisationen in Gänze doch eher planwirtschaftlichen Prinzipien. Kennzeichnend dafür sind

• die Langfristigkeit der Planungen (3-5 Jahresbereich) mit hohem Planungsdetails
• Starke Zentralisierung der Design- und Entscheidungskompetenz durch Gremien und Komitees
• Streben nach möglichst hoher Standardisierung, deren Durchsetzung Top-Down nach dem Prinzip „Command und Control“, gerne auch in der netter verpackten Form „Comply or Explain“ erfolgt

Der Ansatz mag in Einzelfällen dazu beigetragen haben, die Komplexität aktueller IT-Landschaften zu begrenzen. Wie bei allen planwirtschaftlichen Ansätzen ging und geht das aber zu Lasten der Flexibilität und Innovation:

• planwirtschaftliche Zeitraster sind zu unflexibel, um auf geänderte geschäftliche Rahmenbedingungen zu reagieren. Da Änderungsbedarfe i.d.R. nicht entlang der Grenzen von Anwendungen oder Systemen verlaufen, muss ein globaler Abstimmungs und Genehmigungsprozess durchlaufen werden, der die Umsetzung der Anforderungen bremst oder sogar verhindert.
• Die Erfahrung zeigt, dass zentrale Design-Authorities sich sehr schnell von der Realität konkreter Projekte- und Anwendungen entfernen. Da eine Feedbackschleife zu Implementierungsteams oft nicht (mehr) vorhanden oder nur schwach ausgeprägt ist, führt dies dann über Zeit zum berühmten „Elfenbeinturm der Enterprise Architektur“.
• Das Streben nach starker Standardisierung schränkt den Lösungsraumvon Teams ein und verhindert Innovation, da oft nur zum bereits vorhandenen Portfolio „konforme“ Lösungen akzeptiert werden.

Architektur in der Agilen Softwareentwicklung

Erinnern wir uns, dass die Einführung von EAM eine Reaktion war, um die mit einer Ausweitung und Dezentralisierung einhergehende Steigerung der Komplexität der IT-Landschaft der Unternehmen zu managen. In der Entwicklung der letzten Jahre hat es drei wesentliche Game-Changer gegeben, die dazu führten, dass ausgehend von der Startup-Szene ein diametraler Gegenentwurf zum traditionellen EAM in Form einer „No-Architecture-Bewegung“ entstand:

1. Die Demokratisierung der IT-Infrastruktur in Form von standardisierten und am Markt on-demand verfügbarer und maschinell steuerbarer IT-Infrastrukturen – die Cloud. Die Fähigkeiten und das Portfolio der eigenen Betriebsplattformen sind damit nicht mehr der limitierende Faktor und deren Standardisierung erfolgt durch Marktmechanismen.
2. Standardisierung durch Open-Source mit einem communitygetriebenen Ansatz. De-Facto Standards entstehen in einem evolutionären Prozess und nicht am Reißbrett im Elfenbeinturm.
3. Durchsetzung des agilen Vorgehensmodells mit DevOps als vorherrschendes Entwicklungsmodell, bei dem die Entscheidungen zu Architektur, IT-Design und genutzter Technologie eigenständige von den jeweiligen agilen Teams auf Basis der gerade vorliegenden Anforderungen getroffen werden („Emergent Architecture“).

Die agile Softwareentwicklung als Idee fußt auf dem agilen Manifest2 und den daraus abgeleiteten 12 agilen Prinzipien:

Die agile Herangehensweise fokussiert dabei auf eine möglichst schnelle Umsetzung der gerade aktuellen Business Anforderungen mit einem hohen Nutzenpotential (Value-Streams) in kurzen Iterationszyklen. Flexibilität und Reaktionsgeschwindigkeit in Bezug auf sich ändernde Anforderungen (bspw. aus neuen Geschäftsanforderungen oder Nutzer-Feedback) und neu Rahmenbedingungen (bspw. aus dem Entstehen neuer Technologien) stehen dabei im Vordergrund.
Die Entwicklung und der Betrieb von Softwarelösungen finden dabei in kleinen, weitgehend voneinander unabhängigen, selbstorganisierten DevOps-Teams mit großen Entscheidungsbefugnissen statt. Durch eine möglichst lose Kopplung der, von den jeweiligen Teams entwickelten, Softwarekomponenten sollen Abstimmungs-Bottlenecks in der Entwicklung verringert werden und so eine bessere Skalierbarkeit erzielt werden. Aufgrund der schlechten Erfahrungen im klassischen Enterprise Architektur Management mit ausufernden Architektur-, Design- und sonstigen Up-Front Überlegungen vor Beginn der konkreten Umsetzung und den daraus resultierenden langsamen Entscheidungsprozessen und
Bottlenecks, wird darauf weitgehend verzichtet. Stattdessen wird das Modell des „Emergent Designs“ verfolgt. Dabei wird der Fokus auf die konkrete Umsetzung der jeweils aktuellen Anforderungen gelegt und eine darauf ausgerichtete Architektur entwickelt. Diese Architektur ist optimal zugeschnitten auf das konkret zu lösende Problem und an die Kenntnisse, Fähigkeiten und Vorlieben des entwickelten Teams angepasst. Der Leitgedanken dabei ist, dass auf diese Weise folgerichtig die am leichtesten mögliche Architektur zur Umsetzung der konkreten Business-Problemstellung entsteht. Darüberhinausgehende Überlegungen (seien es noch unbekannte, vielleicht später benötigte Erweiterungen, oder auch Abstimmungen mit anderen Projekten) werden wenig beachtet. Wenn aufgrund weiterer Anforderungen Änderungen an der Architektur notwendig werden, wird die gesamte vorhandene Architektur einem Refactoring unterzogen.

Diese Herangehensweise mit ihrem Fokus auf Veränderungsgeschwindigkeit und der Entscheidungshoheit über Architektur und Technologieeinsatz hat Vorteile in Bezug auf die Umsetzungsgeschwindigkeit von einzelnen Anforderungen als auch in der Partizipation an der technologischen Entwicklung. Agile DevOps Teams können in diesem Modell frühzeitig, ohne großen Abstimmungs- und Genehmigungsaufwand mit neuen Technologien experimentieren und in ihre Softwarelösungen einbauen. Damit können die Teams die anstehenden Themen sehr effektiv und effizient zu lösen. Durch den DevOps Gedanken ist auch der Betrieb der jeweiligen Lösung sichergestellt, da die Entwickler – die die Tools und die eingesetzten Softwarekomponenten kennen – ja auch den Betrieb der Softwarelösung übernehmen.

Emergent Design allein ist jedoch in größeren Kontexten nicht ausreichend, da die einzelnen Teams das Gesamtbild dann nicht mehr vollständig überblicken können. Daher werden in größeren Kontexten wichtige, zielgerichtete architektonische Richtlinien verabschiedet, um die Entwicklung halbwegs in Bahnen zu lenken (Intentional Architecture). Diese sind jedoch eher fundamental und lassen den einzelnen Teams nach wie vor große Freiheiten um als Team
gemessen auf sich ändernde Anforderungen reagieren können, ohne übermäßige Versuche, das System zukunftssicher zu machen.

Die Herausforderungen der Architektur in der agilen Softwareentwicklung 

Für eine überschaubare Gruppe von Softwareentwicklern / DevOps- Engineers funktioniert das agile Modell sehr gut, da es Ihnen ermöglicht die anstehenden Themen sehr effektiv und effizient zu lösen. Leider stößt dieses Vorgehen jedoch mit einer zunehmenden Anzahl von beteiligten Teams und im Zeitverlauf an seine Grenzen und skaliert daher nicht auf Enterprise Level.

Die limitierenden Faktoren sind:

1. Abhängigkeiten der Teams voneinander und Schnittstellen:
   Bei einer geringen Anzahl an agilen Teams (Domänen) sind die Abhängigkeiten zwischen den Teams noch gering und in einer überschaubaren Zeit auflösbar. Mit wachsendem Funktionsumfang werden jedoch die Schnittstellen zwischen den einzelnen Teams (Domänen) immer umfangreicher bzw. komplexer. Insbesondere wenn die Abhängigkeiten sich über mehr als zwei Teams erstrecken, so dass ein jeweils bilaterales Management der Schnittstellen nicht mehr möglich ist, steigen Aufwand und Zeit für die nötigen Abstimmungen zur Charakteristik der Abhängigkeit, der verwendeten Schnittstellentechnologie sowie der zeitlichen Priorisierung und Synchronisation. Mit dem Fokus auf das Umsetzen der jeweils aktuellen vorliegenden Anforderungen besteht die Gefahr, dass Abhängigkeiten nicht vollständig bzw. rechtzeitig erkannt werden und es zu unbekannten Kettenabhängigkeiten kommt, bei der Änderungen an einer Stelle (durch Team A) zu Inkompatibilitäten bzw. Änderungen an einer anderen, unerwarteten, Stelle (bei Team B) führen. Diese unbekannten Abhängigkeiten werden im agilen Entwicklungskontext in der Regel durch flächendeckende Tests noch rechtzeitig erkannt (hoffentlich). Allerdings führt das Auflösen der durch die Abhängigkeit entstehenden Konflikte oft zu ungeplanten Aufwendungen mit negativen Auswirkungen auf die Zeitplanung, die Priorisierung und das Budget der jeweiligen Teams.
2. Unkontrollierte Technologievielfalt: Wird die Entscheidung der zu nutzende Technologien, Frameworks und Tools den einzelnen Teams überlassen, so entwickelt sich über Zeit der berühmt berüchtigte Zoo an genutzten Technologien. Insbesondere werden für die gleiche Funktionalität von verschiedenen Teams auch unterschiedlichen Techniken eingesetzt. Dieser Ansatz optimiert in der Regel auf die Funktionen, Effizienz und auch die
   Bequemlichkeit in der Entwicklung, lässt aber die langfristigen betrieblichen Aspekte außer Acht. Insbesondere müssen zu den einzelnen Technologien jeweils ausreichend Skills im Unternehmen verfügbar sein, um auch einen langfristigen effizienten Betrieb und die fortlaufende Wartung und Weiterentwicklung sicherzustellen.Denkt man den DevOps Ansatz zu Ende ist alles ganz einfach. Jedes Team entwickelt und betreibt den Teil seiner Software selbst. Bei nicht kritischen Applikationen geht das auch eine Weile gut. Bei unternehmenskritischen 24x7 Anwendungen wird es aber mit der Zeit immer schwieriger eine ausreichende Abdeckung für jeden der benötigten Skills vorzuhalten (Bereitschaftsdienste, Vertretungen, Priorisierung zwischen Betriebs-, Support und Entwicklungsthemen). Auch ist es nicht immer möglich mit der veränderten Wichtigkeit einer Domäne in ihrem Lebenszyklus (sind ja nicht alle immer gleich wichtig) Entwicklungsressourcen
   freizuschaufeln und andere Themen bearbeiten zu lassen. Die Mitarbeiter werden ja weiterhin für den Betrieb gebraucht. Auch müssen alle eingesetzten Technologien mit den jeweiligen Spezial-Skills bedient werden, so dass Mitarbeiter schlechter zwischen den verschiedenen Domänen ausgetauscht werden können, bzw. sich übergreifend vertreten können. Dies führt langfristig zu Ineffizienz. Darüber hinaus steigt der Aufwand im Betrieb (Monitoring, Logging, IT-Security) und zur kontinuierlichen Aktualisierung aller eingesetzten Tools, Technologien und Frameworks bei den regelmäßig erforderlichen Updates mit jeder eingesetzten Technologie.
3. Unterschätzte Komplexität von SaaS – Integration Heute stehen für viele Aufgaben bereits bestehende Lösungen als Software as a Service zur Verfügung, die von den agil arbeitenden Teams auch gerne genutzt werden. Die Nutzung von SaaS Lösungen erscheint zunächst schnell, einfach und attraktiv zur Lösung des jeweiligen Business Problems beizutragen. Leider werden hierbei die betrieblichen Aspekte (bspw. die Einbindung in das Identitäts- und Rechte- Management und das Monitoring, Aspekte der IT-Security) sowie regulatorische Aspekte gerne vernachlässigt.
4. Aufwand für das Refactoring: Emergent Design und zu großen Teilen auch intentional Design erfordern ein regelmäßiges Refactoring der gerade bestehenden Architektur, um neuen Anforderungen gerecht zu werden. Das funktioniert so lange gut, wie die Kosten und die benötigte Zeit für das jeweilige Refactoring gering sind. Mit wachsender Größe des Softwaresystems im Zeitverlauf und mit zunehmender Anzahl der Teams steigen die für das benötigte Refactoring benötigte Zeit und damit die Kosten stetig an. Darüber hinaus gibt es im Softwaredesign Features, die einfach umzusetzen sind, wenn sie von Beginn an berücksichtigt werden (Mandantenfähigkeit, Mulit-Sprachfähigkeit sind hier unsere Lieblingsbeispiele), später allerdings nur mit hohem Aufwand umzusetzen sind.
5. Organisatorische und Governance-Aspekte: In großen Unternehmen, insbesondere in stark regulierten Unternehmen, kommt dann noch der Aufwand für das Managen der verschiedenen Technologien in Bezug auf Lizenz-, Vertrags- und Providermanagement sowie weitere aufsichtsrechtliche Aspekte (bei Banken bspw. das Auslagerungsmanagement) hinzu.

Damit stehen wir also wieder an dem Punkt, als Enterprise Architektur Management eingeführt wurde, um die Vielfalt an Technologien, Schnittstellen und verteilten Anforderungen zu managen, weil es keine Stelle mehr gab, die einen Überblick über die von den einzelnen Teams bereitgestellten Funktionen, bzw. eingesetzten Technologien hatte und die daraus entstehende Komplexität unbeherrschbar wurde. Ähnliches erleben gerade StartUps oder andere wachsende Unternehmen, denen die akkumulierte Komplexität als Folger der agilen Softwareentwicklung um die Ohren fliegt. Andererseits sind viele etablierte, meistens größere Unternehmen damit konfrontiert, die Methoden der agilen Softwareentwicklung aufzugreifen und mit ihren gewachsenen, hierarchischen Entscheidungsstrukturen zusammenzubringen, um ihre Agilität zu steigern und in Bezug auf Veränderungsfähig konkurrenzfähig zu werden bzw. zu bleiben.

Lösungsansatz: Lean Architektur Managements in einer förderativen Organisation

Beide dargestellten Extreme, zentrale Enterprise Architektur einerseits und dezentrale evolutionäre Architektur andererseits funktionieren langfristig in größeren bzw. wachsenden Unternehmen nicht. Während das Modell einer zentralen Enterprise Architektur (mit vielen übergreifenden Vorgaben und viel Upfront-Design) den Fokus auf Stabilität und Kosteneffizienz mit Fokus auf den Betrieb sowie auf Wiederverwendung legt, ist das agile Modell auf Flexibilität, Effizienz in der Entwicklung und auf das Schaffen von Veränderungen optimiert. Langfristig sind im Unternehmen auch beide Aspekte wichtig. Es muss daher ein Weg gefunden werden, der einerseits dem jeweiligen Entwicklerteam genügend Freiraum gibt, um das spezifische Problem effektiv zu lösen und andererseits ein Set an übergreifenden Regeln für die Gesamtarchitektur. Ein erfolgreicher Lösungsansatz besteht in der Kombination aus einer föderativen Organisation des Enterprise Architekturmanagements und Prinzipen des Lean Architecture Managements.

Föderatives Modell:
Das Föderative Modell im Architekturmanagement basiert darauf, die gesamte Architektur in einzelne möglichst selbständige Domänen zu unterteilen, in dem die jeweiligen Domänen- Architekten weitgehend eigenverantwortlich für die Architektur in ihren Domänen sind.
Innerhalb der Domänen kann die Entscheidung für bestimmte Teile der Architektur weiter zu Sub- Domänen oder einzelnen Teams delegiert werden (in der Verantwortung des/der Domänen- Architekten)
Darüber hinaus gibt es ein zentrales Architekturmanagement, welches den Prozess zur Strukturierung der Gesamtarchitektur in einzelne Domänen verantwortet und ein übergreifendes für alle Domänen verbindliches, möglichst schlankes Regelwerk definiert.
Dieses übergreifende Regelwerk enthält Vorgaben zum Architekturmanagement (Transparenzvorgaben, Qualitätsstandards, KPIs), sowie Vorgaben zur Technologienutzung im Rahmen eines aktiven Technologiemanagements.
Entscheidungen werden in dem föderativen Modell den Ideen des Lean Architecture Managements folgend an der tiefst möglichen Stelle in der Entscheidungshierarchie, möglichst nah an der konkreten Umsetzung getroffen. Weiterhin sollten Entscheidung zum spätest möglichen Zeitpunkt – ohne die Ziele des Vorhabens zu gefährden - getroffen werden, weil dann i.d.R. mehr Informationen zur Entscheidungsfindung vorliegen. Dabei sind die übergreifend gültigen Regeln selbstverständlich zu beachten.

Prinzipien des Lean Architektur Management
Die Idee im Lean Architektur Management ist es, nur genauso viel Architektur wie nötig zu definieren um die Problemstellung schnell, agil und effizient entwickeln und über die angedachten Lebenspanne effizient betreiben zu können. Ziel ist es, für die einzelnen Teams einen möglichst großen Freiraum bezüglich der jeweiligen Architektur zu geben und die Vorgaben seitens eines zentralen Architekturmanagements auf übergreifende Aspekte zu beschränken.

Grundprinzipien:
Die Architekturentscheidungen werden in einem übergreifenden, durch die Enterprise Architektur vorgegebene Rahmen getroffen. Dieser Rahmen wird so gestaltet, dass er primär den Architekturmanagement-Prozess regelt (z.B. die einzelnen Domänen müssen gewisse Qualitätsstandards erfüllen, technische Schulden erfassen, etc.) und weniger Vorgaben zur konkreten Architektur macht. Hier werden nur wenige grundlegende Aspekte (z.B. zur IT-Sicherheit, Interoperabilität, etc.) grundsätzlich festlegt, für einen Großteil jedoch wird ein Optionsraum beschrieben, in dem sich die einzelnen Architekten bewegen können. Architekturentscheidungen sollten auf der tiefsten Entscheidungsebene getroffen werden, also auf Team- oder Domänen-Ebene. Dabei wird der generell durch das Architekturmanagement vorgegebene Rahmen (bspw. aus dem Technologiemanagement) berücksichtigt. Architekturentscheidungen sollten zu einem möglichst späten Zeitpunkt getroffen werden, ohne dass die Entwicklung in Bezug auf Zeit, Geld oder Qualität darunter leidet, wenn diese Entscheidung nicht getroffen wird. Zu diesem Zeitpunkt liegen die bestmöglichen Informationen (Umfang der Information und Qualität der Information) vor, um die jeweiligen Architekturentscheidung zu treffen. Die Entscheidungsfindung wird bis zu diesem Zeitpunkt durch die jeweilig verantwortlichen Architekten vorbereitet. Das ist nicht zu verwechseln mit einem verschleppen der Entscheidung; der Entscheidungsprozess selbst muss schnell sein. In dem durch den zentral vorgegebenen, schlanken und flexiblen Architekturrahmen, werden Architekturentscheidungen primär am (Business-)Nutzen ausgerichtet. Dabei fließen die längerfristigen Aspekte der Entscheidung (Lifecycle-Kosten, technische Schulden, Interoperabilität) selbstverständlich ein.

Der zentrale Rahmen wird dabei flexibel ausgestaltet und kontinuierlich (z.B. im Technologiemanagement) weiterentwickelt. Die notwendige methodische Unterstützung wird durch ein schlankes Architekturmanagement Framework gebildet, welches sich auf die wesentlichen Artefakte (bspw. Domänenmodell, Technologieradar, Business und IT Capabilitiy Maps, Applikationen und wichtige technische
Komponenten) fokussiert und mit angepassten Tools unterstützt wird.

Donmänenmodell

Grundlage für das föderative Architekturmanagement ist ein umfassendes Domänenmodell der gesamten IT-Landschaft. Die Gesamt-Architektur wird dabei möglichst entlang der Business-Strukturen in einzelne möglichst eigenständige Business Domänen unterteilt. Dabei ist darauf zu achten, dass die IT-Strukturen den Business-Strukturen der Domänen entsprechen (gemäß Conways Law). Die Domänen sind dabei eigenständig (autonom), jedoch nicht autark und daher von anderen Domänen abhängig. Für ein umfassendes Gesamtbild und als Grundlage für das übergreifende Architekturmanagement und die Zusammenarbeit zwischen den Domänen müssen diese Abhängigkeiten zwischen den Domänen möglichst vollständig erfasst und die Beziehungen zwischen den Domänen explizit beschrieben werden. Die Entwicklung des Domänenmodells orientiert sich dabei an den Ideen aus dem strategischen Domain Driven Design.

Kontinuierliche Anpassung
Um den stetigen Wandel der Business-Anforderungen und den kontinuierlichen technischen Fortschritt angemessen in der Architektur zu berücksichtigen, müssen das gesamte Domänenmodell, die Beziehungen der Domänen untereinander sowie die Vorgaben der zentralen Architektur kontinuierlich – in dem Sinne, dass die Anpassungen inkrementell bei Bedarf ohne Zeitverzug erfolgen – weiterentwickelt werden. Auch die Architektur in den Domänen wird in diesem Sinne kontinuierlich weiterentwickelt.

Aufgaben des zentralen Enterprise Architektur Management (Enterprise Architekten)
Die zentrale Enterprise Architektur Funktion muss im wesentlichen xx Aufgaben erfüllen, die hier kurz angerissen werden. Für weitergehende Informationen verweisen wir auf unseren Blogpost „Die Rolle der zentralen Enterprise Architektur“ im föderativen EAM.

1. Management des Domänenmodells
   Das zentrale Enterprise Architektur Management ist für den Prozess zu Erstellung und kontinuierlichen Überarbeitung des Domänenmodells verantwortlich. Die zentralen Enterprise Architekten arbeiten dazu eng mit den jeweiligen Domänen-Architekten und den weiteren Stakeholdern aus dem Business und der IT zusammen. Zum regelmäßigen Update des Domänenmodells gehört auch die Identifikation von Optimierungspotentialen in den Domänen – bspw., wenn ähnliche Funktionen in verschiedenen Domänen implementiert sind – und Vorschlagen von Anpassungen des Domänenmodells (z.B. Einführen einer neuen Domain für eine Plattform). Die Enterprise Architekten sind für die Visualisierung des Domänenmodells und die Kommunikation in die Organisation verantwortlich.
   
2. Managen der Abhängigkeiten zwischen den Domänen
   Etablieren eines Prozesses zur Identifikation und zum Management der Beziehungen und Abhängigkeiten zwischen den Domänen. Auch hier arbeiten die zentralen Enterprise Architekten eng mit den Domänenarchitekten zusammen. Ziel ist es die Abhängigkeiten zwischen den Domänen vollständig zu erfassen und die Spielregeln an diesen Abhängigkeiten festzulegen. Auch das Erfassen und Managen der Abhängigkeiten orientiert sich an den Ideen des strategischen Domain Driven Designs. Schlagworte sind: Wer ist Upstream und Downstream in einer Beziehung und welchem Integrationsmuster folgt die Beziehung.
3. Technologiemanagement
   Das Technologiemanagement soll es ermöglichen, dass jede Domain einerseits die zur Erfüllung der jeweiligen Aufgaben geeignete Technologie nutzen und am technischen Fortschritt partizipieren kann, andererseits jedoch die Zahl der genutzten Technologien insgesamt begrenzt werden. Dazu eignet sich die die Nutzung eines verbindlichen Technologie-Radars in allen Domänen.
4. Herstellen von Transparenz:
   Möglichst vollständige Transparenz über die Architektur in den einzelnen Domänen und die Gesamtarchitektur bildet die Basis für die Weiterentwicklung der Architektur. Das zentrale Architekturmanagement setzt daher Mindeststandards, wie die Architektur in den einzelnen Domänen zu dokumentieren ist (bspw. in Bezug Applikationen, Schnittstellen, eingesetzte Technologien sowie aktuelle Roadmaps und Umsetzungspläne) und verantwortet die entsprechende Tool-Unterstützung.
5. Definition von architekturellen Qualitätsstandards und KPIs
   Die Enterprise Architektur definiert Qualitätsstandards, die bei der Weiterentwicklung der Domänenarchitektur verbindlich sind. Bspw. eine Pflicht zur Erfassung und zum Management von technischen Schulden, sowie verbindliche KPIs mit denen die Architektur in den einzelnen Domänen messbar und managebar wird.
   Wichtig ist hierbei auch wieder, Vorgaben zu machen, was in den einzelnen Domänen gemacht werden muss, den Domänen Architekten jedoch hier jedoch Freiräume in Bezug auf die Umsetzung zu lassen.
6. Grundlegende architekturell und technologische Vorgaben
   In einer großen IT-Landschaft, die sich über viele Domänen erstreckt, ist die Festlegung von übergreifend einzuhaltenden Standards notwendig. Wichtig sind hierbei insbesondere übergreifend verbindliche Standards zu IT-Security, Standards zu Schnittstellen, um die Interoperabilität zwischen den Domänen übergreifend und langfristig sicherzustellen, und Standards für einen reibungslosen, den Governance-Vorschriften entsprechenden Betrieb. Darüber hinaus kann es zentrale Vorgaben in Bezug auf vertragliche Aspekte geben (z.B. die Nutzung von bestimmten Cloud Anbietern). Den Grundprinzipien des Lean Architecture Management folgend sollte dieses übergreifende Regelwerk so schlank wie möglich gestaltet werden.
7. Kommunikation, Moderation, Eskalation
   Die Architekten der zentralen Enterprise Architektur Funktion kommunizieren mit den verschiedenen Stakeholdern im Unternehmen, um einerseits ihre Architektur und Roadmaps im Unternehmen bekannt zu machen und andererseits kontinuierlich die Anforderungen aus den einzelnen Unternehmensbereichen aufzunehmen und zu berücksichtigen.
   Auch moderieren sie die gesamten übergreifenden Architekturmanagementprozesse und stellen schlanke effektive Eskalationswege bereit. Moderation und Eskalation sind dabei von dem Gedanken geleitet, dass die Architekturentscheidungen auf dem niedrigsten möglichen Level zu treffen sind.

Aufgaben der Domain-Architekten

Obwohl der Abschnitt zu den Domänen-Architekten in diesem Blog-Post kürzer ausfällt als für die zentralen Enterprise Architekten spielen sie für die Weiterentwicklung der Architektur die entscheidende Rolle.
Die Domain Architekten sind für die Architektur in ihrer jeweiligen Domäne verantwortlich. Je nach Größe der Domain können ein oder mehrere (Domänen-Architekt, Solution-Architekt etc.) Architekten in einer Domäne tätig sein. Sie richten ihre Entscheidungen innerhalb der Grenzen ihre Domänen dabei an den Bedürfnissen ihrer Domäne aus und sind in die Entscheidungsstrukturen der Domäne eingebunden (bspw. in Bezug auf Priorisierung von Anforderungen, Budget). Daher werden die Domänenarchitekten die Architektur ihrer Domänen auf Basis der vorliegenden Anforderungen lokal optimieren. Dabei sind jedoch die übergreifend definierten Rahmenbedingungen zu beachten. Die Domänen Architekten verantworten die Architektur ihrer Domäne vollständig über alle Architekturebenen – von der Business-Architektur (Business Capabilities) über die Informationssystemarchitektur (Applikations- und Datenarchitektur) bis hin zur technischen Architektur und Technologieauswahl – und über den gesamten Lebenszyklus. Dabei können sie das Modell für die Bereitstellung der Business-Capabilities der Domäne eigenständig gestalten (Applikationen, Prozesse, Datenmodell, Prozessmodell, Technologie, Vor- u. Nachbedingungen). Abhängigkeiten von Modellen verschiedener Domänen müssen explizit bei den Abhängigkeiten beschrieben und geregelt werden Von zentraler Bedeutung für eine gute Architektur ist dabei ein umfassendes Verständnis der Geschäftsfunktionen, die in der jeweiligen Domäne abgebildet werden. Dafür ist eine gute und enge Zusammenarbeit mit den Business-Stakeholdern, Produkt-Ownern und Business-Analysten
unabdingbar.

Fazit

Klassisches Enterprise Architektur Management mit seinen langfristigen (3-5 Jahren) Betrachtungszeiträumen und seiner tiefen Regelungstiefe und Fokus auf hohen Standardisierungsgrad kann mit den notwendigen Veränderungen in einer sich stetig und schnell wandelnden Welt nicht mithalten.
Die aus der agilen Softwareentwicklung stammenden Ideen des „Emergent-Design“ und der „Intentional Architecture“ skalieren andererseits nicht großen Unternehmen und vernachlässigen
längerfristige Stabilitäts- und Betriebsaspekte.
Daher schlagen wir einen föderativen Ansatz für das Enterprise Architekturmanagement vor, der beide Dimensionen (langfristige Stabilität und Betreibbarkeit einerseits und Flexibilität andererseits) in angemessener Weise miteinander verbindet. Der gesamten Architekturarbeit sollen dabei die wichtigsten Elemente des Lean Architecture Management zu Grunde liegen, damit nicht schon wieder ein Architektur-Elfenbeinturm entsteht.
Der wichtigste Grundsatz für das föderative Modell lautet daher, dass Architekturentscheidungen,
je nach dem Radius ihrer Auswirkungen auf der tiefst möglichen Ebene und zum spätest möglichen Zeitpunkt (aber ohne Verzögerungen) getroffen werden. Die übergreifenden Regeln sind dabei so zu gestalten, dass den einzelnen Teams genügend Freiräume gegeben sind, um für sich optimale Lösungen zur Umsetzung der Geschäftsanforderungen
und zu Erzielung von Nutzen zu implementieren. Durch regelmäßiges Feedback und kontinuierliche Verbesserung (bspw. beim Auftauchen neuer Technologien) kann flexibel auf die veränderten Markt- und IT Rahmenbedingungen reagiert werden. Durch die Vorgegeben Standardisierung wird die Balance zu den Stabilitäts- und Betriebsaspekten gewahrt. Das Ganze wird durch effiziente Architekturmanagementprozesse und schlanke, schnelle Entscheidungsstrukturen unterstützt, die regelmäßig evaluiert und verbessert werden.