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.
Wie geht man mit Standards und de-facto Standards am besten um?
Stefan Thiel ist CTO von Altoo, einem Unternehmen, das sowohl Produkte anderer Hersteller für die betriebliche IT-Infrastruktur im Einsatz hat, als auch ein eigenes Produkt entwickelt und anbietet, das in einer privaten Cloud betrieben wird. Thiels Erkenntnisse aus der Praxis:
«In der Administration setzen wir Windows und Microsoft 365 ein. In diesem Setup ist immer eine latente Gefahr vorhanden, dass Firmen- oder gar Kundendaten über Microsoft’s Cloud-Services (zum Beispiel OneDrive) in deren Cloud landen. Deshalb stellen wir sicher, dass alle sensitiven Daten auf eigener Hardware in unseren Racks in einem den höchsten Ansprüchen genügenden Rechenzentrum bleiben.
Für die Entwicklung brauchen wir Entwickler-Tools, und das führt zwangsläufig zu Abhängigkeiten. Die Anbieter dieser Tools haben ihre eigenen Interessen und wollen ihre Einnahmen steigern. Entwickler-Tools: Immer mehr Anbieter versuchen mit "breiteren", umfangreicheren Produkten die Preise nach oben zu drücken und vor allem Kunden auch mehr Richtung Cloud-Angebot zu drängen. Zum Beispiel: ist GitLab nun auch ein Buildserver – und nicht nur ein Code-Repository –, welcher allerdings für spezifische Technologien weniger Support bietet als andere Buildserver (in unserem Fall für scala/sbt).
Oder JetBrains bietet auch all-in-one für Entwickler: Wiki, Issue-tracking, Source Repo, Buildserver, … aber eben nur als Cloud-Angebot. Wenn wir also zur Reduzierung der Abhängigkeit und zur Nutzung eigener Ressourcen auf on-premise setzen, sind wir in der Auswahl der Produkte eingeschränkt. Wenn wir auf eine Kombination von Produkten verschiedener Hersteller setzen, welche unseren Zweck je spezifisch erfüllen, so würde das zu einer Kostenexplosion führen, da die Einzelkomponenten nicht mehr verfügbar sind, sondern immer der erhöhte Preis des all-in-one Produktes bezahlt werden muss.
Deshalb bleibt nicht viel anderes übrig, als auf einen einzigen Anbieter zu setzen und diese Abhängigkeit zu akzeptieren. Setzt man auf einen einzigen Anbieter, so ist man dann voll abhängig von diesem, weil die Definition der Build-Prozesse – also deren Abhängigkeiten, Abfolgen, Verzweigungen, … – zwischen den Produkten von verschiedenen Anbietern nicht kompatibel ist. In diesem Beispiel kann man also sozusagen die Kosten einer Migration auf einen anderen Anbieter als Messzahl nutzen, um das Lock-In-Risiko zu beziffern. Leider ist nicht jedes Risiko so einfach bezifferbar.»
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.
Publiziert am 2. Dezember 2021 auf MoneyToday