Technische Schulden skalieren: So vermeidest du den Bankrott

Die Kreuzung ist das Gleiche, was jedes erfolgreiche Softwareunternehmen durchmachen muss. Es wurde kein schlechtes MVP entwickelt, das den Produkt-Markt-Fit-Test bestanden hat, sondern ein vielschichtiges System, das Tausende oder Millionen von Nutzern bedient. Aber es gibt etwas, das unter der Oberfläche liegt. Neue Releases kommen nur langsam voran. Wochen werden für die Entwicklung einfacher Änderungen aufgewendet. Die Rate, mit der Fehler behoben werden, ist höher als die, mit der alte Probleme korrigiert werden. Die Codebasis führt dazu, dass Ingenieure mehr Zeit damit verbringen, zu kämpfen, anstatt neue Funktionen zu entwickeln. Dieses Szenario spielt sich im Technologiebereich erschreckend häufig ab. Unternehmen, die auf dem besten Weg waren, zu Giganten zu werden, werden von ihrem eigenen anfänglichen Erfolg erdrückt und müssen entweder in einem Zustand selbstgefälliger Stagnation weitermachen oder ihre Entwicklung mit kostspieligen Umstrukturierungsmaßnahmen neu in Angriff nehmen. Schuld daran sind nicht etwa schlechte Entwickler oder fehlende Ressourcen. Vielmehr liegt der Ursprung in grundlegenden architektonischen Entscheidungen, die in den ersten entscheidenden Monaten getroffen wurden, als die schnelle Markteinführung wichtiger war als die langfristige Wartbarkeit. Zu wissen, wie sich technische Entscheidungen über einen längeren Zeitraum auswirken, ist echt wichtig für jeden, der eine wachsende Tech-Firma leitet. Die Entscheidungen, die heute getroffen werden, können das Wachstum in Zukunft entweder beschleunigen oder unsichtbare Fesseln schaffen, die alle anderen Initiativen behindern. Der Unterschied zwischen Unternehmen, die wachsen, und solchen, die scheitern, liegt oft darin, wie klug die Architektur ist und ob sie zum richtigen Zeitpunkt eingesetzt wird.

Zwischen Prototyp und produktionsreifer Software gibt es Abkürzungen, die eigentlich nur für kurze Zeit gedacht sind, aber eine sehr lange Amortisationszeit haben. In der Anfangsphase konzentriert sich die Entwicklung natürlich eher auf schnelles Prototyping und direkte Funktionalität als auf abstrakte Themen wie Modularität oder Erweiterbarkeit. Diese Methode ist total sinnvoll, wenn das Hauptziel darin besteht, Hypothesen zu bestätigen und Marktchancen zu nutzen, bevor die Konkurrenz einsteigt. Aber solche taktischen Erfolge können zu strategischen Schwächen führen. Monolithische Architekturen, die bei kleinen Gruppen gut funktionieren, werden zu Engpässen, wenn Unternehmen wachsen. Datenbankschemata, die anfangs optimal sind, lassen sich nur schwer ändern, um neue Funktionen zu unterstützen. Hunderte von Benutzerauthentifizierungssystemen brechen unter Tausenden zusammen. Integrationsmuster, die bei wenigen Drittanbieterdiensten gut funktionierten, werden aufgrund der Größe des Ökosystems unkontrollierbar.

Eine ineffiziente API kann die aktuelle Traffic-Last zwar problemlos bewältigen, bricht aber komplett zusammen, wenn die Auslastung doppelt so hoch wird. Eine engmaschige Codebasis ermöglicht zwar anfangs eine schnelle Funktionsentwicklung, aber mit zunehmender Teamgröße kann die parallele Entwicklung noch schwieriger werden. Unternehmen neigen oft dazu, diese Symptome als vorübergehende Wachstumsschmerzen zu sehen, die nicht systemisch sind und keine strukturellen Korrekturen brauchen. Die Unternehmensleitung könnte denken, dass mehr Ingenieure den Entwicklungsprozess beschleunigen, nur um dann festzustellen, dass Koordinationsaufwand und Code-Konflikte die Entwicklung tatsächlich verlangsamen. Probleme, die bei der Leistung auftreten, werden durch eine Erhöhung der Serverleistung gelöst, anstatt grundlegende Effizienzsteigerungen vorzunehmen. Sicherheitsprobleme werden mit einer Punktlösung statt mit einer System-Site-Tour gelöst. Die wirtschaftlichen Auswirkungen und der Umfang gehen weit über die Produktivität im Ingenieurwesen hinaus. Die Kundenerfahrung wird beeinträchtigt, weil die Systeme weniger stabil sind und langsamer reagieren. Wenn die Plattform potenzielle Unternehmenskunden nicht bedienen kann, gehen Verkaufschancen verloren. Die Wettbewerbsvorteile werden geschmälert, weil die Funktionen nur langsam weiterentwickelt werden. Das macht die Personalbeschaffung schwieriger, weil Ingenieure nicht in Unternehmen arbeiten wollen, die technische Probleme haben.

