devops.ch

Service Automation: die nächste Generation Services – oder das nächste Etikett?

2026-09-15T00:00:00Z

«Service Automation: Die nächste Generation Services gestalten» – unter diesem Motto steht dieses Jahr das Service Management Forum Schweiz. Und weil ich mich dort seit Jahren engagiere, verbringe ich gerade viel Zeit mit genau dieser Frage. Zeit für eine Einordnung hier auf devops.ch – denn was ich in Anbieterpräsentationen sehe und was ich aus Organisationen höre, sind im Moment zwei verschiedene Filme.

Erst mal Vokabeln lernen: generativ ist nicht agentisch

2026 schreibt jeder Hersteller «Agentic AI» auf seine Folien. Schauen wir genauer hin, ist vieles davon ein Chatbot mit neuem Anzug. Die Unterscheidung ist einfach und wichtig: Generative KI schlägt vor – sie entwirft eine Antwort, fasst ein Ticket zusammen, verlinkt einen Knowledge-Artikel. Ausführen tut immer noch ein Mensch. Agentische KI führt aus – sie versteht die Anfrage, wählt selbständig Werkzeuge über mehrere Systeme hinweg, erledigt die Arbeit und prüft das Ergebnis.

Die Kollegen von itsm.tools haben dafür einen herrlich einfachen Test: Lass dir den Anwendungsfall über mehrere Systeme hinweg vorführen – ohne einen einzigen menschlichen Klick. Braucht es zwischen den Schritten Freigaben, ist es kein Agent. Merken wir uns für die nächste Produktdemo. 😊

Die Zahlen: Versprechen trifft Vertrauen

Das Potenzial ist real: Rund 59 Prozent aller Support-Anfragen sind Routine – repetitiv, regelbasiert, in hoher Stückzahl. Genau dafür sind Agenten gebaut, und Pilotprojekte melden 60 bis 80 Prozent weniger L1/L2-Tickets. Gleichzeitig sagen in Umfragen nur 6 Prozent der Unternehmen, dass sie KI-Agenten für Kernprozesse voll vertrauen, und Gartner rechnet damit, dass über 40 Prozent der agentischen KI-Projekte bis Ende 2027 wieder abgebrochen werden.

Diese Lücke zwischen Versprechen und Vertrauen ist keine Technologie-Lücke. Sie ist eine Service-Management-Lücke.

Automatisierung ohne Service-Design automatisiert das Chaos

Hand aufs Herz: Wie sehen deine Ticketkategorien aus? Wie aktuell ist deine CMDB? Wer kann heute – ohne KI – sagen, welche Services von einem Change betroffen sind? Ein Agent, der auf einem ungepflegten Servicekatalog und einer CMDB im Dornröschenschlaf arbeitet, löst Tickets nicht – er halluziniert schneller, als der Service Desk tippen kann.

Die spannendste Entwicklung dahinter heisst ServiceOps: Monitoring und Service Desk wachsen zu einer Schicht zusammen. Statt tausend Einzel-Events und einem Ticketberg korreliert die KI die Ereignisse zu einem validierten Incident mit Business-Bezug – im Idealfall bevor jemand ein Ticket schreibt. Das ist die «ticketlose» Vision, und sie ist erreichbar. Aber nur auf einem Fundament, das wir im Service Management seit zwanzig Jahren predigen: Services end-to-end verstehen, Verantwortung klären, Datenqualität ernst nehmen. Neu ist nicht die Hausaufgabe. Neu ist, dass ihre Vernachlässigung jetzt automatisiert bestraft wird.

Die Governance-Frage, die keiner auf der Folie hat

Wenn ein Agent handelt statt vorschlägt, verschiebt sich die entscheidende Frage: Wer verantwortet die Entscheidung eines Agenten? In produktiven Umgebungen tauchen drei Risiken verlässlich auf: Datenabfluss (der Agent verrät auf geschickte Fragen mehr, als er dürfte), Prompt Injection (manipulierte Eingaben hebeln die Leitplanken aus) und – am unangenehmsten – irreversible autonome Aktionen: ein probabilistisches Modell, das deterministische Änderungen ausführt, ohne dass jemand draufgeschaut hat.

