Auch Software Projekte werden durch das Wasserfall Modell mit ähnlicher Wahrscheinlichkeit realisiert. Meines Erachtens fällt diese relativ tief aus, die für interne und externe Kunden unbefriedigend ist. Aus dieser misslichen Lage führt der Agile- / DevOps-Ansatz. Nämlich deshalb, weil DevOps nicht projekt-, sondern produktbezogen ist, fällt die Realisierungswahrscheinlichkeit höher als 45% aus.
Meinen ersten Wow-Effekt aus der CAS DevOps 2 Vorlesung des Datums 04.04.2020 hatte ich dadurch, als ich hörte, dass die Gewinnwahrscheinlichkeit im Glückspiel „Black Jack“ ca. 48% betrüge und das noch mit einer ausgeklügelten und mathematischen Strategie. Analog pendelt sich die Realisierungsrate jeglicher Projekte bei ca. 45% ein. In der IT-Welt (spez. dasWasserfall Modell) sollte dies ähnlich ausfallen. Die Zahl 45% ist signifikant tief, suboptimal und unzureichend.
Mein zweiter Wow-Effekt: Unsere moderne Welt wird durch die Parameter (VUCA: Volatility, Uncertainty, Complexity, Ambiguity) umrissen. Die Dynamik an Entwicklungen hat in der IT (Cloud Computing & Virtualisation) ungeahnte Dimensionen erreicht, die einen effektiven, effizienten und pragmatischen Ansatz zur Projektrealisation von weit mehr als 45% heute und morgen anstrebt.
Der Zeitgeist schreit nach kostengünstigen Produkten, die die Faktoren „reduce time to market, eliminate fragility, reduce technical dept“ erfüllen sollten. Im optimalen Fall wäre ein neuer Markt (marktgerechtes Produkt mit Nischendasein) sprich „Blue Ocean“ erstrebenswert. So ist man für gewisse Zeit der Konkurrenz voraus könnte durch diesen Vorsprung viel Potential heben (Up- & Cross-Selling) und viel Geld gewinnen. Und im Sinne der Corona Krise ist der Stellenwert der Virtualisierung, Clouding Computing, Infrastruktur als Code, Lean Produktion und Entwicklung agiler Software-Entwicklungsmethoden höher zu bewerten. Auch dieser Punkt setzt eine höhere Realisierbarkeit von «Projekten» voraus. Es sind sicherlich vielmehr Punkte, die für einen Paradigmenwechsel sprechen würden, aber für mich sind die oben erwähnten Faktoren (Zeitgeist, Dynamik, VUCA, Fragility, Technical Dept, Time to market) zentral und prädestiniert, um in die DevOps Welt (Development, IT-Operations, Quality Assurance) eine Brücke (Beitragsbild / Titelbild: Eigenaufnahme) zu schlagen und zu fokussieren.
- Paradigmenwechsel (DevOps ist Produkt getrieben): Die DevOps wurde ins Leben gerufen, um mit dem Ansatz „Projekt“ zu brechen. D.h. die Software Produkte werden nicht mehr projekt-, sondern produktbezogen realisiert. Dieser Ansatz kommt aus dem agilen Umfeld und er gibt vor, dass aus einzelnen Sprints „Shippable Packages“ dem Kunden – hochwertige Produkte – in gewünschter Qualität und JIT (Just in Time) entwickelt, gebildet, getestet und in die Produktion deployt werden.
- Paradigmenwechsel (Infrastruktur als Code etablieren): Dieser fundamentale Wandel setzt das Mangen (Scaling & Maintainability) von Infrastruktur als Code (Skripte) voraus. Somit können Bottlenecks einfacher eruiert, Mankos und Inkorrektheiten im System rascher identifiziert und eliminiert werden.
Das Akronym „DevOps“ setzt sich aus den Wörtern (Development und IT Operations) zusammen. Die DevOps wird durch CALMS (Culture, Automation, Lean Production, Measurement, Sharing) modelliert und besitzt drei essenzielle Elemente wie Kultur (Leute), Organisation (Prozesse), Automatisation (Technologie). Ein multipotentes DevOps Team (E-shaped Staff) besteht aus Product Owner, Bussines Analyst, Developer, Datenbank Spezialist, Test QA, Support Spezialist, Operation Spezialist, Security und Infrastruktur Spezialist, die kontinuierlich Optimierung und Perfektion (Lean Produktion, Kanban) anstreben und somit jegliche Fehler im Vorfeld identifizieren und eliminieren, bevor sie in die Produktionsumgebung gelangen.
Insight & Outlook: Im ersten Schritt sollte die empirische DevOps bedingt durch die VUCA-Welt kontinuierlich ausgebaut und im zweiten Schritt müssten die «Analytische DevOps, Theoretische DevOps, Meta DevOps, Kreativität, Innovation, Neugier, Inspiration» nachgezogen werden. Diese zwei Schritte könnten Quelle für neues Wissen, moderne Technologien und passende Tools werden, die kontinuierlich verbessert und veredelt sein sollten. Und das im Sinne eines exzellenten Realisierbarkeitsgrades eines «Projektes» mit höchster Güte.
