Konferenzprogramm

 

 

 

Das gesamte Konferenzprogramm auf einem Blick? Kein Problem, alle Programminhalte finden Sie hier jetzt auch als praktische PDF-Broschüre ganz bequem zum durchscrollen, downloaden oder ausdrucken:

Zur PDF-Broschüre

 

 

Track: Software Architecture Success Stories

Nach Tracks filtern
Nach Themen filtern
Alle ausklappen
  • Dienstag
    07.02.
  • Mittwoch
    08.02.
, (Dienstag, 07.Februar 2023)
09:00 - 10:30
Di 4.1
Ein Werkzeugkoffer für erfolgreiche(re) Software-Architekten
Ein Werkzeugkoffer für erfolgreiche(re) Software-Architekten

Es ist eine weitverbreitete Erfahrung, dass nur wenige Wege zu einer erfolgreichen Software-Architektur / zu einem erfolgreichen Projekt führen, aber viele Wege zu Problemfällen. Von welchen Ingredienzen hängt aber deren (Miss-)Erfolg ab?

Speziell gefragt: Welche Mittel haben Software-Architekten & -Entwickler in der Hand, um eine erfolgreiche Lösung zu erstellen? Und woran lässt sich erkennen, dass etwas gehörig schiefläuft?

Zielpublikum: Software-Entwickler:innen, Software-Architekt:innen
Voraussetzungen: Erfahrung mit Software-Architektur und Software-Engineering
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Es ist eine weitverbreitete Erfahrung, dass nur wenige Wege zu einer erfolgreichen Software-Architektur / zu einem erfolgreichen Projekt führen, aber viele Wege zu Problemfällen. Wichtig ist insbesondere, von Anfang an die richtigen Weichen zu stellen und möglichst frühzeitig zu erkennen, ob etwas faul ist im Staate Dänemark. Software-Architekten sind dem aber nicht hilflos ausgeliefert, sondern haben im Gegenteil die Möglichkeit, die Entwicklung maßgeblich zu einem Erfolg zu führen.

Von welchen Ingredienzen hängt aber deren (Miss-)Erfolg ab? Speziell gefragt: Welche Mittel haben Software-Architekten & -Entwickler in der Hand, um eine erfolgreiche Lösung zu erstellen? Woran lässt sich erkennen, dass etwas gehörig schiefläuft? Welche Eingangsvoraussetzungen müssen gegeben sein?

Prof. Dr. Michael Stal arbeitet in der Technology-Organisation der Siemens AG, wo er sich mit Software-Architekturen, Geschäftsmodellen und KI beschäftigt. Er ist Professor an der University of Groningen und Chefredakteur von JavaSPEKTRUM.

Michael Stal
Michael Stal
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 14:45
Di 4.2
IT Architecture – the Management Aspect
IT Architecture – the Management Aspect

IT-Architekt, ein Titel im Unternehmen, teils mit, teils ohne Rollenbeschreibung. Welche Aufgaben und Befugnisse die “Architekten” haben, ob es einen oder mehrere gibt, ob sie in Gremien organisiert sind, welche Regeln gelten, all das variiert total.

Meine Meinung ist: IT-Architekt ist eine Management-Aufgabe innerhalb der Organisation und es hilft, eine klare Rollenbeschreibung und eine klare Beschreibung der Gremien einer Organisation zu haben. Im Talk vergleiche und bewerte ich Beispiele aus verschiedenen Organisationen.

Zielpublikum: IT-Mitarbeiter, Software-Entwickler:innen, IT-Management, Produktmanager, QA nerds
Voraussetzungen: Erfahrung in der IT-Produktentwicklung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
IT-Architekt, ein Titel im Unternehmen, teils mit, teils ohne Rollenbeschreibung. Welche Aufgaben und Befugnisse die “Architekten” haben, ob es einen oder mehrere gibt, ob sie in Gremien organisiert sind, welche Regeln gelten, all das variiert total. Meine Meinung ist: IT-Architekt ist eine Management-Aufgabe innerhalb der Organisation und es hilft, eine klare Rollenbeschreibung und eine klare Beschreibung der Gremien einer Organisation zu haben. Im Talk vergleiche und bewerte ich Beispiele aus verschiedenen Organisationen.

Botschaften:
-    Softwareentwicklung ist Teamwork
-    Architekt sein bedeutet Teamworken
-    Exzellente natursprachliche / interkulturelle Kommunikationsfähigkeit ist Voraussetzung
-    Messbarkeit und KPIs helfen
-    Soziale Integrationsfähigkeit ist notwendige Voraussetzung
-    Richtungsleitende dauerhafte Kraft ist hilfreich
-    Überblick und Kooperationsfähigkeit sind nötig
-    Fehler sind gut, oder besser Erfahrungen sammeln
-    Rollenbeschreibungen sind notwendig
-    Gremien Beschreibungen sind notwendig
-    Prozessbeschreibung ist notwendig

