© Excellent backgrounds/Shutterstock.com
Java Magazin
Wartung aus der Sicht einer Softwarearchitektin

Wie Sie teure Dinosaurier vermeiden

Am Ende eines Entwicklungsprojekts, kurz vor dem Livegang, arbeiten Teams üblicherweise auf einem hohen Stressniveau. Es gilt, den Einführungstermin zu halten, letzte Bugfixes durchzuführen, die abschließende Datenmigration aus den Altsystemen vorzunehmen und sicherzustellen, dass die neue, unter so vielen Mühen entstandene Software stabil auf der dafür vorgesehenen Hardware läuft. In dieser Phase denken die wenigsten Projektleiter, Teammitglieder oder Manager umfassend über das Leben nach dem Livegang nach.

Carola Lilienthal


Viel Zeit und Geld ist in den letzten zwanzig Jahren in Softwaresysteme geflossen, die in modernen, objektorientierten Programmiersprachen wie Java oder C# implementiert wurden. Dabei lag der Fokus in initialen Entwicklungsprojekten häufig auf dem schnellen Umsetzen von Features und nicht auf der Qualität der Softwarearchitektur. Dieses Vorgehen führt in der Regel dazu, dass schon im Laufe der ersten Entwicklung technische Schulden angesammelt werden. Selbst wenn sich einige Teammitglieder darum kümmern durften, eine wartbare Architektur zu entwickeln, konnten sie sich spätestens in der letzten Phase des Projekts vor dem Livegang nicht mehr ausreichend um diese Aufgabe kümmern. Auch diese Systeme gehen mit technischen Schulden in Produktion, wenn auch sicher in geringerem Ausmaß als Systeme, die von Anfang an ohne Berücksichtigung einer wartbaren Architektur entwickelt wurden. Dem Management ist diese Situation häufig nicht bis in die letzte Konsequenz klar, sonst hätten wir heute nicht so viele Systeme, deren Wartung und Erweiterung teuer, langwierig und instabil sind. Selbst Systeme, deren Entwicklung in den Jahren 2000 bis 2005 begonnen wurden, muss man heute bereits als Legacy-Systeme der zweiten Generation bezeichnen. Die erste Generation von COBOL-, PL1- und RPG-Systemen werden in vielen großen Unternehmen immer noch mit viel Aufwand gewartet.

Software ist bereits in der Entwicklung teuer, also eine Investition, die mindestens zehn bis fünfzehn Jahre halten sollte. Da die meisten Softwaresysteme Jahr für Jahr erweitert und über neue Schnittstellen mit anderen neueren Softwaresystemen vernetzt werden, wird das Ersetzen eines Softwaresystems nach fünfzehn Jahren noch einmal deutlich teurer als die Anfangsinvestition. Viel besser wäre es da doch, wenn Software länger als fünfzehn Jahre in einem gut zu wartenden Zustand bleibt und das Ersetzen tatsächlich nur im äußersten Notfall vorgenommen werden muss. Um der hier skizzierten Wartungshölle zu entgehen und somit eine möglichst lange Lebensdauer aus seiner Software herauszuholen, bedarf es der folgenden Maßnahmen:

Das Know-how des ursprünglichen Entwicklungsteams muss an das Wartungsteam weitergegeben und über lange Zeit vorgehalten werden. Das System muss durch automatisierte Tests auf allen Ebenen gegen ungewollte Änderungen abgesichert sein. Diese Tests müssen gepflegt und ausgebaut werden. Das System muss von Beginn an mit geringen technischen Schulden im Bereich der Architektur und des Designs ent...

Java Magazin
Wartung aus der Sicht einer Softwarearchitektin

Wie Sie teure Dinosaurier vermeiden

Am Ende eines Entwicklungsprojekts, kurz vor dem Livegang, arbeiten Teams üblicherweise auf einem hohen Stressniveau. Es gilt, den Einführungstermin zu halten, letzte Bugfixes durchzuführen, die abschließende Datenmigration aus den Altsystemen vorzunehmen und sicherzustellen, dass die neue, unter so vielen Mühen entstandene Software stabil auf der dafür vorgesehenen Hardware läuft. In dieser Phase denken die wenigsten Projektleiter, Teammitglieder oder Manager umfassend über das Leben nach dem Livegang nach.

Carola Lilienthal


Viel Zeit und Geld ist in den letzten zwanzig Jahren in Softwaresysteme geflossen, die in modernen, objektorientierten Programmiersprachen wie Java oder C# implementiert wurden. Dabei lag der Fokus in initialen Entwicklungsprojekten häufig auf dem schnellen Umsetzen von Features und nicht auf der Qualität der Softwarearchitektur. Dieses Vorgehen führt in der Regel dazu, dass schon im Laufe der ersten Entwicklung technische Schulden angesammelt werden. Selbst wenn sich einige Teammitglieder darum kümmern durften, eine wartbare Architektur zu entwickeln, konnten sie sich spätestens in der letzten Phase des Projekts vor dem Livegang nicht mehr ausreichend um diese Aufgabe kümmern. Auch diese Systeme gehen mit technischen Schulden in Produktion, wenn auch sicher in geringerem Ausmaß als Systeme, die von Anfang an ohne Berücksichtigung einer wartbaren Architektur entwickelt wurden. Dem Management ist diese Situation häufig nicht bis in die letzte Konsequenz klar, sonst hätten wir heute nicht so viele Systeme, deren Wartung und Erweiterung teuer, langwierig und instabil sind. Selbst Systeme, deren Entwicklung in den Jahren 2000 bis 2005 begonnen wurden, muss man heute bereits als Legacy-Systeme der zweiten Generation bezeichnen. Die erste Generation von COBOL-, PL1- und RPG-Systemen werden in vielen großen Unternehmen immer noch mit viel Aufwand gewartet.

Software ist bereits in der Entwicklung teuer, also eine Investition, die mindestens zehn bis fünfzehn Jahre halten sollte. Da die meisten Softwaresysteme Jahr für Jahr erweitert und über neue Schnittstellen mit anderen neueren Softwaresystemen vernetzt werden, wird das Ersetzen eines Softwaresystems nach fünfzehn Jahren noch einmal deutlich teurer als die Anfangsinvestition. Viel besser wäre es da doch, wenn Software länger als fünfzehn Jahre in einem gut zu wartenden Zustand bleibt und das Ersetzen tatsächlich nur im äußersten Notfall vorgenommen werden muss. Um der hier skizzierten Wartungshölle zu entgehen und somit eine möglichst lange Lebensdauer aus seiner Software herauszuholen, bedarf es der folgenden Maßnahmen:

Das Know-how des ursprünglichen Entwicklungsteams muss an das Wartungsteam weitergegeben und über lange Zeit vorgehalten werden. Das System muss durch automatisierte Tests auf allen Ebenen gegen ungewollte Änderungen abgesichert sein. Diese Tests müssen gepflegt und ausgebaut werden. Das System muss von Beginn an mit geringen technischen Schulden im Bereich der Architektur und des Designs ent...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang