Zählen Sie die Technologien: Das ist der schnellste Test dafür, ob eine Software für ihre Eigentümer entstanden ist oder für den Lebenslauf ihrer Entwickler. Ein System mit vier Datenbanken, zwei Queue-Systemen und einem Framework vom vergangenen Frühjahr wurde nicht entworfen, sondern zusammengetragen. Die Wartungsrechnung dafür zahlt selten der Sammler.
Was aufregende Technologie wirklich kostet
Neue Technologie kassiert dreimal. Zum ersten Mal bei den Risiken, die noch niemand kennt: bei Fehlerbildern, über die niemand gebloggt hat und die Sie um zwei Uhr nachts im Produktivsystem entdecken. Zum zweiten Mal beim Personal, weil jede exotische Entscheidung den Kreis der Menschen verkleinert, die das System warten können, und deren Preis erhöht. Zum dritten Mal bei der Langlebigkeit, denn ob das aufregende Framework dieses Jahres binnen fünf Jahren aufgegeben wird, ist ein Münzwurf, während bewährte Werkzeuge ihre Verdrängungswelle längst überlebt haben.
Die drei Posten verstärken einander. Die exotische Datenbank fällt auf eine Weise aus, die nirgends dokumentiert ist, und das allein wäre zu überstehen; nur hat der eine Entwickler, der sie verstanden hat, im Frühjahr gekündigt, und die Nachbesetzung läuft inzwischen im vierten Monat, weil der Kandidatenkreis für genau diese Fähigkeit ein Rundungsfehler ist. Währenddessen kündigt das Framework darunter seine „aufregende neue Richtung“ an, was in der Sprache der Anbieter einen Rewrite von allem bedeutet, was auf der alten Version entstanden ist. Das waren nie drei Risiken. Es war eines, dreimal gekauft.
Diese Kosten fallen an, nachdem die Agentur das Haus verlassen hat. Genau darin liegt die strukturelle Versuchung, aufregende Technologie zu wählen: Der Gewinn für den Lebenslauf gehört der Agentur, die Wartungsrechnung gehört Ihnen. Diese Anreize in Deckung zu bringen ist ebenso eine Frage des Vertrags wie des Engineerings, und es ist einer der Gründe, warum wir auf unsere Arbeit Gewährleistung geben und anbieten, das Ergebnis anschließend selbst zu betreiben.
Wie die Sammlung zustande kommt
Niemand nimmt sich vor, ein unwartbares System zu entwickeln; es wächst aus lauter einzeln vertretbaren Entscheidungen zusammen. Ein Entwickler will eine Technologie im Lebenslauf haben, und das Projekt ist die einzige Gelegenheit dazu. Ein Konferenzvortrag lässt eine Architektur, die für ein Unternehmen mit tausend Entwicklern entworfen wurde, wie eine Selbstverständlichkeit für ein Team von sechs Leuten wirken. Ein Microservices-Diagramm sieht professioneller aus als ein ehrlicher Monolith. Jede dieser Entscheidungen fügt ein bewegliches Teil hinzu, und bewegliche Teile multiplizieren sich: Zwei Datenbanken kosten nicht das Doppelte einer Datenbank, sondern die zweite Datenbank plus die Synchronisation zwischen beiden, dauerhaft.
Dagegen hilft eine langweilige Regel, angewandt im Review: Jede Technologie jenseits des Standard-Stacks muss sich ihren Platz mit einer messbaren Anforderung erkaufen, die der Standard nicht erfüllt. „Es skaliert besser“ zählt ohne Zahl nicht. „Wir könnten es später brauchen“ ist ein Grund, es später hinzuzufügen. Die Beweislast trägt immer die Neuheit, nie die langweilige Wahl, weil nur eine von beiden auf eine Historie verweisen kann.
Innovation ist ein Budget. Geben Sie es nicht für Ihre Infrastruktur aus, wo nur Ihre Entwickler es bemerken, sondern für Ihr Produkt, wo Ihre Kunden es sehen.
Langweilig ≠ alt
Langweilig heißt nicht Legacy. PostgreSQL, TypeScript, React und die etablierten Cloud-Dienste sind modern, werden aktiv weiterentwickelt und sind außerordentlich leistungsfähig. Langweilig sind sie deshalb, weil ihre scharfen Kanten dokumentiert sind, ihre Fehlerbilder bekannt und eine Million Teams die Probleme längst getroffen haben, auf die Sie gleich stoßen werden. Langweilig heißt berechenbar, und Berechenbarkeit ist das, wofür Sie bezahlen, wenn Sie Senior-Sätze bezahlen.
Darin steckt ein Signal für die Personalauswahl, das Inhaber regelmäßig falsch lesen. Junior-Entwickler suchen interessante Stacks, Senior-Entwickler suchen interessante Probleme und wählen bewusst unaufgeregte Werkzeuge, weil sie die Rechnung für Aufregung um zwei Uhr nachts schon selbst bezahlt haben. Ein Team, das Ihnen eine langweilige Architektur vorschlägt, ist nicht mutlos, sondern zeigt Ihnen seine Narben. Der Ehrgeiz gehört in das, was das System leistet, nicht in das, woraus es besteht.
Die Regel hat eine Kehrseite. Wenn wir das Innovationsbudget tatsächlich ausgeben, etwa bei KI-Systemen, wo sich der Stand der Technik im Quartalstakt verschiebt, kapseln wir den aufregenden Teil hinter langweiligen Schnittstellen, halten ihn austauschbar und legen eine Evaluation darum. Neuheit darf ein Modul erfassen, niemals die Architektur.
In der Praxis heißt das: Der Modellanbieter sitzt hinter einer Schnittstelle, von der der Rest des Systems nichts weiß, sodass ein Wechsel eine Konfigurationsänderung bleibt und keine Migration wird. Es heißt außerdem, dass ein Evaluations-Framework jedes Kandidatenmodell an Ihren echten Fällen bewertet, sodass die Entscheidung für einen Wechsel auf einer Messung beruht und nicht auf einer Mode. Der aufregende Teil darf aufregend bleiben. Den Rest des Systems interessant machen darf er nicht.
Der Standard-Stack - und wie man ihn ändert
Das praktische Werkzeug hinter alldem ist ein schriftlich festgehaltener Standard-Stack: die kurze Liste der Technologien, die ein neues System verwendet, solange niemand das Gegenteil belegt. Darauf stehen eine primäre Datenbank, eine Backend-Sprache, die das ganze Team liest, ein Frontend-Framework und verwaltete Cloud-Dienste statt selbst betriebener Server, weil die langweilige Wahl im Betrieb darin besteht, den Anbieter für die Rufbereitschaft zu bezahlen. Die Liste passt auf eine Karteikarte, und genau das ist ihr Zweck: Jede Ergänzung soll sich teuer anfühlen, weil sie teuer ist.
Den Standard zu ändern ist erlaubt, aber nur durch die Vordertür. Nötig ist ein kurzer schriftlicher Antrag: die Anforderung, die der aktuelle Standard nicht erfüllt, die Zahl, die das belegt, der Weg hinein und der Weg wieder hinaus. Danach folgt ein Probelauf in etwas Unkritischem, bevor irgendetwas Kundennahes davon abhängt. Teams, die dieses Ritual pflegen, übernehmen vielleicht eine neue Technologie pro Jahr, bewusst, und diese bleibt. Teams ohne Ritual übernehmen fünf aus Versehen und behalten zwei; die anderen drei laufen trotzdem weiter, halb migriert, und kassieren dauerhaft Miete.
Fragen an Ihren nächsten Dienstleister
Wer wartet dieses System im dritten Jahr, und was kostet das? Wie viele Entwickler am Markt beherrschen diesen Stack, und was passiert mit unserem Zeitplan, wenn eines dieser Frameworks aufgegeben wird? Warum diese zweite Datenbank, bitte in Zahlen? Wie sieht das On-Call-Runbook aus, und könnte ein Entwickler ihm folgen, der das System nicht selbst entwickelt hat? Bleiben die Antworten ausweichend, dann ist die Architektur ein Risiko, das sich als Demo präsentiert.
Langweilige Technologie ist der Grund, warum Software ein Vermögenswert bleibt, statt zu einem Forschungsprojekt mit Login-Seite zu werden. Sie ist ein Luxus, den sich Ihr Unternehmen gerade deshalb leisten kann, weil sie nicht nach Luxus aussieht. Der Aufpreis steckt nicht in den Werkzeugen, sondern in der Zurückhaltung.