Wenn IT-Altsysteme die Organisationsentwicklung blockieren Conway's law: Modernisieren Sie Software und Organisation gemeinsam!

Conway's law: Modernisieren Sie Software und Organisation gemeinsam!

Schlägt sich auch Ihre IT mit störanfälligen Altsystemen herum? Der Aufwand für eine neue Software-Architektur ist enorm, doch wie Peter Rubarths Bericht zeigt, kann ein solcher Change gelingen – wenn man die Conway Rückkopplung beachtet.

Management Summary

Wenn IT-Altsysteme die Organisationsentwicklung blockieren Conway's law: Modernisieren Sie Software und Organisation gemeinsam!

Conway's law: Modernisieren Sie Software und Organisation gemeinsam!

Schlägt sich auch Ihre IT mit störanfälligen Altsystemen herum? Der Aufwand für eine neue Software-Architektur ist enorm, doch wie Peter Rubarths Bericht zeigt, kann ein solcher Change gelingen – wenn man die Conway Rückkopplung beachtet.

Management Summary

Das Team ist hochkarätig besetzt: Einige der erfahrensten Software-Entwickler:innen sind dem Aufruf eines technischen Managers gefolgt, mit problematischen, technischen Altlasten aufzuräumen. In der Vergangenheit waren verschiedene Versuche gescheitert. Dieses starke Team soll nun einen Weg finden, die Probleme zu lösen, die den Entwickler:innen schon viel zu lange Kopfschmerzen bereiten und eine effizientere Entwicklung verhindern.

Das Team stammt aus allen Teilen der Organisation. Drei Dinge verbinden die Teammitglieder:

  • Sie sind handverlesen und die Herausforderung reizt sie.
  • Sie sind nicht länger bereit, den aktuellen Zustand als unabänderbar zu akzeptieren.
  • Sie sind entschlossen, im Bestandssystem aufzuräumen.

Den Frust unseres Teams dürften viele IT-ler:innen nachempfinden können: In 28,6% aller Firmen verursachen Wartung und Betrieb der Bestandssysteme einen höheren oder sogar deutlich höheren Aufwand, im Vergleich zu anderen Anwendungen. Und in gut 44% machen diese monolithischen Altsysteme mindestens 50% der geschäftskritischen Anwendungen aus (siehe Legacy-Modernisierung 2022), genau wie in unserem Beispiel.

Der anfängliche Enthusiasmus wich bald Ernüchterung: Das Projekt kam nicht in Fahrt. Es war schwierig, überhaupt ein plausibles Vorgehen zu entwerfen, denn es kamen immer wieder andere Themen dazwischen. Nach etwa sechs Monaten Arbeit auf anderen Baustellen – und ohne erkennbaren Fortschritt beim Kernthema – mehrten sich im Team die Stimmen, die den Sinn des ganzen Unterfangens bezweifelten.

Zu diesem Zeitpunkt hatte ich das Team schon einige Zeit als Agile Coach begleitet. Aus dieser Rolle heraus schlug ich dem verantwortlichen technischen Manager vor, die für mich erkennbare Abwärtsspirale aus Selbstzweifeln zu unterbrechen und in die Offensive zu gehen. Wir vereinbarten, in einem Workshop zu klären, ob es ein klares Mandat aus dem Unternehmen gibt – oder nicht. Im Folgenden schildere ich die überaus wechselhaften Stationen des anspruchsvollen Change Projekts, die zu diesem Workshop führten.

In diesem Beitrag erleben Sie mit, wie sich Teamstrukturen und Software-Architektur gegenseitig beeinflussen, was das mit den hier skizzierten Herausforderungen zu tun hat und welches Vorgehen dem Team geholfen hat, konstruktiv mit der Situation umzugehen.

Die Vorgeschichte

Das betreffende Unternehmen betreibt einen virtuellen Marktplatz für Immobilienfinanzierungen. Die Kunden an diesem Marktplatz sind einerseits Finanzierungsvermittler und andererseits Banken mit ihren Finanzierungsprodukten.

Der Marktplatz ist als digitale Plattform umgesetzt; diese wurde über einen längeren Zeitraum aufgesetzt und kontinuierlich weiterentwickelt. Verantwortlich für sie sind mehrere interdisziplinär zusammengesetzte Teams. Zu deren Aufgabengebieten gehören u. a. Software-Entwicklung, Produktmanagement und UX-Design.

