Alles hat ein Ende, so auch diese Kolumne. Und zum Ende lohnt sich ein Ausblick darauf, wie es mit Softwarearchitektur weitergehen wird. Schließlich ändert künstliche Intelligenz alles – und auch sonst ist die Änderung eine Konstante in der Branche. Oder sind das nur scheinbare Innovationen und in Wirklichkeit bleibt alles beim Alten?

Künstliche Intelligenz und insbesondere Large Language Models (LLMs) ist im Moment in unserer Branche der Hype schlechthin. Daher müssen Architekt:innen sich in diesem Bereich positionieren: Der Versuch, diese Technologien möglichst hilfreich in die alltägliche Arbeit zu integrieren, ist eine Position, aber auch das fundamentale Ablehnen dieser Ideen beispielsweise aus ethischen Gründen. Die Positionierung erfordert, dass man sich mit diesen Technologien auseinandersetzt. Sich mit Ideen oder Technologien zu beschäftigen, ist eben ein wichtiger Teil unserer Branche.

Menschen und Kommunikation

Wie kann KI also mir in meinen Tätigkeiten helfen? Mein Arbeitsalltag besteht vor allem aus Kommunikation. Direkte Kommunikation in Workshops, Meeting oder Videokonferenzen, eher indirekte Kommunikation bei Softwarearchitektur im Stream oder durch Vorträge und schließlich Artikel wie diesen. Der Grund dafür ist die Arbeit in Teams. Softwareentwicklung findet eigentlich immer in Teams statt. Wird durch KI Softwareentwicklung keine Tätigkeit von Teams mehr sein? Dafür gibt es im Moment keine guten Indizien. Der Einfluss von KI müsste die Produktivität so stark steigern, dass alle oder zumindest eine große Mehrheit von Projekten von einer einzigen Person umgesetzt werden kann. Das ist aber mehr als fraglich. Es gibt beispielsweise Hinweise, dass die Produktivität sogar nur kurzfristig steigt und langfristig wieder auf ein Niveau sinkt, wie es auch ohne LLMs zu erreichen wäre [1]. Aber natürlich gibt es im Bereich KI sehr viele Investitionen und auch Innovationen. Es ist also schwierig, für einen längeren Zeithorizont gute Vorhersagen zu machen.

Aber selbst wenn die Produktivitätsvorteile massiv sein sollten: Fortschritte wie das Etablieren von Programmiersprachen in den Fünfzigerjahren oder die immer besser werdenden Werkzeuge haben nicht dazu geführt, dass Teams kleiner werden. Stattdessen werden immer mehr und immer komplexere Probleme mit Software gelöst, so dass Entwicklung immer noch im Team stattfindet und die Gesamtzahl der Entwickler:innen immer weiter zunimmt. Warum sollte der Produktivitätsvorteil also nicht einfach dazu führen, dass noch mehr und komplexere Software entwickelt wird, statt die Größe der Teams oder die Anzahl der Entwickler:innen zu reduzieren?

Außerdem gehört zur Entwicklung nicht nur die technische Umsetzung, sondern vor allem auch das Verstehen und Strukturieren von Anforderungen und somit die Fähigkeit zu verstehen, was denn überhaupt umgesetzt werden soll und wie man diese Umsetzung strukturiert. Dazu ist Kommunikation mit Stakeholdern notwendig – und davon gibt es eigentlich immer mehrere. Diese haben verschiedenen Ideen, was eigentlich zu entwickeln ist. Diese Ideen müssen verstanden und dann so aufbereitet werden, dass sie technisch umgesetzt werden können. Auch für diese Herausforderung ist Kommunikation essenziell – die Kommunikation mit den Stakeholdern und der Ausgleich zwischen den verschiedenen Prioritäten.

Natürlich wäre es denkbar, dass in Zukunft Domänenexpert:innen selbst die Software schreiben. Aber auch dann müssen die Interessen der verschiedenen Stakeholder:innen ausgeglichen werden. Außerdem sind alle Vorstöße, Domänenexpert:innen selbst entwickeln zu lassen, gescheitert. Beispielsweise hatte die Programmiersprache COBOL das Ziel, durch eine nahezu natürlichsprachliche Syntax Nichtentwickler:innen das Schreiben von Software zu ermöglichen.

