Die Entwicklungskosten eines Softwaresystems stehen häufig im Fokus. Kritische Controller hinterfragen jede Aufwandschätzung und probieren noch so abenteuerliche Sourcing-Konzepte, um die Herstellungskosten zu senken.
Ist das System dann realisiert und produktiv, gehört es auch schon zu den Legacy-Systemen und wird zu einem festen Posten im Betriebsbudget.
Wartung und Betrieb als Kostenfresser
Die Konzentration auf die Entwicklungskosten verwundert, wo doch lange bekannt ist, dass der Großteil der Kosten in Wartung und Betrieb anfallen. Im Detail mögen die Studien zu etwas unterschiedlichen Kostenverteilungen kommen, aber die Tendenz ist überall gleich: Betrachtet man die Total Cost of Ownership (TCO) über den kompletten Lebenszyklus einer Software hinweg, fallen mehr als ¾ der Kosten bei Wartung und Betrieb an. Es leuchtet sofort ein, dass zwölf Monate Entwicklung im Vergleich mit den Hardware-, Lizenz- und Personalkosten der nächsten zehn Jahre Nutzung von geringerer Bedeutung sind.
Während also in der Entwicklung noch hart über die Kosten gestritten wird, werden die Betriebskosten der Legacy-Systeme häufig weitgehend hingenommen. Der Betrieb kämpft natürlich gegen den Kostendruck, aber er kämpft mit stumpfen Waffen. Aus betrieblicher Sicht wird die Architektur des Systems als weitgehend unveränderlich akzeptiert. Mit betrieblichen Optimierungen alleine ist den Kosten aber nicht beizukommen. So bleibt nur die Hoffnung auf eine Komplettablösung, eine Neuentwicklung, die alles besser macht. Tatsächlich verbergen sich in diesen Kosten aber Schätze, die sich mit Architekturreviews heben lassen – wir führen solche z.B. im Rahmen unseres Future-IT-Ansatzes durch.
Potenziale erkennen
Martin Fowler definierte den Begriff Architektur als „Things that people perceive as hard to change“. Architektur ist die Grundlage, auf der das System gebaut ist. Aber die Vergleiche zur Gebäudearchitektur leiten in die Irre. Tatsächlich ist Software virtuell und fast alles ist änderbar. Nur unsere Phantasie und Kreativität setzen uns Grenzen. Die Welt um die Software herum ändert sich auch ständig. Die Architektur muss die (nicht-funktionalen) Anforderungen abbilden. Im Laufe der Jahre ist es aber gut möglich, dass sich die Anforderungen ändern. Wo man früher hochverfügbar sein musste, würde heute vielleicht auch weniger reichen, da Ausfälle durch angrenzende Systeme, die in der Zwischenzeit entstanden sind, aufgefangen werden.
Auch andere Anforderungen ändern sich, aber selbst wenn nicht, sollte überprüft werden, ob die Lösung mit dem heutigen Wissen noch adäquat ist. Eventuell wurden Dinge selbst implementiert oder teuer eingekauft, für die es heute Open-Source-Komponenten gibt? Wartungskosten durch z.B. Bugfixes oder Lizenzkosten für eingekaufte Komponenten können entfallen. Vielleicht kann durch die Migration auf eine neuere Infrastruktur (Application Server, Datenbank, etc.) die Performance so verbessert werden, dass Hardware (und damit CPU-gebundene Lizenzen) eingespart werden können? Vielleicht bietet das Partnersystem mittlerweile eine einfachere und kostengünstige Schnittstelle an? Vielleicht war der Application Server damals Firmen-Standard, benötigt aber heute teure Sonderbetriebsführung. Ein Architekt kann einschätzen, ob eine Migration auf den aktuellen Regelbetriebsführungsprozess möglich und sinnvoll ist.
Neutraler Blick auf die Systeme
Die Veränderungen in der Umwelt vollziehen sich oft vergleichsweise langsam und graduell, das macht das Projektteam betriebsblind für Optimierungschancen. In einem Architekturreview wird ein unvoreingenommener, externer Blick auf die Systeme und auf ihre Einbettung in die Systemlandschaft geworfen. Ein Review sondiert, ob irgendwo tief unten in der Legacy-Software Schätze schlummern. Der Aufwand, diese zu Tage zu fördern, amortisiert sich häufig schnell aus den Einsparungen an Hardware, Lizenzkosten und vereinfachten Prozessen. Danach wird jedes Jahr Budget frei, um Innovation zu entwickeln und Wettbewerbsvorteile zu realisieren, statt wie bisher nur den Mangel zu verwalten und auf eine Ablösung der Legacy-Systeme zu hoffen.
Bildquelle: Shutterstock
