In a world of rapid changes and increasing uncertainties, organizations have to continuously adapt and evolve to remain competitive and excel in the market. In such a dynamic business landscape organizations need to design for adaptability. Designing for adaptability requires understanding the landscape organizations are operating in, identifying patterns of change, applying principles for organizational fitness, and making mindful strategic decisions to adapt change.

Target Audience: Software Architects, Tech Leads, Engineering Manager, VP of Engineering
Level: Basic

Extended Abstract
Organizations need to aim for building systems and team organizations aligned to the business needs and business strategy and evolving them for adaptability to new changes and unknown environments.
This talk brings different perspectives and techniques together from business strategy (Wardley Mapping), software architecture (Domain-Driven Design), and team organization (Team Topologies) as a powerful toolset to design, build and evolve adaptive systems and team structures for a fast flow of change.

Auch Legacy-Systeme kann man mit Domain-driven Design (DDD) verbessern. Am Anfang sollte die Frage stehen, warum ein erfolgreiches Legacy-System überhaupt verbessert werden soll. Der Vortrag zeigt, wie man sich dazu an Änderungen des Geschäftsmodells orientieren kann. Technische Ansätze wie das Extrahieren von Bounded Contexts oder die Implementierung von Bubble Bounded Contexts verdeutlichen zudem, wie man ganz praktisch vorgehen kann. So kann DDD auch bei der Anpassung existierender Systeme an sich ständig ändernde Anforderungen helfen.

Zielpublikum: Technische Projektleiter:innen, Architekt:innen, Entwickler:innen
Voraussetzungen: Grundlegendes Verständnis über Softwareentwickung
Schwierigkeitsgrad: Anfänger

In den letzten Jahren erfahren IT-Landschaften durch Digitalisierung einen großen Änderungsdruck. Für ältere IT-Landschaften bedeutet dies eine komplette strategische Neuausrichtung. In diesem Beitrag schlagen wir mit Domain Driven Transformation eine Methodik vor, in der DDD mit Methoden des EAMs (Enterprise Architecture Management) kombiniert wird. Im Kern liegt die Definition von Bounded Contexts und einer Context Map, die mit der IST-IT-Landschaft abgeglichen werden kann. Aus dem Abgleich entstehen Handlungsfelder, die priorisiert und in eine Roadmap aufgenommen werden.

Zielpublikum: IT-Architekt:innen, IT-Manager und Projektleiter:innen
Voraussetzungen: Grundsätzliches Verständnis von DDD und EAMs
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
In den letzten Jahren erfahren die IT-Landschaften von Unternehmen einen immer größeren Druck auf notwendige Veränderungen. Dies hat mehrere Gründe:
- Die Cloud verspricht viele Vorteile, aber die vorhandenen, veralteten Technologien verhindern eine Nutzung
- Die Digitalisierung des Business von Firmen führt zu einem Bedarf an schnellen und größeren Änderungen sowie Erweiterungen in der IT-Landschaft
- The 'war of talents' verlangt nach der Nutzung von modernen Technologien, um Talente im Unternehmen zu halten oder einstellen zu können
Für ältere IT-Landschaften bedeutet dies häufig eine komplette strategische Neuausrichtung mit dem Fokus, eine Zielarchitektur zu definieren und einen Plan für die Transformation der IT-Landschaft aufzustellen. Damit die Vorteile der modernen Technologien und Organisation (Cloud-Technologie, DevOps) schnell genutzt werden können, müssen Handlungsfelder priorisiert werden und die Umbauschritte mit dem Projektportfolio und dem EAM verzahnt werden. Ziel des Planungsprojekts ist die Definition einer Zielarchitektur, eine allgemeine Vorgehensweise sowie eine Roadmap, mit deren Hilfe die IT-Landschaft schrittweise in den nächsten Jahren umgebaut werden kann. Und dabei sollen möglichst schnell Benefits hinsichtlich der anfangs genannten Punkte erreicht werden.
In diesem Beitrag werden zunächst die Ausgangslage und die Ziele eines Planungsprojekts erläutert. Dazu schlagen wir eine an die DDD angelegte Methodik vor: Domain Driven Transformation, eine Methodik, in der DDD mit Methoden des EAMs und Projektmanagements kombiniert werden. Im Kern liegt die Definition von Bounded Contexts und einer Context Map, die zum Bedarf des Business passt und mit der derzeitigen IT-Landschaft abgeglichen werden kann. Aus dem Abgleich entstehen Handlungsfelder, die priorisiert und in eine Roadmap aufgenommen werden. Um überhaupt zu einem guten Aufsatzpunkt für DDD zu kommen, muss der Soll-Bedarf des Business definiert werden. Dazu werden capability maps, Prozesslandkarten und Business-Strategien analysiert und damit die gesamte zu betrachtende fachliche Welt aufgespannt. In diesem aufgespannten Feld dienen zunächst Orientierungsszenarien mit Hilfe von Domain Stories dazu, die fachliche Welt näher zu definieren.
In einem spiralförmigen Prozess aus business capabilities, Prozesslandkarte und Domain Stories wird das Feld tiefer erschlossen und Subdomänen werden erkannt. Die daraus definierten Bounded Contexts werden zusammen mit Make-or-buy-Entscheidungen zu einer Zielarchitektur zusammengefasst und mit der IT-Landschaft abgeglichen. Die Handlungsfelder umfassen Redesign-Vorhaben von Applikationen, Modernisierungen, Entrümpelung von nicht mehr benötigten System(teil)en sowie Abschaltung und Einführung von Kaufsoftware zusammen mit der notwendigen Integration.
Der Umbau der IT-Landschaft ist ein über mehrere Jahre andauernder Prozess, der im Sinne einer gesteuerten Evolution immer wieder vom Business-Bedarf über die Zielarchitektur bis zur Priorisierung angepasst werden muss. Die Dokumentation und das Handwerkszeug aus dem obigen Vorgehen eignen sich gut, die Zielarchitektur und die Priorisierungen auf dem Weg der Transformation anzupassen.

