Time to Market ist das Killerargument, wenn es um DevOps, CI/CD-Pipelines und Lean Enterprise geht. Aber was bringt dir eigentlich Time to Market, wenn deine Kunden mit einer langsamen Update-Strategie und seltenen Features zufrieden sind?
Was ist eigentlich Time to Market? Es geht auch ums Messen…
Die Time-to-Market kann als Produktentwicklungszeit übersetzt werden. Sie wird bestimmt durch die Geschwindigkeit, mit der ein Produkt zur Marktreife gebracht wird.
Quelle Wikipedia – Time to Market
Time to Market ist also ein Konzept, bei dem die Literatur allgemein davon ausgeht, dass eine schnellere Produktionsreife eines Produkts oder Features wirtschaftliche Vorteile mit sich bringt. Aber wozu brauchst du eine optimierte Time to Market, wenn deine Kunden das als nicht wertvoll oder gar schädlich ansehen?
Es gibt aber 3 wichtige Gründe, die dennoch für ein schnelles Time to Market spricht. Und es geht dabei nicht um Kundenwirksame Features.
Grund 1: Die geölte Patch-Maschine
Das BSI hat mit dem Cloud Computing Compliance Criteria Catalogue, kurz C5 Kriterien festgelegt, an die sich Cloud-Computing Provider halten müssen. Das gilt nicht nur für die Hyperscaler und Public-Cloud-Anbieter, sondern vor allem auch für On-Premise Clouds (neudeutsch: Private-Clouds). Also auch Plattformen und Software, die du und dein Team als Service bereitstellen. Du bist also mit großer Wahrscheinlichkeit betroffen.
In diesem Dokument gibt es das Kriterium OPS-22, dass es in sich hat. Dort gibt es die Anforderung:
Sicherheitspatches werden ab dem Zeitpunkt ihrer Verfügbarkeit in Abhängigkeit des nach der jüngsten Version des Common Vulnerability Scoring Systems (CVSS) eingeordneten Schweregrades der dadurch adressierten Schwachstellen eingespielt:
- Kritisch (CVSS = 9.0 – 10.0): 3 Stunden
- Hoch (CVSS = 7.0 – 8.9): 3 Tage
- Mittel (CVSS = 4.0 – 6.9): 1 Monat
- Niedrig (CVSS = 0.1 – 3.9): 3 Monate
Quelle: BSI C5, OPS-22 Zusatzkriterium
Das heißt: Wenn eine versteckte Bibliothek in einem von dir angebotenen Service einen CVSS-Score von 9.0 überschreitet und der Hersteller dafür einen Patch veröffentlicht hat, dann hast du laut dieser Kriterien maximal 3 Stunden Zeit, den Patch in Produktion einzuspielen.
Behörden, die zur kritischen Infrastruktur gehören (KRITIS), haben noch einmal deutlich kürzere Reaktionszeiten.
Schaffst du bzw. dein Team das?
Grund 2: Incidents und Bugs in Produktion
IT Service Management Prozesse (ITSM), vor allem der Bereich Incident-Management, haben oft eines gemeinsam: Sie sind extrem komplex. Es werden Kathedralen an Prozessen designed (BPMN ist geduldig), wirklich tolle Ideen verwirklicht, ITIL-Best Practices eingesetzt, genaue Formulare erstellt und mit der ITSM-Software realisiert. „Fülle bitte folgende 25 Felder aus, damit wir uns darum kümmern können“. Ein Fall ist mir besonders in Erinnerung geblieben:
Frühling 2023. Wir mussten zügig eine Firewallfreischaltung durchbringen, weil ein Projektleiter geschlafen hatte. Wir haben also einen Change eröffnet. Erst lag der Change mehrere Tage herum, bevor er Kommentarlos geschlossen wurde. Wir sprachen unseren Key Account Manager an. Er versuchte den Kollegen zu erreichen. Zunächst erfolglos. Nach mehreren Stunden dann die Nachricht: Es fehlte eine Telefonnummer im Change Formular, weshalb jetzt ein neuer Change geöffnet werden soll, der dann in ein paar Tagen umgesetzt würde.
Das fühlt sich an wie: Wenn die Hütte brennt, füll bitte ein Incident-Formular bei der Feuerwehr aus.
Aber wie sind deine ITSM-Prozesse aufgebaut. Wenn dein Team einen Bug gefixt hat. Wie lange dauert es, bis der Bugfix in Produktion ausgerollt ist? Wie lange dauert es, bis du durch Konfigurationsänderungen auf Sonderereignisse reagieren kannst, zum Beispiel DDoS-Attacken, ein Ansturm auf deinen Service oder eine Fehlkonfiguration eines anderen Services?
Grund 3: Der Desaster-Recovery Fall
Stell dir vor, die Produktion geht auf die Bretter. Wie lange dauert es, bis du deine Services wieder vollständig lauffähig hast?
Wenn du jetzt sagst, „das ist doch unrealistisch“: Ich habe während meiner Arbeit bei Kunden im Zeitraum zwischen 2018 und 2023 Jahre Rechenzentrumsausfälle durch Brände, Stromausfälle und Überflutungen mitbekommen. Auch Ausfälle ganzer Availability Zones bei Amazon in Frankfurt waren dabei. Dazu kamen dann noch Hackerangriffe, zum Beispiel DDoS-Attacken, das Ausnutzen von Schwachstellen. Das Einzige, von dem ich bisher verschont wurde, sind Ransomware-Angriffe.
Time to Market ist nicht so wichtig, aber die Auslieferungs- und ITSM-Prozesse …
Wenn ich in den letzten 10 Jahren DevOps eines gelernt habe, dann ist es folgendes:
Time to Market wird oft als Grund genannt, warum Unternehmen den Flow bzw. den Value Stream ihrer Arbeit optimieren sollten. Das ist das Verkaufsargument für die Manager, die glänzen wollen. Vereinzelt mag das in einem hart umkämpften Markt auch sinnvoll sein. In Wirklichkeit gibt es aber einen noch viel gewichtigeren Grund, denn jedes Unternehmen im Blick haben sollte, das IT im Einsatz hat: Der sichere Betrieb der angebotenen Services in Produktion.
Das schaffst du nur durch geölte Prozesse und Arbeitsweisen, optimierten CI/CD-Pipelines, Kommunikation und Führung sowie Software Engineering Praktiken in der Entwicklung und dem Betrieb. Time to Market ist nur das Vehicle, um etwas viel Größeres und Wichtigeres zu schaffen.
In Gesprächen mit Kunden stelle ich immer eine Frage: Wie unterscheiden sich eure Patch-, Bugfix- und Deploymentprozesse? Wenn die Antwort anders als „gar nicht“ lautet, dann haben wir ein enormes Verbesserungspotenzial identifiziert.
Unterscheiden sich diese Prozesse bei dir?