dark

Die DASA-DevOps-Prinzipien

Avatar

Im 1. Teil unserer Artikelserie werden die DASA-DevOps-Prinzipien im Überblick dargestellt. Betrachtet man alle Prinzipien und Zusammenhänge, hat man eine solide Basis für die Entwicklung in Organisation und Personal geschaffen.

DevOps als Kunstwort beschreibt eine Philosophie, die die beiden Namensgeber Entwicklung und Betrieb zusammenbringt. Das Ziel ist es, kontinuierliche Softwarebereitstellung sicherzustellen, um schneller auf Marktveränderungen reagieren zu können und Kundenanforderungen besser gerecht zu werden. Dabei sind die gegenläufigen Ansätze einer agilen Softwareentwicklung, nämlich eine schnellere und häufigere Lieferung neuer Features und der Anspruch an einen sicheren und stabilen Betrieb, in Einklang zu bringen. In der Praxis kann das Verständnis dieser Zielsetzung noch verbessert werden: Häufig wird DevOps lediglich als Aufbau einer kontinuierlichen Bereitstellung von Applikationsänderungen verstanden und damit eher auf die technische Sicht reduziert. Die erfolgreiche Betrachtung des Lebenszyklus einer Anforderung der Fachbereiche von der ersten Formulierung bis zur produktiven Nutzung im Live-System erfordert jedoch einen umfassenderen Blick. DevOps baut also eine Brücke zur Zusammenarbeit zwischen Kunden, Entwicklung und Betrieb, um eine hochperformante IT-Organisation zu schaffen.

Im Unterschied zu bestehenden Frameworks wie ITIL oder Scrum ist DevOps kein neues Framework. Es gibt weder einen Rechteinhaber noch eine Institution, die sich als inhaltlicher Eigentümer des Begriffes DevOps sehen kann. Auch bei genauerer Betrachtung sucht man rechtliche Hinweise wie ® bei ITIL oder ™ wie beim Scrum-Guide vergeblich. Insofern existieren weder allgemeingültige Definitionen noch Vorgaben, was eine IT-Organisation tun sollte, um DevOps anzuwenden oder einzuführen. Eine wachsende 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, Gestaltungsmöglichkeiten und Vorteilen von DevOps beschäftigen. Die DevOps-Agile-Skills-Association (DASA) unterstützt diese Bewegung mit einem Kompetenz-Framework für IT-Mitarbeiter. Dieses Kompetenz-Framework basiert auf sechs Prinzipien und wird in einem modernen Ausbildungskonzept in die Praxis umgesetzt. Das Ziel der DASA ist die Bildung und Unterstützung einer offenen und weltweit präsenten sowie aktiven DevOps-Community. Diese wird von den Mitgliedern getragen und steht allen Interessierten zur Teilnahme offen, um u.a. das Kompetenz-Framework weiter zu entwickeln. Zur Erreichung dieses Zieles ist die DASA in folgenden Themen aktiv:

  • Förderung eines Kompetenz-Frameworks für DevOps, basierend auf einem Set von Prinzipien.
  • Entwicklung und Verbreitung eines herstellerunabhängigen DevOps-Ausbildungskonzeptes für IT-Professionals.
  • Verständnis und Bewusstsein für die Notwendigkeit zur Entwicklung von aktuellen Kompetenzen und Skills wecken.
  • Qualitätssicherung für Seminare und Trainings durch ein allgemein verfügbares Zertifizierungsschema für das DevOps-Kompetenz-Framework.
  • Entwicklung eines passenden Trainingskonzeptes für die jeweiligen Rollen im Framework.

Die DASA-DevOps-Prinzipien beschreiben grundlegend, wie eine IT-Organisation sich und vor allem seine Mitarbeiter in Richtung DevOps entwickeln sollte. In diesem Beitrag wird dazu ein Überblick gegeben, bevor im Folgebeitrag das Kompetenz-Framework detaillierter betrachtet wird. Während also die sechs Prinzipien eher in Richtung einer organisationsweiten Betrachtung gehen, zielt das Kompetenz-Framework auf die Ausbildung der Mitarbeiter ab.

Die 6 DASA-DevOps-Prinzipien. (Abb. 1)

 

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.[1]

Kundenzentriertheit im DevOps bedeutet, dass die Feedback-Zyklen 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 und Anwendern 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, bspw. durch Auflösen der bestehenden organisatorischen Silos zugunsten von produktorientierten Teams.

 

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 Services 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.[3]

Eine Ende-zu-Ende-Verantwortung bedeutet aus Sicht von DevOps, dass die traditionelle Trennung von Entwicklung und Betrieb zugunsten von voll verantwortlichen Teams, man könnte sagen, 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 liegt sowohl die Ergebnis- als auch die Durchführungsverantwortung in einem Team. Die IT erreicht 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.[4]

Die Forderung nach cross-funktionalen, 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. Das bedeutet nicht, dass diese Teams keine Spezialisten mehr benötigen. Ähnlich wie bei einer guten Fußballmannschaft sollte jedoch jeder Spieler das Ganze im Blick haben – gemäß dem Motto „Gute Verteidigung beginnt beim Stürmer!“ – und flexibel auf verschiedenen Positionen einsatzbar sein. 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”.[5]

Das Prinzip von kontinuierlicher Verbesserung beschreibt aus Sicht von DevOps die Tatsache, dass sich moderne IT-Organisationen permanent an verändernde Bedingungen wie 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, wie „Fail fast, fail often“ 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 sowie unterstützt wird und in der Transparenz durch Kennzahlen vorherrscht. Ziel ist es, frühzeitig Veränderungsbedürfnisse zu erkennen und diese durch kontinuierliche Anpassung und Verbesserungen zu jeder Zeit vornehmen zu können. Diese Grundausrichtung benötigen IT-Organisationen für ihren individuellen Erfolg in dieser schnelllebigen Welt. Ein ideales Vorgehen, das 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.[6]

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, die Prinzipien aus der Softwareentwicklung auf den IT-Betrieb überträgt. Standardisierung und Automation ist ein wesentliches Mittel, um die Voraussetzung für die erfolgreiche Adaption einer DevOps-Kultur zu schaffen, die der Maxime Everything-as-code folgt.

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

 

Fazit:

Bei Betrachtung aller DASA-DevOps-Prinzipien und deren Zusammenhängen wird eine solide Basis für Organisations- und Personalentwicklung gelegt. Die beschriebenen Inhalte und Forderungen an die Organisation und die beteiligten Personen sind entscheidend für die notwendigen Veränderungen sowohl in den Organisationen, bspw. bei Kultur oder Prozessen, als auch bei den Mitarbeitern, bspw. Einstellung, Kompetenzen und Wissen.

Die DASA-DevOps-Prinzipien als Basis für ein Kompetenz-Framework. (Abb. 2)

Darüber hinaus identifziert das DASA-Kompetenz-Framework acht Wissensbereiche sowie vier Verhaltensbereiche, die in DevOps und somit modernen IT-Organisationen relevant sind. Dieses Kompetenz-Framework baut auf den sechs DASA-DevOps-Prinzipien auf, die im ersten Teil unserer Artikelserie erläutert wurden. Im zweiten Teil der Serie werden wir insbesondere auf die Kompetenzen, Fähigkeiten und das Wissen der Mitarbeiter im DevOps-Umfeld eingehen.

 

Das Motto von Dierk Söllner lautet: “Ich mache Teams und Menschen erfolgreich!”. Als zertifizierter Business Coach ( dvct. e.V.) unterstützt er Teams sowie Fach- und Führungskräfte bei aktuellen Herausforderungen durch professionelles Coaching. Seine langjährige und umfassende fachliche Expertise als ITIL Expert, DASA Ambassador, DevOps Trainer und zertifizierter Scrum Master machen ihn zu einem kompetenten und empathischen Begleiter bei Personal-, Team und Organisationsentwicklung. Er betreibt den DevOps-Podcast “Auf die Ohren und das Hirn”; hat einen Lehrauftrag zu “Agiles IT Service Management” und das Fachbuch “IT Service Management mit FitSM” publiziert.

 

Total
0
Shares
Previous Post

DevOps-Sportfreunde

Next Post

Task-Parallelität mit CompletableFutures

Related Posts

Die Zukunft von Containern – Was kommt als Nächstes?

Vielleicht haben Sie schon die Schlagworte gehört, die in aller Munde sind, wenn es um die Zukunft von Containern geht. Seltsame Namen wie "Micro-VMs"… "Unikernel"… "Sandboxes"… Haben Sie sich gefragt, was diese Dinge sind und wie Sie sie nutzen können? Oder sollten Sie diese überhaupt verwenden?
Avatar
Read More