Dieselbe Technologie, zwei Kontexte, zwei Urteile — der Hype-Zyklus erklärt das nicht.
Jemand sagt im Architektur-Meeting: „Microservices sind doch durch.“ Zwei Stühle weiter sitzt jemand, der sie gerade erfolgreich einführt. Beide haben recht. Genau deshalb sind Trend-Entscheidungen in der Softwarearchitektur so schwer — und genau deshalb treffen viele Teams sie falsch.
Warum der Hype-Zyklus die falsche Frage stellt
Microservices, Serverless, AI-native Architecture: In der Softwarearchitektur jagen sich die Trends. Manche bleiben, manche verschwinden, manche halten sich hartnäckig im Alltag, obwohl wir es längst besser wissen. Das übliche Werkzeug, um da Ordnung reinzubringen, ist ein Reife-Modell wie der Gartner Hype-Zyklus: Was steigt auf, was ist überholt, was sollte man im Auge behalten?
Das Problem an dieser Frage: Sie behandelt den Wert einer Technologie als ihre Eigenschaft. Als ob „Microservices“ pauschal gut, reif oder tot sein könnten — unabhängig davon, wer sie einsetzt. In der Praxis stimmt das nicht. Wer im Banking arbeitet, bewertet „AI-native“ anders als jemand aus dem E-Commerce. Wer eine Greenfield-Architektur baut, sieht Microservices anders als jemand mit zehn Jahren gewachsenem System im Rücken.
Die Reife-Frage produziert deshalb eine gefährliche Scheinsicherheit. Sie liefert ein Urteil, das sich objektiv anfühlt, aber den entscheidenden Faktor ausblendet: deinen Kontext. Und Entscheidungen, die auf der falschen Frage beruhen, werden teuer — egal wie sorgfältig du sie triffst.
Der Denkrahmen: Kontext schlägt Reife
Der mentale Shift ist klein, aber er ändert alles. Hör auf zu fragen, ob ein Trend ausgereift ist. Frag, ob er zu deinem Kontext passt. Reife ist eine Eigenschaft der Technologie. Eignung ist eine Beziehung zwischen Technologie und Situation — und nur Letztere lässt sich überhaupt beantworten.
Eine Technologie ist nie gut oder schlecht. Sie ist passend oder unpassend — und das entscheidet allein dein Kontext.
Das klingt banal, hat aber harte Konsequenzen. Es heißt, dass es keine allgemeingültige Trend-Bewertung geben kann, die du übernehmen darfst. Es heißt auch, dass Ansätze nicht sterben, weil sie schlecht sind, sondern weil die Hype-Dynamik sie aus der Mode drängt — oft samt ihrer guten Teile. Wer Trends einordnen will, muss zwei Dinge trennen, die ständig vermischt werden: das Urteil der Branche und die Eignung für den eigenen Fall.
Drei Perspektiven auf dasselbe Problem
Trends im eigenen Kontext einordnen statt blind folgen
Die zentrale Herausforderung: Wie bewertest du einen Trend, ohne ihn entweder reflexhaft mitzunehmen oder reflexhaft abzulehnen?
Statt einen fertigen Trend-Radar zu präsentieren, bringen die Teilnehmenden ihre eigenen Trends aus dem Arbeitskontext mit und ordnen sie gemeinsam ein — entlang ihrer Lebenszyklus-Phase, aber mit gezielter Reibung dort, wo dieselbe Technologie unterschiedlich bewertet wird. Genau an dieser Reibung wird sichtbar, was statische Modelle verschweigen: dass der Kontext die Bewertung bestimmt, nicht die Technologie. Es geht auch um die Grenzen klassischer Modelle wie des Gartner Hype-Zyklus und um alternative Denkrahmen für die Lebenszyklen von Trends.
Du nimmst eine Methode mit, um Trends im Team strukturiert einzuordnen — und einen persönlichen Transfer, welche du wie weiterverfolgst.
Der ewige Ritt auf dem Hype-Zyklus beim Software Architecture Summit mit Martin Günther
Warum gute Ansätze verschwinden — das Beispiel OOD
Objektorientiertes Design war einmal die Basis für taktisches Domain-Driven Design. Heute ist es aus der Praxis verschwunden — zusammen mit den UML-Diagrammen, aber eben auch mit den guten Teilen.
Die Keynote geht dem Aufstieg und Fall von OOD nach: ursprüngliche Motivation, Verfehlungen, Niedergang durch Method Wars, das MDA-Debakel und — paradoxerweise — strategisches DDD. Der Punkt ist nicht Nostalgie. Der Punkt ist, dass kein etablierter Ansatz den Platz von OOD bei der Modellierung komplexer Daten eingenommen hat. Ein gutes Werkzeug wurde mit dem Hype entsorgt, und die Lücke ist geblieben.
Du nimmst mit, wie sich bewährte OOD-Prinzipien — kombiniert mit Datenmodellierung aus der funktionalen Programmierung — heute noch für modulare Software nutzen lassen.
Den größten aktuellen Trend nüchtern denken: Coding Agents und Teamrollen
Die Art, wie wir Teams zuschneiden, hat sich schon oft geändert: von Silos und Spezialisierung über cross-funktionale Scrum- und 2-Pizza-Teams bis zu Full-Stack und Team Topologies. Coding Agents sind die nächste Welle — und niemand hat die perfekte Vorhersage.
Wenn Agenten das Tippen übernehmen, verschiebt sich der Engpass: weg von der Implementierung, hin zu Wert- und Vertrauensfragen. Wer klärt die Domäne und die Anforderungen? Wer verantwortet Qualität, Tests, Architektur? Die Keynote schaut darauf, wie sich Teammodelle historisch verändert haben, und fragt nüchtern: Wer sitzt im Team der Zukunft noch am Tisch, wer entscheidet, wer trägt Verantwortung?
Du nimmst einen Rahmen mit, um Rollen und Entscheidungswege im Agenten-Zeitalter wertorientiert statt tool-getrieben zu denken.
The pizza party of the future beim Software Architecture Summit mit Katie Clark und Simon Rohrer
Was du heute tun kannst
- Kläre in jeder Trend-Diskussion zuerst den Kontext, bevor du über die Technologie redest: Greenfield oder gewachsenes System? Welche Branche? Welche Constraints? Erst danach lohnt sich die Bewertung.
- Trenne im Team explizit zwei Fragen, die ständig vermischt werden: „Ist das ausgereift?“ und „Passt das zu uns?“ Die zweite ist die einzige, die du beantworten kannst.
- Wenn ein Ansatz „erledigt“ wirkt, prüfe, ob seine guten Teile mit dem Hype entsorgt wurden — und ob die Lücke, die er hinterließ, bei dir noch offen ist.
Fazit
Der Hype-Zyklus ist ein Beobachtungswerkzeug, kein Entscheidungswerkzeug. Er sagt dir, was die Branche gerade fühlt — nicht, was dein System braucht. Architekturarbeit beginnt genau dort, wo der Hype-Zyklus aufhört: bei der Frage nach dem Kontext.
Wer Trends nach Reife bewertet, stellt die falsche Frage. Die richtige lautet: passend wofür?
Wer das nicht nur lesen, sondern an eigenen Trends durchspielen will — die drei Sessions zu Hype-Zyklus, OOD und der Zukunft der Teamrollen beim Software Architecture Summit in Berlin bieten genau diesen Rahmen. Zum Programm des Software Architecture Summit.
Key Takeaways
- Der Wert eines Trends ist keine Eigenschaft der Technologie, sondern eine Beziehung zu deinem Kontext.
- Reife-Modelle wie der Gartner Hype-Zyklus liefern Scheinsicherheit, weil sie den Kontext ausblenden.
- Trenne „Ist es ausgereift?“ von „Passt es zu uns?“ — nur die zweite Frage ist beantwortbar.
- Ansätze verschwinden durch Hype-Dynamik, nicht durch Untauglichkeit — und nehmen oft ihre guten Teile mit (Beispiel OOD).
- Bei Coding Agents verschiebt sich der Engpass von Implementierung zu Wert- und Vertrauensfragen.
🔍 FAQ
1. Was ist der Hype-Zyklus in der Softwarearchitektur?
Der Hype-Zyklus ist ein Modell, das den Reifegrad einer Technologie über die Zeit beschreibt — von überzogenen Erwartungen über die Ernüchterung bis zur produktiven Etablierung. In der Softwarearchitektur wird er genutzt, um Trends wie Microservices oder AI-native einzuordnen. Seine Grenze: Er bewertet Technologien losgelöst vom konkreten Einsatzkontext, der über Eignung aber tatsächlich entscheidet.
2. Wie bewerte ich, ob ein Architektur-Trend für mein Projekt relevant ist?
Indem du zuerst deinen Kontext klärst, nicht die Technologie: Greenfield oder gewachsenes System, Branche, regulatorische und betriebliche Constraints. Eine Technologie ist nie pauschal gut oder schlecht, sondern nur passend oder unpassend für eine konkrete Situation. Die brauchbare Frage lautet daher nicht „Ist das ausgereift?", sondern „Passt das zu uns?".
3. Warum verschwinden gute Architektur-Ansätze wie OOD aus der Praxis?
Weil Ansätze meist nicht an mangelnder Tauglichkeit scheitern, sondern an der Hype-Dynamik, die sie aus der Mode drängt. Objektorientiertes Design wurde durch Method Wars, das MDA-Debakel und die agile Bewegung verdrängt — samt seiner guten Teile für die Modellierung komplexer Daten. Oft bleibt die Lücke, die ein verdrängter Ansatz hinterlässt, unbesetzt.
4. Wie verändern Coding Agents die Rollen im Entwicklungsteam?
Coding Agents übernehmen zunehmend die Implementierung, wodurch sich der Engpass auf Wert- und Vertrauensfragen verschiebt: Wer klärt Domäne und Anforderungen, wer verantwortet Qualität und Architektur? Damit stehen Teamzuschnitt, Entscheidungswege und Verantwortung neu zur Debatte. Entscheidend ist, Rollen wertorientiert zu denken statt rein am Tooling auszurichten.
