Der digitale Wandel beeinflusst auch das IT-Service-Management. Die Verzahnung von Entwicklung und Betrieb („Development & Operations“, kurz DevOps) spielt eine immer größere Rolle. Häufig stellen sich die Verantwortlichen jedoch eine Frage: Welchen Mehrwert birgt DevOps in sich, oder doch nur Gefahren? Zu den Ursachen für etwaige Bedenken zählt unter anderem die Infragestellung der Stabilität des IT-Betriebs. Angebote aus der Cloud werden mit einem Angriff auf die eigene IT gleichgesetzt und gestandene Change Manager können sich eine weitere Verkürzung und Vereinfachung der Prozesse nicht mehr vorstellen. Dabei lässt sich bei Betrachtung des Bereichs „Entwicklung und Betrieb von Applikationen“ feststellen, dass es durchaus gute Gründe gibt, sich mit den Inhalten von DevOps zu befassen.
Im Gegensatz zu den bereits bestehenden Frameworks wie Cobit oder Scrum existieren weder Rechteinhaber noch Institutionen als inhaltlicher Eigentümer von DevOps. Das bedeutet, dass es keine allgemeingültigen Definitionen und Vorgaben gibt, was eine IT-Organisation tun sollte, um die DevOps-Ansätze effektiv umzusetzen. Mittlerweile hat sich eine eigene Community gebildet, die sich mit dem Thema auseinandersetzt und es mit Open-Source-Anwendungen weitertreibt. Die sogenannte DevOps Agile Skills Association (Dasa) unterstützt diese Bewegung mit einem Ausbildungskonzept, das Hinweise gibt, wie IT-Organisationen sich und ihre Mitarbeiter in Richtung DevOps entwickeln könnte.
So befasst sich ein Prinzip des Ausbildungskonzepts von Dasa (siehe auch die Grafik zum Beitrag hier) mit der Überführung der konventionellen prozessorientierten Vorgehensweise mit individuellen Rollen und Funktionen in eine produktorientierte Organisation. Das Ziel: Die Lieferung funktionierender Software-Produkte an den Kunden sowie die Handlung nach einer entsprechenden Denkweise. Diese Zielsetzung manifestiert sich in der passenden Organisation. Die typischerweise anzutreffende Prozessorganisation mit Arbeitsteilung und Fokussierung auf Aktivitäten ist einer hohen Kundenzufriedenheit nicht zuträglich. Vielmehr verfolgen die einzelnen Prozessteilnehmer eigene Ziele und sind häufig nur an der Ausführung der ihnen beschriebenen Prozessschritte interessiert – der Blick über den Tellerrand fehlt. In einer an DevOps-Ideen ausgerichteten IT-Organisation hingegen wandelt sich die Orientierung vom Spezialistentum hin zu einer Ausrichtung am Ergebnis. Auch die Organisation verändert sich dabei von der Funktionsorientierung hin zu einem teambasierten Aufbau. Zeitgleich wird der Fokus von Projekten auf Produkte verschoben. Arbeitsorganisation bezieht sich demnach zukünftig mehr auf Teams als auf Einzelne.
Ein weiterer wichtiger Aspekt ist die sogenannte End-to-End Responsibility: Aus Sicht von DevOps bedeutet dies, dass die bisher bekannte Trennung von Entwicklung und Betrieb zugunsten von voll verantwortlichen Teams verändert wird. Die Teams entwickeln und betreiben Services, leisten Support und übernehmen demnach eine größere Verantwortung. Die herkömmlich in Prozessen und Abteilungen aufgeteilten Aktivitäten sowie die auf viele Schultern verteilte Verantwortung werden in einem Service-Team zusammengeführt. Ein sogenanntes Business Service Team führt alle Tätigkeiten für die Entwicklung und den Betrieb eines Service eigenverantwortlich durch. Ihm obliegt die gesamte Verantwortung.
Ein weiterer Aspekt des DevOps-Ansatzes ist die Weiterentwicklung agiler Ansätze mit cross-funktionalen, autonom agierenden Teams. Als wohl bekanntestes Framework zählt hierfür die Scrum-Methode, das ebenfalls auf diese Art von Organisation aufsetzt. Um eine qualitativ hochwertige Dienstleistung erbringen zu können, ist ein umfassender Satz an Wissen und Fähigkeiten notwendig, mit anderen Worten: Ein sehr gutes T-Shape Know-how wird anstelle des gewöhnlichen IT-Spezialisten benötigt. Damit verwandeln sich die Anforderungen an die Mitarbeiter noch stärker und es bedarf einer intensiven sowie umfangreichen Personal- und Organisationsentwicklung. DevOps setzt dabei auf die Prinzipien von Lean Management, um Verschwendung zu vermeiden, Kosten zu senken und Liefergeschwindigkeiten zu erhöhen. Gleichzeitig rückt mit DevOps eine neue Fehlerkultur in den Mittelpunkt, bei der die Lerneffekte aus Fehlern positiv bewertet werden, denn es stehen Stimulanzien fürs Experimentieren im Zentrum.
Ein weiteres Prinzip setzt auf die Automatisierung von Tätigkeiten. Damit sollen schnellere Lieferzyklen ermöglicht werden, die wiederum zu einem sofortigen Feedback durch die Kunden führen. Die Automation umfasst dabei nicht nur den Entwicklungsprozess, sondern auch die dazugehörige Infrastruktur („Infrastructure as a Code“).
Fazit
Die Betrachtung der Thematik macht deutlich: DevOps kann als Möglichkeit verstanden werden, das IT-Service-Management um agile und schlanke Prinzipien zu bereichern. IT Operations sowie Change, Configuration und Release Management können beispielsweise durch die Automatisierung eine kontinuierliche Lieferung und eine Verkürzung des Releasezyklus erreichen und die erfolgreiche Produktivsetzung stärker absichern. Eine durch das gesenkte Fehlerrisiko verbesserte Überführung der Services in den operativen Betrieb hilft auch den Prozessen im Incident und Problem Management. Gerade hierbei ist es wichtig, dass die Mitarbeiter rollenbasiert arbeiten und wissen, welche Verantwortlichkeiten und Aufgaben sie in den jeweiligen DevOps haben, um diesen gerecht werden zu können.
In der aktuellen Ausgabe 4/2017 von d1g1tal AGENDA haben wir ein Interview zu DevOps publiziert, dass der Nachfrage nachgeht, in wie weit diese Methode im Rahmen von Systems Engineering eine Rollen spielen könnte. Heft bestellen unter d1g1tal.de/abo.
