Verwalten von technischen Architekturschulden

Wenn ich an technische Schulden denke, erinnere ich mich noch an die erste Anwendung, die ich erstellt habe und die mir die Konsequenzen einer ungeeigneten Architektur vor Augen führte. Das geschah Ende der 1990er Jahre, als ich meine ersten Schritte als Berater machte.

Der Kunde hatte die Nutzung der Lotus Notes- Plattform angefragt, um ein Beschaffungssystem für seine Kunden aufzubauen. Mithilfe des Lotus Notes-Clients und einer benutzerdefinierten Anwendung konnten Endbenutzer Anfragen stellen, die von der Anwendung verfolgt und vom Team des Produktbesitzers erfüllt wurden. Theoretisch war das eine wirklich coole Idee – insbesondere, da webbasierte Anwendungen noch nicht weit verbreitet waren und jeder täglich Lotus Notes verwendete.

Das Hauptproblem war, dass die Daten sehr relational angelegt waren – und Lotus Notes war keine relationale Datenbank. Das Design der Lösung erforderte Schemaverwaltung in jedem Lotus Notes-Dokument und stützte sich auf eine Reihe von Feldern mit mehreren Werten, um die Beziehungen zwischen Datenattributen zu simulieren. Es war ein Chaos.

Ein Großteil der Logik in der Lotus Notes-Anwendung wäre nicht erforderlich gewesen, wenn eine bessere Plattform empfohlen worden wäre. Der Quellcode war kompliziert zu unterstützen. Verbesserungen der Datenstruktur führten zu einer umfassenden Umgestaltung des zugrunde liegenden Codes – ganz zu schweigen von der Ausführung serverbasierter Jobs zur Konvertierung der vorhandenen Daten. Von dem Aufwand, der hinter der Berichterstellung steckt, will ich gar nicht erst anfangen.

Seit Beginn meiner Karriere habe ich mich darauf konzentriert, eine Lösung zu finden, die der Kunde wollte, anstatt zu versuchen, eine bessere Lösung anzubieten. Das war sicherlich eine Lektion, die ich zu Beginn meiner Karriere gelernt habe, aber in den Jahren seit diesem Projekt wurde mir klar, dass die Folgen technischer Architekturschulden eine bedauerliche Realität sind, mit der wir alle konfrontiert sind.

Lassen Sie uns das Konzept der technischen Architekturschulden auf einer Makroebene etwas genauer untersuchen.

Architektonische technische Schulden (ATD)

Die Architectural Technical Debt (ATD) Library der Carnegie Mellon University bietet die folgende Definition von ATD:

Bei architektonischen technischen Schulden handelt es sich um einen Entwurfs- oder Konstruktionsansatz, der kurzfristig zweckmäßig ist, aber einen technischen Kontext schafft, in dem dieselben Arbeiten eine architektonische Überarbeitung erfordern und später mehr kostet, als es jetzt kosten würde (einschließlich höherer Kosten im Laufe der Zeit).

In „Quick Answer: How to Manage Architecture Technical Debt“ (veröffentlicht am 22.09.2023) definiert die Gartner Group ATD wie folgt:

Unter technischer Architekturschuld versteht man jene Art von technischer Schuld, die durch Architekturabweichungen, suboptimale Architekturentscheidungen, Verstöße gegen die definierte Zielproduktarchitektur und etablierte branchenübliche bewährte Architekturpraktiken sowie Architekturkompromisse für eine schnellere Softwarebereitstellung entsteht.

In beiden Fällen können Vorteile, die oft kurzfristige Freude hervorrufen, mit langfristigen Herausforderungen einhergehen. Dies ähnelt meinem Lotus Notes-Beispiel, das ich in der Einleitung erwähnt habe.

Um die Sache noch komplizierter zu machen, fehlten im Vergleich zu anderen Aspekten der Softwareentwicklung Werkzeuge zur Identifizierung und Verwaltung technischer Schulden in der Softwarearchitektur:

Für Codequalität, Beobachtbarkeit und SCA gibt es bewährte Tools wie Sonarqube, Datadog, New Relic, GitHub und Snyk. Der Bereich Softwarearchitektur hinkt jedoch hinterher und verfügt nicht über bewährte Lösungen.

Dies ist bedauerlich, da ATD durchweg die größte – und schädlichste – Art von technischer Schuld ist, wie aus der 2015 von Carnegie Mellon veröffentlichten Studie „ Measure It? Manage It? Ignore It? Software Practitioners and Technical Debt “ hervorgeht.

Die folgende Abbildung fasst Abbildung 4 dieses Berichts zusammen und kommt zu dem Schluss, dass die Ursache für technische Schulden eindeutig in der Wahl einer schlechten Architektur liegt.

Wenn ATD nicht kontrolliert wird, kann es mit der Zeit immer schneller wachsen, wie dieses einfache Beispiel zeigt:

Ohne Milderung wird die Architekturschuld für die zugrunde liegende Lösung, die gemessen wird, irgendwann den Bruchpunkt erreichen.

Umgang mit ATD

Bevor wir ATD in den Griff bekommen können, müssen wir zunächst das Problem verstehen. Desmond Tutu sagte einst weise: „Es gibt nur eine Möglichkeit, einen Elefanten zu essen: Bissen für Bissen.“

