Hauptsache, die Software funktioniert erst mal. Die User:innen werden uns schon auf die Bugs aufmerksam machen. Ok, wenn etwas Zeit ist, schauen wir noch auf die Usability. Dann kann aber wirklich keiner meckern!

Security by Design ist keine Worthülse, sondern ein notwendiges Konzept. Anhand einiger Beispiele aus der Welt der Kriminellen macht Eva Wolfangel deren Denkweise nachvollziehbar und zeigt, wie vernachlässigte Sicherheitsfragen und systematische Denkfehler in der Entwicklung zu großen Problemen führen können.

Zielpublikum: Alle
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Hauptsache, die Software funktioniert erst mal. Oder wenigstens so ungefähr. Die User:innen werden uns schon auf die Bugs aufmerksam machen. Schnell raus damit, ab auf den Markt. Ok, wenn etwas Zeit ist, schauen wir noch auf die Usability. Dann kann aber wirklich keiner meckern!

Diese Haltung ist verbreitet – und sie führt zu vielen Sicherheitslücken, die Kriminelle als erstes finden und ausnutzen. Security by Design ist keine Worthülse, sondern ein notwendiges Konzept. Wer Sicherheit nicht von Anfang an mitbedenkt, hat verloren. Denn sie lässt sich nicht einfach hinterher implementieren, sondern muss schon im ersten Brainstorming mit konzipiert werden. Dabei ist es besonders wichtig sich zu vergegenwärtigen, wie Kriminelle Lücken aufspüren und wie sie systematisch nach ihnen suchen. Anhand einiger Beispiele aus der Welt der Kriminellen macht Eva Wolfangel deren Denkweise nachvollziehbar und zeigt, wie vernachlässigte Sicherheitsfragen und systematische Denkfehler in der Entwicklung zu großen Problemen führen können. Die gute Nachricht: Wer sich in die Köpfe der Angreifer:innen hineinversetzt, wird künftig bei entsprechenden Denkfehlern hellhörig und hat damit schon den ersten Schritt in Richtung sicherer Systeme gemacht.

For many people, refactoring is a simple code transformation they click on in a context menu or via a keyboard shortcut. The widespread availability of automated refactoring should have made oversized classes and long-winded functions a thing of the past. But it hasn't.

Having a tool is only part of the solution: knowing what to do with it and how to use it well matters. In this talk, we'll revisit what refactoring is (and isn't) and emphasise the idea that refactoring should be considered a design process and not just a clean-up click.

Target Audience: Developers, Architects, Tech Leads
Prerequisites: Programming experience
Level: Advanced

Extended Abstract:
For many people, refactoring is a simple code transformation they click on in a context menu or via a keyboard shortcut. They can extract, inline, replace, move, rename, etc. at will. The widespread availability of automated refactoring should have made oversized classes and long-winded functions a thing of the past. But it hasn't.

Having a tool is only part of the solution: knowing what to do with it and how to use it well is what makes the bigger difference. Refactoring is often mentioned in the context of agile development, test-driven development and legacy code, but beyond saying that it should happen, there is often not much focus on how and why.

In this talk, we'll revisit what refactoring is (and isn't), examine what practical and social obstacles refactoring faces, explore the idea that refactoring should be considered a design process and not just a clean-up click, and that most interesting refactorings are not necessarily automated.

Gefühlt stand das Akronym WWW lange Zeit eher für Wild Wild West statt World Wide Web. Architekturmuster und klare Software-Design-Prinzipien waren oft eher die Ausnahme als die Regel.

Neuere Technologien führen aber nicht automatisch zu einer besseren Architektur. Es gilt, nach wie vor, Architekturmuster bewusst und gezielt einzusetzen. Eines der bekanntesten Muster im Domain-Driven Design ist die "Hexagonale Architektur".

In diesem Workshop lernen Sie, wann sich der Einsatz lohnt, und wie Sie es in der Praxis umsetzen.

Maximale Teilnehmendenzahl: 20. Benötigt wird ein Laptop.

Zielpublikum: Architekt:innen, Frontend-Entwickler:innen
Voraussetzungen: Frontend-Erfahrung: JavaScript, TypeScript, React
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Gefühlt stand das Akronym WWW lange Zeit eher für Wild Wild West statt World Wide Web. Architekturmuster und klare Software-Design-Prinzipien waren oft eher die Ausnahme als die Regel. Erst mit der letzten großen Framework-Welle dieses Jahrzehnts und dem Siegeszug von SPAs begann ein längst notwendiges Umdenken.

Neuere Technologien führen aber nicht automatisch zu einer besseren Architektur. Es gilt, nach wie vor, Architekturmuster bewusst und gezielt einzusetzen. Eines der bekanntesten Muster im Domain-Driven Design ist die "Hexagonale Architektur". Sie lernen:

• wann sich der Einsatz lohnt,
• wie sich das Muster von anderen (z. B. Onion-Architektur) abgrenzt
• und wie Sie es in der Praxis umsetzen.

"The Leader must be [X]" is one of the most common sentences we read about leadership. But not all leaders are the same and when working with people context is king!

In this session we will instead analyse the metaphor of Host Leadership: a context-friendly and non-prescriptive way to frame how leadership in an organisation could work. It reuses many of the cultural elements of hosting, thus making it very intuitive and generative!

We will also look at and experiment with practical applications of the idea!

Target Audience: Manager, Leaders, Scrum Master, Agile Coaches
Prerequisites: Experience in a leadership role is a plus, though not required
Level: Basic

Additional Information:
Host Leadership is an idea by Mark McKergow, who analysed the tension between heroic and servant leadership and proposed that an actual effective leadership has elements of both: sometimes hero and sometimes servant. And always adapting according to the context.

When the Agile movement began, it started with the term “lightweight processes”. Lean was closely interwoven with some of the approaches and very often referred to in the general discussion – nowadays you hardly ever read about it.

If you really want to use “Agile” approaches for more than just pushing notes over the wall, or holding meetings as ceremonies, a look at Lean is not only helpful, but actually inevitable which we will present in this talk. We’ll also put them in the context of currently fashionable approaches.

Target Audience: All kinds of change agents – either by choice or by chance.
Prerequisites: Some working knowledge of agile software development techniques and practices
Level: Advanced 

Extended Abstract:
When the Agile movement began, it started with the term “lightweight processes”. Lean was closely interwoven with some of the approaches and very often referred to in the general discussion – nowadays you hardly ever read about it.

If you really want to use “Agile” approaches for more than just pushing notes over the wall, or holding meetings as ceremonies, a look at Lean is not only helpful, but actually inevitable. Straight from “ Lean“ come many approaches that are helpful in the agile realm like:

• Visual Management (as an approach to empowerment),
• the Improvement Kata (as a leadership method),
• the Jidoka concept (as an approach to deal with automation),
• and many other ideas for change and organization,

which we will present in this talk. We’ll also put them in the context of currently fashionable approaches (like the Kanban method, Scrum, SAFe, etc.).

Anwendungsentwicklung in der Praxis skalierbar zu machen, ist eine wichtige Voraussetzung für die zügige digitale Transformation von Unternehmen. Im Vortrag erläutert Menno Odijk, CTO von Mendix, warum Low-Code für die Entwicklung von Unternehmensanwendungen prädestiniert ist und wie die Low-Code-Plattform von Mendix den dringendsten Herausforderungen bei der App-Entwicklung, auch in Multi-Cloud-Szenarien begegnet: Sei es durch Collaboration in sogenannten Fusion Teams, die die Expertise von IT und Fachabteilungen bündeln – oder durch verkürzte Entwicklungszyklen, die den Workload für Entwicklerteams deutlich reduzieren. Ergänzend wird zudem auf den Trend zum Composable Enterprise eingegangen und wie Low-Code den Composability-Ansatz befeuert. 
 
