Wer sich auf klassische Systeme einlässt, sollte sehenden Auges in die damit verbundenen Risiken hineingehen, die da sind:

1) Nutzungsrecht

Das wohl größte Risiko ist das Nutzungsrecht vieler klassischer Angebote, das durch den Abbau lokaler Infrastrukturen hin zur Cloud noch weiter verstärkt wurde. Dies hat natürlich viele Hersteller gelockt, das eigene System als Cloud-Lösung zur Verfügung zu stellen. Damit ist das Risiko des Eigenbetriebs an den Hersteller übergegangen, der sein System so oder so besser kennen sollte und dies auch sicherer betreiben kann. Dazu gesellt sich natürlich der Vorteil, kein Lizenzpaket finanzieren zu müssen, sondern in ein damit meist verbundenes Abo-Modell zu wechseln, was – per Monat betrachtet – natürlich deutlich günstiger ist.

Patches und Updates fließen meist ebenfalls direkt in die Instanz mit ein – und das organisiert vom Hersteller.

Soweit die Win-Win Situation, die an sich für beide Seiten attraktiv sein muss, andernfalls hätte sich das Abo-Modell nicht nahezu flächendeckend etabliert.

Der Preis dafür ist allerdings das zeitliche Nutzungsrecht, das durch das Abo-Modell erworben wird. D.h. man kauft nicht einmalig eine Nutzung, sondern nur für den Zeitraum, für den gezahlt wird. Dazu kommt, dass die Systemhoheit auf expliziten Wunsch beim Hersteller liegt.

Dies bedeutet mit anderen Worten, die eigenen Daten liegen beim Hersteller und man erwirbt nur eine zeitlich begrenzte Nutzung, um mit dem System (und somit mit den eigenen Daten) zu arbeiten.

Das mag kaufmännisch Sinn machen und sich rechnen und sicherlich ist auch die Definition des Wortes „Vernunft“ sehr biegsam, doch bei genauer Überlegung lässt sich dies durchaus als Risiko bewerten.

2) Daten

Wie im vorherigen Punkt (und sogar Blogartikel) dargelegt, befinden sich die Daten integriert in der in (1) beschriebenen Cloud-Lösung. Was bei der Anschaffung oft nicht bedacht wird ist, ob, wie und vor allen Dingen wie umfangreich ein möglicher Export aus dem Ökosystem möglich ist oder wäre.

Oft werden Berichte oder Exporte bereitgestellt, doch diese sind meist als Teil von Arbeitsschritten gedacht, nicht für eine Situation, in der man das Schiff verlassen möchte. Doch da nichts für die Ewigkeit gebaut wird, schon gar nicht in der IT, sollte man vor dem Hineingehen in einen Raum auch nach einem Notausgang schauen.

Gerade bei Migrationen stellen wir oft fest, dass Exporte dann doch keine Selbstverständlichkeit sind. Die dabei gern zur Verfügung gestellten Datenbankabbilder oder kompletten Backups sind hier nicht wirklich hilfreich, da die Datenstruktur absolut nicht transparent ist und somit eine schlechte Alternative darstellt. Der Grund hierfür ist, dass die Datenbankstruktur oft komplex und für Außenstehende nur schwer nachvollziehbar ist. Doch das ist noch das einfachere Problem; nahezu unmöglich wird es, prozessinterne Felder und Werte oder deren Abhängigkeiten voneinander zu finden und zu deuten.

Aus diesem Grund wäre eine umfassende Exportfunktion grundsätzlich nicht schlecht. Berichte helfen hier auch nicht weiter, da sie meist dem Fenster eines Hauses gleichen – man sieht immer nur einen Teilbereich.

3) Wann kann es unangenehm werden?

Wann aber wird dies überhaupt zu einem Problem, denn immerhin handelt es sich dabei in der IT um eines von zwei klassischen Modellen. Die Alternative, also Open Source, hat sich schließlich erst in den letzten Jahren auch im Enterprise durchgesetzt. Wieso kann es also mit einem „altbewährten“ Modell ein Problem geben?