Der Shift-Left-Ansatz umfasst das Konzept, einen bestimmten Aspekt eher an den Anfang als an das Ende eines Lebenszyklus zu verschieben. Dieses Konzept gewann an Popularität beim Shift-Left-Ansatz für Tests, bei dem die Testphase in einen Teil des Entwicklungsprozesses verschoben wurde und nicht als separates Ereignis, das nach Abschluss der Entwicklung abgeschlossen werden musste.

Shift-Left kann beim Management von ATD auf zwei verschiedene Arten implementiert werden:

• Shift-Left für Resilienz – Identifizieren von Quellen, die sich auf die Resilienz auswirken, und anschließendes Beheben dieser Quellen, bevor sie sich in der Leistung niederschlagen.
• Shift-Left für Sicherheit – Erkennen und Mindern Sie Sicherheitsprobleme während des Entwicklungslebenszyklus.

Ebenso wie die Shift-Left-Methode beim Testen verringert eine vorrangige Konzentration auf Belastbarkeit und Sicherheit während der Entwicklungsphase das Potenzial für unerwartete Vorfälle.

Architektonische Beobachtbarkeit

Durch die architektonische Beobachtbarkeit können Entwicklungsteams architektonische Abweichungen innerhalb ihrer Dienste schrittweise auf Makroebene beheben. Tatsächlich bezifferte das Wall Street Journal die Kosten für die Behebung technischer Schulden Anfang dieses Jahres in dem Artikel „Das unsichtbare 1,52-Billionen-Dollar-Problem: Schwerfällige alte Software“ auf 1,52 Billionen Dollar.

Um erfolgreich zu sein, muss die technische Leitung vollständig mit den folgenden Unternehmenszielen übereinstimmen:

• Resilienz – sich schnell von unerwarteten Vorfällen erholen.
• Skalierbarkeit – um entsprechend der Kundennachfrage skalieren zu können.
• Geschwindigkeit – Bereitstellung von Funktionen und Verbesserungen im Einklang mit den Produkterwartungen.
• Cloud-Eignung – Umwandlung von Legacy-Lösungen in effiziente Cloud-native Serviceangebote.

Ich habe vor Kurzem die KI-gesteuerte Architektur-Beobachtungsplattform von vFunction entdeckt, die sich auf die folgenden Ergebnisse konzentriert:

• Entdecken Sie die tatsächliche Architektur von Lösungen durch statische und dynamische Analyse.
• Verhindern Sie Architekturabweichungen durch Echtzeitansichten der Dienstentwicklung.
• Erhöhen Sie die Ausfallsicherheit von Anwendungen durch die Beseitigung unnötiger Abhängigkeiten und Verbesserungen zwischen Anwendungsdomänen und den zugehörigen Ressourcen.
• Verwalten und beheben Sie technische Schulden durch KI-gesteuerte Beobachtbarkeit.

Darüber hinaus bietet die vFunction-Plattform den Nebeneffekt, dass sie einen Migrationspfad zur Umstellung von Monolithen auf Cloud-native-Lösungen bereitstellt. Sobald Teams ihre Plattformen modernisiert haben, können sie diese kontinuierlich auf anhaltende Abweichungen überwachen. Wenn Unternehmen bereits über Microservices verfügen, können sie vFunction verwenden, um die Komplexität verteilter Anwendungen zu erkennen und Abhängigkeiten zu beheben, die sich auf die Belastbarkeit und Skalierbarkeit auswirken. In beiden Fällen können Entwicklungsteams nach der Implementierung ATD deutlich eindämmen, bevor sie den Bruchpunkt erreichen.

In der obigen Abbildung können Entwicklungsteams im Rahmen jeder Version technische Schulden abbauen, da die vFunction-Plattform implementiert ist und ein zugrunde liegender Shift-Left-Ansatz zum Einsatz kommt.

Abschluss

Meine Leser erinnern sich vielleicht, dass ich mich auf das folgende Leitbild konzentriert habe, das meiner Meinung nach auf jeden IT-Experten zutrifft:

„Konzentrieren Sie sich auf die Bereitstellung von Features/Funktionalitäten, die den Wert Ihres geistigen Eigentums steigern. Nutzen Sie Frameworks, Produkte und Services für alles andere.“ - J. Vester

Die vFunction-Plattform entspricht meinem Leitbild, indem sie Entwicklungsteams dabei unterstützt, einen Shift-Left-Ansatz für die Belastbarkeit und Sicherheit ihrer Dienste auf Makroebene zu verfolgen. Dies ist ein wichtiger Unterschied, denn ohne solche Tools werden Teams wahrscheinlich auf Mikroebene abmildern und technische Schulden beheben, die aus organisatorischer Sicht nicht wirklich wichtig sind.

Wenn ich an diese Anwendung zurückdenke, die mir die Herausforderungen der technischen Schulden vor Augen geführt hat, muss ich unweigerlich daran denken, dass diese Lösung mit jeder eingeführten Funktion mehr Probleme als Vorteile mit sich brachte. Sicherlich hätte die Verwendung von Shift-Left allein für die Ausfallsicherheit dazu beigetragen, Probleme mit der zugrunde liegenden Architektur an einem Punkt aufzudecken, an dem die Kosten für die Prüfung von Alternativen vertretbar gewesen wären.

Wenn Sie mehr über die vFunction-Lösung erfahren möchten, können Sie hier mehr darüber lesen.

Habt einen richtig schönen Tag!