Softwareprojekte verlaufen selten genau nach Plan. Neue Anforderungen, technische Abhängigkeiten und unerwartete Schwierigkeiten erfordern Lösungen, die nicht nur technisch funktionieren, sondern auch unter den tatsächlichen Projektbedingungen sinnvoll sind.

Die folgenden drei Geschichten zeigen, wie ich solche Herausforderungen in unterschiedlichen Branchen angegangen bin – und welche Erkenntnisse sich daraus gewinnen lassen.

Wie lässt sich ein System zuverlässig erproben, wenn die Systeme der Projektpartner noch gar nicht fertig sind?

Ziel: Virtuelle Warteschlangen für Ladesäulen

Für einen Automobilhersteller sollte ein Prototyp entwickelt werden, mit dem sich Fahrer von Elektroautos über eine App virtuell in eine Warteschlange für eine besetzte Ladesäule einreihen können.

Dafür musste unser Backend mit einem externen Vermittlungssystem kommunizieren. Dieses wiederum war mit einem weiteren System verbunden, das die Ladesäulen bereitstellte und verwaltete.

Der Prototyp sollte zeigen, dass dieses Zusammenspiel grundsätzlich funktioniert.

Ausgangssituation: Alle entwickeln, aber nicht gleichzeitig

Die beteiligten Projektpartner entwickelten ihre Systeme parallel, kamen dabei aber unterschiedlich schnell voran.

Gemeinsame Tests waren deshalb nur eingeschränkt möglich. Geeignete Testumgebungen fehlten teilweise, und die Termine für systemübergreifende Tests lagen erst gegen Ende des Projekts.

Gleichzeitig wollte der Automobilhersteller schon vorher sehen, welche Fortschritte erzielt worden waren.

Problem: Wie lässt sich also demonstrieren, dass das eigene Backend richtig funktioniert, wenn die anderen Systeme noch nicht zuverlässig verfügbar sind?

Lösung: Das Backend wird zur eigenen Testumgebung

Da von Anfang an nur ein Prototyp und kein produktives System erwartet wurde, konnten wir ungewöhnliche Wege gehen.

Wir statteten das Backend mit zahlreichen Testmöglichkeiten aus. Damit ließen sich interne Zustände und Einstellungen jederzeit verändern, ohne das System neu starten zu müssen.

So konnten wir unterschiedliche Situationen gezielt herbeiführen und das Verhalten des Prototyps unmittelbar überprüfen.

Wir mussten nicht mehr darauf warten, dass die anderen Projektpartner ihre Systeme bereitstellten, um wichtige Teile unserer eigenen Funktionalität zu testen.

Fazit: Wer früh testen kann, entdeckt Probleme früher

Die umfangreichen Testmöglichkeiten machten Fehler schnell sichtbar. Außerdem kamen Unstimmigkeiten in den verwendeten Kommunikationsprotokollen zum Vorschein.

Fehler konnten unmittelbar behoben und offene Fragen zu den Protokollen frühzeitig geklärt werden.

Dadurch ließ sich auch vor den gemeinsamen Integrationstests zeigen, wie sich der Prototyp in unterschiedlichen Situationen verhielt.

Meine Erkenntnis: Testbarkeit ist nicht nur eine Frage der Softwarequalität. Sie kann auch entscheidend dafür sein, wie unabhängig ein Projekt von externen Partnern vorankommt.

Ist es wirklich immer sinnvoll, gemeinsam genutzten Code nur einmal zu implementieren?

Ziel: Geschäftsprozesse flexibler gestalten

In einem Versicherungsprojekt sollten bestehende Anwendungen und Dienste in ein neues, übergeordnetes System integriert werden.

Dieses System sollte Geschäftsprozesse verwalten und ausführen. Die Abläufe wurden dazu mit BPMN modelliert und von einer Workflow-Engine gesteuert.

Das Ziel war, bestehende Geschäftsprozesse leichter verändern und neue Prozesse einfacher hinzufügen zu können.

Ausgangssituation: Eine Änderung betrifft plötzlich alle

Die bisherigen Anwendungen und Dienste verwendeten zahlreiche gemeinsame Bibliotheken und Frameworks.

Das klingt zunächst vernünftig: Warum sollte dieselbe Funktionalität mehrfach implementiert werden?

In der Praxis hatten diese Gemeinsamkeiten jedoch einen hohen Preis.

Änderte sich eine gemeinsame Bibliothek, mussten zahlreiche Anwendungen erneut getestet, veröffentlicht und ausgerollt werden. Das galt selbst dann, wenn sich an ihrer eigentlichen Funktionalität überhaupt nichts geändert hatte.

Die Systeme waren dadurch stark voneinander abhängig. Das neue System sollte diese Schwerfälligkeit überwinden.

Problem:  Wie verhindert man, dass die alten Abhängigkeiten einfach in einer neuen Architektur wieder auftauchen? 

Lösung: Lieber etwas doppelt als alles voneinander abhängig

Wir achteten bei der Entwicklung besonders darauf, die einzelnen Geschäftsprozesse sowie ihre zugehörigen Anwendungen und Dienste konsequent voneinander zu trennen.

Jedes Subsystem sollte möglichst unabhängig von den anderen weiterentwickelt werden können.

Dafür nahmen wir bewusst in Kauf, dass bestimmte Modelle, Tests und Teile des Codes mehrfach vorhanden waren.

