Ist das gut oder schlecht?
Hardware und Software unterliegt ständiger Veränderung. Höhere Leistungsfähigkeit, technologische Weiterentwicklung, ein Mehr an Funktionalität erleben wir in immer kürzeren Zyklen.
Leider lassen diese Vorteile keine Wahl – wer IT in seinen geschäftlichen Prozessen einsetzt, ist gezwungen, die Entwicklung mitzumachen.
Und das zu hohen Kosten.
Die Hersteller von Hard- und Software greifen damit quasi in die mittelfristige Budgetplanung der Organisation ein
Das Ölkännchen – an was erinnert uns das?
Mit dem Ölkännchen verbinden wir das Bild gepflegter Produktionsmittel. Wartung und sorgsamer Umgang führen dazu, dass Anlagen, Fahrzeuge und Maschinen lange genutzt werden können. Oft über den Zeitraum ihrer Abschreibung hinaus – was erfreuliche betriebswirtschaftliche Effekte hat. Wartung im Bereich der Sachanlagen ist also konsequent umgesetzter Investitionsschutz.
Dieses gewohnte Bild lässt sich leider nur bedingt in die Welt der Informationstechnologie übertragen. Die Hardware und Software kennt zwar kein Ölkännchen – aber sie braucht auch Wartung und Pflege.
Leider erleben wir hier aber nicht den Effekt, dass eine gut gewartete Hardware und eine sorgsam gepflegte Software-Landschaft sich lange unverändert nutzen lassen. Irgendwie scheint es, dass immer und immer wieder Investitionen in die Informationstechnologie erforderlich werden.
Die “level of separation” der Informationstechnologie
Um beim Bild zu bleiben: die beweglichen Teile der Maschinen bleiben stabil. Sie mögen defekt werden – das Ersatzteil entspricht in seiner Spezifikation aber immer dem alten Teil.
In der Hard- und Software ist das nicht der Fall.
Liegen die “Geburtszeitpunkte” der alten und der neuen Komponente zu weit auseinander, kommt es zu Unverträglichkeiten – von Sicherheitslücken ganz abgesehen. Die neue Software ist nicht dafür vorgesehen, mit allen bereits vorhandenen Produkten zusammen zu arbeiten.
Das ist aus Sicht der Hersteller nachvollziehbar: Das eigene Software-Produkt muss im Verbund mit den anderen Produkten, auf die es angewiesen ist, um lauffähig zu sein, entwickelt, getestet und supportet werden: Das hochfiligrane Bildbearbeitungsprogramm braucht eine Runtime, ein Betriebssystem, eine Datenbank, ein Framework und, und, und.
Setzt man die Kette der Abhängigkeiten fort, stellt man fest, dass alle Komponenten über verschiedene “level of separation” am Ende nicht separat – und damit unabhängig voneinander gehalten werden können, sondern “aufeinander angewiesen” sind.
Am Ende setzt auch das Betriebssystem eine Prozessorlinie voraus, mit der es sich gut versteht, eine Hauptspeichergröße, in der es sich wohlfühlt und eine Mindestforderung an Plattenplatz, in dem es sich ausbreiten und bequem einrichten möchte.
Und die Hersteller sind bemüht, die Anzahl der möglichen Kombinationen von Produkten und Hardware-Ausbaustufen klein zu halten – Kombinatorik kostet Zeit und Geld in Entwicklung und Test und lässt den Support im Fehlerfall zeitaufwändig und teuer werden.
Der Dominostein-Effekt
Diese Abhängigkeiten bringen eine andere Form des Domino-Effekts hervor. Sie kennen ihn, wenn ihr privater Personal-Computer beim abendlichen Herunterfahren noch nicht müde ist, sondern noch ein wenig spielen möchte “Schalten Sie den Computer nicht aus – Updates werden installiert” warnt ein Hinweis.
Das ist der Dienstag Abend.
Der Mittwoch sieht ein Java, das freudig verkündet, nun auch in aktuellerer Version vorhanden zu sein.
Da möchte der Reader nicht zurückstehen und macht sich ebenfalls “frisch”.
Das Ganze geht noch munter in Form einer gedämpften Schwingung weiter, bis das System wieder in einem eingeschwungenen Zustand ist. Was durchaus eine Woche oder mehr anhalten kann aber nicht immer bewirkt, dass der eingeschwungene Zustand auch ein stabiler ist.
Was sich im Kleinen in Form von Fortschrittsmeldungen einzelner Software-Komponenten bemerkbar macht, erleben Unternehmen im Großen als Domino-Kette in den Produktan- und -abkündigungen.
Für neue Versionen wird dediziert festgelegt, welche Umgebung bereitstehen muss. Leider macht die Software das nicht mehr selber, da muss der Anwender schon Hand anlegen. In diesem Fall der Rechenzentrumsbetrieb, der neue Versionen einspielt. Der Datenbanken konvertiert, weil sich Formate ändern. Nachdem in der Anwendungsentwicklung mit hohem Aufwand dafür Sorge getragen wurde, dass die Anwendungen sich mit der neuen Datenbank verstehen. Nachdem der Einkauf durch spürbare Lizenzzahlungen das kommerzielle Feld bereitet hat, in dem die neue Datenbankversion genutzt werden kann.
Ältere Versionen laufen “aus dem Support” – was bedeutet, dass das Störungsrisiko jetzt beim Anwender liegt. Da nur wenige Organisationen gut leben können, wenn ihre Geschäftsanwendungen “stehen”, ist das eine starke Motivation, doch eineneuere Version einzusetzen.
Die Geschichte mit Einspielen, Anpassungen, Lizenzen bildet auch hier den Refrain – mit der Kernaussage des Budgetverzehrs.
Die Grenzen der Portokasse
Die Produktlebenszyklen bei Hard- und Softwareversionen haben sich verkürzt – was die großen Anpassungen angeht, ist eine weitere Verkürzung kaum noch möglich. Den Organisationen gelingt es kaum, ihre Investitionen in Programmanpassungen, in Lizenzen und in Infrastruktur zu amortisieren.
Die Beträge die für diese Anpassungen aufgewendet werden, stellen einen beträchtlichen Teil des IT-Budgets dar. Die Fachseite würde sich wünschen, für diesen Teil Funktionalität zu sehen, die die Prozesse schneller und stabiler trägt.
Stattdessen müssen diese Kosten getragen werden, um die Schicht der darunter liegenden Software-Komponenten immer mit den Versionen bestückt ist, für die Hersteller ein reibungsfreies Zusammenwirken – drücken wir es vorsichtig aus: zusichern.
Mittlerweile ist der Anteil der Aufwendungen für diese Kategorie in einer Größenordnung angekommen, der nicht mal eben außerplanmäßig bereitgestellt werden kann. Er muss beplant werden – und das langfristig.
Das stellt Organisationen vor die Herausforderung Veränderungen ihrer Plattformen so zeitig zu planen, dass statt realer Versionsangaben mit Platzhaltern gearbeitet werden muss: Was in Jahr x+2 an Veränderung der Plattform-Komponenten, ist noch nicht vorhanden. Damit es aber in x+2 umgesetzt und abgeschlossen sein kann, muss es im Jahr x+1 als Auftrag in die Entwicklung gegeben werden, damit Anpassung und Test der Anwendungen in angemessener Zeit erfolgen.
Damit das geschehen kann -so die Fortsetzung der Rückrechnung- müssen die Veränderungen bereits heute beschlossen sein und bekannt gegeben werden. Sonst fehlt die Zeit, die benötigt wird, um Anpassungsaufwände abschätzen zu können. Und eine Einplanung der Budgets für die Anpassung im Folgejahr und die Beschaffung der Lizenzen ist ebenso im Jahr x notwendig.
Es sei denn, die Portokasse ist ausreichend dimensioniert, um solche Anpassungen aus dem laufenden Cash-Flow zu bezahlen.
Die Konsequenz: konsequente Berücksichtigung der Veränderung
Im Unterschied zu Sachanlagen gelingt es nicht, Hard- und Software-Infrastrukturen lange unverändert zu belassen: Technologie und Markt bringen Veränderung unausweichlich in die Plattformen.
Um dauerhafte Besserung zu erreichen, muss sich die Erkenntnis, dass sich die Systeme verändern, in der Struktur der Systeme widerspiegeln. Dies bedeutet konkret, dass die Architekturen Veränderungen unterstützen müssen. Komponenten, die sich dauernd verändern, müssen anders behandelt werden als solche, die längerfristig stabil bleiben. Bei hohen Änderungsraten kann eine Kapselung der Komponente und eine konsequente Standardisierung der Schnittstellen helfen. Neben der hohen Frequenz der Änderungen in den Versionen einzelner Systeme, der seinen Ursprung oft in den Veränderungen in den Prozessen und letztlich im Markt hat, kann man auch beobachten, dass die Systeme als solche relativ alt werden. Softwaresysteme deren Ursprung 20 bis 30 Jahre zurückliegt sind keine Seltenheit und bilden oft das Rückgrat der Unternehmen. Um diese Systeme fit für die Zukunft zu machen, müssen sie durch sukzessive Restrukturierung änderungsflexibel gemacht werden. Ob dies lohnt oder der steinige Weg des Austauschs mehr verspricht, muss jeweils im Einzelfall geprüft werden. Auf jeden Fall sollte das neue System dann die erforderliche Flexibilität aufweisen. Denn: Damit es besser wird, muss sich etwas ändern, aber wenn sich etwas ändert bedeutet es noch lange nicht, dass es besser wird. Besserung bedarf intelligenter, vorausschauender Planung. Unzufriedenheit mit dem Vorhandenen reicht alleine nicht aus und ist oft kein guter Ratgeber.
Solange also die Erfindung des “Ölkännchens” für die Hard- und Software auf sich warten lässt, bleibt also nur eine Strategie: konsequente Vorschau zu den Versions- und Technologiewechseln – über mindestens zwei Jahre!
Damit verhindern Sie, dass die Hersteller faktisch ein “Mitgestaltungsrecht” in der laufenden Budgetperiode ausüben – in Form von Produktabhängigkeiten, die sie kurzfristig zu Anpassungen zwingen. Sie behalten mit dieser vorausschauenden Planung die Entscheidungshoheit, wann und in welchem Umfang sie Technologiehübe adaptieren können – und wollen.