Wie meistert man den Spagat zwischen Nachhaltigkeit und Agilität in der IT-Architektur?

Wir haben mit Dietmar Hafner, langjähriger Experte und Dozent des Kurses «Architekturarbeit in agilen Vorhaben» darüber gesprochen, ob es überhaupt möglich und sinnvoll ist, in agilen Projekten seriöse Software-Architekturarbeit zu leisten. Oder ob der Widerspruch, dass dadurch die agilen Prinzipien verletzt werden, zu gross ist.

Dietmar Hafner ist seit über 10 Jahren in der IT tätig. Er besitzt ein breit gefächertes Beraterprofil, angefangen bei Software-Entwicklung und Architektur bis hin zur Technologieberatung, Produkt Management und agilen Software Entwicklungsmethodik. Zu seinen Branchenkenntnissen zählen die Telekom-Industrie, die Finanzbranche sowie Kundenbindungssysteme. Neben seiner technischen Ausbildung in IT-Management schloss er ein rechtswissenschaftliches Studium in der Domäne Computer- und IT-Recht ab.

Herr Hagner, heutzutage gilt agile Softwareentwicklung als Erfolgsfaktor bei besonders innovativen und zeitkritischen Projekten durch ihre Fähigkeit, auf Änderungen zu reagieren. Wie schafft man den Spagat zwischen Nachhaltigkeit und Agilität?

Durch die Nutzung der agilen Prinzipien wird die Architektur zu jedem Zeitpunkt nur so weit festgelegt, dass so viele Entscheidungen getroffen werden, wie unbedingt nötig sind. Die Entscheidungen, die noch offengelassen werden können, lässt man so lange wie möglich offen. Die Entscheidung fällt erst zu einem späteren Zeitpunkt, basierend auf gewonnenen Erkenntnissen.

In der klassischen Softwarearchitektur werden vor den Phasen Design und Entwicklung Fehler und Lücken in den Anforderungen identifiziert und eliminiert, die Software-Architektur festgelegt und optimiert. Architektur- und Dokumentationsprofis erarbeiten detaillierte Modelle und Prozesse, um das Risiko von bösen Überraschungen zu eliminieren. Erst danach wird mit dem Coden angefangen. Das ist doch ein solides Vorgehen oder nicht?

Dieser Ansatz ist perfekt geeignet für komplizierte Systeme. Das sind Systeme, welche zwar sehr viele Variablen, Bedingungen und Funktionen haben, aber über eine perfekte Spezifikation verfügen. Die Anforderungen sind und bleiben mehr oder weniger stabil, von Anfang bis zum Ende. Nicht mehr so gut funktioniert es bei komplexen Systemen, bei denen die Anforderungen über die Zeit nicht stabil bleiben, sondern mehr oder weniger stark variieren. Die vorgängig festgelegte Architektur passt sehr schnell nicht mehr optimal. In diesem Fall wäre es besser, agil vorzugehen und sich so möglichst viele Optionen offen zu halten. Die meisten grossen Softwareprojekte sind komplex und nicht kompliziert. Es gibt oft und viele Änderungen und Unbekannte. Dies sind etwa neue Technologien, Schnittstellen, Trends oder Anforderungen.

Sie behaupten also, die richtig anspruchsvollen Projekte können am besten mit agilem Vorgehen bewältigt werden.

Nein, so einfach ist es nicht. Im klassischen und bewährten Vorgehen geht man von der Prämisse aus, dass Systeme kompliziert aber nicht komplex sind. Das bedeutet, dass Anforderungen und Rahmenbedingungen stabil und genügend gut bekannt sind. Das verleitet sehr häufig dazu, die folgenden Denkfehler zu machen:

1. Während der Umsetzung werden Fehler erkannt. Daraus kann aber nicht mehr gelernt werden, da die Konzepte ja schon lange fertig und teilweise umgesetzt sind. Die Architektur ist «in Stein gemeisselt» und wird nicht mehr angetastet.
2. Ein zu hoher Detaillierungsgrad der Architektur ist nicht zwingend ein Zeichen für hohe Qualität, sondern ist der Qualität eher abträglich und generiert unnötigen Aufwand.
3. Oft verleitet die konsequente Generalisierung zur Meinung, Anforderungen vorwegnehmen zu können, was oft zu überkomplizierten und falschen Architekturen und Designs führt.

Zudem werden oft die folgenden Aspekte ausser Acht gelassen:

1. Alle Mitglieder in einem agilen Team besitzen Intelligenz und Wissen. Die Kollaboration dieser Intelligenzen zu nutzen birgt ein Mehrfaches an Potential als ein einzelner genialer Architekt.
2. Fehler und Irrwege sind etwas Gutes – wenn man sie frühestmöglich macht. Wenn man Fehler als solche anerkennt, kann man sofort darauf reagieren und es besser machen. Wenn man sie verleugnet, vertagt man die Lösung auf einen späteren Zeitpunkt und der Fehler wird immer schwerer.

Wie macht man agile Entwicklung denn nun richtig?

Agil heisst nicht ohne Struktur, sondern agil strukturiert. Es gibt klare Rollenzuteilungen. Der sogenannte Product Owner verantwortet den fachlichen Business Scope und das Budget. Das Team verantwortet die Product Increments, also die gebaute Lösung und steuert sich selbst. Der Scrum Master coacht alle methodisch und moderiert die Meetings. Er ist auch dafür verantwortlich, die Hindernisse aus dem Weg zu räumen.

Braucht es dann noch einen Architekten als solchen?

Auch agile Projekte benötigen eine Architektur, also einen Architekten. Er ist Mitglied des Entwicklungsteams. Der Architekt beteiligt sich an der Umsetzung und überprüft die Zweckmässigkeit der Lösungsansätze regelmässig. Architekturentscheidungen werden laufend durch Prototypen oder Durchstiche überprüft und untermauert. Fehlentscheidungen können passieren, werden aber sofort vom Team aufgedeckt und korrigiert. Durch die Beteiligung des Teams an der Architekturarbeit ist ein grosser Erfahrungsschatz vorhanden und die Akzeptanz wird laufend gewährleistet.

Nach welchen Prinzipen sollte die Architekturarbeit gemacht werden?

Festlegung der Architektur nach dem Prinzip nur «so viel wie nötig» ermöglicht es, Optionen länger offen zu halten – Ansätze wie «Last Responsible Moment» diktieren die Entscheidungsfindung. Dadurch können ändernde Anforderungen berücksichtigt werden. Das Produkt entsteht inkrementell. Die Dokumentation der Architektur wird laufend fortgeführt und im Team gechallenged. Durch den so implementierten, laufenden Rückkopplungsprozess des Softwarearchitekturentwurfs sind auch die Entwickler massgeblich an der Architektur beteiligt. Dies hat erwiesenermassen nur Vorteile

Sie sagen also Architektur entsteht im Team. Welche Rolle spielt die Architektur-Arbeit und welche Aufgaben übernimmt der Architekt dabei?

Heute werden die meisten IT-Projekte agil abgewickelt. Dabei hat sich aus der Erfahrung gezeigt, dass es gerade bei der IT Architektur häufig Fragezeichen und Lücken gibt. Auch die IT Architektur-Arbeit muss sich wandeln, damit sie in der agilen, von offenen Optionen und Flexibilität geprägten Projektwelt beste Ergebnisse liefert.

Hier gilt es, den Spagat zwischen Einbeziehung des Teams mit den langfristigen Zielen und Aufgaben der Architektur zu schaffen. Das Team hat häufig viel Erfahrung und Wissen. Davon sollte man profitieren. Softwarearchitektur ist aber nach wie vor kein demokratischer Prozess, sondern richtet sich strikt nach funktionalen und nicht-funktionalen Kundenanforderungen sowie wirtschaftlichen Unternehmenszielen. Bei divergierenden Auffassungen im Entwicklungsteam muss der Architekt die Entscheidung herbeizuführen.