DevOps im Konzern: Autonomie vs Betriebssicherheit

•Download as PPTX, PDF•

0 likes•349 views

Aus Sicht eines DevOps-Teams ist für eine hohe angestrebte Geschwindigkeit hohe Autonomie bei allen Architektur- und Implementierungsentscheidungen notwendig. Aus Sicht der DB Systel, die den stabilen IT-Betrieb der Deutschen Bahn sicherstellen soll, ist die Forderung nach Autonomie jedoch ein Risiko. Zur Lösung dieses Konfliktes findet man daher in der Industrie häufig Ansätze, bei der Betriebseinheiten zentral betreute CI/CD-Pipelines bereitstellen. Während die mit dieser Lösung verbundene Automatisierung eine gute Kontrolle von Betriebsaspekten mit sich bringt, stellt die damit auch verbundene notwendige Standardisierung von Architekturaspekten häufig eine zu starke Einschränkung der Autonomie von DevOps-Teams dar. In diesem Talk möchten wir darauf eingehen, wie die DB Systel ihren DevOps-Teams durch Verortung der Betriebsverantwortung in den DevOps-Teams eine optimale Autonomie gewährt und gleichzeitig die Risiken für Stabilität, Datenschutz und Compliance kontrolliert. Wir geben Ihnen auch einen Einblick in den Alltag eines DevOps-Teams in der DB Systel aus Sicht eines Betroffenen. Wir stellen dar, wie hohe Autonomie und umfängliche Verantwortung eine völlig neue Arbeitsweise erfordern.

Internet

DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)
DevOps im Konzern
Autonomie von DevOps-Teams
vs. Sicherheit im Betrieb

Wir entwickeln und implementieren DevOps bei der Deutschen Bahn
2
Softwarecraftsman und DevOps-Coach
Deutsche Bahn / DB Systel GmbHJohannes
Dienst
DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)
Thomas
Kappatsch
Chefarchitekt IT (CI/CD / DevOps)
Deutsche Bahn / DB Systel GmbH

3 DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)
Digital | bewegen | verstehen | anwenden | begleiten | vernetzen | denken und handeln | belegen
DB Systel. Digital bewegen. Gemeinsam.

Bekenntnis der DB Systel zu DevOps
DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)4
„Wir entwickeln und betreiben Services
in stehenden, agilen Teams in der Cloud,
um unsere Time-to-Market Zyklen
radikal auf 2 Deployments pro Tag zu verkürzen.“

Von EDV zu DevOps - damals
DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)5

Von EDV zu DevOps - heute
DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)6

Von EDV zu DevOps - morgen
DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)7

„DevOps“ vs. „ein bisschen DevOps“
DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)8

Alltag eines DevOps-Teams
9 DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)
• API-basiertes headless Content
Management System
• Frei definierbares Datenmodell
• Unabhängigkeit zu Ausgabekanälen
• Umsetzung von individuellen
Webseiten-Themes oder Angular
Applikationen
• …

DevOps Produktionsmodell
DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)10

Shared Nothing Architecture
DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)11

Multi Cloud
DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)12

Agile Arbeitsweise
DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)13

Nah am Kunden
DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)14

Learnings
DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)15

Learnings (2)
DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)16

Learnings (3)
DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)17

DevOps-Coach (Fahrlehrer)
18 DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)
Arbeitet im Team mit
Coacht Methodisch
Coacht technisch

Compliance
DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)19

DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)20
Vorgaben

Compliance as a Service
DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)21

Fazit
22 DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)

DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)
Johannes.Dienst@DeutscheBahn.com
@JohannesDienst
Thomas.Kappatsch@DeutscheBahn.com

Unsere Talks auf der JAX
24
Mittwoch, 15:15, Rheingoldhalle Forum West
Docs as Code:
arc42, AsciiDoc und Gradle im Einsatz
Montag, 11:00, Rheingoldhalle Gutenberg 2+3
DevOps im Konzern – Autonomie von
DevOps-Teams vs. Betriebssicherheit
Ralf
Müller
DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)
Johannes
Dienst
Thomas
Kappatsch

What's hot

Collaboration day 2016 panagenda

Belsoft

Collaboration day 2016 - Connections - Apps

Belsoft

Viele IT-Lenker in Unternehmen machen sich gerade Gedanken, wie sie die bessere Wirtschaftlichkeit und Skaleneffekte von Cloud nutzen können. Dabei wählen sie einen dieser Wege: Private Cloud und Software-as-a-Service-Einkauf. Doch beide Wege stoßen schnell an Grenzen. Beck et al. Services eröffnet seinen Kunden einen Mittelweg, bei dem Wirtschaftlichkeit und Skaleneffekte genutzt werden, die Kontrolle über Daten und ihre Bestimmung jedoch beim Kunden bleibt:

Cloud ohne Kontrollverlust Webinar (1) der BeaS AWS Cloud Reihe

Beck et al. GmbH

Collaboration day 2016 - Aus alt mach neu - Modernisierung mit xPages

Belsoft

