Das DIKW-Modell hilft uns dazwischen zu unterscheiden, ob Daten/Information oder Wissen/Weisheit (also data/infrormation oder knowledge/wisdom) fehlt.

Entwickler, die mit Continuous Integration arbeiten, mergen ihre Änderungen so oft wie möglich zurück in den Haupt-Branch. Zur Validierung der vom Entwickler vorgenommenen Änderungen wird ein Build erstellt, der dann automatische Tests durchläuft. Auf diese Weise lassen sich die Integrationsprobleme vermeiden, die möglicherweise auftreten, wenn die Entwickler mit dem Mergen der Änderungen in den Release-Branch bis zum Release-Datum warten.

Bei der Continuous Integration wird großer Wert auf die Testautomatisierung gelegt, um die Anwendung auf Fehlerfreiheit zu überprüfen, wenn neue Commits in den Haupt-Branch integriert werden.

Continuous Delivery ist eine Erweiterung der Continuous Integration, da alle Codeänderungen nach der Build-Phase automatisch in einer Test- und/oder Produktionsumgebung implementiert werden.

Dies bedeutet, dass du zusätzlich zu automatisierten Tests über einen automatisierten Release-Prozess verfügst und deine Anwendung jederzeit mit einem Klick auf eine Schaltfläche bereitstellen kannst.

Theoretisch kannst du mit Continuous Delivery entscheiden, ob du täglich, wöchentlich, vierzehntägig oder in sonstigen deinen Geschäftsanforderungen entsprechenden Intervallen veröffentlichst. Wenn du jedoch wirklich die Vorteile der Continuous Delivery nutzen möchtest, solltest du die Anwendung so früh wie möglich für die Produktion bereitstellen, damit kleine Batches veröffentlicht werden können, an denen eventuelle Probleme leicht zu beheben sind.

Continuous Deployment geht noch einen Schritt weiter als Continuous Delivery. Bei dieser Methode wird jede Änderung, die sämtliche Stationen der Produktionspipeline durchlaufen hat, für die Kunden freigegeben. Dieser Prozess erfolgt vollautomatisch. Nur wenn ein Test fehlschlägt, wird eine neue Änderung nicht in der Produktion bereitgestellt.

Continuous Deployment ist eine hervorragende Möglichkeit, die Feedbackschleife mit deinen Kunden zu beschleunigen und den Druck auf das Team zu mildern, da es keinen Release-Tag mehr gibt. Entwickler können sich auf die Entwicklung von Software konzentrieren und sehen, wie ihr Werk Minuten nach der Fertigstellung live geht.

Einfach formuliert ist Continuous Integration ein Bestandteil von Continuous Delivery und Continuous Deployment. Continuous Deployment entspricht Continuous Delivery – abgesehen von den automatisch erfolgenden Releases.

Microservices haben nicht nur einen Einfluss auf die technologische Basis des Projektes, sondern auch auf die Organisation der Arbeit. Ein großes Projekt wird durch kleinere Projekte, d. h. Microservices, ersetzt. Die Teams können eigenverantwortlich arbeiten und haben mehr Freiheit, wenn es um die Wahl der Technologie geht. Aus der Geschäftssicht wird weniger zentrale Koordinierung benötigt. Der Microservices-Ansatz steht eng im Zusammenhang mit Scrum, bei dem selbstorganisierte Teams im Vordergrund stehen.

Software-Entwicklung läuft traditionell nach dem sogenannten Wasserfall-Modell ab. Nacheinander werden die folgenden Phasen „von oben nach unten“ bzw. auf einem Zeitstrahl von links nach rechts abgearbeitet:

1. Definition der Anforderungen
2. Entwicklung des Designs
3. Coding
4. Tests
5. Veröffentlichung

Beim Shift Left Testing wird der Wasserfall aufgelöst. Die Reihenfolge ohne Tests sieht jetzt so aus: Anforderungen - Design - Coding - Veröffentlichung. Das Testen wird auf dem Zeitstrahl möglichst weit nach links geschoben und mehrfach durchgeführt.

Definition: Das Akronym DMAIC steht für den Kernprozess des Qualitätsmanagement-Ansatzes Six Sigma und beschreibt dessen Phasen |Define (Definieren)|Measure (Messen)|Analyse (Analysieren)|Improve (Verbessern)|Control (Steuern)|

Was ist das Problem?
In dieser Phase wird der Ist-Zustand dokumentiert und definiert, wer die Kundschaft (im weitesten Sinn) des Prozesses ist und welche Kundenbedarfe er erfüllen soll. Auf dieser Basis werden dann die Leistungsmerkmale des Prozesses definiert, die kritisch für die Erfüllung der Kundenerwartungen sind. Zudem werden Projektparameter wie Umfang, Grenzen und Zeiträume festgelegt.

