Software-Sprawl eindämmen

Die Symptome von Software-Wildwuchs sind anfangs oft nur schwer zu erkennen. Anfangs ist es nur ein kleines Ärgernis, das zugunsten wichtigerer Dinge ignoriert wird. Doch wenn nichts dagegen unternommen wird, kann Software-Wildwuchs die Entwicklungsteams mit einer höheren kognitiven Belastung lähmen, die Teammotivation verringern und die Vorteile einer lose gekoppelten Architektur zunichte machen. Wie das Sprichwort: "Der beste Zeitpunkt, einen Baum zu pflanzen, war vor 20 Jahren. Der zweitbeste Zeitpunkt ist jetzt". Wer in Zukunft erfolgreich sein will, muss dem Software-Wildwuchs Einhalt gebieten, bevor er zu einem Problem wird.

Im Folgenden findest du drei Anzeichen für Software-Sprawl und was du tun kannst, um das Chaos zu bewältigen und gleichzeitig eine innovative und dynamische Umgebung zu schaffen, die das Potenzial aller Teams ausschöpft.

Ein frühes Anzeichen von Software-Sprawl ist es, wenn mehrere Überprüfungen nach Vorfällen (Post-Incident-Reviews, PIRs) Upstream-Änderungen als Hauptursache für einen Vorfall angeben. Eine wachsende Anzahl von Microservices und ein erhöhtes Änderungsvolumen innerhalb einer Umgebung können die bestehenden Normen in Bezug auf die Zusammenarbeit von Entwicklern und die Koordination von Änderungen auf die Probe stellen. Selbst eine kleine Erhöhung der Änderungshäufigkeit von monatlich auf wöchentlich für eine modernisierte Anwendung kann zu einer 100-fachen Erhöhung der Releases pro Monat führen. Es ist keine Überraschung, dass Entwickler ihre Art der Zusammenarbeit anpassen müssen. Vorfälle treten in der Produktion eher auf, wenn die Normen für die Zusammenarbeit von Entwicklern in einer schnelllebigen Umgebung nicht skalierbar sind.

Die Schaffung einer unauffälligen Methode für Entwickler, Upstream- und Downstream-Änderungen zu berücksichtigen, ist eine großartige Möglichkeit, die Auswirkungen von Software-Sprawl einzudämmen. Wir bei Atlassian verwenden Compass – ein Entwicklerportal, das Teams dabei hilft, sich in verteilten Architekturen zurechtzufinden –, um Entwicklerteams In-App-Benachrichtigungen über aktuelle Änderungen an Upstream- und Downstream-Services zu senden. Das Bestätigen dieser Benachrichtigung signalisiert dem Initiator der Änderung, dass die Teams, die für abhängige Services verantwortlich sind, die Änderung zur Kenntnis genommen haben. Dies bietet die Möglichkeit, gemeinsam an der Änderung zu arbeiten, falls es zu Problemen kommt. So kann die Wahrscheinlichkeit unbeabsichtigter Auswirkungen auf die Produktion verringert werden. Da Vorfälle in einer dynamischen Umgebung unvermeidlich sind, ist die Zusammenarbeit der Entwickler während eines Vorfalls von entscheidender Bedeutung, um Services schnell wiederherzustellen.

Bei Überprüfungen nach Vorfällen, in denen Upstream-Änderungen die Hauptursache sind, ist es üblich, dass die Zeit für die Wiederherstellung von Services von der Zeit beeinflusst wird, die benötigt wird, um die problematische Upstream-Änderung zusammen mit dem Team oder der Person zu identifizieren, das oder die für den Service zuständig ist. Logischerweise reduziert die Verringerung der Zeit, die benötigt wird, um die fehlerhafte Upstream-Änderung zu identifizieren, langfristig die mittlere Wiederherstellungszeit (Mean Time to Restore, MTTR). Dies gestaltet sich in einer lose gekoppelten Architektur, in der Services in einer umfangreichen Abhängigkeitshierarchie gegliedert sind und die Hauptursache eines Vorfalls an einer beliebigen Stelle des Stacks liegen kann, schwieriger. Traditionell durchsuchen Vorfallsverantwortliche Protokolle oder Änderungsdatensätze, um eine Änderung zu identifizieren, die zu einem Vorfall geführt haben könnte. In einer dynamischen Umgebung gleicht dies der sprichwörtlichen Suche nach der Nadel im Heuhaufen.