Das widerspricht auf den ersten Blick einem bekannten Grundsatz der Softwareentwicklung: „Don't repeat yourself“, kurz DRY.

Doch durch die Trennung musste nicht mehr zwangsläufig ein anderes Subsystem angepasst werden, nur weil sich eines veränderte.

Fazit: Nicht jede Wiederholung ist schlecht

Die bewusst geschaffene Unabhängigkeit reduzierte die Kopplung zwischen den Subsystemen.

Änderungen konnten dadurch gezielter vorgenommen werden, ohne automatisch Änderungen an anderen Subsystemen nach sich zu ziehen.

Natürlich ist duplizierter Code nicht grundsätzlich besser als gemeinsam genutzter Code. Auch Wiederholung verursacht Wartungsaufwand.

Entscheidend ist, welche Kosten die jeweilige Lösung langfristig verursacht.

Meine Erkenntnis: Gute Softwarearchitektur bedeutet nicht, möglichst viele Prinzipien kompromisslos einzuhalten. Sie bedeutet, die Konsequenzen unterschiedlicher Entscheidungen abzuwägen. Manchmal ist etwas wiederholter Code der bessere Preis für unabhängige Systeme.

Wie erweitert man ein bewährtes System, ohne seine Stabilität unnötig aufs Spiel zu setzen?

Ziel: Eine neue Schnittstelle für Börseninformationen

Ein über viele Jahre gewachsenes Backend-System stellte umfangreiche Statistiken über den Börsenhandel bereit. 

Die Daten konnten von Clients abgerufen oder als laufende Aktualisierungen empfangen werden.

Nun sollte das System um eine neue Schnittstelle mit eigenem Kommunikationsprotokoll erweitert werden. Eine wichtige Anforderung war die Unterstützung von WebSockets, die die bisherigen Schnittstellen nicht boten.

Ausgangssituation: Bewährt, aber schwer zu verändern

Das Backend war über viele Jahre kontinuierlich erweitert worden. Gleichzeitig hatte sich die zu verarbeitende Datenmenge vervielfacht.

Trotzdem arbeitete das System weitgehend zuverlässig.

Allerdings war es durch seine historische Entwicklung zunehmend schwierig geworden, neue Funktionalität einzubauen und gründlich zu testen.

Jede Änderung barg das Risiko, bestehende Funktionen zu beeinträchtigen oder sogar Abstürze auszulösen.

Hinzu kam eine weitere Schwierigkeit: Eine Erweiterung der bisherigen Schnittstellen hätte auch Änderungen am vorhandenen Client und möglicherweise an den darauf aufbauenden Frontends erfordert.

Problem: Wie konnte die neue Funktionalität umgesetzt werden, ohne unnötige Risiken und zusätzliche Anpassungen zu verursachen?

Lösung: Ein neuer Service statt Eingriffe ins alte System

Wir entschieden uns dafür, die neue Schnittstelle in einem eigenständigen Service zu implementieren.

Selbst Funktionalität, die grundsätzlich auch das bestehende Backend hätte übernehmen können, wurde im neuen Service umgesetzt.

Dadurch konnten wir die neue Lösung von Anfang an so gestalten, dass sie sich einfach und gründlich testen ließ.

Besonders wichtig war das für das Streaming von Börsendaten. Denn im Gegensatz zu einfachen Anfrage-Antwort-Abläufen müssen beim Streaming auch fortlaufende Aktualisierungen und zeitliche Abläufe berücksichtigt werden.

Mit einem eigenständigen, gut testbaren Service ließen sich solche Situationen wesentlich leichter untersuchen.

Fazit: Neue Funktionalität muss nicht zwangsläufig ins alte System

Durch die gute Testbarkeit konnten zahlreiche Fehler frühzeitig entdeckt und korrigiert werden, bevor sie in den Frontends sichtbar wurden.

Gleichzeitig blieb das bestehende Backend von den Änderungen verschont. Auch der vorhandene Client musste nicht angepasst werden.

Die neue Funktionalität konnte unabhängig entwickelt werden, ohne unnötig in ein bewährtes System einzugreifen.

Meine Erkenntnis: Die naheliegendste Erweiterung eines bestehenden Systems ist nicht immer die risikoärmste. Manchmal ist ein neuer, klar abgegrenzter Service die bessere Lösung – insbesondere dann, wenn sich neue Funktionalität dadurch leichter testen und bestehende Software unverändert weiterbetreiben lässt.

Ob E-Mobilität, Geschäftsprozesse oder Finanzinformationen: In allen drei Projekten waren technische Abhängigkeiten eine zentrale Herausforderung.

Mal ging es darum, unabhängig von externen Projektpartnern testen zu können. Mal darum, Geschäftsprozesse und Dienste voneinander zu entkoppeln. Und mal darum, ein bewährtes System nicht unnötig verändern zu müssen.

Die Lösungen waren unterschiedlich. Der zugrunde liegende Gedanke war jedoch derselbe:

Gute Softwarearchitektur schafft Handlungsspielräume, begrenzt Risiken und erleichtert zukünftige Änderungen. Genau dabei unterstütze ich auch heute Unternehmen – von der Analyse bestehender Systeme über konkrete Verbesserungsvorschläge bis zur praktischen Umsetzung.

Möchten Sie erfahren, welche Verbesserungen in Ihrer Software möglich sind?

Lassen Sie uns in einem kostenlosen Erstgespräch über Ihre Herausforderungen sprechen.