Software Sprawl zähmen – 3 Symptome und eine Atlassian-Lösung

Die monolithische Software-Entwicklung verschwindet schnell. Stattdessen setzen zahllose Unternehmen längst auf lose gekoppelte Architekturen: Verteilte, autonome Teams brechen monolithische Applikationen in Sammlungen von Komponenten wie Microservices auf.

Warum? Eine lose gekoppelte Architektur macht es einfacher, die Performance und Resilienz von Software zu skalieren, während gleichzeitig bei der Auslieferung neuer Features die Risiken und die Lead Time reduziert werden. Sie versetzt Teams in die Lage, unabhängig zu agieren und häufige Änderungen an die User auszuliefern. Und nicht zuletzt sind autonome Teams, die Software in lose gekoppelte Architekturen entwickeln, nachweislich zufriedener, engagierter und produktiver.

Doch neue Arbeitsmethoden führen immer auch zu neuen Herausforderungen. Durch die Erschaffung einer dynamischen und skalierbaren Umgebung, in der individuelle Komponenten unabhängig von allen anderen gebaut werden, nimmt die Komplexität zu und wird der Weg für eine neue Art von Problem geebnet: Software Sprawl.

Was ist Software Sprawl?

Software Sprawl, also Software-Wucherung, liegt vor, wenn die Zahl der Applikationen oder Software-Komponenten innerhalb einer Umgebung rapide wächst und sich rasant ändert, was die Komplexität signifikant steigert und traditionelle Software-Management-Methoden vor kaum lösbare Herausforderungen stellt. Solche Szenarien entstehen regelmäßig, wenn sich die Geschwindigkeit in verteilten Software-Architekturen erhöht.

Die Modernisierung jeder einzelnen monolithischen Applikation führt sehr wahrscheinlich dazu, dass hunderte Microservices entstehen, die von diversen Teams verwaltet werden, die wiederum unabhängig und häufig neue Features in das Produktivsystem einspielen. Erweitert man dies auf ein Applikations-Portfolio, haben wir es potenziell sogar mit tausenden Microservices über zig Teams hinweg zu tun.

Es ist kein Geheimnis, dass traditionelle Managementmethoden selbst bei einem kleinen Applikations-Portfolio mit großer Wahrscheinlichkeit langfristig nicht erfolgreich sind. Der Zähmung von Software Sprawl kommt daher eine entscheidende Rolle zu, wenn es darum geht, die Potenziale einer lose gekoppelten Architektur und autonomer Teams zu entfalten.

Die Symptome von Software Sprawl sind anfangs nicht immer ohne Weiteres zu identifizieren. Oft beginnt es mit kleinen Ärgernissen, die jedoch zugunsten höherer Prioritäten beiseite gelegt werden. Doch wenn sie unbearbeitet bleiben, setzen diese Ärgernisse die Entwicklungsteams einer erhöhten kognitiven Last aus; sie reduzieren das Team-Engagement und kehren die Vorteile, die mit einer lose gekoppelten Architektur verbunden sind, ins Gegenteil um.

“Die beste Zeit, einen Baum zu pflanzen, war vor 20 Jahren. Die zweitbeste Zeit ist jetzt.” Diese Redewendung lässt sich prima auf Software Sprawl anwenden: Der zukünftige Erfolg hängt davon ab, Software Sprawl entgegenzutreten, bevor ein ernsthaftes Problem entsteht. Nachfolgend zeigen wir dir drei Anzeichen für Software Sprawl sowie Tipps, um das Chaos zu meistern und stattdessen eine innovative, dynamische Umgebung zu schaffen, in der die Potenziale der modernen Architekturen ausgeschöpft werden können.

Post-Incident-Reviews identifizieren Upstream-Änderungen als Grundursachen

Ein frühes Symptom von Software Sprawl besteht darin, dass Post-Incident-Reviews Upstream-Änderungen als Grundursachen von Vorfällen indizieren. Eine wachsende Zahl von Microservices und ein erhöhtes Volumen an Änderungen in einer Umgebung kann die bestehenden Normen im Hinblick auf die Entwicklungszusammenarbeit und die Koordination von Änderungen belasten.

