35 years ago, Eliyahu Goldratt introduced the Theory of Constraints (ToC) in his seminal book "The Goal" as a new management paradigm for manufacturing plants, struggling with excess inventory, late deliveries, poor quality. The ToC solved this through five focusing steps - a guideline to systematic improvement and continuous learning.

Today, the ToC is one of the pillars of the DevOps movement. This talk will present its principles, and how it applies to the software industry, through a mix of theory, stories and experiences, and practical advice.

Target Audience: Architects, Developers, Project Leaders, Managers, Decision Makers
Prerequisites: Some previous knowledge of software delivery is helpful, but not required
Level: Basic

This talk will provide insights for a successful integration of lean-quality management to scaled agile projects. We will show based on our project experience that by improving process quality, higher product quality is achieved, resulting in significantly increased customer satisfaction. We will share how the lean principles and an easy-to-use toolkit helped us to tackle complex problems by providing a proven and scalable approach for continuous improvement and boost business agility at the same time.

Target Audience: Quality & Test Engineers, Agile Coaches, Project Managers, Quality Managers
Prerequisites: Solid agile knowledge, basic lean understanding, basic understanding of quality assurance
Level: Advanced

In einer Live-Coding-Session werde ich demonstrieren, wie über eine Continuous Deployment Pipeline in Kombination mit Consumer-driven Contracts und einem Pact Broker sichergestellt werden kann, dass sowohl auf der Integration Stage als auch in Produktion nur Services deployt werden (können), deren Schnittstellen kompatibel sind.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen
Voraussetzungen: Java-Kenntnisse sinnvoll, Microservices-Erfahrung, Grundkenntnisse in CI/CD
Schwierigkeitsgrad: Fortgeschritten

Mit ITIL4 steht seit Februar 2019 ein Framework für agiles Service-Management bereit, das das "alte" ITIL explizit in Richtung von agilen Ansätzen öffnet und für eine neuartige Nutzung bereit macht. In der Tat kombinieren viele Organisationen verschiedene Konzepte, um ihre IT effektiver zu gestalten und agile Ansätze zu skalieren. In diesem Vortrag werden die Neuerungen durch ITIL4 kurz dargestellt, mit DevOps zusammengeführt und dann anhand ausgewählter Aspekte die Skalierungsmöglichkeiten für hoch performante IT-Organisationen dargestellt.

Zielpublikum: Führungskräfte im IT-Management, Teamleiter:innen, Service-Manager:innen, Scrum Master, Product Owner
Voraussetzungen: Allgemeine Erfahrungen in der agilen Software-Entwicklung oder im Betrieb von Applikationen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Für agile Organisationen steht ITIL als verstaubtes und stark reglementierendes Framework. Die ITIL-Prozesse und Vorgaben stehen in vielen Unternehmen als Gegensatz zu autonomen und selbstorganisierenden DevOps-Teams. Spätestens wenn mehrere Teams an einem Produkt arbeiten, agile Entwicklungsmannschaften aus vielen Menschen bestehen und die Betriebstätigkeiten wirklich in den DevOps-Teams etabliert werden müssen, stellt sich die Problematik der Skalierung. Aufgrund der jahrelangen Erfahrung des Autors in beiden Welten wird ITIL4 als idealer Ansatz für eine sofort nutzbare Skalierungsmethode erläutert. ITIL4 hat sich neu erfunden und kann bspw. sehr schön über den Value Stream-Ansatz mit DevOps kombiniert werden. In diesem halbtägigen Workshop stecken knapp 2 Jahre Erfahrung in der Konzeption und Durchführung sowie mehrere Inhouse und offene Seminare.

Im Vergleich zur klassischen Software-Entwicklung, in der DevOps-Tools und Prozesse seit vielen Jahren gang und gäbe sind, stehen wir bei Machine Learning-Projekten noch recht am Anfang.

Dennoch gibt es immer mehr Tools, wie beispielsweise Kubeflow, DevOps für Azure ML Services oder Databricks etc., die sich dieser Problematik annehmen.

In dieser Session zeigt Sascha Dittmann, wie diese Tools KI-Projekte unterstützen können und wie sich diese in die tägliche Arbeit integrieren lassen.