Die Antwort darauf ist kein Bauchgefühl, sondern Handwerk: Routineaufgaben laufen autonom, Rechtevergaben und Admin-Rollen brauchen den Menschen, Konfidenzschwellen eskalieren im Zweifel, jede Aktion hat einen getesteten Rollback und einen lückenlosen Audit-Trail. Wer jetzt denkt «das klingt wie Change Enablement mit neuen Begriffen» – willkommen im Club. Genau das ist es. Und mit dem EU AI Act bekommt diese Hausordnung auch noch einen regulatorischen Rahmen.

Realistisch bleiben: 18 bis 24 Monate, nicht 18 Tage

Reife Agentic-Deployments brauchen nach heutiger Erfahrung anderthalb bis zwei Jahre – nicht, weil die Modelle langsam wären, sondern weil die Organisation Schritt halten muss. Der Weg dahin ist unspektakulär: Erst die Datenhygiene für zwei, drei Anwendungsfälle (Kategorien standardisieren, CMDB entrümpeln), dann Piloten für Klassifizierung, Routing und Passwort-Resets, dann schrittweise mehr Autonomie mit dem Menschen in der Schleife. Oder kürzer: Bevor du einen Agenten einstellst, räum sein Büro auf.

Mein Fazit

Service Automation ist kein Hype-Etikett – sie ist der Moment, in dem sich gutes Service Management endlich auszahlt. Die Gewinner werden nicht die sein, die als Erste einen Agenten kaufen, sondern die, deren Services so sauber beschrieben sind, dass ein Agent sie versteht. Die nächste Generation Services entsteht dort, wo Automatisierung und Service-Design zusammen gedacht werden – von Menschen, die beide Welten kennen.

Wer das Thema vertiefen und mit Praktikern diskutieren will: Am 29. Oktober trifft sich die Schweizer Service-Management-Community am SMFS in Zürich – unter genau diesem Motto, inklusive der Verleihung des Service Management Team Awards an Teams, die zeigen, wie es wirklich geht.

Quellen und weiterführende Links

Service Management Forum Schweiz – Motto und Programm 2026
itsm.tools: Agentic AI in ITSM – die fünf Verschiebungen am Service Desk inkl. Zahlenbasis
Gartner: Prognose zu agentischen KI-Projekten – über 40 Prozent Abbrüche bis Ende 2027
EU AI Act – regulatorischer Rahmen für autonome Systeme

class PlatformEngineering extends DevOps?

2026-09-15T00:00:00Z

Alle paar Jahre bekommt der Betrieb einen neuen Namen. 2020 habe ich Euch hier «class SRE implements DevOps» vorgestellt, ein Jahr später musste ich nachlegen und nannte SRE «die grösste Lüge seit Kanban» – nicht weil die Idee schlecht wäre, sondern weil so viele Firmen nur das Türschild ausgetauscht haben. Und jetzt, 2026, lese ich auf LinkedIn im Wochentakt: «DevOps ist tot. Lang lebe Platform Engineering.»

Zugegeben, bei so viel Beerdigungsstimmung werde ich neugierig. Wer ist da gestorben, wer erbt, und wer hat das Testament geschrieben? Schauen wir genauer hin.

Was ist da eigentlich neu?

Platform Engineering heisst: Eine Organisation baut sich eine interne Entwicklungsplattform – neudeutsch Internal Developer Platform (IDP) – und behandelt sie wie ein Produkt. Die «Kunden» dieses Produkts sind die eigenen Produktteams. Statt dass jedes Team seine Pipeline, sein Kubernetes-Setup und sein Monitoring selbst zusammenschraubt, bekommt es vom Plattform-Team vorbereitete, abgesicherte Wege: sogenannte Golden Paths. Selbstbedienung statt Ticket, Standard statt Bastelei.

