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 (Management, Entwicklung, Betrieb) 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. Mit all den Problemen und Verzögerungen und den draus resultierenden Folgen.
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 damals geplanten 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. Dies waren jedoch Projektmethoden, welche heute nicht mehr modern sind.
Zurück also zum DevOps und der agilen Arbeitswelt.
In der Softwareentwicklung haben sich agile Entwicklungsmethode (Scrum Methode) 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. Letzteres lässt sich durch eine hohe Automation bewältigen. Hier wiederum sind die teils strikte Trennungen zwischen Management, Betrieb und Softwareentwicklung eine Hürde. Vor allem da Änderungen unkompliziert und teils kopetenzüberschreitend statt finden sollten. 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. / Administration. Im Gegenzug greift der Betrieb in Entwicklungsnahen Tätigkeiten ein.
- Neu organisieren z.B. in Squad, Chapter und Tribes.
- Verantwortlichkeit neu verteilen z.B. Systemowner und Productowner.
Der Wunsch ist ganz klar, dass sich vieles so vereinfacht, dass theoretisch jeder alles machen kann. In der Realität ist es so, dass viele Aufgaben so automatisiert werden, dass weniger Ressourcen bei einem Release beansprucht werden müssen. Dies macht eine Planung einfacher und effizienter und ermöglicht auch kleiner Änderungen schneller in Betrieb nehmen zu können. Bugfixes oder eben leicht umsetzbare Kundenwünsche können somit zeitnah umgesetzt und realisiert werden.
Ganz neu ist das alles nicht. Zumindest nicht die Organisation. Was man sicherlich als Gruppe, Abteilung und Bereich kennt organisiert sich nun in Squad, Chapter und Tribes . Neu ist der Schulterschluss und die Zusammenlegung der unterschiedlichen Interessengruppen zwischen Management, Entwicklung und Betrieb. Somit kommen alle Beteiligten an einen 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 / Produkt zu arbeiten und sind damit in einem Chapter organisiert. Ein Squad wiederum besteht meist aus einer Fachrichtung: DBAs, Entwickler, Designer usw. Ein weiterer Ansatz. Etwas komplexer wird die Organisation nach dem Spotify Prinzip.
Ein organisatorischer Bestandteil aus der Scrum Methode ist der Productowner und Systemowner. Die Aufgabe beider Positionen ist im Grunde nicht anders als früher, als man es noch Abteilung nannte, auch. Der eine trägt die Verantwortung über die IT Systeme, der andere ist für die Entwicklung des Produktes verantwortlich. Der Scrum Master stellt nun in gewisser weise das Bindeglied beider Parteien dar. Er moderiert und organisiert die Sprints und Rertrospektive, welches die Basis für den Austausch und häufig einem gewünschte kontinuierlichen Verbesserungsprozess, ist.