Probleme bei der Softwarebereitstellung treten selten plötzlich auf.

Wenn ein Projekt eindeutig unter regelmäßigen Verzögerungen leidet, sind die sichtbaren Symptome meist schon seit einiger Zeit vorhanden. Sprintziele werden begonnen und verschieben sich immer weiter. Schätzungen werden zunehmend unzuverlässig. Einfache Änderungen dauern länger als erwartet. Das Team wird vorsichtiger. In Bereichen, die eigentlich schon stabil sein sollten, treten mehr Fehler auf – als Folge von Änderungen in anderen Bereichen. Releases erfordern mehr Abstimmung, als sie eigentlich sollten.

Von außen oder auf den ersten Blick kann das sehr wie ein Lieferproblem aussehen.

Die Führungsebene fragt sich vielleicht, warum das Team nicht schneller vorankommt, warum Schätzungen ungenau sind, warum Entwickler immer wieder an denselben Teilen des Systems arbeiten oder warum jede neue Funktion scheinbar unerwartete Nebenwirkungen hat.

Das sind natürlich berechtigte Fragen, aber sie zielen oft auf die falsche Ebene ab.

In vielen Fällen wird das Lieferproblem nicht in erster Linie durch mangelnden Einsatz, schwache Entwickler oder schlechtes Aufgabenmanagement verursacht. Die eigentliche Einschränkung ist oft architektonischer Natur. Das System hat einen Punkt erreicht, an dem seine Struktur das Tempo, die Sicherheit oder die Klarheit, die das Unternehmen von ihm erwartet, nicht mehr unterstützt.

Das ist eine heikle Phase, weil das Projekt noch sehr aktiv wirken kann. Es wird gearbeitet. Pull Requests werden zusammengeführt. Meetings finden statt. Das Backlog bewegt sich. Doch unter all dieser Aktivität steigen die Kosten all dieser Veränderungen immer weiter an.

Das Team entwickelt nicht mehr einfach nur Funktionen; es muss ständig mit der Architektur verhandeln und gegen sie ankämpfen.

Wenn die Architektur die Auslieferung nicht mehr unterstützt, wird jede Änderung teurer, als sie zunächst erscheint.

Diese Situation ist für CEOs, CTOs, Engineering Manager und Projektleiter wichtig, weil architektonische Lieferprobleme nicht lange rein technisch bleiben. Sie führen zu verpassten Zusagen, einer langsamen Reaktion auf Marktanforderungen, wiederholt fragilen Releases, einer steigenden Zahl von Incidents, frustrierten Teams und schließlich zu einem unnötigen Vertrauensverlust zwischen Business und Engineering.

Je früher diese Signale erkannt werden, desto leichter lassen sie sich korrigieren.

Das verbreitete Missverständnis über Architektur

Architektur wird oft zu abstrakt diskutiert.

Es wird als technische Präferenz behandelt, als optionaler Schritt in der Entwicklung, als Diagramm, als Framework-Entscheidung oder als etwas, worüber Senior Engineers diskutieren, während das Business auf die Auslieferung wartet. So sollte man nicht darüber denken, und Unternehmen, die das tun, setzen sich unnötigen Risiken und dem Scheitern aus.

Die Architektur in der Software definiert einen Betriebsrahmen mit Einschränkungen, ähnlich wie die Architektur eines realen Gebäudes vorgibt, was mit dem Gebäude möglich ist und wie einfach sich daran Änderungen vornehmen lassen.

Die Softwarearchitektur bestimmt, wie leicht ein Team Änderungen vornehmen, Risiken eingrenzen, Verhalten testen, Entwickler einarbeiten, mit anderen Systemen integrieren und sich von Fehlern erholen kann. Gute Architektur bedeutet nicht, dass das System nach irgendeinem theoretischen Maßstab elegant ist. Sie bedeutet, dass das System es dem Unternehmen ermöglicht, sich weiterzuentwickeln, ohne dass jede Änderung unverhältnismäßig riskant oder langsam wird oder Teile der Software beeinträchtigt, die eigentlich nicht betroffen sein sollten.

Schlechte Softwarearchitektur ist nicht immer so offensichtlich wie schlechter Code.

Manchmal ist der Code für sich genommen völlig verständlich und funktioniert einwandfrei. Das Problem liegt in der Struktur des Systems: unklare Grenzen, verborgene Abhängigkeiten, doppelte Geschäftsregeln, unzuverlässige Verträge und Lücken in der Zuständigkeit zwischen Modulen, Teams oder Anbietern.

Deshalb werden Architekturprobleme so oft unterschätzt oder sogar gar nicht erkannt.

Eine einzelne Verzögerung bei einem Feature mag wie ein lokales Lieferproblem erscheinen. Doch wenn jede Feature-Verzögerung demselben Muster folgt, ist das Problem nicht mehr lokal. Das System liefert Ihnen diese Information tatsächlich.

Die Führung sollte dies beachten, bevor die Organisation mit der falschen Maßnahme reagiert.

- Mehr Druck wird unklare Grenzen nicht beheben.
- Mehr Entwickler einzusetzen, kann die Abhängigkeitsverflechtung noch verschlimmern.
- Mehr Projektmanagement wird Verträge, denen niemand vertraut, nicht ausgleichen.
- Mehr QA am Ende wird keine Probleme mit einem System lösen, das sich nicht sauber testen lässt.

Die richtige Maßnahme beginnt damit, die architektonischen Anzeichen frühzeitig zu erkennen.

5 Anzeichen für schlechte Architektur
5 Anzeichen für schlechte Architektur