KI: Warum kollaborative Modellierung wichtiger wird als Programmieren

Inhaltsverzeichnis

close notice

This article is also available in English. It was translated with technical assistance and editorially reviewed before publication.

Don’t show this again.

Das Potenzial von KI-Ansätzen hängt davon ab, worum es in der Softwareentwicklung im Kern geht. Die offensichtliche Antwort: Code. Schließlich ist Software Code. Diese Antwort ist aber nicht nur offensichtlich, sondern auch falsch.

Continuous Architecture – Eberhard Wolff

Eberhard Wolff ist Head of Architecture bei SWAGLab und arbeitet seit mehr als zwanzig Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u.a. zu Microservices und trägt regelmäßig als Sprecher auf internationalen Konferenzen vor. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Domain-driven Design und Microservices.

Wichtigster Skill in der IT?

Stellen wir eine andere Frage. Was ist der wichtigste Skill in der IT? Wir haben bei „Software-Architektur im Stream“ diese Frage bei einer IT-Konferenz gestellt – und am häufigsten wurde als Antwort „Kommunikation“ genannt. Auch darüber hinaus kamen die allermeisten Antworten aus dem Bereich Soft Skills. Das ist bemerkenswert, weil es eine technisch ausgerichtete Konferenz war, bei der man vielleicht eher technische Skills als Antworten erwartet hätte.

Hauptherausforderung in der Softwarearchitektur

Die Frage nach dem wichtigsten Skill in der IT ist sehr breit – schließlich geht es um IT im Allgemeinen. Vielleicht sind im Bereich Softwarearchitektur andere Dinge wichtig? Wenn man nach der Hauptherausforderung in der Softwarearchitektur fragt, ergibt sich ein ähnliches Bild: Es geht vor allem um Menschen und die Zusammenarbeit zwischen ihnen.

Der Arbeitsalltag vieler Softwarearchitektinnen und -architekten zeigt auch, wie wichtig dieser Aspekt ist: Sie verbringen viel Zeit damit, mit Menschen zu kommunizieren, um gemeinsam am Projekt zu arbeiten.

Die Natur der Softwareentwicklung

Das ist nicht zufällig so. Der Grund ist die Natur von Softwareentwicklung. Die zu entwickelnde Software beeinflusst viele Menschen: Nutzer, Managerinnen und verschiedene andere Rollen. Die Anforderungen dieser Gruppen in Bereichen wie Sicherheit, Performance oder Betreibbarkeit zu verstehen, zu priorisieren und eine geeignete technologische Umsetzung zu finden, ist die zentrale Herausforderung in der Softwarearchitekturarbeit. Dabei haben Stakeholder unterschiedliche Interessen, manchmal sogar entgegengesetzte. Außerdem setzt ein Softwareprojekt einen Lernprozess in Gange, in dessen Rahmen dann neue Ideen und Gedanken auftauchen, die wieder neue Anforderungen zur Folge haben. Auslöser für das Lernen ist die Frage nach den genauen Anforderungen und die kritische Auseinandersetzung mit der vorhandenen Software und den schon bekannten Anforderungen. Dadurch denken die verschiedenen Rollen intensiv über die Software nach und finden so weitere Dinge, die es wert sind, umgesetzt zu werden.

Neben den Stakeholdern sind auch viele Technikerinnen mit der Software beschäftigt: Implementierung, Betrieb und auch Felder wie Sicherheit werden von unterschiedlichen Personen verantwortet. Auch hier gilt: Die Personen und Rollen müssen koordiniert werden, damit sie erfolgreich zusammenarbeiten.

Natürlich ist ein technisches Verständnis als Grundlage für die Arbeit an der Architektur notwendig. Man kann kaum in der Koordination erfolgreich sein, wenn man nicht weiß, worum es eigentlich geht. Tiefes Expertenwissen ist aber nicht notwendig: Solches Wissen ist entweder im Team vorhanden oder kann als Beratung zugekauft werden. Das Wissen um die Kollaboration und Koordination ist also eigentlich wichtiger als das rein technische Wissen.

LLMs und generative KI löst das schon?

Für die hauptsächliche Herausforderung Kommunikation können LLMs und generative KI nur indirekt helfen. So wie man im Web oder in Büchern Tipps findet, wie man die Zusammenarbeit verbessern kann, so können LLMs auch Ideen liefern. Aber sie können nur Texte oder Code generieren, keine funktionierenden Teams. Am Ende ist also der Mensch gefragt.