Was ist die beste Vorgehensweise um ein Produkt im Konzernumfeld für mehrere Mandanten auszurollen? Hoffentlich ein multimandantenfähiges Kaufprodukt einkaufen, das der Vorgabe der Prozesstrennung für Mandanten entspricht. Leider hatten wir in unserem Team kein solches Produkt zur Verfügung und standen vor der Herausforderung für jeden Mandanten einen eigenes System aufsetzen zu müssen. In diesem Vortrag beschreiben wir die drei Entwicklungsstufen unseres Deploymentprozesses hinsichtlich der Server-Infrastruktur in AWS inklusive Trennung der AWS-Accounts in Test- und Produktiv-Umgebungen. Die erste Phase beschreibt dabei den Aufbau einer managed Cloud mit festen Servern. Diese können zwar automatisiert eingerichtet werden, die automatische Skalierbarkeit ist aber unzureichend. Die nächste Iteration beleuchtet den Ansatz des "Infrastructure as Code" über Cloudformation, der für ein dediziertes System sehr gut funktionierte. Probleme bereiteten uns der richtige Git-Flow und die fehlende Unterstützung für eine echte Trennung der Systeme pro AWS-Account. In unserer aktuellen und hoffentlich finalen Iteration sind wir auf einen konsequenten GitOps-Ansatz gewechselt. Wir beschreiben, wie wir mit diesem Vorgehen seit Monaten stabile Infrastuktur-Deployments über Gitlab in Produktion bringen, welche Herausforderungen zu lösen waren im Hinblick auf Configuration as Code und dem richtigen Git-Flow. Auch die Erleichterung hinsichtlich der Einhaltung verschiedener Konzernvorgaben, beispielsweise der ISO 20000 an Release- und Changemanagement, darf hierbei nicht fehlen.

Von Managed-Cloud zu GitOps - Multi Client-Cluster Deployments

Johannes Dienst

SAP Enable Now - DeepDive Workshop Education Forum 2017

Thomas Jenewein

cloud oder nicht-cloud - strategien für sonnenschein am it-himmel

We4IT Group

Quibiq Flyer - Azure Integration Migration

QUIBIQ Hamburg

n diesem Vortrag berichtet der Sprecher von seinen Erfahrungen, Erfolgen und Fehlern mit dem arc42-Architekturtemplate in einem DevOps-Team im Konzernumfeld mit Produktentwicklungsfokus. Produktentwicklung ist geprägt von kurzen Iterationszyklen und wird darum gerne agil betrieben, wie im Team des Sprechers. Dort wurde die vorhandene unstrukturierte Dokumentation in das arc42-Template überführt und in einem Wiki abgelegt. Im Laufe der Zeit stellte sich heraus, dass das Tooling eine entscheidende Rolle für die Qualität der Dokumentation bedeutet und deswegen auf Docs-as-Code umgestellt. Im Laufe des Vortrags wird auf die wichtigsten Entscheidungspunkte für die aktuelle Iteration der technischen Softwarearchitektur eingegangen. Darunter unter anderem der Umgang mit "Entwicklerprosa", veralteter Dokumentation und der für ein DevOps-Team besonders wichtigen Architekturentscheidungen. Die Einbindung in das methodische Vorgehen Kanban wurde mit arc42 und einer Microsite basierend auf AsciiDoc möglich. Nicht ausgespart werden die gemachten Fehler, wie zum Beispiel fehlende Qualitätssicherung erstellter Dokumentation oder die Vermischung von fachlichen und technischen Themen.

Lessons Learned: arc42 in einem echten DevOps Team

Johannes Dienst

What's hot (9)

Collaboration day 2016 panagenda

Collaboration day 2016 - Connections - Apps

Cloud ohne Kontrollverlust Webinar (1) der BeaS AWS Cloud Reihe

Collaboration day 2016 - Aus alt mach neu - Modernisierung mit xPages

Von Managed-Cloud zu GitOps - Multi Client-Cluster Deployments

SAP Enable Now - DeepDive Workshop Education Forum 2017

cloud oder nicht-cloud - strategien für sonnenschein am it-himmel

Quibiq Flyer - Azure Integration Migration

Lessons Learned: arc42 in einem echten DevOps Team

Similar to DevOps im Konzern: Autonomie vs Betriebssicherheit

Es vergeht kaum ein Jahr in dem keine neue disruptive Technologie auftaucht. War es früher möglich mit moderatem Aufwand sich auf dem neuesten Stand zu halten, ist es inzwischen praktisch unmöglich geworden. Zusätzlich wird mit agilen Methoden entwickelt und gerade im Konzernumfeld schlagen vorhandene zwischenmenschliche und politische Spannungen dadurch oft bis auf den einzelnen Mitarbeiter durch. Auch ich sah mich in dieser Situation und war auf der Suche, wie ein sinnvoller Umgang damit aussehen kann. Dabei stieß ich auf die griechische Philosophie namens Stoizismus. Sie wird von vielen Menschen praktiziert, die sich in herausfordernden Lebensumständen befinden. Als ganzheitliche praxisfokusierte Philosophie richtet sich der Stoizismus vor allem an den einzelnen Menschen und hilft ihm dabei das höchste Ziel des glücklichen Daseins (Eudaimonía) anzustreben. In diesem Vortrag werden die Grundzüge des Stoizismus vorgestellt. Anschließend beschäftigen wir uns mit den wichtigsten Eigenschaften eines übenden Stoikers. Darunter auch emotionale Selbstbeherrschung. Diese können durch geeignete Übungen gezielt trainiert werden, um im Alltag mehr Gelassenheit zu bekommen und resilienter zu werden. Im Alltag lässt sich damit Stress vermeiden und der Fokus auf die möglichen Lösungen lenken anstatt nicht gewinnbringende Auseinandersetzungen einzugehen.

