You can not “Do” DevOps, but you can…
Du kannst nicht “DevOps machen”, aber Du kannst z.B. Deine Teams entlang von Produkten und Value Streams 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:
- Dein nächster härtester Konkurrent könnte ein Startup mit einer disruptiven App sein. Diese Firmen 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).
- Die IT-Abteilung in Deinem Unternehmen ist gespalten zwischen Entwicklern und Betrieb. Die einen wollen Flexibilität, die anderen Stabilität. Das Business will Beides. Brüche und zersiedelte Prozesse überall. Wo ist der Value Stream – end to end? So kann es nicht weiter gehen.
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 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 danach ausrichten und eine Kultur mit gemeinsamen Zielen schaffen (statt Flexibilität vs 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“
- Kontinuierlich Automatisierungspotential identifizieren und nutzen, z.B. Tests automatisieren, Deployments automatisieren
- Schnelle Feedbackloops einbauen, um Fehler früh zu identifizieren
- Schlussendlich eine Deployment-Pipeline schaffen
- Eine “Tool Chain” entlang der Deployment Pipeline schaffen, ohne Brüche (sonst kein Continuous Delivery)
- Eine agile Kultur schaffen, neu auch mit Leuten aus dem Betrieb (welche lange dagegen angekämpt 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, Bottlenecks identifizieren und eliminieren
Dies ein paar Beispiele, diese Liste liesse sich um viele weitere erfolgreiche “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) zu werden, 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.