Technische Schuld und Legacy Systeme: Wann fördern Verträge diese Entwicklung?

12.04.2021

Überall, wo Software zum Einsatz kommt, ist das Risiko vorhanden, dass Alt-Systeme zu Legacy Systemen mutieren. Dies bedeutet, dass sie nicht mehr im Rahmen vertretbarer Kosten und ohne vorhersehbares technisches Risiko weiterentwickelt oder gewartet werden können. Wie kann also vermieden werden, dass ein System oder Alt-System zum Legacy System wird? Lesen Sie im folgenden Artikel, wie Legacy Systeme rechtzeitig erkannt werden, wie man diese entfernt und letztendlich vermeidet.

Wie werden Legacy Systeme erkannt?

Ein essenzielles Qualitätskriterium für Software ist eine langfristige Wart- und Erweiterbarkeit. Durch einen Fokus auf dieses Kriterium kann sichergestellt werden, dass künftige Erweiterungen in Bezug auf Kosten, Umsetzungszeit, Wirtschaftlichkeit und Risiko akkurat eingeordnet werden können. Abbildung 1 zeigt anhand der grünen Linie eine optimale Kostenentwicklung in Bezug auf das Alter der Software. Ein initialer Anstieg der Kosten ist damit verbunden, dass Investitionen in die Qualität getätigt werden, welche mittelfristig die Kosten stabilisieren, sowie die Software am Leben erhalten.

Im Unterschied dazu zeigt die rote Linie eine mögliche Entwicklung für ein System, wo Qualitätskriterien vernachlässigt werden. Jeder rote Punkt zeigt eine Entscheidung in der Entwicklung, wo ein Kompromiss zwischen Qualität und Kosten oder ev. Umsetzungszeit eingegangen wurde. Dadurch entsteht in der Software etwas, das unter dem Begriff “technische Schuld” bekannt ist. Diese technischen Schulden führen dazu, dass die Komplexität künftiger Wartungen und Weiterentwicklungen erhöht wird und somit auch die Änderungskosten, sowie das damit verbundene Risiko. Technische Schulden führen erfahrungsgemäß schnell dazu, dass Teile eines Systems oder das System als Ganzes nicht mehr wart- oder erweiterbar werden.

Die Entwicklung eines Systems hin zu einem Legacy-System ist allgemein gut messbar. Unter anderem können hier folgende Anzeichen beobachtet werden:

Die Kosten und Umsetzungszeiten für Änderungen steigen über die Zeit an. Vor allem bei Aufgaben mit vergleichbarem Inhalt ist dies gut beobachtbar.
Es ist ein Anstieg der Fehlerquote im Produktivsystem bei bzw. nach Versionsupdates messbar.
Die Termine für Produktivsetzungen können nicht konstant eingehalten werden.
Die Entwicklerinnen und Entwickler zeigen Unsicherheiten bei den Schätzungen.
Es häufen sich Fragen nach der Machbarkeit.
Es entwickelt sich bei Produktverantwortlichen und Entwicklerinnen und Entwicklern eine Scheu, Veränderungen voranzutreiben.
Es wird vermehrt von Workarounds gesprochen.
etc.

Wie geht man mit einem bestehenden Legacy-System um?

Technische Schuld wird im Rahmen einer Softwareentwicklung immer anfallen. Dies ist nicht vermeidbar. Jedoch können die Prozesse in der Softwareentwicklung derart priorisiert werden, dass technische Schulden abgebaut werden können. Hierfür ist ein gemeinsames Mindset im Projektteam notwendig. Eine konstante Überwachung der technischen Schulden und die Ermächtigung der Entwicklerinnen und Entwickler, diese wieder entfernen zu können/dürfen, sind unumgänglich hierfür. Methoden welche hier Anwendung finden sind unter anderem Code Reviews, Coding Guidelines, Pair Programming, Refactoring, Test Driven Development etc. Abbildung 2 zeigt die konstante Korrektur der technischen Schulden durch kleine Anpassungen.

