Die DASA DevOps-Prinzipien als Basis für ein modernes IT-Kompetenz- und Skillframework

DevOps als Kunstwort aus Development und Operations ist kein neues Framework. Es beschreibt eine Philosophie, die die beiden "Namensgeber" (Entwicklung und Betrieb) zusammenbringt [1].

Im Unterschied zu bestehenden Frameworks wie ITIL, COBIT oder Scrum gibt es keinen Rechteinhaber und auch keine Institution, die sich als inhaltlicher Eigentümer des Begriffes "DevOps" sehen kann. Insofern existieren weder allgemeingültige Definitionen noch Vorgaben, was eine IT-Organisation tun sollte, um "DevOps anzuwenden oder einzuführen". Eine breite Community hat sich etabliert, um eigene Erfahrungen, praktische Überlegungen und Sichtweisen auszutauschen und so diese Philosophie in aller Öffentlichkeit und gemeinsam weiter zu entwickeln. In deutschen Unternehmen etablieren sich mehr und mehr Initiativen, die sich mit den Inhalten und Möglichkeiten von DevOps beschäftigen.

Prinzip 1: Customer-Centric Action

It is imperative nowadays to have short feedback loops with real customers and end-users, and that all activity in building IT products and services centers around these clients. To be able to meet these customers’ requirements, DevOps organizations require the guts to act as lean startups that innovate continuously, pivot when an individual strategy is not (or no longer) working, and constantly invests in products and services that will receive a maximum level of customer delight. [2]

Kundenzentrierte Aktionen im DevOps bedeutet, dass die Feedbackzyklen mit Kunden und Anwendern immer kürzer und direkter werden. Aus der agilen Softwareentwicklung ist dieser Ansatz bekannt und hat sich als sehr erfolgreich herausgestellt. Um die gesamte Wertschöpfungskette in der IT zu unterstützen, muss das Feedback bis zur produktiven Nutzung ausgedehnt werden. Dabei werden bspw. A/B-Tests eingesetzt oder einfach das Nutzungsverhalten analysiert. Alle Aktivitäten der Serviceerbringung müssen sich an den Kunden orientieren. Die beschriebene Ausrichtung an der Wertschöpfungskette muss zu einer permanenten Überprüfung der Aktivitäten führen, so dass überflüssige Arbeiten schnell erkannt und eliminiert werden. IT-Organisationen müssen dazu die Fähigkeit erlangen, sich ähnlich wie junge Start-ups kontinuierlich neu zu erfinden und schnell auf veränderte Einflüsse zu reagieren.

Konkret heißt das, mit Blick auf die Verschwendungsarten aus dem Lean Management den Fokus auf die Vermeidung von Verschwendung zu legen. Das resultiert in einer kontinuierlichen Weiterentwicklung der Strategie und den daraus abgeleiteten Aktivitäten, auch durch kontinuierliche Investition in Produkte und Services mit Blick auf ein Höchstmaß an Kundenzufriedenheit. Ziel sollte es sein, das Thema Servicequalität stärker in den Köpfen der IT-Mitarbeiter zu verankern. Dazu gehören dann neben der Anpassung in der eigentlichen Umsetzung auch das Umdenken in der täglichen Arbeit der Mitarbeiter und die Offenheit für neues Vorgehen. Die Kundenorientierung sollte darüber hinaus auch organisatorische Veränderungen nach sich ziehen.

Prinzip 2: Create with the End in Mind

Organizations need to let go of waterfall and process-oriented models where each unit or individual works only for a particular role/function, without overseeing the complete picture. They need to act as product companies that explicitly focus on building working products sold to real customers, and all employees need to share the engineering mindset that is required actually to envision and realize those products. [2]