Michael Lamprecht, Leiter Service Process Operations bei DATEV, dem drittgrößten Anbieter für Business-Software in Deutschland, wird exklusive Einblicke aus der Praxis liefern. Er teilt die Erfahrungen von DATEV mit der Low-Code-Plattform von Mendix und wie diese seinem Unternehmen geholfen hat, die Kundenbindung zu verbessern, indem beispielsweise repetitive Aufgaben automatisiert und verschiedene Systeme nahtlos integriert wurden. Gespannt sein darf man auch auf eine Sneak-Peak zu spannenden neuen Applikationen, die DATEV für den weiteren Verlauf des Jahres geplant hat und die aufzeigen, in welchen Bereichen Low-Code seine Stärken ausspielen kann – für mehr Agilität, eine gestärkte IT-Landschaft, nachhaltiges Wachstum und mehr Innovationsfähigkeit. 

In den letzten 30 Jahren habe ich viel Software selbst oder mit Teams entwickelt und viele Softwaresysteme analysiert, um die darin angesammelten technischen Schulden zu analysieren und Lösungen zu erarbeiten. Dabei bin ich immer wieder ähnlichen Missverständnissen rund um das Thema Software-Architektur begegnet. In diesem Vortrag werde ich erklären, welche Missverständnisse das sind und warum sie anders gedacht werden müssen, damit wir mit unseren Software-Architekturen kleine und große Probleme lösen können.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider:innen, alle!
Voraussetzungen: Erfahrung aus Software-Entwicklungsprojekten
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
In Beratungs- und Schulungssituationen habe ich immer wieder mit Kunden zu tun, die irgendein Architekturkonzept gelernt oder gelesen und vielleicht sogar selbst in ihre Software eingebaut haben, es aber aus meiner Sicht falsch verwenden/verstehen. Diese Erkenntnis taucht meist erst nach einer eingehenden Diskussion auf. Zuerst denken alle, wir meinen das Gleiche.

Meine aktuellen Highlights sind:

• Microservice-Architekturen sind dasselbe wie Service-orientierte Architekturen (SOA)
• Wenn man Events einsetzt, dann hat man eine lose gekoppelte Architektur
• Wiederverwendung steht über allen anderen Konzepten
• Zyklen sollte man durch den Einsatz von Interfaces auflösen
• Neubau ist besser als Refactoring
• Jedes Team sollte seine eigene Technologie frei wählen
• Sourcecode reicht als Dokumentation aus

Es kommen immer wieder neue Missverständnisse hinzu – so dass zum Zeitpunkt der Konferenz durchaus einige Missverständnisse erneuert sind.

Je nach Länge variiere ich die vorgestellten Missverständnisse.

Wie man eine Produktentwicklungsorganisation aufbaut, die sich durch die Weiterentwicklung und Förderung ihrer Talente auszeichnet, um ein leistungsstarkes Unternehmen zu werden.

Bist du bereits eine 10-Sterne-Expertin in vue.js (oder Flutter oder Typoskript)? Oder kämpfst du noch mit Level 2? Und was hat dein Unternehmen für deine Entwicklung getan?

Unternehmen sind großartig darin, den Unternehmenserfolg sicherzustellen. Jedoch wird die Entwicklung von Menschen oft nicht richtig bedacht und umgesetzt. Zusammen mit Experten aus verschiedenen Unternehmen begannen wir zu beschreiben, wie Experten und Wissen in einer Kultur der Expertenarbeit wachsen können. Das fing bei Tchibo an. Wir sprechen über Skills, Skill-Levels, Personalentwicklungspfade und Gehälter.    
Mehr Open-Souce auf github: https://kommitment.github.io/engineering-excellency/ 

A recipe for collaborative product ownership: Finding solutions to business problems that are feasible and sustainable.

Target Audience: Product Owners, Manager, Project Leader, Architects
Prerequisites: None
Level: Basic

Extended Abstract:
How do you translate Objectives and key results (OKR) back to a hypothesis that can be challenged by the various roles within a team? How do you ensure that the communication around initiatives is not hindered by conflicting terminology or by misinterpretation? In what ways can you involve business stakeholders in finding solutions that will help them understand the technical constraints that a team has to take into account? And how do you prevent tech teams building the wrong thing the right way?

**Imagine:**

- a way to visualize and clarify to the relationships between OKRs, hypothesis and the underlying technical constraints within the technical real-estate;

- a clear path from "user need" to the responsible "components";

- having a common language to talk about problems in context, removing ambiguity and confusion in the process;

- and finally, a way to collaboratively dive into the nitty gritty detail of the current landscape and the proposed solution;

In this session Marijn Huizendveld will take you through the process of leveraging your existing OKRs to clarify what needs to be done to all stakeholders and members of a team.

Um den Projektalltag zu durchbrechen, braucht es manchmal frische Ideen. Orientieren kann man sich dabei an Kontexten, die erst einmal nichts mit der Software-Entwicklung zu tun haben. Spielerische Ansätze steigern die Motivation, gemeinsame Erlebnisse wie ein Buchclub zur Weiterbildung den Teamzusammenhalt. Wir stellen einige Ideen vor und geben den Teams gute Argumente in die Hand, warum sich Spaß im Projekt auch für die Projektleitung und die Organisation auszahlt.

Zielpublikum: Entwickler:innen, Tester:innen, Projektleiter:innen, Scrum Master
Voraussetzungen: Projekterfahrung, Grundkenntnisse agiler Methoden
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Wenn in das Projekt der Alltag einzieht, unbeliebte Aufgaben liegenbleiben und die Weiterentwicklung des Teams leidet, braucht es frische Ideen. Warum nicht einmal einige Gamification-Techniken ausprobieren? Oder einen Buchclub gründen, um die lange geplante, aber immer wieder verschobene Fortbildung in Eigenregie in Angriff zu nehmen?

Doch wie schafft man es, aus dem Team heraus neue Ideen zu generieren und in das Team hinein solche Ideen zu tragen? Der Vortrag zeigt dazu Wege auf und schlägt Techniken vor, die den Alltag auflockern können. Denn Spaß im Projekt, gezielt eingesetzt, stärkt nicht nur den Teamzusammenhalt, sondern bringt das Team auch auf anderen Ebenen weiter – fachlich, menschlich, kreativ. Das erhöht die Mitarbeiterzufriedenheit, die Identifikation mit Projektzielen und letztlich die Mitarbeiterbindung.

Moderne Softwarearchitekturen werden immer komplexer und auch die Art, wie Software entwickelt wird, ändert sich ständig. Hat man in der Vergangenheit noch große monolithische Anwendungen entworfen und mit mehreren hundert Entwicklern über einen langen Zeitraum hinweg entwickelt, so bestehen moderne Architekturen heute aus vielen "kleinen" Microservices, die mit kleinen Teams in kurzen Iterationen entwickelt werden. Da stellen sich in Bezug auf die Architekturarbeit folgende Fragen, die in dem Vortrag aufgegriffen und diskutiert werden sollen:

• Was sind die Herausforderungen bei aktuellen Softwarearchitekturen?
• Was bedeutet Architekturarbeit heute?

• Brauchen wir dedizierte Softwarearchitekten, oder ist die Architekturverantwortung nicht in den Teams besser aufgehoben?

• Wer behalt denn den Überblick über die Geschäftsarchitektur?
• Wie wird Architekturwissen weitergegeben?

Copy & Paste ist seit Jahrzehnten als Code-Smell verschrien. Trotzdem kommen in allen größeren Systemen viele Klone vor. Das schafft Probleme.

Clone Detection – die automatisierte Erkennung solcher Duplikate – ist inzwischen in vielen IDEs enthalten. Allerdings nützt es wenig, eine Liste mit 100k Klonen zu erzeugen. Die Herausforderung ist der sinnvolle Umgang mit bestehenden Klonen. Im Vortrag stelle ich Clone Detection und Management-Techniken vor. Außerdem zeige ich, wie man als Architekt eine Bestandsaufnahme im eigenen System machen kann.

Zielpublikum: Architekt:innen und Entwickler:innen
Voraussetzungen: Grundlegende Programmiererfahrung.
Schwierigkeitsgrad: Anfänger 