Je nachdem, wie weit sich das Softwareprodukt auf der Reise in Richtung “End of Life” befindet, können kleinere Anpassungen ggf. nichts mehr bewirken und größere Refactorings oder Reengineerings können notwendig werden. In diesem Fall ist es hilfreich, sich Reengineering-Spezialisten ins Projektteam zu holen, die nach und nach ein konsistentes Reengineering der bestehenden Alt-Systeme durchführen (siehe dazu https://risc-software.at/fachbeitraege-software-reengineering/). Abbildung 3 zeigt das späte Erkennen technischer Schulden. Hier muss mit deutlich mehr Aufwand und Zeit gegengesteuert werden, um das System wieder auf den richtigen Pfad zu bringen.

Wie vermeidet man ein Legacy-System?

Neben der Beobachtung technischer Schulden stellt sich die Frage, wie technische Schulden vermieden werden können. Dafür muss analysiert werden, wie technische Schulden zustande kommen. Wo liegen die Ursachen hierfür und was kann getan werden, um diese Ursachen zu entschärfen?

Wie im vorigen Abschnitt festgehalten, sind die Entwicklerinnen und Entwickler diejenigen, welche für die technische Qualität eines Softwareproduktes zuständig sind. Technische Schuld wird daher nicht vorsätzlich in ein System integriert, sondern durch externe Faktoren gefördert. Betrachtet man den zeitlichen Verlauf einer Softwareentwicklung, so kann folgender Zusammenhang festgestellt werden:

Die blaue Linie zeigt die lineare Projektabwicklung, d.h. die Erfüllung des geplanten Projektumfanges bis zum Lieferzeitpunkt bei V1.0. Die Ideallinie in der Realität sollte der grünen Linie entsprechen. Es gibt kontinuierliche Anpassungen in der Umsetzung, wodurch die Produktentwicklung “auf Kurs” gehalten und so sichergestellt wird, dass ein wertvolles, lauffähiges Produkt zum geplanten Termin zur Verfügung steht.

Abbildung 5 zeigt ein Bild, welches in der Realität jedoch meist vorzufinden ist. Eine Abweichung vom Plan wird bemerkt. Wie es dazu kam, kann unterschiedliche Gründe haben. Eventuell war eine initiale Schätzung nicht akkurat, das Team hat an Effizienz verloren, es gibt äußere Einflüsse wie z.B. Krankenstände, die Komplexität der Software hat sich geändert, der Projektumfang hat sich geändert, etc. Die Gründe hierfür können vielfältig sein.

An dieser Stelle wird jedoch interessant, welche Optionen ein Projektteam hat. Folgende primären Entscheidungen können, unter Berücksichtigung der Gegebenheiten, getroffen werden.

Option 1: Der bzw. die Produktverantwortliche verschiebt das Fertigstellungsdatum

Sofern der bzw. die Produktverantwortliche die Möglichkeit dazu hat. Hinter einer Verschiebung des Fertigstellungstermins stehen üblicherweise andere Personen oder Systeme, welche davon abhängig sind und mehr oder weniger auf den ursprünglich geplanten Termin bestehen. Dazu kommt noch der Nachteil, dass nicht nur eine Produktivsetzung und somit der (ev. wirtschaftliche) Nutzen zeitlich verschoben wird, sondern auch noch das Projektteam einen längeren Zeitraum finanziert werden muss. Dies führt zu zusätzlichen Kosten und späteren Einnahmen. Eine direkte, negative Auswirkung auf den ROI ist die Folge.

Option 2: Die Entwicklungsgeschwindigkeit wird erhöht

Die wenigsten Widerstände dürfte man sich erwarten, wenn man es schafft, die Arbeitsgeschwindigkeit der Entwicklerinnen und Entwickler dahingehend zu optimieren, dass der Fertigstellungszeitpunkt und die Entwicklungskosten eingehalten werden. Tatsächlich ist das eine Option, wobei man hier zwei unterschiedliche Szenarien unterscheiden muss.

Option 2a: Es gibt Einflussfaktoren, welche das Team in der Effizienz stört, welche auch tatsächlich behoben werden können. Diese Maßnahmen funktionieren und sind auch jene, welche bei einer kontinuierlichen Prozesskontrolle und -verbesserung stattfinden. Das Szenario in Abbildung 4 setzt eben diese voraus. Voraussetzung für diese Maßnahmen sind folglich aber auch, dass die Abweichungen nicht zu spät erkannt werden und auch nicht zu groß sind. In Abbildung 7 könnte das ev. schon zu spät für eine solche Maßnahme sein.

Option 2b: Es gibt zwar störende Einflussfaktoren, diese werden jedoch nicht behandelt oder es ist zu spät für entsprechende Maßnahmen. In diesem Fall wird eine Erhöhung der Entwicklungsgeschwindigkeit lediglich durch den Aufbau von Druck auf die Entwicklerinnen und Entwickler erreicht. Druck führt üblicherweise dazu, dass in den Methoden eingespart wird, welche keinen offensichtlich direkten Einfluss auf den Produktumfang einer Software hat. Dies sind jene, welche zur Erhaltung der Qualität notwendig sind und somit kommt es sukzessive zu einem Aufbau von technischer Schuld. Da es auch an Zeit und Kapital für den Abbau der technischen Schulden fehlt, schreitet dieser Aufbau ggf. mit entsprechender Geschwindigkeit voran.

Option 3: Verminderung des Projektumfangs

Als dritte Option besteht die Möglichkeit, die Inhalte des Softwareproduktes anzupassen. Eine entsprechende Befugnis der Produktverantwortlichen ist hierfür jedoch Voraussetzung, bzw. werden hierfür ggf. entsprechend intensive Verhandlungen zwischen dem bzw. der Produktverantwortlichen und den Stakeholdern benötigt. Anpassungen dieser Art werden durch diverse Maßnahmen erleichtert:

Variabler Projektumfang – variable Inhalte
Laufende Priorisierung der benötigten Funktionen
Entwicklung der Funktionen entsprechend ihrer Prioritäten
Kontinuierliche Beobachtung der Geschwindigkeit, Timeline, Inhalte, …
Etc.

Tatsächlich ist eine solche Anpassung im Projektumfang zu jeder Zeit in der Umsetzung möglich. Rechtzeitig erkannt, sind die Änderungen marginal, spät erkannt, sind die Änderungen entsprechend umfangreicher. Hier gilt: Sofern das Produkt bereits die WERTvollsten Funktionen beinhaltet, sollte eine Produktivsetzung mit vermindertem Funktionsumfang kein Hindernis sein. Durch entsprechend gut geschulte und erfahrene Produktverantwortliche kann dieses Risiko deutlich minimiert oder gar vermieden werden.

Welche Option ist die Beste?

Wie so oft kann hier keine pauschale Aussage getroffen werden. Eventuell macht eine der Optionen für sich alleine Sinn oder eine entsprechende Kombination der Optionen 1, 2a und 3 führt zu einer entsprechenden Korrektur des Kurses. Lediglich Option 2b sollte vermieden werden, da genau diese letztendlich ein System in Richtung “End of Life” entwickelt.

Die Maßnahmen, welche letztendlich ein Legacy-System verhindern sind

eine starke und präsente Führung durch eine/n erfahrene/n und ermächtigte/n Produktverantwortliche/n,
der kontinuierliche Fokus auf initiative und proaktive Verbesserung durch einen Coach und
bewusste technische Qualitätssicherungsmaßnahmen durch die Entwicklerinnen und Entwickler.

Warum bindet man sich vertraglich an technische Schuld?

Abschließend soll noch ein wichtiger Einflussfaktor genannt werden, welcher die Optionen 1 – 3 entsprechend einschränken kann: der Vertrag.

Es ist verständlich, dass Auftraggeber vertragliche Sicherheit in Hinblick dahingehend haben wollen, welcher Umfang, in welchem Zeitraum, zu welchen Kosten geliefert wird. Aus diesem Grund werden oftmals Verträge mit den Auftragnehmern geschlossen, wo alle drei Faktoren fixiert werden. Somit hat der bzw. die Produktverantwortliche aber keinerlei Handlungsspielraum:

Das Releasedatum steht fest – es darf keine Verspätung geben (Option 1)
Die Kosten stehen fest – es darf keine Mehrarbeit durchgeführt werden (Option 1, Option 2a)
Der Umfang steht fest – es dürfen keine Features entfernt werden (Option 3)

Somit bleibt, vertraglich betrachtet, meist nur noch Option 2b, nämlich die Erhöhung des Drucks auf die Entwicklerinnen und Entwickler und die damit verbundene Minimierung der Qualität des Produktes.

Empfohlen wird hier vielmehr die Fixierung von Releasedatum und Kosten (z.B. durch Stabilisierung des Teams) und die Schaffung von Flexibilität in den Anforderungen an ein Produkt. Durch die Führung eines bzw. einer Produktverantwortlichen, können Auftraggeber den benötigten Funktionsumfang eines Softwareprodukts bis zum Releasedatum steuern und erhalten dadurch eine transparente Kostenkontrolle. Zusätzlich kann das Produkt während der Umsetzung an die Marktbedürfnisse angepasst und so zielgruppenorientiert positioniert werden.

>> Lesen Sie mehr