Die Zahlen dazu sind eindrücklich. Gartner prognostizierte, dass bis 2026 rund 80 Prozent der grossen Software-Organisationen ein Plattform-Team haben werden – 2022 waren es erst 45 Prozent. Und die DORA-Forschung meldet für 2025: 90 Prozent der befragten Organisationen nutzen eine interne Plattform, 76 Prozent haben ein dediziertes Plattform-Team. Wer jetzt erst davon hört, ist also nicht früh dran – aber auch nicht zu spät, dazu gleich mehr.

Der eigentliche Grund: unsere Köpfe sind voll

Um zu verstehen, warum das gerade jetzt passiert, muss man ehrlich auf zehn Jahre DevOps zurückschauen. «You build it, you run it» war und ist das richtige Prinzip: Wer die Anwendung baut, verantwortet sie auch im Betrieb. Nur haben wir dabei etwas unterschätzt – die Rechnung zahlt das Hirn der Teams.

Ein Produktteam von heute soll sein Fachgebiet beherrschen, dazu Kubernetes, Infrastructure as Code, IAM-Policies, Observability, Security-Scanning und die halbe Cloud-Preisliste. Team Topologies von Matthew Skelton und Manuel Pais hat dafür den passenden Begriff geprägt: kognitive Last. Teams haben eine endliche Denkkapazität, und DevOps hat die Komplexität nicht beseitigt – es hat sie umverteilt. Auf alle.

Ich schrieb schon im SRE-Artikel von meiner Zeit als Leiter eines Betriebsteams, das für vier, fünf Entwicklungsteams den Betrieb stemmen sollte: Wir waren klug, wir waren automatisiert, und wir waren trotzdem chancenlos, weil das Modell uns verheizt hat. Platform Engineering ist die organisatorische Antwort auf genau diese Überlast – nicht auf DevOps selbst.

Das Autonomie-Paradox

Der spannendste Gedanke der aktuellen Debatte ist für mich dieser: Golden Paths schränken die Wahlfreiheit ein – und erhöhen damit die Autonomie. Klingt widersprüchlich? Ist es nicht. Ein lesenswerter Beitrag auf Java Code Geeks bringt es auf den Punkt: Es gibt zwei Sorten Freiheit – die Freiheit, die Infrastruktur beliebig zu konfigurieren, und die Freiheit, Produkt auszuliefern. Platform Engineering tauscht bewusst die erste gegen mehr von der zweiten.

Wer schon einmal in einem Unternehmen mit acht Teams und acht verschiedenen Deployment-Verfahren ein Incident-Wochenende erlebt hat, weiss, welche der beiden Freiheiten am Montag fehlt.

Bevor jetzt alle ein Plattform-Team gründen…

…kommt der Teil, den die Anbieter von Plattform-Produkten seltener zitieren. Dieselbe DORA-Forschung, die die Verbreitung misst, misst nämlich auch: Schlecht gemachte Plattformen können Durchsatz und Änderungsstabilität senken. Eine Plattform, die niemand wollte, ist kein Golden Path, sondern eine goldene Fussfessel – zentralisierte Bürokratie mit YAML-Anstrich.

Die Gegenmittel sind bekannt, und sie klingen verdächtig nach dem, was wir im Service Management seit Jahren predigen: Behandle die Plattform als Produkt mit echten Kunden. Fang mit einer minimum viable platform für den häufigsten Anwendungsfall an, nicht mit dem Fünfjahresplan. Miss Entwicklerzufriedenheit und Adoption, nicht nur Kosten. Und sorge dafür, dass die Plattform Feedback gibt – laut DORA ist «klare Rückmeldung über das Ergebnis meiner Aufgabe» die Plattform-Eigenschaft mit der stärksten Wirkung auf die Entwicklererfahrung.

