Integration war und ist immer noch relevant - vielleicht mehr denn je. Insbesondere, wenn wir über Anwendungsmodernisierung sprechen. In Zeiten von Cloud- und Microservice-Architekturen müssen wir neu darüber nachdenken, wie wir Integrationsherausforderungen bewältigen können. Klassische ESB-Lösungen sind meist veraltet - was aber ist die Alternative?
Anhand der Erfahrungswerte aus unserem eigenen IT-Modernisierungsprojektes, werde ich vorstellen, wie Integrationsherausforderungen heute mit Hilfe moderner Technologien adressiert werden können.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Cloud, Integration, API, Events
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Integration ist ein wichtiges Thema. In jedem Modernisierungsprojekt existieren entsprechende Herausforderungen, die nach einer entsprechenden Integrationsstrategie verlangen.
In der Regel starten wir ja nicht auf der grünen Wiese, sondern müssen die alte und neue Welt zusammenbringen. Auch ein Monolith kann nicht im Rahmen eines Big Bang Ansatzes einfach mal eben so abgelöst werden.

Im Kontext des Vortrages werde ich von unserem eigenen IT Modernisierungsprojekt berichten, im Kontext dessen wir einen über 30 Jahre gewachsenen Oracle Forms Monolithen in einem inkrementellen Vorgehen ablösen und durch SaaS-Lösungen ersetzen wollen. Die Integration zwischen alter und neuer Welt erfolgt basierend auf modernen Technologiekonzepten wie Containern, API Gateway, Service Mesh und Event Hub mit Kubernetes als zentrale Runtime Plattform.
Dies ermöglicht uns perspektivisch mehr Flexibilität und Agilität sowie eine Steigerung der Developer Productivity durch die Verwendung entsprechender Konzepte und Technologien sowie eine hochgradige Automatisierung im Kontext der Applikationsbereitstellung.

Die Welt der operativen, transaktionalen Systeme und der analytischen Systeme ist seit jeher getrennt. Unterschiedliche SW-Entwicklungsparadigmen, andere Technologien, andere Datenmodelle, usw. prägen die jeweiligen Systeme. Statt Silos zu bauen, geht es darum, eine Balance zu finden zwischen Dev und Data: DevDataOps? Wie können Data Mesh und Data Lakehouse dazu beitragen?

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

Extended Abstract:
Die Welt der operativen, transaktionalen Systeme und der analytischen Systeme ist seit jeher getrennt. Unterschiedliche SW-Entwicklungsparadigmen, andere Technologien, andere Datenmodelle, usw. prägen die jeweiligen Systeme. Statt Silos zu bauen, geht es darum, eine Balance zu finden zwischen Dev und Data: DevDataOps? Wie können Data Mesh und Data Lakehouse dazu beitragen?

Data Mesh ist ein Ansatz, der mit Prinzipien wie domänengetriebener Entwicklung, Produktorientierung oder Self-Service Infrastruktur die Welten verschmelzen möchte. Beim Data Lakehouse stehen dagegen technische Eigenschaften im Mittelpunkt der Veränderungen gegenüber gängigen Architekturen. DevDataOps wird von beiden Architekturen unterstützt – die Gewichtung ist jedoch grundverschieden. Auch die Anforderungen an die Umsetzung sind unterschiedlich: Data Mesh führt beispielsweise organisatorische Änderungen nach sich. Im Vortrag werden solche Fragestellungen anhand praktischer Erfahrungen vertieft.

Die Zertifizierung von Energie aus erneuerbaren Quellen in Europa weist Mängel auf. Wir stellen die Architektur einer Anwendung für Herkunftsnachweise mit einem reaktiven System und einer vertrauenswürdigen Buchführung vor. Sie ist in der Lage, das heutige Verfahren aus Sicht von Endkunde und Energielieferant durch eine zeitnahe Zuordnung von erzeugter und verbrauchter Energie sowie durch Nachvollziehbarkeit maßgeblich zu verbessern. Unser Vorschlag fügt sich in das aktuelle System ein und hat das Potenzial, dieses mittelfristig zu ersetzen.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Interesse an heterogenen Software-Architekturen und vertrauenswürdigen Systemen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Heutzutage legen Kunden großen Wert auf elektrische Energie, die aus erneuerbaren Quellen stammt. Sie sind bereit, dafür einen höheren Preis zu bezahlen, erwarten aber im Gegenzug einen vertrauenswürdigen Herkunftsnachweis. Vertrauenswürdig bedeutet hier, dass der Weg vom Produzenten zum Konsumenten von elektrischer Energie lückenlos transparent aufgezeichnet wird, eine doppelte Zuordnung unmöglich ist und die Buchführung jederzeit überprüfbar ist.