Eine Organisation sollte sich selbst beschrieben habe, denn sonst versteht sie sich selbst nicht und neigt dazu, chaotisch und unordentlich zu sein. Verbesserungsprozesse in chaotischen und unordentlichen Organisationen sind fast unmöglich.

Beispiele:
•    Intersoft: 5 mio loc, lange QA-Zyklen
•    NewStore: teamnamen nach Farbe
•    Idealo: CTO & cpo im team
•    Otto: Performance vs Umsatz

Hannes Mainusch - impulsiver nerd-manager.
Dinge, die mich inspirieren, sind innovative Technologien, Röhrenradios und Radfahren. Und ich freue mich, wenn die Menschen um mich herum und ich lernen, besser zu werden. Veränderung beinhaltet Scheitern und Lernen, organisatorische Veränderung beinhaltet die Schaffung einer Lernumgebung. Also versuche ich, offen für neue Herausforderungen zu bleiben und gleichzeitig einen tollen und empathischen Job im Change-Management zu machen.
In den letzten Jahren war ich im IT-Management und Consulting tätig. 2016 haben wir die commitment GmbH & Co. KG als Experiment radikaldemokratischer Unternehmensberatung gegründet.

Johannes Mainusch
Johannes Mainusch
flag VORTRAG MERKEN

Vortrag Teilen

16:15 - 17:15
Di 4.3
The Big Move – a Cloud Modernisation Experience
The Big Move – a Cloud Modernisation Experience

Re-purchasing an application is seen as the top of craftsmanship for cloud migrations. But people have rarely seen such a project in practice. This is the courageous journey of a real consumer product running on expensive infrastructure for years with 2 million active users and more than 6PB of data.

The talk takes you on a journey to a German public cloud and shares all the learnings - about shifting massive data, about terraforming infrastructures, about customizing open source and about all it takes to launch and stay in business.

Target Audience: IT people with no fear of few technical details
Prerequisites: Curiosity about a real public cloud modernisation approach
Level: Advanced

Extended Abstract:
The journey will have the following stages:

Stage 1: How architecture for such a quest looks like and how to start?
Three architecture goals will drive the rest of the journey:
- Efficient scaling
- Minimal run efforts
- Release robust customisation

Stage 2: Customisation of an Open Source product

Stage 3: Migration - decisions and actual experiences during migration

Stage 4: Rollout and staying alive

Bernd Rederlechner ist einer der Principal Lead Architects von T-Systems mit Schwerpunkt "Digitale Lösungen". Er war verantwortlich für die Lieferung von kleinen Innovationsprojekten, aber auch von wirklich großen Landschaftsvorhaben, wo er immer eine Balance zwischen Product Owner, Dev, Ops, Test und Security finden musste. Heute liegt seine Passion im Aufbau von Teams, die digitale Ideen zur Reality machen können - für Kunden und für die Deutschen Telekom.

Bernd Rederlechner
Bernd Rederlechner
flag VORTRAG MERKEN

Vortrag Teilen

17:45 - 18:45
Di 4.4
Architekturikonen in Software. Wegweisende Lösungen im Porträt
Architekturikonen in Software. Wegweisende Lösungen im Porträt

Die Architekturkritik bezeichnet bahnbrechende Bauwerke als Architekturikonen.

In diesem Vortrag greife ich den Begriff auf und diskutiere die Lösungsstrategien einiger prominenter Softwarelösungen. Ich stelle den Architekturzielen die gewählten Entwurfsentscheidungen gegenüber und mache auf diese Weise das Geheimnis ihres Erfolges sichtbar. Sie erwartet eine kleine Galerie prägnanter Architektur-Porträts vom Framework bis zum Quelltext-Editor, von 2002 bis 2020.

Was ist die Sydney-Oper der Softwarearchitektur? Welchen Systemen haben wir Architektur-Stile wie Microservices oder Serverless zu verdanken?

Zielpublikum: In erster Linie alle, die Software entwerfen und entwickeln, Führungskräfte können folgen
Voraussetzungen: Erfahrung in Softwareentwicklungsvorhaben sind von Vorteil
Schwierigkeitsgrad: Anfänger