Zielpublikum: Architekt:innen, Entwickler:innen, Data Scientists
Voraussetzungen: Grundlagen in ML sind hilfreich, aber nicht unbedingt nötig
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Im Vergleich zur klassischen Software-Entwicklung, in der DevOps-Tools und Prozesse seit vielen Jahren gang und gäbe sind, stehen wir bei Machine Learning-Projekten noch recht am Anfang.

Dennoch gibt es immer mehr Tools, wie beispielsweise Kubeflow, DevOps für Azure ML Services oder Databricks etc., die sich dieser Problematik annehmen.

In dieser Session zeigt Sascha Dittmann, wie diese Tools KI-Projekte unterstützen können und wie sich diese in die tägliche Arbeit integrieren lassen.

Dabei werden verschiedene Themenbereiche abgedeckt, wie z.B. der Aufbau einer Pipeline für kontinuierliches Modelltraining, die Automatisierung der Validierung der Modelle, die Erstellung einer Service-Infrastruktur, die Implementierung von Monitoring und mehr.

Mittlerweile wird die Infrastruktur immer mehr mithilfe von Code beschrieben und automatisiert. Klassische Betriebler mutieren auf einen Schlag zu Entwicklenden und müssen programmieren, um an ihre Infrastruktur zu kommen.

Doch ist auch allen Beteiligten klar, dass sie zu Programmierern geworden sind? Wenn man sich Entwicklungsprozess und Code anschaut, erinnern beide stark an die Fricklermentalität der 2000er: Juhuu, es läuft irgendwie.

Dieser Vortrag zeigt, was helfen kann, den Infrastruktur-Code qualitativ hochwertiger zu machen.

Zielpublikum: Entwickler:innen, Operation
Voraussetzungen: Grundkenntnisse aus IaC
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Mittlerweile wird die Infrastruktur immer mehr mithilfe von Code (Provisionierungsskripte, Dockerfiles, (Shell-) Skripte etc.) beschrieben und automatisiert. Klassische Betriebsabteilungen mutieren auf einen Schlag zu Entwicklungsabteilungen und müssen programmieren, um an ihre Infrastruktur zu kommen.

Doch ist auch allen Beteiligten klar, dass sie zu professionellen Programmierern geworden sind? Wenn man sich Entwicklungsprozess und Code anschaut, erinnern beide stark an die Fricklermentalität der 2000er: Juhuu, es läuft irgendwie, kein VCS, keine Qualitätssicherung mit Test oder Review.

Wenn es sich stark nach “normaler” Software-Entwicklung anfühlt, warum dann auch nicht die Best Practices und Lessons Learned der letzten 30 Jahren auf Infrastructure as Code adaptieren und somit die Qualität erhöhen? Müssen die frisch gebackenen OpsDevs die alten Fehler der Devs wiederholen? Kann man Infrastruktur-Code vielleicht sogar testgetrieben entwickeln?

Dieser Vortrag lädt zu einer Zeitreise ein, welche Best Practices in der Software-Entwicklung zur einer höheren Qualität geführt haben und wie diese Erkenntnisse helfen können, die Entwicklung von Infrastruktur-Code qualitativ hochwertiger zu machen.

AI is maybe the most powerful tool our generation has available. Andrew NG called it "the new electricity". But what does it take to build AI enabled products? What are the key elements to achieve production grade AI? How does it impact your development process? How can quality be achieved? These are the questions this talk tries to answer. You will get an idea why the industry is talking about nothing less than a paradigm shift when it comes to developing AI based products.

Target Audience: Everyone interested in the shift from classical software engineering to data driven AI applications
Prerequisites: Interested in AI, how it works and its impact on engineering departments
Level: Advanced

Extended Abstract:
AI is maybe the most powerful tool our generation has available. Andrew NG called it "the new electricity". Most likely you used an AI based product within the last 3 hours, maybe without even noticing it. But what does it take to build AI enabled products? What are the key elements to achieve production grade AI? How does it impact your development process? How can quality be achieved? These are the questions this talk tries to answer. In addition we will look into the different stages of AI development and the tools which can help to make this process more efficient. You will get an idea why the industry is talking about nothing less than a paradigm shift when it comes to developing AI based products.

