Agile und TOGAF ADM

Kern des TOGAF ist die Architecture Development Method, ADM. Sieht aus wie ein Wasserfallansatz, ist es aber nicht notwendigerweise. Die einzelnen Phasen und Gruppen von Phasen können durchaus in einer agilen Art und Weise und in Sprints durchlaufen werden.

Eines der primären Ziele der Phase A ist ein Konsens über die „Vision“. Man könnte sagen, dass eine Phase A ein „Epos“ definiert. Alternativ könnte eine andere Phase A eine „User Story“ definieren. So kann Phase A das „Program Increment“ für einen „Agile Release Train“ definieren. Jedes dieser Dinge kann auf verschiedenen Ebenen auf Phase A: Architecture Vision abgebildet werden. Übertragen auf SAFe Agile, könnte Phase A auch die Definition von „Strategischen Themen auf Unternehmensebene“ oder „Wertströmen auf Programmportfoliomanagementebene“ abbilden und diese vereinfachen. Hilfestellung liefert hier TOGAFs „Capability-Based-Planning ”.

Aus Sicht der Unternehmensarchitektur und der IT ist Capability-Based-Planning eine leistungsstarke Methode, um sicherzustellen, dass der strategische Geschäftsplan das Unternehmen von oben nach unten führt. Es kann auch mittels Capability Engineering angepasst werden, um aufkommende Bottom-up-Innovationen zu nutzen. Unabhängig davon, wie das Unternehmen selbst strukturiert ist, muss es die Bereitstellung von Geschäftsfähigkeiten bewältigen, deren Implementierung eine Koordination und Ausrichtung über alle Geschäftsbereiche hinweg erfordert. Die Funktionen sind idealerweise geschäftsorientiert. Eine der Hauptherausforderungen besteht darin, dass die Vorteile häufig auf Unternehmensebene und nicht auf Bereichs- oder Abteilungsebene erzielt werden. Folglich tendieren Projekte in bereichs- oder abteilungsorientierten Portfolios eher zur eigenen als zur Unternehmensperspektive. Das Management der Bereitstellung einer Fähigkeit ist eine ist eine Herausforderung, aber die Verankerung einer fähigkeitsbasierten Perspektive in einem Unternehmen ist ein leistungsstarker Mechanismus, um einen synergistisch abgeleiteten Geschäftswert zu erzielen, der sich in Rentabilität und Aktienwert niederschlägt.

Bei jeder agilen Iteration auf jeder Ebene – und bei jeder ADM-Iteration auf jeder Ebene – müssen die Interessengruppen und deren Anforderungen einbezogen werden. Einige Stakeholder können in einer „User Story“ als „Epic Owners“ oder als „Persona“ betrachtet werden.

In TOGAF ist das Stakeholder-Management von entscheidender Bedeutung. Wer beim Stakeholder-Management versagt, riskiert, dass die gesetzten Ziele nicht erreicht werden. 80% der Transformationsprojekte scheitern genau daran – und bei Agile dreht sich auch alles um das Stakeholder-Management. In einem agilen Kontext werden „Epic-Eigentümer“ während des gesamten agilen Designprozesses direkt eingebunden. Agile sagt das und TOGAF sagt genau dasselbe.

Anforderungen und Design entstehen, wenn wir in agilen Sprints und ADM-Zyklen iterieren. Immer direkt und kontinuierlich mit unseren Stakeholdern verbunden – Schulter an Schulter, im selben Raum, in denselben Scrum-Teams.

Es muss entschieden werden, inwieweit die Phasen B, C und D relevant sind und was in Bezug auf diese Architekturdomänen oder „Anliegen“ (Concerns) getan werden muss. Idealerweise ist das Ergebnis der Phase D bereits definiert und es ist anzunehmen, dass die technische Architektur eher langlebig, bereits vorgegeben und wiederverwendbar ist. So konzentrieren sich die Teams in Ihren Sprints nur auf Phase B und C – die Business Architektur, Anwendungs- und Daten-Architektur. Das muss natürlich nicht so sein. Sie könnten genauso gut agiles Design und Iteration für die Bereitstellung einer Infrastrukturtechnologie oder -plattform durchführen, aber ich glaube nicht, dass Agile wirklich für diesen Zweck entwickelt wurde.