The world in which a software system lives is filled with meaning. The structure, concepts and names that inform the code, its changes and the mental models held by developers are expressions of meaning. The very act of development is an exercise in meaning — it's discovery, its formulation, its communication.
But just because we are immersed in concepts of meaning from an early age, and just because the daily work of software development is about wrangling meaning, that doesn't mean we're necessarily good at it. Let's talk about what we mean.

Target Audience: Developers, Architects, UX, Product Owners
Prerequisites: No specific prerequisites
Level: Advanced

Extended Abstract
"It's just semantics." How many conversations about philosophy, politics and programming are derailed by this thought-stopping comment?
Semantics is all about meaning. If there is one thing we struggle with and need to get better at, it is the search for and clarification of meaning. The world in which a software system lives is filled with meaning. The structure, concepts and names that inform the code, its changes and the mental models held by developers are expressions of meaning. The very act of development is an exercise in meaning — it's discovery, its formulation, its communication. Paradigms, processes and practices are anchored in different ways of thinking about and arriving at meaning.
But just because we are immersed in concepts of meaning from an early age, and just because the daily work of software development is about wrangling meaning, and just because it's just semantics, that doesn't mean we're necessarily good at it. It takes effort and insight. Let's talk about what we mean.

Within DDD we have the perspective of strategic design where we can split a large-system into multiple sub-domains, each having its purpose and responsibilities, where teams can work in autonomous, clean bounded contexts. One of the most effective ways to define these boundaries is by collaborative modelling with all the stakeholders involved in these domains. Join us were we share war stories about our experience doing collaborative modelling in several companies with 30+ people.

Target Audience: Architects, Manager, Decision Makers, Tech Leads
Prerequisites: None
Level: Advanced

Extended Abstract
As a business, we want to make sure our software can handle changes when the business changes. We want to define boundaries that support the flow of the business value. Within Domain-Driven Design we have the perspective of strategic design. A perspective where we can split a large-system into multiple sub-domains, each having its purpose and responsibilities. Within these sub-domains, teams can work in autonomous, clean bounded contexts. One of the most effective ways to define these boundaries is by collaborative modelling with all the stakeholders involved in these domains. But that poses real challenges: What exactly is the definition of a (sub)domain? What is problem space? How can we form a common language of these boundaries? How does a customer journey fit in? And how do you decide and come to a single model in a large group, where everyone shares that same model on a high level?
Join us in this talk where we will show and tell war stories about our experience of having done collaborative modelling in several companies. We will tell our successes, but more importantly our failures and what we learned from them. What are the key heuristics we think that makes a collaborative modelling session with 30+ people, without any DDD knowledge, succeed? What are the skills we need to learn to facilitate it, and how can we make a company not dependent on us as consultants to continue their journey? You will leave with the knowledge of how to start your own collaborative modelling of your domain boundaries. We tell you our definition of (sub)domains, problems and solution space, and how we explained it to the companies we consulted. Providing you with new perspectives on how to embed this as a ritual in your company.

Soziotechnische Architekturen verheiraten organisatorische und strukturelle Betrachtungen auf Software-Architekturen. Um dieses Geflecht zu visualisieren, haben sich in den letzten Jahren zwei Techniken etabliert: Context Maps aus dem strategischen DDD und Team Topologies von Matthew Skelton und Manuel Pais. Dieser Vortrag stellt beide Ansätze vor und zeigt, wie diese zusammen genutzt werden können, um verschiedene Perspektiven und Fragestellungen auf den Themenkomplex Architektur / Organisation greifbar zu machen.

Zielpublikum: Architekt:innen, Entscheider:innen, Manager, Projektleiter:innen
Voraussetzungen: Grundlagen Architektur
Schwierigkeitsgrad: Fortgeschritten