An dieser Stelle schmunzle ich als ITIL-Mensch übrigens still in mich hinein: Ein Plattform-Team, das definierte Services über einen Katalog anbietet, Service Levels verspricht und seine Nutzer als Kunden begreift – das ist lupenreines Service Management. Wir nennen es nur nicht mehr so, weil es dann keiner mehr cool fände. 😊

Und wer braucht das jetzt wirklich?

Hand aufs Herz: Nicht jede Organisation. Schon beim SRE-Thema galt – wer deutlich unter hundert Engineers hat, sollte sich gut überlegen, ob er ein separates Team für irgendetwas gründet. Ein Zweierteam «Plattform» für drei Produktteams ist kein Platform Engineering, sondern ein umbenanntes Infrastruktur-Team mit neuem Backlog-Namen. Die Signale, ab wann es sich lohnt, sind ziemlich eindeutig: mehrere Teams lösen dieselben Infrastrukturprobleme unterschiedlich, das Onboarding neuer Leute dauert Wochen, und die erfahrensten Engineers verbringen ihre Zeit mit Infrastruktur-Fragen statt mit dem Produkt.

Für die Schweizer Realität mit ihren vielen mittelgrossen IT-Organisationen heisst das: Der erste Schritt ist selten ein neues Team, sondern ein ehrlicher Blick auf die kognitive Last der bestehenden Teams. Was davon ist Differenzierung, was ist Ballast? Der Ballast gehört auf einen gemeinsamen Pfad – ob den nun ein eigenes Team baut oder erstmal zwei Leute mit Produktdenken.

Mein Fazit

DevOps ist nicht tot. Platform Engineering ist DevOps, das erwachsen geworden ist: dieselben Prinzipien – Flow, Feedback, kontinuierliches Lernen – angewendet auf die eigene interne Infrastruktur, mit Produktdenken statt Projektdenken. Wer es als Ausrede benutzt, wieder ein zentrales Silo zu bauen und die Zusammenarbeit einzustellen, hat weder DevOps noch Platform Engineering verstanden – er macht das, was ich 2021 bei SRE die grosse Lüge nannte, einfach mit neuem Etikett.

Oder um im Bild meiner Artikel-Reihe zu bleiben: class PlatformEngineering extends DevOps – sie erbt alles Wesentliche und überschreibt nur, was sich in zehn Jahren als zu schwer für einzelne Teams erwiesen hat.

Quellen und weiterführende Links

Gartner: Platform Engineering – Definition und Prognosen zur Verbreitung
DORA: Platform Engineering Capability – Forschungsbefunde inkl. der Risiken
Team Topologies – Skelton/Pais zum Konzept der kognitiven Last
CNCF: What is Platform Engineering? – Begriffe IDP und Golden Path
Java Code Geeks: Platform Engineering vs. DevOps – das Autonomie-Paradox
Growin: Platform Engineering in 2026 – die fünf Verschiebungen im Überblick

Organizational Change Management: Hoffnung ist keine Methode

2026-09-15T00:00:00Z

Diesen Sommer habe ich etwas getan, das ich jedem empfehle, der seit Jahren «Transformation» sagt: Ich habe mich prüfen lassen. Drei APMG-Prüfungen im Change Management – Foundation, Practitioner, dazu das Trainer-Assessment – und dazwischen viele Abende mit dem Study Guide. Nicht weil mir langweilig war, sondern weil mir in zwanzig Jahren Beratung ein Muster keine Ruhe lässt: Wir scheitern fast nie an der Technik. Wir scheitern an den Menschen, die mit der Technik arbeiten sollen.

Und das Unangenehme daran: Für die Technik haben wir Frameworks, Pipelines und Zertifikate im Überfluss. Für die Menschen haben wir – Hoffnung. Ein Kick-off, ein Newsletter, ein Foliensatz «Warum wir uns verändern». Hoffnung ist aber keine Methode.

Warum das Thema auf devops.ch gehört