Extended Abstract:
Copy & Paste-Programmierung ist seit Jahrzehnten als Code-Smell verschrien. Das hat nicht verhindert, dass quasi in allen größeren Systemen viele durch Copy & Paste entstandene Klone vorkommen. In einigen Systemen kommt mehr als die Hälfte aller Zeilen in Kopie an anderen Stellen auch vor. Das schafft in der Weiterentwicklung viele Probleme, da Änderungen an mehreren Stellen durchgeführt werden müssen, Code-Reviews aufwändiger werden, Fehler oft bei Fixes in Kopien übersehen werden etc.

Clone Detection, also statische Code-Analyse, die solche Duplikate automatisiert erkennen kann, ist inzwischen in einigen IDEs enthalten. Allerdings zeigt die Erfahrung, dass es wenig nützt, eine Liste mit 100.000 Klonen zu erzeugen.

Die Herausforderung ist nicht das Finden, sondern Clone-Management: der sinnvolle Umgang mit existierenden Klonen.

Welcher Umgang mit Klonen der richtige ist, hängt vom eigenen Kontext ab: Wie viel Copy & Paste-Programmierung kommt im eigenen System vor, und wie wirkt sich das auf die Kosten aus? Welche Fehler wurden nicht in allen Kopien behoben? Gibt es "Copy & Paste im Großen" zwischen verschiedenen Anwendungen in der Unternehmensarchitektur? Welche Klone sollten wir in wiederverwendbare Module/Bibliotheken herausziehen, bei welchen lohnt es nicht? In welchen Bereichen wollen wir Duplikation eventuell bewusst, um z. B. Microservices unabhängig voneinander weiterentwickeln zu können? Und wie stellen wir dabei sicher, dass wir Fehler in Kopien trotzdem konsistent beheben?

Im Vortrag stelle ich Clone Detection und Management-Techniken vor. Ich zeige Kostenmodelle, um die Kosten von Klonen zu quantifizieren, und gehe auf Erfahrungen ein, die wir mit Clone-Management in den letzten 10 Jahren bei verschiedenen Kunden gesammelt haben. Außerdem zeige ich, wie man eine Bestandsaufnahme im eigenen System machen kann, um diese Fragen als Architekt für das eigene System oder die eigene Anwendungslandschaft zu beantworten.

Bei den Themen Authentifizierung und Autorisierung geht heute kein Weg mehr an OAuth2, OpenIDConnect (OIDC) und JWT (JSON-Web-Token) vorbei. Viele verschiedene "Flows", "Grants" und weitere neue Wörter inklusive. Doch wie funktioniert das eigentlich, was bedeutet das und wie kann ich das in meine Architektur integrieren? Viele Entwickler:innen und Architekt:innen haben hier Fragen.

Ich möchte in meiner Session mehr Licht ins Dunkel der Begriffe und Arbeitsweisen bringen und erkläre anhand eines einfachen Beispiels, wie das alles funktioniert.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Alignment ist der aktuelle Hype. Alle sollen an einem Strang ziehen. So wichtig das Thema ist, so oberflächlich und voller Plattitüden wird es diskutiert.

Den Beteiligten muss klar sein, was erreicht werden soll. Das und wie man das tut, ist seit mindestens 1954 bekannt. Allerdings entsteht das Alignment, das wir meinen, nur, wenn die Menschen im Unternehmen wissen, was sie tun müssen, ohne ständig alles Mögliche abstimmen und koordinieren zu müssen.

Mission Command und OKRs sind Ansätze, um genau das zu erreichen.

Zielpublikum: Manager, Entscheider:innen, Product Owner, Scrum Master, Projektleiter:innen
Voraussetzungen: Grundkenntnisse Agilität
Schwierigkeitsgrad: Anfänger 

Extended Abstract:
Alignment ist der aktuelle Hype. Alle sollen an einem Strang ziehen. So wichtig das Thema ist, so oberflächlich und voller Plattitüden wird es diskutiert.

Offensichtlich muss den Beteiligten klar sein, was erreicht werden soll. Das und wie man das tut, ist seit mindestens 1954 bekannt. Es reicht offensichtlich nicht aus. Schließlich entsteht das Alignment, das wir meinen, nur, wenn die Menschen im Unternehmen wissen, was sie tun müssen, ohne ständig alles Mögliche mit allen möglichen Leuten abstimmen und koordinieren zu müssen.

Die Alignment-Mechanismen reichen von der Rücknahme agiler Arbeitsweisen über OKRs (Objectives and Key Results) bis hin zu Anleihen aus der Militärtaktik wie z. B. Mission Command. Der Vortrag betrachtet verschiedene Methoden in der historischen Entwicklung und vergleicht einzelne Ansätze kritisch bzgl. ihrer Eignung.

Anschließend stellt er wiederkehrende Muster für die erfolgreiche Umsetzung in der Praxis vor.

Nach dem Vortrag kennen die Teilnehmenden die wichtigsten Konzepte zum Thema Alignment & Autonomie und können so fundiert entscheiden, welcher Ansatz in ihrem Kontext besonders nützlich sein kann.

AI is being used every day to power sustainability efforts. We will look at a few areas where we have direct experience working with agriculture, oil and gas, and transportation companies to reduce their carbon footprint and their energy consumption, as well as their risk of systemic failure. We will also talk about the inherent risks of using AI in the sustainability domain, where human-machine interactions are the strongest. We will review some Responsible AI best practices that we have used.

Target Audience: Architects, Developers, Project Leader, Manager, Decision Makers
Prerequisites: None
Level: Advanced 

Die DB AG beschäftigt sich seit 2019 mit Quantentechnologien zur Optimierung ihrer Assets (Schiene, Zug, Personal, Energie) und den Auswirkungen auf die Security. In Konsortien mit Forschungseinrichtungen erfolgt ein Realitätscheck, in dem Implementierungen auf Digital Annealern durchgeführt werden. Der praktische Umgang mit der Technologie steht im Vordergrund. Es werden aktuelle Use Cases ebenso vorgestellt wie auch Herausforderungen, die sich durch die Technologie ergeben. Eine Übersicht des Quantencomputing-Ökosystems rundet das Bild ab.

Zielpublikum: Architekt:innen, Projektleiter:innen, Manager, Entscheider:innen
Voraussetzungen: Keine speziellen IT-Kenntnisse
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Der kommerzielle Einsatz von Quantencomputern wird von den Software- und Hardwareherstellern seit kurzem angeboten. Die Technologie verspricht einen großen Nutzen bspw. in der Materialforschung und in der Optimierung. Auf der anderen Seite birgt die Technologie Risiken für die IT und OT, da Verschlüsselungsmechanismen bei ausreichender Größe und Stabilität der Quantensystem gebrochene werden können. Für die Unternehmen ist die Annäherung an das Thema eine Herausforderung, da (noch) wenige Experten die Anwendungsmöglichkeiten, die Risiken und die Anbieterlandschaft erfassen. In dem Vortrag werden den Zuhörern Mittel an die Hand zu geben, sich mit der Technologie frühzeitig auseinanderzusetzen, in den Unternehmen zum Einsatz zu bringen und sich auch abzusichern. So ist in Europa ein Ökosystem aus mehr als 160 Unternehmen vom Startup bis hin zu Konzernen entstanden, das sich in Allianzen und Kooperationen weltweit austauscht.

Künstliche Intelligenz ist auf dem Vormarsch. Egal ob Qualitätssicherung in der Produktion, Retourenmanagement im Online-Handel oder Customer-Support via Chatbot: KI eröffnet bisher noch nicht dagewesene Möglichkeiten, die eigenen Prozesse und Geschäftsmodelle deutlich zu verbessern. Aber wie lässt sich KI in die eigene Software-Architektur integrieren? Wer befindet über das richtige Modell und den richtigen Algorithmus? Und wie wird über die hinreichende Quantität/Qualität von Daten entschieden? Die Rolle des KI-Architekten scheint geboren.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Die Session veranschaulicht die verschiedenen Herausforderungen, die sich durch das Einbinden von KI für die eigene Software-Entwicklung ergeben können, und zeigt dafür passende, pragmatische Lösungsansätze auf.

Angefangen bei der fachlichen und qualitativen Analyse der vorliegenden Daten, über die eigentliche Modellierung und das Training der KI, bis hin zur Bereitstellung in Produktion in Form eines Web-Service, zeige ich Schritt für Schritt an einem durchgehenden Beispiel, wie KI in bestehende Software-Landschaften integriert werden kann. 

