14. September 2018

Bewegende Software-Architektur: Wie funktioniert Architekturarbeit in agilen Vorhaben?


Heutzutage gilt agile Softwareentwicklung als Erfolgsfaktor bei besonders innovativen und zeitkritischen Projekten durch ihre schnelle Reaktionsfähigkeit auf Veränderungen im Markt. Wie aber ist es möglich, die Software-Architektur so zu gestalten, dass der vermeintliche Widerspruch Nachhaltigkeit versus Agilität, nicht nur elegant gelöst wird, sondern sogar noch zu einer besseren Architektur führt.

Die moderne IT, mit ihren ambitionierten Anforderungen und sich rasch bewegenden Technologie-Frameworks, ist eine hochkomplexe Welt. Um erfolgreich Projekte zu realisieren, ist es deshalb essentiell, nicht nur die Anforderungen genau zu kennen und zu definieren, sondern auch eine tragfähige Software-Architektur vorzusehen, damit keine bösen Überraschungen in späteren Phasen das Projekt in Schieflage bringen können.

Dazu werden – schon vor dem Projektstart – Fehler und Lücken in den Anforderungen identifiziert und eliminiert sowie die Architektur festgemacht. Um das Risiko zu eliminieren, dass Teile der Software nochmals neu geschrieben werden müssen, erarbeiten Architektur- und Dokumentationsprofis detaillierte Modelle und Prozesse. Erst danach wird mit der Codierung angefangen. Für jede spezifische Aufgabe gibt es bewährte Spezialisten (Anforderungen, Architektur, Codierung), damit das Projekt effizient und termingerecht umgesetzt werden kann.


Ein perfektes Vorgehen – oder etwa doch nicht?

Was sind häufige Denkfehler und Probleme beim klassischen Vorgehen in der Software-Architektur?

  • Die meisten Anforderungen ändern sich während des Projektes laufend und sind vor Beginn der Implementierung nie ganz bekannt.
  • 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.
  • Ein hoher Detaillierungsgrad der Architektur ist nicht zwingend ein Zeichen für hohe Qualität. Es ist der Qualität eher abträglich und generiert unnötigen Aufwand.
  • Oft verleitet die konsequente Generalisierung zur Annahme, dass Anforderungen vorweggenommen werden können. Dies führt oft zu überkomplizierten und falschen Architekturen und Designs.
  • Alle Mitglieder in einem agilen Team besitzen Intelligenz und Wissen. Die Nutzung der Kombination dieser Intelligenz, birgt ein Mehrfaches an Potential als ein einzelner genialer Architekt.

Fehler und Irrwege sind dann gut, wenn sie frühestmöglich gemacht werden. Wenn sie als solche anerkannt werden, kann sofort darauf reagiert und verbessert werden («Inspect and Adapt»).


Das agile Chaos

Um mit agilem Vorgehen gute Software zu machen, werden alle hierarchischen Strukturen eliminiert. Die Teams sind selbstorganisiert und machen was sie gerade für richtig halten. Es wird nichts mehr dokumentiert. Es gibt keine Projektleiter. Es gibt keine verbindlichen Meilensteine mehr, es gibt keinen Architekten mehr, die Projektkosten können nicht genau beziffert werden. Es gibt niemanden, der den Überblick hat. Es wird nach dem Motto „Es kommt dann schon gut!“ gearbeitet.

Daraus entsteht im besten Fall eine «Accidental Architecture». Das Chaos ist vorprogrammiert und keine Ziele werden so erreicht.


Agil – richtig gemacht

Agil heisst eben nicht ohne Struktur, sondern agil strukturiert. Der 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 ebenfalls dafür verantwortlich allfällige Hindernisse aus dem Weg zu räumen.

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äßig. Architekturentscheidungen werden laufend durch Prototypen oder Durchstiche überprüft und untermauert. Fehlentscheidungen können passieren, werden aber sofort von Team aufgedeckt und korrigiert.
  • Durch die Beteiligung des Teams an der Architekturarbeit ist ein grosser Erfahrungsschatz vorhanden und die Akzeptanz wird laufend gewährleistet.
  • Festlegung der Architektur nach dem Prinzip «nur so viel wie nötig» ermöglicht es Optionen länger offen zu halten – Ansätze wie «Der letzte vernünftige 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 diskutiert. Es werden keine mutmasslichen, potenziellen Anforderungen angenommen und berücksichtigt. Die Dokumentation ist kurz und aktuell. Dies ermöglicht bestmögliche Pflegbarkeit und Verständlichkeit.
  • Durch den so implementierten, laufenden Rückkopplungsprozess des Softwarearchitekturentwurfs sind auch die Entwickler maßgeblich an der Architektur beteiligt. Die hat erwiesenermassen nur Vorteile.


Fazit

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 so wandeln, dass sie in der agilen, von offenen Optionen und Flexibilität geprägten Projektwelt beste Ergebnisse zu liefern vermag.

Hier gilt es, den Spagat zwischen Einbeziehung des Teams und langfristigen Zielen und Aufgaben der Architektur zu schaffen. Das Team hat häufig viel Erfahrung und Wissen, davon muss profitiert werden. 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 ist es die Aufgabe des Architekten eine Entscheidung herbeizuführen.

Die Fähigkeiten zur Kommunikation, Motivation und Entscheidungsfindung waren für Architekten schon immer wichtig. Im agilen Umfeld sind sie unabdingbar.

 

Willst du mehr über Agiles Vorgehen wissen? Dann besuche unseren Workshop am Agile Leadership Day!


Pic
Dietmar Hafner

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 Softwareentwicklungs-Methodik. 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