Wer meine Kulturrevolution-Serie kennt, weiss: Kultur ist der Kern jeder Transformation. Und im Readiness-Artikel habe ich beschrieben, wie man mit den drei Lücken – Wissen, Methode, Erlebnis – herausfindet, wo es klemmt. Was dann noch fehlt, ist das Handwerk, die Lücken systematisch zu schliessen. Genau das ist Organizational Change Management (OCM): kein weiches Beiwerk, sondern die Disziplin, die aus «wir führen DevOps ein» ein «wir arbeiten wirklich anders» macht.

Das APMG-Zertifizierungsschema, entwickelt mit dem Change Management Institute, bündelt dazu, was die Forschung seit Jahrzehnten weiss – von der individuellen Veränderung über Teams bis zur Organisation. Nichts davon ist Zauberei. Aber es ist eben ein Wissensgebiet, kein Bauchgefühl.

Veränderung passiert pro Kopf, nicht pro Rollout

Die erste Einsicht, die jede DevOps-Initiative ernst nehmen sollte: Organisationen ändern sich nicht – Menschen ändern sich, einer nach dem anderen, und jeder durchläuft dabei seine eigene Kurve. Zwischen «ich habe davon gehört» und «ich kann das» liegt ein Tal, das die Lernforschung präzise kennt: der Moment der bewussten Inkompetenz, in dem die neue Arbeitsweise noch holpert und die alte plötzlich sehr attraktiv aussieht. Wer in diesem Tal keine Unterstützung bekommt – Zeit, Coaching, Fehlertoleranz –, kehrt um. Und zwar völlig rational.

Deshalb ist «Widerstand» in den allermeisten Fällen auch kein Charakterfehler der Belegschaft, sondern Information: Da signalisiert jemand, dass eine der drei Lücken offen ist. Wer Widerstand wegmoderieren will statt ihn zu lesen, verschenkt die beste Diagnostik, die eine Transformation hat.

Die kritische Masse statt der grossen Ansage

Die zweite Einsicht: Veränderung skaliert nicht über Ansagen, sondern über Netzwerke. John Kotter – ja, der mit den acht Schritten – hat sein eigenes Modell weiterentwickelt: weg vom einmaligen Programm, hin zu einer «Volunteer Army», einem freiwilligen Netzwerk von Menschen, die die Veränderung tragen, quer zur Hierarchie. Das ist übrigens exakt das, was in DevOps-Transformationen funktioniert, wenn es funktioniert: nicht das Operating-Model-Poster, sondern die fünfzehn Leute aus verschiedenen Teams, die es unbedingt wollen – und denen man Raum gibt.

Dazu gehört die ehrliche Unterscheidung, wie viel Mitgestaltung wirklich drin liegt: Verkünde ich (Tell), werbe ich (Sell), beteilige ich (Include) oder gestalten wir gemeinsam (Co-Design)? Jede Stufe ist manchmal richtig. Verlogen wird es nur, wenn Co-Design draufsteht und Tell drin ist – das merken Menschen sofort, und das Vertrauen ist schwerer zurückzuholen als jede Deployment-Pipeline.

Was das für DevOps-Initiativen konkret heisst

Wenn ich heute eine DevOps- oder Plattform-Initiative begleite, gehören für mich drei Dinge von Anfang an ins Setup – gleichberechtigt neben Toolchain und Betriebsmodell: ein echtes Bild der Betroffenheit (wer verliert was, wer gewinnt was – Rollen, Status, Gewohnheiten), eine Change-Architektur, die pro Zielgruppe die passende Intervention wählt statt «ein Training für alle», und Sponsoren, die sichtbar vorangehen statt nur zu genehmigen. Nichts davon ist teuer. Alles davon ist billiger als eine Transformation, die im dritten Anlauf wieder beim Kick-off steht.

Mein Fazit