Agility is vital for any organization that doesn’t want just to adopt the Agile terminology but start changing itself, its core, and its way of thinking and operating.

With our thinking tool, the Adaptivity Map, we have discovered different topologies of organizational design. The org topologies are created in the context of a perfection goal of full adaptivity. By doing this, we discovered the organizational changes and paradigm shifts required to move from one type to another.

Target Audience: CEO, Agile Coaches, Project Leader, Manager, Decision Makers
Prerequisites: Basic knowledge of agile frameworks
Level: Advanced

Extended Abstract:
Many organizations struggle to adopt "agile" in a way that delivers on its promise to make the company fast, flexible and efficient. Global consultancy firms have great pitches on how to adopt different so-called “Agile frameworks”. The marketing is great, but are the results too? We see how our clients get stuck in adopting a framework – forming “agile teams”, appointing “product owners” and then clustering all this into “tribes”. Thus creating robust structures that make further organizational improvements and adaptability difficult, slow, and expensive.

For more details visit www.orgtopologies.com

Key Outcome:

In this session, the participants will receive a hands-on thinking tool – Adaptivity Map, that allows participants to design a tailored, long-lasting roadmap to grow their organization's adaptivity towards perfection.

Description:

We believe that every organization needs to discover its own Agile adoption goal, and then lay down a path to it. Agility is vital for any organization that doesn’t want just to adopt the Agile terminology but start changing itself, its core, and its way of thinking and operating.

With our thinking tool, the Adaptivity Map, we have discovered different topologies of organizational design. The org topologies are created in the context of a perfection goal of full adaptivity. By doing this, we discovered the organizational changes and paradigm shifts required to move from one type to another.

This session:

In this session, we propose a context-driven approach to find the level of adaptivity that fits in your organization. You will learn a new way of looking at organizational transformation towards high adaptivity. We will offer a realistic palette of corporate transformation strategies using archetypical organization topologies.

Decision-makers attending this session will get familiar with this model and will be able to evaluate their ongoing Agile adoption (if any). They will be able to see their next horizon, and understand what options are available and what difficulties need to be overcome. Attendees will be able to assess their Agile transformation roadmap.

Participants of this session will learn:

• Understand how Agile adoptions are a journey and the adoption of any scaling framework is not an end-state.
• Understand the prevalent org topologies (archetypes of Agile organization design) and what a starting point of minimal agility is.
• Identify which org topology matches their current Agile adoption.
• Learn how to navigate Agile transformations using the Adaptivity Map to improve the Agile adoption journey.
• Learn to see the organizational changes and paradigm shifts that are required to navigate towards a more adaptive organization.

Can you relate to that ambiguous desire to “actually DO something” while – at the very same time – feeling an irresistible urge to “just hide under a blanket until 'this' all is over”?

I can!

In uncertainty, we humans all too often oscillate somewhere between ‘numbing’ and ‘over-action’. Yet, crises always bear something new, something that wants to be uncovered and tended – besides all the easily visible “unwanted” things.

Join us, in (my) search of sustain-ability.

But: be prepared to be surprised.

Target Audience: All curious human beings (including Developers, Architects, Managers, Project Leads)
Prerequisites: Curiosity and openness for different ways of thinking (and behaviour)
Level: Advanced

Extended Abstract:

Oh crap! Another crisis!

Or at least: another challenging, changing situation.

What can I do? What can WE do – as change supporters, as leaders, as human beings in business?

"What can I do?" is one question I asked myself A LOT of times “just for work” with teams in organisations. Now in times of pandemic, wars & climate change this question got a whole different scope and magnitude for many of us beyond work contexts.

I will take you on a little journey, sharing some of my own experiences… what worked, what didn’t… and most important: what I learned in times of crises.

You will leave that session with digestible psychological science (around Relational Frame Theory (RFT), S. Hayes et al) and most important: with tangible tools to try out yourself. At work and beyond.

More information about the keynote will follow shortly.

Viele Firmen kämpfen mit dem optimalen "Flow" in der Software-Entwicklung. Abhängigkeiten und Übergaben zwischen Teams sorgen für lange Zeiträume zwischen Idee und Auslieferung an den Kunden. Im Kontext von DDD und Microservices herrscht oft Unsicherheit, wie Services und Teams "richtig" zu organisieren sind.

In diesem Workshop stellen wir Team Topologies vor. Die vorgestellten Topologien, Formen der Zusammenarbeit und Prinzipien hinter dem Modell können Teilnehmer:innen praktisch anwenden und auf ihren eigenen Kontext anwenden.

Zielpublikum: Entwickler:innen, Architekt:innen, Manager, Agile Coaches
Voraussetzungen: Projekterfahrung als Teammitglied
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Dieser Workshop besteht aus einer kurzen Einführung in die Probleme, die Team Topologies löst: Abhängigkeiten, Teamschnitt nach Expertise, traditionelle Hierarchien, Conway's Law und das daraus resultierende sozio-technologische System.

Danach gehen wir auf die Topologien und Interaction Modes von Team Topologies ein und zeigen auf, welche Konsequenzen diese in unterschiedlicher Zusammensetzung haben können.

Im dritten Schritt geht es dann für die Teilnehmer:innen ans Eingemachte: Individuell und in kleinen Gruppen werden die eigenen Team-Topologien sichtbar gemacht und gemeinsam diskutiert, welche Probleme daraus entstehen und aktuell wirken.

Zuletzt darf jede:r Teilnehmer:in sich an einer inkrementellen Verbesserung probieren, die im Nachgang an den Workshop in der eigenen Organisation als Impuls verwendet werden kann.

Zunehmend vermögen selbst ressourcenarme Mikrocontroller ML-Inferenz durchzuführen, was zu einem Mehrwert von IoT-Produkten & -Lösungen führt. Wie funktioniert das und wie lässt sich dabei systematisch vorgehen?

Der Deep Dive leitet die Teilnehmer anhand von Präsentationen und praktischen Übungen von den Grundlagen von ML bis hin zu eingebetteten Systemen mit integrierter ML-Funktionalität. Als Mittel dienen die MLOps-Plattform Edge Impulse und eine darauf unterstützte eingebettete Hardware. Das Tutorium basiert auf Konzepten des Edutainments.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Erfahrung in Software-Entwicklung, C/C++ & Python-Grundlagen
Schwierigkeitsgrad: Anfänger

Extended Abstract:

Zunehmend vermögen selbst schmalbrüstige Mikrocontroller ML-Inferenz durchzuführen, was zu einem Mehrwert von Produkten und Lösungen führt. Während die Inferenz sogar auf Mikrocontrollern stattfinden kann, braucht es für das Training von neuronalen Netzen immer noch leistungsfähige Server.

Doch wie funktioniert das und wie lässt sich dabei systematisch vorgehen? Was sind die dafür notwendigen Schritte und Werkzeuge? Worauf ist zu achten?

Der Deep Dive leitet die Teilnehmer anhand von Präsentationen und praktischen, selbstständigen Übungen von den Grundlagen von ML bis hin zu eingebetteten Systemen mit integrierter ML-Funktionalität. Als Mittel der Wahl dienen die MLOps-Plattform Edge Impulse und eine darauf unterstützte eingebettete Hardware.

Zur Sprache kommen dabei auch Integrationsaspekte.

Das Tutorium basiert auf Konzepten des Edutainments.

Lernziele sind dabei:

• Vermitteln von Grundkenntnissen über ML
• Praktisches Verständnis der Möglichkeiten und Grenzen von ML auf eingebetteten Systemen
• Kennenlernen von MLOPs und Teilaspekten von Model Governance

This talk is inspired by the BOSSA nova book from Jutta Eckstein and John Buck on company-wide agility, based on Beyond Budgeting, Open Space, Sociocracy and Agile.

This workshop gives a short introduction to BOSSA nova, but is mainly very interactive, supported by Liberating Structures. It helps the participants to identify and refine their biggest challenges in the agile transformation in their organization and provides a structure in which they can create and improve an experiment that they can start with when back in office.

