Architektur

„Im agilen Projekt werden keine Architekten benötigt“

Zuvor wurde diese Blog-Artikel-Serie über typische Missverständnisse im Kontext Agilität und Software-Architektur bereits mit einem einführenden Beitrag gestartet.

Missverständnis 1: „Im agilen Projekt werden keine Architekten benötigt“

Oft wird die Auffassung vertreten, dass jedes agile Team, nur dadurch dass es agil arbeitet, immer die richtigen Architekturentscheidungen treffen wird. Befürworter dessen glauben an den emergenten Architekturansatz, der im Gegensatz zum Big UpFront Design (BUFD), Architekturentscheidungen zum richtigen Zeitpunkt erfordert, nämlich erst dann wenn sie wirklich notwendig sind und nicht zu früh, damit andere Optionen nicht verbaut werden. Im Grunde ist dieser Ansatz sehr viel besser mit einem agilen, iterativ arbeitenden Projektvorgehen vereinbar. Dennoch muss beachtet werden, dass es teilweise extrem schwierig werden kann, den richtigen Zeitpunkt für eine Architekturentscheidung zu treffen. Das erfordert Erfahrung und Weitblick, die oftmals nur Projektmitglieder haben, die ein gewisses Architekturverständnis über die Jahre aufgebaut haben. Wichtig zu wissen ist zudem, dass jede Entscheidung ihren Preis hat und nicht alle technischen Mittel und Ansätze gut miteinander kombinierbar sind. Unter Abwägung all dieser Faktoren ist es zudem wichtig, dass Architekturentscheidungen Rückhalt im Team haben und akzeptiert werden. Die Krux mit dem Thema IT-Architektur und Agilität ist sehr viel komplexer und tiefgreifender als das anfangs meist wahrgenommen wird.

Aufgabe der Architektur

Grundsätzliche Aufgabe der IT-Architektur ist es, einen Plan für eine adäquate Problemlösung zu finden. Das zentrale Problem dabei ist jedoch immer, dass es nicht einfach zu erkennen ist, was „adäquat“ im jeweiligen Fall konkret bedeutet. Die treibenden nichtfunktionalen Anforderungen an eine Architektur müssen aus den Rahmenbedingungen, den Projektzielen sowie den strategischen Unternehmenszielen abgeleitet werden. Dabei hat jedes Unternehmen eine individuelle Ausgangsposition. Verfügbares Personal und Know-how, Alter und technische Schuld der bestehenden Systeme spielen dabei wichtige Rollen. Die bestehende Architektur der angetroffenen Systemlandschaft, welche zumeist eine Mischung aus Standardprodukten und individuell gestalteten Lösungen darstellt, ergänzen die Rahmenbedingungen. Dies alles erfordert eine Beleuchtung der Problemstellung aus unterschiedlichen Perspektiven und oftmals kann das gewünschte Ergebnis von den Stakeholdern nicht ad hoc treffend formuliert werden, daher müssen diese oft zwischen den Zeilen herausgelesen werden, was ein Gespür für die Situation des jeweiligen Unternehmens und einen gewissen Erfahrungsschatz erfordert.

Im Rahmen des agilen Wandels werden heute Ansätze wie Cloud-Plattformen, Microservices, Container-Technologien oder Event-getriebene Herangehensweisen favorisiert. Unter diesen und weiteren Möglichkeiten gilt es die jeweils passenden auszuwählen. Zusätzlich muss neben klassischem Make-or-Buy entschieden werden, ob die neue individuell entwickelte Cloud-ready Lösung wirklich in der Cloud unter Nutzung Cloud-only as-a-service Angebote oder doch lieber im eigenen Rechenzentrum betrieben werden soll? Ebenso sollte die mögliche Abhängigkeit zu einem bestimmten Cloud-Service-Anbieter (Vendor-Lock-In) beachtet werden.

Ein fehlgeschlagener Prototyp ist selten so teuer wie ein fehlgeschlagenes Projekt

Ob der jeweilige Ansatz unter Beachtung des beim Kunden vorhandenen Know-Hows, der mitgebrachten Altlasten (Legacy Systeme) sowie der individuellen Zielsetzung zum Erfolg führen kann, erfordert Erfahrung und insbesondere bei neuen Ideen auch den Mut zum Experimentieren. Über Prototypen lassen sich beispielsweise die erdachten Konzepte hinsichtlich ihrer technischen Tragfähigkeit überprüfen. Ein fehlgeschlagener Prototyp ist selten so teuer wie ein fehlgeschlagenes Projekt.

Eine bestimmte Investition ist immer notwendig, um die zugehörigen Voraussetzungen sowohl für den agilen Wandel als auch für die digitale Transformation zu schaffen. Die Schrittweite der gesamtheitlich agilen, wie auch der zugehörigen technischen Transformation muss passend gewählt werden. Ein zusätzlicher Know-how Aufbau im unternehmensinternen Entwicklungs- und Betriebsteam ist bei einem starken technischen Wandel zudem immer erforderlich. Auch die teilweise notwendige, organisationsstrukturelle Anpassung hat starken Einfluss auf die technische Lösung.

Fazit

Es gilt also immer stetig zu lernen, d. h. Teams und die Organisation lernen zu lassen und dabei für die schwierigen, teilweise nicht perfekt zu vereinbarenden Punkte in der Zielsetzung passende Trade-Offs im Laufe des Projekts zu erarbeiten. Aus diesen Gründen und der dargestellten Komplexität der Zusammenhänge ist für eine wirklich adäquate Lösung immer eine langfristige Architekturbegleitung der Weg zum Ziel. Die technische Architektur muss ständig angepasst, verfeinert und hinterfragt werden. Insbesondere die dabei entstehenden technischen Schulden sind im Blick zu behalten.

Vielleicht wäre es also tatsächlich kein Problem die Rolle des Architekten im Team zu eliminieren, solange seine Disziplinen erfüllt werden. Die richtigen Fragen sind zu stellen, die zugehörigen komplexen Zusammenhänge müssen verstanden werden und ein langfristiges Qualitätsbewusstsein gepaart mit der zugehörigen Erfahrung und Verantwortungsbereitschaft für diese Fragestellungen sollte gegeben sein. Und darauf gilt es bei der Teamzusammenstellung zu achten.

Eine moderne Lösungsarchitektur muss viele individuelle Einflussfaktoren berücksichtigen.