Boring by Design: Warum die unspektakulärste IT-Architektur oft die klügste ist

Neue Programmiersprachen versprechen Wettbewerbsvorteile. Eine seit zehn Jahren einflussreiche Denkschule aus dem Silicon Valley rät genau zum Gegenteil.

Geprägt wurde die Idee der unspektakulärsten Architekturen 2015 von Dan McKinley, der zuvor mehrere Jahre als Ingenieur beim Onlinehändler Etsy arbeitete. In seinem seither vielfach zitierten Essay „Choose Boring Technology“ schlägt McKinley ein einfaches Gedankenmodell vor: Jedes Unternehmen verfügt über eine begrenzte Anzahl sogenannter Innovationstoken, üblicherweise drei.

Für jede technologische Entscheidung, die tatsächlich neues, noch nicht vertrautes Terrain betritt, etwa den Einsatz einer erst seit kurzem existierenden Datenbank oder eines neuartigen Service-Discovery-Systems, wird eines dieser Token verbraucht. McKinleys Kernargument: Die eigentliche Innovation eines Unternehmens sollte sich auf das Produkt selbst und dessen Nutzen für Kunden konzentrieren, nicht auf den technischen Unterbau, der dieses Produkt trägt. Bewährte, „langweilige“ Technologien wie relationale Datenbanken, etablierte Programmiersprachen oder klassische Cron-Jobs gelten dabei ausdrücklich nicht als minderwertig, sondern als Werkzeuge, deren Fehlermodi und Grenzen bereits gut erforscht sind, wodurch sich unerwartete Ausfälle im Betrieb deutlich seltener einstellen.

Der Fall Segment: Von der Microservice-Euphorie zurück zum Monolithen

Wie kostspielig sich eine verfrühte, hype-getriebene Architekturentscheidung auswirken kann, zeigt ein vielbeachteter Fall des Datenplattform-Anbieters Segment. Rund ein Jahr nach dem eigenen Produktstart zerlegte das Unternehmen seine ursprünglich monolithische Anwendung in mehr als 100 einzelne Microservices, in der Erwartung, dadurch Entwicklungsgeschwindigkeit und Skalierbarkeit zu verbessern. In der Praxis führte die Aufteilung jedoch dazu, dass bereits ein einzelner fehlerhafter Verbindungspunkt im System dazu führte, dass sich Anfragen stauten, während die Systemlandschaft insgesamt versuchte, den Fehler automatisch zu kompensieren.

Da Segment dabei Hunderttausende Ereignisse pro Sekunde zwischen Kundendatenquellen und Analyseplattformen weiterleiten musste, wurde die technische Komplexität der verteilten Architektur zunehmend zur eigentlichen Belastung für das Ingenieursteam. Das Unternehmen entschied sich daraufhin bewusst für den Rückbau zu einer monolithischen Architektur und entwickelte dafür ein zentrales Aggregationssystem namens Centrifuge, das die zuvor über viele einzelne Warteschlangen verteilte Logik in einem einzigen, deutlich leichter zu wartenden Dienst zusammenführte.

Der Fall Amazon Prime Video: 90 Prozent geringere Infrastrukturkosten

Ein noch prominenteres Beispiel lieferte 2023 das Video-Überwachungsteam von Amazon Prime Video. In einer öffentlich dokumentierten Fallstudie beschrieb das Team, wie es seinen zuvor auf verteilte Microservices und serverlose Komponenten ausgelegten Video-Qualitätsüberwachungsdienst zu einer einzigen, monolithischen Anwendung zusammenführte. Das Ergebnis war eine Reduzierung der zugehörigen Infrastrukturkosten um 90 Prozent, verbunden mit einer deutlich einfacheren Skalierbarkeit des Gesamtsystems. Bemerkenswert an diesem Fall ist insbesondere, dass ausgerechnet ein Team des Cloud-Anbieters Amazon Web Services, der Unternehmen weltweit den Aufbau verteilter Microservice-Architekturen als Cloud-Dienstleistung verkauft, intern zu einer deutlich einfacheren Architektur zurückkehrte, sobald sich diese für den konkreten Anwendungsfall als wirtschaftlicher erwies.

Prinzip im Zeitalter der KI-gestützten Entwicklung

Nach Einschätzung mehrerer Fachautoren, die McKinleys ursprüngliches Konzept jüngst erneut aufgegriffen haben, gewinnt der Grundgedanke mit dem verbreiteten Einsatz von KI-Programmierwerkzeugen zusätzlich an Relevanz. Da große Sprachmodelle überwiegend anhand öffentlich verfügbaren Codes trainiert werden, sind etablierte, weit verbreitete Technologien wie SQL, PostgreSQL oder REST-Schnittstellen in den Trainingsdaten entsprechend umfangreich vertreten, wodurch KI-Werkzeuge bei deren Einsatz zuverlässigere Vorschläge liefern.

Bei neuartigen oder wenig verbreiteten Technologien fehlt sowohl dem Entwicklerteam als auch dem KI-Werkzeug selbst die notwendige Tiefe an verlässlichem Referenzmaterial, wodurch sich das ursprüngliche Risiko eines Innovationstokens in der Praxis nach Einschätzung dieser Autoren sogar verdoppelt: einmal für das Team, einmal für die KI-Unterstützung, auf die sich dieses Team bei der Umsetzung verlässt. Die folgende Übersicht fasst zentrale Aspekte des Konzepts zusammen:

Boring heißt nicht schlecht

Wichtig ist dabei nach übereinstimmender Einschätzung der zitierten Quellen eine Unterscheidung, die im Alltag leicht verloren geht: Boring bedeutet ausdrücklich nicht minderwertig. Es gibt durchaus Technologien, die zugleich unspektakulär und schlecht sind, solche Kombinationen sollten selbstverständlich weiterhin vermieden werden. Der eigentliche Kern des Konzepts liegt vielmehr darin, dass die tatsächlichen Fähigkeiten und vor allem die typischen Fehlermodi einer bewährten Technologie über Jahre hinweg gut dokumentiert und verstanden sind, während bei einer neuen, gerade erst populär gewordenen Lösung selbst erfahrene Teams zunächst grundlegende Betriebserfahrung im eigenen Umfeld erst sammeln müssen, oft genau dann, wenn ein System bereits unter echter Produktionslast steht.

Was das für IT-Entscheider bedeutet

Die zitierten Fälle deuten übereinstimmend darauf hin, dass technologische Komplexität nicht automatisch mit technischer Reife gleichzusetzen ist. Wo Architekturentscheidungen vor allem aus dem Wunsch heraus getroffen werden, dem Vorgehen bekannter Großunternehmen zu folgen, statt aus einer konkreten, im eigenen Betrieb tatsächlich vorhandenen Notwendigkeit, entsteht nach Einschätzung der zitierten Quellen ein erhebliches Risiko für spätere, kostspielige Rückbauten. McKinleys ursprüngliches Bild der begrenzten Innovationstoken bietet dafür eine simple, aber nach zehn Jahren weiterhin praxistaugliche Faustregel: Wer eine neue, unvertraute Technologie einführt, sollte sich bewusst fragen, ob dieser Schritt tatsächlich ein zentrales, unternehmensspezifisches Problem löst, oder ob er sich mit einer bereits bewährten, weniger aufregenden Lösung ebenso gut, schneller und mit deutlich geringerem Betriebsrisiko umsetzen ließe.