Blog: Enterprise Architecture und Agile Development: Gegensätze ziehen sich an?

Marc Lankhorst (BiZZdesign), Danny Weinberger (CSC)

Warum Agilität wichtig ist

Agilität ist zu einer wichtigen Fähigkeit der Unternehmen geworden. Das Tempo, bei dem die Kunden sich verändern, bei dem neue Gesetze und Verordnungen ihre Dienstleistungen und Prozesse beeinflussen und die Schnelligkeit, mit der Wettbewerber, wie Google und Apple, sie herausfordern, führt allzu oft zu einem enormen Druck auf das Unternehmen. Dabei kann sich der Druck in unterschiedlicher Art und Weise bemerkbar machen, wie zum Beispiel Druck sich schnell zu verändert, oder neue Technologien einzuführen, Wachstum zu generieren oder Kosten zu reduzieren. In Folge dessen ist die Agilität schlichtweg notwendig, um überhaupt mit ständigen Innovationen schnell auf dem Markt agieren zu können. Beides, Innovation und Flexibilität, sind für eine nachhaltige Positionierung am Markt notwendig.

Agile Development ist zur Norm für die Softwareentwicklung geworden. Aber wahre Agilität des Geschäfts und des Unternehmens benötigt mehr als die Schaffung von Scrum-Teams. Mehr noch, fokussiert man sich nur auf die Agilität in kleinem Rahmen, die durch Agile Software Development erreicht wird. Allerdings sieht man dann den Wald vor lauter Bäumen nicht mehr. Die Frage, die sich hier stellt ist,  warum will man als Unternehmen agil sein und was ist dafür notwendig?

Agilität in großem Maß organisieren

Ein Unternehmen ist mehr als nur eine Ansammlung lokaler Entwicklungen kleiner Teams. Die Puzzlestücke, an denen diese Teams arbeiten, müssen irgendwie zusammenpassen. Und hoffentlich ist da eine Vision für die Zukunft, eine Geschäfts- und IT-Strategie, eine Reihe von Zielen, die die Organisation anstrebt. Das ist, wo Enterprise Architecture auf den Plan gerufen wird.

Klassische Enterprise Architecture hat eher einen Top-Down-Charakter, bei dem man umfassende Pläne entwickelt, bevor man diese implementiert. Die Agile-Bewegung, mit dem Fokus auf Anpassung an Veränderung und Widerstand gegen ‘Big Design Up-Front’ (BDUF), ist eigentlich das Gegenteil.

Beide Ansätze haben ihre also Vor- und Nachteile. Klassische Enterprise Architecture Management kann zu einer langsamen und bürokratischen Organisation führen, die es nicht versteht mit der Zeit zu gehen. Eine losgelöste Reihe von unterschiedlichen Scrum-Teams ohne integrativen, überliegenden Ansatz zu haben, kann zu einer unschlüssigen Architekturlandschaft voller agile-Silos führen. Dennoch können wir die Unternehmen in die Lage versetzen,  sich als ganze Einheit zu bewegen, wenn wir auf die Stärken beider Ansätze bauen, ohne ein zentral bestimmendes Management zu haben, das Innovationen und Entwicklungen gleich im Keim erstickt.

Beispiel: das Scaled Agile Framework

Moderne Entwicklungen, wie das Scaled Agile Framework (SAFe) und Disciplined Agile Delivery (DAD), bewegen sich in diese richtige Richtung. Nehmen wir beispielsweise SAFe, dargestellt in vereinfachter Form in der untenstehenden Abbildung.

Figure 1. Scaled Agile Framework (simplified)

SAFe nutzt einen iterativen Ansatz über mehrere Ebenen, bei dem wir die typischen agile-Teams in der untersten Ebene finden können. Sie liefern Ergebnisse in einer agile-typischen Frequenz von 2 bis 3 Wochen. In der mittleren Ebene werden die Ergebnisse dieser Teams integriert und mittels von Solution Architecture Konzepten wie Architecture Runway und Agile Release Train veröffentlicht, was sicherstellt, dass diese zusammenpassen. Diese Ebene wiederholt sich mit einer Geschwindigkeit, die sich aus einer Mehrzahl der Team-Ebene ergibt und so potentiell lieferbare Produkte alle 2 bis 3 Monate erarbeitet. Auf der obersten Ebene sind die großen, langzeitlichen Entwicklungen angesiedelt. Genau dort findet  Enterprise Architecture Management statt. Die Unternehmensstrategie mündet ebenfalls in dieser Ebene und stellt den Rahmen für alle groß angelegte Architekturentscheidungen mit hohem Einfluss, Festlegung von Prioritäten und schließlich die Zuweisung der notwendigen Mittel.

Auf dieser obersten Ebene befinden sich die etablierten Enterprise Architecture Methoden, wie TOGAF. TOGAF hat ebenfalls eine sich wiederholende Struktur, die sich im bekannten „Architekturentwicklungs“ Diagramm des Architecture Development Method (ADM) wiederspiegelt. Dieses in einem agilen Kontext anzuwenden, erfordert jedoch einige Anpassungen. Insbesondere muss die Enterprise Architecture dafür offener nach außen und konsequent Geschäftsorientiert, Endkunden- und Ergebnisfokussiert werden. Ein Geschäftsergebnis kann ein Endkundenprodukt sein, welches durch Services, Fähigkeiten (Capabilities), Ergebnisse und Artefakte, aber auch Unternehmenstransformation die neue Strategien implementiert, beschrieben wird.

Betrachten wir TOGAF weiter, dann benötigt TOGAF‘s Implementation Governance (Phase G im ADM), die an Implementationsprojekte und – Programme koppelt ist, eine Überarbeitung. Besonders, dass agile Methoden sich stark auf Rückkopplungen  verlassen, während TOGAF‘s Governance von Natur aus mehr auf die Zukunft ausgerichtet ist. TOGAF‘s Architecture Change Management (Phase H) ist eine typische Anlaufstelle für diese Art von  Feedbacks. Wir werden dies in einem zukünftigen Blog näher ansprechen.

Figure 2. Agile EA with TOGAF 9.1

Ferner sind SAFe, DAD, TOGAF und verwandte Methoden weiterhin sehr IT-zentriert. Entsprechend dem SAFe, ist die Rolle des Enterprise Architect „[...] ganzheitliche Technologieimplementation an[zu]treiben [...]“. Aber wahre Enterprise Architects sind nicht alleine auf die Technologie fokussiert. Vielmehr ist die Geschäftsarchitektur ein immer wichtiger werdender Teil der Arbeit, wie zum Beispiel: Abbildung der Strategie, Fähigkeiten-basierte Planung, Mehrwert Ermittlung, Geschäftsprozessmanagement, Lean Six Sigma und andere geschäftsbezogene Disziplinen fehlen noch im Gesamtbild. Ein wirklich agiles Unternehmen braucht mehr als eine agile IT alleine. Wir wollen diese Problematik der Unternehmensagilität in zukünftigen Blogs weiter vertiefen.

Verfolgen Sie uns weiter für agilere Enterprise Architecture, und lassen Sie uns in der Zwischenzeit Ihre Gedanken zu dieser Thematik wissen.