Wahrscheinlich ist, dass Phase D: Technologie-Architektur eine Art „Architektur-Epos“ darstellt, das wir separat realisieren werden. Ich denke, dass Phase D nicht sehr häufig in einem Sprint oder Programmschritt entworfen oder realisiert wird. Eher bin ich davon überzeugt, dass ein agiler Sprint sich auf Geschäftsarchitektur, Anwendungsarchitektur und Informations- / Datenarchitektur konzentrieren wird. Phasen B und C.

Es ist festzulegen, was vorhanden und gegeben ist (Baseline) und wo sie hinwollen (Target). Tatsächlich wird nur selten auf der grünen Wiese entwickelt. Daher ist es möglicherweise gut zu wissen, wovon wir ausgehen. Möglicherweise gibt es dort Einschränkungen oder Anforderungen, die bekannt sein müssen, möglicherweise gibt es bereits verabschiedete Prinzipien, die einzuhalten sind, Die Phasen B und C lassen sich durchaus auf „Agile/Scrum“-Praktiken abbilden. Man könnte sagen, dass die Phasen B und C – parallel durchgeführt – einen „Sprint“ definieren können und, dass die Phasen B und C – parallel durchgeführt – einen iterativen „Agile Release Train“ (ART) definieren können, also ein „Programminkrement“.

Es kann entschieden werden, dass Phase B: Business Architecture nur in agilen Iterationen ausgeführt wird. Dies kann insbesondere auf der Ebene der Fall sein, auf der strategische Unternehmensthemen definiert werden oder auf der darüber nachgedacht wird, die großen Wertschöpfungsströme auf der Ebene des „Programmportfoliomanagements“ zu ändern. Auf dieser Ebene interessiert vielleicht eher das strategische „Was“ als das taktische „Wie“.

Ich denke, wer einen Aspekt der Geschäftsarchitektur ändert, wird fast immer einen Aspekt der Anwendungs- und Informations- / Datenarchitektur ändern. Und genau hier wird Agilität gefordert. Die meisten flexiblen Release-Trains, die ich sehe, kombinieren – und konzentrieren sich fast ausschließlich auf – Geschäftsarchitektur, Anwendungsarchitektur (Präsentation, Geschäftsregeln, Workflow) und Informationen und Daten. So iterieren sie also ständig über Phasen B, C und selten D.

Nachdem einige inkrementelle Iterationen der Phasen B, C und möglicherweise D durchgeführt wurden, ist es nötig, in Phase E über eine Reihe alternativer Optionen nachzudenken, wie die Änderungen, die in einem agilen Release-Train vorgenommen wurden, umgesetzt werden können. Dies kann die Prüfung einer Reihe verschiedener Optionen für das Zusammenstellen und Wiederverwenden von Architekturbausteinen aus dem TOGAF-Architecture-Repository beinhalten. Welche Teile verwirklichen das „miniumum viable product“ am besten, welche Teile sollten weggelassen oder herausgenommen und wieder in das Kanban-BackLog eingefügt werden? Manchmal ist Phase E möglicherweise nicht erforderlich und lässt sich mit Phase F kombinieren. In einer Agile + DevOps-Umgebung werden Phase E und Phase F also dasselbe.

Was in Phase F geplant wird, kann sofort und vollständig von einem DevOps-Team entwickelt, als eigene Iterationen parallel zum ADM-Zyklus implementiert, getestet und bereitgestellt werden. Wichtig ist, dass ständig Informationen bereitgestellt werden, die in den ADM-Phasen F und G benötigt werden, um allfällige Anpassungen in der Architektur und/oder dem Architektur-Rahmenwerk zu gewährleisten. So kann man sich die Phasen F und G als „DevOps-Iteration“ des ADM vorstellen. Und DevOps ist agil. Wer wirklich agil sein möchte, sollte versuchen, DevOps zu erreichen.

