4. August 2020

Best Practices für ein agileres IT-Architekturmanagement

Wie gelingt IT-Architekturmanagement im Zeitalter der Agilität? Hält man sich an vier zentrale Punkte, steigen die Erfolgschancen.
it-architektur

IT-Architekturmanagement ist eine Disziplin, die darauf ausgerichtet ist, einen Überblick über die IT-Landschaft und deren Einbettung im Geschäftskontext des Unternehmens durch Modellierung der Verzahnung mit Prozessen, Produkten und Technologien zu gewinnen. Entstanden als Antwort auf die wachsende Komplexität der IT-Landschaften und gleichzeitig steigende Anforderungen des Fachbereichs in Bezug auf die Flexibilität und Geschwindigkeit, fand das Architekturmanagement schnell Einzug in viele IT-Organisationen.

Eine besondere Herausforderung stellt aktuell der Einsatz des Architekturmanagements im agilen Umfeld dar. Nachfolgende Best Practices können dabei helfen ein agileres Architekturmanagement aufzubauen und versprechen das Comeback einer bewährten Disziplin mit ein paar entscheidenden Twists.

  1. Dezentrale Entscheidungen

Dezentrale Entscheidungen sind ein charakteristisches Merkmal für viele agile Methoden und Vorgehensweisen. Daher sollte dieser Faktor beim Aufbau der hauseigenen Architektur-Kompetenz unbedingt berücksichtigt werden. In vielen klassischen Organisationen ist das Architekturmanagement als eine Funktion innerhalb des IT-Departments aufgehängt und wird zentral besetzt. Modernere Organisationen setzen eher auf Architekturmanagement als organisationsweite Fähigkeit und verteilen diese Kompetenz auf mehrere Köpfe. Dies geschieht in der Regel in Form von Architektur-Gilden, Communities of Practice oder virtuellen Architektur-Teams. Traditionelle Aufgaben des IT-Architekturmanagements wie z.B. Pflege der Application Repository, Bereitstellung von Architektur-Visualisierungen und Reports, Vorbereitung von Entscheidungsgrundlagen und Szenarien, werden dabei auf mehrere Köpfe verteilt und unter Einsatz entsprechender Collaboration Tools erledigt.

So hat beispielsweise ein grosser europäischer Finanzdienstleister im Rahmen der Einführung des Spotify-Modells die Enterprise Architecture (EA) Gilde kreiert. Eine Gilde ist ein virtuelles Interessensteam und setzt sich aus Mitarbeitenden diverser Teams (Squads) innerhalb einer Tribe zusammen. Jede Gilde hat einen Gildenmeister, der die Aktivitäten der Gilde koordiniert. Dadurch dass die Mitglieder der Gilde in diversen Squads sind, vertreten sie dort die Architektur-Kompetenz und helfen ihrem Team in der lokalen Entscheidungsfindung rund um Architekturfragen.

  1. Keine Architekturarbeit mehr auf Vorrat

Die Just-in-Time-Produktion von Arbeitsergebnissen ist eng mit einer Wertorientierung und Beschränkung auf das Wesentliche verbunden. Weniger Bilder und Kennzahlen sagen oft mehr als komplizierte Reports. Die Beschränkung auf den Informationsbedarf der Organisation und des Managements hilft oftmals unnötige Arbeit zu vermeiden.

Architekturergebnisse sollen Antworten auf konkrete Problemstellungen in Programmen, Projekten oder Proof-of-Concepts liefern und dienen als Entscheidungsvorlagen. Folgende Ergebnistypen haben sich in diesem Zusammenhang als besonders nützlich erwiesen:

  • MVP Scope Diagramm: Wie genau sieht das Minimal Viable Product (MVP) einer neuen Lösung aus? Was ist in-scope/out-of-scope? Welche Wirkung hat es auf IT-Landschaft, Kunden, Partner und das Ökosystem? Welche Integrationsarbeit ist notwendig, um das MVP schnellstmöglich mit der IT-Landschaft zu verbinden?
  • Business Capability Map: Welche Fähigkeiten in Bezug auf das Management von Architekturen und welche Lösungen sind notwendig, damit das Unternehmen die gesetzten Ziele bei der digitalen Transformation erreichen kann?
  • Agile Roadmap: Auch wenn das Projekt keinen herkömmlichen Projektplan hat und agil durchgeführt wird, welche Schwerpunkte werden voraussichtlich in der nächsten Iteration/Sprint bearbeitet? Was ist notwendig, damit dort Architekturentscheide fundiert gefällt werden können?
  1. Design for Change

