Auch agile Projekte brauchen Softwarearchitekten
In sehr vielen Stellen- oder Projektbeschreibungen wird nach Architekten gesucht – und dies in klarer Abgrenzung zur Rolle eines Entwicklers oder Projektleiters. Dies wirft natürlich die Frage auf, worin genau sich die Rolle des Architekten von den beiden anderen unterscheidet.
Auf Nachfrage bei den Verantwortlichen hinter der Ausschreibung ist die Antwort oftmals dünn – sie reichen von „Können wir nicht genau sagen“ bis hin zu „eigentlich gibt es in Scrum-Teams keine wirklichen Architekten mehr“.
Es herrscht in vielen Fällen die Sichtweise vor, die Bezeichnung „Architekt“ spreche für sich selbst – wobei es für den Begriff tatsächlich sehr viele unterschiedliche Interpretationen gibt. Ich selbst habe einige Projekt als Softwarearchitekt begleitet und selbst in diesem Kontext trat die Frage auf, was dies nun eigentlich bedeutet. Auch in der agilen Welt hat der Architekt seinen Platz. Und deshalb sollten wir die Rollendefinition genauer unter die Lupe nehmen.
Softwarearchitektur definiert den Aufbau des Systems und Regeln für den Umgang damit
Auch in der Literatur variieren die Definitionen der Begriffe „Softwarearchitektur“ und „Softwarearchitekt“. Eine Sammlung der wichtigsten hat beispielsweise die Carnegie Mellon University in Pittsburgh zusammengetragen. Beim Fachverband „International Software Architecture Qualification Board“ (iSAQB) findet sich folgende Definition, die auch im Standard IEEE 1471 festgelegt ist:
„Die Softwarearchitektur definiert die grundlegenden Prinzipien und Regeln für die Organisation eines Systems sowie dessen Strukturierung in Bausteinen und Schnittstellen und deren Beziehungen zueinander wie auch zur Umgebung. Dadurch legt sie Richtlinien für den gesamten Systemlebenszyklus, angefangen bei Analyse über Entwurf und Implementierung bis zu Betrieb und Weiterentwicklung, wie auch für die Entwicklungs- und Betriebsorganisation fest.“
Aus dieser Definition lassen sich zwei entscheidende Aspekte ableiten. Erstens geht es bei der Softwarearchitektur um einen konstruktiven Aspekt, nämlich den Aufbau des Systems in Bezug auf die Bausteine, Schnittstellen und intrinsischen Beziehungen. Zweitens gibt die Softwarearchitektur Prinzipien und Regeln vor, die im gesamten Systemlebenszyklus zu beachten sind, um eine reibungslose Funktionsfähigkeit sicherzustellen.
Softwarearchitekten sind Teil des täglichen (agilen) Projektgeschehens
Die Hauptaufgabe eines Softwarearchitekten besteht nun darin, zunächst sehr einfach gesagt, die Softwarearchitektur zu entwerfen. Als „Zehnkämpfer“ der IT müssen sie dabei für alle Technologien Verständnis mitbringen, die im Systemlebenszyklus relevant werden. Eine weitere wichtige Aufgabe, die eher aus dem Projektmanagement kommt, besteht darin, beim Requirements Engineering mitzuwirken und die Softwarearchitektur im Hinblick auf die darin definierten Anforderungen zu entwerfen. Dies schließt natürlich auch entsprechende Kommunikation mit den Stakeholdern ein.
Die tägliche Arbeit eines Softwarearchitekten ist daher weit entfernt vom Klischee des reinen Theoretikers, der sich im stillen Kämmerlein einschließt und nach einer Weile mit dem fertigen Plan in der Hand wieder vor die Entwicklermannschaft tritt. Tatsächlich stellt die Rolle des Architekten ein wichtiges Bindeglied zwischen unterschiedlichen Interessengruppen des Projekts dar, beispielsweise die Anwender, Auftraggeber, der Betrieb, die Projektmanager, die Entwickler oder auch – nicht zu vergessen – das Management.
Ebenso haben Architekten in der agilen Praxis ihre Berechtigung. Sie müssen verhindern, dass aus initial beschriebenen User Stories und Anforderungen nach zahlreichen Änderungen ein sogenannter „Big Ball of Mud“, also ein großer Klumpen wird. Damit bezeichnet der Informatik-Jargon ein Programm, in dem keine erkennbare Softwarearchitektur wiederzufinden ist. Gefährlich an einer solchen Entwicklung ist, dass ein „Big Ball of Mud“ zunächst tatsächlich ohne weitere Probleme funktionieren kann. Spätestens sobald er aber eine gewisse Komplexitätsstufe erreicht wird, steigen die Kosten für Test und Wartung enorm.
Dem können Architektur-Spezialisten entgegnen, indem sie ihr Know-How – zum Beispiel über Entscheidungswege, Design-Patterns oder Architekturprinzipien – Sprint für Sprint in den Entwicklungsprozess einfließen lassen. Durch Trainings und Wissenstransfer können sie ihr Team hinsichtlich der Anforderungen und Vorteile einer definierten Architektur sensibilisieren. Auch diese lässt sich, ganz nach den Prinzipien des Agilen Manifests, iterativ weiterentwickeln.