Aber vielleicht machen LLMs Softwareentwicklung so einfach, dass keine Teams mehr benötigt werden, sondern nur noch eine einzelne Person? Bei den Technikern ist es denkbar, dass die Größe der Teams durch Produktivitätsvorteile sinkt. Vielleicht bleiben die Teams aber auch gleich groß. Dann führen die Produktivitätsvorteile dazu, dass komplexere Software entwickelt wird. Technischer Fortschritt hat auch in der Vergangenheit zu einer besseren Produktivität geführt. Dennoch ist die Anzahl der Entwicklerinnen und Entwickler in der Branche insgesamt und in den einzelnen Projekten nicht gesunken, sondern gestiegen.

Was also tun?

Damit befinden sich Softwarearchitekten in einer eigentümlichen Situation: Scheinbar geht es in ihrem Bereich um technische Themen. Die meisten haben deswegen auch eine technische Ausbildung. In Wirklichkeit geht es aber um Menschen und die Zusammenarbeit. Die Zusammenarbeit von Menschen ist aber nicht so einfach und gut strukturierbar wie Software. Zwar ist es auch nicht einfach, gute Strukturen für Software zu finden, aber Software kann gar nicht an den Strukturen vorbeiarbeiten oder sich widersetzen und hat auch keinen eignen Willen.

Event Storming

Es gibt aber Techniken, die Zusammenarbeit und Kommunikation verbessern können und recht einfach einsetzbar sind. Zudem sind sie auf typische Herausforderungen in der Softwarearchitekturarbeit angepasst. Ein bekanntes Beispiel ist Event Storming: Um sich eine Domäne zu erarbeiten, schreiben Domänen-Expertinnen und -Experten Events auf Post-its. Anschließend bringt man sie in die zeitlich korrekte Reihenfolge und identifiziert parallel Aktivitäten sowie Events, die einen neuen Bereich in dem Ablauf einläuten (Pivotal Events). Dieses Vorgehen verteilt Wissen über die Domäne im gesamten Team. Außerdem ist ein Bereich in einer Swimlane zwischen zwei Pivotal Events ein Kandidat für eine Komponente in der Architektur.

Dieses Vorgehen verbessert die Kollaboration: Alle arbeiten parallel. Menschen, die sonst in Meetings eher still sind, können bei diesem Vorgehen Post-its schreiben und sich so viel besser einbringen. Es geht also nicht um eine schwer fassbare, abstrakte Verbesserung der Zusammenarbeit, sondern die Technik ist so angelegt, dass Zusammenarbeit angenehmer, effektiver und effizienter wird.

In diesem Zusammenhang ist noch eine weitere Beobachtung interessant: Man könnte denken, dass durch das Meeting ein wichtiges Artefakt entsteht – eine strukturierte Sammlung von Events, auf der dann die Architektur und die Entwicklung aufbauen kann. Nehmen wir an, wir würden dieses Artefakt wegwerfen. Wir hätten dennoch sehr viel über die Domäne gelernt und Zusammenarbeit geübt, und soziale Aspekte wie die Qualität der Zusammenarbeit oder Wissensmonopole wären offensichtlich geworden. Diese Ergebnisse könnten vielleicht sogar wichtiger als das Artefakt sein und sich ebenfalls positiv auf die Zusammenarbeit auswirken.

Kollaborative Modellierung

Event Storming ist nur ein Beispiel für eine ganze Palette von Techniken, für die sich der Begriff „kollaborative Modellierung“ etabliert hat. Sie beschreiben Formate, mit denen sich die gemeinsame Arbeit an Architekturen verbessern lässt. Weil die Zusammenarbeit so wichtig ist, sind diese Techniken eine große Bereicherung für alle Architektinnen und Architekten. Wer sich dafür interessiert: Es gibt dazu diverse Episoden bei Software-Architektur im Stream und auch ein Training von Tom Asel und mir (auch in Wien von Daniel Sack), in dem man praxisnah lernt, solche kollaborativen Modellierungssessions erfolgreich vorzubereiten und durchzuführen.

tl:dr

Skills im Bereich Kollaboration sind besonders wertvoll, weil Zusammenarbeit ein fundamentales Problem in der Architekturarbeit darstellt und durch KI nicht lösbar ist. Entsprechende Techniken beispielsweise im Bereich kollaborativer Modellierung wie „Event Storming“ kann man erlernen.

(rme)