Griechische Philosophie für moderne Softwareentwicklung

Johannes Dienst

Das Scaled Agile Framework kombiniert Ansätze aus den agilen Methoden Scrum, Kanban und Extreme Programming mit Lean Thinking sowie den von Donald G. Reinertsen formulierten Prinzipien zum Lean Product Development und ermöglicht es so, Agilität im Enterprise Umfeld und grossen Maßstab anzuwenden. Für die Entwickler tönt das sehr spannend, aber geht denn das auch im Infrastrukturbau? Klar Infrastructure-as-Code, ist ja schliesslich auch nur programmieren, aber wenn dann die gestandenen Datenbankadministratoren sich in einem agilen Team einfinden müssen, ist der Spass vielleicht schon vorbei. In diesem Vortrag wird die Struktur von SAFe aufgezeigt und dann auf die Erfahrungen eines DBA und System-Engineer-Teams eingegangen, welches in ein bestehendes SAFe-Umfeld integriert wurde. Die DevOps-Phasen mit initialem Aufbau, Betrieb mit SLA-Verantwortung und Lifcycle werden ebenfalls vorgestellt und der Ablauf von PI (Programm Increment) über Sprints mit Userstories erläutert.

Infrastruktur agil bauen - der DBA im SAFe-Umfeld

Daniel Steiger

In diesem Vortrag erfahren Sie, warum sich der erste Ansatz einer zentralen CI/CD-Installation für alle Teams als problematisch erwies und durch dezentrale Pipelines ersetzt wurde. Danach lernen Sie die Tücken unserer Einführung einer eingekauften API-Management-Lösung kennen, und wieso sich der Kauf von großer On-Premise-Software nur schwer mit den agilen Prinzipien vereinbaren lässt. Der Zuhörer lernt zudem, wie wir im Team mit polyglotter Softwareentwicklung zu kämpfen haben und wie wir permanent gegen Wissensinseln ankämpfen. Zuletzt gehe ich darauf ein, wie wir mit umfassender Architekturdokumentation gestartet und gescheitert sind. Unser neuer Ansatz ist eine leichtgewichtige dezentrale Dokumentation mit AsciiDoc und ein im Team abgestimmter Toolstack, der auch vom Zuhörer adaptiert werden kann. Am Ende der Reise wird der Zuhörer einige Methoden und Tools kennen gelernt haben, um in einem Kontext zu überleben, der an vielen Stellen noch von klassischen Prozessen dominiert wird. Aber eines ist klar: Der Weg Richtung DevOps geht nicht plötzlich, es ist eine Reise mit Umwegen und Hindernissen. Die Reise ist es aber auf jeden Fall Wert!

DevOps - Mehr Geschwindigkeit auf der Schiene

Vorname Nachname

Dev Day Johannes Dienst.pdf

CarolinaMatthies

Architectures for .Net Core Applications

Robin Sedlaczek

Präsentation über SharePoint 2016 Beim Event Get ready for SharePoint 2016 hat die Next Iteration GmbH aus Karlsruhe die neue SharePoint Version ausführlich vorgestellt. Neben den Themen "Die Zukunft der Arbeit" und Cloud basierte Infrastruktur ging es hauptsächlich um die Zukunft von SharePoint. Das Microsoft Event "The future of SharePoint" wurde ebenso beleuchtet, wie die neue Features von SharePoint 2016. Zum Ende der Präsentation wurden konkrete Informationen zur Migration auf SharePoint 2016 gegeben und angesprochen, in welchem Fall SharePoint 2016 empfohlen wird.

Get ready for SharePoint 2016

Next Iteration

Das arc42-Architektur-Template verleitet dazu, alle Kapitel von oben nach unten durchzuarbeiten. Ein Architektur-Review offenbart aber eine sinnvollere Herangehensweise, um Softwarearchitektur zu erarbeiten. Dabei werden zuerst In-Scope sowie Out-Of-Scope des Vorhabens definiert und anschließend Qualitätsattribute aufgenommen, um schließlich konkrete Qualitätsszenarien abzuleiten. Die Dokumentation dieser Ergebnisse im arc42 stellt uns vor viele Aufgaben und Fragestellungen: Wie erarbeite Architekturentscheidungen, Qualitätsattribute und Qualitätsszenarien? Und wie dokumentiere ich diese effizient? In diesem Vortrag zeigen wir anhand des Docs-as-Code-Ansatzes, wie wir mit dem arc42-Template effizient arbeiten und die Dokumentation als Microsite jedem zur Verfügung gestellt wird. Durch diese Vorgehensweise ist es effizient möglich, eine Architekturdokumentation zu erstellen, die jeder Review standhält.