Stefan Zörner ist Software-Architekt bei embarc in Hamburg. Er wirkt bei Entwurfs- und Umsetzungsfragen mit, unterstützt beim Festhalten von Architektur und beleuchtet Lösungsansätze in Bewertungen. Sein Wissen und seine Erfahrung teilt er regelmäßig in Vorträgen, Artikeln und Workshops. Stefan ist aktives Board-Mitglied im iSAQB und Autor des Buchs „Softwarearchitekturen dokumentieren und kommunizieren“ (Hanser-Verlag).

Stefan Zörner
Stefan Zörner
flag VORTRAG MERKEN

Vortrag Teilen

, (Mittwoch, 08.Februar 2023)
09:00 - 10:45
Mi 4.1
Integrationsarchitekturen auf Basis von Microservices, APIs und Events
Integrationsarchitekturen auf Basis von Microservices, APIs und Events

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.

Sven Bernhardt arbeitet für OPITZ CONSULTING als Chief Architect im Corporate Development Team. In seiner Rolle ist er für das Management des Technologieportfolios und die Entwicklung von Best Practices und Guidelines verantwortlich. Darüber hinaus unterstützt Sven seine Kollegen bei der Implementierung von Softwarelösungen in Kundenprojekten.
Er spricht regelmäßig auf Konferenzen über Technologie- und Architekturthemen und teilt seine Gedanken und Erfahrungen in Artikeln und Blogbeiträgen.

Bücher:
2017 | Dynamikrobuste Architekturen der Digitalisierung: Architecting for the Digital World!
2015 | Design Principles for Process-driven Architectures Using Oracle BPM and SOA Suite 12c

Mit Data Mesh oder Data Lakehouse zu DevDataOps?
Mit Data Mesh oder Data Lakehouse zu DevDataOps?

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.

 

Andreas Buckenhofer arbeitet als Lead Expert "Vehicle Data Platforms" bei Mercedes-Benz Tech Innovation. Daten sind schon immer seine Leidenschaft. Er verfügt über langjährige Erfahrung in der Entwicklung datenintensiver Produkte. Sein Wissen gibt er gerne in internen Vorträgen weiter oder als Sprecher auf Konferenzen. An der DHBW hält er seit vielen Jahren eine Vorlesung über Data Warehousing und Data Management.

Sven Bernhardt
Andreas Buckenhofer
Sven Bernhardt

Vortrag Teilen

Andreas Buckenhofer
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Mi 4.2
Reaktives System zur Erstellung vertrauenswürdiger, zeitnaher Herkunftsnachweise für grüne Energie
Reaktives System zur Erstellung vertrauenswürdiger, zeitnaher Herkunftsnachweise für grüne Energie

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.

Thomas Goetz ist Leiter des TechLabs von PostFinance. Er und sein Team sind zuständig für Innovationen an der Schnittstelle von Geschäft und IT. 
Neben seiner Tätigkeit in Projekten und Linie baute er vor 3 Jahren ein interdisziplinäres Blockchain-Team auf und führt dieses inhaltlich. Er studierte an der Universität Bern Naturwissenschaften und Informatik und absolvierte ein MBA in Business Engineering an der Universität St. Gallen. Er verfügt über langjährige Erfahrung in Finanz- und Eisenbahnindustrie sowie als Dozent in der Nachdiplomausbildung von Ingenieuren.

Oliver Hofer arbeitet im TechLab als IT-Architekt mit Fokus auf Exploration und Innovation. Er hat mehrere Start-ups mitgegründet und in verschiedenen Industrien gearbeitet.

Simon Vogt arbeitet im TechLab als Software-Architekt. Er strebt als Lead Software Engineer nach zuverlässigen, test- und wartbaren, übersichtlichen Lösungen.

Thomas Goetz, Oliver Hofer, Simon Vogt
Thomas Goetz, Oliver Hofer, Simon Vogt
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Mi 4.3
Technische Schulden dem Management erklären
Technische Schulden dem Management erklären

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

Dr. Carola Lilienthal ist Software-Architektin und Geschäftsführerin bei der Workplace Solutions GmbH. Seit 2003 analysiert sie die Zukunftsfähigkeit von Softwarearchitekturen und spricht auf Konferenzen über dieses Thema. 2015 hat sie ihre Erfahrungen in dem Buch „Langlebige Softwarearchitekturen“ zusammengefasst.

Carola Lilienthal
Carola Lilienthal
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Mi 4.4
Shared Data in verteilten Architekturen
Shared Data in verteilten Architekturen

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.

Lars Röwekamp, Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise und Cloud Computing sowie ML/AI, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen.

Lars Röwekamp
Lars Röwekamp
flag VORTRAG MERKEN

Vortrag Teilen

Zurück