Das Übliche

Der kritischste Punkt ist, eine Software in Produktion zu setzen. Ist der Schritt einmal getan, dann ist tatsächlich das Schwerste geschafft. Schwierig wird es jedoch, wenn der Schuh zu drücken beginnt. Die Gründe hierfür können vielseitig sein. Um nur ein paar zu nennen:

  • der Softwarehersteller wird übernommen und die Software nicht länger fortgesetzt
  • der Hersteller selbst setzt das Produkt nicht länger fort
  • das eigene Unternehmen ist gewachsen und hat einen neuen Mandanten eröffnet, die Lösung ist aber nicht mandantenfähig
  • das System ist nicht mehrsprachig, doch das eigene Wachstum setzt dies voraus
  • die Prozesse haben sich geändert und passen nun nicht mehr zur Software
  • die Lösung hat nicht alle Bereiche abgedeckt (da es sich vielleicht um eine Fachlösung gehandelt hat) und die Workarounds sind nicht länger lebbar

Veraltete Technologien

Da viele dieser klassischen Lösungen aus Jahrzehnten vor oder nach der Dotcom Zeit kommen, sind viele gar nicht oder größtenteils nicht webbasiert. In den aktuellen Zeiten, in denen das Wachstum über die eigenen Grenzen hinausgeht, stellen Client-Server-Architekturen jedoch ein Problem dar bzw. bieten nicht die Möglichkeiten, Kunden oder Lieferanten über eine Portal-Lösung einzubeziehen.

Upgrades

Unangenehm kann es jedoch auch aus einer ganz anderen Richtung werden, wenn etwa die Upgrade-Kosten gescheut werden. Die IT entwickelt sich schnell und Software veraltet rapide, gerade durch Webtechnologien und besonders durch den überall Einzug-haltenden Prozess der Continuous Integration (https://en.wikipedia.org/wiki/Continuous_integration oder https://de.wikipedia.org/wiki/Kontinuierliche_Integration ). Dies sieht man schon an der Versionierung: Firefox liegt in einer Version größer 80 vor, ebenso Google Chrome. Die Abstände, in denen neue Versionen veröffentlicht werden, sind sehr kurz geworden und von Jahren auf Monate heruntergegangen. Der Hintergrund ist schlichtweg der, dass auf diese Weise schnell neue Funktionen an die Benutzer gebracht werden und die Änderungen klein bleiben. Dabei hat man von Unter-Versionierungen Abstand genommen, da das große Auflegen neuer Versionen und Planungen zu umfangreich wäre. Heute sammelt man die Wünsche der Benutzer, bewertet sie und setzt sie nach Priorität um.

Damit hat sich der Alterungsprozess von Software beschleunigt.

Wer hier nicht mitzieht, steht schnell vor einem alten Stück Software. Und dann bleibt nur noch eines: Neu anfangen.

Noch schlechter wird es, wenn man unter Zugzwang gerät. Dies geschieht schnell durch äußere Umstände, die sich nicht planen lassen. Kein System läuft allein, es gibt zumindest ein Betriebssystem, das wiederum aus verschiedenen Komponenten besteht. Wenn hier ein gravierendes Problem entdeckt wird, kann man das System sicherlich noch von außen abschotten. Doch versagt vielleicht die Hardware, und auf der neuen lässt sich das alte Betriebssystem nicht mehr zum Laufen bringen, wird es noch einmal enger. Dann bleibt die Virtualisierung, doch auch diese wird irgendwann einmal den Support für ältere Systeme einstellen. Dann ist die Fahrt definitiv zu Ende und zwar ungeplant schnell, es besteht Handlungsbedarf. Und dann muss rasch eine Lösung her, die so leicht nicht implementiert werden kann.