Rock Solid Software Architecture with ADRs, arc42 and Microsites

Johannes Dienst

Developer Week 2019: Architekturen für .NET Core-Anwendungen

Robin Sedlaczek

.NET Core Architecture (UI)

Robin Sedlaczek

V02 02 - weinbrecht - koexistenzmodelle und -erfahrungen

Andreas Weinbrecht

Technologie und SEO: Cloud, Big Data und Mobile First angeschaut

Ralf Schwoebel

"Failure is not an options" Slides from our IBM Connections Webinar Series. F...

Beck et al. GmbH

Softwarearchitektur ist in aller Munde. Doch was ist diese Disziplin über die jeder gerne spricht? Die Antwort ist selbst in der Literatur nicht eindeutig. Fest steht: Sie ist immer vorhanden. Entweder implizit oder explizit. Meistens wird aber nur die technische Seite der Softwarearchitektur betrachtet. Dabei ist sie vielseitiger als es den Anschein hat. In diesem Vortrag werden überraschende Eigenschaften von Softwarearchitektur vorgestellt. Dabei wird bewusst auf weniger im Fokus stehende Themen wie zum Beispiel Risikomanagement eingegangen. Diese Eigenschaften können genutzt werden, um die Kommunikation mit Stakeholdern zu verbessern und ein Softwareprojekt effizient zu steuern.

Ist das Softwarearchitektur oder kann das weg?

Johannes Dienst

ConSol Unternehmenspräsentation 2019

ConSol Consulting & Solutions Software GmbH

Im Webcast, der sich im Allgemeinen an den IT-Channel und im Besonderen an SAP- und Microsoft-Partner richtet, geht es unter anderem um • die Gestaltung von vertikalen, wertschöpfenden „as a Service“-Lösungen • Value-Added-Service im Bereich Systemintegration • Integrations-Services für Daten und Prozesse • Applikations-Integration und Mehrwertleistungen von QUIBIQ und Tech Data für Microsoft- und SAP-Partner.

QUIBIQ Webcast: SAP on Azure - Erfolgsfaktor Integration für SAP-/MS-Partner

QUIBIQ Hamburg

Modellierung integrierter SAP System Landschaften

cbs Corporate Business Solutions Unternehmensberatung GmbH

Config as Code: Der Weg zu Configuration as Code

DevOps Meetup Bern

ShareConf 03.07.2014 SAP Integration für Sharepoint

Patrick Theobald

Webinar Cloud als Bindeglied

acentrix GmbH

Die Cloud als Bindeglied zwischen Legacy IT & zukünftigen Arbeitsplatzkonzep...

acentrix GmbH

Similar to DevOps im Konzern: Autonomie vs Betriebssicherheit (20)

Griechische Philosophie für moderne Softwareentwicklung

Infrastruktur agil bauen - der DBA im SAFe-Umfeld

DevOps - Mehr Geschwindigkeit auf der Schiene

Dev Day Johannes Dienst.pdf

Architectures for .Net Core Applications

Get ready for SharePoint 2016

Rock Solid Software Architecture with ADRs, arc42 and Microsites

Developer Week 2019: Architekturen für .NET Core-Anwendungen

.NET Core Architecture (UI)

V02 02 - weinbrecht - koexistenzmodelle und -erfahrungen

Technologie und SEO: Cloud, Big Data und Mobile First angeschaut

"Failure is not an options" Slides from our IBM Connections Webinar Series. F...

Ist das Softwarearchitektur oder kann das weg?

ConSol Unternehmenspräsentation 2019

QUIBIQ Webcast: SAP on Azure - Erfolgsfaktor Integration für SAP-/MS-Partner

Modellierung integrierter SAP System Landschaften

Config as Code: Der Weg zu Configuration as Code

ShareConf 03.07.2014 SAP Integration für Sharepoint

Webinar Cloud als Bindeglied

Die Cloud als Bindeglied zwischen Legacy IT & zukünftigen Arbeitsplatzkonzep...

More from Johannes Dienst

Metrics in Developer Relations can be perplexing, often leading to confusion and vague advice. In this talk, I share practical insights gathered from my extensive research and hands-on application within my current company. If you've ever felt lost in discussions where specific recommendations are elusive, join me. This session is a down-to-earth guide for both newcomers and experienced professionals, offering practical wisdom to navigate the metrics maze.

Developer Relations Metrics - A Humble Guide

Johannes Dienst

Testing workflows that span multiple applications and platforms is a challenging task. Imagine a test case that calls an API first, then an operator has to enter information at his web app so that the end user finally sees the update in his native app on a smartphone. Real End-to-End automation is nearly impossible today. Current approaches try to automate cross-platform with the help of web apps running on (mobile) browsers. Native apps on Android or iOS can only be included in the workflow using time-intensive techniques like picture-in-picture search because they lack code selectors that operate on the Document-Object-Model (DOM). With the rise of machine learning/artificial intelligence, we can train models to recognize elements on User Interfaces based solely on visual attributes. With that, it becomes possible to automate any platform when you combine it with automation on the Operating System level. In this talk, I will show a live demo that will walk the audience step-by-step through a typical 2-Factor Authentication using a physical smartphone. We will see what automation is possible today and how it enables testing currently untestable workflows.