In der Vergangenheit waren diese Teams entlang fachlich-technischen Überlegungen strukturiert. Dies erleichterte es, klare Verantwortlichkeiten zu schaffen und die Arbeit zwischen den Teams aufzuteilen.

Die Problematik der Kernkomponenten

Entsprechend verantworteten einzelne Teams jeweils einen Teil der Basis des Programmcodes. Daneben entstand eine ganze Reihe Kernkomponenten (Bild 1), in welchen übergreifende Funktionalitäten gebündelt wurden, die jeweils für viele Teams relevant waren (z.B. Nutzerauthentifizierung, E-Mail-Versand oder zentrale Datenbanken).

Die Verantwortung für diese Kernkomponenten teilten sich die Teams. Auch bei anderen Komponenten gab es gegenseitige Abhängigkeiten. Allerdings gab es hier eindeutige Zuständigkeiten. Bei den Kernkomponenten nicht.

Software-Komponenten und Teamaufteilung vor dem Change
Bild 1: Software-Komponenten und Teamaufteilung vor dem Change

Dieser Ansatz funktionierte jahrelang gut. Mit der Zeit wurden jedoch Probleme sichtbar, die eine Veränderung erforderten: Einerseits war die Struktur stärker orientiert an praktischen internen Erwägungen als an Markterfordernissen. Dies führte dazu, dass an der Umsetzung von Kundenanforderungen teilweise mehrere Teams arbeiteten, die sich untereinander abstimmen mussten. Diese Koordination war aufwendig. Der Abstimmungsbedarf und die gegenseitigen Abhängigkeiten führten manchmal zu langen Umsetzungszeiten und reduzierter Flexibilität beim angemessenen Reagieren auf Marktveränderungen.

Gleichzeitig wurden im Laufe der kontinuierlichen Wartung und Weiterentwicklung ursprünglich klar erkennbare Architekturgrundsätze immer weiter aufgeweicht. Aufgrund dessen war die gewachsene Software-Architektur immer schwieriger zu verstehen. Bei Veränderungen mehrten sich die bösen Überraschungen, wenn eine Anpassung an einer ganz anderen Stelle unvorhergesehene Probleme auslöste. Dieser Umstand resultierte in weiteren Verzögerungen bei der Umsetzung von neuen Themen und damit in reduzierter Reaktionsfähigkeit.

Warum wird Software in Komponenten aufgeteilt?

Die Aufteilung von Software in voneinander abgegrenzte Komponenten erfolgt hauptsächlich, um den Umgang mit dem Code zu erleichtern. Ab einer bestimmten Größe ist es bei praktisch keiner Software möglich, alle Abläufe im Detail zu überblicken. Es ist notwendig, voneinander abgegrenzte Bestandteile zu schaffen, welche in sich verstanden und unabhängig voneinander weiterentwickelt werden können.

Sollen mehrere Menschen gleichzeitig an einer Software arbeiten, wird es notwendig, die Codebasis so zu strukturieren, dass diese ihre Arbeit verrichten können, ohne sich gegenseitig zu behindern. Erreicht Software eine Größe, bei der mehr Software-Entwickler:innen notwendig sind, als sich sinnvoll in einem Team organisieren lassen (ab ca. zehn), wird eine weitere Abgrenzung notwendig, um die Zusammenarbeit dieser Teams zu ermöglichen.

Näher an den Markt durch eine neue Struktur

DownloadDownload

Jetzt Feedback geben und mitdiskutieren!

Wir würden uns über Ihre Bewertung und/oder einen Kommentar freuen ‒ nur so können wir Ihnen in Zukunft noch bessere Inhalte liefern.

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung.
2 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 2
Kommentare 2

Das könnte Sie auch interessieren

Vorschaubild

Teams zu Hochleistungsteams zu entwickeln, ist eine Aufgabe vieler Agile Coaches. Dabei gibt es konkrete Rahmenbedingungen, Werkzeuge und Methoden, auf die man achten sollte.

Vorschaubild
Teil 1:
Welche Mischformen sind für die Praxis relevant?

Agil, klassisch, hybrid oder selektiv: Viele Unternehmen haben die Bedeutung agiler Methoden mittlerweile erkannt. Eine weitergehende Systematik, wie agile und traditionelle Methoden am besten zusammenspielen, fehlt jedoch meist. Dies stellt …

Alle Kommentare (2)

Philipp
Reiffenstein

Danke für diesen informativen Artikel und vor allem die Durchleitung mit dem anschaulichen Praxisbeispiel!