Technische und wirtschaftliche Abhängigkeiten
Abhängigkeiten lassen sich in der IT nicht vermeiden. Allerdings spielt es durchaus eine Rolle, wie gross eine Abhängigkeit ist und welche Folgen diese Abhängigkeit haben kann. Eine Abhängigkeit ist immer auch ein Risiko. Dieses Risiko muss man im Detail kennen, um die Tragweite einschätzen zu können. Das ist essentieller Teil des Risikomanagements und somit Sache der Geschäftsleitung.
Abhängigkeiten bei Eigenentwicklungen
Bei der Entwicklung eigener Produkte besteht zuallererst eine Abhängigkeit von der eigenen Organisation, den internen Prozessen und den zur Verfügung stehenden Ressourcen. Also eine organisatorische Abhängigkeit, die direkten Einfluss auf das Schicksal des Produkts hat. Dazu kommen die produktspezifischen Abhängigkeiten. Softwareentwicklungen setzen auf Plattformen, Frameworks und Bibliotheken und verwenden Programmiersprachen. In den Entwicklungsprozess eingebettet sind auch DevOps (Development Operations)-Tools. Die verwendeten Plattformen, Frameworks und Bibliotheken sind unabhängige Produkte von Dritten, die entweder weiterentwickelt werden oder veralten. Die Eigenentwicklung muss sich dem anpassen. Gleiches gilt auch für die Programmiersprachen und die DevOps-Tools. Eine Eigenentwicklung ist somit nie abgeschlossen, sondern muss jeweils an den neusten Stand der verwendeten Plattformen, Frameworks, Bibliotheken, Programmiersprachen und DevOps-Tools angepasst werden.
Abhängigkeiten bei kommerziellen Produkten
Abhängigkeiten entstehen in der IT mit der Wahl der Produkte und der Wahl der Anbieter. Und das betrifft alle drei Bereiche: (1) Infrastruktur, (2) Kommunikation und (3) Applikationslandschaft. Anbieter werden gross, weil sie über eine Produktpalette verfügen, die mehrere Bereiche abdeckt und bei der die Produkte untereinander so aufeinander abgestimmt sind, dass sie zwar in der Kombination funktionieren, aber nicht unbedingt äquivalent mit Produkten anderer Anbieter zusammenspielen. Jeder Anbieter hat seine eigene Produktpolitik und mit der muss sich der Kunde abfinden. Jeder Anbieter hat seine eigene Welt und in der muss sich der Kunde zurechtfinden. Das bedingt, dass der Kunde in seiner Organisation entsprechendes Know-How aufbaut und entsprechend Ressourcen zur Verfügung stellt. Das braucht es, um den Betrieb zu gewährleisten. Bei der Breite des Angebots vieler Anbieter und der jeweils eigenen Namensgebung für Produkte und Technologien ist das nicht gerade einfach.
Verwendet ein Kunde sowohl Plattform wie auch Applikationen eines Anbieters, so besteht eine doppelte Abhängigkeit. Betriebsspezifische Anpassungen und Erweiterungen sind Eigenentwicklungen, die wiederum an die Produkte des Anbieters gebunden sind.
Bei kommerziellen Produkten fallen Wartungskosten an für Support, Schwachstellenbeseitigung und Weiterentwicklungen. Das wird dem Kunden über einen Wartungsvertrag und teilweise über höhere Kosten verrechnet. Diese Kosten können auch Teil von monatlichen Nutzungsgebühren (Platform as a Service - PaaS, Software as a Service - SaaS) sein. Bei on-premise Produkten können die Kosten des Wartungsvertrages über fünf Jahre die Initialproduktkosten übertreffen. Höhere Kosten können beim Kunden zusätzlich durch die Weiterentwicklung eines Produkts durch den Anbieter anfallen, weil das Upgrade kostenpflichtig ist. Oder weil gewisse bestehende oder neue Funktionalitäten von der Nutzung eines Cloud-basierten Services abhängig gemacht werden und dieser Service nur als Abonnement verfügbar ist und so zu ungeplanten Zusatzkosten führt.
Ein Thema, das oft übersehen wird: Auch in Bezug auf die gewährte Sicherheit ist der Kunde vom Hersteller abhängig. Und die ist meist massiv geringer als versprochen. Man kann nur herausfinden wie sicher ein Produkt ist, wenn man es auf Sicherheit prüft. Das ist aufwendig und verursacht zusätzliche Kosten. Dem Anbieter glauben, dass sein Produkt «secure» ist, wie im Marketing versprochen, ist da deutlich einfacher und kostengünstiger. Nur kennt man dann die Risiken nicht und das ist schlecht für das Risikomanagement. Mit einem ISMS, das ISO 27001 voll unterstützt, ist es zudem nicht vereinbar. Eine Gap Analysis zeigt das relativ schnell und eindeutig auf.
Auswirkungen in der Praxis
Lock-in Effekte sind bei den meisten Unternehmen vorhanden und werden durch die Einbindung von Cloud-basierten Diensten noch verstärkt. Ein Wechsel auf ein anderes Produkt wäre mit grossen Kosten und negativen Auswirkungen auf den Betrieb verbunden. Für die Hersteller ist das ein guter Ausgangspunkt, um von Zeit zu Zeit die Preise zu erhöhen. Zudem sind Cloud-basierte Dienste günstiger für die Anbieter, weil die Produkte nicht mehr auf die unterschiedlichsten Plattformen angepasst werden müssen. Etablierte Hersteller von on-premise Produkten sind deshalb daran interessiert, auch on-premise Produkte mit einer Cloud-basierten Komponente zu verbinden. Es gilt der Grundsatz: Je grösser der Lock-in, desto mehr Macht hat der Hersteller gegenüber dem Kunden. Herstellerspezifische de-facto Standards stellen ein Risiko dar.
Die Abhängigkeiten werden grösser – die Risiken steigen
Die Abhängigkeiten in Bezug auf IT werden immer grösser. War das früher auf Produktfunktionalität, Produktqualität, Produktsicherheit und Produktverfügbarkeit beschränkt, so ist heute auch der Datenerwerb, die Datenspeicherung und die Datenverarbeitung betroffen. IT hat wie Janus zwei Gesichter. Auf der einen Seite ermöglicht die Digitalisierung mittels IT neue Möglichkeiten und Effizienzgewinne. Auf der anderen Seite schafft IT immer mehr Abhängigkeiten und wird so immer mehr zum Risikofaktor. Geschäftsleitungen sollten diese Risiken beachten und auch in die Entscheidungsfindungen einfliessen lassen. Service-Modelle klingen verlockend, doch können diese zum «Hotel California»-Effekt führen: «You can check out any time you want, but you can never leave». Produkte, die nur noch als Service verfügbar sind können bestehende Abhängigkeiten zementieren, da ein Wechsel für den Kunden schwierig und mit hohem Aufwand verbunden ist. Jede Abhängigkeit ist eine technische Schuld, die beglichen werden muss.