Selbst eine scheinbar kleine Erhöhung der Änderungsfrequenz von monatlich zu wöchentlich für eine modernisierte Applikation kann dazu führen, dass letztlich ein drastischer Zuwachs an Releases pro Monat zu verzeichnen ist. Das erfordert von den Entwicklungsteams eine entsprechende Adaption. Die Wahrscheinlichkeit von Incidents in der Produktion steigt, wenn die Normen der Zusammenarbeit von Entwickler*innen nicht mit der schnell veränderlichen Umgebung skalieren.

Um die Auswirkungen von Software Sprawl in den Griff zu bekommen, brauchen Entwickler*innen einen möglichst unaufdringlichen Weg, um Upstream- und Downstream-Änderungen im Blick zu behalten. Beispielsweise mithilfe von Atlassian Compass: Das Entwicklungsportal unterstützt Teams dabei, durch ihre verteilten Architekturen zu navigieren, und sendet In-App-Benachrichtigungen über problematische Änderungen an Upstream- und Downstream-Services.

Diese Benachrichtigungen sorgen dafür, dass der Initiator oder die Initiatorin der Änderung und die für die abhängigen Services verantwortlichen Teams sich der Gefahr bewusst sind. Dadurch entsteht die Möglichkeit, gemeinsam an der Änderung zu arbeiten, falls Probleme zu erwarten sind, und die Wahrscheinlichkeit unerwünschter Auswirkungen auf das Produktivsystem wird reduziert. Da Vorfälle in einer dynamischen Umgebung nie zu vermeiden sind, ist eine solche Zusammenarbeit sehr wichtig, um die Services im Fall eines Incidents schnell wiederherzustellen.

In Post-Incident-Reviews, in denen Upstream-Änderungen als Ursache identifiziert wurden, ist regelmäßig dokumentiert, dass die Zeit für die Wiederherstellung der Services von der Zeit beeinflusst wird, die benötigt wird, um die problematische Upstream-Änderung sowie die Service-Owner überhaupt erst einmal zu identifizieren.

Logischerweise erhöht dieser Aufwand mit der Zeit die sogenannte Mean Time to Restore (MTTR). Eine lose gekoppelte Umgebung verkompliziert die Dinge, denn die Services weisen eine umfangreiche Abhängigkeitshierarchie auf – und die Grundursache eines Vorfalls könnte überall liegen. Traditionell gräbt sich das Incident-Team durch Logs und ähnliche Aufzeichnungen, um die Änderung zu ermitteln, die den Vorfall verursacht hat. In einer dynamischen Umgebung ist das allerdings vergleichbar mit dem Durchwühlen eines Ameisenhaufens, um die Ameise zu finden, die uns gebissen hat.

Der Activity Stream in Compass kann helfen, die MTTR zu reduzieren. Er zeigt alle Ereignisse für die Upstream-Systeme inklusive der dahinterstehenden Owner-Teams. Das vermindert die Triage-Zeit und unterstützt die Entwicklerkollaboration während eines Vorfalls. Incidents kommen vor – aber das Identifizieren einer ursächlichen Upstream-Änderung innerhalb des kürzestmöglichen Zeitraums ist ein kritischer Faktor, wenn es darum geht, die Auswirkungen zu minimieren und die Services rasch wieder zum Laufen zu bringen.

Der Aktivitätsstrom in Compass zeigt alle Ereignisse in Upstream-Systemen, was die Triage-Zeit während eines Vorfalls verkürzt.

Der Output ist hoch, die Produktivität aber gering

Die Transition hin zu einer lose gekoppelten Architektur gehört zu den Schlüsselfaktoren zur Steigerung der Teamproduktivität und -zufriedenheit, denn sie eröffnet die Möglichkeit, unabhängig zu agieren und ein hohes Maß an Autonomie zu erlangen. Software Sprawl kann, sofern man dem Problem nicht entgegentritt, einige dieser Vorteile ins Gegenteil umkehren. Das Ergebnis sind stark beschäftigte, aber unproduktive und unzufriedene Teams.

