Was haben Altherrenmannschaften und Replatforming gemeinsam?

Was haben eine Altherrenmannschaft und Legacy-Architektur gemeinsam? Je älter desto schwerer!

Was bedeutet das konkret und an welchen Stellen kann man ansetzen?

Replatforming, Refactoring, Architekturwechsel: Diese und vergleichbare Maßnahmen dienen dem grundsätzlichen Zweck, Komplexität besser handhaben zu können. Motivation ist, negative Effekte in Bezug auf Kosten, Risiko und Wartbarkeit zu minimieren.

Im Allgemeinen löst sich Komplexität nicht einfach auf. Sie kann lediglich von einem schwer zu steuernden Bereich in einen leicht zu steuernden Bereich verlagert werden. Was nicht unbedingt eine Verbesserung bedeuten muss, etwa dann, wenn die Einschätzung falsch ist, welcher Bereich nun leichter zu bedienen ist. Schauen wir uns das in zwei Beispielen aus unterschiedlichen Ebenen und Zeiten einmal an:

Unit-Tests

Softwarefehler werden meist sehr spät entdeckt, da die Auswirkung von Änderungen schwer abschätzbar ist. Lösung: Unit-Tests schreiben und die Software testbar implementieren.

Die Komplexität des Testens auf QA-Level (es muss Infrastruktur bereitgestellt werden und die Ursache eines Fehlers muss zuerst untersucht werden) wird an den Anfang der Produktionskette verlegt. Programmierer*innen wissen meist am besten, welche Stellen gut und häufig getestet werden müssen. Gefundene Fehler resultieren in neuen Unit-Tests.

Unter bestimmten Bedingungen funktioniert diese bewährte Vorgehensweise jedoch nicht:

• Entwickler*innen sind voll ausgelastet mit neuen Features
• bei engen Zeitplänen und Fear-Driven-Development
• QA testet hauptsächlich manuell
• Testpläne sind wichtiger als automatisierte Tests

Durch Verlagerung der Komplexität werden die bekannten, negativen Effekte nicht weiter minimiert. Im schlechtesten Fall werden sie sogar vergrößert. Dann würde Komplexität von einem Bereich, in dem sie schwer steuerbar ist, in einen Bereich verschoben, in dem sie auch nicht gut handzuhaben ist. Wichtig bei einer Verlagerung der Komplexität ist daher zuerst zu prüfen, ob der Zielbereich tatsächlich Stärken aufweist oder ob dort nur Stärken erworben werden sollen.

Der Application-Server

Bestimmte querschnittliche Funktionalität (Connection-Pooling, Datenbankverbindung, Webserverfunktionalität, …) soll für alle Entwickler*innen bereitgestellt werden, damit die damit verbundene Funktionalität nicht immer wieder neu und anders gelöst wird. Die Komplexität wird aus dem Quellcode in die Infrastruktur und das Operating verschoben.

Erfolgsrelevant für dieses Vorgehen sind:

• ein Team, welches die fraglichen Application-Server geeignet verwaltet
• Entwickler*innen, die verstehen, welche Funktionalität durch welchen Bereich des Technologie-Stacks bereitgestellt wird
• Verständnis für das korrekte Einbinden der Funktionalität des Application-Servers

Ansonsten wird regelmäßig querschnittliche Funktionalität immer noch von den Entwickler*innen gelöst und die Application-Server müssen verwaltet werden.

Das Auftreten dieses Phänomens („Application Server sind viel zu komplex“) hat unter anderem den Microservices den Weg geebnet.

Microservices

Softwareentwicklung und Paketierung der Artefakte ist generell komplex. Software wird daher nur in kleinen, beherrschbaren Services bereitgestellt und über Container ausgeliefert. Die Komplexität landet somit in der Infrastruktur.

Ein guter Plan für alle, die Herausforderungen in der Entwicklung suchen und eine gut aufgestellte Infrastruktur haben. Ein nicht so guter Plan allerdings, wenn gute Entwickler*innen fehlen und Defizite in der Infrastruktur vorkommen.

Wenn es ganz schlimm kommt, wird Komplexität aus einem Bereich, wo sie nur mühsam beherrschbar ist, in einen Bereich verschoben, in dem sie gar nicht beherrschbar ist. Hinzu kommt, dass mangelnde Beherrschbarkeit sich oft nur schleichend manifestiert: Fehlende Automatisierung etwa fällt nicht bei den ersten Einzel-Deployments auf, sondern erst im Laufe der Zeit, bei stetig wachsenden Anforderungen.

Halbzeit-Fazit

Architektur und verwendete Plattform müssen einem ständigen Wechsel der Anforderungen und der vorhandenen Technologien genügen. Eine regelmäßige Prüfung, ob andere Patterns oder Technologien aktuelle Herausforderungen besser adressieren, ist nötig

Wichtig ist eine gewissenhafte Prüfung, ob das Zielbild – auch wenn es einfacher aussieht – tatsächlich mit den vorhandenen Kompetenzen und Ressourcen einfacher zu managen ist oder zumindest in der Zukunft einfacher zu managen sein wird. Verantwortungsvolle Architektur kann auch darin bestehen (begründet) einen Trend auszulassen.

