devops.ch

Die Rolle von Künstlicher Intelligenz (KI) und Maschinellem Lernen (ML) im modernen DevOps Ansatz

2025-04-08T00:00:00Z

Die Rolle von Künstlicher Intelligenz (KI) und Maschinellem Lernen (ML) im modernen DevOps Ansatz

In der heutigen schnelllebigen Technologielandschaft stehen Unternehmen vor der
Herausforderung, ihre Softwareentwicklungs- und Bereitstellungsprozesse kontinuierlich zu
optimieren. Die Integration von Künstlicher Intelligenz (KI) und Maschinellem Lernen (ML) in
DevOps hat sich dabei als entscheidender Faktor erwiesen, um Automatisierung zu verbessern,
Vorhersagen zu treffen und die Effizienz zu steigern.

Integration von KI/ML in DevOps

Wenn man DevOps mit einem Uhrwerk vergleicht, dann sind KI und ML wie ein automatischer
Uhrmacher: Sie greifen dort ein, wo vorher manuelles Eingreifen nötig war, und das mit Präzision,
Geschwindigkeit und manchmal mit überraschender Weitsicht. Durch den Einsatz trainierter Modelle
können Logdateien in Echtzeit analysiert, Anomalien automatisch erkannt und mögliche Ursachen
eingegrenzt werden, noch bevor ein Mensch überhaupt eingreift. Aber damit nicht genug: KI kann
auch Prioritäten setzen, Risiken bewerten und Vorschläge machen, wie ein Deployment verbessert
oder beschleunigt werden könnte. Der Übergang vom reaktiven zum proaktiven DevOps wird durch
diese Technologien erst möglich.

Fallstudie: Uniphore

Ein Beispiel aus der Praxis verdeutlicht das besonders gut: Das Unternehmen Uniphore, bekannt für
seine KI-gesteuerten Lösungen im Bereich Sprach- und Gesprächsanalytik hatte sich das Ziel
gesetzt, Innovationen schneller zum Kunden zu bringen, ohne dabei Abstriche bei Sicherheit oder
Zuverlässigkeit zu machen. Mithilfe der DevSecOps-Automatisierungsplattform von DuploCloud und
der Infrastruktur von AWS gelang es Uniphore, eine agile Umgebung zu schaffen,
in der neue Produktfeatures in einem Bruchteil der früher benötigten Zeit ausgeliefert werden
konnten. Die operative Komplexität sank drastisch um ganze 70 Prozent, während sich die
Time-to-Value für neue Lösungen fast verzehnfachte. Dieses Beispiel zeigt: Wenn Technologie auf
eine klare Vision trifft, sind transformative Ergebnisse möglich.

MLOps vs. DevOps

MLOps wird häufig als DevOps für maschinelles Lernen bezeichnet, und dem kann man nur schwer widersprechen. MLOps erbt viele Prinzipien von DevOps.

Trotz der Ähnlichkeit können wir nicht einfach DevOps-Tools nehmen und sie auf die Operationalisierung von ML-Modellen anwenden. Und hier sind die Hauptgründe dafür.

1. Neben der Code-Versionierung benötigen wir einen Speicherort für Daten und Modellversionen.

Beim maschinellen Lernen wird viel experimentiert. Datenwissenschaftler trainieren Modelle mit verschiedenen Datensätzen, was zu unterschiedlichen Ergebnissen führt. Zusätzlich zur in DevOps verwendeten Code-Versionskontrolle benötigt MLOps daher spezielle Instrumente zum Speichern von Daten und Modellversionen, die wiederverwendet und neu trainiert werden können.

2. Im Gegensatz zu Code verschlechtern sich Modelle mit der Zeit, was eine Überwachung erfordert .

Nachdem ein trainiertes Modell in die Produktion gelangt ist, beginnt es, Vorhersagen aus realen Daten zu generieren. In einer stabilen Umgebung würde seine Genauigkeit nie nachlassen. Aber leider „verändern sich das Leben und damit auch die Live-Daten, die unser Modell aufnimmt,“ – räumt ein erfahrener Entwickler ein. „Dies führt zu einer sogenannten Modellverschlechterung – mit anderen Worten, seine Vorhersageleistung nimmt mit der Zeit ab. Um Fehler zu vermeiden, brauchen wir eine kontinuierliche Modellüberwachung, was für DevOps-Praktiken nicht typisch ist.“

3. Das Training endet nie.

Sobald der Leistungsabfall erkannt wird, muss das Modell mit den neuen Daten neu trainiert und validiert werden, bevor es wieder in die Produktion eingeführt wird. Bei MLOps ersetzen kontinuierliches Training und Validierung kontinuierliche Tests, die bei DevOps durchgeführt werden.

MLOps vs. DataOps

DataOps oder Data Operations kamen fast zeitgleich mit MLOps ins Spiel und haben sich auch viele Muster von DevOps entlehnt. Der Kernbereich der Anwendung ist jedoch die Datenanalyse.

DataOps deckt alle Schritte des Datenlebenszyklus ab, von der Erfassung bis zur Analyse und Berichterstattung, und automatisiert sie, wo immer möglich. Ziel ist es, die Qualität und Zuverlässigkeit von Daten zu verbessern und gleichzeitig die für die Bereitstellung einer Analyselösung erforderliche Zeit zu minimieren.

Der Ansatz ist besonders hilfreich für Organisationen, die mit grossen Datensätzen und komplexen Datenpipelines arbeiten. DataOps kann auch ML-Projekte erleichtern – allerdings nur bis zu einem gewissen Grad, da es keine Lösungen für die Verwaltung eines Modelllebenszyklus bietet. MLOps kann also als Erweiterung von DataOps betrachtet werden.

MLOps vs. AIOps

AIOps, die jüngste der oben genannten Operations, wird oft synonym mit MLOps verwendet, was, vereinfacht ausgedrückt, nicht korrekt ist. Laut Gartner, der den Begriff 2017 geprägt hat, „kombiniert AIOps – oder Artificial Intelligence for IT Operations – Big Data und maschinelles Lernen, um IT-Betriebsprozesse zu automatisieren.“

Im Wesentlichen besteht das Ziel von AIOps darin, Probleme im täglichen IT-Betrieb automatisch zu erkennen und mithilfe von KI proaktiv darauf zu reagieren. Gartner geht davon aus, dass bis 2025 bis zu 30 Prozent der grossen Unternehmen AIOps-Tools zur Überwachung ihrer IT-Systeme einsetzen werden.

Und nun ist es an der Zeit, zu unserem Kernthema zurückzukehren und den gesamten MLOps-Zyklus genauer zu untersuchen.

MLOps-Konzepte und -Workflow

Der durchgängige MLOps-Workflow wird durch kontinuierliche Integrations-, Bereitstellungs- und Schulungsmethoden gesteuert, die sich gegenseitig ergänzen und den Weg von KI-Lösungen zu den Kunden verkürzen.

Continuous Integration und Continuous Delivery (CI/CD).

MLOps ist in einem CI/CD-Rahmen angesiedelt, der von DevOps als bewährte Methode zur Einführung hochwertiger Code-Updates in kurzen Abständen befürwortet wird. Beim maschinellen Lernen wird die Integrationsphase jedoch um die Daten- und Modellvalidierung erweitert, während bei der Bereitstellung die Komplexität von maschinellen Lernbereitstellungen berücksichtigt wird. Insgesamt führt CI/CD Daten-, Modell- und Codekomponenten zusammen, um einen prädiktiven Dienst zu veröffentlichen und zu aktualisieren.

Continuous Training (CT).

Ein einzigartiges Konzept für MLOps, bei dem es um die Automatisierung des Modell-Retrainings geht. Es umfasst alle Schritte des Modell-Lebenszyklus von der Datenerfassung bis zur Leistungsüberwachung in der Produktion. CT stellt sicher, dass Ihr Algorithmus bei den ersten Anzeichen von Verfall oder Veränderungen in der Umgebung aktualisiert wird.

Um besser zu verstehen, wie kontinuierliche Integration, Bereitstellung und Schulung in der Praxis umgesetzt werden und wie die Aufgaben zwischen ML- und Betriebsspezialisten aufgeteilt werden, wollen wir uns die Schlüsselkomponenten von MLOps in einem nächsten Beitrag näher ansehen. Dazu gehören:

Modell-Trainings-Pipeline
Modellregister
Modellbereitstellung (Deployment)
Modellüberwachung
CI/CD-Orchestrierung

Natürlich können die Schritte und der gesamte Workflow in verschiedenen Fällen variieren - je nach Projekt, Unternehmensgrösse, Geschäftsaufgaben, Komplexität des maschinellen Lernens und anderen Faktoren.

Mit dem Fortschreiten der Technologie ist zu erwarten, dass KI und ML eine noch zentralere Rolle in
DevOps einnehmen werden. Die Entwicklung von MLOps, einer Praxis zur Operationalisierung von
ML-Modellen, wird weiter voranschreiten und Unternehmen dabei unterstützen, ihre Modelle
effizient zu verwalten und zu skalieren.

Natürlich bringt jede technologische Neuerung auch ihre Schattenseiten mit sich. KI und ML sind
Keine Selbstläufer, sie leben von Daten. Und Daten, insbesondere im DevOps-Umfeld, sind oft
verstreut, inkonsistent oder sensibel. Damit ein Algorithmus lernen kann, braucht er nicht nur grosse
Mengen, sondern vor allem qualitativ hochwertige Informationen. Genau hier beginnen die
Herausforderungen: Datenschutzrichtlinien, Governance-Fragen und ethische Abwägungen stehen
jeder Innovation gegenüber. Zudem stellt sich die Frage: Wie viel Entscheidungsmacht wollen wir
Maschinen wirklich überlassen, gerade bei sicherheitsrelevanten Prozessen? Diese Bedenken sind
nicht neu, aber sie verdienen besondere Beachtung, wenn man mit KI im produktiven Betrieb
arbeitet.

Die Reise hat gerade erst begonnen. Während heute viele Unternehmen noch in der Pilot- oder
Experimentierphase stecken, zeichnen sich schon klare Trends ab: MLOps also die
Operationalisierung von ML-Modellen wird zum neuen Goldstandard. Ähnlich wie DevOps eine
Brücke zwischen Entwicklung und IT-Betrieb gebaut hat, schlägt MLOps die Verbindung zwischen
Datenwissenschaft und Produktionsumgebung. Künftig könnten adaptive Systeme in Echtzeit auf
Umgebungsdaten reagieren, sich selbst kalibrieren und mit DevOps-Pipelines harmonieren.

Vielleicht erleben wir schon bald eine Ära, in der menschliche und künstliche Intelligenz nicht mehr
getrennt, sondern als kollaborative Einheit gedacht wird.

Wie seht ihr diese spannende Entwicklung? Schreibt Eure Meinung gerne in die Kommentare.

LG Euer Sven

"Agilität trifft Struktur: Wie moderne Unternehmen im Sturm der Veränderung navigieren"

2023-10-09T00:00:00Z

Agilität trifft Struktur

Posted on 10/10/2023 in Alle by Sven Ossenberg

0 Comments

"Agilität trifft Struktur: Wie moderne Unternehmen im Sturm der Veränderung navigieren"

Die Symbiose von Agilität und Struktur in der modernen Geschäftswelt

In der heutigen Geschäftswelt fühlen sich viele Unternehmen wie Schiffe in einem ständigen Sturm der Veränderung. Die Wellen der Digitalisierung, Globalisierung und ständigen Innovationen treffen auf sie ein, und es scheint, als ob der einzige Weg, um nicht unterzugehen, darin besteht, sich ständig anzupassen und neu auszurichten. In diesem Kontext wird Agilität oft als der rettende Anker angesehen, der Organisationen ermöglicht, den rauen Gewässern der Veränderung standzuhalten.

Agilität: Mehr als nur ein Trend

Agilität ist in der Geschäftswelt zu einem fast magischen Wort geworden. Aber was bedeutet es wirklich? Es geht nicht nur darum, schnell zu sein oder sich ständig zu verändern. Es geht darum, eine Denkweise zu verkörpern, die es ermöglicht, proaktiv auf Veränderungen zu reagieren, innovative Lösungen zu entwickeln und dabei stets den Kunden im Mittelpunkt zu halten. Es erfordert eine Kultur der Offenheit, in der Fehler als Lernchancen und nicht als Misserfolge gesehen werden. Es geht darum, Prioritäten ständig neu zu bewerten und sich an die sich ständig ändernde Landschaft anzupassen.

Die Notwendigkeit von Strukturen

Während Agilität zweifellos viele Vorteile bietet, kann sie ohne die richtigen Strukturen und Methoden zu Chaos führen. Ein Unternehmen, das versucht, agil zu sein, ohne klare Verantwortlichkeiten, Zielsetzungen und Kommunikationswege, könnte sich schnell in einem Zustand der Verwirrung und Ineffizienz wiederfinden. Strukturen sind notwendig, um sicherzustellen, dass alle im Unternehmen in die gleiche Richtung ziehen und dass die Agilität in geordneten Bahnen verläuft.

Synergie zwischen Agilität und Struktur

Es mag auf den ersten Blick so erscheinen, als ob Agilität und Struktur in Konflikt miteinander stehen. Aber in Wirklichkeit können sie Hand in Hand gehen und sich gegenseitig verstärken. Agilität bietet die Flexibilität, die Unternehmen benötigen, um sich in einer sich ständig verändernden Welt zu bewegen, während Strukturen und Methoden den notwendigen Rahmen bieten, um sicherzustellen, dass diese Bewegung effektiv und effizient ist. Es geht darum, die richtige Balance zu finden und Methoden zu wählen, die zur Unternehmenskultur passen und gleichzeitig die Dynamik der Veränderung unterstützen.

Konkrete Business-Beispiele: Agilität und Struktur in Aktion

Um die Theorie in die Praxis zu übertragen, werfen wir einen Blick auf einige konkrete Beispiele aus der Geschäftswelt, die die Symbiose von Agilität und Struktur veranschaulichen:

Spotify: Das schwedische Musik-Streaming-Unternehmen ist bekannt für sein "Squad"-Modell. Auch wenn die eigentliche Idee es nie vom Reißbrett in die Praxis schaffte, orientieren sich bis heute unzählige Firmen an diesem Modell.

Jedes Squad ist ein autonomes Team, das für einen bestimmten Bereich des Produkts verantwortlich ist. Während jedes Team agil arbeitet und schnell auf Veränderungen reagieren kann, gibt es übergeordnete Strukturen und "Gilden", die sicherstellen, dass Wissen geteilt wird und dass es kohärente Ziele und Visionen im gesamten Unternehmen gibt.

Amazon: Das Prinzip "Zwei-Pizza-Teams" von Amazon besagt, dass jedes Team so klein sein sollte, dass es mit zwei Pizzen gefüttert werden kann. Diese kleinen Teams arbeiten autonom und agil, aber innerhalb der größeren Struktur von Amazon, die klare Richtlinien und Ziele vorgibt.
ING Bank: Nachdem die ING Bank erkannte, dass sie sich schneller an die digitale Transformation anpassen musste, wechselte sie zu einem agilen Modell mit "Squads" und "Tribes". Diese Teams arbeiten unabhängig, aber innerhalb einer festgelegten Struktur, die sicherstellt, dass sie alle in dieselbe Richtung arbeiten und die übergeordneten Ziele der Bank erfüllen.
Airbnb: Als Reaktion auf sich ändernde Marktbedingungen und Benutzeranforderungen hat Airbnb seine Produktentwicklungsteams so strukturiert, dass sie agil arbeiten können, aber immer noch innerhalb der übergeordneten Vision und Mission des Unternehmens. Dies ermöglichte es ihnen, schnell auf Veränderungen zu reagieren, ohne das Gesamtbild aus den Augen zu verlieren.
Bosch: Das globale Technologieunternehmen hat agile Methoden in seine Arbeitsweise integriert, wobei Teams in "Agile Release Trains" arbeiten. Diese Züge ermöglichen es den Teams, unabhängig und flexibel zu arbeiten, aber innerhalb einer festgelegten Struktur, die sicherstellt, dass sie alle auf dasselbe Ziel hinarbeiten.

Diese Beispiele zeigen, dass, egal ob in der Technologiebranche, im Finanzsektor oder in der Fertigungsindustrie, Agilität und Struktur Hand in Hand gehen können. Es geht darum, die richtige Balance zu finden, die es den Teams ermöglicht, flexibel und innovativ zu sein, während sie immer noch innerhalb eines Rahmens arbeiten, der Klarheit, Richtung und Stabilität bietet.

Zusammenfassung

In der heutigen Geschäftswelt sind Agilität und Struktur keine Gegensätze, sondern vielmehr zwei Seiten derselben Medaille. Beide sind notwendig, um in einem ständigen Sturm der Veränderung erfolgreich zu sein. Es liegt an uns, wie wir diese beiden Konzepte in Einklang bringen und nutzen, um unsere Unternehmen auf Erfolgskurs zu halten.

Ich lade Dich herzlich ein, mit uns am nächsten Cloud Talk über dieses spannende Thema zu diskutieren, ein toller kostenloser vor Ort Event.

Melde Dich einfach mit dem unten stehenden Link an. https://t.ly/1RhTS

Viel Erfolg auf Eurer agilen Reise, Euer Sven

Grüezi SAFe, 6.0!

2023-03-18T00:00:00Z

Der Wandel ist die einzige Konstante im Leben.

-Heraklit, griechischer Philosoph

Grüezi SAFe, 6.0!

Es ist soweit und für viele, mich eigeschlossen, ging es dann doch recht schnell.

Die Damen und Herren aus Boulder, USA präsentieren uns eine neue Version des Scaled Agile Frameworks. Die Version 6.0 ist da. Als ob sie es gewusst hätten, die erste Änderung, die mir auffiel, ist die farbliche Umgestaltung von einem maritimem blau auf meine Lieblingsfarbe, eine ART-Petrol färbende Darbietung des Internetauftritts.

Apropos ART, was gibt es denn eigentlich inhaltlich Neues aus unserem «Zug».

Auch bei SAFe ging und geht die Pandemie nicht spurlos vorüber. Die Herausforderungen den wir täglich begegnen fliessen in das Framework ein. Doch auch der technische Fortschritt nimmt an Fahrt auf und Themen wie AI, Big Data, Cloud und Co finden thematisch eine zentralere Rolle im neusten update.

Vor allem jetzt, wo die Pandemie, die globale Wirtschaft und die Probleme in der Lieferkette eine jahrzehntelange Realität vor Augen geführt haben: Unternehmen werden von ständigen Veränderungen überrollt, stellt dich das Framework dieser gestiegenen Komplexität. Die Komplexität und Kritikalität dieser neuen Systeme war noch nie so hoch wie heute. Das allgemeine Wohlergehen der Menschheit - und manchmal sogar unser eigenes Leben - hängt buchstäblich von ihnen ab.

Klingt dramatisch – ist es auch!

Die klugen Köpfe hinter SCALED AGILE warfen wohl in letzter Zeit immer öfter einen kritischen Blick auf das gesamte Framework - vom SAFe Big Picture bis hin zu allen unterstützenden Knowledge-Base-Artikeln, Grafiken und Kursunterlagen - und entschieden, dass es Zeit für eine neue Version ist. Eine, die scheinbar sicherstellen soll, dass Nutzer dieses mächtigen Rahmenwerks weiterhin die Anleitungen und Ressourcen erhalten, die sie benötigen, um sich an Marktveränderungen anzupassen und um Störungen in Chancen zu verwandeln.

Ein Schelm der dabei böses denkt, würde man dieses ausschließlich tun um die bestehenden Kurse, Zertifizierungen, Toolkits und Online-Lernprogramme anzupassen. Hand aufs Herz, nützlich besteht der Grund einer jeden Existenz darin, um zu überleben - das gilt für Lebewesen und Firmen gleichermassen. Von daher ist es mehr als verständlich, dass die Investitionen in diese Arbeit auch am Ende vom Tag wieder reingeholt werden müssen.

Da fällt mir doch gleich die nächste persönliche Änderung ins Auge, die zumindest meinen Jobtitel beeinflussen wird. Es heisst nicht mehr SAFe Program Consultant, sondern ITIL 4 lässt grüssen, SAFe Practice Consultants. Ein Grund, sich das mal näher anzusehen.

Als erstes verschaffen wir uns einen Überblick aus der Vogelperspektive. Ja, nicht nur die Farbe ist eine andere, auch neue Begriffe fallen uns direkt auf:

SAFe 6.0 enthält viele neue und Praktiken, um die neuesten Technologie- und Geschäftstrends zu unterstützen. Zudem gibt acht zusätzliche Möglichkeiten zur Beschleunigung der Value Streams. SAFE wäre ja auch kein skaliertes Rahmenwerk, wenn nicht versucht würde auch die Ausweitung auf andere Geschäftsfunktionen im Unternehmen zu beschreiben.

Folgende 6 Themen heben die wichtigsten Änderungen und Ergänzungen hervor:

Stärkung der Business Agility –

Die grundlegenden Aspekte von Business Agility, einschließlich des Business Agility Value Stream (BAVS) werden durch eine neue, schlankere Denkweise und aktualisierte Grundwerte wesentlich verändert und hoffentlich auch verbessert. Hier fällt auf, das sogar die SAFe-Implementierungs-Roadmap aktualisiert und überarbeitet wurde. Neue Verantwortlichkeiten für SAFe-Practice-Consultants (SPCs) verdeutlichen dieses am ehesten.

Die SAFe-Implementierungs-Roadmap, die die entscheidenden Schritte für die Einführung des Frameworks enthält, wurde aktualisiert, um die Änderungen in SAFe 6.0 zu berücksichtigen:

- Der Schritt "Wasserfall/Ad Hoc Agile" wurde als Ausgangspunkt entfernt, da die Einführung von SAFe nicht immer von einem dieser Ausgangspunkte aus erfolgt
- Das SAFe Executive Workshop Toolkit wurde dem Schritt "Go SAFe" hinzugefügt
- Lean-Agile Center of Excellence - Verfeinerung und Klärung der Verantwortlichkeiten
- Leading in the Digital Age wurde in die Roadmap aufgenommen, ein Programm, das Führungskräfte mit dem Wissen und den Fähigkeiten ausstattet, ihre agilen Teams zu unterstützen und Veränderungen effektiv zu managen
- «Organize Around Value» wurde umbenannt in "Identify ARTs and Value Streams", um den Zweck und die Verbindung zu Prinzip Nr. 10 zu verdeutlichen
- Das SAFe Workshop-Toolkit zur Identifizierung von Wertströmen und ARTs wurde zum Schritt "Organize Around Value" hinzugefügt
- Enhance the Portfolio wurde umbenannt. Zuvor hieß es "Portfolio erweitern". In diesem aktualisierten Schritt wird empfohlen, dass Organisationen bereits zu einem früheren Zeitpunkt mit der Erkundung einiger LPM-Praktiken beginnen, z. B. mit der Implementierung eines Portfolio-Kanban-Systems, um die Sichtbarkeit aktueller und zukünftiger Initiativen zu gewährleisten. Daher werden LPM-Schulungen im Rahmen des Roadmap-Schrittes "Schulung der Führungskräfte, Manager und Leiter" empfohlen
- Accelerate betont, dass der Weg der Transformation nie abgeschlossen ist, sondern mit der Schaffung einer Kultur des kontinuierlichen Lernens beginnt, die zu ständiger Verbesserung und zur Förderung einer Innovationskultur verpflichtet
Dieser letzte Punkt hätte von vielen meiner Berater Kollegen:innen sein können, versuchen wir doch immer wieder darauf aufmerksam zu machen, dass wir kein definiertes Ende dieser Transformation haben werden….

Befähigung von Teams und Klärung von Rollen und Verantwortlichkeiten –

Neue Anleitungen helfen Einzelpersonen, ihre Rollen besser zu verstehen und ihre Arbeitsleistung zu verbessern, was zu einer größeren Unterstützung der Unternehmensziele und einer höheren persönlichen Zufriedenheit führt. Ein Beispiel für das neue Rollen- und Verantwortungsrad für den neu benannten Scrum Master/Team Coach ist unten abgebildet.

Beschleunigung des Value Flows –

Ein tieferes Verständnis für das Erreichen und Optimieren des Werteflusses ist von zentraler Bedeutung für die Entwicklung von SAFe. Es gibt hierzu einen Leitfaden, der acht Value Stream «Beschleuniger» definiert (wie unten dargestellt), die den Flow in SAFe verbessern sollen. Mit der Fähigkeit, den Flow zu messen, haben wir eine neue und quantitative Basis, um zu verstehen, was passiert, wie die Dinge funktionieren und was wir tun können, um sie zu verbessern. Neue Artikel zu SAFe Scrum, SAFe Team Kanban, Built-in Quality und Wertstrommanagement fügen den Flow direkt in die tägliche Arbeit der Teams ein. Vier neue Flow-Artikel bieten zudem Anleitungen zur Anwendung des Prinzips 6 - Wertfluss ohne Unterbrechungen - auf Agile Teams, ARTs, Solution Trains und Portfolios.

Glauben wir nur den Designer, soll dies vielleicht der bedeutendste Durchbruch in SAFe sein.

Verbesserung der Business Agility mit SAFe im gesamten Unternehmen –

Der neue Business and Technology-Artikel hebt fünf bewährte Muster hervor, die zur Ausweitung der Agilität im gesamten Unternehmen genutzt werden können. Dazu gehören:

Die Zukunft gestalten mit KI, Big Data und Cloud –

SAFe 6.0 solls nun auch dabei helfen, die Einführung der neuesten Technologien durch erweiterte Beschreibung zur Integration von KI, Big Data und Cloud in die Wertströme zu beschleunigen. Die Anwendung dieser Technologien ist heute und in Zukunft entscheidend für die Wettbewerbsfähigkeit, was wir momentan durch Chat GPT ansatzweise erahnen können.

Bessere Ergebnisse mit Measure and Grow und OKRs –

SAFe 6.0 unterstützt nun auch Unternehmen dabei, bessere Geschäftsergebnisse zu erzielen, indem es eine erweiterte Darstellung zur Anwendung von Objectives and Key Results (OKRs) und einer verbesserten Technik zur Messung und Verbesserung von Kompetenz und Flow bietet. Dieses Thema habe ich seit langem in dieser Form vermisst, für mich war die Bedeutung von OKRs wesentlich bedeutender, als es SAFe in der Vergangenheit behandelte.

Aktualisierte Lern- und Praxisressourcen

Und natürlich spiegeln sich diese neuesten Anleitungen auch in den Aktualisierungen der SAFe-Kursunterlagen, Online-Lernprogramme und Praxisressourcen wider. Auffällig, ist das Leading SAFe®, einer der beliebtesten Kurse von Scaled Agile, ist jetzt in Sprachen wie brasilianisches Portugiesisch, Chinesisch, Französisch, Deutsch, Japanisch, Koreanisch und Spanisch verfügbar.

SAFe® Studio

Als Teil dieser Version wurde nun SAFe® Studio eingeführt, eine neue abonnementbasierte Plattform, die es SAFe-Experten ermöglicht, SAFe zu lernen, zu üben und zu managen. Es soll bei der Übersetzung von Leitfäden helfen. Hier werde ich mich die nächsten Tage mal intensiv mit beschäftigen und eventuell an dieser Stelle nochmals mit beschäftigen.

Vereinheitlichung der ART-Terminologie –

Die Terminologie für Programm wurde im gesamten Framework durch ART ersetzt. Die Standardisierung dieser Terminologie soll die Einfachheit und Klarheit verbessern. Also an alle da draussen die eine ZErtifizierunbg anstreben, es gilt wieder einmal neue Vokabneln zu lernen. Davon halte man was man möchte 😊

Fazit

Alter Wein in neuen Schläuchen? Nein, das wäre definitiv zu kurzgefasst. Es gibt viele neue Ansätze und Ideen, die sich erst einmal in der Praxis beweisen müssen. Es wird’s sich zeigen, wie hoch die Akzeptanz im Markt sein wird und ob wir als Berater die Chance bekommen das umzusetzen was individuell für unsere Kunden am sinnvollsten ist. Meine Erfahrung, dass es eine Mehrheit gibt, die krampfhaft versucht, «sklavistisch» an Frameworks festzuhalten, wird dieses auch in der Version 6.0 tun, doch ohne diese Herangehensweise wäre mein Job ja auch langweilig.

Wie seht ihr die Änderungen, werden sie bei Euch etwas verändern?

Euer Sven,

(SAFe Prog….äh..Practice Consultant, SPC) der GlenfisAgile 😊

Kommentare (archiviert, 2017–2023)

Adrian Müller · 2023-04-03

Hey Sven, danke für diese Zusammenfassung - gut gemacht! Adrian

Sven Ossenberg · 2023-04-04

Danke Dir. Freue mich, Dir die Neuigkeigen gerne vorzustellen :)

LG Sven

SRE: Die grösste Lüge seit Kanban?!

2021-11-18T00:00:00Z

Site Reliability Engineering: Die größte „Lüge“ seit Kanban

Zugegeben ein bisschen provokant ist der Blog schon, doch die Diskussionen führe ich derzeit einfach sehr häufig....

Was hat sich zugetragen:

In letzter Zeit wird viel darüber diskutiert, wie Site Reliability Engineers zu DevOps Engineers passen, (es gibt zwar viele DevOps Engineers Ausschreibungen, doch wunder ich mich stets, denn es gibt immer noch keine einheitliche Definition dieses Job Titels) mit ihnen konkurrieren oder was auch immer sie mit DevOps machen. In der nächsten Woche werde ich einen Vortrag zum Thema "Site Reliability Engineers vs. DevOps" halten, und zur gleichen Zeit sehe ich Moderatoren, die Folien von Velocity und Value Stream Mapping in Verbindung mit Site Reliability Engineering zur Umsetzung von DevOps twittern. Und je mehr ich darüber nachdenke und sehe, was die Leute tun, desto mehr "Sorgen" bekomme ich.

Die große Lüge

Nur damit die Leichtgläubigen nicht gleich ihre Mistgabeln in die Hand nehmen, ich habe nichts gegen Site Reliability Engineers und ich habe nichts gegen Kanban. Im Gegenteil, dieses anzuwenden und zu unterrichten macht mir Freude. Der Grund, warum ich Kanban eine "große Lüge" nenne, ist, dass es noch mehr fachliche Ausrichtung erfordert Kanban richtig anzuwenden um den größtmöglichen Nutzen daraus zu ziehen. Es sieht jedoch so aus, als wäre es nichts Neues, dass zahlreiche Teams da draußen sagen: "Sie machen Kanban" und damit meinen, dass sie nichts machen, sondern nur die Kanban-Ansicht in JIRA aktiviert haben, damit sie es bequem haben. Sie haben keine Vorhersehbarkeit, sie bewirken keinen WIP, sie identifizieren keine Engpässe - sie haben nur eine sichtbare Tafel und das war's. Aus meiner Erfahrung heraus glaube ich fest daran, dass die meisten Teams, die "Kanban" anwenden, in Wirklichkeit gar nichts tun. In diesem Blog gibt es Artikel darüber, wie ich meine Teams, denen ich Agilität näher brachte, dazu bewog, zuerst Scrum zu machen, wenn sie Kanban nutzen wollten, um die nötige fachliche Ausrichtung zu entwickeln. Und ich bin nicht der einzige "Freak", der so denkt. Ein Freund von mir hat seinem Managementteam vor ein paar Wochen genau das Gleiche gesagt, was mir das wieder ins Gedächtnis gerufen und mich zu diesem Artikel angeregt hat.

Denn ich erlebe das Gleiche bei den SREs (Site Reliability Engineers). Das ist nicht überraschend - es gab und gibt eine Menge "DevOps-Washing" von bestehenden Operations-Teams. Benenne dein Betriebs-Team in DevOps um, fertig. Wenigstens war DevOps in der Lage zu sagen: "Es ist eine Methodik, keine Stellenbeschreibung oder ein Gruppenname", - deshalb heißt das Team meines Freundes bei der Arbeit auch "Engineering Operations" und nicht "DevOps". Ich hatte eine Diskussion mit einem anderen Teamleiter und das Ergebnis war: "Site Reliability Engineers - ja, das ist ein Team wie dein eigenes Operation Team, vom Organigramm aus gesehen sieht es genauso aus...." Site Reliability Engineers zu beschäftigen, kann also - und tut es in zahlreichen Unternehmen auch - bedeuten, nichts Neues zu machen. Du nennst dein bestehendes Operation Team einfach Site Reliability Engineers und denkst - das war's. ;)

Eine kurze, persönliche Geschichtsstunde - in einem meiner früheren Jobs vor DevOps@pontine leitete ich ein Engineering Team - ein Betriebsteam.

Dort lernten wir "agilen" Admins uns richtig kennen, denn 2 meiner Kollegen waren beide Operation Engineers in diesem Team! Wir hatten kluge Leute und machten den Betrieb richtig gut.

Wir hatten Automatisierung, Monitoring, und sogar "Definition of done"-Standards für neue Services. Man muss nicht allzu sehr Flunkern, um dieses Team einfach als Site Reliability Engineers zu bezeichnen und Feierabend zu machen. Meinen schlimmsten Feinden würde ich diesen Job jedoch nicht wünschen. Es war brutal, den Betrieb für nur 4-5 Entwicklerteams zu machen, und das mit gleichzeitiger Unterstützung der ganzen Firma, einigen gemeinsamen Zielen und so weiter. Unsere Lebensqualität war gelinde gesagt eingeschränkt, wir wurden nicht befähigt und egal, wie sehr wir uns bemühten, der Erfolg blieb uns immer verwehrt. Als wir dann ein Team gründeten, das DevOps-Denken verwendete, war der Unterschied wie Tag und Nacht, und wir begannen, unsere Arbeit als Operation Engineers zu genießen. Ich würde es ungern sehen, wenn sich jemand vormacht, er bekäme das Beste aus diesen Prinzipien, was ein DevOps/"echter" Site Reliability Engineers-Ansatz zu bieten hat, während er es immer noch so macht, wie wir es gemacht haben.

Ein Freund von mir, der bei einer heimischen Softwarefirma arbeitet, hat mir erzählt, dass sie alle QA-Mitarbeiter in SWET (Software-Engineer In Test) umbenennen, unabhängig davon, ob sie programmieren können oder nicht und alle Mitarbeiter*innen im Betrieb sind SREs. Man könnte wohlwollend sein und sagen, dass sie sich nach vorne bewegen und vorhaben, das mit Umschulungen oder Ähnlichem zu untermauern, jedoch... werden sie das tun?

Wahrscheinlich nicht, denn es ist nur eine Umbenennung in den angesagten neuen Begriff, ohne eine Änderung, die den Technikern hilft in ihrem Job erfolgreicher zu sein!

Site Reliability Engineers sind keine "Implementierung von DevOps", wenn du sie nur als Bezeichnung für ein aufgemotztes Operation-Team verwendest. Richtig verstanden, kann es eine Umsetzung eines der drei Teile von DevOps sein: Infrastructure As Code, Continuous Integration/Deployment und Site Reliability Engineering. Das Reliability Engineering beginnt jedoch nicht mit dem Deployment in die Produktion, sondern erfordert, wie bei DevOps üblich, die Zusammenarbeit von Dev- und Operation-Teams und zwar sowohl im Entwicklungszyklus als auch in der Produktion, um richtig zu funktionieren. Das muss nicht unbedingt ein anderes Team sein. Wenn das Team nicht beschlossen hat, ob es den Betrieb für eine bestimmte Anwendung übernimmt, wenn es nicht 50 % seiner Zeit damit verbringen darf die Arbeit zu reduzieren und wenn du die Site Reliability Engineers nicht so bezahlst wie die Entwicklungsingenieure - dann ist es kein Site Reliability Engineering und du bist ein „Gauner“, wenn du es Site Reliability Engineering nennst. Wenn du die DevOps-Prinzipien nicht beachtest, bekommst du nur dein altes Operationsteam mit seinen alten Problemen zurück.

Deshalb ist Site Reliability Engineering eine große Lüget - denn sie ermöglicht es den Leuten zu behaupten, dass sie etwas tun, das ihrem Unternehmen zum Erfolg verhelfen könnte und ihren Dev- und Operation Engineers eine bessere Karriere und ein besseres Leben zu ermöglichen - es jedoch nicht wirklich durchführen.

Ja, es hat schon früher große Täuschungen gegeben, weshalb ich Kanban als weiteres Beispiel anführe - doch selbst wenn der neue Verbrecher dem alten ziemlich ähnlich ist, hängt man sein Bild trotzdem die Lobby des Unternehemens.

Ehrlich gesagt trägt jeder der Site Reliability Engineering propagiert, ohne einen Warnhinweis anzubringen, zum Problem bei.

"Nun, jedoch wird es in Kapitel 20 des zweiten Buches erwähnt", sagte jemand als Antwort auf meine Diskussion, die ich mit einem Kollegen zu diesem Thema führte. In meinen Augen eine kritische Antwort, denn:

Wenn etwas das du verkaufst, zutiefst missverstanden wird, ist es deine Verantwortung die Probleme offen anzusprechen.

Die kleinen Probleme

Nun gibt es berechtigte Probleme mit dem "echten Site Reliability Engineers"-Modell, zumindest mit der Art und Weise, wie es normalerweise beschrieben wird. In den Google-Büchern wird es einerseits als Praxis der Engineers beschrieben und andererseits als "ein Team, das so arbeitet". Selbst unter denjenigen, die sich nicht mit dem klassischen Site Reliability Engineers-Betrieb befassen, wird allgemein davon ausgegangen, dass es sich bei den Site Reliability Engineers um eine Berufsbezeichnung für ein Team innerhalb des Produktionsbetriebs handelt.

Hier gibt es ein Problem: das Problem der Spezialisierung. Wenn du den Maßstab von Google anlegst, dann musst du dich spezialisieren und ein separates Operation-Team ist sinnvoll. Jedoch bist du nicht der Maßstab von Google. Wenn du weniger als 100 Engineers hast, machst du meiner Meinung nach einen Fehler, wenn du ein separates Operation Team hast. Deine Produktteams müssen sich um ihre Produkte kümmern. Zweitens: Ich will mir die netten Google-Ingenieure da draußen nicht zum Feind machen, doch hast du die Erfahrung gemacht, dass sich Google Services schnell weiterentwickeln und besser werden, sobald sie zum Release bereitstehen? Das ist nicht meine. Hast du in letzter Zeit Google Hangouts verwendet, ohne dass es mit Fluchen und anschließendem Wechsel zu Zoom oder Teams endete?

Diese Art von Spezialisierung hat immer noch ihre Schattenseiten, denn sie behindert die Feedbackschleifen die dich besser werden lassen (der Zweite Weg von DevOps). Ist "Site Reliability Engineers" einfach nur Google-Jargon für "nachhaltig"?

Der Reiz des Modells und der Grund, warum Google so stark darauf ausgerichtet ist, liegt in Kubernetes selbst. k8s ist sehr komplex, was die Leute ein wenig zu dem alten Priester-im-Heiligtum-Modell zurückbringt: "Jemand wartet die Infrastruktur, du schreibst die App und lässt sie dann von ihm deployen", doch jetzt gibt es einige Standards (wie das Deployment als Container), die das wieder in Ordnung bringen. Wenn du jedoch glaubst, dass Zuverlässigkeit und Beobachtbarkeit die Hauptverantwortung eines Operation-Teams sind das nicht an der Entwicklung der Anwendung beteiligt ist, dann hast du entweder tiefgreifende Unternehmensstandards, die ein nahtloses Ineinandergreifen des einen mit dem anderen ermöglichen, oder man macht sich was vor....-unter uns: -->90 % machen sich etwas vor.

Site Reliability Engineering als "separates neumodisches Operation-Team" mag für manche funktionieren, du musst jedoch realistisch sein was die Probleme und Kompromisse angeht die du eingehen willst. Überlege dir, ob Produktteams ihr Produkt unterstützen, vielleicht mit Hilfe eines Plattformteams, das Tools erbringt und eines Enabling/Consulting/Center of Excellence-Teams, das fachlichen Rat geben kann?

DevOps hat uns gezeigt, wie sehr das Modell "von Dev zu Ops über die Mauer werfen" unserer Branche geschadet hat. Der Wechsel von der Entwicklung zu den Site Reliability Engineering, macht das nicht besser, sondern ist gefühlt ein Rückschritt. Um Site Reliability Engineering "richtig" zu machen, um das zu kompensieren, braucht es wie bei Kanban mehr fachliche Ausrichtung, nicht weniger – da sollte jeder realistisch sein, ob in der eigenen Organisation das Google-Niveau an fachlicher Ausrichtung besteht 😊

Ich für meinen Teil werde auf die Umsetzung achten und in meinen Kursen genau das Lehren. Die Prinzipien und Praktiken sind vorhanden und gut verstanden. Diese richtig angewendet, sind ein absoluter Garant für guten Service.

Doch wie so oft und bei fast allen mir bekannten IT - Frameworks und Methoden, mangelt es zu oft an der Umsetzung und Implementierung.

Und nein, DevOps ist kein Framework, es ist eine Bewegung!

Wie ist Deine Meinung zu dem Thema...übertriebe ich, oder kommt Dir diese Art der Diskussion bekannt vor?

LG Euer Sven

Enterprise DevOps Skills Report 2021 ist da!

2021-04-21T00:00:00Z

Hast du schon gehört? Der Upskilling 2021: Enterprise DevOps Skills Report ist jetzt verfügbar!

In unserem letzten Webinar zusammen mit Eveline haben wir den Report angekündigt. Passend zum Anlass des heute am 21.04.2021 erschienenen Upskilling Report 2021 möchte ich Euch noch einmal im Detail erläutern, welche Dimensionen besprochen werden und wie ein Assessment der DevOps Capabilities helfen kann, die agile Reise im Unternehmen zu wagen.

Hier ein gutes Einführungsvideo

Eine schöne Einleitung kommt daher passend von Jayne selber:

“The Humans of DevOps are in urgent need of an empirical model that supports their goals to improve organizational performance through the practice of DevOps principles. They want to be able to measure their progress as their capabilities increase during their DevOps journey and know where to invest their time and energy. Our model empowers teams and enterprises to grasp what DevOps means to them and accelerate progress. We are pleased to make this available to the market.”

-Jayne Groll, CEO of DevOps Institute

Assessment of DevOps Capabilities: 5 Dimensions Explained: Erklärung der 5 Dimensionen.

Damit sich Organisationen und Teams in Richtung DevOps-Reife bewegen können, müssen sie ihre DevOps-Fähigkeiten verstehen. Ein Assessment of DevOps Capabilities bestimmt einen DevOps-Basiszustand, misst und beschleunigt die kontinuierliche Verbesserung.

Als das DevOps Institute das Assessment of DevOps Capabilities (ADOC) entwarfen, brachten die DevOps Ambassador eine Menge Ideen rund um die High-Level-Themen ein, die auf ihrer jahrelangen Erfahrung in diesem Bereich basieren. Zusammen mit dem DevOps Institute sprachen wir als Botschafter darüber, wie wichtig es war, die drei Elemente abzudecken, auf die wir uns in unserer Branche klassischerweise beziehen: Menschen über Prozesse über Tools und zahlreiche verwiesen auf das CALMS-Modell (Culture, Automation, Lean, Measurement and Sharing), das in der DevOps-Welt weithin bekannt ist und ursprünglich von Willis, Edwards und Humble geprägt wurde.

Die DOI Forschungsleiterin Eveline Oehrlich, die zusammen mit Helen Beal, der Chief Ambassador die 40-köpfige Botschafter-Gruppe leitete, die das Modell per Crowdsourcing erstellte, hatte bereits seit mehreren Jahren Recherchen für den Upskilling Report durchgeführt. Die dort angewandten Modell, die sie dort verwendet hatte, um eine umfassende Abdeckung der verschiedenen Dimensionen von DevOps zu erreichen führten zu dem jetzt umfassenden Report.

Sie stimmten mit den anderen Modellen, die das DOI ohnehin schon in Betracht gezogen hatte überein und fanden im Team Anklang und alle waren sich einig, dass dieser Ansatz die besten Chancen boten, sicherzustellen, dass die Organisationen, die das Assessment verwenden würden, alle Elemente dieser komplexen und anspruchsvollen Arbeitsweise, die wir DevOps nennen, berücksichtigen.

Die 5 Dimensionen der Bewertung von DevOps-Fähigkeiten (ADOC)

Human aspects (menschlichen Aspekte)
Process and frameworks (Prozesse und Frameworks)
Functional composition (Funktionale Zusammensetzung)
Intelligent automation (Intelligente Automatisierung)
Technology ecosystem (Technologie-Ökosystem)

Die nächste Aufgabe bestand darin, die Themen in jeder Dimension zu definieren und dann Likert-Aussagen für jedes der Themen festzulegen. Mit diesen Aussagen können Daten gesammelt werden, die den Teams Aufschluss darüber geben, wo ihre Fähigkeiten stark sind und gemeinsam genutzt werden sollten und empfohlen wird, mit Verbesserungen zu experimentieren.

Schauen wir uns bei der Gelegenheit jede Dimension im Detail an:

1. Human aspects

Beim DevOps Institute dreht sich alles um die menschlichen Elemente. Wir bei Glenfis, die ein solches Assessment durchführen wissen, dass die Kultur für die meisten Unternehmen auf dem Weg zu DevOps die größte Herausforderung darstellt. Einzelpersonen und Teams dabei zu helfen, ihr Verhalten zu verstehen und zu verändern, ist eines der Hauptziele.

In dieser Dimension werden sprechen psychologische Sicherheit und eine Kultur des Vertrauens angesprochen. Es wird erforscht, wie sich die Führung verhält und verwenden dabei die transformationale Führung als Modell. Wir stellen Fragen, die untersuchen, wie das Team das Gefühl hat, dass die Organisation in Bezug auf Ausrichtung, Verantwortlichkeit, Autonomie und Empowerment funktioniert und ob und wie sie sich unterstützt fühlen. Wir schauen auf dynamisches Lernen und konstruktive Zusammenarbeit.

Einige Themen konzentrieren sich auf die Drei Wege (Three Ways) ; wir betrachten den Fluss durch die Linse der Kundenorientierung und des Wertstromdenkens. Wir fragen danach, wie Feedback erzeugt, empfangen und in Retrospektiven überprüft wird. Wir untersuchen, wie Innovation und Experimentieren passieren. Es gibt einige Aussagen, die den Teams helfen, etwas über Organisationsdesign und Teamtopologien zu lernen. Und wir beziehen auch Glück und Freude bei der Arbeit sowie Themen der Vielfalt und Inklusion ein.

1. Prozess- und Frameworks-Dimension

Hier passt wunderbar die Formulierung von Jayne: "DevOps ist die glückliche, polygame Ehe von ITSM, zu agil und schlank." Natürlich gehören diese Frameworks in diese Dimension - nämlich wie sie sich mit den DevOps-Aktivitäten verbinden.

Wir schauen uns auch an, wie die Teams die Skalierung ihrer Aktivitäten erleben und ob es für sie funktioniert. Wir möchten, dass die Teams verstehen, wie sie eine hohe Leistung bei kontinuierlicher Compliance erreichen können, also helfen wir ihnen dabei, herauszufinden, wie sie Governance, Risiko und Compliance (GRC) in all ihre Aktivitäten beinhalten.

Wir werfen einen weiteren Blick auf die Arbeitsweise im Wertstrom aus der Prozessperspektive und darauf, wie gut die Teams vom Projekt zum Produkt übergehen. Wir sehen uns einige Frameworks an, die sehr eng mit DevOps verbunden sind: Site Reliability Engineering (Site Reliability Engineers) und DevSecOps.

Wir untersuchen, wie die Teams das System- und Designdenken nutzen. Wir sammeln Daten darüber, welche Elemente von immersivem Lernen, Holacracy und Humanocracy ihnen helfen, ihre DevOps-Ziele zu erreichen.

Dimension der funktionalen Zusammensetzung

In dieser Dimension betrachten wir alle Schritte von der Ideenfindung bis zur Wertrealisierung.

Wir beginnen mit der Betrachtung, wie die Teams zusammenarbeiten und dann, wo und wie Ideen konzipiert, gepflegt und durch Portfolio-, Backlog- und Produktmanagement und Ownership verfeinert werden.

Wir schauen uns Veränderungen an, ob die Teams die Muster des Change Advisory/Genehmigungsausschusses (CAB) auf unterer Ebene verwenden und wie weit sie in Richtung Peer-Review fortgeschritten sind. Wir untersuchen mit ihnen, wie lose gekoppelt ihre Architektur ist und wie sie bauen, entwickeln und integrieren. Wir bitten sie um eine Einschätzung ihrer Fähigkeiten in den Bereichen Test und Validierung sowie Deployment und Release.

Andere Fähigkeiten, die wir untersuchen, sind Operation und Support, Sicherheit, Infosec und Cybersecurity - wir helfen ihnen, die Muster zu verstehen, die die sichersten Umgebungen schaffen, um Geschäftsrisiken zu reduzieren. Wir schauen uns „Data Lakes“ an und wie sie Daten im Allgemeinen nutzen; ihre Zustandsabhängigkeit hat schon immer Probleme mit der DevOps-Geschwindigkeit verursacht; insbesondere bei der Remediation und bei Testdaten. Und wir helfen ihnen zu verstehen, wie sie Zuverlässigkeit und Wiederherstellungsmuster einbauen können, um den Risiken entgegenzuwirken, die mit „high-velocity working“ verbunden sind.

Dimension Intelligente Automatisierung

In dieser Dimension dreht sich alles um die DevOps-Toolchain; vom Artefaktmanagement und der Quellcodekontrolle über CI/CD bis hin zum Live-Betrieb.

Wir sehen uns auch an, wie Tools verwendet werden, um ein einheitliches Backlog zu erstellen, und wie Service und Support nach dem Release ablaufen. Wir untersuchen das Environment Management und wie gut die Teams eine kontinuierliche Compliance erreichen und was dies für die Kundenzufriedenheit bewirkt.

Wir betrachten einige der wichtigsten Tool-Kategorien, die dabei helfen, Feedback für die Verbesserung der Kundenerfahrung zu erhalten; Beobachtbarkeit und Überwachung und fügen alles zusammen, indem wir untersuchen, wie das Team das Wertstrommanagement verwendet, um Sichtbarkeit, Nachvollziehbarkeit und Einblicke in den End-to-End-Fluss durch die DevOps-Toolchain zu erhalten.

Technologie-Ökosystem

Unsere letzte Dimension soll Teams helfen zu verstehen, wie die Infrastruktur, die ihr Produkt, ihre Dienstleistung oder ihren Wertstrom umgibt, ihre Fähigkeit beeinflusst, besser, schneller, sicherer und zufriedener zu arbeiten. Das bedeutet, dass sie ihre Fähigkeiten in Bezug auf Cloud, Elastizität, Serverless, Container, Microservices und APIs verstehen.

Es geht um ihre Einstellung zu Open Source und darum, inwieweit Inner-Source ihnen hilft, besser zu arbeiten oder nicht. Es muss untersucht werden, wie sie ihre Route-to-Live konstruieren und wie sie die Toolchain in diesem Kontext gestalten.

Wir betrachten Sicherheitselemente, wie z. B. die Verwaltung von Geheimnissen, und einige der Technologiekonzepte, die sich derzeit entwickeln und die uns weiter voranbringen werden: robotergestützte Prozessautomatisierung (RPA), Blockchain sowie virtuelle und erweiterte Realität.

Was können wir von der Bewertung der DevOps-Fähigkeiten erwarten?

Dieses fünfdimensionale Modell ermöglicht es Teams und Organisationen, ihren aktuellen Stand auf ihrer DevOps-Reise zu bewerten. Die gesammelten Daten ermöglichen es den Teams, Verbesserungen selbst zu entdecken und den Fortschritt zu beschleunigen - unter der Anleitung eines qualifizierten ADOC-Beratungspartners. Organisationen können die Teamfähigkeiten im gesamten Unternehmen vergleichen, hohe Fähigkeitsniveaus identifizieren und lokale Entdeckungen in globale Verbesserungen umwandeln. ADOC ist ein Tool zur Messung und Beschleunigung einer DevOps-Reise.

ADOC ist jetzt exklusive erstmalig im deutschsprachigen Raum durch Glenfis vertreten. Ich freue mich zudem als Ambassador dieses begleiten zu dürfen.

Fragen, Anregungen, Kritik? Meldet Euch einfach wie gewohnt bei mir.

Bleibt gesund! Liebe Grüsse, Euer Sven

Online Webinar - Die fünf wichtigsten DevOps Skill-Kategorien für Dich und Dein Team- 16.04.2021

2021-04-13T00:00:00Z

Gleich anmelden: --> Mehr Wachstum? Mehr IT-Leistung? Mehr DevOps!

Webinar: 16.04.2021 14:00-15:00

Die fünf wichtigsten DevOps Skill-Kategorien für Dich und Dein Team

Unser Gast, Eveline Oehrlich, Chief Research Officer des DevOps Institutes (DOI) präsentiert zusammen mit Sven den Upskilling 2021: The Enterprise DevOps Skills Report Die "Humans of DevOps" benötigen dringend ein empirisches Modell, das ihre Ziele zur Verbesserung der organisatorischen Leistung durch die Praxis der DevOps Prinzipien unterstützt. Sie wollen in der Lage sein, ihren Fortschritt zu messen, während ihre Fähigkeiten während ihrer DevOps-Reise zunehmen und wissen, wo sie ihre Zeit und Energie investieren müssen. Hier zu hat das DevOps Institute ein Modell entwickelt, welches Teams und Unternehmen befähigt zu begreifen, was DevOps für sie bedeutet und den Fortschritt zu beschleunigen. Wir freuen uns als Enterprise Partner des DevOps Instituts, das Assessment of DevOps Capabilities (ADOC) im Webinar zusammen mit dem, DevOps Instituts vorstellen und Euch erstmalig im deutschsprachigen Raum zur Verfügung zu stellen.

Online Webinar - Scrum Master - 26.03.2021

2021-03-17T00:00:00Z

Gleich anmelden: --> Der Scrum Master

Der Scrum Master - Eine wesentliche Schlüsselfunktion aller erfolgreichen Organisationen

Gesucht werden Führungskräfte (True Leader) die agile Teams in Scrum, Extreme Programming (XP), Kanban und skalierter Agilität entwickeln und unterstützen können. Sie müssen in der Lage sein, Hindernisse für die Teams zu beseitigen und ein Umfeld für leistungsstarke Teamdynamik, kontinuierlichen Fluss und unermüdliche Verbesserung zu fördern. Die selbstorganisierenden, selbstverwaltenden Teams sind bei der Erreichung ihrer Ziele auf kompetente Unterstützung und Führung angewiesen.
Bei skalierter Agilität muss die Verbindung und Ausrichtung der Teams untereinander und die Zusammenarbeit mit den Release Train Engineers und anderen Beteiligten sichergestellt werden, um die Effektivität im gesamten Unternehmen zu erhöhen

Online Webinar - SRE 05.03.2021

2021-03-02T00:00:00Z

Gleich anmelden: --> SRE Webinar

Online Webinar - SAFe 5.1 - 19.02.2021

2021-02-08T00:00:00Z

Gleich anmelden: --> SAFe Webinar

SAFe 5.1 - Was steckt im Scaled Agile Framework und warum brauchen wir skalierte Agilität?

Heute ist es für Unternehmen wichtiger denn je schnell zu antizipieren, auf neue Anforderungen rasch reagieren zu können, und Innovationen zeitnah auf den Markt zu bringen. Agile Entwicklungsteams sind sehr erfolgreich darin diese neuen Produkte und Service zu entwickeln. Wie sieht es aber aus wenn komplexe und umfangreiche Systeme aufgebaut und unterhalten werden müssen? Was ist wenn die Ergebnisse einer grösseren Organisation, bestehend aus verschiedenen agilen Teams, siloübergreifend, ausgerichtet und synchronisiert werden müssen? In diesem Webinar über das Scaled Agile Framework (SAFe) erfährst Du alles, was Du darüber wissen musst, praxisbezogen und in konzentrierter Form.

Die folgenden Fragen werden wir beantworten:

Was ist agile Skalierung und wozu brauchen wir das?
Was ist das Scaled Agile Framework (SAFe) und wie funktioniert SAFe?
Was sind die Vor- und Nachteile von SAFe?
Welche Herausforderungen entstehen beim Einsatz von SAFe und wie kannst Du damit umgehen?

Ich freue mich mit Euch das Thema zu besprechen.

LG Ralf

GlenfisAgile tritt dem Scaled Agile Partner-Netzwerk bei

2021-01-29T00:00:00Z

GlenfisAgile tritt dem Scaled Agile Partner-Netzwerk bei

Glenfis ist dieses Jahr offiziell dem Scaled Agile Partner Netzwerk als Bronze Partner beigetreten. Dieses weltweite Netzwerk umfasst Transformations- und Plattformanbieter, die Unternehmen dabei unterstützen, Geschäftsergebnisse durch die Einführung des Scaled Agile Framework (SAFe) zu erleichtern und zu beschleunigen.

Als weltweit führendes Framework für Unternehmensagilität ermöglicht SAFe Unternehmen, die grossen Herausforderungen bei der Entwicklung und Bereitstellung von qualitativ hochwertiger Software und Systemen in möglichst kurzer Zeit zu bewältigen.

SAFe ist eine Wissenssammlung bewährter, integrierter Prinzipien, Praktiken und Kompetenzen aus Lean, Agile und DevOps und ergänzt das Glenfis Beratungs- und Ausbildungsangebot seit Jahren optimal. So konnten wir in den letzten Jahren über 200 Fachleute erfolgreich in Kursen wie SAFe Einführung, Leading SAFe, SAFe Scrum Master, SAFe Product Owner und SAFe für Teams ausbilden. Dabei haben wir uns ein gutes Verständnis des SAFe Frameworks angeeignet, verfügen über Anwendungsbeispiele aus den meisten Branchen und können damit den Praxisbezug sicherstellen.

Mit der offiziellen SAFe Partnerschaft haben wir die nächste Phase unserer SAFe Reise eingeleitet.

Als SAFe Transformation Partner sind wir noch besser in der Lage Unternehmen erfolgreich in die Unternehmensagilität zu begleiten. Dabei bietet uns die Scaled Agile Partnerschaft die Möglichkeit der Zusammenarbeit mit den weltbesten SAFe Experten. Als Transformationspartner haben wir noch besseren Zugriff auf Expertenwissen und Toolkits, um sie bei Ihrer SAFe Implementierung zu unterstützen. Durch die enge Zusammenarbeit bekommen wir schnellen Zugriff auf neue Trends und Methoden und profitieren vom Austausch und den Erfahrungen im Partnernetz. Diese Vorteile setzen wir zu Eurem Nutzen ein.

Bucht direkt eine SAFe Ausbildung (Glenfis Academy) oder sprecht mit uns über Eure Beratungs- und Consultinganforderungen.

Wir freuen uns über Eure Fragen und Rückmeldungen und stehen für einen Austausch gerne zur Verfügung.

Microservices, Container und CI/CD Toolchain – aber wie geht das denn nun?

2021-01-29T00:00:00Z

Wie schon Christopher Little im DevOps Handbuch sagt: „DevOps is not about automation, just as astronomy is not about telescopes.” Während es also bei DevOps nicht nur um Automatisierung geht, sondern primär um Praktiken, die eine DevOps-Kultur etablieren ist die Automatisierung doch ein wesentlicher Erfolgsfaktor. Schliesslich nutzen wir Technologie, um Zeit für Verbesserungen und Innovationen frei zu bekommen.

Bei der Automatisierung gehen Cloud und DevOps dabei Hand in Hand – und sind viel stärker, wenn sie zusammen angewendet werden. DevOps macht beispielsweise von "Infrastructure as Code" Praktiken gebrauch. Cloud-Anbieter stellen dabei programmierbare Infrastruktur zur Verfügung und anstatt die Infrastruktur manuell zu konfigurieren werden die Konfigurationen vollständig in den Anwendungscode integrieren. Grundsätzlich empfiehlt es sich die Cloud- und DevOps-Transformation auf der Grundlage etablierter Engineering-Praktiken zu beschleunigen, anstatt DevOps neu zu erfinden. Nichtsdestotrotz bedarf es in der Regel die Modifizierung vorhandener Anwendungen für die Cloud, die Entwicklung neuer Cloud nativer Anwendungen und die Transformation der Architektur und Infrastruktur. Microservices-Architekturen sind dabei eine Herangehensweise an die Entwicklung von Software, mit der komplexe Applikationen in einzelne unabhängige Bausteine oder Services aufgeteilt werden. Diese modularen Services können individuell deployed und verwaltet werden, wodurch grosse Applikationen robuster gegenüber Veränderungen werden.

Im Gegensatz zu traditionellen (monolithischen) Architekturen, die darauf abzielen, Software als eine einzelne Einheit aufzubauen, verfolgen Microservices-Architekturen einen modularen Ansatz. Die Software wird also in unterschiedliche Komponenten aufgeschlüsselt, die aus unabhängig voneinander austauschbaren und erweiterbaren Services bestehen. Diese Services können als Prozesse definiert werden, die über ein Netzwerk unter Verwendung von technologieunabhängigen Protokollen (APIs) kommunizieren. Im besten Fall hat jeder Microservice seine eigene Datenbank, damit Verantwortung dezentralisiert und Updates individuell durchgeführt werden können.
Die Idee lose gekoppelter Services, die leicht in der Wartung sind und gleichzeitig einfach getestet werden können, klingt besonders für Unternehmen faszinierend, deren IT-Herausforderungen in zu komplexen Applikationen begründet liegen. Mit ständiger Bereitstellung und Integration, Containern und DevOps ist die Innovationsgeschwindigkeit im Web sehr stark angestiegen, deshalb ist das Microservices-Konzept heute wichtiger denn je. Doch bevor das bestehende System komplett überarbeitet wird, müssen Unternehmen zunächst verstehen, wie Microservices überhaupt funktionieren. Am Anfang steht das Design eines Microservices-Architekturdiagramm, dass für die Abbildung von Abhängigkeiten notwendig ist. Diese wichtige Phase im Design-Prozess stellt sicher, dass sich ein möglicher Systemfehler in einem einzelnen Service-Bereich nicht auf das gesamte System auswirkt.

Vorteile einer Microservice Architektur:

Die Wartung, Fehlersuche und -Behandlung wird wesentlich einfacher und weniger aufwendig
Somit erlaubt das Modell einen Modularitätsgrad, mit dem die einzelnen Dienste schneller zu entwickeln, einfacher zu verstehen (agiler) und einfacher zu pflegen sind
Automatisierungstechniken wie kontinuierlichen Integration & Bereitstellung (CI/CD) wird möglich
Die unabhängigen Komponenten können für andere Projekte/Services/Features wiederverwendet werden
Codes und Applikationen sind zugänglicher für Mitarbeiter, die nicht Teil der Entwickler-Teams sind
Jeder eingesetzte Service kann dupliziert werden (Skalierbarkeit und Resilienz)
Einzelne Software-Komponenten lassen sich einfacher testen (automatisiertes Testen)

Für die Microservices Governance wird bspw. das Open-Source-Container-Orchestrierungssystem Kubernetes (K8s)eingesetzt, um die Microservices-Architektur zu hosten. Kubernetes bietet eine flexible Plattform sowie CI-Tools und wird gemäss unserer Idee vom PaaS Provider zur Verfügung gestellt.

Container dienen der Kapselung und Isolierung von Applikationen mit allen erforderlichen Systemkomponenten. Sie stellen alle für die Verarbeitung von Programmcode erforderlichen Ressourcen unabhängig von physischen Servern und deren Betriebssystemplattformen zur Verfügung und ermöglichen so einen einfacheren verteilten Einsatz sowie eine einfache und schnelle Portierbarkeit. Container (z.B. Docker) passen perfekt zu einem auf Microservices basierten Software-Architekturansatz und reduzieren den Provider-Lock-In da man seine Programme in den Containern schnell und meist ohne grössere Abhängigkeiten von A nach B verschieben kann. Wenngleich Container in der Linux- und Provider-Welt seit langem bekannt sind und auch benutzt hat sich Container-Virtualisierung erst mit dem Erscheinen von Docker flächendeckend durchgesetzt. Das gilt vor allem deshalb, weil Docker im DevOps-Umfeld, in dem sich Administratoren zwangsläufig mit unterschiedlichen Laufzeitumgebungen, Configuration-Management-Werkzeugen, Paketformaten und Deployment-Strategien auseinandersetzen müssen, für einheitliche Standards sorgt.

Ein wichtiger Punkt bei Microservices ist, dass jeder Microservice seine zugehörigen Daten besitzt und daher eine eigene Datenbank haben sollte. Datenbanken können bspw. auf regulären eigenständigen Servern in lokalen Clustern oder in PaaS-Diensten in der Cloud verwendet werden. Die Datenbanken können sich dabei an einem beliebigen Ort befinden. In diesem Fall befinden sie sich alle im selben Container, um den Arbeitsspeicherbedarf von Docker so gering wie möglich zu halten. Microsoft stellt bspw. seinen SQL-Server auch als Container-Image zur Verfügung, der dann in einer Containerumgebung auf Basis von Docker läuft. Diesen Punkt müssen wir sicher noch mit den Experten klären (SWOT).

Mit einer CI/CD-Pipeline ("Continuous Integration, Continuous Delivery und Continuous Deployment") kombiniert, realisiert man in Container-Umgebungen fabrikähnliche Verfahren von der Software-Entwicklung, über das Testing bis hin zum automatisierten Deployment von Software (DevOps). Microservices und ihre Bündelung in Containern haben also nicht nur hohe Effizienzpotenziale. Sie helfen auch dabei, dass Ihr Euch nicht in Abhängigkeiten von (Cloud-) Anbietern begeben müsst. Alle Hyperscaler bieten PaaS-Lösungen.

Ich freue mich auf Eure Ergänzungen und Kommentare.

Liebe Grüsse Euer Ralf

Online Webinar - DevOps 05.02.2021

2021-01-29T00:00:00Z

Gleich anmelden: --> DevOps Webinar

DevOps Studie 2021 für die Schweiz

2021-01-20T00:00:00Z

Heute freue ich mich ganz besonders Euch ein Beitrag von VSHN vorstellen zu dürfen. VSHN trägt den Namen "The DevOps Company" nicht ohne Grund und hat wie im letzten Jahr keine Mühen gescheut, um für uns alle in Erfahrung bringen zu wollen, wie es um den aktuellen Stand von DevOps in der Schweiz steht.

Hierzu hatte ich die Gelegenheit mich mit Markus Speth, seines Zeichen CMO von VSHN, auszutauschen.

Viel Spass beim Lesen und vor allem beim Mitmachen !

Bleibt gesund, Euer Sven

DevOps in der Schweiz 2021

In einer Welt der Ungewissheit und des Zweifels, in der Software die Welt auffrisst, jedes Unternehmen ein Softwareunternehmen ist und alle Branchen dem Druck der Disruption der digitalen Transformation ausgesetzt sind, bestehen insbesondere die Teams und Unternehmen, die effektiv, stabil und multidisziplinär arbeiten und auf den Kundennutzen ausgerichtet sind.

DevOps ist Enabler einer modernen IT

Die Regeln des Geschäftslebens haben sich grundlegend geändert, was zum Aufstieg von DevOps geführt hat. Eine moderne IT-Organisation muss flexibel und schnell auf sich ändernde Anforderungen reagieren, ohne dabei den Sicherheitsaspekt zu vernachlässigen. Softwareentwicklung und Betrieb müssen zusammenarbeiten, um agil und anpassungsfähig zu sein. Ständige datengesteuerte Neubewertungsschleifen und ein kontinuierlicher Verbesserungsprozess helfen der Organisation dabei, die Qualität des Outputs fortlaufend zu verbessern und zu maximieren. DevOps steht hierbei für eine neue Kultur und Herangehensweise in der Zusammenarbeit, um die Softwarequalität und die Verfügbarkeit zu erhöhen und ultimativ die Kundenzufriedenheit zu steigern.

DevOps betrifft alle Sektoren und ist nicht nur auf die reine Softwareentwicklung beschränkt. Viele traditionelle Wirtschaftszweige unterstützen heute ihr Kerngeschäft durch Software: Egal ob Banken, Versicherungen, Handel oder Industrie – die Digitalisierung macht vor keiner Branche halt. Ist der Kunde glücklich, ist es auch das Team, der einzelne Mitarbeiter und letztlich auch das Unternehmen.

Die aktuell erfolgreichsten Produktfirmen wie Netflix deployen ihre Applikationen mehrere hundert bis tausend Mal pro Tag. Ausfälle können nicht verhindert, aber von vornherein eingeplant werden, um von ihnen zu lernen.

Im Gegensatz zu Agile geht DevOps über den Entwicklungsteil hinaus und hat die gesamte Wertschöpfungskette im Visier: DevOps-Teams tragen die Verantwortung für ein Produkt über den gesamten Lifecycle hinweg. Doch DevOps ist nicht nur dazu da, die Softwareentwicklung durch Erhöhung des Automatisierungsgrads und Steigerung der Effizienz und Agilität zu beschleunigen.

DevOps kann Enabler des kulturellen Wandels einer Organisation sein und Zusammenarbeit, Arbeitsklima und Motivation insgesamt verbessern. DevOps steht für Kollaboration, Flexibilität, Agilität und die Konzentration auf den gemeinsamen Geschäftserfolg: zufriedene Nutzer, marktgerechte Produkte und langfristig motivierte und loyale Mitarbeiter.

Hilf mit, den aktuellen Stand von DevOps in der Schweiz zu ermitteln!

Auch in der Schweiz sind Softwarefirmen auf dem Vormarsch, die durch eine gelebte DevOps-Praxis ihre Applikationen stetig verbessern und ihre Kunden in den Vordergrund stellen.

Um den aktuellen Stand von DevOps zu ermitteln, führt VSHN auch in diesem Jahr wieder eine Studie durch. "DevOps in der Schweiz 2021" untersucht, wie DevOps in der Schweiz verstanden wird und ob schon nach DevOps-Prinzipien gearbeitet wird. Die Ergebnisse werden wir mit den letztjährigen verglichen, um direkt Rückschlüsse und Trends erkennen zu können.

Nimm Teil an unserer Studie und berichte uns von deinen Erfahrungen mit DevOps und welche Rolle DevOps in eurem Unternehmen spielt.

Umfrage:

Die Umfrage ist offen bis zum 31. Januar 2021 und darf selbstverständlich mit anderen geteilt, geshared und retweeted werden. Du benötigst nur ca. 5 min. zum ausfüllen. Hier geht’s direkt zur Umfrage:

https://www.surveymonkey.com/r/devops2021

Viel Spass beim mitmachen.

Markus Speth

Organisationen neu erfinden

2020-12-03T00:00:00Z

Letzte Woche durfte ich den DevOps Leader Kurs® vom DevOps Institute in einer online Version als Trainer durchführen.
Es ist in den aufkommenden Gesprächen wieder deutlich geworden, welch besondere Wirkung die verschiedenen Leadership Typen haben. Wie soll ich mich verhalten, soll ich von Command & Control plötzlich auf Servant Leadership gehen? Ist das realistisch und noch mehr, ist das überhaupt glaubwürdig? Doch wie nötig ein Wechsel alter Verhaltensweisen sein kann, wollen wir ein wenig beleuchten.

Eine Tatsache wird vorerst bleiben. Verhalten, insbesondere Führungsverhalten, ist einer der Hauptschlüssel in diesen Tagen um Ergebnisse schneller, sicherer und auch zufriedenstellender zu erzielen und das Wohl eines jeden einzelnen dabei auch noch zu berücksichtigen.

Die Welt der Arbeit hat sich geändert. Wir haben uns vom Zeitalter des Öls und der Massenproduktion, in dem die meisten menschlichen Bestrebungen sich wiederholten und bekannt waren, zum Zeitalter der Digitalisierung hin bewegt, in dem menschliche Bestrebungen immer einzigartiger und unbekannter werden und in dem Software einen kontinuierlichen Strom von Produktinnovationen ermöglicht unabhängig vom Industriesektor.

Mit den neuen Produktionsmitteln ist die Änderung kein Stakkato mehr; sie ist kontinuierlich und das Tempo nimmt zu.

Heutzutage besteht ein Bedarf an experimentieren, viele wollen sich einfach ausprobieren und das auch am Arbeitsplatz. Es besteht der Bedarf an Zusammenarbeit, an dem Bedarf schnellstmöglich Wissen anzueignen, um sich flexibel anzupassen, um Arbeitsergebnisse zu optimieren. Dies erfordert ein Umfeld, in dem es sicher ist zu experimentieren; man darf früh und auch oft scheitern, (fail early als eines der Prinzipien von DevOps) ohne Angst vor Repressalien zu haben.

Die Bestrebung ist offensichtlich. Man möchte durch ein hohes Mass an Befähigung und fokussiertem Arbeiten auf ein gemeinsames gewünschtes Ergebnis hinsteuern. Dies ist eine einnehmendere, lohnendere und menschlichere Art zu arbeiten.

Leider ist gesunder Menschenverstand keine gängige Methode. Laut dem letzten State of Agile Report sind vier der fünf grössten Hindernisse für eine bessere Arbeitsweise kultureller Natur -darunter eine zu geringe Beteiligung der Führung und eine unzureichende Unterstützung und Förderung durch das Management.

Im Folgenden werden drei gängige Muster und die entsprechenden Anti-Muster, für Führungskräfte auf allen Ebenen und in allen Rollen beschrieben, um wie eingangs erwähnt, schneller, sicherer und glücklichere Ergebnisse zu erreichen.

Anti-Muster oder neudeutsch Anti-Pattern, sind Herangehensweisen, die normalerweise Gegenwind erzeugen, der einen anstrengenden Job noch schwieriger macht. Auf der anderen Seite stehen die Muster und Prinzipien, die normalerweise Rückenwind erzeugen. Weil Änderungen aufkommen und Organisationen komplexe, anpassungsfähige Systeme sind, gibt es keine Patentlösung für alle Herausforderungen und keine Methode, die für sich alleingenommen der Heilsbringer ist.

Von daher bin ich auch nie müde zu erwähnen, dass DevOps keine Methode darstellt, sondern eine kulturelle Bewegung.

do as I say, not as I do

Bei diesem Anti-Prinzip mangelt es an Vorbildfunktion, so dass Bitten oder sogar Befehle zur Änderung von einzelnen gegeben werden, ohne dass diese Änderung von innen heraus stattfindet. Das inkongruente Verhalten ist deutlich zu erkennen. Das eine wird gesagt, das andere getan. Taten passen nicht zu Worten. Um Fredric Laloux, den Autor von "Reinventing Organizations" zu zitieren: "Der Bewusstseinsgrad einer Organisation kann den Bewusstseinsgrad ihrer Führungskraft nicht übersteigen".

Das ist nichts was Menschen veranlassen oder befehlen können. Es ist nicht dasselbe wie ein Update des Betriebssystems zu starten, wo man einfach das neueste Update herunterlädt, es installiert und den Return Button betätigt. Es ist weder eine Anwendung, die man einfach aktivieren kann, noch eine Änderung des Organigramms die man durchführen kann. Es geht in allen Fällen nicht ohne eine Änderung des Verhaltens, eine Änderung der Kultur.

Es gibt nichts zu finden in den Ursprüngen der Worte "Lead", "Leader" oder "Leadership", was mit den Worten "Order", "Command", "Direct", "Commit" oder "Control" zu tun hat. Die Definition von Führung ist nicht jemandem zu befehlen eine Reise zu unternehmen und dann auch noch sagt: "Viel Glück! Lass mich wissen, wenn du dort ankommst".

Der Ursprung des Wortes stammt von den alt-englischen Wörtern „laedan“, was "führen, begleiten" bedeutet, und layjan, was "reisen" bedeutet. Führen, heisst "auf einer Reise führen/begleiten". Führungspersonen gehen auf dieselbe Reise wie die Geführten.

Psychologisch unsicher

Am 1. Februar 2003 zerbrach die Raumfähre Columbia tragischerweise beim Wiedereintritt in die Erdatmosphäre, weil austretender Schaumstoff einen der Flügel traf. Ein Ingenieur hatte sechsmal versucht Bilder des Flügels zu bekommen, bevor ihm gesagt wurde "das ist ein totes Thema". Der Schaumstoff löste sich regelmässig beim Start und der Erfolg in der Vergangenheit (keine Katastrophen) wurde als Indikator für den zukünftigen Erfolg angesehen. Laut dem Columbia Accident Investigation Board hatte "die Organisationskultur genauso viel mit diesem Unfall zu tun wie der Schaumstoff selber" und "die Ursachen des institutionellen Fehlers, die für die Challenger Katastrophe [17 Jahre zuvor] verantwortlich war, sind heute noch nicht behoben".

Die Ölkatastrophe von Deepwater Horizon im Jahr 2010 war der schlimmste Ölunfall der Geschichte. Die Hälfte der befragten Arbeiter gab an, Angst vor Repressalien zu haben, wenn sie über unsichere Arbeitsbedingungen berichten würden, die zu der Katastrophe geführt haben.

Im März 2020 stellte der Ausschuss des US-Hauses in seinen vorläufigen Untersuchungsergebnissen zu den tödlichen Abstürzen der Boeing 737 Max fest, dass auf dem Höhepunkt der nötigen Zulassungsaktivitäten "39% der befragten Mitarbeiter einen übermässigen Druck vom Management wahrgenommen haben und dass 29% über die Folgen besorgt waren, wenn sie über diesen erheblichen Druck berichteten würden, was ein besorgniserregendes Bild kultureller Probleme bei Boeing ergibt, die die Sicherheit und Kontrolle untergraben".

Wenn es eine Kultur der Angst und Furcht vor Repressalien gibt, werden schlechte Nachrichten begraben, bis es zu spät ist. Zwei Hierarchieebenen höher scheint alles in Ordnung zu sein; der RAG-Status (red-amber-green) bleibt so lange auf grün, bis einem alles um die Ohren fliegt und keine Zeit mehr zum Reagieren bleibt. „Wir haben von alledem nichts gewusst…“, ist sicher nur eine der bekannten Floskeln

Deterministische Denkweise

Eine deterministische Denkweise führt dazu, dass einmalige, nicht bekannte Arbeiten und Situationen so behandelt werden, als wären sie vorhersehbar und schon längst bekannt, und dass das Ergebnis die Lösung und die Aufgaben in einem festen Projektplan vorherbestimmt werden können.

Häufig gibt es ein " Milestone-Driven Management", bei dem Erfolg über das Erreichen von Milestones definiert wird. Habt ihr Euch nicht auch schon gefragt, warum in Projekten morbide Begriffe verwendet werden wie „Verfallsdatum“ oder „Deadline“? Dies ist sicher nicht optimal beim Erreichen gemeinsamer Ziele und Ergebnisse.

Der Fokus liegt eher auf dem fixen Output als auf dem Lernen und das Anwenden des Erlernten auf dem gemeinsamen Weg. Der Weg ist das Ziel verstaubt als Spruch in alten Bibliotheken, Konfuzius wäre nicht happy damit.

Der Output der am Anfang mal bestimmt wurde, bei dem die geringsten Informationen zu einem Projekt vorherrschten, ist sicher nicht optimal für das Erreichen des Gesamt-Ergebnis denn die Bedingungen ändern sich ständig.

Es lohnt sich die Frage zu stellen: "Wie oft haben wir genau diese Arbeiten gemacht, in genau diesem Kontext, mit diesen Leuten? Wenn es schon viele Male so gemacht wurde, wie zum Beispiel beim Bau eines Autos oder bei der Installation eines Servers in einem Rechenzentrum, gibt es tatsächlich „bekannte Unbekannte“, und ein schlanker, deterministischer Ansatz kann angebracht sein.

Wenn es noch nie zuvor in genau diesem Zusammenhang gemacht wurde, wie zum Beispiel bei der Entwicklung eines Produkts, einer Änderung der Organisation oder sogar der Installation eines ERP-Systems, gibt es massiv „unbekannte Unbekannte“.

Ein agiler, innovativer Ansatz mit schneller Lernfähigkeit reduziert das Risiko und ermöglicht die Optimierung im Hinblick auf die gewünschten Ergebnisse.

Jedes dieser Anti-Pattern hat ein entsprechendes Gegen-Muster.

Führungskräfte gehen voraus

Führungspersönlichkeiten führen von vorne, führen und begleiten die Menschen auf einer Reise, wie es dem Ursprung des Wortes entspricht. Man spürt dieselben Prüfungen, Niederschläge und Triumphe. Führung erfordert Mut und Verwundbarkeit, man wird zum Vorbild und lebt die gewünschten Verhaltensweisen vor.

Es ist einfacher darüber zu reden, als es tatsächlich zu tun. Änderung beginnt an der Spitze. Den Satz mit dem Fisch spare ich mir an dieser Stelle 😊

Verhaltensregeln, die von Verantwortlichen in Führungspositionen gezeigt werden, haben einen unverhältnismässig grossen Einfluss auf Kultur, Anerkennung, Belohnung, Verhaltensweisen, Zweck, Motivation und darauf, wer wir sind und wie wir als Unternehmen funktionieren.

Seid mehr Leader, weniger Commander. Stellt sicher, dass es ein hohes „Alignment“ bei den gewünschten Ergebnissen gibt. Lasst dann die Teams autonom daran arbeiten und bietet Unterstützung an, um Hindernisse aus dem Weg zu räumen.

Psychologische Sicherheit

Um die Ergebnisse zu optimieren, müssen die Menschen in der Lage sein, sicher zu experimentieren. Sie müssen das Gefühl haben, dass es sicher ist zu lernen, den Status quo in Frage zu stellen, jemanden in einer höheren Position zu befragen, Verbesserungsexperimente durchzuführen oder eine Idee zu testen, die scheitern könnte.

Darüber hinaus müssen die Mitarbeiter*innen dafür anerkannt werden, dass sie früh scheitern (frühes Lernen), um so den Trugschluss des Kosten-Nutzen-Verhältnisses zu vermeiden. Es gibt kein fehlgeschlagenes Experiment, es gibt nur das Lernen daraus. Der einzige Fehler ist die Annahme, dass die Zukunft vorhersagbar ist und dass Organisationen reduktionistisch sind, wie die Funktionsweise einer mechanischen Uhr.

Googles Projekt Aristoteles fand heraus, dass an erster Stelle der Bestimmungsfaktoren für leistungsstarke Teams die psychologische Sicherheit ist.

Laut Amy C. Edmondson, Autorin von „The Fearless Organization“, müssen Organisationen drei Schritte unternehmen, um psychologische Sicherheit aufzubauen.

Zuerst müssen Fehler als Lernerfolg angesehen werden und die geschaffene Arbeitswelt als etwas, das nicht persönlich ist, und somit auch frei von Schuldzuweisungen als neu zu definieren ist.

Zweitens müssen sie zur Teilnahme einladen um Input bitten und zuhören, insbesondere wenn die Betroffenen darauf konditioniert wurden, nicht das Wort zu ergreifen.

Drittens müssen sie produktiv reagieren, Wertschätzung für Feedback und stetiges Lernen zum Ausdruck bringen und schnelles, „intelligentes Scheitern“ feiern.

Neue Denkweise

Die Anwendung einer neuen Denkweise anstelle einer deterministischen Denkweise legt Wert auf Experimente, Zusammenarbeit und kontinuierliches Lernen im Einklang mit den gewünschten Ergebnissen. Es legt den Fokus auf wertvolle Ergebnisse und nicht nur auf einfachen „Output“.

Änderungen, Verbesserungen und die Zukunft sind nicht vorhersehbar und die Art und Weise, wie ein komplexes adaptives System (d.h. eine Organisation) reagiert, ist ebenfalls nicht vorhersehbar. Um die Ergebnisse zu optimieren, muss es eine Verlagerung vom Output (fester Weg, langsames Lernen) zu den Resultaten (wackliger Weg, schnelles Lernen) geben, von vorbestimmten Lösungen zum Testen von Annahemen (learn fast and cheap).

Der beste Weg eine Hypothese zu testen wenn die Arbeit im Entstehen begriffen ist besteht darin zu erforschen, zu spüren und zu reagieren. Organisationen, die überleben und erfolgreich wachsen wollen, müssen ein neues Gedächtnis aufbauen, eine (wieder)lernende Organisation werden, experimentieren, schnelles Feedback einholen und früh und oft auf Neues reagieren.

Die Erarbeitung von Rollenmodellen für das gewünschte Verhalten, die Förderung der psychologischen Sicherheit und die Optimierung der Herangehensweise an die Art der Arbeit, werden als Rückenwind wirken, damit wir schneller, sicherer und glücklicher bessere Leistungen erbringen können.

Gerade in der jetzigen Zeit, brauchen wir Vertrauen und Leader die das beste aus ihnen Mitarbeiter*innen herausholen.

Bleibt gesund, LG Euer Sven

Scrum Rollen in anderen Galaxien!

2020-08-26T00:00:00Z

....da wagte ein junger Berater-Schüler, das gut geplante, doch ungewöhnlich umgesetzte Scrum-Framework einer Organisation zu hinterfragen.

Wie konnte er nur?

Es entstanden kuriose Diskussionen über die Aufgaben einzelner Rollen. Ich rede hier nicht von den klassischen Rollen, die wir kennen, NEIN, es waren die Rollen, die hinzugedichtet wurden und als unabdingbar galten. Man müsse eben auch als Berater von aussen verstehen, dass gewisse Elemente einer Branche nicht vor Scrum Halt machen könnten…und so öffnete der junge Berater-Schüler wohl unbewusst die Luken zum Todesstern und liess einige bis dato unerwartete Scrum-Rollen aus der Kiste…..Alle diese Rollen hatten eines gemeinsam, sie versprachen einem Keksen und faselten etwas von einer dunklen Seite….

Der junge Berater dachte sich wie die Leser seines Blogs, dass er davon ausgehen konnte, dass die meisten bereits mit den typischen Rollen vertraut sind, wenn es um Scrum geht (ihr wisst schon, das Scrum Team, der Scrum Master, der Scrum Product Owner).

Er war sich auch sehr sicher, dass alle wussten, welche Aufgaben jeder von ihnen erfüllen sollte und wie sie interagieren und zusammenarbeiten sollten, um ein Projekt erfolgreich abschliessen zu können.

Aus diesem Grund wollte er auch aufhören, über traditionelle und bekannte Scrum-Rollen zu sprechen, um sich mit einigen anderen ungewöhnlichen jedoch einflussreichen Rollen vertraut zu machen, die es auch in deinem agilen Team geben könnte.

Sei also auf der Hut!

Um seinen Standpunkt besser zu erklären, schrieb er uns eine (nicht umfassende, aber hoffentlich ziemlich relevante) Liste von Rollen auf um diese Erfahrungen uns zur Verfügung stellen.

Mal sehen, ob wir auch diese Rollen in unserem Team erkennen 😉

—

Die wortreichen „Gäste“ des Meetings

Obwohl sie nicht wirklich eine besondere Meinung über etwas haben, werden sie vorgeben, eine zu haben, nur um Zeit zu verschwenden, indem sie ihren Sprechautomat benutzen um andere Leute zu verwirren. Sei es bewusst, oder unbewusst…

Mehr noch; selbst wenn sie sich dazu bekennen mit jemandem über etwas übereinzustimmen, müssen sie mindestens eine halbe Stunde damit verbringen, ihre Zustimmung zu betonen; ganz zu schweigen davon, wenn sie vorgeben, nicht übereinzustimmen...

Die engstirnigen Untergebenen

Sie tun nur, was ihr Chef ihnen sagt.

Auch wenn jemand der Meinung ist, dass diese Art von Arbeitern leicht zu managen sind da sie ihrem Chef immer zunicken, macht die Tatsache, dass sie normalerweise nicht in der Lage sind eine persönliche Meinung zu einem relevanten Thema zu haben, sie in einer agilen Umgebung praktisch nutzlos.

Merkwürdigerweise entscheiden sie sich im entfernten Fall, ihre "Meinung" mit dem Rest des Teams zu teilen, denn ihre Meinung stimmt immer genau mit der überein, was ihr Boss bereits gesagt hat.

Die irreführenden Programmierer

Wenn ein Tester den Entwickler nach etwas Merkwürdigem fragt, von dem er glaubt, es in der Anwendung gefunden zu haben, versucht dieser lieber schnell diese Veränderung vorzunehmen, wobei er sich auf etwas anderes konzentriert (etwas Ähnliches natürlich, aber völlig unabhängig von dem speziellen Bereich, der von dem merkwürdigen Gefühl des Testers betroffen ist), nur um sicherzugehen, dass der Tester durch eine gut funktionierende Funktionalität abgelenkt werden kann.

Übrigens, was diese Programmierer wahrscheinlich tun in der Hoffnung den Tester dazu zu bringen sich mit dieser lästigen Gewohnheit abzufinden und einfach zu einer anderen Aufgabe/Funktion zu springen, könnte den gegenteiligen Effekt haben da der Tester normalerweise anfängt, diese seltsame Sache zu untersuchen die ihre Aufmerksamkeit noch tiefer in sich gefangen hat...

Die verblendeten Testdesigner

Für diese Art von Leuten ist es egal ob eine Anforderung überhaupt Sinn ergibt oder eben nicht. Anstatt eine Überprüfung der Anforderungen vorzuschlagen, fangen sie einfach atemlos an zu arbeiten, um so schnell wie möglich einen Testfall zu haben um dann auch noch den Unsinn zu überprüfen.

Wenn der Testfall also fertig ist und ein aufgeschlossener Tester erkennt, dass sowohl die Anforderung als auch der Testfall keinen Sinn ergeben, gibt es für das Team trotzdem oder gerade deswegen noch eine Menge Arbeit zu tun: eine Anforderung muss aktualisiert werden, eine Implementierung muss überprüft werden, ein Testfall muss wahrscheinlich gelöscht werden, ein neuer Testfall muss entworfen werden...

Und selbst wenn es wahr ist, dass einige dieser Dinge sowieso hätten getan werden müssen, in einer weniger engstirnigen und agileren Umgebung hätten einige von diesen Tests früher erledigt werden können während andere vielleicht gar nicht erstellt worden wären.

Die boykottierenden Entwickler

Auch wenn sie normalerweise stolz darauf sind, dass sie einige Fehler in der Anwendung eingebaut und belassen haben, nur der Kontinuität des Projekts zuliebe, würde ich nicht darauf wetten, dass sie in der Lage sind, all diese Fehler zu beheben. Ausserdem ist ihr Code normalerweise so schlecht, dass niemand sonst in der Lage ist diese Veränderungen zu ändern, geschweige denn zu refaktorisieren.

Es muss nicht erwähnt werden, dass diese Art von altmodischem und unethischem Verhalten besonders bei kritischen Projekten riskant sein kann.

Die grosszügigen Inkompetenten

Sie sind normalerweise in fast allem inkompetent was kein ernstes Problem darstellen würde, wenn sie nicht bei allem helfen wollten, in dem sie unfähig sind.

Mit anderen Worten das Problem ist je schlechter sie etwas tun, desto mehr wollen sie helfen etwas zu tun.

Seltsamerweise lehnen sie normalerweise die Hilfe anderer ab, vielleicht nur, um sicherzustellen, dass sie die einzigen sind, denen es erlaubt ist zu "helfen"...

Die laaaaaangsamen Typen

Nicht zuletzt passen Menschen die aus offensichtlichen Gründen [PAUSE] denken und [PAUSE] langsam [PAUSE], sehr [PAUSE] langsam [PAUSE] handeln, nicht sehr gut in eine agile Umgebung. Ausserdem, da sie sich normalerweise nie unter Druck fühlen, gibt es keine Möglichkeit, sie schneller zu machen: sie werden einfach in ihrem gemächlichen Tempo weitermachen.

Auch wenn sie für Projekte, die auf andere Art und Weise funktionieren, sicherlich nützlich sein könnten, scheinen sie sich nicht für eine Umgebung zu eignen, in der sie kontinuierliche Leistungen erbringen und in der man stattdessen besser die Verwendung von pro-aktiven und schnelleren Typen nutzen sollte.

—

Nun, wenn du bis hierher gelesen hast, liegt es wahrscheinlich daran, dass du einige dieser unerwarteten Rollen in deinem Scrum-Team erkannt hast. Ausserdem scheinen einige Leute eine Gabe zu haben, mehr als eine dieser Eigenschaften gleichzeitig zu haben.

Wenn dem so ist, solltest du ernsthaft in Betracht ziehen, dass sie, wenn du sie nicht loswirst, deine zerbrechliche Umgebung sprengen könnten, da sie (unbewusst oder nicht) wirklich darauf erpicht sind dein (nur scheinbar) agiles Team zu zerstören, zumindest bis sie an Bord der Fähre des Imperators sind…

In diesem Sinne***, „Do or do not there is no try“,*** lasst und nicht gleichzeitig eine Aufgabe erledigen indem wir sie nicht erledigen. Wenn du etwas tust, dann verpflichte dich. Engagiere dich, oder tue es überhaupt nicht. Ich bin gespannt auf weitere, ungeahnte Rollen im Scrum Universum…

-Euer Sven

Kommentare (archiviert, 2017–2023)

Roland Brechbühl · 2020-08-29

Der Chef, der einfach nur will, dass es funktioniert, der keine Zeit hat sich damit auseinander zu setzen und der findet, die Informatikabteilung sei in jedem Falle für seine Fachapplikation verantwortlich. Ihm gefällt zwar der Begriff "Owner" - wer will schon nicht etwas besitzen? - aber er will trotzdem möglichst wenig damit zu tun haben. Falls aber etwas entschieden werden muss, was Geld kostet, kommt man nicht an ihm vorbei, schliesslich ist ja er der "Owner" der Schatulle(n) :-) .....unendliche Weiten, wo noch nie zuvor.....

SVEN OSSENBERG · 2020-09-24

..ein Arbeitnehmer gewesen ist...

Was ist eigentlich DevSecOps?

2020-08-13T00:00:00Z

Was ist DevSecOps?

Ich bin von Ralfs Business Agilität Reihe hier auf devops.ch so begeistert, dass ich mich wieder meiner Spielwiese rund um DevOps widmen möchte.

Ich sehe nämlich gerade in Frameworks wie SAFe oder LeSS immer noch die Herausforderung, wie die Agilität mit der Stabilität konkurriert.

Wenn jetzt noch der CISO seine 5 Cent zu jedem Release einwirft, dann wird es knifflig.

Auf die Gefahr hin, dass es einigen ein wenig zu technisch wird, ist es jedoch nicht von der Hand zu weisen, dass der Grad und die Möglichkeiten der Automatisierung uns bei den lieb gewonnen kulturellen Aspekten massiv unterstützen. Wie brechen Silos auf und kommunizieren auf eine uns fast schon unbekannte Weise 😊

Wie wir jetzt vermuten können, geht es bei DevOps eben nicht nur um „Entwickler“ und „Betriebler“ und Betriebsteams. Wenn du die Agilität und Reaktionsschnelligkeit eines DevOps-Ansatzes voll ausnutzen möchtest, muss auch die IT-Sicherheit eine integrierte Rolle im gesamten Lebenszyklus deiner Apps spielen.

Warum?

In der Vergangenheit war die Rolle der IT-Security in der Endphase der Entwicklung auf ein bestimmtes Team beschränkt. Das war nicht so problematisch, wenn Entwicklungszyklen Monate oder sogar Jahre dauerten, aber diese Zeiten sind vorbei. Effektives DevOps sorgt für schnelle und häufige Entwicklungszyklen (manchmal Wochen oder Tage), aber veraltete Sicherheitspraktiken können selbst die effizientesten DevOps-Initiativen zunichte machen.

Jetzt, im gemeinschaftlichen Rahmen von DevOps, ist Security eine geteilte Verantwortung, die von Anfang bis Ende integriert ist. Es ist eine Denkweise, die so wichtig ist, dass einige den Begriff "DevSecOps" geprägt haben, um die Notwendigkeit zu betonen, ein Sicherheits-Fundament in die DevOps Initiativen einzubauen.

DevSecOps bedeutet, von Anfang an über die Sicherheit von Anwendungen und Infrastruktur nachzudenken. Es bedeutet auch, einige „Security-Gates“ zu automatisieren, um den DevOps-Workflow nicht zu verlangsamen. Die Auswahl der richtigen Tools zur kontinuierlichen Integration der Sicherheit, wie z.B. die Vereinbarung einer integrierten Entwicklungsumgebung (IDE) mit Sicherheitsfunktionen, kann helfen, diese Ziele zu erreichen. Effektive DevOps Security erfordert jedoch mehr als nur neue Tools - sie baut auf den kulturellen Veränderungen der DevOps Bewegung auf, um die Arbeit der Security Teams eher früher als später zu integrieren.

DevOps Security ist bereits integriert.

Egal ob du es "DevOps" oder "DevSecOps" nennst, es war immer ideal, Security als einen integralen Bestandteil des gesamten App-Lebenszyklus mit einzubeziehen. Bei DevSecOps geht es um bereits integrierte Sicherheit, nicht um Sicherheit, die als Perimeter um Apps und Daten funktioniert. Wenn die Sicherheit am Ende der Entwicklungspipeline bleibt, können Organisationen, die DevOps einsetzen, wieder zu den langen Entwicklungszyklen zurückkehren, die sie von vornherein vermeiden wollten.

Teilweise hebt DevSecOps die Notwendigkeit hervor, Sicherheitsteams zu Beginn von DevOps Initiativen einzuladen, um Informationssicherheit einzubauen und einen Plan für die Sicherheitsautomatisierung aufzustellen. Sie unterstreicht auch die Notwendigkeit, den Entwicklern bei der Entwicklung von sicherheitsrelevantem Code zu helfen, ein Prozess, bei dem die Security-Teams Sichtbarkeit, Feedback und Erkenntnisse über bekannte Bedrohungen austauschen. Es ist möglich, dass dies auch neue Sicherheitstrainings für Entwickler beinhalten kann, da dies nicht immer ein Schwerpunkt in der traditionelleren Anwendungsentwicklung war.

Wie sieht die bereits integrierte Sicherheit denn nun aus?

Für den Anfang ist es eine gute DevSecOps Strategie, die Risikotoleranz zu bestimmen und eine Risiko-/Nutzenanalyse durchzuführen. Wie viele Sicherheitskontrollen sind innerhalb einer bestimmten Anwendung notwendig? Wie wichtig ist die Markteinführungsgeschwindigkeit für verschiedene Apps? Die Automatisierung von sich wiederholenden Aufgaben ist der Schlüssel zu DevSecOps, da die Durchführung von manuellen Sicherheitskontrollen in der Pipeline zeitintensiv sein kann.

DevOps Security ist automatisiert

Zu tun: Kurze und häufige Entwicklungszyklen aufrechtzuerhalten, Sicherheitsmaßnahmen mit minimaler Betriebsunterbrechung zu integrieren, mit innovativen Technologien wie Containern und Microservices Schritt zu halten und gleichzeitig eine engere Zusammenarbeit zwischen häufig isolierten Teams zu fördern - das ist eine große Aufgabe für jede Organisation. All diese Initiativen beginnen auf der menschlichen Ebene - mit dem Ins und Outs der Zusammenarbeit in eurer Organisation - aber der Vermittler dieser menschlichen Veränderungen in einem DevSecOps Rahmen ist die Automatisierung.

Aber was soll man automatisieren, und wie? Es gibt eine schriftliche Anleitung, um diese Frage zu beantworten. Organisationen sollten einen Schritt zurücktreten und die gesamte Entwicklungs- und Betriebsumgebung in Betracht ziehen. Dies beinhaltet Source Control Repositories, Container Registries, die kontinuierliche Integration und Continuous Deployment (CI/CD) Pipeline, Application Programming Interface (API) Management, Orchestrierung und Releaseautomatisierung, sowie Betriebsmanagement und Überwachung.

Die neuen Automatisierungstechnologien haben den Organisationen geholfen, agilere Entwicklungspraktiken einzuführen, und sie haben auch eine Rolle bei der Förderung neuer Sicherheitsmaßnahmen gespielt. Aber die Automatisierung ist nicht das Einzige, was sich in den letzten Jahren in der IT-Landschaft verändert hat - Cloud-Native Technologien wie Container und Microservices sind heute ein wichtiger Teil der meisten DevOps-Initiativen, und DevOps Security muss sich anpassen, um ihnen gerecht zu werden.

DevOps Security ist in Container und Microservices bereits integriert

Der größere Umfang und die dynamischere Infrastruktur, die durch Container ermöglicht wird, haben die Art und Weise, wie viele Organisationen Geschäfte machen, verändert. Aus diesem Grund müssen sich die Sicherheitspraktiken von DevOps Security an die neue Landschaft anpassen und sich an die containerspezifischen Sicherheitsrichtlinien anpassen.

Cloud-Native Technologien eignen sich nicht für statische Sicherheitsrichtlinien und Checklisten. Vielmehr muss die Sicherheit kontinuierlich und in jeder Phase des Lebenszyklus von Anwendungen und Infrastruktur integriert sein.

DevSecOps bedeutet, Sicherheit von Anfang bis Ende in die Entwicklung von Anwendungen zu integrieren. Diese Integration in die Pipeline erfordert eine neue organisatorische Denkweise ebenso wie neue Tools. In diesem Sinne sollten die DevOps-Teams die Sicherheit automatisieren, um die gesamte Umgebung und die Daten zu schützen, sowie den kontinuierlichen Integrations- und Auslieferungsprozess - ein Ziel, das wahrscheinlich auch die Sicherheit von Microservices in Containern einschließen wird.

Spannend, auch wenn ich für mich bei meinen Beratungsmandaten die kulturellen Aspekte einer Agilen Transformation stets am Anfang sehe, so gebe ich zu, dass die Automatisierung eine grosse Stütze in dieser Bewegung darstellt.

In diesem Sinne, bleibt sicher :)

-Euer Sven

Service Management – ein Grundpfeiler von DevOps und Agile

2020-08-06T00:00:00Z

Service Management – ein Grundpfeiler von DevOps und Agile – aber wie geht das denn nun?

Wie in meinen letzten Beitrag angekündigt, möchte ich heute kritisch hinterfragen, inwieweit bewährte Standards und Methoden zur gewünschten Zusammenarbeit zwischen Entwicklung und Betrieb (DevOps) geführt haben. Konnten die Silos aufgebrochen werden und arbeiten die Teams an gemeinsamen Zielen? Falls noch Handlungsbedarf besteht, was wären mögliche Lösungsansätze?

Bevor wir die Frage beantworten, ob und wie unterschiedliche Frameworks eingesetzt werden können und sollen, müssen wir uns noch einmal die ursprüngliche Zielsetzung von DevOps vor Augen führen.

«Stellen Sie sich eine Welt vor, in der Product Owner, Entwicklung, Qualitätssicherung, IT-Betrieb und InfoSec zusammenarbeiten, nicht nur, um sich gegenseitig zu helfen, sondern auch, um sicherzustellen, dass die gesamte Organisation erfolgreich ist. Indem man auf ein gemeinsames Ziel hinarbeiten, ermöglicht das den schnellen Fluss der geplanten Arbeit in die Produktion und erreicht gleichzeitig Stabilität, Zuverlässigkeit, Verfügbarkeit und Sicherheit von Weltklasse.» - Das DevOps Handbuch

Nach wie vor stellt diese Vision viele IT-Organisationen vor Herausforderungen. Der Abbau der über Jahre aufgebauten Silos und hierarchisch gewachsenen Funktionseinheiten gestaltet sich trotz allgemeinem Verständnis und Überzeugung, als schwierig.

Und Hand aufs Herz, hat sich die Zusammenarbeit zwischen IT-Betrieb und Entwicklung so weit verbessert, dass die im Phoenix Projekt beschriebene Abwärtsspirale bei Ihnen kein Thema mehr ist?

DevOps ist bekanntlich die Kombination aus den zwei Wörtern, Development (Entwicklung) und Operations (Betrieb). Ohne den DevOps-Ansatz erleben wir Spannungen zwischen denen, die neue Funktionen entwickeln, und denen, die die Stabilität der Lösung in der Produktion aufrechterhalten (siehe Wall of Confusion).

Die Entwicklungsteams werden an dem Business Value gemessen, den sie den Endbenutzern liefern, während das IT-Servicemanagement an der Qualität und Stabilität der Produktionsumgebung gemessen wird. Weil jede Gruppe scheinbar gegensätzliche Geschäftsziele hat, können Ineffizienz bei der Bereitstellung und organisatorische Reibungsverluste die Regel sein.

Zwischenzeitlich ist die Notwendigkeit zur Veränderung in der Zusammenarbeit in allen Organisationseinheiten (Silos) angekommen. Um im digitalen Zeitalter wettbewerbsfähig zu sein und wachsen zu können, müssen Unternehmen schnell auf Marktveränderungen und Chancen reagieren können. Dies erfordert, dass alle, die an der Bereitstellung von Lösungen beteiligt sind schlanke und agile Praktiken nutzen, um kontinuierlich innovative, qualitativ hochwertige Produkte und Dienstleistungen schneller als die Konkurrenz zu liefern.

Das haben wir ja zwischenzeitlich Alle begriffen, aber warum hapert es dann noch mit der Umsetzung?

IT-Operation (IT OPS) ist von Natur aus Ticket gesteuerte Arbeit. Das ist etwas ganz anderes als Software-Entwicklungsprojekte, bei denen eine Initiative durch ein Portfolio getrieben wird. In der Welt der IT OPS gibt es Arbeit, die schnell erledigt werden muss, und Arbeit, die jetzt erledigt werden muss. Dies führt dazu, dass IT OPS oft noch wenig in agile Initiativen eingebunden ist.

Bei den agilen Entwicklungsteams vermittelt IT OPS oft den Eindruck sich hinter unsäglichen Prozessen und Kontrollen zu verstecken. Wohingegen bei IT OPS sich die Meinung verfestigt, dass die agilen Teams sich nicht um Vorgaben und Regulatorien zu scheren. Dabei liegt der Erfolg von DevOps gerade in der Integration unterschiedlicher Rahmenwerke und Methoden wie beispielsweise IT-Service Management (ITSM). ITSM-Prozesse sind für Unternehmen, die diesen Erfolg erreichen wollen, von entscheidender Bedeutung. DevOps eliminiert nicht den Bedarf an Kontrollen und Daten. Regulatorische Kontrollen und Audits gibt es immer noch, und Risiken und Auswirkungen müssen auch zukünftig bewältigt werden.

Damit IT OPS den erforderlichen Beitrag in agilen Projekten leisten kann muss es die Maturität der Service Management Prozesse erhöhen und die Abläufe automatisieren.

Ein Ansatz für die Umsetzung liefert das Agile Service Management (Agile SM). Agile SM stellt sicher, dass ITSM-Prozesse die agilen Werte widerspiegeln und mit «gerade genug» Kontrolle und Struktur gestaltet werden, um effektiv und effizient Dienstleistungen zu erbringen, die den Kunden die Ergebnisse erleichtern, wann und wie sie benötigt werden. Agile SM erfindet ITSM nicht neu - es modernisiert den Ansatz indem es:

Agile Praktiken an das ITSM-Prozessdesign adaptiert
Service Management in kleinen, iterativen Schritten implementiert
Sicherstellt, dass ITSM-Prozesse Agile Werte vom ersten Entwurf bis zur CSI widerspiegeln
Zu «minimal durchführbaren» und «gerade genug» Prozessen, um Geschwindigkeit und Konformität zu erhöhen, ermuntert

Nun müssen wir aber schon noch die skalierte Agilität anschauen. In meinem letzten Blog habe ich das Thema Business Agilität und SAFe vorgestellt. Das Scaled Agile Framework ist (SAFe) ist neben LeSS eines der verbreitetsten Frameworks, um Scrum bzw. Agil zu skalieren. SAFe baut auf Lean auf und bietet ein agiles Framework für die Ebene der Teams, der Programme und der gesamten Organisation (Portfolio-Ebene).

Bedauerlicherweise gibt es nicht das eine Framework mit dem wir alle unsere Herausforderungen lösen können.

Damit die Organisationseinheiten Entwicklung (Dev) und IT-Betrieb (Ops) ohne Reibungsverluste zusammenarbeiten können müssen wir auch die unterschiedlichen und im Einsatz befindlichen Frameworks berücksichtigen.

Sind denn nun SAFe und ITIL Freunde oder Feinde?

Auch hier erleben wir oft genug wie die Organisationseinheiten, Entwicklung und Betrieb das kämpften, was man auch als "Religionskrieg" bezeichnen könnte. Entwicklung in der Welt von Scaled Agile (SAFe) und Betrieb mit ITIL. Verschiedene Planeten. Oder doch nicht? Wenn wir uns zusammensetzten und uns die Leitprinzipien sowohl von SAFe als auch von ITIL genau anschauen kommen wir zum Schluss, dass sie tatsächlich viel enger aufeinander abgestimmt sind, als man das erwartet hätte.

Gehen wir nun einmal davon aus, dass sowohl DevOps, SAFe und ITIL weiterhin sinnvoll miteinander eingesetzt und betrieben werden sollen. Um die Brücke zwischen Entwicklung und Betrieb zu schlagen fordern wir mehr Zusammenarbeit zwischen den beiden Welten.

Mit ein wenig «Good will» und Kreativität lassen sich die Frameworks gut kombinieren. Dies veranschauliche ich gerne mit einem Beispiel.

Der kontinuierliche Ausbau und die Weiterentwicklung der Service Management Kompetenz sowie der notwendigen Automatisierung muss heute in enger Zusammenarbeit durch agile (abteilungsübergreifende) Teams erfolgen.

Dabei ist auch zu beachten, dass solche, für das Unternehmen wichtige Themen, auf Führungsstufe entschieden und beauftragt werden müssen. Gemäss SAFe würden solch strategische Themen auf der Portfolio Ebene priorisiert.

Die Umsetzung, beispielsweise einzelner ITIL Praktiken, würden auf der Programmebene anschliessend priorisiert und dann in Form von User Stories in den Programm Inkrementen, auf der Teamebene umgesetzt.

Tatsächlich erleben wir, dass durch den konsequenten Ausbau und die Automatisierung von Service Management die Silos Entwicklung (Dev) und Betrieb (OPS) aufgebrochen werden können

Liegt es nun an den fehlenden oder unzulänglichen Standards und Methoden, warum einige Organisationen noch nicht wie gewünscht harmonieren? Ganz ehrlich, gute und bewährte Methoden wie man etwas macht gibt es mehr als genug. Ich bin der Meinung, dass jede Organisation aus der Vielfalt von Frameworks die für sie richtigen Werkzeuge herausnehmen, sich zu Nutze machen und anschliessend konsequent anwenden sollte.

Google hat sich dem Thema vor Jahren bereits angenommen und betrachtet auch den Betrieb als Software Engineering Herausforderung.

Auf der Basis-Ebene bringen SREs Software-Engineering-Prinzipien in Infrastruktur- und Betriebsstörungen ein, mit dem ehrgeizigen Ziel, hochskalierbare und zuverlässige Systeme zu schaffen.

Doch das ist auch nur ein Teilaspekt des komplexen Konstrukts und ist auch kein Allheilmittel, das für alle «Horses» und «Unicorns» passt.

Es bleibt spannend, doch von einer Sache bin ich absolut überzeugt:

Agilität ist die dabei richtige Vorgehensweise!

Euer Ralf Winter

Kommentare (archiviert, 2017–2023)

Roland Brechbühl · 2020-08-12

Danke Ralf für den spannenden Input. Am Ende müssen wir noch die Psychologie um Antwort bemühen, wieso Menschen eigentlich so viele Mauern und Barrieren schaffen zwischen den Vertretern der einen und der anderen "Ecke". Wie Du es ansprichst, gibt es da zuweilen schon fast "religiöse" Ansichten. Hatten wir nicht auch im Geschichtsunterricht gelernt, dass sich z.B. in der Reformation vermeintlich die Unterschiede nur bei Kleinigkeiten zeigten (ist es nun das Blut Christi oder nicht?), aber bei näherer Betrachtung es um Geld und Macht ging? Bin weiterhin interessierter Leser dieses ausführlichen Blogs. Grüsse. Roland

Hans Fabian · 2022-08-23

wenn die ops fraktion nicht frühzeitig einbezogen wird geht aus den agilen teams nichts, aber auch mal gar nichts live... deshalb frühzeitig einbeziehen, auch wenn sich der Leiter Betrieb bockig zeigt und seine Leute nur widerwillig zu den jungen Wilden wechseln...

Business Agilität – das agile Unternehmen

2020-07-30T00:00:00Z

Business Agilität – das agile Unternehmen – aber wie geht das denn nun?

Funktionsübergreifende Teams sind in aller Munde, neue «siloübergreifende» und kollaborative Zusammenarbeitsformen werden allerorts etabliert. Warum sollen denn nun die seit vielen Jahren etablierten und funktionierenden Organisationsformen nicht mehr sinnvoll sein und warum müssen wir uns verändern? Diese Frage wurde bereits in anderen – auch DevOps.ch –Blogs ausreichend erörtert. Der allgemeine Konsens dazu lautet, weil die Unternehmen agiler werden müssen. Wir wollen uns deshalb heute damit auseinandersetzen, warum Business Agilität so notwendig ist, was eigentlich mit Business Agilität gemeint ist, und wie ein Unternehmen agil wird.

Warum ist Business Agilität notwendig?

Die Unternehmen, die langfristig überleben und gedeihen, haben eines gemeinsam: die Fähigkeit, wendig zu sein. Wie das weise Sprichwort über den Grashalm, der sich im Wind biegt, weiss ein erfolgreiches Unternehmen, wann es sich biegen, drehen und verändern muss, um Kräfte aufzunehmen, die stärker sind als es selbst. Um dies zu tun, muss das Unternehmen beweglich sprich agil sein. Die konsequente Ausrichtung auf den Kunden und den Kundennutzen sind in den Genen der Startups (Unicorns) verankert, aber Hand aufs Herz, wie sieht das denn bei den börsenkotierten Konzernen (Horses) aus? Sobald eine Unternehmung wächst baut es seine Organisation nach bewährten Modellen aus und läuft dabei Gefahr seine Kundenorientierung und Agilität zu verlieren. Gemäss dem Business Agility Institute (https://businessagility.institute/) können traditionelle Modelle des Managements und der Unternehmensführung nicht mehr mit den Bedürfnissen der modernen und sehr dynamischen Wirtschaft Schritt halten.

Was verstehen wir unter Business Agilität?

Die Agile Alliance bezeichnet Business Agilität als die Fähigkeit einer Organisation, Veränderungen intern oder extern zu spüren und entsprechend zu reagieren, um ihren Kunden einen Mehrwert zu bieten.

Business Agilität ist demzufolge eine Organisationsmethode, die Unternehmen dabei hilft, sich schnell an Marktveränderungen anzupassen. Das bedeutet externe Veränderungen, aber auch interne Veränderungen.

Business Agilität ist keine spezifische Methodik oder gar ein allgemeines Framework. Es ist eine Beschreibung dessen, wie eine Organisation arbeitet, indem sie eine bestimmte Art von Wachstumsmentalität verkörpert, die der agilen Denkweise (agile Mindset) sehr ähnlich ist, welche von Mitgliedern der agilen Software-Entwicklungs-gemeinschaft beschrieben wird.

Das Scaled Agile Framework (SAFe) (https://www.scaledagileframework.com/business-agility/) definiert Business Agilität schlicht als die Fähigkeit, im digitalen Zeitalter wettbewerbsfähig zu sein und zu gedeihen, indem man schnell auf Marktveränderungen und neue Chancen mit innovativen Geschäftslösungen reagiert. Business Agilität erfordert, dass alle, die an der Bereitstellung von Lösungen beteiligt sind - Unternehmensleitung, Entwicklung, IT-Betrieb, Recht, Marketing, Finanzen, Support, Compliance, Sicherheit und andere - schlanke und agile Praktiken einsetzen, um kontinuierlich innovative, qualitativ hochwertige Produkte und Dienstleistungen schneller als die Konkurrenz zu liefern.

Wie machen wir denn nun das Unternehmen agil?

Wichtig scheint dabei die Erkenntnis, dass die Prinzipien der Agilität auf die gesamte Organisation angewendet werden müssen, nicht nur auf die IT-Abteilung. Bei einer agilen Transformation wird das gesamte Unternehmen nach spezifischen Bereichen durchsucht, in denen ein agiles Betriebsmodell Werte freisetzen kann.

In diesem Zusammenhang müssen wir nun kurz auf das Scaled Agile Framework (SAFe) mit den darin beschriebenen Kernkompetenzen zu sprechen kommen. Es sei mir verziehen, wenn ich, um den Blog kurz zu halten; nicht auf alle anderen, ebenfalls bewährten und funktionierenden Frameworks eingehe. SAFe liefert den umfassenden Methodenkoffer, um die gesamte Organisation schrittweise in die gewünschte Business Agilität zu überführen. Die sieben Kernkompetenzen von Business Agilität beschreiben die Praktiken zur Unterstützung dieses Ziels, wobei ein Business Agilitäts-Assessment ein idealer Startpunkt für die Reise darstellt, weil damit die Identifizierung von Massnahmen auf der Grundlage der Bewertungsergebnisse möglich wird.

SAFe entwickelt sich Zusehens zum Standard, um Agilität in einem Unternehmen aufzubauen und zu skalieren. Dabei ist SAFe auch in der DevOps Bewegung und den DevOps Ausbildungen angekommen.

Ich könnte mir vorstellen in einem weiteren Beitrag das SAFe Framework etwas tiefer zu beleuchten.

Allerdings wäre auch eine kritische Betrachtung sinnvoll, inwieweit all die bewährten Standards und Methoden denn nun zur gewünschten Zusammenarbeit zwischen Entwicklung und Betrieb (DevOps) geführt haben. Konnten die Silos aufgebrochen werden und arbeiten die Teams an gemeinsamen Zielen? Falls bei einigen IT-Organisationen noch Handlungsbedarf besteht, wäre das Thema wie man IT-Operations, als Schlüsselkompetenz der Business (oder Unternehmens-) Agilität besser integriert noch spannend.

Euer Ralf Winter

_____________________________

Kommentare (archiviert, 2017–2023)

Sven Ossenberg · 2020-08-03

Vielen lieben Dank Ralf, in diesem Sinne freuen wir uns über weitere Gedanken und Fragen zu dem Thema. :)

Service Management – ein Grundpfeiler von DevOps und Agile - Devops · 2020-08-06

[…] in meinen letzten Beitrag angekündigt, möchte ich heute kritisch hinterfragen, inwieweit bewährte Standards und Methoden […]

Was ist eigentlich DevSecOps? - Devops · 2020-08-13

[…] bin von Ralfs Business Agilität Reihe hier auf devops.ch so begeistert, dass ich mich wieder meiner Spielwiese rund um DevOps widmen […]

class SRE implements DevOps

2020-07-23T00:00:00Z

Heute möchte ich Euch von meinen neusten Erfahrungen aus dem Umfeld der agilen Transformation berichten, auch ich habe mich erfolgreich an das Wagnis einer neuen Zertifizierung gewagt....

Aus dem Baukasten des SRE.

Was oder wer ist ein SRE?

Wir beleuchten heute die Rolle des Site Reliability Engineer.

Die zuerst von Google aufgestellten Prinzipien des Site Reliability Engineering haben zu einer neuen, technischen Rolle im Herzen von DevOps geführt.

Haben wir jetzt 2 konkurrierende Bewegungen oder gar neue Frameworks? Und warum kommt Google auf einmal damit um die «Ecke»?

Da sich die Welt online verändert hat, ist die Zuverlässigkeit von Websites, Cloud-Anwendungen und Cloud-Infrastrukturen zu einer entscheidenden Geschäftsvoraussetzung geworden - vom E-Commerce-Betrieb über globale Banken bis hin zu Suchmaschinen. (ein erster Hinweis auf Google😊

Die Art und Weise, wie wir Systeme und ihre Arbeitsabläufe verwalten, hat sich geändert. Heute denken wir selten in Form von wertvollen, hochleistungsfähigen Servern mit hohem Bedienkomfort, sondern stattdessen denken wir in Racks von Commodity-Servern, die durch Virtualisierung zusammengelegt werden, wobei eine verteilte Software-Architektur verhindert, dass Serverausfälle zu Ausfallzeiten führen. Der Schwerpunkt hat sich von der Hardware auf eine softwaredefinierte Infrastruktur verlagert und von inkonsistenten und fehleranfälligen manuellen Prozessen auf konsistente, zuverlässige und wiederholbare automatisierte Aufgaben.

Site Reliability Engineering ist die Praxis, diese programmierbare Infrastruktur aufrechtzuerhalten und die Verfügbarkeit der darauf laufenden Arbeitslasten zu maximieren. Die Berufsbezeichnung Site Reliability Engineer (SRE) stammt ursprünglich aus den Hallen von Google, das zur Jahrtausendwende die Beziehung zwischen Software-Entwicklern und Operations neu definieren wollte - und ihnen dabei helfen wollte, gemeinsam robuste, flexible Systeme mit ständiger Verbesserung und Automatisierung als Kernprinzipien aufzubauen.

Auf der Basis-Ebene bringen SREs Software-Engineering-Prinzipien in Infrastruktur- und Betriebsstörungen ein, mit dem ehrgeizigen Ziel, hochskalierbare und zuverlässige Systeme zu schaffen.

"Im Grunde ist es das Ergebnis, was passiert, wenn man einen Software-Engineer bittet, eine Operations-Funktionalität zu entwerfen", Ben Treynor, VP of Engineering bei Google und der Pate von SRE.

Das klingt jetzt alles nach Tool-Chain-Analyse und technischem Kling-Klang. Schauen wir mal, wo die Kultur sich versteckt hält.

Doch erstmal zu den Aufgaben eines SRE.

Zu den Hauptaufgaben von SRE gehört die Festlegung von Service-Level-Schwellenwerten, die sich oft als Service-Level Objectives (SLOs) manifestieren und darüber informieren, ob ein Release grünes Licht erhält. Der heilige Gral sind immer die geheiligten "fünf Neunen" oder 99,999% Betriebszeit. Je besser die Betriebszeit, desto mehr Entwickler können coole neue Software auf den Markt bringen und desto mehr schlafen die SREs 😊

Das wiederum führt unweigerlich für beide Seiten zu einer vorteilhaften Beziehung, weit entfernt von den alten Zeiten des Antagonismus, in denen sich Dev und Ops feindlich gegenüberstanden.

Eine SRE-Aufgabe wird in der Regel anhand einer Reihe wichtiger Zuverlässigkeitskennzahlen gemessen, nämlich:

Systemleistung, Verfügbarkeit, Latenz, Effizienz, Überwachung, Kapazitätsplanung und Notfallreaktion.

Jeder gute SRE wird vor allem von einer Sache besessen sein: der Automatisierung..

Wie Jason Qualman, ein SRE bei dem Monitoring Entwickler New Relic, in einem Blogbeitrag feststellt: "Ein großer Teil dieser Rolle besteht darin, über ineffiziente und zeitraubende Dinge nachzudenken, die die Menschen tun, und diesen Dingen so schnell wie möglich ein Ende zu setzen. Anstatt eine Dose mit seinem Fuss den Weg hinunter zu treten, sagen sie sich: "Ich werde mir die Zeit nehmen, dies jetzt zu automatisieren und verhindern, dass jemand anderes diesen schmerzhaften Kick ausführen muss.»

Ein weiteres Schlüsselelement der SRE-Rolle ist etwas, das als "Release Engineering" bezeichnet wird und die Definition von Best Practices beinhaltet, um sicherzustellen, dass Software-Releases konsistent und wiederholbar sind.

" Release-Engineers haben ein solides (wenn nicht sogar Experten-) Verständnis von Quellcodeverwaltung, Compilern, Build-Konfigurationssprachen, automatisierten Build-Tools, Paketmanagern und Installationsprogrammen. Zu ihren Fähigkeiten gehört ein tiefgreifendes Wissen in mehreren Bereichen: Entwicklung, Konfigurationsmanagement, Testintegration, Systemadministration und Kundensupport", schreibt Dinah McNutt, technische Programm-Managerin bei Google, für das Buch Site Reliability Engineering (veröffentlicht von O'Reilly im Jahr 2016 und verfasst von Googlers Jennifer Petoff, Niall Richard Murphy, Chris Jones und Betsy Beyer).

Dann gibt es jedoch noch den reaktiven Part der Rolle, der die Alarmierung, den Bereitschaftsdienst und die Fehlerbehebung sowie die Reaktion auf Notfälle und Zwischenfälle und die Post-Mortem Analyse umfasst.

Im Wesentlichen ist es wichtig, dass SREs wissen, wie sie Systeme am besten überwachen und reagieren können, wenn etwas schief läuft, indem sie ständig sogenannte "Response Playbooks" schreiben und neu schreiben, um die Zeit zu verkürzen, die für die Behebung einer eventuell auftretenden Störung benötigt wird. Bei Google bedeutet dies, einen Vorfall zu dokumentieren, alle beitragenden Ursachen zu verstehen und zukünftige Präventivmaßnahmen zu implementieren.

"Einen Post-Mor

tem Report zu schreiben ist keine Strafe - es ist eine Chance zum Lernen für das gesamte Unternehmen", schreiben die Googlers John Lunney und Sue Lueder in einem Kapitel des Buches Site Reliability Engineering.

SREs vs. DevOps Engineers

Ich kann mir vorstellen und ahne was du denkst. Das klingt doch alles sehr nach dem uns bekannten DevOps, aber wenn es um die Terminologie geht, ist die Berufsbezeichnung SRE ungefähr fünf Jahre älter als DevOps Engineer.

Beide basieren auf ähnlichen Prinzipien, aber der Unterschied ist sowohl subtil als auch wichtig. Der Hauptunterschied besteht darin, dass sich DevOps-Engineers darauf konzentrieren, die kontinuierliche Bereitstellung und die Geschwindigkeit der Entwickler zu unterstützen, während SREs die Verantwortung für Zuverlässigkeit und Automatisierung während des gesamten Software-Lebenszyklus übernehmen, wobei der Schwerpunkt auf der erfolgreichen Bereitstellung und Überwachung von Releases liegt und die softwaredefinierte Infrastruktur am Laufen gehalten werden.

Die SRE haben eine integrale Funktion innerhalb des umfassenderen Engineer Teams: Sie sorgen dafür, dass ein Spezialist am Tisch sitzt, der sich auf den Aufbau stabiler Systeme konzentriert.

Wie Jayne Groll vom DevOps-Institut es ausdrückt: "DevOps konzentriert sich auf das Engineering der kontinuierlichen Lieferung bis zum Einsatzort; SRE konzentriert sich auf das Engineering des kontinuierlichen Betriebs am Ort des Kundenverbrauchs."

Puhh, da muss ich zweimal lesen um es zu verstehen, doch darum scheint es tatsächlich zu gehen 😊 Ich bin gespannt auf Kommentare wie ihr das seht….

Die Geschichte von SRE bei Google

Die Rückverfolgung der SRE-Prinzipien bis zu ihren Ursprüngen bei Google in den frühen 2000er Jahren stellt eine zentrale Lektion in dieser Disziplin dar.

"Als ich zu Google kam, hatte ich das Glück, Teil eines Teams zu sein, das zum Teil aus Leuten bestand, die Software-Ingenieure waren und die dazu neigten, Software als Mittel zur Lösung von Problemen zu verwenden, die in der Vergangenheit von Hand gelöst wurden. Als es also an der Zeit war, ein formelles Team für diese operative Arbeit zu bilden, war es nur natürlich, den Ansatz 'alles kann als Softwareproblem behandelt werden' zu wählen und damit zu arbeiten", erklärte Ben Treynor in einem Interview im internen Blog von Google.

"SRE führt also im Grunde genommen Arbeiten aus, die in der Vergangenheit von einem Betriebsteam ausgeführt wurden, setzt jedoch Ingenieure mit Software-Know-how ein und verlässt sich auf die Tatsache, dass diese Ingenieure von Natur aus dazu prädisponiert sind und die Fähigkeit haben, menschliche Arbeit durch Automatisierung zu ersetzen", fügt Treynor hinzu.

Google denkt auch recht starr darüber nach, wie man ein SRE-Team zusammenstellt. Alle Google-SRE müssen entweder Google-Software-Ingenieure oder "Kandidaten sein, die den Qualifikationen von Google Software Engineering sehr nahe kommen". Sie müssen auch über Fähigkeiten im Bereich Infrastrukturmanagement verfügen, am häufigsten werden hier "Kompetenz im Bereich Unix-Systemengineering und Netzwerke Spezialisten (Layer 1 bis Layer 3) gewählt."

Die SRE-Qualifikationen sind nach wie vor von Unternehmen zu Unternehmen unterschiedlich, aber was die Grundprinzipien betrifft, ist der Google-Ansatz ein solider Ausgangspunkt. Die Einzelheiten hängen von den geschäftlichen Anforderungen, den etablierten Prozessen und dem Tech-Stack ab, den das Unternehmen bereits eingeführt hat.

SREs verbringen in der Regel etwa 50 Prozent ihrer Zeit mit der Ausführung traditioneller Operations Tätigkeiten, wie z.B. Bereitschaftsdienst und Einspringen bei der Lösung von Problemen. Die anderen 50 Prozent konzentrieren sich auf die Entwicklung von Software, um die zugrunde liegenden Systeme mit der Zeit widerstandsfähiger, automatisierter und "selbstheilender" zu machen. Deshalb erfordert diese Aufgabe eine solide Mischung aus Software-Engineering-Aufgaben und operativen Fähigkeiten. Ein SRE ist gut organisiert, unter Druck kühl und ein Problemlöser. SRE-Manager sind für Teamleistung, Strategie und Optimierung verantwortlich.

Netflix stellt in diesem Zusammenhang ein First Mover dar. Die von ihnen ins Leben gerufene "Simian Army" ist für mich immer noch ein Meilenstein des Chaos Engineering auf gekonnt amüsanter Weise: -->https://en.wikipedia.org/wiki/Chaos_engineering

Aber was ist mit Organisationen, in denen die SRE-Rolle nicht existiert? In dem O'Reilly-Bericht "Was ist SRE? empfehlen Kurt Andersen von LinkedIn und Craig Sebenik von Split, einen " grassroots"-Ansatz zu wählen.

Sie empfehlen, „dort ein Entwicklungsteam zu finden, das motiviert ist, ein kleines SRE-Team (oder eine Einzelperson) zu entwickeln und zu implementieren". Mit der Zeit kannst du diesen Erfolg als positives Beispiel für andere Teams nutzen".

Nun gut, klingt nach einer weiteren Spielwiese mit unklarem Ausgang…

Da war doch das Thema Kultur. Nun, ich schreibe aus dem Grund nichts dazu, da sich in diesem Punkt die Philosophien nicht wirklich unterscheiden. Bei Google arbeiten, ist vermutlich ohnehin eine „coole“ Sache, ich denke hier stellt sich die Kulturfrage eh nicht.

Andererseits werden andere Firmen die gleichen Herausforderungen haben, wenn es darum geht agile Teams einzusetzen jedoch vergessen die Welt drumherum mit einzubinden.

DevOps steht nach wie vor für mich als Bewegung klar im Vordergrund. So schliesst sich nämlich auch für mich der Kreis, wenn wir den Blog schliessen mit der Code Zeile:

<< class SRE implements DevOps >>

Mich würde spontan interessieren, wie DevOps als Bewegung mit den verschiedenen Frameworks umgeht.

Wie werden eigentlich Service Management Disziplinen in einem agilen Umfeld realisiert?

Wie entsteht z.B. ein Service Katalog samt Prozessualer Unterstützung im SAFe Umfeld…spannend und vielleicht auch bald einen Blog wert.

Solange Roboter uns nicht das Spielen abnehmen, kickt ruhig mal gegen eine Cola-Dose, das hat auch als Kinde Spass gemacht und tat nicht weh 😊

Alles Liebe, bleibt gesund,

-Euer Sven

Kommentare (archiviert, 2017–2023)

Ralf · 2020-07-23

Lieber Sven Deinen Artikel habe ich mit grosser Freude gelesen und nehme auch die Herausforderung auf etwas zum Thema Service Management zu verfassen. Danach nehmen wir unsere zwei Themen und schauen wie wir das zusammenbringen. Bis demnächst

Sven Ossenberg · 2020-07-23

Lieber Ralf

Auf die "Challenge" habe ich ich gewartet :) Ich freue mich, mit Dir diese Themen anzugehen.

LG Sven

Pascal · 2021-05-17

Hallo Leute

Mich würde brennend interessieren, wie der klassischen IT-Operation in der Praxis Rechnung getragen wird? Stichworte Betrieb und Bereitstellung physischer IT-Hardware (Erweiterung Compute, Storage und Network) als stabile Basis für die agilen Software-Welten.

LG Pascal

Sven Ossenberg · 2021-05-18

Hi Pascal

Da triffst Du natürlich einen Nerv :) Darüber könnte ich auch mal einen Blog schreiben. Grundsätzlich sehe ich die Tendenz, dass die "klassische" Operations nicht in vollem Umfang insbesondere bei der Bereitstellung der physische Komponenten vollumfänglich ins "agile Boot" mit aufgenommen wird. Wir können uns mal gerne darüber unterhalten, ich sehe bei SRE einen tollen Ansatz in diesem Bereich, der auch ganz gut durch unsere Erfahrung dokumentiert ist. Ich würde Dir nachher mal schreiben, dafür benötige ich mehr Platz als ich hier habe :) LG Sven

Pascal · 2021-05-21

Hallo Sven

Besten Dank, auf den Austausch freue ich mich. LG Pascal

Die Kulturrevolution- „So machen wir das hier.“ - Teil 5

2020-02-26T00:00:00Z

Inhalt: Teil 1 - Teil 2 - Teil 3 Teil 4 - Teil 5

Jenseits vom Silodenken

Wie versprochen geht es heute um die altbekannten Silos. Ein für mich tolles Thema von daher auch ein wenig ausführlicher...

Einer der schwierigsten Teile der Bewältigung des Wandels ist es, die Kommunikation zu verbessern und die IT so umzugestalten, dass sie besser funktioniert, um den Zielen und Bedürfnissen der Organisation gerecht zu werden.

Für angehende DevOps-Manager gibt es gute Beispiele und Prozesse, die ihnen bei der Gestaltung der Transformation helfen können. DevOps Leader sind im Stande, die Chance rechtzeitig zu erkennen, die sich bietet, um die nötigen Massnahmen, die es für die Neugestaltung braucht, einzusetzen. Eine ebenso wunderbare Chance, die DevOps Strukturen vorzustellen und den Groove ins Unternehmen zu bringen.

Silos aufbrechen ist der Anfang - nicht das Ende

Der positive Nutzen der Intensivierung der Kommunikation innerhalb von Crossfunctional Teams und des Aufbrechens traditioneller IT-Silos besteht in der Verbesserung des Ablaufs der Softwareentwicklung und in der verbesserten Deployment Fähigkeit.

Eine verstärkte Kommunikation allein reicht jedoch nicht aus, denn DevOps ist vielmehr eine Entwicklungsreise, die versucht, den Gesamtprozess und die daraus resultierenden Inkremente stetig zu verbessern.

Kurz um, das Ziel von DevOps ist es, das Business besser zu bedienen.

Das Ergebnis der Implementierung von DevOps ist ein Softwareprodukt (natürlich auch jedes andere Produkt), damit gewünschte Funktionen schneller implementiert werden können und im gleichen Masse weniger Fehler bei der Auslieferung verursacht. Hier sehen wir im Besonderen, wie Kultur und Automatisierung zusammenkommen und sich einander bedienen.

Die Hauptprofiteure dieser Veränderungen sind diejenigen, die sich bei der Führung des Unternehmens auf die IT verlassen – nämlich das Management des Unternehmens.

Wir sollten jedoch nicht unterschätzen, welch grosse Vorteile es für die IT Teams selbst hat.

Weniger Arbeit und effizientere Fehlerbehebung, weniger „waste of time“, da zu jederzeit die Ressourcen effektiv eingesetzt werden. Dies alles geschieht, um das tägliche „Doing“ innerhalb der IT zu verbessern.

Hier kommt nun endlich Mr. Conway ins Spiel. Wenn man das Conway-Gesetz betrachtet, ist es wichtig, die eigene Vision zu sehen und zu verstehen. Das Gesetz von Conway ist eine nach dem US-amerikanischen Informatiker Melvin Edward Conway benannte Beobachtung, dass die Strukturen von Systemen durch die Kommunikationsstrukturen der sie umsetzenden Organisationen vorbestimmt sind.

Es wurde von Conway 1968 folgendermaßen formuliert:

„Organisationen, die Systeme entwerfen, […] sind gezwungen, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen abbilden.“

Das Gesetz von Conway basiert auf der Überlegung, dass für die Definition der Schnittstellen zwischen getrennten Softwaremodulen zwischenmenschliche Kommunikation notwendig ist. Daher haben die Kommunikationsstrukturen der Organisationen einen großen Einfluss auf die Strukturen dieser Schnittstellen. Von daher muss die Organisation der IT dahingehend optimiert werden, um genau die Engpässe zu vermeiden, die den Wert beeinträchtigen. Wo wir wieder bei den Value Streams sind.

Schön, dass sich der Kreis wieder einmal schliesst.

Ein Vorreiter in der agilen Transformation dürfte uns als Musikliebhaber die Firma Spotify sein (wobei ich gerade meine alte Liebe zu den Drei ??? wieder entdeckt habe und diese momentan meiner elektronischen Musikleidenschaft vorziehe,….zumindest im Zug 😊)

Es geht um das Spotify Prinzip, welches sich zu meiner Freude auch viele Gaming-Design-Studios zu Eigen machen:

https://www.growly.io/spotify-engineering-model-with-squads-tribes-chapters-and-guilds/

Squads, Tribes, Chapters, and Guilds

In Anlehnung an das Conway-Gesetz sollte die Organisation der IT die Bedürfnisse der Produkt- und Anwendungsportfolios, die die IT erstellt, widerspiegeln.

Spotify verwendet ein Modell, dass die traditionelle Art und Weise der Strukturierung der IT innerhalb des Software Developments neu organisiert. Das allgemeine Prinzip von dem Modell der Squads, Tribes, Chapters, and Guilds besteht darin, dass sich ein Squad auf ein bestimmtes Arbeitsfeld oder eine Plattform konzentriert, z.B. den IPhone-Client für eine speziell zu betreuende Applikation.

Squads sind das Äquivalent von Teams im traditionellen IT-Modell. Eine Gruppe von Squads, die - wie alle UI-Teams einer Produktfamilie - den gleichen Fokus haben, bilden die Tribes. Diese tauschen Themen, Prozesse und Ideen aus.

Ein Chapter ist das, was die traditionelle IT den „Subject Matter Expert“ nennen würde:

Die Mitarbeiter, die über vertiefte Kenntnisse eines Tools verfügen oder spezialisierte Skills haben, können ihr Wissen darüber einbringen, wie man Abläufe rationalisieren oder neue Wege zum Erreichen von Zielen beschreiten kann.

Guilds können sich auf all die Themen konzentrieren, die zusätzlich mit den Zielen des Unternehmens zusammenhängen und ermöglichen somit den Austausch von Informationen über spezifische Themen, die ausserhalb der Squads, Tribes und Chpaters anfallen.

Wertschöpfung innerhalb einer vielseitigen Organisation

Der Schlüssel zu Spotifys Struktur besteht darin, dass sie die Entscheidungsfindung und Verantwortung, wo es möglich ist, auf die Squad Ebene verteilen. Die Teams erhalten allgemeine Vorgaben und müssen dann die Ziele der Organisation im Auge behalten und gleichzeitig Probleme lösen, die auf dem Weg zum Erreichen der Ziele auftauchen.

Die Flexibilität in der Organisation und die Unabhängigkeit der einzelnen Gruppen machen diese Struktur anpassungsfähig, um sich in der gleichen Weise zu verändern, wie das Unternehmen sich an die Marktfluktuation anzupassen hat.

Es erlaubt der IT-Organisation, in dieselbe Richtung wie das Business zu ziehen, anstatt das Ruder ein wenig hinter dem Boot baumeln zu lassen und es mit langsamen Reaktionszeiten und unzureichenden Bewegungen vom Kurs abzuziehen.

Wenn sich in der Zwischenphase eines Großprojekts das Geschäftsumfeld ändert und die Unternehmensführung die zu liefernde Software zu ändern hat, ist es im DevOps-Modell weitaus einfacher, die Änderung in Gang zu setzen und die Bedürfnisse des Unternehmens wirklich zu unterstützen als bei monolithischen Entwicklungs- und Einsatzmethoden.

Auch die Behebung kritischer Probleme ist einfacher. Nicht, dass das Debugging plötzlich einfacher wird, aber es gibt weniger Fehlerbehebungen, so dass ein kritisches Problem sofort Aufmerksamkeit erfährt, ohne dass andere Fehler ignoriert werden müssen.

In diesem Sinne wünsche ich Euch eine schöne Zeit beim Computer spielen, oder Hörbuch hören..

Bis nächste Woche, Euer Sven

Kommentare (archiviert, 2017–2023)

Die Kulturrevolution - „So machen wir das hier.“ - Teil 1 - Devops · 2020-02-26

[…] Inhalt: Teil 1 – Teil 2 – Teil 3 Teil 4 – Teil 5 […]

Die Kulturrevulotion– „So machen wir das hier.“ – Teil 4 - Devops · 2020-02-26

[…] Inhalt: Teil 1 – Teil 2 – Teil 3 Teil 4 – Teil 5 […]

Die Kulturrevolution - „So machen wir das hier.“ - Teil 3 - Devops · 2020-02-26

[…] Inhalt: Teil 1 – Teil 2 – Teil 3 Teil 4 – Teil 5 […]

Die Kulturrevulotion– „So machen wir das hier.“ – Teil 2 - Devops · 2020-02-26

[…] Inhalt: Teil 1 – Teil 2 – Teil 3 Teil 4 – Teil 5 […]