Der Aufstieg des Cloud Computing hat das Gesicht der Informationstechnologie für immer verändert. Vor der Cloud erforderte der Zugang zu Infrastruktur beträchtliche Vorabinvestitionen und Vorlaufzeiten von mehreren Monaten. Nach dem Start des Cloud Computing war Infrastruktur innerhalb weniger Minuten verfügbar – zu Kosten von wenigen Cent pro Stunde.
Diese Infrastrukturrevolution brachte wiederum das Web 2.0 hervor – eine Reihe von Unternehmen, die in der Cloud entstanden sind. Diese Innovatoren führten neue Angebote ein, die träge analoge Prozesse durch kostengünstige digitale Technologien ersetzten, was bei großen Unternehmen mit langer Geschichte zu tiefgreifenden Umwälzungen führte. Neue Verben entstanden, um diese Disruption zu beschreiben: geubert. Oder geairbnbt. Oder genetflixt.
Natürlich waren die etablierten Akteure dieser Branchen nicht bereit, sie den Emporkömmlingen zu überlassen. Also folgten sie den Disruptoren in die Cloud. Doch bei den meisten dieser Vorhaben geschah etwas Merkwürdiges: Sie zahlten sich nicht aus.
Ein Unternehmen nach dem anderen startete große Cloud-Initiativen, stellte jedoch keine Beschleunigung seiner IT-Prozesse fest und war nicht in der Lage, sich mit der Geschwindigkeit der Disruptoren zu bewegen.
Wie sich herausstellte, reicht die Einführung der Cloud nicht aus, um sich mit der Geschwindigkeit des Web 2.0 zu bewegen. Schnelle Infrastruktur muss mit schnellen Softwarepraktiken verbunden werden. Anders ausgedrückt: Der Weg der Software in die Produktion muss mit der Geschwindigkeit der zugrunde liegenden Infrastrukturressourcen Schritt halten.
Web-2.0-Unternehmen haben typischerweise hochgradig angepasste Toolchains aufgebaut, um die für eine Softwareänderung vom Keyboard bis zur Produktion benötigte Zeit zu verkürzen. Gemeinsam ist Web 2.0 der intensive Einsatz von Open-Source-Komponenten, die mit unternehmensspezifischen Integrationskomponenten verbunden werden, um eine maßgeschneiderte Eigenlösung zu schaffen.
Als Reaktion darauf haben viele Unternehmen eigene Initiativen für Eigenlösungen gestartet. Doch allzu viele davon führen nie zu einer praktikablen Lösung, sodass die Unternehmen in ihren Bemühungen behindert werden, die Geschwindigkeit des Web 2.0 zu erreichen. Die naheliegende Frage lautet daher: Warum gelingt es so vielen Unternehmen nicht, ihren eigenen Weg in die Produktion erfolgreich aufzubauen?
Ich habe viele dieser gescheiterten Eigeninitiativen beobachtet und möchte die dabei häufig auftretenden Probleme teilen – und Vorschläge machen, die technischen Fachleuten dabei helfen, einen optimierten Weg in die Produktion zu schaffen.
Siehe auch: Führende Cloud-Service-Provider und Unternehmen
Vorsicht vor den Nachteilen eigener Cloud-Lösungen
Welche Probleme sind mir in großen Unternehmen begegnet, die versucht haben, einen eigenen Cloud-Computing-Produktionsweg aufzubauen?
Hier sind einige Gründe, warum diese Bemühungen um Eigenlösungen scheitern:
Auswahl der Komponenten
Es gibt ein derart schwindelerregendes Angebot an Open-Source-Komponenten für die verschiedenen Teile des Wegs in die Produktion, dass allein die Auswahl eines geeigneten Sets zur Integration in die Toolchain eine große Aufgabe darstellt.
Die Augenkarte, die die CNCF-Landschaft darstellt, macht es schon zu einer Herausforderung, die Optionen für die verschiedenen Teile der Toolchain aufzulisten – ganz zu schweigen davon, eine gute Option zu bewerten und auszuwählen. Natürlich gibt es eine Alternative: Man lässt einen Mitarbeiter auf Grundlage des Rufs einer Lösung oder danach entscheiden, was jemand aus seinem Umfeld verwendet hat. Das wirkt jedoch bestenfalls willkürlich und schlimmstenfalls hochriskant.
Unterschätzte Integrationskosten
Einige Komponenten verfügen über integrierte Integrationen für ergänzende Komponenten, sodass die Integrationsaufgabe einfach zu sein scheint.
Allerdings verfügen nicht alle ausgewählten Komponenten über Integrationen zu anderen Komponenten, für die sich eine Organisation entscheiden könnte. Und in jedem Fall ist es meiner Erfahrung nach ein Trugschluss anzunehmen, dass integrierte Integrationen in allen Anwendungsfällen gut funktionieren und sich skalieren lassen. In Wahrheit erfordert die Software, die wie eine einfache Integrations-„Klebeverbindung“ wirkt, typischerweise deutlich mehr Arbeit als erwartet – mit mehr Personalaufwand und längeren Zeitplänen, als ursprünglich veranschlagt.
Der gesamte Lebenszyklus der Anwendung wird nicht berücksichtigt
Bemühungen zum Aufbau einer DIY-Toolchain beginnen häufig in einer Gruppe, die ein konkretes eigenes Problem lösen möchte. Die Gruppe macht sich daran, ihre Arbeitsaufgaben zu automatisieren, Betriebskosten zu senken und den Durchsatz zu erhöhen. So weit, so gut.
Leider gibt es häufig keine Arbeit, um einen automatisierten Workflow mit den vor- und nachgelagerten Teams zu verbinden, die ebenfalls zum Weg in die Produktion beitragen. Die Übergabe einer Aufgabe an die nächste erfolgt daher letztlich manuell. Sehr oft führt die Automatisierung einzelner Aufgaben zu keiner Beschleunigung insgesamt, da der Großteil der Zeit auf dem Weg in die Produktion zwischen den Aufgaben und nicht innerhalb der Aufgaben verbracht wird.
Personalmangel
Die Kehrseite der Unterschätzung des Arbeitsaufwands und der Komplexität einer durchgängigen Automatisierung besteht darin, dass dem Projekt zu wenig Personal zugewiesen wird. Diese Projekte beginnen oft als sogenannte Skunkworks-Vorhaben, bei denen einige Mitarbeiter eines Teams nebenbei in Teilzeit daran arbeiten. So wird der Aufwand für die Erstellung eines „echten“ Projekts – etwa Budgetierung und Zeitplanung – vermieden.
Sobald der tatsächliche Umfang des Projekts deutlich wird, wenn andere am Weg in die Produktion beteiligte Gruppen ihre Anforderungen vorbringen, sind die personellen Möglichkeiten eines Skunkworks-Vorhabens schnell überfordert. Dann müssen sich Organisationen unangenehmen Entscheidungen stellen: das Projekt aufgeben – und damit in einem langwierigen manuellen Prozess stecken bleiben – oder echte Mittel dafür bereitstellen, was Dokumentation und Konkurrenz um das Budget erfordert.
Abzug von Fachkräften
Jede Technologieorganisation verfügt nur über eine begrenzte Zahl talentierter Ingenieure. Werden diese Ingenieure mit der Verbesserung eines internen Prozesses betraut, tragen sie nicht zu den übergeordneten Zielen des Mutterunternehmens bei.
Nur sehr wenige Unternehmen sind bereit, bewusst wertvolle und knappe Talente einem internen Projekt zu widmen, so lohnenswert es auch sein mag. Daher fehlt es dem internen DIY-Projekt an Fachkräften, was zu Verzögerungen oder unvollständiger Funktionalität führt.
Verzögerte Wertschöpfung
Zu Beginn dieses Artikels wurde das wichtigste Motiv für die Einführung cloudnativer Praktiken in Unternehmen genannt: die Reaktion auf die durch Cloud-native-Wettbewerber verursachte Marktveränderung.
Ein teures und komplexes DIY-Projekt in Angriff zu nehmen, das unter Fachkräfte- und Budgetmangel leiden wird, ist ein Rezept für verspätete Auslieferung und verzögerte Wertschöpfung. Eine selbst entwickelte Software-Toolchain vermittelt zwar ein Gefühl des Eigentums, doch 24 bis 36 Monate zu benötigen, um sie in die Produktion zu bringen, hindert das Mutterunternehmen daran, jetzt auf gefährliche Konkurrenz zu reagieren.
Siehe auch: Führende Unternehmen der digitalen Transformation
Leitfaden zur eigenen Cloud: DIY richtig umsetzen
„Aha!“, denken Sie. Ich möchte all diese Probleme beim Aufbau des automatisierten Wegs meines Unternehmens in die Produktion vermeiden. Aber wie?
Wenn ich mit großen Unternehmen spreche, die ein DIY-Projekt für einen Cloud-Produktionsweg in Angriff nehmen, empfehle ich ihnen, darauf zu achten, dass ihr Plan die folgenden Faktoren berücksichtigt:
Verstehen Sie Ihr Warum
Aus welchem geschäftlichen Grund ist ein selbst entwickeltes System wichtig? Allzu oft dient ein DIY-Projekt jemandem dazu, ein eigenes kleines Machtreich aufzubauen, was den Interessen dieser Person, aber nicht unbedingt denen des Unternehmens dient.
Verstehen Sie daher, was Sie mit dem Aufbau Ihres eigenen Wegs in die Produktion erreichen wollen. Und stellen Sie sich nicht vor, Sie seien eine weltweit einzigartige Schneeflocke, die eine maßgeschneiderte Lösung benötigt – oder verstehen Sie zumindest, warum Sie eine Schneeflocke sind, um die Bedeutung eines selbst entwickelten Systems besser einschätzen zu können.
Die meisten Unternehmen wären, wenn sie ehrlich zu sich selbst sind, mit einer Standardlösung für ihren Weg in die Produktion bestens bedient.
Beziehen Sie alle Silos ein
Wie bereits erwähnt, beginnen allzu viele DIY-Projekte innerhalb einer einzelnen Gruppe und berücksichtigen nie die Anforderungen anderer Beteiligter am Lebenszyklus einer Anwendung. Das alte Klischee lautet: zweimal messen, einmal sägen; mit anderen Worten: erst planen, dann ausführen.
Bevor Sie mit dem Aufbau beginnen, stellen Sie sicher, dass die Lösung jeder Gruppe, die auf dem Weg in die Produktion mit Code arbeitet, dabei hilft, ihren Teil des Prozesses zu automatisieren – oder dass sich die eigenen automatisierten Systeme dieser anderen Gruppen problemlos in das entstehende System integrieren lassen.
Andernfalls besteht bestenfalls das Risiko, dass sich Ihre Softwarepraktiken nicht beschleunigen; schlimmstenfalls drohen organisatorische Konflikte, wenn diese anderen Gruppen Hindernisse aufbauen und sich weigern, mitzuwirken.
Planen Sie die laufende Wartung ein
Machen Sie sich bewusst, dass Sie eine Plattform aufbauen. Jede Plattform erfordert laufende Arbeit, um Funktionen zu erweitern, Fehlerkorrekturen zu integrieren sowie Betrieb und Ausfallsicherheit zu verbessern. Dies ist eine nachgelagerte Budgetverpflichtung, für die Sie unbedingt planen sollten. Andernfalls erhalten Sie ein veraltetes, für die Nutzer unbefriedigendes System, das sich nur noch mühsam dahin-schleppt.
Erstellen Sie ein Budget
Ich hoffe, dieser Artikel hat verdeutlicht, dass ein wichtiges System zur Unterstützung Ihres Wegs in die Produktion eine langfristige Verpflichtung darstellt und nicht etwas ist, das sich von einigen Teilzeitkräften schnell zusammenbauen lässt.
Wenn Sie Ihren Cloud-Projektplan erstellen, weisen Sie entsprechende Mitarbeiterkapazitäten zu und planen Sie die Personalkosten ein. Berechnen Sie außerdem die Infrastruktur, die Sie für den Betrieb einer Plattform benötigen. Das bedeutet, dass Sie Entwicklungs-, Staging- und Produktionsumgebungen benötigen, um Plattformverbesserungen und Tests vor der Produktion zu ermöglichen.
Berechnen Sie die Opportunitätskosten Ihrer Ressourcen
Die Mitarbeiter, die Sie mit dem Aufbau Ihrer Plattform betrauen, könnten an anderen Dingen arbeiten. An welchen? Welchen Wert könnten Sie erzielen, wenn Sie sie anderen Aufgaben zuweisen?
Jede Technologieorganisation hat eine endlose Liste anstehender Aufgaben. Gibt es darunter Aufgaben, die der Organisation oder dem Unternehmen insgesamt einen größeren Nutzen bringen?
Führen Sie eine Kaufen-oder-selbst-entwickeln-Analyse durch
Wie ich zu Beginn dieses Beitrags angemerkt habe, entwickeln die meisten Web-2.0-Unternehmen ihre eigenen maßgeschneiderten Systeme für den Weg in die Produktion. Für sie ist das finanziell absolut sinnvoll, da sie im Kern digitale Unternehmen sind und sehr große Mengen an Codeänderungen und Releases durch ihre Systeme schleusen.
Werden die Kosten für technische Ressourcen und Infrastruktur auf ein solches Volumen umgelegt, ist ein selbst entwickeltes System für sie finanziell sinnvoll. Die Frage lautet: Ist es das auch für Sie?
Es gibt kommerzielle Produkte, die durchgängige Funktionen für den Weg in die Produktion bereitstellen. Sie können Ihre Budget- und Opportunitätskosten den Kosten einer kommerziellen Lösung gegenüberstellen und ermitteln, welcher Ansatz für Ihre Situation sinnvoll ist.
Siehe auch: Gewinner und Verlierer der Cloud-Native-Welt
Die wichtigsten Erkenntnisse: Aufbau eigener Cloud-Lösungen
Was sind die wichtigsten Punkte, die Sie aus diesem Artikel mitnehmen sollten?
- Softwarekompetenz ist im Zeitalter des Cloud Computing eine wichtige Voraussetzung. Das Aufpfropfen veralteter Softwareentwicklungspraktiken auf eine Cloud-Infrastruktur führt zu keiner höheren Anwendungsgeschwindigkeit. Schlimmer noch: Es kann höhere Kosten verursachen, als eine Legacy-Anwendung unangetastet zu lassen. Um in der Wirtschaft von morgen zu bestehen, brauchen Sie fundierte Softwarekompetenz.
- Sie müssen so schnell wie möglich ein modernes System für den Weg in die Produktion einführen. Die durch Web-2.0-Unternehmen verkörperte Disruption in den Branchen zeigt keine Anzeichen eines Abflauens. Wer nicht sofort beginnt, riskiert, den Anschluss zu verlieren.
- Überlegen Sie sich Ihren Ansatz sorgfältig. DIY ist verlockend. Durch den Einsatz von Open-Source-Komponenten scheint der Einstieg einfach und kostengünstig. Es ist entscheidend, dass Sie die vollständigen Auswirkungen eines selbst entwickelten Systems hinsichtlich Kosten, Personalbindung und Zeit bis zur Wertschöpfung verstehen.
- Ist Ihr Plan umfassend? Stellen Sie sicher, dass Ihre endgültige Lösung den gesamten Weg in die Produktion abdeckt und alle Aufgaben umfasst, die eine Codeaktualisierung auf ihrem Weg in die Produktion durchläuft.
Behalten Sie diese Punkte stets im Blick, und Sie erhöhen Ihre Erfolgschancen enorm.