Whether evolution or revolution, or yet old wine in new skins, for more than 10 years, DevOps is changing how we develop and deliver software. This session looks back on the roots of DevOps, its movement until today, and current as well as possible future directions. This interactive session aims to offer a set of fruitful starting points for reflection and discussions.

Target Audience: Anyone interested in developing and delivering software
Prerequisites: Knowledge in DevOps and agile software development
Level: Advanced

Ein halbes Jahrhundert der Software-Entwicklung ist von einem überraschenden Phänomen geprägt: Wir, die Entwickler:innen + Architekt:innen, haben nicht nur immer wieder neue Technologien und Architekturansätze geschaffen, sondern auch Methoden entwickelt, die über die reine Programmierung hinausgehen. Projektleiter, Anwender, Betrieb und Tester haben von unseren Innovationen profitiert. Dieser Vortrag berichtet über die erstaunlichen Beiträge, die unsere Disziplin konzipiert und entwickelt hat, und wagt einen Blick in die Zukunft unserer Disziplin.

Zielpublikum: Alle
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Nach diesem Vortrag werden die Teilnehmenden voller Motivation ihre Reise durch die OOP antreten.

Neben dem Blick in die Vergangenheit wird die Zukunft unserer Disziplin den Schwerpunkt dieses Vortrags bilden.

Unter „Resilienz“ versteht man die Fähigkeit von Systemen, auch unter massiven Störungen von außen ihre Funktionsfähigkeit zu erhalten. Die Coronakrise mit ihren massiven Einschnitten und Opfern hat uns vor Augen geführt, dass Resilienz von Unternehmen entscheidend sein kann für das weitere Überleben. In diesem Vortrag betrachten wir Situationen, in denen Resilienz von besonderer Bedeutung ist, und leiten daraus ab, welche Voraussetzungen Unternehmen erfüllen müssen, um Resilienz zu zeigen. Spoiler: Auch Agilität spielt dabei eine Rolle ...

Zielpublikum: Manager:innen, Entscheider:innen, Organisations-Entwickler:innen, Coaches
Voraussetzungen: Verständnis über Unternehmenssteuerung und Agilität
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Roter Faden dieses Talks ist eine Analogie zwischen der Situation, in der sich Unternehmen während der Coronakrise befanden und noch immer befinden, und den (frei interpretierten) Phasen der Behandlung lebensbedrohlicher medizinischer Notfälle, für die sich in den letzten 50 Jahren weltweite Standards etabliert haben (nein, es wird keine Schockfotos geben. Mir geht es um Taktik und Strategie, nicht um Sensationslust).

Für jede der Phasen (unmittelbare Existenzsicherung, Ursachenfindung, Aufbau von Handlungsoptionen, Ausprobieren der Optionen, Einrichten auf die neue Normalität) wird analysiert, welche Eigenschaften und Praktiken Unternehmen dabei unterstützen oder behindern und wie man sie fördern kann. Dass dabei viele Ähnlichkeiten mit agilen Ansätzen aufscheinen, ist nicht überraschend, wichtig sind aber auch die Bereiche, in denen Agilität alleine nicht ausreicht.

Was hat das mit Tintenfischen zu tun? Diese kommen aus einer Analogie der "Supporting Agile Adoption"-Arbeitsgruppe der Agile Alliance, in der Oktopusse als Beispiel für einen völlig anders organisierten Organismus dienen, der dezentral mit neun Gehirnen kognitive Leistungen erbringt, die sich mit intelligenten Säugetieren messen lassen können. Es zeigt sich, dass die Fähigkeit von Organisationen, Entscheidungen verteilt fällen zu können, ihre Resilienz wesentlich verbessern kann.

Microservices kommen als Architektur-Idee gut an, Kubernetes etabliert sich als ihre Laufzeitumgebung - plus seiner Komplexität.

Praktisch ist jedoch, dass es auch mit eigenen Operatoren erweitert werden kann. Sie können im Test und Deployment der Services mit all ihren definierten Abhängigkeiten und deren Konfigurationen durch Automatisierung helfen. Dies rundet Microservices ab und erleichtert das Leben.