Wie lässt sich die Auswirkung messen?
Daten, Zahlen und Fakten liefern die Basis für ein erfolgreiches Verbesserungsprojekt. Messen bedeutet in dieser Phase, die derzeitige Ausprägung der Leistungsmerkmale festzustellen. Dazu wird der Prozess zunächst in Teilprozesse aufgegliedert und visualisiert (Process-Mapping). Auf dieser Basis können mögliche Einfluss- und Ausgangsgrößen ermittelt sowie Methoden und Instrumente zur Erhebung von Daten aus den einzelnen Prozessschritten festgelegt werden. Ziel ist, die Funktionalität des Prozesses zu erfassen. Als Werkzeuge stehen dafür unter anderem statistische und grafische Methoden sowie Prozess- und Messsystemfähigkeitsuntersuchungen zur Verfügung. Nach Abschluss diese Phase liegen beispielsweise ein Datenerfassungsplan, Datenerfassungsblätter, Häufigkeitsdiagramme (Histogramme), Messsystemanalysen, eine Prioritätsmatrix sowie eine FMEA (Failure Mode and Effects Analysis, dt.: Fehlermöglichkeits- und -einflussanalyse, kurz Auswirkungsanalyse) vor.

Welche Ursachen hat das Problem?
Ziel der Analysephase ist, die Ursache-Wirkungs-Beziehungen zwischen In- und Outputs nicht nur qualitativ, sondern möglichst auch quantitativ darzustellen, um die Ursachen der Abweichung von definierten Leistungszielen zu identifizieren. Als Werkzeuge hierzu dienen neben dem Brainstorming beispielsweise Ishikawa-Diagramme, FMEA sowie statistische Methoden. Das Ergebnis dieser Phase führt unter Umständen dazu, dass Änderungen der Problembeschreibung oder des gesamten Projektrahmens vorgenommen werden müssen.

Wie lässt sich das Problem eliminieren?
In der Verbesserungsphase sollen Lösungsmöglichkeiten für die in der Analysephase identifizierten und ausgewählten Probleme gefunden werden. Dies kann durch Kreativitätstechniken (wie Brainstorming oder Brainwriting, Mindmapping, Morphologischer Kasten) unterstützt werden. Die möglichen Lösungen werden anhand von Normen (gesetzliche Auflagen, Verordnungen, Umweltrichtlinien usw.) sowie Mach- und Wünschbarkeitskriterien überprüft und bewertet. Über die Eignung der Lösungen wird entschieden, die vorteilhafteste wird umgesetzt.

Die letzte Phase dient der Verankerung der erreichten Verbesserungen und neuen Verfahren im Alltagsbetrieb durch Standardisierung und Dokumentation. Der Prozess bzw. die Wirkung der Maßnahmen wird mit den entwickelten Messsystemen kontinuierlich überwacht, um bei Abweichungen vom definierten Ziel geeignete Korrekturmaßnahmen einleiten zu können. Die Überprüfung der Zielrerreichung erfolgt durch das Controlling.

Der Vorteil des DMAIC-Prozesses als Kern von Six Sigma liegt darin, dass er ein weites Spektrum an Möglichkeiten und Werkzeugen im Bereich der Projektmanagementtechnik eröffnet. Von großem Wert ist das Schaffen eines konzeptionellen Rahmens im Unternehmen, um Leistungen kontinuierlich messen, verbessern und kontrollieren zu können. Damit fördert DMAIC die Effektivität und die Effizienz der Unternehmensprozesse, denn

• auf Markt- und Strategieveränderungen kann schnell und konsequent reagiert werden.
• die konsequente Datenbasierung und die Prozessorientierung werden gefördert.
• Fehler werden reduziert und Doppelarbeit wird vermieden.
• die Kundenzufriedenheit wird durch Einbindung der Kundenbedürfnisse erhöht.
• die Profitabilität sowie der Umsatz eines Unternehmens werden gesteigert.
• durch Einbindung der Zulieferer wird ein verbessertes Lieferantenmanagement möglich.

CALMS ist ein konzeptioneller Rahmen für die Integration von Entwicklungs- und IT-Betriebsteams (DevOps) innerhalb eines Unternehmens. Das Akronym steht für

Culture (Kultur)	Automation (Automatisierung)	Lean (Schlank)	Measurement (Messung)	Sharing (Austausch)

Culture umfasst die unternehmensweit geltenden Werte, Überzeugungen und Haltungen, die das Handeln und Umfeld von Unternehmen charakterisieren und Entwicklung, Betrieb und QA (Qualitätssicherung) unterstützen.