Eine Nichtbeachtung dieser Prüfung führt schnell dazu, dass man in der neuen Architektur die Nachteile von Ist- und Soll-Zustand vereinigt.

Umbau der Architektur, bzw. der Mannschaft: Wie sieht die weitere Taktik aus?

Wo sind jetzt unsere Alten Herren aus dem Sportverein? Ich selbst habe in einer Mannschaft gespielt, die erfolgreich auf hohem Niveau gespielt hat. Leider war abzusehen (wenn man es denn sehen wollte), dass der Erfolg nicht von Dauer sein würde:

• das Durchschnittsalter der Mannschaft war sehr hoch – und wurde jedes Jahr höher
• Spieltaktiken haben sich weiterentwickelt und wurden nicht adaptiert
• Neueinsteiger schrecken hohe Erwartungen und rauer Umgangston ab

Gehen wir an dieser Stelle einmal nicht weiter ins Detail. Betrachten wir lieber die Ist-Situation: „Der Mannschaft geht es momentan gut“. Ein kluger Manager oder Trainer plant natürlich über die aktuelle Saison heraus. Mittel- und langfristig steht unsere Mannschaft nicht mehr so gut da. Nach Betrachtung der Ist-Situation steht die Frage: „Wo wollen wir hin?“. Einfachste Antwort ist natürlich: „Alles lassen, wie es ist“ und damit zufrieden sein, wenn es ein bis zwei Ligen runter geht.

Für Unternehmen ist das definitiv keine Option. Genau wie in unserer Altherrenmannschaft werden bewährte Methoden entwickelt. Jeder weiß, was zu tun ist, aber es ist absehbar, dass ohne weitergreifende Änderung die Leistungsfähigkeit im Vergleich zum Mitbewerber (im Sport etwa die junge Mannschaft im Aufbruch) sinken wird.  Irgendwann sinken die Chancen im direkten Wettkampf zu gewinnen erheblich.

Nehmen wir an, dass die Mannschaft sich auf jeden Fall verjüngen möchte. Auf dem Weg dorthin müssen einige Punkte beachtet werden:

• Wie kommen wir überhaupt an neue Spieler (was sind unsere Anforderungen)?
• Wie können die „alten Hasen“ weiterhin ihre wertvolle Erfahrung einbringen?
• Mit jungen Spielern vergrößert sich die Mannschaft – was heißt das für die Ersatzbank?

Bezogen auf das Replatforming sind wir nun voll im Changemanagement, ohne auch nur einmal über konkrete Technik gesprochen zu haben. Das ist auch gut so, denn die ersten Fragen sollten sein: „Wo stehen wir?“, „wo wollen wir hin (und was versprechen wir uns davon)?“ und „was bedeutet das für die Stammspieler?“

Ihr seht, die Begriffe vermischen sich schnell.

Insbesondere die beiden ersten Fragen führen zu einer Ziel-/Wunscharchitektur. Diese hilft bei der Entwicklung einer Zielstrategie („Wollen wir in Zukunft wirklich auf Schnelligkeit setzen, wenn alle unsere Stammspieler eher langsam aber extrem kräftig sind?“). Hier kommen dann auch konkrete Tools und Techniken vor.

Die Reihenfolge im Vorgehen ist wichtig – es kommt durchaus vor, dass die Toolauswahl an erster Stelle steht („Wir machen was mit Kubernetes und Docker“). Am Spielerstammtisch führt dieses Vorgehen zu skurrilen Gesprächen:

„Wir müssen konditionell so gut werden wie die Beispielshausener“

„Manfred, das Durchschnittsalter unserer Mannschaft liegt knapp unter 50. Da werden wir höchstens noch schneller müde!“

„Dann machen wir ab jetzt eben zu Beginn jeden Trainings 20 Minuten Konditionstraining.“

Falls sich die Idee durchsetzt, bleibt der Trainingsplatz künftig in den ersten 20 Minuten eher leer. Falls ab und zu doch mal ein lauffreudiger Spieler vorbeischaut, verliert dieser schnell die Lust. Denn nur mit „Stehgeigern“ kann er seine Vorteile nicht ausspielen.

Und hier kommen wir zur Ausgangsfrage: „Wohin verlagere ich meine Komplexität?“ Das hängt eng mit der Frage zusammen: „Wie baue ich die Abteilung / mein Unternehmen um, damit die verlagerte Komplexität besser gehandhabt werden kann als vorher?“

Wie dargestellt, ist die Frage nach der konkreten Technik eher nachgelagert. Wichtig sind an erster Stelle die Analyse des Ist-Zustands, ein Soll-Zustand, der realistisch nah am Ist-Zustand liegt, und natürlich eine Planung für den Übergang.

Das klingt überraschend offensichtlich, dennoch sind Altherrenmannschaften, die sich wundern, warum sie dauerhaft keine schnellen neuen Spieler bekommen, eher die Regel als die Ausnahme. Häufigste Ausrede: „Der macht ja immer alles allein.“ So ist zumindest die Schuldfrage eindeutig geklärt.