Gemäß europäischem Regelwerk können Herkunftsnachweise in einem Zeitfenster von einem ganzen Jahr nach der Erzeugung entwertet werden. So kann beispielsweise im Winter um Mitternacht erzeugter Strom aus Wärmekraftwerken zusammen mit einem im vorhergehenden Sommer um die Mittagszeit erzeugten Solarstromzertifikat als Ökostrom verkauft werden.
Herkunftsnachweise können sogar unabhängig von der Energielieferung gehandelt werden, wodurch es möglich wird, dass Nachweise für Energie aus Wasserkraft in Island in Deutschland entwertet werden, obwohl keine Möglichkeit zum Energieaustausch besteht. In der Schweiz und in Europa gibt es Vorstöße, die «mehr Transparenz bei der Stromherkunft» fordern.

Wir messen den Verbrauch und die Erzeugung von elektrischer Energie mit geeichten und plombierten «intelligenten» Zählern, die digital signierte Messergebnisse liefern. Die Anwendung empfängt diese Messwerte und legt diese unveränderbar als Erzeugungs- oder Verbrauchs-Datensatz ab. Anschließend ordnet der Matcher dem Verbrauchs-Datensatz die entsprechende Menge an nachhaltig erzeugter Energie zu. Damit wird der Herkunftsnachweis erbracht. Der Erzeugungs- und Verbrauchs-Zeitpunkt darf maximal 15 Minuten auseinanderliegen, damit Erzeugung und Verbrauch einander zugeordnet werden können. Andernfalls erfolgt keine Zuordnung, der Herkunftsnachweis kann nicht erbracht werden.

Ausgehend von der Problemanalyse leiten wir mögliche Geschäftsmodelle und Anforderungen an eine Lösung ab. Wir stellen verschiedene Varianten vor und begründen unsere Wahl. Wir erläutern außerdem, wie wir das System konzipiert haben, damit es robust ist, nachweislich eine korrekte Buchführung gewährleistet und gleichzeitig einen hohen Durchsatz ermöglicht.
Zusätzlich zu den digital signierten Messwerten muss die Vertrauenswürdigkeit der gesamten Kette von Systemkomponenten und Technologien nachgewiesen werden. Dies umfasst sowohl technische Aspekte wie verifizierbare Datenhaltung als auch organisatorische Aspekte wie Vertrauen zwischen Geschäftspartnern.

Wir entwickeln heute Software nicht mehr auf der grünen Wiese, sondern wir erweitern und verändern vorhandene Systeme. Dabei wird der Code immer komplexer und sammelt technische Schulden an. Im Entwicklungsteam ist uns das allen klar, aber wie erklären wir dem Management, dass es sinnvoll ist, frühzeitig technische Schulden abzubauen?

In diesem Vortrag berichte ich von meiner Erfahrung aus verschiedensten Kontexten und gebe Empfehlungen, wie die Kommunikationsbarriere zwischen Management und Entwicklungsteams übersprungen werden kann.

Zielpublikum: Architekt:innen, Entwickler:innen, Product Owner, Projektleiter:innen, IT-Management
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Anfänger

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
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Die Session zeigt anhand eines praktischen Beispiels typische Data Pitfalls, die einem bei der Zerlegung eines Monolithen in eine Vielzahl von Microservices mit Sicherheit begegnen werden.
Für jede dieser Herausforderung werden mehrere Patterns als Lösungen vorgestellt und in ihrem jeweiligen Kontext bewertet.