Und es ist ja nicht so, als würden Domänenexpert:innen nicht selbst entwickeln. Bei genügend Firmen haben Domänenexpert:innen beispielsweise die wichtigste Logik der Firma in Excel abgebildet. Oft muss diese Software dann irgendwann komplett neu geschrieben werden, weil sonst die Wartbarkeit oder andere nicht-funktionale Anforderungen bzw. Qualitäten nicht mehr eingehalten werden können. Um Software wirklich dauerhaft in Produktion zu halten, bedarf es mehr als nur Domänenwissen und die Kenntnis eine Implementierungstechnologie. Entwickler:innen und Architekt:innen können Systeme strukturieren und so implementieren, dass sie auch langfristig den Anforderungen entsprechen. Es erscheint daher wahrscheinlich, dass auch in Zukunft bei solchen Unterfangen dieses Wissen relevant ist.

Empfehlungen

Kommunikation und das Verständnis für die Domäne sind also wichtig. Daraus ergeben sich die konkreten Empfehlungen, gerade in diese Bereiche beim eigenen Wissen zu investieren. Diese Empfehlung ist nichts Neues: Nahezu traditionell ist ein Fokus auf diese Themen etwas, was Architekt:innen und auch anderen Techniker:innen immer wieder nahegelegt wird. Technische Skills werden in solchen Rollen natürlich vorausgesetzt, aber die Kommunikation ist der Bereich, der das größte Potenzial bietet. Und wenn man Menschen nach den wichtigsten Skills in der IT [2] oder in der Softwarearchitektur [3] befragt, sind solche Skills ganz weit oben. Sich mit diesem Bereich zu beschäftigen und sich als Architekt in diesem Bereich zu verbessern, ist also auf jeden Fall sinnvoll. Denn die zentrale Herausforderung in der Softwareentwicklung sind die Menschen und der Umgang mit ihnen. Es ist praktisch sicher, dass dies so bleiben wird – völlig unabhängig von dem technischen Fortschritt. Daher sind diese Fragen auch wichtig in dieser Kolumne gewesen – noch mehr als es noch eine sozio-technische Kolumne war.

Grundlagen

Also sind Kommunikation und der Umgang mit Menschen wichtig. Aber bei der Architekturberatung fallen oft auch andere Herausforderungen auf: Wie werden Softwaresysteme aufgeteilt? Das ist zwar eine fundamentale Frage, aber das bedeutet keineswegs, dass es dafür ein allgemeingültiges Vorgehen in der Architektur gibt. Die Frage zum Vorgehen bei der Aufteilung von Systemen wird sehr unterschiedlich von unterschiedlichen Menschen beantwortet. In diesen grundlegenden Fragen besser zu werden, ist auf jeden Fall ein Vorteil, weil diese Fähigkeit die Qualität von Entwürfen nachhaltig beeinflusst.

Eine andere fundamentale Herausforderung: Wie werden die Systeme in Produktion gebracht – idealerweise mit einem hohen Maß an Automatisierung bei den Tests und auch beim Deployment? Die meisten glauben, dass dadurch nur das Time-to-Market besser wird. Aber durch die DORA-Studien [4] wissen wir, dass die Produktivität von Teams sich ebenso bessert und sogar beispielsweise die Gefahr für Burnouts abnimmt. Das in diesem Bereich aber grundlegende Stellschrauben für eine besseres Produktivität zu finden sind, ist Vielen nicht klar – dabei ist Produktivität ein extrem wichtiger Faktor und sollte gerade das Management von solchem Vorgehen überzeugen.