Real Cross-Platform Workflow UI Automation_JohannesDienst.pdf

Johannes Dienst

UI testing is an essential part of software development. Despite technological progress, the automation of UI tests is still considered too complex to function completely without manual intervention. In addition to classical selector-based approaches, more and more image-based methods are being pursued. This talk will cover the "state of the art" of UI testing with an overview of tools and techniques. In particular, current problems and future developments will be discussed. Furthermore, it will be shown which kind of UI representations are used by today's test tools and how the addressing of elements in the user interface is done. In addition, the role of artificial intelligence in the different approaches is shown and a prediction of testing tools of the future is presented on the basis of current research.

The Future of UI Testing - Challenges in UI Automation

Johannes Dienst

What is the best practice to roll out a product in a multi-client group environment? Hopefully, purchase a multi-client capable product that meets the requirement of process separation for clients. Unfortunately, we did not have such a product available in our team and were faced with the challenge of having to set up a separate system for each client. In this talk, we will describe the three development stages of our deployment process with respect to the server infrastructure in AWS including separation of AWS accounts into test and production environments. The first phase describes the setup of a managed cloud with fixed servers. Although these can be set up automatically, the automatic scalability is insufficient. The next iteration highlights the "infrastructure as code" approach via cloudformation, which worked very well for a dedicated system. Problems we had were the proper Git flow and the lack of support for true separation of systems per AWS account. In our current and hopefully final iteration, we switched to a consistent GitOps approach. We describe how we have been using this approach for months to bring stable infrastructure deployments into production via Gitlab, what challenges had to be solved in terms of Configuration as Code and proper Git flow. We also talk about how this process facilitates compliance with various corporate requirements, such as ISO 20000 for release and change management.

Managed Cloud to GitOps: Deploying Several Client Clusters

Johannes Dienst

Stoizismus - Praktische Philosophie für den IT-Alltag (Pecha Kucha)

Johannes Dienst

Managed Cloud to GitOps: Deploying Several Client Clusters

Johannes Dienst

In this presentation, the speaker will talk about his experiences, successes and failures with the arc42 architecture template in a DevOps team in a corporate environment with a product development focus. Product development is often characterised by short iteration cycles and is therefore often operated in an agile manner, as in the speaker's team. There the existing unstructured documentation was transferred to the arc42 template and stored in a wiki. In the course of time, it turned out that tooling plays a decisive role for the quality of the documentation and therefore switched to Docs-as-Code. In the course of the presentation, the most important decision points for the current iteration of the technical software architecture will be discussed. These include the handling of "developer prose", outdated documentation and the architecture decisions that are particularly important for a DevOps team. The integration into the methodical procedure Kanban was made possible with arc42 and a microsite based on AsciiDoc. Not left out are the mistakes made, such as missing quality assurance of created documentation or the mixing of business and technical topics.

Lessons Learned Using arc42 in a Real DevOps Team

Johannes Dienst

Documentation is not one of the favorite tasks in everyday software development. Either there is hardly any documentation or too much. This makes it difficult to find information. A lightweight approach is the arc42 template. It also documents design decisions that shape the software architecture. Undocumented design decisions can lead to incorrect follow-up decisions that can cause the project to fail. But how can many decisions be documented efficiently and comprehensibly? This presentation will introduce a compact format called Architecture Decision Records (ADR) and show how they can be used efficiently. In addition to small details such as title assignment, a proposed solution is shown for dealing with a large collection of design decisions (>50). The Docs As Code approach is used. Through tagging and an efficient search, the documentation becomes a daily work tool.

Work efficiently with Architecture Decision Records

Johannes Dienst

Mit DevOps sollen Dev und Ops zusammenwachsen. Dadurch sollen Teams in die Lage versetzt werden, die komplette Wertschöpfungskette abzudecken. Von der Anforderungen bis hin zum Betrieb in der Produktion. Die Qualität der produzierten Lösung soll sich dadurch signifikant erhöhen, da keine lokale Optimierung mehr stattfindet. Das hört sich zuerst einmal sinnvoll und attraktiv für Mitglieder eines DevOps-Teams an. Mit der gleichen Einstellung war ich vor einem Jahr einem DevOps-Team in der DB Systel beigetreten. In diesem Vortrag schildere ich meine persönlichen Erfahrungen in diesem Team. Was für uns funktioniert und was nicht funktioniert hat. Dabei werden schmerzhafte Erkenntnisse nicht ausgespart, aber auch gezeigt, welche Strategien zum Erfolg führen können.

The Dev, The Ops, And The Team: What works in a DevOps Team?

Johannes Dienst

Dokumentation gehört oft nicht zu den Lieblingsaufgaben im Softwareentwicklungsalltag. Das resultiert in vielen Fällen daraus, dass nicht klar ist, warum etwas dokumentiert werden sollte. Der in der Praxis gelebte Ansatz einen Dokumentationsort, zum Beispiel in Form eines Wikis, ist zum Scheitern verurteilt. Entweder es wird kaum dokumentiert oder zu viel und es wird schwer Informationen zu finden, die man sucht. Ein leichtgewichtiger Ansatz ist arc42, bei dem je nach Bedarf die vorgegebenen Unterpunkte ausgefüllt werden. Dort werden im Unterpunkt neun Entwurfsentscheidungen dokumentiert, also genau die Entscheidungen, die die Softwarearchitektur entscheidend prägen. Die Auswirkungen von nicht dokumentierten Entscheidungen gehen von immer wiederkehrenden Diskussionen, bis hin zu fehlerhaften Folgeentscheidungen die das Projekt zum Scheitern bringen können. Doch wie können viele Entscheidungen effizient und nachvollziehbar dokumentiert werden? In diesem Vortrag wird ein kompaktes Format namens Architecture Decision Records (ADR) vorgestellt und gezeigt, wie sie effizient eingesetzt werden können. Neben Kleinigkeiten wie der Titelvergabe für eine ADR wird ein Lösungsvorschlag aufgezeigt, um bei einer großen Sammlung von Entwurfsentscheidungen (>50) nicht den Überblick zu verlieren. Dabei kommt der Docs-As-Code Ansatz mit AsciiDoc und JBake zum Einsatz, mit dem die technische Architektur in einer Microsite gerendert wird. Durch Tagging und eine effiziente Suche, wird die Dokumentation nicht nur lebendig, sondern zum täglichen Arbeitsmittel.

Effizient arbeiten mit Architecture Decision Records (ADR)

Johannes Dienst

Agile Softwareentwicklung stellt die zwischenmenschliche Kommunikation in den Vordergrund, was dazu führen soll, das Richtige richtig zu implementieren und Software schneller ausliefern zu können. Doch wie dokumentieren agile Teams ihre Softwarearchitektur? Herkömmliche Vorgehensweisen wirken zu schwergewichtig, da sie sich eher für Wasserfall-Projekte eignen. Sollten architekturrelevante Entscheidungen überhaupt dokumentiert werden? Und wie fügt sich eine geeignete Methode in die agile Arbeitsweise ein? In diesem Vortrag wird eine leichtgewichtige Methode zur Dokumentation von Softwarearchitektur vorgestellt. Diese hält Architekturentscheidungen in Architecture Decision Records (ADR) fest. Ein kompaktes Format, angereichert mit Zusatzinformationen, wie Kontext und Randbedingungen. Nicht-funktionale Anforderungen werden als Qualitätsszenarien beschrieben, deren Erfüllung durch die ADRs geprüft werden kann. So wird die Dokumentation ein Instrument zur Kommunikation mit allen Stakeholdern

Leichtgewichtige Softwarearchitektur mit Architecture Decision Records und Qu...

Johannes Dienst

Das Spock Testframework verwendet das ausdrucksstarke Groovy um BDD als Testansatz zu realisieren. Neben einer klaren Teststruktur punktet es mit lesbaren Reports, die dank einer Template-Engine auch in AsciiDoc generiert werden können. Kann man das noch verbessern? Wir treten den Beweis an und kombinieren Spock mit Mutationstests. Denn eine Testabdeckung von über 80 % beweist noch nicht, dass die Testsuite in der Lage ist Fehler zuverlässig zu erkennen. Der Vortrag zeigt, wie sich Spock mit Mutationstesten zu einem cleveren Duo kombinieren lässt.

Spock vs Supermutanten: Spezifikationstesten trifft Mutationstesten

Johannes Dienst

In diesem Vortrag wird eine leichtgewichtige Methode zur Dokumentation von Softwarearchitektur vorgestellt. Diese hält Architekturentscheidungen in Architecture Decision Records (ADR) fest. Ein kompaktes Format, angereichert mit wichtigen Zusatzinformationen, wie Kontext, Alternativlösungen und Randbedingungen. Nicht funktionale Anforderungen werden als Qualitätsszenarien beschrieben und deren Erfüllung durch die ADRs geprüft werden kann. So wird die Dokumentation ein effizientes Instrument zur Kommunikation mit allen Stakeholdern.

Leichtgewichtige Softwarearchitektur mit Architecture Decision Records und Qu...

Johannes Dienst

