Vitale Softwarelösungen brauchen Pflege, Wartung und Technologiewandel
Als Unternehmen, welches individuelle Softwarelösungen entwickelt die mindestens mittelfristig oder langfristig eingesetzt werden sollen, gelangt man früher oder später an den Punkt, dass die einst sehr gute und aktuell noch produktiv eingesetzte Lösung nicht mehr mit einer vielversprechenden Perspektive weiterentwickelt werden kann. Aber warum eigentlich?
Der Bedarf des Kunden für diese Lösung ist meist unverändert vorhanden oder hat sich höchstens um verschiedene Aspekte erweitert, sei es dass zusätzliche Funktionen oder die Integration in andere Systeme benötigt wird. Hier kann also nicht das Problem liegen. Dies merkt man auch daran, dass der Kunde selbst eine Lösung gar nicht für veraltet ansieht. Sie löst ja alle Aufgaben nach wie vor und konnte in der Vergangenheit auch immer um weitere Aspekte erweitert werden. Also warum jetzt plötzlich nicht mehr?
Die Ursache liegt also doch eher auf der technologischen Seite. Mit einem gewissen Abstand zur IT ist dies zunächst verwunderlich, denn eine EDV Lösung basiert immer auf gewissen Standardtechnologien (verschiedenste Arten und Schichten von Hardware, Software und Vernetzung). Diese Technologien sind nicht mehr neu, weit verbreitet und bereits unzählig oft verwendet worden. Doch wie immer steckt der Teufel im Detail und die Technologien, die als Standard erscheinen sind es im Detail eben doch nicht. Besonders die Softwaretechnologie(n) verändern sich durchaus schnell. Dies bietet zwar immer neue Möglichkeiten, stellt aber vor allem dann ein Problem dar, wenn der Lebenszyklus einer Softwarelösung länger ist, als der ihrer zugrunde liegenden Technologie. Was passiert denn, wenn die Technologie veraltert?
Wenn die sich die Veralterung einer Technologie nach und nach in ein Softwareprodukt einschleicht, ist dies zuerst bei der Wartung und als nächtes bei Erweiterungen zu erkennen - und zwar nicht beim Kunden sondern in der Entwicklung. Die Aspekte sind vielseiteig: es kann sich die Systemumgebung verändern (neue Server, andere Datenbanken, höhere Sicherheitsanforderungen) oder es gibt Integrationsanforderung für neue Systeme (neuartige Schnittstellen). Die Probleme in der Entwicklung können ebenfalls sehr vielfältig sein: die bisher eingesetzte Technologie unterstützt die aktuellen Standards nicht oder die Architektur ist nicht leistungsfähig genug; bei sehr alten Systemen kann es sogar passieren, dass schlicht und einfach niemand mehr zu finden ist, der die eingesetzt Technologie überhaupt kennt. Am Anfang sind solche Probleme klein und noch lösbar, aber irgendwann ist der Punkt erreicht, an dem die Weiterentwicklung entweder nicht mehr möglich oder nicht mehr rentabel ist. Letztendlich hat die einst moderne Softwarelösung ihre Vitalität verloren.
Eine vitale Softwarelösung zeichnet sich vor allem dadurch aus, dass sie leicht wartbar, flexibel anpassbar und erweiterbar ist. Die Vitalität einer Softwarelösung ist also nicht daran meßbar, ob die bezweckten Aufgaben zufriedenstellend erledigt werden (auch eine nicht vitale Lösung kann eine Aufgabe erfüllen), sondern ob sie es auch in Zukunft können wird. Letztlich ist es bei Softwaresystemen genau wie bei allen anderen Dingen - sie benötigen eine ausführliche Dokumentation und eine kontinuierliche Pflege und Wartung, wenn sie langfristig eingesetzt werden sollen. Dazu gehören kleinere Upgrades (kurzer Zyklus) genauso wie die regelmäßige Aktualisierung der technologischen Basis (längerer Zyklus), was ggf. auch eine komplette Neuimplementierung bedeuten kann. Ein Softwaresystem vital zu halten ist folglich kein technisches Problem, sondern eines der Zielsetzung.
Man muss sich also fragen, welche Softwarelösungen vital gehalten werden müssen. Hierfür ist besonders die beabsichtigte Nutzungsdauer von Bedeutung, weil nur mittel- und langfristig angelegte Softwarelösungen der Gefahr ausgesetzt sind, dass eine eingesetzte Technologie veraltet bevor die Lösung nicht mehr benötigt wird. In der Regel sind dies Teile der Unternehmensinfrastruktur. Und genau weil es sich um Teile der Infrastruktur handelt ist die Vitalität von besonderer Bedeutung. Denn beginnt diese zu veralten und unflexibel zu werden, ist viel mehr als nur das Fortbestehen eines Softwareproduktes gefährdet.
Die entscheidene Frage ist also, ob es sich bei der betroffenen Softwarelösung um ein Teil der Unternehmensinfrastruktur handelt (dabei ist es nicht relevant, ob dier Teil ein keliner oder ein großer ist). Ist dies gegeben, muss das Ziel eines Softwareprojektes auch entsprechend definiert werden. Neben der Erfüllung der konkreten Anforderungen muss auch die langfristige Vitalität eines Systems als Ziel definiert werden. Hierfür muss natürlich das Bewußtsein für die Notwendigkeit vorhanden sein oder geschaffen werden. Ist dieser entscheidende Schritt getan, kann die Erhaltung der Vitalität auch entsprechend geplant und auch angemessen budgetiert werden.
Die Maßnahmen zur Erhaltung der Vitalität eines Softwaresystems können sich je nach Art, Umfang und Priorität unterscheiden. Eine wesentliche Voraussetzung ist aber immer eine gute und umfassende Dokumentation. Während des Betriens können darauf basierend gezielt Aktualisierungen von verwendeten Komponenten (z.B. Update von Betriebssystem, Datenbank, Webserver, Interpreter) vorgenommen werden. Hiermit kann zumindest innerhalb eines Technologiezyklus das nötige Maß an Vitalität erhalten werden. Oft ist es zusätzlich nötig partiell Erweiterungen oder Korrekturen in der Architektur vorzunehmen (Refactoring), um neue Funktionalitäten umsetzen zu können. Ab einem gewissen Punkt wird sich jedoch die Erweiterung der Architektur und der Technoloiebasis nicht mehr lohnen, weil durch die Verwendung einer neuen Technologien mehr Probleme gelöst werden, als es auf Basis der alten Technologien wirtschaftlich (oder auch rein techisch) möglich wäre.
Ein Technologiewandel bei Softwaresystemen, die Teil der Unternehmensinfrastruktur sind, ist also vollkommen normal und auch notwendig. Die Frage ist nur, ob diese Notwendigkeit bereits zu Beginn eines Softwareentwicklungsprojektes erkannt und als Ziel definiert wurde, oder erst bei Eintritt der Einbußen bei der Vitalität des Systems erkannt wird.
Denn wie überall gilt auch hier: Wenn eine Erkenntnis später erlangt wird, ist sie zumeist mit Überraschungen verbunden.