DevOps hat uns gelehrt, Deployment-Schmerz nicht als Naturgesetz zu akzeptieren, sondern als lösbares Problem zu behandeln. Es ist Zeit, den Veränderungs-Schmerz genauso zu behandeln: mit Handwerk statt Hoffnung. Organizational Change Management ist dieses Handwerk – erlernbar, prüfbar, anwendbar. Ich habe die Prüfungen hinter mir; die eigentliche Prüfung findet aber jeden Tag in den Organisationen statt. Packen wir es an.

In eigener Sache: Wer das Handwerk lernen will – bei Glenfis gibt es die APMG-zertifizierte Organizational-Change-Management-Ausbildung jetzt aus erster Hand. Und für alle anderen: Mehr zu diesem Thema bald an dieser Stelle.

Quellen und weiterführende Links

APMG International: Change Management Certification – das Zertifizierungsschema (Foundation/Practitioner)
Change Management Institute – die Fachorganisation hinter dem Body of Knowledge
Kotter: 8 Steps for Leading Change – die acht Schritte und ihre Weiterentwicklung zum Netzwerk-Modell
Die Kulturrevolution – Serie auf devops.ch und Agile Readiness – die Vorarbeiten zu diesem Artikel

Agile Readiness: Warum mich dein Reifegrad nicht interessiert

2026-09-15T00:00:00Z

Das Internet ist voll davon: «Bestimme deinen agilen Reifegrad – online, kostenlos, in drei Minuten.» Am Ende steht eine Zahl, sagen wir 3,2 von 5, ein Spinnendiagramm und ein Benchmark gegen die Branche. Und dann?

Dann passiert in den meisten Organisationen: nichts. Oder schlimmer – es startet ein Programm, um aus der 3,2 eine 3,8 zu machen. Herzlichen Glückwunsch, wir optimieren jetzt eine Kennzahl, die niemandem wehtut und niemandem hilft.

Was Reifegradmodelle wirklich messen

Versteht mich nicht falsch: Ich habe nichts gegen Diagnose. Ich lebe davon, genau hinzuschauen. Mein Problem mit den gängigen Maturity-Checks ist ein anderes: Sie messen Konformität mit einem Zielbild – wie ähnlich sieht deine Organisation dem Lehrbuch? Macht ihr Dailys? Habt ihr einen Product Owner? Gibt es OKRs? Das lädt zum Ankreuz-Schummeln ein und belohnt Cargo-Kult: Wer die Rituale kopiert, bekommt den besseren Score, ganz gleich, ob dahinter irgendetwas anders geworden ist. Wer meine Kulturrevolution-Serie gelesen hat, ahnt, was ich davon halte – Kultur lässt sich nicht ankreuzen.

Und noch etwas stört mich: «Reife» klingt nach einer Einbahnstrasse mit Level 5 als Endstation. Als gäbe es genau ein richtiges Ziel für die Bank, das Spital, das KMU und die Bundesverwaltung. Ein Framework für alle – das Dogma habe ich in zwanzig Jahren Beratung genau null Mal funktionieren sehen.

Readiness ist die bessere Frage

Deshalb frage ich in Mandaten nicht «wie reif seid ihr?», sondern «wozu seid ihr bereit?». Readiness ist keine Note, sondern eine Standortbestimmung für den nächsten Schritt: Was will diese Organisation erreichen, was steht dem im Weg, und was davon lässt sich jetzt bewegen? Das Ziel liefert der Kontext, nicht das Modell.

Damit das nicht in Beliebigkeit endet, braucht es trotzdem ein Raster. Meines ist über die Jahre in der Arbeit mit Teams und Führungsetagen entstanden, und es ist bewusst simpel: KENNEN – KÖNNEN – TUN.

Die drei Lücken

Zwischen dem, was eine Organisation erreichen will, und dem, was sie heute tut, liegt immer mindestens eine von drei Lücken:

Die Wissenslücke: Die Leute kennen es nicht. Sie haben eine vage Vorstellung von Agilität aus einem LinkedIn-Post und einem halben Buch. Hier fehlt Orientierung – was ist das, wozu dient es, was bedeutet es für uns?