Target Audience: Agile Coaches, Scrum Masters, Leaders, Managers
Prerequisites: None
Level: Advanced

Extended Abstract:
In the VUCA world that we are in, companies are expected to be flexible and both rapidly responsive and resilient to change, which basically asks them to be agile.

But, the agile toolbox is not enough to cover all aspects that create a true agile organization.

We do a brief overview of the additional principles and practices of Beyond Budgeting, Open Space and Sociocracy that Jutta Eckstein and John Buck added to Agile in their book BOSSA nova on company-wide agility. What is it, why is it needed and how it does fit in.

Participants will be engaged and supported to identify their biggest impediments in their agile transformation. From there participants will learn how to cope with these impediments by setting up an experiment to validate a small change, inspired by the BOSSA nova toolbox.

Participants will help each other to refine and improve their safe to fail experiment that they can start running when back in office.

Is your organization perfect? Or do you wish some things could be different? You may be stuck – so you scratch your head, brainstorm a bit, and grumble a bit more. This session will help you get unstuck. You will be introduced to Fearless Change strategies and participate in a Fearless Journey game that can help you and your team begin to move from the present situation to where you want to be. Get ready for some fun and you'll take away some strategies you can start to use on Monday morning!

Target Audience: Anyone who sees problems in their organization and would like to help make change happen
Prerequisites: A desire to learn (and have some fun while you do)
Level: Basic

Extended Abstract:

This workshop is for anyone who wants to learn how to start to make change happen, even if it's as big as increasing sustainability in your organization. As an attendee you will:

• Learn some strategies you can use to begin to get people so interested and involved that they want to change
• Participate in a "game" that will help you begin to get from the present situation to where you want to be
• Take away change leadership strategies you can begin to use right away

More information about the keynote will follow shortly.

Überall werden Architekturprinzipien publiziert, die diesen oder jenen Vorteil haben.

Immer wieder gibt es Success-Storys, wie gut z. B. ein System skalierbar ist.

Aber mal ehrlich, jeder kennt auch negative Beispiele.

Genau darüber soll in diesem Talk gesprochen werden – mit Euch!

• Welche Beispiele von Fallstricken kennt ihr?
• Wie wird man sie wieder los?
• Hätte man vorher die Probleme erkennen können?

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider:innen
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten 

Extended Abstract:
Während die Literatur über Software-Engineering geradezu von Positivbeispielen erfolgreicher Software-Architekturen strotzt, kennen Software-Architekturen auch einige Probleme oder sogar Fehlschläge. Nicht immer wählen Architekten die richtigen Entscheidungen, nicht immer existiert ein idealer Projektkontext. Wir leben und agieren in einer nicht perfekten Welt. Bei einer Retrospektive erkennen Architekten oft, was sie hätten anders machen sollen. Jeder kann ein Liedchen davon singen. In einem Fish-Bowl-Setting erhalten Teilnehmer die Gelegenheit, aus dem Nähkästchen zu plaudern. Welche Fehler kennen sie und was hätte anders laufen sollen. Stichwort: Aus Fehlern lernen. Dadurch sollte es zu einigen Déjà-vus kommen. Ziele sind ein geschärfter Blick der Teilnehmer und ein Lernen von anderen.

In Anwendungen, die Machine Learning-Komponenten enthalten, müssen bereits in der Entwicklung eine Metrik zur Überwachung, besondere Qualitätsmerkmale wie Erklärbarkeit und Fairness und ebenso die ständige Weiterentwicklung mitgedacht werden. 

Das beschert derartigen Anwendungen eine besondere Position im Bereich des DevOps und mit MLOps entsteht eine eigenständige Sparte. 

In diesem Talk gehe ich auf die besonderen Anforderungen im Betrieb ein und welche Auswirkungen diese auf die Entwicklung haben. 

Zielpublikum: Architekt:innen und Entwickler:innen 
Voraussetzungen: Ein Grundverständnis von DevOps ist notwendig, ein Verständnis von ML ist hilfreich 
Schwierigkeitsgrad: Fortgeschritten 

 Extended Abstract: 
Bei klassischer Software-Entwicklung wird Business-Logik anhand von Regeln von Software-Entwicklern kodiert. Diese Regeln sind entweder unmittelbar gegeben (z. B. Gesetzestexte) oder entstehen durch die Analyse einer Domäne in Form von Anforderungen. 

Machine Learning-Modelle basieren dagegen nicht auf expliziten Regeln, sondern werden durch für die Domäne repräsentative Daten trainiert. Das Herausarbeiten von Regeln übernimmt hier also auch die Maschine und nicht der Mensch. Da die Welt und die meisten Domänen nicht stillstehen, ist dies allerdings ein dynamischer Prozess. Ein Modell kann selten einmal trainiert werden und dann über längere Zeit in Produktion gehalten werden. 

Dies erfordert bereits in der Entwicklungsphase eine Metrik, mit der man bestimmen kann, wie gut ein solches Modell noch auf die Realität passt. Zudem muss für viele Anwendungen die Erklärbarkeit gewährleistet und auch in Produktion geliefert werden. 

Im Bereich von Teams bedeutet das die Einführung weiterer Rollen und eine neue Form von Zusammenarbeit zwischen diesen. 

Was MLOps umfasst, ist bisher nicht geschlossen festgelegt, sondern eher definiert darüber, was man braucht, um Machine Learning-Modelle in Produktion zu bringen und dort erfolgreich zu halten. Mit Sicherheit müssen wir über die Integration in bestehende Software, die Aufteilung in Services und das Monitoring sprechen. 

Diese Session beschränkt sich nicht auf die Konzepte, sondern demonstriert diese anhand einer durchgängigen Anwendung. 

Many have suggested using DDD to help define the functional scope of microservices. But how to apply this idea in practice is not clear to everyone. This talk will cover basic DDD concepts, and we'll discuss why and how DDD can help to create microservices with better autonomy, scalability, and reliability. Using examples, we'll navigate from a domain model to the design of both synchronous (REST-based) and asynchronous (reactive) microservices.

Target Audience: Architects, Developers, PM's, QA
Prerequisites: Understanding of Microservices and DDD is useful
Level: Advanced

Extended Abstract:
Many have suggested that DDD modeling techniques can help define the functional scope of microservices. But how to apply this idea *in practice* is not clear to everyone. DDD is NOT an approach to microservice design. However, DDD can help with some aspects of microservice design. DDD has had a resurgence with the advent of Microservices, specifically as it can help you design the right-sized microservices modeled around the domain.

This talk will examine how to take the results of domain modeling (specifically Domain-Driven Design) and map them to a microservices implementation for systems with better availability, scalability, reliability, and modifiability. This will include examples for the design of both synchronous (REST-based) and asynchronous (reactive) microservices. I will also explore various microservice design scenarios around DDD concepts such as aggregates (with entities and value objects), bounded contexts, domain events, anti-corruption layer, and various strategies for Bounded Context interactions.

Das Krümelmonster? Neulich sah ich einen kurzen Ausschnitt aus der Sesamstraße und das Krümelmonster versuchte, in einer Bibliothek Kekse zu bekommen. Ich hatte dabei ein Déjà-Vu… mir kamen die Argumentation und die Situation merkwürdig vertraut vor… Diese Type kannte ich und in der Regel heißt das für das Zusammenspiel im Spannungsfeld PO und GF nichts Gutes für die digitale Transition. Aber wie geht es richtig? Lasst es uns zusammen mit dem Krümelmonster in dieser interaktiven Session herausbekommen! Eure Erfahrungen sind gefragt!

Zielpublikum: Manager, Team- und Abteilungsleiter:innen, Entscheider:innen, Product Owner, Interessierte, Krümelmonsterfans
Voraussetzungen: Erfahrungen aus in einer agilen Transition, Digitalisierung wünschenswert, aber nicht zwingend
Schwierigkeitsgrad: Fortgeschritten 