Die Wirtschaft durchlebt gerade erneut einen Paradigmenwechsel: der Fokus verschiebt sich von der Effizienz mehr in Richtung Resilienz und Veränderungsfähigkeit. Leider ist dieser Paradigmenwechsel bisher nur teilweise im Architekturmanagement angekommen. Die Disziplin muss sich dieser Veränderung anpassen und ihren Ansatz verändern:

  • Architekturmanagement ist keine Städteplanung, sondern vielmehr Kompass in einem Ozean: Weg von einem Verständnis des Architekturmanagements als starre Städteplanung, wo alle ein paar Jahre ein neues Gebäude dazu kommt, zu einem Kompass in einem stürmischen Ozean der Realität mit schneller Veränderung, wo man aktiv navigieren muss.
  • Modellierung der Ökosysteme statt nur ein tiefer Blick nach innen: Die Vernetzung mit externen Partnern über die Organisationsgrenzen hinweg soll modelliert und aktiv gemanagt werden, statt den Blick nur nach innen zu richten.
  • Explizite Modellierung von Informations- und Datenflüssen aus der Geschäftsperspektive: Bisher modellierte meist nur die hausinterne IT die Informations- und Datenflüsse innerhalb des Unternehmens. Es gab sporadische Ansätze auf der Seite des Fachbereichs (Business Engineering, Prozess-Manager, IKS). Aber nur wenige davon haben sich wirklich durchgesetzt und waren wirkungsvoll. Es ist jedoch zwingend notwendig, dass Informations- und Datenflüsse vom Fachbereich verstanden und aktiv gemanagt werden.
  • Einfaches Vokabular soll dazu beitragen, die cross-funktionale Zusammenarbeit zu erleichtern und einen schnellen Einstieg in die Disziplin zu gewährleisten.
  1. Iterative Einführungspfade

Iterative Vorgehensweisen sorgen dafür, dass die Disziplin schrittweise in einer Organisation etabliert wird. Entscheidend ist dabei die Aufteilung des Arbeitsvorrats (Backlogs) in einzelne beherrschbare Arbeitspakete und Abwicklung dieser Arbeitspakete in einzelnen Iterationen. Jede einzelne Iteration befasst sich idealerweise mit einem Thema (Applikationen, Schnittstellen, Prozesse, Technologien, Governance usw.).

Ein iterations-übergreifender Backlog fasst alle wesentlichen Anforderungen an das Einführungsprojekt zusammen und wird durch den Product Owner aktiv gemanagt. Iteration Planning sind Team Meetings und sorgen dafür einen Iteration Backlog zu kreieren (eine Auswahl an Tasks aus dem Projekt-Backlog, welche innerhalb der nächsten Iteration abgearbeitet werden sollen). Wöchentliche Jour-fixe-Termine im Team sorgen für einen regelmässigen Austausch und kurze Feedbackzyklen. Review und Retrospektive gehören ans Ende jeder Iteration. In einem Review-Meeting werden alle wesentlichen Arbeitsergebnisse der Iteration angeschaut und kritisch überprüft. Eine Retrospektive gibt dem Team eine Möglichkeit, den Ablauf der letzten Iteration zu reflektieren und Verbesserungen für die neue Iteration einzuleiten.

Das Einführungsteam umfasst dabei einen Product Owner (Architekturverantwortlicher intern), Sponsor (Mitglieder des Managementteams und Sponsor des Projekts), Architektur-Coach (externer Coach für Methoden, Werkzeuge und Prozess), Verantwortlicher Business Applications, Verantwortlicher Infrastruktur, Vertreter des Fachbereichs und des Change Boards.

 

Bild: ThisisEngineering RAEng on Unsplash

Disclaimer: Zühlke ist ein swissICT Firmen-Mitglied. Firmen-Mitgliedern steht unser Blog offen für Themen-Inputs und Fachartikel. Die Beiträge müssen journalistischen Anforderungen genügen und dürfen nicht werblich sein. Sie möchten auch einen Beitrag publizieren? Für Fragen dazu benutzen Sie gerne dieses Kontaktformular.

Mit Ihrem Besuch auf unserer Website stimmen Sie unserer Datenschutzerklärung und der Verwendung von Cookies zu. Dies erlaubt uns unsere Services weiter für Sie zu verbessern. Datenschutzerklärung

OK