devOps
Heute, erneut eine Ausschreibung erhalten mit Position als: devOps.
Was ist ein DevOps
Provokant muss man wohl festhalten, es gibt per se keinen DevOps. Eine solche Rolle kann es nicht geben. Scheinbar ist immer noch der Wunsch nach einem Alleskönner in der IT gegeben. Dieser Wunsch ist jedoch falsch und so nicht umsetzbar. Vielleicht etwas besser Verständlich: Mit einem Beinbruch würde niemand auf die Idee kommen, zu einem Augenarzt zu gehen, nur weil er sich als Arzt bezeichnet.
In der IT gibt es viele unterschiedliche Fachrichtungen und Tätigkeitsfelder. Grob lässt es sich vereinfacht in 4 Bereiche unterteilen:
- Der Kunde
- Das Management
- Die Entwicklung
- Der Betrieb
Der Kunde möchte eine Lösung und hat konkrete Vorstellungen mit der er sich an den Lieferanten wendet.
Das Management kümmert sich um die Projektleitung. Organisiert die Aufgaben, Anforderungen und den organisatorischen Ablauf. Kapazitätsplanung und Budgetplanung als Stichworte angeführt.
Die Entwicklung wiederum schreibt die Software auf Basis der Anforderung des Produktmanagements und/oder Kunden oder auch Produktdesigner. Die fachliche Anforderung wird von ggf. einem nicht technisch tief versierten Mitarbeiter definiert. Hier liegt teils schon eine grosse Diskrepanz zwischen dem Machbaren und dem Gewünschten und erfordert so manches mal höchste Kreativität in der Umsetzung.
Der Betrieb wiederum kümmert sich darum, dass diese Software läuft und erreichbar ist. Die Planung der Rechnersysteme und Infrastruktur, eingreifen bei Störungen und auch Absicherung des Systeme sind hier Alltag.
Diese 3 Verantwortungsbereiche sind organisatorisch häufig getrennt. Zudem bestanden ebenfalls teils sehr starre Betriebsabläufe welche zum einen die Kommunikation aber auch eine flexible Arbeitsweise im Projekt behinderten. In der heutigen Zeit ist Time to Market noch wichtiger, als es schon vor vielen Jahren war. Entsprechend müssen sich die Arbeitsmethoden verändern. Ich denke, dass die Elbphilharmonie oder der Berliner Flughafen gute Beispiele für Komplexität und Abhängigkeiten sind, wie Sie auch in der Softwareentwicklung in ähnlicher Form zu finden sind.
Beispiel Berliner Flughafen: Ein wesentlicher Grund für die Verspätung und Kostenexplosion solcher Projekte sind externe Veränderungen von Anforderungen und Rahmenbedingungen. So z.B. wurde das Projekt zunächst mit den Anforderungen aus dem Jahr 2006 und früher geplant, kalkuliert und technisch betrachtet, die Statik berechnet. Während der Bauphase ergaben sich neue Bestimmung u.a. wegen des Brandschutzes. Die notwendigen Anpassungen wiederum sorgten für eine Kettenreaktion im Gesamtprojekt. In Kürze gesagt, durch die notwendigen Änderungen mussten bauliche Änderungen durchgeführt werden, welche mit der berechneten Statik nicht mehr vereinbar waren. Somit musste die Architektur neu angegangen werden, was wiederum weitere Problem mit sich brachte. Stärker Pfeiler machen die Gesamtkonstruktion viel schwerer und damit passt das Fundament nicht mehr zum Flughafengebäude. Ähnliche Problematik gibt es natürlich auch in der IT / Softwareentwicklung aber auch Lösungswege um sich mit dem Auseinandertriften zum Schluss wieder an zu nähern.
Zurück also zum DevOps.
In der Softwareentwicklung haben sich agile Entwicklungsmethode zunehmend etabliert. Hierbei ist das bestreben durch Änderung u.a. in der Management Struktur und Reduktion der Gesamtanforderung zu kleineren Teilschritten zu gelangen. Damit kann man Anforderungen und Anpassungen schneller implementieren. Dies erfordert jedoch mehr Aufwand in der Integration und Test. Hierfür wiederum sind die teils strikte Trennungen zwischen Management, Betrieb und Softwareentwicklung eine Hürde. Beim DevOps Gedanken geht es im Grunde um folgende Punkte:
- Schulterschluss zwischen den jeweiligen Bereichen. Engere Zusammenarbeit und gemeinsame Umsetzung.
- Verständnis für die Anforderung der anderen Bereiche
- Aufbau von Werkzeugen und Automatisierung CI / CD, Kubernets, Docker etc.
- Damit verbunden übergreifende Tätigkeiten. Entwickler übernehmen Teile des Rollouts und Test.
- Neu organisieren z.B. in Squad, Chapter und Tribes.
- Verantwortlichkeit neu verteilen z.B. Systemowner und Productowner.
Ganz neu ist das alles nicht. Zumindest nicht die Organisation was man sicherlich als Gruppe, Abteilung und Bereich kennt. Neu ist der Schulterschluss und die Zusammenlegung der unterschiedlichen Interessengruppen zwischen Management, Entwicklung und Betrieb. Somit kommen alle Beteiligten an einem Tisch und der Austausch findet direkter Statt. Die Werkzeuge wiederum ermöglichen eine effizientere Arbeit für alle Parteien. So also finden sich in einem Squad mehrere Personen aus den unterschiedlichen Bereichen um direkter Miteinander an einem Projekt zu arbeiten.