Im agilen Umfeld hat das Team die Arbeitsgemeinschaft ersetzt. Crossfunktional, T-Shaped und selbstorganisiert soll es sein. Was sich nach einer idealen Arbeitsumgebung anhört, kann langfristig trotzdem zu Frust und Motivationsverlust führen. Was können die Ursachen sein? Im ersten Teil des Vortrags (Stolz) geht es um die Mechanismen rund um Teambildung. Im Großen sind das Bestimmung einer Teamvision und -Mission und die Ermittlung von gemeinsamen Werten. Im Kleinen ist es das Konzept der „Psychological Safety“, das allen erfolgreichen Teams gemeinsam ist. Außerdem wird mit Stoizismus eine Geisteshaltung vorgestellt, mit der jeder Einzelne aktiv sein teamorientiertes Handeln verbessern kann. Es ist aber ein Vorurteil, wenn man glaubt, dass ein funktionierendes Team einmal zusammengestellt dauerhaft gut zusammenarbeitet. Daher werfen wir im zweiten Teil einen Blick auf den aktuellen Forschungsstand und die Historie von Motivation. Teilnehmer verstehen, was es mit extrinsischer und intrinsischer Motivation auf sich hat und welche Menschenbilder Taylorismus und die X-Y-Theorie propagieren. Wir gehen auf verschiedene evolutionäre Organisationsformen von Unternehmen ein und zeigen, wie gut die verschiedenen Motivationstheorien zu bestimmten Organisationsformen passen. Abschließend bringen wir Stolz & Vorurteil zusammen: wir zeigen, wie in agilen Teams mit der individuell passenden Motivation langfristig erfolgreich zusammengearbeitet werden kann.

Pride & Prejudice: Teambildung & Motivation im agilen Umfeld

Johannes Dienst

Leichtgewichtige Softwarearchitektur mit Architecture Decision Records und Qu...

Johannes Dienst

Agile Softwareentwicklung stellt die zwischenmenschliche Kommunikation in den Vordergrund, was dazu führen soll das Richtige richtig zu implementieren und Software schneller ausliefern zu können. Doch wie dokumentieren agile Teams ihre Softwarearchitektur? Herkömmliche Ansätze sind meist zu schwergewichtig, da sie eher auf Wasserfallprojekte zugeschnitten sind. Sollten architekturrelevante Entscheidungen überhaupt dokumentiert werden? Und wie fügt sich eine geeignete Methode in die agile Arbeitsweise ein? In diesem Vortrag wird eine leichtgewichtige Methode zur Dokumentation von Softwarearchitektur vorgestellt. Diese hält Architekturentscheidungen in Architecture Decision Records (ADR) fest. Ein kompaktes Format, angereichert mit wichtigen Zusatzinformationen, wie Kontext, Alternativlösungen und Randbedingungen. Nicht funktionale Anforderungen werden als Qualitätsszenarien beschrieben und deren Erfüllung durch die ADRs geprüft werden kann. So wird die Dokumentation ein effizientes Instrument zur Kommunikation mit allen Stakeholdern.

Leichtgewichtige Softwarearchitektur mit Architecture Decision Records und Qu...

Johannes Dienst

Eine Testabdeckung von 50-80% ermöglicht es eine Codebasis wartbar zu halten. Refaktorisierungen sind dadurch sicherer durchführbar. Doch diese Sicherheit ist trügerisch. Denn wer garantiert, dass die Tests das richtige Testen? An dieser Stelle tritt eine "alte" Technik auf den Plan: Das Mutationstesten. Bereits 1971 vorgeschlagen, gewinnt es heute mit leistungsfähigen Multicore-Prozessoren immer mehr an Bedeutung. Der Vortrag zeigt die Leistungsfähigkeit dieser Technik am Beispiel der ausgereiften Bibliothek PIT. Mit dieser wurden Tests aus einem realen Projekt überprüft und deren Qualität erheblich gesteigert.

Und wer testet die Tests? - Mutationstesten mit PIT

Johannes Dienst

TypeScript ist in der heutigen JavaScript-Welt ein immer wieder auftauchender Bestandteil. Mit TypeScript 2.0 wurde der Grundstein gelegt, die Sprache endgültig in das bestehende JavaScript-Tooling mit npm zu integrieren. In dieser Livecoding-Session werden wegweisende Features vorgestellt. Darunter die immer bessere Control-Flow-Analyse zur Typinferenz als auch Non-nullable Types, Sprachkonstrukte für besseres OOP und ganz neue Typen wie never. Ein weiteres Thema sind die ESNext-Features, wie Async/Await und Decorators, die schon heute nach ES3/ES6 transpiliert werden können.

Type Script 3.x - Was war. Was kommt!

Johannes Dienst

Die moderne Softwareentwicklung hat eine ganze Reihe von Techniken parat, um hohe Qualität zu erzeugen. Kein seriöses Softwareunternehmen würde heutzutage ohne Versionskontrollsystem, Continuous Integration, Unit-Tests etc. pp. arbeiten. Bewegungen wie Clean Code geben Entwicklern Regeln an die Hand, wie Code handwerklich sauber produziert werden kann. Diese Regeln sind einfach einzuhalten, werden aber oft missachtet. Wie kommt es dann, dass unter vorgehaltener Hand viele Teams über Qualitätsprobleme klagen? Das Problem scheint eine andere Ursache zu haben. Der Vortrag beleuchtet das Thema Softwarequalität von verschiedenen Blickwinkeln. Insbesondere werden die gängigen Herangehensweisen zur Lösung der Qualitätsprobleme wie agile Softwareentwicklung kritisch betrachtet. Schließlich wird ein Lösungsvorschlag mit Empathy Driven Development in Kombination mit szenariobasierter Softwarearchitektur vorgestellt.