Und dann gibt es da noch ein fundamentales Missverständnis: Irgendwie soll Architektur doch etwas Stabiles sein. Das ist aber keine gute Idee [5]. Projekte und Ansprüche ändern sich. Deswegen muss man in Iterationen an der Software aber auch an der Architektur arbeiten. Das gilt nicht nur für Softwareentwicklung, sondern für jede Art von ingenieurmäßigem Vorgehen [6]. Den Pionier:innen in der Softwareentwicklung ist das zu einer Zeit sehr schnell klar geworden, als die meisten Menschen in unserer Branche noch gar nicht geboren waren [7]. Der Entwurf einer Architektur kann prinzipiell nur so lange Bestand haben, bis Änderungen an den Voraussetzungen einen neuen Entwurf erforderlich machen. Die Notwendigkeit einer solchen Änderung ist daher nicht etwa eine Schwäche der Architektur, sondern eben eine unabwendbare Begebenheit.

Und schließlich müssen die notwendigen Qualitäten bzw. nichtfunktionalen Anforderungen klar sein. Muss das System besonders sicher sein? Oder besonders schnell? In welchen Situationen ist Geschwindigkeit wirklich wichtig? Wann nicht? Nur wenn diese Fragen klar beantwortet sind, sind die Ziele der Architektur klar und nur dann kann die Architektur und die technische Umsetzung sie wirklich erreichen. Wenn das nicht der Fall ist, werden die Ziele höchstens zufällig erreicht werden. Außerdem wird vielleicht zu viel in weniger wichtige Eigenschaften des Systems investiert, was dann die Entwicklung unwirtschaftlich macht.

Wenn die Aufteilung der Systeme, die Continuous-Delivery-Pipeline, das iterative Vorgehen und die Qualitäten beachtet werden, sind in vielen Fällen schon die größten Probleme im Projekt beseitigt. Das kann natürlich auch schon kompliziert und zeitaufwendig werden. Aber in zu vielen Fällen sind die Prioritäten nicht klar, so dass diese Themen auf der Strecke bleiben, obwohl sie so wichtig sind – und die Projekte verlieren sich in der Lösung irrelevanter Probleme. Diese Themen werden also auch in Zukunft relevant bleiben.

Intrinsische Motivation: Nicht nur gut

Für Viele ist die Entwicklung von Software oder Architekturen mehr als ein Broterwerb. Sie lösen gerne Probleme in diesem Bereich und erfreuen sich an guten Lösungen. Solche intrinsische Motivation ist sicher hilfreich, aber auf der anderen Seite kann das recht leicht zu Frustrationen oder am Ende zu einem Burnout führen, wenn man beispielsweise dazu gezwungen ist, zu viele Kompromisse zu machen. Wichtig: Berufsunfähigkeit im Bereich Softwareentwicklung ergibt sich meistens aus solchen psychologischen Problemen, eher weniger aus körperlichen Einschränkungen.

Gleichzeitig sind wir privilegiert. Auch in den aktuell wirtschaftlich schwierigen Zeiten verdienen Menschen in der Softwareentwicklung mehr als in vielen anderen Berufen und wir sind immer noch relativ gefragt.

Daraus ergibt sich: Wenn man in einer frustrierenden Umgebung tätig ist, kann und sollte man versuchen, die Situation zu ändern. Wenn das nicht erfolgreich ist, sollte man sich vielleicht einen anderen Job suchen. In unserem Tätigkeitsfeld steht diese Alternative einem oft auch wirklich offen.

Fazit

Softwarearchitektur wird unabhängig von KI ein Thema sein, bei dem Menschen und Kommunikation im Mittelpunkt stehen müssen. Ein Fokus auf wesentliche Aspekte wie die Aufteilung der Systeme, die Continuous-Delivery-Pipeline, das iterative Vorgehen und die Qualitäten des Systems sind für einen Erfolg zentral. Und wenn man dann auch noch auf sich selbst achtet, kann Softwarearchitektur dauerhaft ein spannendes Betätigungsfeld sein.

Ich hoffe, mit dieser und den davor erschienenen Kolumnen spannende und interessantes Lesematerial geboten zu haben und bedanke mich für die Aufmerksamkeit!