Ward Cunningham prägte den Begriff Technical Debt im Jahr 1996. Technical Debt ist ein Konzept in der Softwareentwicklung, das die indirekten Kosten für zusätzliche Nacharbeit durch Abkürzungen oder Aufschieben von Arbeit beschreibt. Damals, im Jahr 2010, hat mir Philippe Kruchten das Konzept in einem spannenden Vortrag vorgestellt, der mir immer im Gedächtnis geblieben ist. Daraus ergab sich ein interessanter Gedanke: Was wäre, wenn wir die Kosten für fehlerhafte Software in Geldwerten messen könnten? Mit anderen Worten, die Vorteile der Vermeidung oder Behebung von Fehlern quantifizieren?
Probleme bei der Arbeit
Natürlich gibt es mehrere Gründe, die dafür verantwortlich sind. Zum einen sind da die Ecken, die unter Zeitdruck absichtlich kurz gehalten wurden (das war übrigens bevor das Konzept des Minimum Viable Product aufkam). Es gibt die Entscheidungen, die ein einzelner Entwickler getroffen hat, obwohl sein Wissen über die Domäne nicht vollständig war. Es gibt die Probleme, dass man dem Projekt unter Zeitdruck einfach nicht genug Aufmerksamkeit schenkt. Ohne Vorbereitung in das Projekt zu stürzen ist ein weiteres Problem. Nicht die richtigen Leute mit an Bord zu holen ist ein weiteres.
Und noch etwas ganz anderes spielt eine Rolle: Zeit. Chris Sterling definierte sie als „das Abklingen des Komponenten- und Interkomponentenverhaltens, wenn die Anwendungsfunktionalität einen Mindeststandard für die Zufriedenheit des Kunden erfüllt“. Wir wissen alle, dass diese Mindeststandards mit der Zeit reifen. Technologien entwickeln sich weiter. Designs entwickeln sich weiter. Der Bedarf an Verjüngung ist nur eine Frage der Zeit. So wie ein Haus ab und zu einen neuen Anstrich braucht, braucht auch Software ab und zu einen Neuanstrich.
Teufelskreis
„Wenn ich es noch einmal aufbauen müsste, mit dem Wissen, was ich während des Aufbaus gelernt habe, würde ich meinen Code anders strukturieren.“ Ich weiß, dass ich das schon oft zu mir selbst gesagt habe. Ich weiß, Du kannst nicht gegen die Zeit ankämpfen. Du kannst versuchen, deiner Zeit voraus zu sein, aber im Allgemeinen ist das keine realisierbare Strategie. Also, das Beste, was du tun kannst, ist für jede unbekannte zukünftige Veränderung zu entwerfen. Mach es flexibel, offen und einfach zu pflegen. Sorge dafür, dass Dein Design aktuell, eindeutig und leicht zu verstehen ist. Und das sind genau die Ecken, die unter Zeitdruck zu kurz kommen. Technical Debt erzeugt mehr Technical Debt. Das will niemand, aber es ist nun mal so, wie es ist.
Über die Lebensdauer des Produkts neigen die Schulden dazu, sich anzuhäufen und können zu einem Wartungsalptraum werden. Es gibt aber einen Weg, dies zu verhindern. So wird zumindest das häufige Refactoring von Code verkauft. Halte Deine Software fit für die Veränderungen, die unweigerlich kommen werden. Wenn nicht, enden Deine Schulden letztendlich im Bankrott.
Paradigmenwechsel
Heute behaupte ich, dass dies nicht genug ist. Wir wissen alle, dass es so viel mehr als die reine Funktionalität zu beachten gibt. Zum Beispiel Verfügbarkeit, Leistung, Benutzerfreundlichkeit, Datenschutz und Preis. Die Welt ist in der Tat ziemlich anspruchsvoll geworden. Sind wir uns sicher, dass das jetzige System, das vielleicht ganz gut funktioniert, nicht durch etwas Billigeres, Schnelleres und Besseres ersetzt werden kann? Ist deine Wahrnehmung, dass dein System nicht defekt ist, eine ausreichende Rechtfertigung, es nicht zu reparieren? Produkteigentümer erwarten heutzutage die höchste Qualität zum niedrigsten Preis in der schnellsten Geschwindigkeit. Die alte Denkweise wird nicht die Ergebnisse hervorbringen, die diese neue Realität verlangt. Hier müssen sich unsere Paradigmen verschieben, und genau das passiert gerade.
Wenn sich Paradigmen verschieben, werden schnelle Lösungen nicht viel helfen. Ein Facelifting ist ein sehr oberflächlicher Verjüngungsversuch. Man kann es mögen oder hassen, als Industrie befinden wir uns inmitten eines Wandels, der im Grunde alles in Frage stellt, was wir bisher gewohnt waren. Die neue Devise lautet „Cloud Native“ und favorisiert massiv verteilte, eng skalierte Microservices, die als ein zusammenhängendes Netzwerk von interagierenden Komponenten instrumentiert werden. Dies ist in vielerlei Hinsicht der nächste Schritt im Übergang von einer datenzentrierten zu einer digitalen Denkweise. Hier werden die neuen Maßstäbe in Bezug auf Qualität, Kosten und Veränderungsgeschwindigkeit gesetzt, was erklärt, warum so viele traditionelle Systeme und Dienste heute Architectural Debt sind.
Befreie deinen Geist
Wenn ich also heute auf meine frühere Arbeit zurückblicke, ist es nicht so sehr mein Design, das schlecht ist. Wenn ich es noch einmal entwerfen müsste, mit den heutigen Technologien, würde ich definitiv andere Kompromisse eingehen. Virtualisierung ist das Zauberwort, das dieses neue Paradigma vorantreibt. Jedes Bauteil kann seine eigene virtuelle Datenbank haben, ohne sich um die eigentliche Datenverarbeitung zu kümmern. Ich fühle mich so frei, eine relationale Datenbank für einen Service zu entwerfen, der eine komplexe Abfrage implementiert, und eine Objektdatenbank für einen Service, der ein Objekt von einem Modell in ein anderes transformiert, und einen Key-Value-Store für deklarativ verwaltete Services, alle als Teile eines einzigen Super-Services. Vor ein paar Jahren hätte ich von einem solchen Design nicht einmal geträumt, aber tatsächlich finde ich es ziemlich befreiend. Ich kann mir einfach das richtige Werkzeug für den Job aussuchen.
Das gilt für Datenbanktechnologien, aber auch für Middleware-Technologien, für rechenintensive Technologien wie Machine Learning und für Datenverteilungs-Pipelines. Wenn ich sie einfach als Service konsumieren kann und die Barriere für die Annahme niedrig ist, gibt es keine wirklichen Nachteile der Heterogenität. Ich brauche nur die richtigen Leute. Das ist noch immer eine Selbstverständlichkeit. Und natürlich kann das Team, das ich beschäftige, die Design-Entscheidungen einschränken, die ich treffe.
Die Cloud nutzen
Die größte architektonische Schuld liegt heute darin, dass moderne Cloud-Native-Prinzipien – Container, Orchestrierung, Verteilung, CI/CD, noSQL, Data Mesh, Service Mesh – nicht genutzt werden und die Macht von Machine-Learning-Techniken für immer intelligentere Lösungen entfesselt wird. Und beides ist eng miteinander verbunden. Die Cloud bietet die Möglichkeit, in einem bisher nicht gekannten Umfang und Tempo zu operieren und Big Data zu generieren, die sich in Echtzeit auswerten lassen. Ich weiß, das ist für verschiedene Organisationen in verschiedenen Märkten ganz unterschiedlich, aber ich habe noch keine Organisation kennengelernt, die nicht ein großes Potenzial hat, von diesen Technologien zu profitieren.
Trägheit
Das bringt mich zu einer anderen Art von Schulden. Trägheit. Es ist eine bekannte Tatsache, dass Menschen dazu neigen, Dinge so zu tun, wie sie sie immer getan haben. Sie denken nicht darüber nach, eine relationale Datenbank zu benutzen. Vielleicht denken sie über die Verwendung eines Containers nach, aber nur als eine leichtgewichtige virtuelle Maschine, an die sie gewöhnt sind. Sie könnten in Erwägung ziehen, eine API bereitzustellen, aber nur als eine Hülle um eine bestehende Schnittstelle. Während Trägheit scheinbar nicht schaden kann, kann sie auf lange Sicht teuer werden. In gewisser Weise gilt: Je technikfeindlicher du bist, desto mehr Potenzial kannst du freisetzen.
Begleiche Architectural Debt
Ich glaube, dass Softwarearchitekten den Weg zur Begleichung der Architectural Debt vorgeben sollten. Ich glaube, dass Softwarearchitekten die ersten sein sollten, die das verborgene Potenzial der Cloud aufdecken. Meiner Meinung nach sollten Softwarearchitekten über Paradigmenwechsel Bescheid wissen und verstehen, dass verschiedene Kompromisse heute Sinn machen. Unabhängig davon, ob du es quantifizieren kannst oder nicht, wird die Modernisierung einen Wert bringen.
Möglicherweise bist du nicht die Art von Person, die an der vordersten Front der aufstrebenden Technologien kämpft. Das ist okay. Aber es bedeutet nicht, dass du dich einfach zurücklehnen kannst. Es bedeutet nur, dass dein Timing anders ist. Um mein Timing zu verbessern, kategorisiere ich neue Technologien gerne in drei Prioritätsgruppen:
- Zeit zum Starren, Technologieeinführung irgendwann aus. Verschaffe dir ein Verständnis für die potenziellen Auswirkungen.
- Zeit, um aufmerksam zu sein, Technologie, die reifen wird oder machbar wird. Mach dich bereit, die Technologie zu bewerten.
- Zeit zur Vorbereitung. Mach dich bereit, die Technologie zu übernehmen.
Ich kann die Praxis des aktiven Managements deines Technologie-Radars sehr empfehlen. Dieses simple Werkzeug wird dir helfen, den Überblick über die Veränderungen zu behalten – und somit als Softwarearchitekt relevant zu bleiben.
Wenn du es also noch nicht getan hast, investiere etwas Zeit, um dich mit dem neuen Paradigma vertraut zu machen. Studiere die Design Principles for Cloud Native Applications. Denke es durch. Lies es dann noch einmal. Tauche ein bisschen tiefer ein. Es ist eine radikal andere Denkweise, die bessere Lösungen in einem schnelleren Tempo und zu geringeren Kosten verspricht. Es ist weithin bewährt. Es ist solide. Es gibt keine Alternative auf meinem Radar. Und Du kannst auch davon profitieren.
Aufruf zum Handeln
An diesem Punkt musst du eine grundlegende Vorstellung von deiner Schuldenposition haben. Vielleicht kannst du sie nicht in Geldbeträgen beziffern, aber es steht unbestreitbar eine Menge Geld auf dem Spiel. Es ist an der Zeit, deine Architectural Debt zu begleichen. Beginne ein Experiment und baue Traktion auf. Höre auf, die gleichen Fehler immer wieder zu machen. Lass das alte Paradigma hinter dir, wenn du neue Lösungen entwickelst. Lerne, wachse und gedeihe.
Du musst dich nicht allein auf die Reise begeben. Wir sind hier, um dir auf deinem Weg zu helfen. Wir wissen, wie man mikroskopiert. Jetzt los!
Unter dem Mikroskop ist eine Blogserie von unbestimmter Länge, die sich auf das Design von belastbaren, verteilten, cloud-nativen Architekturen konzentriert. In jeder Ausgabe werden wir ein anderes Licht auf die Mikrosphäre werfen. Lies auch die anderen Blogs dieser Reihe.