In Phase H: Architektur Change Management kann der Kanban-Rückstand verwaltet werden. Ich betrachte Phase H als den Ort, an dem die „Architekturschulden“ verbucht werden. Architecture Debt wird in TOGAF nicht einmal erwähnt. Aber es ist ein allgemeiner Begriff, der von Architekten auf der ganzen Welt verwendet wird. Manchmal nennen sie es „technische Schulden“ oder „Unternehmensschulden“. Sobald Inkremente in der Produktionsumgebung implementiert sind, überprüft das Team in Phase H sofort den Kanban-Backlog und beginnt mit der Planung und Ausführung des nächsten agilen Release-Trains, des nächsten Programminkrements, des nächsten Epos und des nächsten Sprints, der nächsten Phase A.

Agile und TOGAF: Kein Widerspruch

In diesem Sinne gibt es keinen Konflikt zwischen architektonischen Rahmenbedingungen und Agilität, da beide versuchen, unterschiedliche Probleme auf verschiedenen Ebenen zu lösen. Die Unternehmensarchitektur befasst sich auf Ebene der Strategischen Architektur und Segment Architektur mit der eher langlebigen Definition der Business Prinzipien und Standards, Anwendungsbausteinen, Infrastruktur und der Standards, innerhalb derer agile Teams arbeiten. Bei agilen Methoden geht es eher um die effizienteste Organisation eines Softwareentwicklungsteams und ist daher am besten geeignet auf Ebene der Capability Architecture für schnelle Iterationen.

Durchsetzung und Governance

Trotz dieser Trennung gibt es einen Punkt, an dem die zwei Ansätze kollidieren können, und das hauptsächlich dann, wenn es um Durchsetzung der Strategischen und Segment-Architektur und Governance geht.

Obwohl wir möchten, dass agile Teams autonom sind und sich selbst verwalten, sind sie immer noch Teil einer umfassenderen Organisation. Agile Teams in großen Organisationen können niemals vollständig autonom sein, da sie innerhalb der Grenzen von Daten, Konventionen, Technologien, Regelwerke und Strategien agieren, die für die gesamten Organisation festgelegt werden. TOGAF versucht, einen Strukturprozess zu definieren, um diese Grenze transparent und inklusiv zu gestalten.

Mithilfe von Compliance-Überprüfungen wird sichergestellt, dass bewährte Verfahren angewendet, Standards eingehalten und eine gemeinsame Infrastruktur verwendet wird. Dies kann ein sehr detaillierter Prozess sein – eine vollständige Konformitätsprüfung umfasst eine Checkliste mit mehr als hundert Elementen, einschließlich Hardware, Informationsmanagement, Sicherheit und technischer Vorgehensweise.

TOGAF sieht vor, dass die Standard-Checkliste so anpasst wird, dass sie sich auf Bereiche mit hohem Risiko konzentriert mit der Absicht, ein externes Architektengremium auf einen sehr detaillierten Stand des Back-log der agilen Entwicklungsteams zu bringen. Architectural Governance ist notwendig und in Ordnung, wenn es um den weiteren Kontext geht, den Teams nicht erkennen können. Es ist weniger angemessen, wenn es sich um Aspekte der Entwicklung handelt, bei denen die Teams selbst die anerkannten Experten sein sollten.

Braucht Agile Architektur, um erfolgreich zu sein? „Ja!“ würde ich sagen, und die Frage erweitern: „Welche Art von Architektur braucht Agile, um erfolgreich zu sein?“ Agile erfordert eine stabile Architektur, die die Art und Weise unterstützt, wie die Agile Praxis die Ergebnisse und Mehrwert liefert. Die Art der Architektur, die dies tun wird, muss eine Kombination aus einem agilen, reaktiven Architekturstil sein, der durch einen traditionelleren, strukturierten Ansatz der Architektur unterstützt wird. Die Herausforderung ist, wie bei vielen Dingen, den richtigen Mix zu finden.