Eine Klage, die man desöfteren von Entwicklungsteams hört, lautet: "Alles funktioniert prima – bis wir wir uns mit einem anderen Team einlassen müssen." Und dies ist ein weiteres Anzeichen, das auf Software Sprawl hindeutet. In einer rapide wachsenden und sich schnell verändernden Umgebung wird es zunehmend schwieriger zu überblicken, wer die richtigen Ansprechpersonen bei Upstream- oder Downstream-Abhängigkeiten sind. Das kann Prozesse verzögern und zu Frust führen, da die Teams ihre Ergebnisse ja eigentlich mit hoher Geschwindigkeit ausliefern wollen.

Nehmen wir an, es gibt Team Alpha und Team Beta. Beide schieben pro Woche eine identische Zahl an Vorgängen und Story-Points in die Done-Spalte. Team Alpha verbringt 90 Prozent seiner Zeit mit der Arbeit an neuen Features und ihrer Auslieferung, Team Beta hingegen steckt 30 Prozent in die produktive Entwicklungsarbeit und 70 Prozent darin, auszutüfteln, wie es mit den zahlreichen Upstream-Services ineinander greifen kann, von denen das Team abhängig ist.

Beide Teams haben denselben Umfang an Output, aber nur Team Alpha wird als produktiv gelten. Software Sprawl erhöht die Notwendigkeit der teamübergreifenden Zusammenarbeit. Autonome Teams benötigen clevere, effiziente Wege, um sich bei Bedarf mit anderen kurzschließen zu können. Nur so lässt sich das Potenzial einer lose gekoppelten Umgebung heben. Eine solche Umgebung erfordert die Fähigkeit, sich selbst mit allen nötigen Informationen zu versorgen. Dabei kann die Implementierung eines zentralisierten, aber dezentral verwalteten Katalogs der Software-Komponenten helfen, bei dem jedes Team dafür zuständig ist, die Services abzubilden und zu aktualisieren, für die es als Owner fungiert.

In traditionellen Umgebungen gibt es für gewöhnlich einen zentralisierten Katalog, der durch ein spezifisches Team oder eine spezifische Funktion betreut wird. Doch dieser Ansatz kann mit der Änderungsrate in einer verteilten Umgebung nicht Schritt halten. Das führt dazu, dass Teams letztlich inoffizielle Wikis und ähnliche Schatten-Tools betreiben, in denen sie festhalten, wer wofür verantwortlich ist und wie man sich mit diesen Teams koppelt.

Ein dezentraler Ansatz reduziert dagegen diese unsichtbaren und oft vergeblichen Bemühungen über die Teams hinweg. Er verbessert die informellen Selbstversorgungsmöglichkeiten und fördert eine Umgebung, in der bei Bedarf eine effektive und effiziente teamübergreifende Kollaboration möglich ist. Die Verfügbarkeit von Self-Service-Informationen über Upstream- und Downstream-Abhängigkeiten bekämpft die Auswirkungen von Software Sprawl nachhaltig und erhöht die Teamproduktivität.

Compass bietet einen zentralen Ort für entwicklungsspezifische Informationen über die Software-Komponenten, ihre Owner und ihre Abhängigkeiten.

Change-Management und Security werden zu Flaschenhälsen

Ein drittes Anzeichen für Software Sprawl liegt vor, wenn Steuerungsfunktionen wie Change-Management und Cybersecurity sich im Zuge der Auslieferung von Änderungen in die Produktivsysteme zunehmend als Flaschenhälse erweisen. Diese Funktionen bzw. Teams spielen eine essenzielle Rolle für die Einhaltung organisatorischer Standards. Sie sollen gewährleisten, dass die Anforderungen des Unternehmens erfüllt werden, bevor Änderungen in die Produktion übergeben werden.