Modulare Architektur aufbauen

Um eine Architektur effektiv zu entwickeln, musst du die Prinzipien kennen, die zu einem guten Design beitragen, sowie die praktischen Einschränkungen, die bei der Entscheidung über die Umsetzung berücksichtigt werden müssen. Die Grundlage bildet die Modularität und die Trennung von Aufgabenbereichen. Entwickelte Systeme strukturieren die Funktionalität in diskreten Elementen, definierten Schnittstellen und Verantwortlichkeiten. Eine solche Strategie ermöglicht es Teams, einzelne Teile zu erstellen, zu ändern oder zu ersetzen, ohne das gesamte System zu stören. Serviceorientierte Architekturen sind ein gutes Beispiel für dieses Konzept im Allgemeinen. Anstatt monolithische Anwendungen mit allen Funktionen unter Verwendung derselben Codebasis zu entwickeln und auf ähnliche Weise bereitzustellen, können Unternehmen Systeme in dedizierte Dienste aufteilen, die über konsistente APIs interagieren. Dienste sind unabhängig und können von verschiedenen Teams gleichzeitig entwickelt, getestet und bereitgestellt werden, ohne sich gegenseitig zu beeinträchtigen.

Der Trick besteht darin, klare Verträge zwischen den verschiedenen Teilen des Systems zu definieren und keine enge Kopplung zu haben, die dazu führt, dass sich Änderungen in alle Richtungen durch die gesamte Codebasis ausbreiten.

Überlegungen zur Datenarchitektur

Besonders wichtig ist die Datenarchitektur, weil solche Entscheidungen bei Datenbanken am teuersten sein können, wenn man sie rückgängig machen will. Das Schema zur Optimierung von Anwendungsfällen kann bei sich ändernden Anforderungen ein echtes Problem sein. Erfolgreiche Unternehmen setzen auf Datenmodelle, die flexibel genug sind, um Wachstum zu unterstützen, ohne dass man alles komplett migrieren muss. Das könnte so aussehen:

• Wähle je nach Bedarf Dokumentendatenbanken statt relationaler Datenbanken.
• Nutze eine Strategie zur Datenversionierung.
• Erstelle keine APIs, die die zugrunde liegenden Speicherimplementierungen verstecken.

Ausgleich zwischen aktuellen und zukünftigen Anforderungen

Skalierbarkeitsanforderungen sollten ein Gleichgewicht zwischen den aktuellen Anforderungen und den zukünftigen Möglichkeiten schaffen. Wenn Lösungen für Probleme, die vielleicht nie auftreten werden, überdimensioniert sind, werden Ressourcen verschwendet und die Dinge unnötig kompliziert gemacht. Lösungen, die für das vorhersehbare Wachstum unterdimensioniert sind, verursachen technische Schulden, die exponentiell wachsen. Die beste Lösung besteht darin, Skalierungsengpässe frühzeitig zu erkennen und eine Architektur einzusetzen, die sich unter Last reibungslos skalieren lässt.

Beobachtbarkeit und Sicherheit

Beobachtbarkeit ist ein weiterer wichtiger architektonischer Faktor, der in der Anfangsphase der Entwicklung oft nicht berücksichtigt wird. Jedes System, dem es an gründlichen Protokollierungs-, Überwachungs- und Debugging-Funktionen mangelt, wird mit zunehmender Komplexität schwieriger zu warten. Es ist viel kostengünstiger, die Beobachtbarkeit von Anfang an in die Architektur zu integrieren, als dies nachträglich zu tun, und die dabei gewonnenen Erfahrungen sind für die Optimierung und Fehlerbehebung von unschätzbarem Wert. Das Gleiche gilt für die Sicherheitsarchitektur, die auch eine frühe Investition ist. Durch die Einführung der Basiskomponenten für Authentifizierung, Autorisierung und Datenschutz können Funktionen schnell entwickelt werden, ohne dass Sicherheitsrisiken entstehen. Andererseits ist der Ansatz, Sicherheit erst nachträglich zu berücksichtigen, in Fällen, in denen Compliance-Anforderungen oder Bedrohungsmodelle geändert werden, mit hohen Kosten für die Neugestaltung verbunden.