Die Methodenlücke: Sie kennen es, aber sie können es nicht. Das Wissen ist da, die Anwendung am eigenen Arbeitsgegenstand scheitert. Retrospektiven finden statt und verändern nichts; das Board existiert und lügt.

Die Erlebnislücke: Sie kennen es, sie könnten es – aber sie tun es nicht, weil sie nie erlebt haben, dass es funktioniert. Kein Vertrauen ohne Erfahrung. Das ist die am meisten unterschätzte der drei Lücken, und sie ist mit Argumenten nicht zu schliessen. Man kann Vertrauen nicht herbeierklären.

Der Witz an der Sache: Die Diagnose ergibt für verschiedene Zielgruppen derselben Organisation verschiedene Befunde. Das mittlere Management hat oft eine Methodenlücke, die Teams eine Erlebnislücke, die Geschäftsleitung eine Wissenslücke – oder umgekehrt. Ein einziger Reifegrad-Score für «die Organisation» verdeckt genau diese Unterschiede. Und exakt darum bringt er dich nicht weiter.

Von der Lücke zum Handlungsfeld

Der praktische Wert des Rasters: Jede Lücke verlangt eine andere Intervention – und die falsche Paarung verbrennt Budget.

Gegen eine Wissenslücke hilft Ausbildung: Training, gemeinsame Sprache, Einordnung. Gegen eine Methodenlücke hilft kein weiteres Training – hier braucht es Übung am eigenen Objekt, also Coaching in der echten Arbeit, nicht im Schulungsraum. Und gegen eine Erlebnislücke hilft beides nicht: Hier braucht es Erfahrung – eine Simulation, ein echtes Experiment mit echtem Risiko, ein Besuch bei einem Team, das es lebt. Wer eine Erlebnislücke mit einem Foliensatz bekämpft, bekommt genau das, was in so vielen Transformationen zu besichtigen ist: informierte Skeptiker.

So werden aus einer Standortbestimmung Handlungsfelder: erkunden (mit wem reden wir worüber – und zwar getrennt nach Zielgruppen), bestimmen (welche Lücke dominiert wo) und dann die Interventionen der Lücke zuordnen statt dem Reflex «machen wir halt ein Training».

Der Selbsttest ohne Spinnendiagramm

Wenn du das für deine Organisation ausprobieren willst, brauchst du keine Software, sondern drei ehrliche Fragen pro Zielgruppe: Könnten sie in zwei Sätzen erklären, was ihr erreichen wollt und warum? (Kennen.) Haben sie es in ihrer eigenen Arbeit schon einmal angewendet – nicht im Workshop, in der Arbeit? (Können.) Und: Haben sie einmal erlebt, dass es ihnen persönlich etwas gebracht hat? (Tun.) Drei Mal ehrlich geantwortet sagt mehr als jedes Ampel-Dashboard – und dauert übrigens auch nur drei Minuten. 😊

Mein Fazit

Reifegradmodelle beantworten die Frage, wie ähnlich du einem Lehrbuch bist. Readiness beantwortet die Frage, was du als Nächstes tun solltest. Für Ersteres gibt es Benchmarks, für Letzteres gibt es Arbeit – erkunden, Lücken bestimmen, Handlungsfelder ableiten. Ich weiss, was ich einer Organisation empfehle, die vorwärtskommen will statt gut abzuschneiden.

Quellen und weiterführende Links

BankingHub (zeb): Agile Readiness Check-up – Beispiel eines Online-Quick-Checks («in 3 Minuten»)
Rewion: Reifegrad-Modelle für agile Organisationen – Überblick über gängige Maturity-Modelle
Die Kulturrevolution – Serie auf devops.ch – warum Kultur der eigentliche Kern der Transformation ist

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: 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

Online Webinar - DevOps 05.02.2021

2021-01-29T00:00:00Z

Gleich anmelden: --> DevOps Webinar

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

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.

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