Lassen Sie sich in die Idee und die Entwicklung von Operatoren einführen.

Zielpublikum: Entwickler:innen, DevOps
Voraussetzungen: Basiskenntnisse in Go und Kubernetes
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Das Ausrollen von Microservices in einem Kubernetes-Cluster kann ein recht manueller Prozess sein, welcher sich mit externen Tools automatisieren lässt. Doch dies lässt von Service zu Service noch viel Freiraum zu, insbesondere in Bezug auf Abhängigkeiten wie Datenbanken, Message Queue und weiteren Tools.

Kubernetes Operatoren erlauben die Verlagerung der Automatisierung von außen nach innen. Die durch die Services zu nutzenden Tools und ihre Standardkonfigurationen lassen sich so zum Beispiel vordefinieren, sodass für das Rollout eines neuen Service nur mehr eine relativ begrenzte Konfiguration notwendig ist. Ebenso können Tests automatisch angestoßen werden. Die Einsatzzwecke sind vielfältig.

Die Session führt in die Idee der Operatoren ein, zeigt die Client-Bibliothek ebenso wie den Kubebuilder und nimmt dann in die Entwicklung eines Microservice Operators mit.

Moderne Cloudarchitekturen ermöglichen es, via Quellcode IT-Landschaften versioniert abzulegen und jederzeit automatisiert auf- und abzubauen. Mit dem Einsatz von Templates können Aspekte wie Sicherheit projektübergreifend genutzt und adressiert werden.

Anhand von praktischen Beispielen werden Prinzipien für eine betreibbare und wartbare Infrastrukturautomatisierung erläutert, beispielsweise Modularisierung von Infrastrukturelementen, Trennung von Konfiguration und Automatisierung sowie Lebenszyklen für Build, Deployment und Staging.

Zielpublikum: DevOps Engineer
Voraussetzungen: Grundlegendes Verständnis von DevOps
Schwierigkeitsgrad: Anfänger

Extended Abstract:
AWS, Openstack oder Azure - es ist heutzutage sehr einfach, Infrastruktur per GUI zusammenzustellen. Eine so aufgesetzte Infrastruktur ist aber nicht robust gegen Fehler und anfällig für Fehlbedienung. Im schlimmsten Fall kann die aufgebaute Infrastruktur nach einem Fehler oder Ausfall nicht mehr hergestellt werden - ein Szenario, das für eine Produktivumgebung undenkbar und höchst kritisch wäre.

Dieser Vortrag soll dazu motivieren, Infrastruktur analog zu Softwareständen als Code abzulegen und somit nachvollziehbar und reproduzierbar zu machen.

Wir bei intersoft bauen in Hamburg die Software für unsere Mutterfirma, die WWK-Versicherung in München. Entfernung: > 6 h Bahnfahrt. Alter der beteiligten Software-Komponenten: > 30 Jahre. Ältestes bekanntes Betriebssystem: BS2000. Kulturen: Bajuwaren und Wikinger. All das bietet eine Menge Zündstoff für Konflikte.

Wir berichten mitten aus der HOST-Migration der WWK auf zeitgemäße IT, über die Koexistenz moderner Produktentwicklungsteams mit alten 2-Monats-Releasezyklen. Und darüber, wie uns das Corona-Virus hilft, besser zu werden.

((d[-_-]b))

Zielpublikum: Legacy & Innovation lovers
Voraussetzungen: None
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Die HOST-Migration ist ein gigantisches und definierendes Projekt der WWK und muss bis 2023 abgeschlossen sein. Neben der ganz alten HOST-IT und der ganz neuen IT gibt es auch noch viel gewachsene Java-Software, die schon an den Rändern vergilbt. Insgesamt stehen wir damit vor einer entscheidenden Herausforderung für die Firma und vor einer Situation, die viele Unternehmen in ähnlicher Form kennen sollten. Neben den technischen Herausforderungen finden wir auch die organisatorischen und die kulturellen spannend. Wir berichten über:

Die entstehende Architekturarbeit zwischen Teams und Konzern.

Traditionelle Quality Gates in einem neuen gemeinsamen interkulturellen KANBAN Board.

Die schrittweise Verzahnung des Münchner Operations-Teams mit den Hamburger Entwicklern.

