Wechselnde Anforderungen

Die harte Realität für jeden, der mit Software-Entwicklung zu tun hat, ist: Wechselnde Anforderungen treten von Tag 1 an auf. Manche sind leicht zu bewältigen – andere schwer zu meistern. Die finanziellen Auswirkungen neuer Anforderungen hängen dabei stark davon ab, in welcher Phase des System-Lebenszyklus sie auftreten.

Es gibt nur einen Weg: Nach oben.

Schon in den frühen 80ern, wurde die IT-Branche von Barry Boehm und seinem wegweisenden Buch Software Engineering Economics wachgerüttelt. Er warnte davor, dass die Cost-of-Change Kurve exponentiell wächst – ohne zeitliche Beschränkung. Mit anderen Worten: Eine Anforderung, die bei Entwicklungs-Beginn leicht zu meistern wäre, kann fünf Jahre später den 100-fachen Aufwand nach sich ziehen – wenn nicht rechtzeitig angepackt wird. Und auch wenn agile Methoden dabei helfen, die Kostenkurve erheblich zu verflachen – der Aufwand wird in der Regel von 1:100 auf das Verhältnis 1:4 verringert – kann keine Lösung den Trend zu steigenden Kosten komplett aufhalten.

Keine Überraschung: Die wachsenden Probleme alter Software-Systeme führen zu einer Cost-of-Change Kurve, die alles andere als flach verläuft. Dies ist in den seltensten Fällen der Fehler einer einzelnen Abteilung, sondern eher ein Zeichen mangelnder Abstimmung zwischen den Teams. Altsysteme werden meist ihrem eigenen Verfall überlassen – manchmal sogar über Jahrzehnte hinweg. Tatsächlich ist es unmöglich vorherzusehen, welche Bedeutung jeder einzelne Aspekt eines Systems heute in zehn Jahren haben wird. Denn wir dürfen nicht vergessen: Wechselnde Anforderungen wirken wie ein Domino-Effekt – und führen oft zu erheblichen Veränderungen für IT-Technologie, -Architektur und Funktionen. Hierzu ein paar Beispiele:

• Früher mussten Systeme „nur“ Tausende Kunden eines Landes unterstützen – heutzutage aber Millionen von Nutzern weltweit und rund um die Uhr.
• Sobald ein Intranet-System Teil einer öffentlichen Web-Anwendung wird, vervielfachen sich die Anforderungen.
• Von einem System, das erst auf Stapelverarbeitung ausgelegt war, kann nicht erwartet werden, auch in Echtzeit zu funktionieren.

Sie sehen also: Diese Beispiele gehören zu den “nicht-funktionalen” Anforderungen, mit denen wir die Betriebsmerkmale eines Systems beschreiben. Anders hingegen die Gruppe der “funktionalen” Anforderungen, welche spezifische Verhaltensmuster skizzieren. Während manche funktionalen Anforderungen geregelt werden können, sind nicht-funktionale Anforderungen meist problematischer, weil sie die Grundlagen jedes Systems beeinflussen – sowohl die Technologie als auch die Architektur.

Erst nachdenken. Dann durchstarten.

So wie jedes System einzigartig ist, gilt dies auch für jede Situation. Die beste Vorgehensweise ist es, in einzelnen Phasen Teile der Lösung zu erarbeiten. Bevor eine Schritt-für-Schritt Migration durchgeführt wird, müssen alle relevanten Problemstellen erkannt werden. Danach werden neue Funktionen von Grund auf entwickelt, während die Architektur erhalten bleibt – und damit die Fähigkeit, weiterhin benötigte Anforderungen zu erfüllen. Frühere Komponenten werden durch einen API Layer vermittelt, der erst zum Einsatz kommen kann, wenn der bestehende System-Code zuvor überarbeitet wurde.

Die Beurteilung von Altsystemen ist die erste Pflichtaufgabe für jedes Unternehmen, das sein Legacy System seriös modernisieren will. Dazu gehört eine 4-phasige Analyse der Software-Entwicklungs-Methoden. Es ist wichtig, zu bedenken, dass diese Analyse alle betreffen wird: Nicht nur die IT, sondern das gesamte Unternehmen – also jedes Team-Mitglied mit einem Zugang zum System. Eine erfolgreiche Beurteilung setzt eine enge Zusammenarbeit aller Beteiligten voraus – inklusive externen Dienstleistern.