Mit dem Prinzip "Schon zu Beginn an das Ergebnis denken" versucht DevOps, die "klassische" prozessorientierte Vorgehensweise mit individuellen Rollen und Funktionen in eine produktorientierte Organisation zu verwandeln. Diese agiert mit dem Ziel, funktionierende Produkte an Kunden zu liefern und mit einer dazu passenden Denkweise zu agieren. Diese Zielsetzung manifestiert sich in der entsprechenden Aufbau- und Ablauforganisation. Diese muss den Überblick über das übergeordnete und angestrebte Ergebnis sicherstellen. Wichtig ist, dass die beteiligten Mitarbeiter diese durchgängige Sichtweise verinnerlicht haben, um daraus ableitend Produkte und Service zu erschaffen.IT-Organisationen müssen als Produktunternehmen agieren, die sich explizit darauf konzentrieren, funktionierende Produkte zu entwickeln, die an Kunden geliefert werden. Alle Beteiligten müssen die umfassende Denkweise teilen, die erforderlich ist, um diese Produkte zu konzipieren und zu realisieren. Es gibt ein Team für ein Produkt und es übernimmt die Verantwortung für alle Prozesse, Funktionen und Aktivitäten innerhalb dieses Produktes. Dieser Ansatz verfolgt das Ziel, das Ganze zu sehen und zu erkennen und nicht nur ein Teil einer Prozesskette oder einer Funktion zu sein. Weiterhin erreicht dieser Ansatz die drastische Reduzierung der Kommunikation mit anderen Abteilungen und sorgt durch die permanente Verkürzung und Verstärkung der Rückkopplungsschleifen für ein immer stabileres und sichereres Arbeitssystem.

Prinzip 3: End-To-End Responsibility

Where traditional organizations develop IT solutions and then hand them over to Operations to deploy and maintain these solutions, in a DevOps environment teams are vertically organized such that they are fully accountable from concept to grave. IT products or services created and delivered by these teams remain under the responsibility of these stable groups. These teams also provide performance support, until they become end-of-life, which greatly enhances the level of responsibility felt and the quality of the products engineered. [2]

Eine Ende-zu-Ende-Verantwortung bedeutet aus Sicht von DevOps, dass die traditionelle Trennung von Entwicklung und Betrieb zugunsten von voll verantwortlichen Teams ("Von der Wiege bis zur Bahre") aufgelöst wird. Diese Teams entwickeln und betreiben die Services, ebenso wie sie Support leisten. Dieser Umstand erhöht deutlich das Niveau der gefühlten und realen Verantwortung und somit die Qualität der entwickelten Produkte und Services, denn im Sinne des RACI-Modells ist sowohl die Ergebnis- als auch die Durchführungsverantwortung in einem Team [5].

Die IT erlangt mit dieser Sichtweise wieder den Fokus auf das IT-Produkt und den Kunden zu setzen. Durch produktverantwortliche Teams können stabilere und qualitativ hochwertigere IT-Produkte als bisher entwickelt werden. Hierbei müssen bestehende Organisationen, Prozesse und Arbeitsweisen analysiert und dem Prinzip angepasst werden. Eine neue Denkweise innerhalb des Unternehmens ist dabei erforderlich. Je nach genutztem IT-Produkt können hierbei unterschiedliche Zielsetzungen angegangen werden.

Prinzip 4: Cross-Functional Autonomous Teams

In product organizations with vertical, fully responsible teams, these teams need to be entirely independent throughout the whole lifecycle. That requires a balanced set of skills and also highlights the need for team members with T-shaped all-round profiles instead of old-school IT specialists who are only knowledgeable or skilled in for example testing, requirements analysis or coding. These teams become a hotbed of personal development and growth. [2]

Die Forderung nach crossfunktionalen, autonomen (vertikal organisierten) Teams aus Sicht von DevOps ist eine Weiterentwicklung agiler Ansätze. Scrum als bekanntestes agiles Framework setzt ebenfalls auf diese Teamorganisation. Um eine hochwertige Serviceerbringung sicherzustellen, ist ein fein ausbalanciertes Set an Wissen und Fähigkeiten notwendig. Es ist also ein sehr gutes T-Shape-Profil im Team und bei den Teammitgliedern notwendig anstelle des klassischen IT-Spezialisten.

Cross-funktionale, autonome Teams können somit Innovationen ganzheitlich denken. Gleichzeitig können sie das gesamte Aufgabenspektrum über den kompletten Produktlebenszyklus eigenverantwortlich und in effizienter Zusammenarbeit erledigen. Voraussetzung ist dabei der Kulturwandel in den IT-Organisationen. Er wird begleitet durch eine schlanke Teamorganisation und -steuerung sowie die vielseitigen Fähigkeiten der Mitarbeiter. So wird das Team gemeinsam zum Unternehmenserfolg beitragen.

Prinzip 5: Continuous Improvement