Extended Abstract:
Warum das Krümelmonster? Ich habe neulich einen kurzen Ausschnitt aus der Sesamstraße gesehen (der ist natürlich Teil dieser Session…) und das Krümelmonster versuchte, in einer Bibliothek Kekse zu bekommen. Und der immer verzweifeltere Bibliothekar versuchte händeringend, dem Krümelmonster zu erklären, warum es in der Bibliothek nun mal Bücher gibt und was man da alles Schönes mit machen kann…

Ich hatte dabei ein Déjà-Vu… mir kamen diese Argumentation und diese Situation merkwürdig vertraut vor…

Ich habe einige Coachings von agilen Teams und agilen Transitionen und Digitalisierungsprojekten hinter mir, habe die Digitalisierung im eigenen Unternehmen versucht und bei anderen geholfen.

Und da gibt es einiges zu berichten, aus meiner eigenen Erfahrung und der meiner Kolleginnen und Kollegen. Da gibt es auch das Krümelmonster als PO, Stakeholder oder Geschäftsführer, uneinsichtig, nichts verstehend oder sehr gut verstehend, aber viel zu meinungsstark für das Team. Am Ende ist das Ergebnis eher suboptimal oder die mühsam geplante Digitalisierungsstrategie ist gescheitert, ...

Oder das Krümelmonster hat alle leckeren Zutaten aufgefuttert und erwartet trotzdem tolle Kekse.

Da könnt ihr doch ein bisschen kreativ sein, oder?

Wieso sind Eure agilen Prozesse so starr? Ich dachte Agilität bedeutet Flexibilität, Anpassen an neue Situationen, da kann man doch mal den Prozess anpassen, oder?

Wir releasen jetzt jede Woche, auch wenn der Sprint drei Wochen lang ist – wo ist das Problem?

Wie sieht das denn aus in der Zusammenarbeit zwischen Produktmanagement und Unternehmensleitung, wenn auf die innovativen Produkte gewartet wird, aber bitte die bisherigen Produkte auf keinen Fall vernachlässigt werden dürfen – damit verdienen wir schließlich unser Geld.

Seid doch mal ein bisschen innovativ...!

Wie seht ihr das? Was sind Eure Erfahrungen? Wie geht ihr mit dem „Krümelmonster-PO“ oder dem "Krümelmonster-Geschäftsführer" um?

Diese interaktive und nicht immer ganz ernste Session lebt von Eurem Feedback und ich möchte mit Euch und Euren Erfahrungen gemeinsam „Best Practices“ zur Zusammenarbeit im Spannungsfeld von Produktentwicklung (PO) und Unternehmensleitung erarbeiten.

Was ist unverzichtbar, worüber kann man diskutieren und wie geht man am besten mit den Störungen des Prozesses um?

Diese Session wird zum größten Teil aus gemeinsamer Gruppenarbeit bestehen, immer wieder unterbrochen durch ganz kurze Impulsvorträge, Zwischenrufe, Provokationen zum Thema.

Das Krümelmonster wird natürlich auch live mit dabei sein... :)

In jedem größeren Unternehmen gibt es Bestandssoftware, die über viele Jahre gewachsen ist. Deren Technologie ist oft veraltet, über die Jahre ist ein Monolith entstanden, der immer schwerer wartbar wird.

In dieser Session wird an einem Projekt aus der Praxis gezeigt, wie man es schaffen kann so einen Monolithen schrittweise auf den aktuellen Stand der Technik zu bringen. Dabei wird das Wissen und die Erfahrung der ""Alten"" gepaart mit neuen Technologien, Best Practices und Vorgehensweisen.

Auf diese Weise kann der über die Jahre entstandene hohe Wert der Bestandssoftware erhalten und fit für die Zukunft gemacht werden.

Elasticsearch ist eine weit verbreitete Suchmaschine und ein Datenspeicher. Neben diesem Erfolg gibt es aber beinahe wöchentlich negative Schlagzeilen, weil falsch konfigurierte Cluster sensible Daten preisgeben oder Ziel von Erpressern werden.

Dieser Vortrag gibt einen Überblick, wie es aus dem Spannungsfeld von Einfachheit gegenüber Sicherheit dazu kam, was genau die Probleme sind und wie man sie auflösen kann. Dabei geht es auch darum, dass richtige Entscheidungen der Vergangenheit heute andere Lösungen erfordern und wie man mit seinem Erfolg wächst.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider:innen
Voraussetzungen: Keine strikten Voraussetzungen
Schwierigkeitsgrad: Fortgeschritten

At a big town hall, a manager mentions DevOps, how that can help our company, and that it is necessary to switch to DevOps as our leading culture/process. Simple, yes? But what often gets forgotten is what needs to be changed to succeed in that culture switch and the expectation that it is a journey. I will show you two teams in the same company with the same presentation and how they went completely different directions. What we have learned from that and what I can give you as advice.

Target Audience: Developers, Managers, Team Leads, Ops, Decision Makers, Project Leader
Prerequisites: Basic knowledge of what DevOps is about
Level: Advanced

Extended Abstract:
Why is it so hard to move to a DevOps culture? This a common question from managers as they already talked about the advantages and got positive feedback from the team. On the other hand, developers now think they must be full-stack developers and ops specialists but still earn a developer salary. Then there is the Ops team, who struggles with the outcome of the development teams and their new role in the process. Everybody else is confused by the word DevOps and starts to think it is a new position in the company (well, you find DevOps team leads and specialists on job platforms).

Changing a company to follow a DevOps-oriented culture is a big project and should be planned accordingly. You will have setbacks; the bigger the company, the longer it will take. If you understand that this is a journey and that you cannot simply copy another company's culture, then you are at the right starting point.

Misunderstandings between developers and the business are a plague. Bad communication makes projects fail. This talk presents a remedy (including a practical demonstration with auditorium participation).

Domain Storytelling is a technique to transform domain knowledge into effective business software. It brings together domain experts and development teams.

We let domain experts tell us stories about their tasks. While listening, we record the stories using an easy-to-understand pictographic language.

Target Audience: Everyone involved or interested in software development, including non-technical people
Prerequisites: Curiosity
Level: Basic

Extended Abstract:
Misunderstandings between developers and the business are a plague. Bad communication makes projects fail. This talk presents a remedy (including a practical demonstration with auditorium participation).

Domain Storytelling is a technique to transform domain knowledge into effective business software. It brings together domain experts and development teams to: (a) understand the domain of a software system, (b) find microservices boundaries, and (c) talk about requirements.

We let domain experts tell us stories about their tasks. While listening, we record the stories using an easy-to-understand pictographic language.

The domain experts can see immediately whether we understand their story correctly. After very few stories, we are able to talk about the people, processes, and events in that domain.

The talk is aimed at everyone involved or interested in software development, including non-technical people.

Bei der Gestaltung digitaler Lösungen für komplexe Probleme müssen Design & Engineering als Kompetenzgebiete optimal integriert werden. Mit einem gemeinsamen Wertverständnis gilt es, dass sich verschiedene Professionsschwerpunkte wie EAM, RE, UX, Software Architecture in einem gemeinsamen Handlungsraum begegnen und zusammenwirken. Gemeinsame Sprache und Praktiken sind hierbei essenziell.

Wir berichten, wie wir dieses mit Hilfe eines Concept Core innerhalb des Deutschen Bahn vorantreiben und wo noch Herausforderungen vor uns liegen.

Zielpublikum: Digital Designer, Product Owner, Requirements Engineers, Business Analysts, Solution Architects
Voraussetzungen: Methodisches Grundverständnis für digitale Lösungskonzeption
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Menschen in den Professionsschwerpunkten Design, Engineering und Unternehmensarchitektur blicken aus verschiedenen Perspektiven auf die Herausforderungen der digitalen Transformation. Hinter gleichen Begriffen und ähnlichen Methoden stecken häufig sehr unterschiedliche Vorstellungen. Das kann zu Ergebnissen führen, die aus der Sicht eines Professionsschwerpunktes passende Lösungen für die jeweilige Herausforderung sind. Jedoch greifen die einzelnen Ergebnisse oftmals nicht einander und es entsteht keine stimmige Gesamtlösung.