Wie sich QA im gesamten Prozess aus einem Test-Dungeon entwickelt

Wie ein Programm-Manager 3 Jahre vor der Rente beginnt, von Helm-Charts zu reden

Wir berichten davon, was schieflief und wo wir im Januar 2021 stehen werden

Das Vorhaben der HOST-Ablösung befindet sich nun schon im zweiten Jahr und wir haben gerade eine schlimme Frust-Phase hinter uns und ehrgeizige Meilensteine vor uns. Um von Frust auf Erfolg zu gehen, haben wir uns im Februar/März 2020 eng getaktete und frühe Liefertermine gesetzt. Interessanterweise hat das bei allen Stakeholdern zu viel Vertrauen geführt und die beteiligten Teams motiviert. Und dann kam Corona, und anstatt einer neuen Depression erleben wir, dass es besser läuft als erwartet. Auf einmal ist die gesamte Company gleich weit voneinander entfernt. Die Zusammenarbeit Hamburg, München und zurück läuft viel besser als vormals. Die Teams sind engagiert und hängen sich richtig rein. Meetings sind so effizient wie kaum zuvor.

Im Februar berichten wir dann live, wie es gelaufen ist und weiter geht.

Vor allen Dingen die Verzahnung von Produkt > Dev > QA > OPS in einen gemeinsamen schneller drehenden Prozess ermöglicht uns den Erfolg.

After years of introducing “CI”/CD-Pipelines, after using Jenkins, CircleCI, Docker and K8s, your teams still don’t deliver software within minutes? And your customers still know about bugs before you do? Well, maybe you’re doing it wrong.

We’ll share our experiences on how to incrementally get organisations and systems to be able to leverage all the things associated with “continuous everything”. We argue for solutions tailored to individual situations, and more connected to software craftsmanship than to buzzwords and boxed solutions.

Target Audience: Everyone with the challenge to get functionality to customers - quick
Prerequisites: Some knowledge about general software development
Level: Advanced

Extended Abstract:
After years of introducing “CI”/CD-Pipelines, after using Jenkins, CircleCI, Docker and K8s, your teams still don’t deliver software within minutes? And your customers still know about bugs before you do?

Maybe designing the perfect world during your first sprint just doesn’t cut it. The beautiful docker scaling idea just doesn’t work, because the “microservice” can only run in one instance at a time. The testautomation framework the Ops team provided can unfortunately not test your windows application. Your elasticsearch needs more and more space, but none of the developers have removed a single exception notification. The awesome buildpipeline with the included tests has a great dashboard that shows a red build continuously, but no one cares and you still do hotfixes on the production system. And your last major “refactoring” branch has been running green for the last two month, but you just can’t merge it back into your production code without breaking a few minds.

Well, maybe you’re doing it wrong.

Companies that successfully employ continuous delivery usually don’t excel in their tools. They excel in the architecture of their software, they excel in the way the people in the company work together, they excel in the way everyone actually understands what they are doing. In such environments people are not afraid of magic things that might happen in some unknown system, but leverage tools to automate things they themselves know how to do - so good that it gets boring and thus these tasks are better done by tools.

We’ll share our experiences on how to incrementally get organisations and systems to be able to leverage all the things associated with “continuous everything”. We argue for solutions tailored to individual situations, and more connected to software craftsmanship than to buzzwords and boxed solutions.

YAML seems to be the predominant way to describe our Kubernetes workloads. For each and every microservice we have to declare pods, deployments, services and a lot more. Now multiply this by several environments and deployment variants. The result often is excessive YAML bloat that leads to insufficient dev-prod parity, frustration and low developer productivity. So make sure to join this talk if you want to learn how to continuously deliver quality software and have happy Cloud-native developers on your team again.

Target Audience: Developers, Architects, Tech Leads, SREs
Prerequisites: Basic knowledge and experience with tools and practices of Cloud-native DevOps
Level: Advanced

Extended Abstract:
In this session we will have a closer look at several developer focused tools like Buildpacks, Helm, Kustomize, Skaffold and Tilt. These tools aim to improve and optimize the inner development loop by reducing the amount of YAML and the required steps from source to deployment significantly.