Automation bezieht sich auf die Überzeugung, dass alles, was effektiv automatisiert werden kann, auch automatisiert werden sollte. Das Ziel dabei ist, Mitarbeiter von sich wiederholenden Aufgaben zu befreien, Fehler zu reduzieren und Prozesse zu verbessern.

Lean bedeutet, Überschuss zu reduzieren und trotzdem die gewünschten Ergebnisse zu erzielen. Das bedeutet beispielsweise, die Anzahl und Länge von Meetings zurückzufahren, die Größe von Teams zu verschlanken und die Anzahl verwendeter Werkzeuge auf ein Minimum zu begrenzen.

Measurement bezieht sich darauf, für alles Daten zu sammeln und für Mechanismen zu sorgen, dass alle betrieblichen Systeme und Ereignisse möglichst gut einsehbar und transparent sind. Diese sollten zudem über eine einheitliche Schnittstelle wie ein Dashboard zugänglich sein.

Sharing bezieht sich auf die Notwendigkeit einer laufenden Kommunikation und Abstimmung zwischen Entwicklung und Betrieb. Dabei sollten nicht nur Ergebnisse und Daten ausgetauscht werden, sondern auch Analysen und Ideen.

Der Erste Weg beschäftigt sich damit, auf einfachstem Niveau zu verstehen, wie Arbeit fließt, wie Arbeit von Dev zu Ops läuft und danach aus den funktionalen Bereichen des Unternehmens zu den Kunden – von links nach rechts, von einem Team zum anderen. Das heißt zu identifizieren, wie einzelne Teile zusammenpassen – zu verstehen welche Sachen von Team zu Team fließen, warum sie fließen und was mit ihnen danach passiert.
Beim Durchfluss werden vorher besprochene Beschränkungen identifiziert – d.h. zu verstehen, wo sich die Engpässe befinden und wo die Produktion am langsamsten ist, damit man danach die größte Wirkung priorisieren kann. Nur wenn man versteht, wie Arbeit fließt, kann man die Hindernisse, die die Mauer der Verwirrung verursacht, klar identifizieren und die Mauer eliminieren.

Der Zweite Weg beschreibt die Prinzipien, die gegenseitiges und ständiges Feedback von rechts nach links bei allen Phasen des Wertstroms ermöglichen. In der IT findet Arbeit in komplexen Systemen statt. Das Risiko von katastrophalen Störungen oder Folgen ist sehr hoch. Eng verknüpfte Komponenten sind häufig stark vernetzt, und diese Variabilität und Komplexität heißt, dass nicht immer die gleichen Ergebnisse entstehen, wenn eine Sache zweimal gemacht wird. Deswegen werden Sicherheit, Zuverlässigkeit und Stabilität sehr wichtig

• Systems Thinking wird ausschlaggebend.
• Feedbackschleifen helfen sicherere, resilientere Arbeitssysteme zu entwickeln, weil sie mehr Möglichkeiten bieten, um Fehler zu entdecken und zu korrigieren.

Der Dritte Weg behandelt die Erzeugung einer Kultur des kontinuierlichen Experimentierens und das Lernen, die kontinuierliche Erzeugung von Wissen für Einzelne, Teams und die Organisation, zu ermöglichen. Es umfasst das Niederreißen der Silo-Mentalität, die oft eine Kultur der Angst und des geringen Vertrauens ist. Dazu gehört auch das, der IT dabei zu helfen Fehler als Lernerfahrung zu sehen und den Wert darin zu sehen, neue Sachen zu probieren und Neuerungen einzuführen.

Die Deployment Pipeline ist ein Prozessmodell, das einen Anfangspunkt dafür bietet, Transparenz und Steuerung zu sichern, während Arbeit durch die verschiedenen Tests und Deployments Richtung Release fließt.

Die Schritte in einer CI/CD-Pipeline stellen verschiedene Untergruppen von Aufgaben dar, die in sogenannte Pipeline-Phasen eingeteilt werden. Zu diesen Phasen gehören üblicherweise:

• Build – Die Phase, in der die Anwendung kompiliert wird.
• Test – Die Phase, in der der Code getestet wird. Hier lassen sich durch Automatisierung sowohl der Zeit- als auch der Arbeitsaufwand verringern.
• Release – Die Phase, in der die Anwendung ins Repository gestellt wird.
• Bereitstellung – In dieser Phase wird der Code in der Produktionsumgebung bereitgestellt.
• Validierung und Compliance – Welche Schritte zur Validierung eines Builds notwendig sind, bestimmen die Anforderungen des jeweiligen Unternehmens. Scanning Tools für die Image-Sicherheit, wie Clair, sichern die Qualität von Images, indem diese mit bekannten Schwachstellen (CVEs) verglichen werden.