Aufbauend auf einem gemeinsamen Werteverständnis haben wir bei der Deutschen Bahn einen Handlungsraum von People, Business und Technology definiert, innerhalb dessen wir mit dem Grundverständnis eines informationsorientierten Gestaltungsprozesses agieren. Durch die Bestimmung von Informationsbausteinen, als Kern-Informationsobjekte einer integrierten Konzeption, haben wir eine gemeinsame Sprache für das gegenseitige Verständnis der Professionsschwerpunkte gefördert. So haben wir Begriffe wie „Geschäftliches Ziel“, „Nutzungskontext“ oder „Geschäftsprozesse“ gemeinschaftlich definiert und Teil einer gemeinsamen Sprache werden lassen.

Um nicht in die Falle eines Methodengefängnisses zu tappen, trennen wir die Informationsbausteine von Methoden und Ergebnistypen. Wir nutzen Praktiken wie Domain Storytelling, Fit-Gap Analyse oder Journey Mapping konsequent als Mittel zum Zweck und können auf Basis der Informationsbausteine flexible Canvases bilden. Durch den primären Fokus auf die Informationsbausteine sind diese Praktiken miteinander verzahnt und unterstützen die Gestaltung einer stimmigen Gesamtlösung. Essenziell ist hierbei, die gemeinsame Praxiskultur innerhalb eines interdisziplinären Teams ausgehend von „minimum viable practices“ zu entwickeln.

Herausforderungen liegen für uns unter anderem darin, bestehende Silos zwischen den Teams aufzubrechen, die Professionsschwerpunkte in den stetigen Austausch zu bringen und kontinuierlich die Zusammenarbeit zu verbessern. Es bedarf Mut und Vertrauen, sich von Glaubenssätzen und detaillierten Kochrezepten des eigenen Professionsschwerpunktes zu lösen und in einen gemeinsamen, beweglichen Handlungsraum mit Gestaltungsfreiheit zu bewegen.

Das Thema digitale Inklusion spielt in der IT-Welt noch immer eine untergeordnete Rolle. Dabei sind bereits die Vorgaben und Gesetze für die IT gemacht. IT-Lösungen von Unternehmen müssen ab 2025 barrierefrei sein.

• Was muss moderne Software-Architektur dafür beachten?
• Wie erhalte ich weiterhin Zugang zu öffentlichen Ausschreibungen?
• Wie erfülle ich die Mindestanforderungen, auch im privaten Sektor?

Die Expertin für Barrierefreiheit, Peggy Reuter-Heinrich, bietet einen auch für Techis hilfreichen Einstieg in das Thema.

Zielpublikum: IT-Schaffenden Projektmanager:innen, Entwickler:innen, UX-Designer:innen, Entscheider:innen
Voraussetzungen: Kenntnisse in UX-UI-Design, Development
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Das Thema digitale Inklusion spielt in der IT-Welt leider noch immer eine untergeordnete Rolle. Dabei sind bereits mit der Barrierefreien-Informationstechnik-Verordnung („BITV) sowie den Web Content Accessibility Guidelines (WACG) die Vorgaben für die IT gemacht. Das mündet in das Europäische Teilhabe-Gesetz (EAA) und das Barrierefreiheitsstärkungsgesetz (BFStG). Beides gibt für Unternehmen vor, dass auch deren IT-Lösungen ab 2025 barrierefrei sein müssen. In dem Vortrag werden die Vorgaben und Bedingungen aufgezeigt und erläutert, die moderne Software-Architektur heutzutage mit einbeziehen muss, um weiterhin Zugang zu öffentlichen Ausschreibungen zu erhalten und die Mindestanforderungen künftig auch im privaten Sektor zu erfüllen. Die 98 Regeln der BITV bilden hierfür die Grundlage, wozu die Sprecherin einen auch für Techis nachvollziehbarer Einstieg bietet. Der technischen Programmierung kommt dabei eine Schlüsselrolle zu, da sie die Basis für alle digitalen barrierefreien Lösungen ist. Das gilt für mobile Apps, Webseiten und Software. Hierfür sind sämtliche Hauptakteure aus der IT gefragt, um Brücken für eine menschenfreundliche digitale Welt zu bauen. Insbesondere Software-, Web- und App-Entwickler:innen, Software-Architekt:innen, technische Berater:innen, IT-Abteilungsteiler:innen und IT-Projektleiter:innen wird die Expertin für Barrierefreiheit, Peggy Reuter-Heinrich, pragmatisch weiterhelfen.

Der Weg in die Cloud ist herausfordernd, insbesondere wenn ein gewachsenes Ökosystem den Ausgangspunkt bildet. Denn in einer langen Historie entstanden vielfältige Spezialitäten und organisatorische Eigenheiten. Für eine erfolgreiche Migration sind daher die Bereiche Organisation, Architektur und Infrastruktur gemeinsam anzugehen.

In diesem Vortrag möchte ich aufzeigen, was Cloud-Migration und Cloud Native eigentlich bedeutet und welche Konsequenzen daraus abgeleitet werden sollten.

Zielpublikum: Projektleiter:innen, Manager, Entscheider, Architekt:innen
Voraussetzungen: Projekterfahrung, Cloudmigrationserfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Cloud-Migration ist der Prozess der Verlagerung von Arbeitslasten, Daten, Anwendungen und Prozessen in eine Cloud-Umgebung. In den meisten Fällen werden die Ressourcen von einem lokalen Rechenzentrum zu einem Cloud-Anbieter geschoben. Manchmal auch von einem Cloud-Anbieter zu einem anderen.

Die Gründe sind vielfältig. Manche Unternehmen erhoffen sich geringere Kosten, andere mehr Flexibilität, und manchmal zwingen Vorschriften dazu, mehr als einen Cloud-Anbieter zu nutzen. Was auch immer der Grund sein mag, eine einfache Umstellung auf die Cloud ist nicht immer erfolgversprechend und kann auch nicht die Vorteile und das Versprechen der Cloud ausschöpfen. Darüber hinaus kann die Umstellung auf die Cloud neue Anforderungen an das Unternehmen stellen und Veränderungen erfordern. Eine Veränderung, die für alteingesessene Unternehmen nicht immer einfach ist.

In diesem Vortrag werde ich aufzeigen, was Cloud-Migration und Cloud Native eigentlich bedeutet und welche Konsequenzen daraus abgeleitet werden sollten. Anschließend zeige ich die Herausforderungen einer solchen Migration auf und gebe Empfehlungen für ein schrittweises Vorgehen. Natürlich darf auch die Sicherheit der Umgebungen und Daten nicht außer Acht gelassen werden. Ich informiere über die zu berücksichtigenden Sicherheitsaspekte. Schließlich formuliere ich Migrationsmuster, die bewährte Verfahren aus vielen Migrationsprojekten beschreiben.

To understand and impact a large-scale environment (a team, an enterprise, a society), we need effective modeling. Over the years Domain-Driven Design (DDD) has gained a visible foothold in software-centric corporate change agendas.

In my work as a DDD evangelist and sociotechnical architect in large organizations, I’ve lived and breathed DDD to decouple domains and systems, to kickoff greenfield initiatives, to deploy brownfield modernization, and to design reteaming using the Inverse Conway Maneuvre and Team Topologies.

All that hard work has brought me many a pat on the shoulder. But time after time I’ve been surprised by how I/we could make things worse by attempting to make things better. I’ve been frustrated to witness bubbly energy and DDD enthusiasm from event storming workshops and alike evaporate like a deflated balloon. Improvements remained temporary and local. New practices failed to gain widespread adoption. I have to admit with absolute candor that it is so very hard to make lasting impact with DDD, or whatever else technology or tooling du jour.

In this talk, I will share my observations through the systems thinking lens, of what happened in a large change initiative in a big bank, where DDD played a central role. You will hear examples of sociotechnical systems dynamics and episodes about shifting dominance of competing feedback loops. You will be invited to partake in a postmortem forensic of what could have happened, what unfortunately didn’t happen, and the many what-if’s of alternate realities, or pasts. For people new to systems thinking, a positive side benefit can be a sneak peak into systems modeling building blocks and systems archetypes.

