Eine auf Microservices basierende Architektur umzusetzen, bedeutet, dass auch die Datenhaltung auf die verschiedenen Services verteilt werden muss. Was aber bedeutet das in der Praxis? Was ist, wenn Daten einer Entität - vollständig oder in Teilen - in mehreren Services benötigt werden? Wie wird referenzielle Integrität über mehrere Services hinweg realisiert? Wie lassen sich serviceübergreifende Transaktionen realisieren? Dies sind nur einige von vielen Fragen, die im Rahmen der Session beantwortet werden. So viel vorab: Umdenken ist gefragt!

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

Extended Abstract

Nur wenn die Auftrennung der Fachlichkeit in verschiedenen Microservices auch konsequent bis hin zur Ebene der Datenhaltung vollzogen wird, kann die angestrebte Unabhängigkeit der Services zur Entwicklungs- und Laufzeit erreicht werden. Ohne diesen Schritt dagegen würde sich das Problem der starren Kopplung und der damit einhergehenden Abhängigkeiten einer monolithischen Architektur lediglich um eine Schicht nach unten, in die Datenbank, verlagern. Was aber bedeutet das konsequente Einhalten des Database-per-Service-Patterns und einer damit einhergehenden Verteilung der Datenhaltung in der Praxis? Die Session zeigt die wesentlichen Herausforderungen auf und liefert passende Lösungsansätze.

The idea of looking at your organization as a single coherent system is tempting, but is it realistic? If it isn't, what does that mean for software developers, and how can we make discoverable what we are developing? This talk looks at organizations as ecosystems rather than as systems, and asks what that difference means for software development. It all boils down to focusing on software as components implementing business capabilities, and how to best capture these capabilities and make them findable and useful as reusable components.

Target Audience: Developers, Architects, Project Leaders, API Strategists
Prerequisites: API Basics, Large-scale information systems
Level: Advanced

Oft wird Software immer schlechter wartbar, je länger Entwicklungsteams an ihr arbeiten. Dazu hat sich die Metapher “technische Schulden” etabliert. Aber es ist nicht immer sinnvoll, technische Schulden zu beseitigen und sie können auch “einfach so” entstehen. Darum geht es in diesem Vortrag - und über die Grundlagen der Metapher, wie sie bei der Kommunikation mit Managern hilft, warum die Metapher eigentlich nicht besonders gut gewählt ist und natürlich wie man mit technischen Schulden sinnvoll umgehen kann.

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

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. Dieser Vortrag wird klä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: Software-Architekt:innen, Softwareentwickler:innen, Projektleiter:innen, Manager:innen
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract

Als Missverständnisse werde ich ansprechen:

1) Microservices bilden eine SOA

2) Überall Events

3) Jedes Team wie es will

4) Wiederverwendung

5) Gegen Zyklen helfen Interfaces

6) Sourcecode = Dokumentation

7) Neubau ist besser als Refactoring

Dabei erkläre ich das Missverständnis und biete jeweils eine oder mehrere entgegengesetzte Sichtweisen an. Beispiele benutze ich, um die Argumentation zu verdeutlichen, und schließlich gebe ich jeweils meine Empfehlung dazu.

Architektonische Konzepte in Code abzubilden, bleibt in Java-Applikationen meist eine Herausforderung, ebenso wie die Trennung von fachlichem Code und Applikationsframework. Der Vortrag gibt einen Überblick über das jMolecules API und zeigt, wie Entwickler:innen die bereitgestellten Abstraktionen nutzen können, um Architektur-Konzepte auszudrücken. Darüber hinaus wird konkrete Integration mit Technologien sowie die Generierung von Dokumentation am praktischen Beispiel beschrieben.

Zielpublikum: Software-Architekt:innen, Seniorentwickler:innen
Voraussetzungen: Grundlegende Java- und Software-Architekturkenntnisse
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Java-Applikationen basieren gewöhnlicherweise auf einem Framework oder einer Entwicklungsplattform. Einige davon erlauben es, einige architektonische Konzepte auszudrücken. Diese jedoch direkt in Code abzubilden, bleibt meist eine Herausforderung, ebenso wie die Trennung von fachlichem Code und Applikationsframework.
jMolecules ist eine Framework-unabhängige Bibliothek, die es erlaubt, verbreitete, architektonische Konzepte direkt in Code abzubilden, zu überprüfen, ob Regeln bezüglich der Implementierung dieser Konzepte eingehalten werden, und sowohl die nötige technische Integration als auch entsprechende Dokumentation daraus abzuleiten.
Der Vortrag gibt einen Überblick über den grundsätzlich Ansatz und zeigt, wie Entwickler:innen die bereitgestellten Abstraktionen nutzen können. Darüber hinaus wird konkrete Integration mit Spring, Jackson und JPA sowie die Generierung von Dokumentation am praktischen Beispiel gezeigt.
 

Klassisches EAM ist gut verstanden und hat in sich nur langsam oder voraussehbar verändernden Umgebungen erhebliche Verbesserungen bewirkt. Aufgrund steigender Komplexität und Dynamik nimmt die Verbreitung Agiler Methoden immer weiter zu. Außerdem werden im Zuge der digitalen Transformation Veränderungen auf der Business-Seite zunehmend zum wesentlichen Treiber strategischer Veränderungen in der IT. Darauf muss sich die IT insgesamt und die Unternehmens-Architektur im Besonderen mit ganz neuen Vorgehensweisen einstellen.