Allerdings leidet ihre Effektivität, wenn Software Sprawl ins Spiel kommt. In einer solchen Umgebung werden Governance-Teams graduell überlastet, wenn sich die Änderungsrate erhöht: Ihr Backlog mit Änderungen und Requests, die zu prüfen sind, wird größer und größer; die Deployments in die Produktion verzögern sich immer weiter. In der Studie 2022 State of DevOps geben 56 Prozent der teilnehmenden Fachleute an, dass die Software-Sicherheitsprozesse die Entwicklungsprozesse in ihren Organisationen verlangsamen. Vielleicht kommt dir das bekannt vor – in jedem Fall ist es aber ein bedenkliches Ergebnis, nicht wahr?

Idealerweise sind Security-Praktiken in die Entwicklungsprozesse eingewoben, aber in der echten Welt sind es häufig separate Personen, die Änderungen reviewen, ehe sie in die Produktion eingehen. Das ist in einer skalierten verteilten Umgebung alles andere als effektiv. Einerseits leidet die Fähigkeit des Unternehmens zur Auslieferung von Änderungen, andererseits ist es wahrscheinlich, dass eine ungesunde Reibung zwischen den Entwicklungsteams und jenen Teams entsteht, die für die Einhaltung der organisatorischen Standards verantwortlich sind.

In einer Umgebung, die unter Software Sprawl leidet, ist es entscheidend, eine hohe Velocity zu erreichen, ohne bei der Skalierung die angestrebten organisatorischen Standards anzutasten. Automatisierte oder semi-automatisierte Scorecards sind ein gutes Mittel, um organisatorische Standards zu kommunizieren und Compliance-Aspekte über die Umgebung hinweg zu prüfen.

Compass bietet ein Scorecard-Feature, das es ermöglicht, für jede Software-Komponente Transparenz bezüglich der Compliance herzustellen. Teams und Entwicklungsleitungen können den Scorecards produktspezifische Standards hinzufügen und dadurch ein komplettes, für alle sichtbares Bild der Qualitätserwartungen und der aktuellen Status erschaffen.

Das ist eine signifikante Verschiebung: Governance- und Compliance-Checks finden nicht am Ende eines Delivery-Zyklus statt; stattdessen werden die Anforderungen frühzeitig aufgesetzt und deutlich gemacht, sodass die Teams sie im Rahmen ihres Entwicklungsprozesses verstehen und umsetzen können. Scorecards eröffnen also eine wirklich hilfreiche Möglichkeit, Software Sprawl zu begegnen und den negativen Auswirkungen auf die Governance- und Entwicklungsteams entgegenzutreten.

Die Scorecards in Compass werden genutzt, um den Health-Status von Software-Komponenten im Hinblick auf die definierten Erwartungen zu verstehen.

Software Sprawl so früh wie möglich erkennen und anpacken

Es gibt keinen ultimativen Königsweg, um Software Sprawl zu bändigen. Doch langfristiger Erfolg basiert darauf, die Folgen von Software Sprawl frühzeitig zu identifizieren und anzugehen. Erste Anzeichen sind unter anderem zunehmende Incidents durch Upstream- oder Downstream-Änderungen, Teams, die ausgelastet sind, aber ihre Ziele nicht erreichen, und Flaschenhälse bei Governance-Teams. Der beste erste Schritt, Software Sprawl zu erkennen, besteht darin, das Gespräch mit den Entwicklungsteams zu suchen und ihre Herausforderungen zu verstehen.

Atlassian entwickelt Compass, um den Teams im nächsten Schritt zu helfen, Software Sprawl zu bändigen, indem sie die Komplexität verteilter Architekturen bei der Skalierung besser handhaben. Bei dieser Lösung handelt es sich um eine umfassende Entwicklungsplattform, die nicht verknüpfte Informationen über den gesamten Entwicklungs-Output und die Team-Kollaboration an einem zentralen, durchsuchbaren Ort abbildet.

Hast du Fragen zu Atlassian Compass? Möchtest du mehr über die Features, Möglichkeiten und Use Cases der Plattform wissen? Unsere erfahrenen Atlassian-Fachleute freuen sich darauf, mit dir ins Gespräch zu kommen und dir und deinem Team einen unverbindlichen Test von Compass bereitzustellen. Melde dich bei uns!