End-to-end responsibility also means that organizations need to adapt continuously in the light of changing circumstances (e.g. customer needs, changes in legislation, new technology becomes available). In a DevOps culture, a strong focus is put on continuous improvement to minimize waste, optimize for speed, costs, and ease of delivery, and to continuously improve the products/services offered. Experimentation is therefore an important activity to embed and develop a way of learning from failures is essential. A good rule to live by in that respect is "if it hurts, do it more often". [2]

Das Prinzip von kontinuierlicher Verbesserung beschreibt aus Sicht von DevOps die Tatsache, dass sich moderne IT-Organisationen permanent an verändernde Bedingungen (Kundenanforderungen, technologische Rahmenbedingungen, Gesetze und Verordnungen, usw.) anpassen können müssen. DevOps setzt dabei auf Prinzipien von Lean Management, um Verschwendung zu vermeiden sowie Kosten zu senken und die Liefergeschwindigkeit zu erhöhen. Experimente werden gefördert und eine neue Fehlerkultur (Fail fast, fail offen) etabliert, die darauf abzielt, aus Fehlern zu lernen.

Für kontinuierliche Verbesserung müssen Rahmenbedingungen in den IT-Organisationen geschaffen werden. Eine Kultur, in der Experimente und Lernen aus Fehlern akzeptiert und unterstützt wird, in der Transparenz durch Kennzahlen vorherrscht und in dem ein großes Augenmerk auf die Unternehmensumwelt gelegt wird. Ziel ist es, frühzeitig Veränderungsbedarfe zu erkennen und diese durch kontinuierliche Anpassung und Verbesserungen zu jeder Zeit annehmen zu können. Diese Grundausrichtung benötigen IT-Organisationen für ihren individuellen Erfolg in dieser schnelllebigen Welt. Ein ideales Vorgehen (Best Practice) gibt es dabei nicht. Jedes Unternehmen muss selbst einen Weg als eigene Herausforderung und große Chance für den individuellen Erfolg finden.

Prinzip 6: Automate Everything You Can

To adopt a continuous improvement culture with high cycle rates and to create an IT organization that receives instant feedback from end users or customers, many organizations have quite some waste to eliminate. Fortunately, in the past years, enormous gains in IT development and operations can be made in that respect. Think of automation of not only the software development process (continuous delivery, including continuous integration and continuous deployment) but also of the whole infrastructure landscape by building next-gen container-based cloud platforms that allow infrastructure to be versioned and treated as code as well. Automation is synonymous with the drive to renew the way in which the team delivers its services. [2]

"Automatisiere alles was du kannst!" ist eine im Prinzip unmissverständliche Forderung. Sie setzt unter anderem auf der kontinuierlichen Verbesserung auf bzw. unterstützt diese, um schnelle Lieferzyklen zu realisieren, die dann zu sofortigem Feedback durch die Kunden führen. Die Automation umfasst dabei nicht nur den Entwicklungsprozess, sondern auch die darunterliegende Infrastruktur. Unter dem Begriff "Infrastructure as code" wird damit eine neue Art der Servicelieferung beschrieben. Standardisierung und Automation ist ein wesentliches Mittel, um die Voraussetzung für die erfolgreiche Adaption einer DevOps-Kultur zu schaffen.

Die weitreichende Forderung, alles, was möglich ist, zu automatisieren, stellt hohe Anforderungen an die IT-Organisation. Zunächst bezieht sich das auf die Development-Pipeline, da diese einen zentralen Prozess in der Softwareentwicklung darstellt. Die Integration von Continuous Delivery führt zu einer Anpassung der angrenzenden Prozesse und Systeme. Die Integration von On-Premise- sowie Cloud-Komponenten erfordert dann ein hohes Skillset der DevOps-Ingenieure, sodass zwar durch die Automatisierung Tätigkeiten auf die Systeme verlagert werden, aber neue und anspruchsvollere Tätigkeitsgebiete entstehen. Die Integration von DevOps in das Unternehmen endet hierbei nicht mit der Auslieferung von Softwarepaketen, sondern kann darüber hinaus weitere Relevanz erhalten. Verändert sich die Unternehmenskultur von der eher klassischen und manuellen Ausrichtung hin zu Unternehmensprozessen mit besonderem Fokus auf Automatisierung, können die freien Ressourcen zur Verbesserung der Marktposition genutzt werden.