Zielpublikum: Unternehmensarchitekt:innen, IT-Manager, Architekt:innen, Projektleiter:innen, Change-Manager
Voraussetzungen: Grundkenntnisse EAM, Agile Methoden, Projekterfahrungen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Klassisches EAM ist gut verstanden und hat in sich nur langsam oder voraussehbar verändernden Umgebungen erhebliche Verbesserungen in der IT von Unternehmen bewirkt. Aufgrund steigender Komplexität und Dynamik nimmt die Verbreitung Agiler Methoden immer weiter zu. In der Folge sind Ansätze einer "Agilen Unternehmens-Architektur" in ersten Ansätzen erkennbar. In Zukunft wird in heterogenen Unternehmen allerdings die Herausforderung bestehen, dass innerhalb eines Unternehmens Organisationsbereiche mit ganz unterschiedlichen Umfeldern und Kulturen (tayloristisch, synergistisch und chaordisch) parallel zueinander existieren. Außerdem werden im Zuge der digitalen Transformation Veränderungen auf der Business-Seite zunehmend zum wesentlichen Treiber strategischer Veränderungen in der IT. Darauf muss sich die IT insgesamt und die Unternehmens-Architektur im Besonderen mit ganz neuen Vorgehensweisen einstellen. Klassische, auf die IT-beschränkte "Agile Transformationen" greifen dabei zu kurz.

Der Beitrag diskutiert, wie man event-getriebene Architekturen als eine Form der reaktiven Architekturen in einer Beratungssoftware einsetzen kann. Warum wurde für diese Beratungssoftware der event-getriebene Ansatz gewählt? Es werden sowohl die geschäftlichen als auch die technischen Anforderungen diskutiert, die zur Wahl dieses Architektur-Ansatzes geführt haben. Der event-getriebene Ansatz erwies sich als der richtige, um eine Entkopplung der Systeme und ein gesamthaftes Bild der einzelnen Aktivitäten für den Benutzer sicherzustellen.

Zielpublikum: Architekt:innen, Entwickler:innen, Entscheider
Voraussetzungen: Prinzipielles Verständnis von Software-Architektur
Schwierigkeitsgrad: Anfänger

Extended Abstract
1. Vorstellung Beratungssoftware
2. Vorstellung Beratungsprozess
3. Variante als steuernder Prozess (klassische Architektur)
4. Variante als event-getriebener Prozess (reaktive Architektur)
5. Vorstellung der technischen Architektur
6. Vor- und Nachteile des gewählten Ansatzes
7. Weitere Arbeiten

Detail:
Die Beratungssoftware der Allianz Gruppe wird in den Agenturen eingesetzt, um Kunden gezielt und individuell beraten zu können. Dabei ist es wichtig, dem Berater auf der einen Seite Hilfe und Richtung in den teilweisen komplizierten Produkten anzubieten und auf der anderen Seite die notwendige Flexibilität des Verkaufsprozesses nicht einzuschränken.
Technisch erlauben Events, die Informationen von sehr unterschiedlichen Systemen ohne eine enge Kopplung dem Agenten zur Verfügung zu stellen. Der Gesamtprozess muss nicht den Einzelsystemen bekannt sein, sondern wird vielmehr aus den verschiedenen Informationen erst gebildet.
Dadurch erreicht man eine hoch flexible und entkoppelte Architektur, ohne auf Gesamtüberblick und strukturierte Darstellungen verzichten zu müssen.

10 Jahre nach CAP wurde das CALM-Theorem formuliert, das beweist, was wir immer alle geahnt haben: Im Fall von Netzwerkpartitionen sind Konsistenz UND Verfügbarkeit unter bestimmten Bedingungen möglich! Im Vortrag gehen wir auf eine Journey vom CAP-Theorem hin zum CALM-Theorem. Ich räume mit gängigen Mythen auf und zeige euch, wie ihr das CALM-Theorem praktisch anwenden könnt. Der Vortrag vereint neueste Forschungsergebnisse und Lessons Learned aus mehreren Studien mit konkreten Entwurfsmustern und Code-Beispielen für Architekt:innen.

Zielpublikum: Architekt:innen
Voraussetzungen: Fachkenntnisse verteilte Systeme, Basiswissen DDD, Entwurfsmuster, Java
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Zehn Jahre nach Eric Brewers CAP-Theorem formuliert Joseph Hellerstein das CALM-Theorem und beweist das, was wir schon immer geahnt haben: Im Fall von Netzwerkpartitionen sind Konsistenz UND Verfügbarkeit unter bestimmten Bedingungen möglich! Wie das geht, zeige ich euch in diesem Vortrag und nehme euch mit auf eine Journey vom CAP-Theorem hin zum CALM-Theorem. Ich räume mit gängigen Mythen auf und zeige euch, wie ihr das CALM-Theorem praktisch anwenden könnt. Basierend auf unseren empirischen Erfahrungen aus verschiedenen Studien (Case Studies und Action Research Studies) und unserer laufenden Forschung entwickeln wir Architektur-Empfehlungen und Entwurfsmuster für das Design von daten-intensiven, verteilten Anwendungen. Der Vortrag gibt konkrete Hilfestellungen für Architekt:innen, demonstriert Entwurfsmuster mit laufendem Code und teilt mit den Teilnehmern unsere frei verfügbaren, open access Architektur-Guidelines.