As a community, we’ve come a long way modeling software-centric systems, thanks to practice like DDD, architecture and Team Topologies. But what about the runtime dynamics of large human systems in our working environment, especially when such systems are full of fixes that don’t work? As software professionals, can we just tell jokes about SAFe, about policy makers in our company who can copy the Spotify Model, but not paste it? Or should we give the usual shrug – “it’s the system’s fault”?

From a systems standpoint, we are part of the same mess. If we can become better at seeing and naming the elephants in the room, not as random events, but as systemic patterns described through a consistent systems language, then the current messy reality is no longer our enemy but our ally. It can become a generative force for us to identify leverage and sustain influence in large organizational spaces.

I hope this talk will spark interest in system dynamics modeling. It is a call to action for boundary spanners and design-oriented change agents to explore abstractions, heuristics, modeling and visualization techniques to articulate and reason about dynamic system behavior.

How can we architect shared experiences to surface mental models so they can be challenged, improved and no longer stand in the way of change? With the rising initiative fatigue in large enterprises, how do we collectively discover leverage points, design and deploy systemic interventions with long lasting impacts?

Target Audience: Architects, Developers, Product Owners, Agile Coaches, Decision Makers at all levels
Prerequisites: Understanding of agile, architecture, domain-driven design
Level: Expert

Requirements Engineers und User Experience Professionals sind ins agile Vorgehen häufig schlecht integriert. Die Ursache: Fachliche Disziplinen sind im Scrum-Framework nicht explizit vorgesehen. Das führt in der Praxis wiederum zu Problemen. Es ist etwa unzureichend geklärt, welche Aufgaben und Verantwortlichkeiten PO, RE und UX haben oder wie sie bestmöglich zusammenarbeiten.

In unserem Vortrag teilen wir unsere konkreten Tipps zur Zusammenarbeit, um die Disziplinen ein stückweit zueinander zu führen.

Zielpublikum: Product Owner, Requirements Engineers, UX Professionals, Entwickler:innen, Projektleiter:innen
Voraussetzungen: Grundkenntnisse in agilem Vorgehen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Aufbauend auf unternehmensinternen Umfragen und Interviews sowie einer Literaturrecherche entwickelten wir eine Zusammenarbeitsvorlage für agile Teams. Sie enthält die Aufgaben, Skills und Methoden der Expertisen UX, RE, Development und Product Owner und insbesondere deren Erwartungshaltung an die jeweiligen anderen Expertisen.

Die Vorlage hilft beispielsweise beim Projekt-Kickoff sowie während des Teambuildings, ein gegenseitiges Verständnis aufzubauen und so die Zusammenarbeit zu verbessern.

Bei dem Vortrag geht es uns nicht um das Beibehalten von etablierten Rollenbildern, sondern um den Blick über den Tellerrand und die Offenheit für andere Denkansätze. Nur so kann wirklich effektiv in einem cross-funktionalen Team zusammengearbeitet werden.

Zielgruppe des Vortrags sind alle Mitwirkenden in agilem Vorgehen. Wir geben konkrete Tipps zur Zusammenarbeit in agilen Projekten.

Wenn Code und Architektur einer Anwendung nicht mit Testbarkeit im Hinterkopf entwickelt wurden, ist es oft schwierig, diese Anwendungen in eine agilere Software-Entwicklung mit kontinuierlicher Auslieferung zu überführen. Die dafür nötigen automatisierten, schnellen Tests können oft nicht oder nur mit sehr hohem Aufwand geschrieben werden. In dieser Session zeige ich ein paar grundlegende Muster und Ideen, mit denen vorhandener Legacy-Code für bessere Testbarkeit umgebaut werden kann. Und dieses Wissen hilft natürlich auch bei Neuentwicklungen.

Zielpublikum: Entwickler:innen, Architekt:innen
Voraussetzungen: Hilfreich ist, wenn man schon mal versucht hat, (Unit-)Tests für alten Code zu schreiben
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Wer schon einmal Änderungen in einer großen, alten Anwendung einbauen musste, die "historisch bedingt" nicht durch ausreichende Testautomatisierung abgesichert ist, weiß vielleicht, wie schwer es sein kann, nachträglich (Unit-)Tests für solche Altanwendungen zu schreiben. Zumal es ohne eine solche Absicherung durch schnelle Tests kaum möglich ist, solche Anwendungen für beispielsweise Continuous Delivery fit zu machen – was bei vielen Unternehmen im Rahmen von DevOps-Initiativen o. ä. relevant ist bzw. wird.

Wie schafft man es aber, vorhandenen Code besser testbar zu machen? Oder neuen Code gleich gut testbar zu entwickeln? Oft denkt man dann sofort an Programmierpraktiken wie Test-Driven Development (TDD), durch die ein besseres – besser testbares! – Code-Design entsteht. Aber es gibt auch einige Architekturstile bzw. -muster, die ein einfacheres Testen mit schnelleren Feedback-Schleifen ermöglichen.

Wir schauen uns in dieser Session an, was es bedeutet, Geschäftslogik von Integrationscode zu trennen, welche unterschiedlichen Code-Designs und Architekturmuster es gibt, um dieses Ziel zu erreichen – und warum damit kleinere und schnellere automatisierte Tests möglich sind.

Es geht dabei um die absoluten Grundlagen von testbarem Code und testbarer Architektur. Wer sich nicht sowieso schon täglich mit diesen Themen beschäftigt, wird Anregungen und Tipps bekommen, wie man sofort morgen im eigenen Projekt die ersten Verbesserungen vornehmen kann.

Die DevOps-Bewegung bricht Silos zwischen Entwicklung und Betrieb auf. Etliche Unternehmen sind intern auf dieser Reise weit gekommen. Sobald sie jedoch externe IT-Lieferanten beauftragen, entstehen oft wieder die alten Silos: Der Lieferant baut die Lösung und übergibt sie für den Betrieb an den Kunden.

Dabei muss das nicht so sein. Auch externe IT-Lieferanten können gemäß der DevOps-Philosophie mit ihren Kunden (zusammen-) arbeiten. Konstantin Diener zeigt euch einige Muster und praktische Beispiele dafür.

Zielpublikum: Entwickler:innen, Product Owner, Projektleiter:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

EasyJet Test Manager Laveena Ramchandani as she shares the skills and strategies needed to be successful in Test/QA leadership. Drawing from her own experiences and from those with varying backgrounds, she offers actionable guidance for those aiming to become, or just starting to work as, a Test Manager.

Explore how to choose and deploy the right processes, tools, and team members to meet your quality mandate. Learn how to create a culture that values feedback. Understand why growing and retaining your best people is critical in uncertain economic times.

Target Audience: All
Prerequisites: None
Level: Advanced 

Extended Abstract:
EasyJet Test Manager Laveena Ramchandani as she shares the skills and strategies needed to be successful in Test/QA leadership. Drawing from her own experiences and from those with varying backgrounds, she offers actionable guidance for those aiming to become, or just starting to work as, a Test Manager.

Explore how to choose and deploy the right processes, tools, and team members to meet your quality mandate. Learn how to create a culture that values feedback. Understand why growing and retaining your best people is critical in uncertain economic times

Key takeaways:

• Traits to cultivate
• Being a people manager
• Tools and techniques: How to choose what’s best for your team
• Giving and receiving feedback
• Working smart

Wir stehen vor großen Herausforderungen – Klimakrise, Artensterben, Krieg, Krankheiten, Hunger, Wassermangel, … – und es gibt eine vermeintlich einfache Lösung: innovative Technologien! Leider ist die Lösung nicht ganz so einfach. Aus diesem Grund ist es an der Zeit, die transhumanistische Begeisterung für Technologien, die eine Verbesserung und Optimierung des Menschen versprechen, kritisch in den Blick zu nehmen. Zunächst gilt es, den Unterschied zwischen Transhumanismus, technologischem und kritischem Posthumanismus zu verstehen. Verschiedene Beispiele zeigen dann, wie Technologien das menschliche Leben bereits heute und umso mehr in Zukunft auf unterschiedliche Weise beeinflussen. Um diesem Einfluss nicht ausgeliefert zu sein, stelle ich ein Werkzeug zur ethischen Evaluation von Technologien vor.