Ops4Agile: Agiler Betrieb von Cloud-Plattformen im Managed-Service-Kontext

Publish date:

Wer im Kontext von Managed-Services Software mit agilen Prozessen entwickelt, braucht einen neuen Ansatz für den Betrieb von Cloud-Plattformen. Ops4Agile verzahnt Entwicklung und Betrieb durch vier wichtige Prinzipien.

Florian Bär, Capgemini
Florian Bär, Capgemini

Software wird heute verstärkt im Rahmen von agilen Prozessen entwickelt. Eine enge Verzahnung des IT-Betriebs mit der Softwareentwicklung, wie durch das DevOps-Paradigma gefordert, ist im Kontext von Managed-Services jedoch kaum realisierbar. Daher bedarf es für diesen Kontext eines neuen Ansatzes zum Betrieb von Cloud-Plattformen unter Berücksichtigung agiler Softwareentwicklungsprozesse. Ops4Agile entwickelt dazu ein bekanntes Implementierungskonzept des DevOps-Paradigmas weiter.

Ops4Agile stützt sich auf die äußerst konsequente DevOps-Implementierungsform des Site Reliability Engineerings (SRE) und ergänzt sie für den agilen IT-Betrieb im Kontext von Managed-Services um die folgenden vier Prinzipien: Team in the Middle, Human Interfaces, Agile Way of Working und Controlled Automation. Die Erweiterung um diese vier Prinzipien ist notwendig, um einen agilen IT-Betrieb im Kontext von Managed-Services zu ermöglichen.

Team in the Middle

Ops4Agile verteilt den agilen IT-Betrieb auf zwei Teams: Ein Agile-Tools-Team und ein Plattform-Team. Die Zussammenarbeit dieser beiden Teams bei der Erfüllung ihrer Aufgaben ist essentiell. Das Agile-Tools-Team verantwortet den Betrieb der zur agilen Softwareentwicklung erforderlichen Tools, z. B. für die Continous Integration und das Continous Delivery (CI/CD). Demgegenüber verantwortet das Plattform-Team den Betrieb der Plattform, auf welcher die neue Software zu betreiben ist. Häufig handelt es sich bei diesen Plattformen um Hyperconverged-Infrastructure-basierte und/oder Container-basierte Cloud-Plattformen. Die durch die Softwareentwicklung eingehenden Anforderungen an Tools und die Plattform werden durch den agilen IT-Betrieb umgesetzt. Sich ergebende Change- und Service-Requests für die zugrundeliegende IT-Infrastruktur werden an einen Basis-IT-Betrieb übertragen. Der Basis IT-Betrieb verantwortet die Bereiche Compute (z. B. die einer Cloud-Plattform zugrundeliegenden physischen oder virtuellen Instanzen), Storage (z. B. ein virtuelles Storage Area Network (vSAN) oder Objekt-basierter Storage) und Network (z. B. physische bzw. virtuelle Switches und Network Function Virtualisation (NFV)) nach traditionellen Vorgehensmodellen des IT-Service-Managements wie ITILv3.

Human Interfaces

Um eine effektive und effiziente Zusammenarbeit zwischen Softwareentwicklung und agilem IT-Betrieb sicherzustellen, ist jedem Team beider Seiten jeweils mindestens ein Site Reliability Engineer zuzuordnen. Die Site Reliability Engineers stellen damit das zentrale Bindeglied zwischen der Softwareentwicklung und dem agilen IT-Betrieb dar. Sie sind verantwortlich für die Definition und Absprache gemeinsamer Ziele wie etwa Service Level Agreements (SLAs). Das jeweilige agile Vorgehensmodell bestimmt dabei die Art und Häufigkeit dieser Absprachen.

Agile Way of Working

Der agile IT-Betrieb wählt ein agiles Vorgehensmodells (z. B. SCRUM). In Form von Epics bzw. User-Stories werden Change- und Service-Requests definiert und in regelmäßigen Sprints abgearbeitet. Diese Anforderungen an den agilen IT-Betrieb resultieren aus den von Softwareentwicklung und agilem IT-Betrieb gemeinsam definierten Zielen. Ein gemeinsames Backlog dient der Softwareentwicklung und dem agilen IT-Betrieb als Grundlage der agilen Zusammenarbeit. Sofern sich die Softwareentwicklung aus mehreren Teams zusammensetzt, sind die Einträge im Backlog durch den agilen IT-Betrieb zu aggregieren. Dadurch sollen doppelte Arbeitsschritte vermieden und das Automatisierungspotential erhöht werden.

Controlled Automation

Das Unternehmen, welches den Managed-Service auslagert, und der IT-Dienstleister, der den Managed-Service erbringt, sind rechtlich selbständige Unternehmen. Für das auslagernde Unternehmen muss daher stets nachvollziehbar sein, welche Änderungen an seiner IT-Infrastruktur durchgeführt werden. Nur dann kann es die Kontrolle über resultierende Kosten und technologische oder sicherheitsrelevante Folgen behalten. Entscheidungen über Änderungen an der IT-Infrastruktur sollten daher stets durch den IT-Dienstleister in Absprache mit dem auslagernden Unternehmen getroffen werden. Bei der Automatisierung dieser Änderungen mittels Infrastructure-as-Code sollten daher Kontroll- und Prüfmechanismen für das auslagernde Unternehmen implementiert werden.

Ops4Agile wurde bereits in mehreren Kundenprojekten implementiert. Es diente z. B. als Ansatz für die Erbringung von Managed-Services im Automobilbereich. Die hierbei gesammelten Erfahrungen im agilen Betrieb von Container-basierten Infrastrukturen sind positiv.

Eine detailliertere Beschreibung von Ops4Agile erschien in der Zeitschrift HMD – Praxis der Wirtschaftsinformatik in Band 57, Ausgabe 5/2020. Siehe hierzu: https://link.springer.com/article/10.1365/s40702-020-00649-0.

Zum Einsatz von Ops4Agile bietet das deutsche Cloud Center of Excellence individuelle Beratung an. Kommen Sie bei Interesse gern auf mich zu.

 

Weitere Posts

Sustainability in der Automobilindustrie: Was Kunden erwarten und Hersteller leisten

Ralf Blessmann
Date icon August 3, 2021

Nachhaltigkeit gewinnt für die Automobilindustrie immer mehr an Bedeutung – nicht zuletzt, da...

Arbeitswelt

Arbeitswelt der Zukunft im Energiesektor | Teil 1 – Upskilling

Iris Brückner
Date icon August 2, 2021

Energieversorger setzen auf die Qualifizierung ihrer Belegschaft, um die neuen...

Karriere

Eine gemeinsame Sprache: Coding Guidelines in Software Engineering

Capgemini Karriere
Date icon Juli 29, 2021

Die Codequalität zu verbessern und den Code nachhaltig sauber halten, ist vielen Teams ein...