Dean Leffingwell, Autor und Unternehmer sowie einer der weltweit führenden Autoritäten für Lean-Agile Methodiken, hat federführend SAFe entwickelt. Mit der Einführung 2011 bezweckte er Unternehmen bei der Entwicklung besserer Systeme und Software, in Abstimmung mit den sich ändernden Kundenanforderungen, zu unterstützen. SAFe beschreibt die Enterprise Architecture (EA) als ein Schlüsselelement.
In neuen agilen Organisationen spielen Enterprise Architects eine entscheidende Rolle bei der Bereitstellung strategischer Leitlinien, Referenzarchitekturen und Technologiestandards für die Entwicklungsteams, damit diese auf standardisierte Weise arbeiten können. Es ist daher wichtig,
die SAFe Bausteine besser zu verstehen. Hinzu kommt, dass immer mehr Organisationen diesen Framework (einschließlich der Begriffe wie z.B. Architectural Runway, Intentional Architecture, Emergent Design) verwenden.
Im Folgenden möchte ich darauf eingehen, wie sich die Rolle des Enterprise Architects verändern muss, um besser mit den Entwicklungsteams zusammenarbeiten zu können und wie sich die gesamte EA-Praxis in diesen neuen agilen Organisationen entwickeln bzw. positionieren könnte.
1. SAFe und der Architectural Runway
Eine der Schlüsselkomponenten des SAFe-Rahmens ist der Architectural Runway.
Im SAFe-Rahmenwerk sind die Entwicklungen in Programmschritte unterteilt, die 8 bis 12 Wochen dauern können. Zur Verlängerung des Runways weden Enabler eingesetzt, um die Aktivitäten zu unterstützen, die für die Bereitstellung der zukünftigen Geschäftsfunktionalitäten erforderlich sind. Zu den Enablern gehören Infrastruktur-, Compliance- und Architekturentwicklungen. Die Enabler werden für die nächste Programmerweiterung gebaut, diese stellen sicher, dass die in der nächsten Programmerweiterung entwickelten Geschäftsfunktionen sicher auf der beschriebenen Bahn landen. Daher der Begriff "Landebahn". Da sich die Geschäftsanforderungen weiterentwickeln und Technologien schnell veralten, entwickelt sich diese mit der Zeit weiter.
Architectural runway SAFe
2. Intentional Architecture vs Emergent Design
Einerseits schreiten die Entwicklungen schnell voran und agile Teams werden befähigt, die Architektur so zu entwerfen, wie sie diese benötigen: The best architectures, requirements, and designs emerge from self-organizing teams. (11. Principle Agile Manifest)
Bei „Emergent Design“ existiert keine abgrenzbare Designphase, es findet keine bewusste Gestaltung statt. Es handelt sich um Architektur und technischen Lösungen, die „on the fly“ gemacht werden, orientiert sich an Prinzipien, Kompromissen, Mustern und wird oft refaktorisiert.
Andererseits entwerfen Enterprise Architects die „Intentional Architecture“. Diese Form der Architektur ist planbasiert, mit dem Ziel bereichsübergreifend Teams aufeinander abzustimmen. Irgendwann sollte diese Intentional Architecture mit dem Emergent Design in Einklang gebracht werden, um den Veränderungen, die während der Entwicklungen eingetreten sind, folgen zu können.
Emergent Design und Intentional Architecture im Einklang
Organisationen stoßen jedoch in den meisten „Agile at Scale“-Umgebungen hierbei auf die folgenden Probleme:
Deshalb ist die Balance zwischen Emergent Design und Intentional Architecture entscheidend: Emergentes Design ist für kleine, taktische Projekte. Intentionale Architektur soll das größere Bild bringen.
3. Die sich entwickelnde Rolle der Enterprise Architects:
Ermitteln Sie den besten Weg für die Zusammenarbeit mit Entwicklungsteams
In agilen Umgebungen müssen Enterprise Architects ein echter Sparringspartner für unterschiedliche Disziplinen im Unternehmen sein und die strategische Vision in die Programme einbringen, während sie ebenfalls regulatorische Einschränkungen und Richtlinien in die Programme einbeziehen sollten.
Sie bauen die Intentional Architecture, die agile Entwicklungen unterstützt, und arbeiten eng in Entwicklerteams daran Silos auzufbrechen. Insgesamt erleichtern sie die Einführung agiler Praktiken und legen fest, wann ein Emergent Design oder eine Intentional Architecture bevorzugt werden sollte.
Wenn Enterprise Architects den Entwicklungsteams architektonische Leitplanken zur Verfügung stellen, müssen sie die beste Art und Weise der Interaktion mit ihnen definieren. Je nach Grad der Interaktion kann dies zu einer zu fragmentierten Architektur oder zu einer von der Realität abgekoppelten Architektur führen, wie in der folgenden Tabelle beschrieben.
4. Entwicklung der EA-Praxis in agilen Umgebungen:
mehr Gestaltungsspielraum für lokale Teams
Im Artikel "The five trademarks of agile organizations" von McKinsey wird der Wandel von einer traditionellen Top-Down-Organisation zu einer agilen Organisation, mit dem Risiko einer Kluft zwischen den Zielen des Management-Teams und des agilen Teams, beschrieben.
In der Tat identifizieren Manager in traditionellen Organisationen was zu tun ist, und geben ihren Mitarbeitern Anweisungen nach dem klassischen Top-Down-Ansatz. In agilen Organisationen besteht das Ziel darin, den Kunden zu begeistern. Die Arbeit erfolgt in selbstorganisierenden Teams, mit iterativen Arbeitszyklen und direktem Kundenfeedback. Die vorherrschenden Werte sind Transparenz und kontinuierliche Verbesserung.
In diesem neuen Kontext wird auch die Enterprise Architecture von einem Top-Down-Ansatz zu einem dezentralisierten Managementansatz übergehen und den lokalen Teams mehr Macht verleihen. In diesem neuen Modell arbeiten lokale Teams an einer Lösungsarchitektur, die auf lokaler Ebene verwaltet wird. Auf Unternehmensebene bietet das Enterprise-Governance-Team strategische Führung für die gesamte Organisation. Sie arbeiten an der Geschäftsarchitektur, erfassen Geschäftsziele und regulatorische Einschränkungen, bewerten Business-Chancen (insbesondere durch neue Technologien) und planen zukünftige Business Capabilities. Sie definieren Technologiestandards und -muster, die zu mehr Sicherheit und Skalierungseffekten führen.
Dezentralisierte Enterprise Architecture in agilen Organisationen
Die Enterprise Architecture ist eine Schlüsselkomponente des SAFe-Rahmens, denn sie bietet den Entwicklerteams strategische Leitlinien, einschließlich Referenzarchitekturmodellen, Technologiestandards und regulatorischen Einschränkungen.
In diesen neuen agilen Organisationen müssen Enterprise Architects auch die beste Art und Weise finden, mit den Entwicklungsteams zusammenzuarbeiten und ein angemessenes Gleichgewicht zwischen dem Emergent Design und der Intentional Architecture zu finden.
Wenn sich SAFe zu einem etablierten Rahmen innerhalb der eigenen Organisation entwickelt, kann ein Teil der Leitung außerhalb des EA-Teams angesiedelt werden, damit lokale Teams ihre eigene Architektur auf der Grundlage der definierten strategischen Ziele entwerfen können.
Sie sind an weiteren Informationen interessiert? Hier geht's zu unserem White Paper:
3 Steps to scale Agile Development using Enterprise Architecture
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.