Du kannst nicht „DevOps machen“, aber Du kannst z.B. die Teams entlang von Produkten und Value Streams auf den Kunden ausrichten. Bevor Du das tust (dazu später), solltest Du Dir die Frage stellen, warum DevOps für Dein Unternehmen überhaupt relevant ist. Für DevOps gibt es mindestens zwei gute Grunde:
- Silos zwischen Business, IT Entwicklung und Betrieb: Die einen wollen Flexibilität, die anderen Stabilität. Das Business will Beides. Brüche, Handovers und zersiedelte Prozesse überall. „Not my responsibility“. Wo ist der Value Stream – end to end? So kann es nicht weiter gehen.
- Dein nächster härtester Konkurrent könnte ein Unicorn mit einer disruptiven App sein: Unicorns sind fähig, sehr schnell mit neuen und qualitativ hochwertigen Dienstleistungen an den Markt zu gehen und schnell neue Ideen am Markt zu testen. In dieser „Digital Ecomomy“ ist es eben nicht der grosse Fisch, den den kleinen Fisch frisst, sondern der schnelle Fisch frisst den langsamen. Und: Keine Branche ist davon verschont. Und natürlich ist das nicht für alle Deine Produkte relevant (Bi-modale IT lässt grüssen).
Nachdem Du Dir über Dein „Warum?“ im Klaren bist und Dir für die Bereiche, wo dieses relevant ist, entsprechende Ziele gesetzt hast (und diese auch messen kannst), kannst Du zum Beispiel Folgendes tun:
- Deine Value Streams entlang von Produkten identifizieren – von der Vision, den Anforderungen bis hin in den Betrieb
- Cross-functional Teams schaffen und diese auf die Value Streams ausrichten und eine Kultur mit gemeinsamen Zielen schaffen (statt Dev: Flexibilität vs Ops: Stabilität)
- Die Grundlagen für Continuous Delivery schaffen, d.h.Entwicklungs- und Testplattformen sollen schnell zur Verfügung stehen, die Cloud (PaaS) ist die Grundlage dafür. Bis hin zu „Infrastructure as a Code“ und modularisierter Architektur
- Kontinuierlich Automatisierungspotential identifizieren und nutzen, z.B. Tests automatisieren, Deployments automatisieren
- Schnelle Feedbackloops einbauen, um Fehler früh zu identifizieren
- Eine Continuous Delivery Pipeline schaffen
- Mit einer entsprechenden „Tool Chain“ entlang der Delivery-Pipeline schaffen, ohne Brüche (sonst kein Continuous Delivery)
- Eine agile Kultur schaffen, neu auch mit Leuten aus dem Betrieb (welche lange dagegen angekämpft haben). Als erster Schritt kann das auch einfach mal ein Kanban Board sein, und dann lernen es die Leute mögen (Denn: Culture eats Strategy for Breakfast)
- Kontinuierlich Value Stream Mappings durchführen. Wo sind unser Bottlenecks? Wo können wir uns verbessern?
- Und last but not least: Realisieren, dass Du nicht zum vornherein wissen kannst, was funktioniert, sondern du auch ab und zu „fail safe“ Experimente eingehen musst um zu verstehen, was bei Dir funktioniert und was nicht.
Dies ein paar Beispiele, diese Liste liesse sich um viele weitere „DevOps Practices“ erweitern. Dabei soll es auch klar sein, dass DevOps nicht ein einmaliges Projekt ist, sondern eine Reise, die nie aufhört. Alles, was hilft, schneller (z.B. Time to Market) und besser (z.B. Service-Verfügbarkeit & Customer Experience) zu werden, und einen Lernprozess von innen zu etablieren (agile Kultur), nützt. Und Experimentieren ist dabei ein wichtiger Bestandteil, solange dahinter klare Ziele und eine Vision steckt. Funktioniert Kanban bei Dir? Don’t know. Try it and you find out. Klein anfangen und daraus wachsen.