Software zu entwickeln war noch nie so einfach wie heute. Ideen lassen sich schnell ausprobieren, Features schnell umsetzen, Releases schnell ausliefern. Dank generativer KI wird diese Entwicklung auch noch deutlich beschleunigt. Ich finde das spannend, weil dadurch vieles möglich wird, was früher deutlich mehr Aufwand erfordert hat. Gleichzeitig frage ich mich: Was nützt uns diese Geschwindigkeit, wenn wir nicht wissen, ob wir das richtige Problem lösen? In vielen Projekten sehe ich, dass Teams viel Energie in den Output stecken: Roadmaps, Tickets, Velocity, Releases. Das ist verständlich, weil all das sichtbar und planbar wirkt. Gleichzeitig fehlt manchmal das gemeinsame Bild davon, für wen wir eigentlich entwickeln und welchen Nutzen ein Feature haben soll. Dann sind wir zwar schnell, arbeiten aber nicht unbedingt in die richtige Richtung.
In meinem Talk möchte ich zeigen, wie Outcome-Driven Architecture Teams hilft, sich auf das Wesentliche zu konzentrieren, nicht als neue Rolle oder Framework, sondern als Haltung. Architektur bestimmt nicht nur, wie ein System gebaut ist, sondern auch, wie wir lernen, beobachten und uns verbessern können. Gute Architektur hilft Teams, Annahmen zu prüfen, Experimente zu ermöglichen und auf neue Erkenntnisse zu reagieren. Am Ende zählt nicht, wie viel Code entsteht, sondern welchen Wert Software für Menschen schafft.