Technische Entscheidungen

Firmen, die architektonische Fallstricke vermeiden wollen, sollten technische Entscheidungsmodelle einführen, die kurzfristige Geschwindigkeit und langfristige Ausdauer gleichmäßig berücksichtigen. Dazu gehören:

• Entwicklung von Verfahren zur Überprüfung der Architektur bei wichtigen technischen Entscheidungen
• Kompromisse dokumentieren
• Regelmäßige Bewertung der entstandenen technischen Schulden im Hinblick auf die geschäftlichen Prioritäten

Testen und Integration

Investitionen in automatisierte Tests und kontinuierliche Integration zahlen sich auch insofern aus, als sie es ermöglichen, mit Zuversicht Umgestaltungen vorzunehmen und in die Architektur zu investieren. Wenn Teams in der Lage sind, Änderungen schnell zu bestätigen, ist die Wahrscheinlichkeit höher, dass sie proaktive Anpassungen vornehmen, anstatt den Wartungsprozess auf unbestimmte Zeit zu verschieben. Eine parallele Entwicklung wird auch durch umfassende Testsuiten ermöglicht, die Probleme bei der Integration frühzeitig erkennen.

Codeüberprüfung und Wissensaustausch

Bei der Überprüfung von Codes musst du sowohl die Auswirkungen auf die Architektur als auch die korrekte Funktion checken. Wenn du dich nur auf die unmittelbare Funktionalität konzentrierst, kannst du strukturelle Probleme nicht erkennen und beheben, bevor sie sich festsetzen. Die Qualität der Entscheidungen im gesamten Unternehmen kannst du verbessern, indem du Ingenieure darin schult, architektonische Kompromisse zu erkennen und zu kommunizieren.

Die regelmäßigen technischen Präsentationen und Architekturmeetings helfen dabei, dass alle im Rahmen der wachsenden Entwicklerteams auf dem gleichen Stand bleiben.

Regelmäßige Architekturprüfungen

Regelmäßige Architekturprüfungen bieten die Möglichkeit, etwas Abstand vom täglichen Entwicklungsgeschehen zu gewinnen und den Zustand der Systeme in einem größeren Maßstab zu analysieren. Bei solchen Überprüfungen sollte festgestellt werden, wo technische Schulden entstanden sind, ob die aktuellen Architekturen den Anforderungen des Unternehmens entsprechen und was getan werden kann, um sie zu verbessern, damit sich die Investitionen in die Technik optimal auszahlen.

Der Prozess nach dem Start-up bis zur Skalierung ist zwangsläufig mit einer Weiterentwicklung der Architektur verbunden, muss aber nicht unbedingt mit kostspieligen Neuprogrammierungen oder sogar einer Stagnation in der Entwicklung einhergehen. Unternehmen, die von Anfang an kluge Architekturentscheidungen treffen, sind besser in der Lage, Nachhaltigkeit zu erreichen, während Unternehmen, die strukturelle Aspekte übersehen, in der Regel durch ihre eigenen Erfolge ins Hintertreffen geraten. Die meisten Tech-Firmen, die erfolgreiche Modelle haben, sehen Architektur nicht als eine einmalige Entscheidung, sondern als einen fortlaufenden Prozess. Sie entwickeln Systeme, die sich gut weiterentwickeln lassen, investieren in die Tools und Prozesse, die für sichere Änderungen nötig sind, und haben das Architekturwissen, um gute Kompromisse zu finden, wenn es wirklich darauf ankommt. Die Kosten für architektonische Disziplin sind nichts im Vergleich zu den Kosten einer technischen Insolvenz. Durch die Erkenntnis, dass Entscheidungen, die in einer frühen Phase getroffen werden, sich mit der Zeit vervielfachen, und durch die konsequente Anwendung bewährter Architekturprinzipien werden Unternehmen in der Lage sein, Software zu entwickeln, die ihren Erfolg langfristig nur steigern wird. Die Frage ist nicht, ob architektonische Probleme auftreten werden, sondern ob sie bemerkt und behoben werden, bevor sie sich zu scheinbar unüberwindbaren Problemen entwickeln.