Wir bei Atlassian verwenden den Aktivitäten-Feed in Compass, um die MTTR zu verkürzen. Der Aktivitäten-Feed zeigt alle Ereignisse für Upstream-Systeme zusammen mit den Details des Teams, das dafür zuständig ist. Das reduziert die Selektierungszeit erheblich, indem die Zusammenarbeit der Entwickler während eines Vorfalls unterstützt wird. Vorfälle passieren, aber die rechtzeitige Identifizierung einer Upstream-Änderung als Hauptursache eines Vorfalls ist entscheidend, um sicherzustellen, dass die Auswirkungen minimiert werden und die Services schnell wiederhergestellt werden.

Die Umstellung auf eine lose gekoppelte Architektur ist einer der wichtigsten Bestandteile für Teamproduktivität und Zufriedenheit – die Möglichkeit, unabhängig und mit einem hohen Maß an Autonomie zu handeln. Wenn nichts dagegen unternommen wird, kann Software-Sprawl einige dieser Vorteile ins Gegenteil umkehren, was zwar zu einem beschäftigten, aber unproduktiven und unglücklichen Team führt. Eine häufige Beschwerde der Entwicklerteams lautet: "Alles funktioniert gut, bis wir mit einem anderen Team zusammenarbeiten müssen." Dies gilt umso mehr, wenn Software-Sprawl zu einem Problem wird. Eine schnell wachsende und sich verändernde Umgebung verringert die Fähigkeit der Entwickler, den Überblick darüber zu behalten, wen sie für Upstream- oder Downstream-Abhängigkeiten beauftragen müssen. Dies führt letztendlich zu einer Verlangsamung und zu Frustration in Teams, die versuchen, schnell zu liefern.

Hypothetisches Szenario: Alpha-Squad und Beta-Squad haben dieselbe Anzahl von Vorgängen und Story Points, die in Jira jede Woche nach "Erledigt" verschoben werden. Der Alpha-Squad investiert 90 Prozent seiner Zeit darauf, neue Funktionen in die Produktion einzubringen, während der Beta-Squad 30 Prozent für neue Funktionen und 70 Prozent für die Interaktion mit den vielen Upstream-Services aufwendet, von denen sie abhängig sind. Beide Squads haben das gleiche Leistungsniveau, aber nur Alpha wird wahrscheinlich als produktiv angesehen. Software-Sprawl erhöht die Notwendigkeit der Zusammenarbeit zwischen Teams. Die Identifizierung intelligenter Methoden für autonome Teams zum Reagieren auf Abruf ist der Schlüssel, um das Potenzial einer lose gekoppelten Umgebung auszuschöpfen.

In einer schnell wachsenden und dynamischen Umgebung ist die Fähigkeit, Informationen selbst zu nutzen, wichtig für die Produktivität und Zufriedenheit des Teams. Eine Möglichkeit, dies zu erreichen, ist die Implementierung eines zentralen Softwarekomponentenkatalogs mit dezentraler Verwaltung. Hierbei handelt es sich um einen zentralen Katalog, bei dem jedes Team für die Erstellung und Aktualisierung der Services, für die es zuständig ist, verantwortlich ist. Herkömmliche Umgebungen haben in der Regel einen zentralen Katalog, der von einem bestimmten Team oder einer bestimmten Funktion verwaltet wird. Dies kann jedoch nicht mit der Geschwindigkeit des Wandels in einer verteilten Umgebung Schritt halten, was dazu führt, dass Teams Schatten-Wikis darüber erstellen, wer und wie eingebunden werden soll. Wir bei Atlassian haben festgestellt, dass ein dezentraler Ansatz den nicht sichtbaren und vergeudeten Aufwand teamübergreifend reduziert, die Self-Service-Funktionen verbessert und eine Umgebung für Einbindung auf Abruf schafft. Die Eindämmung von Software-Sprawl durch selbst genutzte Informationen zu Upstream- und Downstream-Abhängigkeiten ist eine großartige Möglichkeit, die Teamproduktivität mit zusätzlichen Auswirkungen auf die Zufriedenheit und die Einbindung des Teams zu verbessern.