Clean Code ist doch einfach... Qualität ist schwierig!

Johannes Dienst

More from Johannes Dienst (19)

Developer Relations Metrics - A Humble Guide

Real Cross-Platform Workflow UI Automation_JohannesDienst.pdf

The Future of UI Testing - Challenges in UI Automation

Managed Cloud to GitOps: Deploying Several Client Clusters

Stoizismus - Praktische Philosophie für den IT-Alltag (Pecha Kucha)

Managed Cloud to GitOps: Deploying Several Client Clusters

Lessons Learned Using arc42 in a Real DevOps Team

Work efficiently with Architecture Decision Records

The Dev, The Ops, And The Team: What works in a DevOps Team?

Effizient arbeiten mit Architecture Decision Records (ADR)

Leichtgewichtige Softwarearchitektur mit Architecture Decision Records und Qu...

Spock vs Supermutanten: Spezifikationstesten trifft Mutationstesten

Leichtgewichtige Softwarearchitektur mit Architecture Decision Records und Qu...

Pride & Prejudice: Teambildung & Motivation im agilen Umfeld

Leichtgewichtige Softwarearchitektur mit Architecture Decision Records und Qu...

Und wer testet die Tests? - Mutationstesten mit PIT

Type Script 3.x - Was war. Was kommt!

Clean Code ist doch einfach... Qualität ist schwierig!

DevOps im Konzern: Autonomie vs Betriebssicherheit

1. DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst) DevOps im Konzern Autonomie von DevOps-Teams vs. Sicherheit im Betrieb

2. Wir entwickeln und implementieren DevOps bei der Deutschen Bahn 2 Softwarecraftsman und DevOps-Coach Deutsche Bahn / DB Systel GmbHJohannes Dienst DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst) Thomas Kappatsch Chefarchitekt IT (CI/CD / DevOps) Deutsche Bahn / DB Systel GmbH

4. Bekenntnis der DB Systel zu DevOps DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)4 „Wir entwickeln und betreiben Services in stehenden, agilen Teams in der Cloud, um unsere Time-to-Market Zyklen radikal auf 2 Deployments pro Tag zu verkürzen.“

5. Von EDV zu DevOps - damals DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)5

6. Von EDV zu DevOps - heute DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)6

7. Von EDV zu DevOps - morgen DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)7

8. „DevOps“ vs. „ein bisschen DevOps“ DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)8

9. Alltag eines DevOps-Teams 9 DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst) • API-basiertes headless Content Management System • Frei definierbares Datenmodell • Unabhängigkeit zu Ausgabekanälen • Umsetzung von individuellen Webseiten-Themes oder Angular Applikationen • …

10. DevOps Produktionsmodell DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)10

11. Shared Nothing Architecture DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)11

12. Multi Cloud DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)12

13. Agile Arbeitsweise DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)13

14. Nah am Kunden DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)14

15. Learnings DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)15

16. Learnings (2) DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)16

17. Learnings (3) DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)17

18. DevOps-Coach (Fahrlehrer) 18 DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst) Arbeitet im Team mit Coacht Methodisch Coacht technisch

19. Compliance DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)19

20. DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)20 Vorgaben

21. Compliance as a Service DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)21

22. Fazit 22 DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst)

23. DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst) Johannes.Dienst@DeutscheBahn.com @JohannesDienst Thomas.Kappatsch@DeutscheBahn.com

24. Unsere Talks auf der JAX 24 Mittwoch, 15:15, Rheingoldhalle Forum West Docs as Code: arc42, AsciiDoc und Gradle im Einsatz Montag, 11:00, Rheingoldhalle Gutenberg 2+3 DevOps im Konzern – Autonomie von DevOps-Teams vs. Betriebssicherheit Ralf Müller DB Systel GmbH | Thomas Kappatsch Johannes Dienst (@JohannesDienst) Johannes Dienst Thomas Kappatsch

Editor's Notes

Wir kennen ihn alle…Hat schon ganze Architekturlangschaften auf Bierdeckeln entworfen.
Hat
Netzwerk ist unglaublich wichtig
Unglaublich viel gelernt
17 Security 13 Compliance 13 DSGVO 12 BSI 11 CMMI 11 SLA 10 ISO9000 10 ITIL 10 TÜV 9 Verschlüsselung 9 BestPractices 9 Whitesource 9 Prinzipien 9 Lizenzen 9 ISO20000 9 Incident 9 App-Sec 9 A-Team 9 Claire 9 KoRiL 9 LINT 8 Problem 8 Change

DevOps im Konzern: Autonomie vs Betriebssicherheit

Recommended

Recommended

More Related Content

What's hot

What's hot (9)

Similar to DevOps im Konzern: Autonomie vs Betriebssicherheit

Similar to DevOps im Konzern: Autonomie vs Betriebssicherheit (20)

More from Johannes Dienst

More from Johannes Dienst (19)

DevOps im Konzern: Autonomie vs Betriebssicherheit

Editor's Notes