Selected talks

Kinder zu bekommen ist das eine, täglich mit ihnen zu leben das andere. So richtig darauf vorbereitet hat mich niemand. Dafür trainiert mich mein Zweijähriger im Bootcamp „Familie" täglich für die Herausforderungen in der Kommunikation zwischen Fach(abteilungen) und IT – sei es bei schwierigen Rahmenbedingungen wie begrenzten Kommunikationszeiten und -herausforderungen beim Spezifizieren oder beim Berücksichtigen der unterschiedlichen Hintergründe der Gesprächspartner.

In diesem Talk teile ich Learnings aus meinem ganz persönlichen Bootcamp „Familie" und gebe Anregungen für die erfolgreiche Abstimmung zwischen Fach- und IT-Seite.

Qualitätsziele helfen uns, Architekturentscheidungen fundierter zu treffen. Die genau richtige Qualität ist jedoch oft subjektiv und ändert sich über die Zeit hinweg. Dies macht das Arbeiten mit und an Qualitätszielen vor allem bei langlebigen Softwaresystemen spannend.

In diesem Vortrag stelle ich eine neue Sicht auf Softwarequalität vor, bei der wir Qualität im evolutionären Kontext betrachten. Als Basis verwende ich das ISO 25010 Qualitätsmodell sowie Wardley Mapping, um die passende Qualität nach Wichtigkeit und Evolutionsstufen zu finden.

Aufzeichnung des Vortrags

In der Anwendungsentwicklung müssen wir heute nicht mehr alles selbst erfinden, sondern wir nutzen Bibliotheken von Drittanbietern. Mit den Vorteilen dieser Bibliotheken geht jedoch auch die Verantwortung einher, sie regelmäßig zu aktualisieren, um potenzielle Sicherheitsrisiken zu minimieren. Die zeitnahe Durchführung dieser Updates, ohne das Überspringen von Releases, reduziert dabei Risiko und Aufwand. In diesem Vortrag wird deswegen Renovate vorgestellt, ein Open-Source-Bot für das automatisierte Updaten von Abhängigkeiten.

In einer Data-Mesh-Architektur werden Datenprodukte entwickelt und zwischen verschiedenen Teams ausgetauscht. Wir brauchen eine skalierbare Möglichkeit, uns auf die Qualität und Stabilität der Daten zu verlassen. Hier kommen Data Contracts ins Spiel. Der Datenanbieter definiert das Schema der bereitgestellten Daten und ihre Qualitätsattribute, aber auch Beispieldatensätze und die domänenspezifische Bedeutung der Attribute. Data Contracts legen außerdem die Nutzungsbedingungen für die Daten fest.

Viele große Unternehmen arbeiten immer noch mit zentralisierten architekturbezogenen Teams. Deren Aufgabe besteht häufig darin, anderen Teams architektonische Spezifikationen vorzugeben und dafür zu sorgen, dass diese Spezifikationen bei der Umsetzung eingehalten werden. Diese Teams werden oft als “Elfenbeinturm-Architektur”-Teams bezeichnet, die darauf abzielen, hochqualifizierte Architekt:innen zu bündeln. Diese Rolle ist auf dem Markt sicherlich nicht in Hülle und Fülle vorhanden. Sie passen jedoch nicht in eine agile Umgebung, in der wir den Teams die Möglichkeit geben wollen, ihre eigenen Entscheidungen zu treffen. Bestimmte Leitplanken sind dennoch notwendig, um sicherzustellen, dass das Gesamtkonstrukt funktioniert. Darüber hinaus können gut gewählte Leitplanken auch den Abstimmungsbedarf zwischen den Teams drastisch reduzieren. Wir müssen diese Teams in die Lage versetzen, den größten Teil der architektonischen Arbeit selbst zu erledigen, und gleichzeitig dafür sorgen, dass die einzelnen Teile zusammenpassen. An dieser Stelle kommen Team Topologies ins Spiel, eine von Matthew Skelton und Manuel Pais eingeführte Methode. Dort gibt es den Teamtyp des “Enabling Teams”, welches – knapp zusammengefasst – andere Teams mit Wissen und Methodik unterstützt.

Dieser Vortrag gibt Ihnen einen Überblick über diesen Wandel sowie eine praktische Anleitung, wie Sie ein zentralisiertes Architekturteam in ein Enabling Team umwandeln können, dessen Aufgabe es ist, die Architekturarbeit in anderen Teams zu verbessern. Sie werden lernen:

• Welche Stakeholder Sie in diesen Prozess einbeziehen sollten
• Warum das künftige Enabling-Team ebenfalls befähigt werden muss und wie man das macht
• Wo häufige Fallstricke auf dieser Reise liegen
• Warum diese Reise auf agile Weise mit kontinuierlichem Lernen und Retrospektiven durchgeführt werden muss

Dieser Vortrag wird auch viele Beispiele aus der Praxis enthalten, die eine solche Transformation begleiten.

Data Mesh is a socio-technical approach to data management that enables teams to perform data analysis independently within their domain to make data-driven decisions. Data mesh promotes sharing data with other teams as data products and defined data contracts.

Data Mesh adopts the principles from Domain-driven Design, Team Topologies and Microservices to the data world. However, it has many organizational implications, such as ownership and federated governance.

In this talk, Simon and Jochen from INNOQ describe how a Data Mesh architecture can be implemented in practice, which organizational transformations will be necessary and which technologies are suitable in this context.

Agenda This talk is part of Softwareaarchitektur Hamburg Meetup

• 18:30 Open doors
• 19:00 Talks (ca. 60 min + Q&A)
• Afterwards: Networking

Wardley Maps sind eine Technik zur Visualisierung und zum Verständnis der Weiterentwicklung von Systemen, Services und Entwicklungsteams. Sie sind ein nützliches Werkzeug für Softwareentwickelnde, um die wichtigsten Komponenten eines Systems zu identifizieren und zu verstehen, wie sie sich im Laufe der Zeit verändern.

In diesem Vortrag führe ich Euch in die grundlegenden Konzepte von Wardley Maps und den Prozess der Erstellung einer Map für ein Softwaresystem ein. Ich werde auch vorstellen, wie Wardley Maps verwendet werden können, um Möglichkeiten für Innovationen zu identifizieren und wie man sie für die Kommunikation des aktuellen Zustands und der zukünftigen Ausrichtung eines Systems nutzen kann.

Ich gebe Beispiele dafür, wie ich Wardley Maps in realen Softwareentwicklungsprojekten einsetze und wie ich daraus kleine und große strategische Entscheidungen ableite. Obwohl Wardley Maps kein Allheilmittel sind, kann es eine nützliche Technik im Werkzeugkasten von Softwareentwickler:innen sein, um Ideen für die Weiterentwicklung von Softwaresystemen mit anderen – insbesondere der Geschäftsseite – zu besprechen.

Schnelle Software Delivery hängt heute u.a. an der Etablierung von autonomen Teams, die unabhängig voneinander Funktionalität entwickeln und liefern können. Aber wie schaffen wir es, dass diese Teams nicht in unterschiedliche Richtungen laufen, sondern ein gemeinsames Architektur- und Technologieverständnis entwickeln, aber gleichzeitig einen eigenen Entscheidungsspielraum haben?Um diese Fragen zu beantworten, diskutieren wir Architektur-Prinzipien, Makroarchitektur und Service Templates (aka Golden Path, Paved Road, Sensible Defaults, Follow the Trail) und wie diese Ideen hier helfen können, aber auch wo deren Fallstricke liegen

Key takeaways

• You will learn about the importance of aligning teams with architecture and domains
• You will learn two methodologies for visualizing and talking about sociotechnical architectures: Team Topologies and Context Maps
• You will learn how to combine Team Topologies and Context Maps together

Team Topologies and Context Maps are two interesting approaches to visualize sociotechnical architectures. However, using each method on its own, you will not be able to capture a truly holistic view of the system as a whole, but you can use both in combination and this is what this talk is about. This talk will introduce a Systems Thinking perspective on those two approaches and explain how both can be leveraged in combination to get a deep dive on many interactions in a system of teams and software. Those interactions include: - team relationships - team dependencies - propagation of domain models - governance related communication - provisioning of APIs services. However, we will also look at the components of the system with Team Topologies being team centric and Context Maps being bounded context centric. I will finally explain how you can use both methods to visualize alignments between domains, bounded contexts and teams. This talk assumes that you have a basic understanding of strategic Domain-Driven Design (esp. Bounded Contexts and Context Maps) open_in_new

Moderne Datenarchitekturen verwenden das Konzept eines Datenprodukts, um die Bereitstellung und Nutzung von Daten besser zu organisieren.

Ein Datenprodukt bildet eine logische Einheit um fachlich relevante Daten und umfasst alle Komponenten, um diese Daten zu speichern, aufzubereiten, zu aggregieren, zu erklären und für die Nutzer:innen so einfach wie möglich zugänglich zu machen.

Jochen Christ, Autor von datamesh-architecture.com, zeigt, wie ein Datenprodukt in der AWS-Cloud implementiert werden kann, welche Funktionen eine gute Datenplattform zur Verfügung stellen sollte, und wie Datenprodukt-Governance mit dem Data Mesh Manager unterstützt wird.

Große Sprachmodelle (LLM) sind eine neue Technologie, die die Welt in kürzester Zeit erobert hat. KI-Chatbots wie ChatGPT haben KI durch die Verwendung natürlicher Sprache steuerbar und damit für die breite Öffentlichkeit zugänglich und äußerst nützlich gemacht.

Die meisten Menschen haben wahrscheinlich schon mit diesem oder einem anderen Chatbot experimentiert und ähnliche Erfahrungen gemacht: Sie wissen auf fast jede Frage eine Antwort, schreiben detaillierte Texte und reagieren sogar auf Gegenfragen. Dabei gibt es ein großes Problem: Die Chatbots halluzinieren, d.h. sie erfinden Inhalte, die richtig klingen, aber nicht richtig sind. Außerdem ist es aufgrund der riesigen Menge an Trainingsdaten nicht mehr möglich, zu rekonstruieren, woher eine Information stammt.

Wir haben uns mit diesem Problem auseinandergesetzt und versucht, eine Lösung zu finden, bei der ein Chatbot seine Antworten innerhalb einer bestimmten Domäne aufbaut und Quellen für die Herkunft der verwendeten Informationen aus der Domäne angibt. Solche wissensbasierten Chatbots können in praktisch jedem Bereich eingesetzt werden, z. B. zum Chatten mit Dokumentationen, Inhalten einer Datenbank oder einer Website, unter Verwendung natürlicher Sprache, ohne das Risiko von Halluzinationen. Wir haben auch Ideen wie die Verwendung von Open-Source-LLMs (z. B. LLama2), Skalierbarkeit und Kostenmanagement untersucht.

Die Hotspot-Analyse ist eine weit verbreitete Methode zur Untersuchung bestehender Softwaresysteme, mit dem Ziel, Verbesserungsarbeiten am vorhandenen Code gezielt zu priorisieren. Sie ermöglicht die Darstellung der Verbesserungsdringlichkeit und Code-Komplexität für die gesamte Codebasis in einer anschaulichen Visualisierung, aus der sich schnell die wichtigsten Schwerpunkte ableiten lassen sollen.

In diesem Vortrag werfen wir einen Blick hinter die Kulissen dieser Analysemethode. Wir werden die technischen Aspekte der Analyse beleuchten, mögliche Fallstricke aufdecken und die weiteren Potenziale dieser faszinierenden Analysetechnik erkunden. Alle, die schon immer einmal wissen wollten, was hinter den bunten Visualisierungen der Analyse-Tools steckt, finden hier wertvolle Einblicke – auch für ihre ganz eigenen Analyseideen.

Viele Architektur-Reviews betrachten häufig strukturelle und technische Entscheidungen vor dem Hintergrund von Qualitätsanforderungen. Und das ist auch gut so! In den letzten Jahren häufen sich jedoch Qualitätsanforderungen, die nicht nur rein architektonisch gelöst werden können. Dazu zählen unter anderem sehr schnelle Release-Zyklen oder minimale Abstimmungen zwischen Teams (aka Team-Autonomie). Wir behaupten: Architektur-Reviews können auch untersuchen, inwieweit eine Software-Architektur autonome Teams mit klaren Grenzen für eigene fachliche Entscheidungen unterstützt.

An dieser Stelle setzt unser Workshop an: Wir stellen vor, wie man Architektur-Reviews mit einer ganzheitlichen Perspektive betreiben kann. Dabei stellen wir einerseits kurz klassische Review-Methoden vor, z.B. ATAM, und legen einen Schwerpunkt darauf, wie man diese so erweitern kann, dass auch Perspektiven wie Domänen und Teams mit berücksichtigt werden. Auch das Alignment zwischen vertikalen Modulen in der Architektur, Domänen und Teams wird dabei beleuchtet. Wir werden hierbei diverse methodische Elemente aus dem Softwarearchitektur-, Domain-Driven Design- und Team Topologies-Umfeld aufgreifen und unsere eigenen Erfahrungen bei der Durchführung solcher Reviews einbringen. Zudem wird der Workshop auch auf Stakeholder der Bewertung und politische Fallstricke solcher ganzheitlichen Reviews eingehen.

Diese Session zeigt auf, wie sich die Ideen von DevOps und DDD ergänzen und warum man beide Ansätze kombinieren sollte. Wir werden dabei auf die kulturellen Aspekte beider Ansätze eingehen und herausarbeiten, dass die Kombination aus DevOps und DDD zu sehr gut geschnittenen cross-funktionalen Teams mit Ende-zu-Ende-Verantwortung für einen klar abgegrenzten fachlichen Bereich führt.

Der Vortrag zeigt zudem auf, welche Wege sie beschreiten können, damit aus einem “you build it, you run it” ein “you design it, you build it and you run it” wird.

Zielpublikum: Architekt:innen, Projektleiter:innen, Entscheider Voraussetzungen: DevOps- und DDD-Grundlagen sind vorteilhaft Schwierigkeitsgrad: Fortgeschritten

Team Topologies and Context Maps are two interesting approaches to visualize sociotechnical architectures. However using each method on its own you will not be able to capture a truly holistic view of the system as a whole but you can use both in combination and this is what this talk is about. This talk will introduce a Systems Thinking perspective on those two approaches and explain how both can be leveraged in combination to get a deep dive on many interactions in a system of teams and software.

Those interactions include:

• team relationships
• team dependencies
• propagation of domain models
• governance related communication
• provisioning of APIs / services

However we will also look at the components of the system with Team Topologies being team centric and Context Maps being bounded context centric. I will finally explain how you can use both methods to visualize alignments between domains, bounded contexts and teams. This talk assumes that you have a basic understanding of strategic Domain Driven Design (esp. Bounded Contexts and Context Maps)

Livestream: https://youtu.be/xbH2rxXsaI0

Wardley Maps is a technique for visualizing and understanding the evolution of systems, services, and development teams. It is a valuable tool for software developers to identify the key components of a system and understand how they change over time.

In this talk, I will introduce you to the fundamental concepts of Wardley Maps and the process of creating a map for a software system. I will also discuss how Wardley Maps can be used to identify opportunities for innovation and how to use it for communicating the current state and future direction of your system.

I provide examples of how I use Wardley Maps in real-world software development projects, and how I derive strategic decisions from them. Although Wardley Maps is not a silver bullet, it may be a useful technique in your toolbox where you need a bird’s eye view of your system and discuss ideas for its evolution with others – especially businesspeople.

Häufig wird im Zusammenhang mit Spring Boot das Wort “Magie” erwähnt. Tatsächlich können der Einsatz von Annotationen und die sonstigen Mechanismen, die unter der Haube von Spring Boot werkeln, gerade auf Menschen ohne jahrelange Spring Erfahrung magisch wirken. Diese Session zeigt, aus welchen Bestandteilen Spring Boot besteht und wie diese im Detail funktionieren. Dabei wird auch klar, welche Arbeit uns das Framework abnimmt. Am Ende angekommen wirkt das ganze dann nicht mehr magisch, sondern eher wie mit Wasser kochen.

In Unternehmen werden Datenanalysen intensiv genutzt, um aus Geschäftsdaten wertvolle Einsichten zu gewinnen. Warum nutzen wir als SoftwareentwicklerInnen Datenanalysen dann nicht auch für unsere eigenen Daten?

In diesem Workshop stelle ich Vorgehen und Best Practices von Software Analytics vor. Wir sehen uns die dazugehörigen Open-Source-Werkzeuge an, mit denen sich Probleme in der Softwareentwicklung zielgerichtet analysieren und kommunizieren lassen.

Im Praxisteil mit Jupyter, pandas, jQAssistant, Neo4j & Co. erarbeiten wir gemeinsam wertvolle Einsichten aus Datenquellen wie Git-Repositories, Performancedaten, Qualitätsberichten oder auch direkt aus dem Java-Programmcode. Wir suchen nach besonders fehleranfälligem Code, erschließen No-Go-Areas in Altanwendungen und priorisieren Aufräumarbeiten entlang wichtiger Programmteile.

Development teams usually don’t like to write documentation. By way of contrast, a certain amount of documentation often proves useful in the long run. Why not give the established Canvas pattern a chance to shine in software architecture?

In this talk, you will learn a highly pragmatic approach to document and communicate the most important aspects of your architecture (and implementation). It is compatible with the established arc42 template, but significantly shorter. Prepare yourself for an example-ridden talk and plenty of practical tips that will make documentation fun and productive!

Backing article: Concise Documentation – Revisited

In his book “The Software Architect Elevator” Gregor Hohpe uses the analogy of an elevator in a high building for the daily work which software architects should be doing: They are supposed to talk to folks who build and maintain stuff in the engine room but also make sure that the managment which is residing on the penthouse floors understand and gain interest in what is happening in the engine room.

In my talk I will build upon Gregors ideas and show you how you can leverage ideas from Domain Driven Design in this daunting communication tasks. But rest assured: I will not only present the obvious strategic Domain Drivend Design elements like core / supporting / generic subdomains here. We will go deeper and explore links to other initiatives in an org like DevOps, Agile and / org Design Thinking as well which are of interest for the leadership of an organization.

We as a community should get better at this topic because Domain Driven Design needs a healthy, blame free and safe environment in order to flourish and this environment needs to be established and lived by the leadership folks.

PS: The talk idea and usage of Gregors elevator analogy have been approved by Gregor

Data Science gains new insights from business data. As software developers, why don’t we use Data Science to analyze our data from our software systems, too?

In this session, I will talk about approaches to mine software data based on the many ideas from the Data Science field. We’ll also look at the standard tools used in this area to analyze and communicate software development problems easily. With tools such as computational notebooks, data analysis frameworks, visualization, and machine learning libraries, we make hidden issues visible in a data-driven way.

Attendees will learn how to leverage scientific thinking, manage the analysis process, and apply literate statistical programming to analyze software data in an understandable way. The main part will be hands-on live coding with Open Source tools like Jupyter notebook, Python, pandas, jQAssistant, and Neo4j. I’ll show which new insights we can gain from data sources such as Git repositories, performance measurements, or directly from source code.

Ein großer Teil der Softwareentwicklung besteht aus Wartungsarbeit. In Ausbildung und Studium haben wir oft jedoch nur die Neuentwicklung kennengelernt. Überforderung droht, Frust baut sich auf und die Freude an der Softwareentwicklung geht verloren. Das muss nicht sein!

Wir stellen die Rolle “Evolutionist” vor, welche sich auf die qualitativ angemessene Weiterentwicklung bestehender Systeme fokussiert. Wir blicken auf das notwendige Skill- und Mindset sowie erste Praktiken, um mit großen und langlebenden Softwaresystemen zurecht zu kommen.

Viele große Unternehmen setzen noch immer auf zentralisierte, architekturbezogene Teams. Oftmals geben diese Teams anderen Teams architektonische Vorgaben und sorgen dafür, dass diese Vorgaben in der Praxis eingehalten werden. Solche Teams werden häufig als „Elfenbeinturm-Architektur”-Teams bezeichnet, die darauf ausgerichtet sind, hochqualifizierte Architekten und Architektinnen zu bündeln. Solche Rollen sind auf dem Markt zwar selten, passen aber nicht in eine agile Umgebung. In der agilen Welt möchten wir den Teams die Freiheit geben, eigene Entscheidungen zu treffen. Dennoch sind bestimmte Leitplanken erforderlich, um das Gesamtkonstrukt funktionsfähig zu halten. Richtig gewählte Leitplanken können zudem den Koordinationsaufwand zwischen den Teams erheblich verringern. Unser Ziel sollte es sein, die Teams zu befähigen, den Großteil der architektonischen Arbeit selbst zu übernehmen, während gleichzeitig sichergestellt wird, dass alle Komponenten zusammenpassen. Hier setzt das Konzept der Team Topologies von Matthew Skelton und Manuel Pais an. Insbesondere der Teamtyp des „Enabling Teams”, welcher, kurz gesagt, andere Teams mit Wissen und Methodik unterstützt.

In diesem Vortrag erhältst Du einen Überblick über diesen Wandel sowie praktische Tipps, wie Du ein zentrales Architekturteam in ein Enabling Team umwandeln kannst. Das Hauptziel dieses Teams ist es, die Architekturarbeit in anderen Teams zu verbessern. Du wirst lernen:

• Welche Stakeholder Du in diesen Prozess einbeziehen solltest
• Warum und wie das zukünftige Enabling-Team ebenfalls befähigt werden muss
• Wo typische Fallstricke dieser Transformation lauern
• Warum dieser Wandel auf agile Weise, geprägt von kontinuierlichem Lernen und Retrospektiven, stattfinden sollte

Zudem werden im Vortrag zahlreiche Praxisbeispiele vorgestellt, die diesen Transformationsprozess begleiten.

Manche Entscheidungen beim Entwurf und der Evolution von Softwarearchitekturen lassen sich nicht immer rational begründen. Zahlen, Daten und Fakten sprechen klar für die eine Lösung, jedoch wird sich zu oft “aus dem Bauch heraus” für die andere Lösung entschieden. Was treibt uns hier an? Welche unsichtbaren Kräfte wirken hier auf uns ein, ohne dass wir es merken?

In diesem Talk betrachten wir ein spannendes Feld, welches in der Softwarearchitekturarbeit bisher wenig präsent ist: Behavioral Economics. Wir sehen uns an, woher es kommt, dass wir uns in manchen Situationen von unserem eigenen Gehirn austricksen lassen. Wir lernen aber auch, wie wir uns in der täglichen Arbeit als Softwarearchitekt:innen etwas besser davor schützen. Dazu stelle ich Techniken und Workshop-Formate vor, welche einige Denkfallen vermeiden.

Das Buch Team Topologies von Matthew Skelton und Mauel Pais hat sich in den letzten drei Jahren als Referenz für den Entwurf und vor allem auch die Evolution von Delivery Organisationen etabliert. Im Kern werden in Team Topologies vier fundamentale Team-Arten und drei grundlegende Team-Interaktionsformen definiert und in einen evolutionären Ansatz gegossen.

Seit ca. einem Jahr gibt es zudem noch das unFIX Modell von Jurgen Appelo, welches an einigen Stellen stark von Team Topologies beeinflusst ist aber zusätzliche Facetten beleuchtet.

In diesem Vortrag werden beide Ansätze vorgestellt und miteinander verglichen. Des Weiteren gehen wir darauf ein, wie beide Ideen in der praktischen Arbeit zum Einsatz kommen können.

‍

Wir sprechen in unserem Vortrag darüber, was soziotechnische Systeme sind, grenzen den Begriff ein und nähern uns den Herausforderungen, denen wir gegenüberstehen, wenn sich Technologie und soziale Systeme verflechten.

Die Prinzipien hinter der DevOps-Bewegung sind schon recht alt. Dennoch haben die meisten Unternehmen nach wie vor Probleme damit, DevOps-Praktiken lösungsorientiert anzuwenden. Dadurch bleiben viele der Vorzüge auf der Strecke und die Qualität der zu entwickelnden Produkte sinkt.

Im halbtägigen Webinar mit Anja Kammer und Sven Johann lernen Sie anhand praktischer Beispiele, wie Sie Wissens- und Kompetenzsilos auflösen. Mit Value Stream Mapping und weiteren Techniken können Sie dann Ihre Prozesse analysieren und Flaschenhälse ihrer Software-Delivery identifizieren. Abschließend lernen Sie mit Team Topologies, Community of Practice und dem Spotify-Modell verschiedene, gut funktionierende Praxisbeispiele kennen.

In verteilten Systemen eignen sich asynchron entkoppelte Schnittstellen, um Daten zu replizieren und um Domain Events auszutauschen. Bei asynchronen Schnittstellen denkt man dabei häufig sofort an Message Broker wie Apache Kafka, RabbitMQ und ähnliche Technologien.

Dies führ allerdings zu Komplexität und technologischen und organisatorischen Abhängigkeiten.

Dabei können asynchrone Schnittstellen auch ohne zusätzliche Middleware-Systeme einfach über HTTP-APIs realisiert werden.

Wir schauen uns ATOM, Server-Sent Events und Long-Polling-Ansätze wie REST-Feeds näher an und diskutieren die Anforderungen an solche APIs.

Mit Java 17 gibt es seit dem 14.9. ein neues Long-Term-Support Release, das auf Java 11 folgt. Obwohl die Möglichkeit bestand, alle sechs Monate auf das jeweils aktuellste Zwischenrelease zu migrieren, haben viele auf genau dieses neue LTS-Release gewartet. Bei einem Wechsel kommen jetzt natürlich alle neuen Features der letzten 3 Jahre zusammen. Darum wollen wir uns in diesen 45 Minuten die Zeit nehmen, um uns die, meiner Meinung nach, wichtigsten Features gemeinsam anzuschauen.

Git ist heute das wohl am weitesten verbreitete Versionskontrollsystem. Die Meisten verwenden aber nur wenige Features wie Commit, Push, Branch und Merge. Für Problemlösungen werden irgendwelche Umwege beschritten, da gar nicht bekannt ist, dass es dafür Hausmittel gibt.

In diesem Vortrag möchte ich von einigen dieser verborgenen Schätze berichten und zeigen, wann es Sinn macht, diese zu verwenden. Wir werden uns unter anderem auf die Suche nach Commits machen, die unsere Anwendung kaputt gemacht haben, Encoding-Problemen entgegentreten, verschiedene farbige Darstellungen unserer Historie ausprobieren, Repositorys aus anderen Versionskontrollsystemen (SVN) importieren und dabei Daten und Inhalte filtern und unsere Konfigurationen aufräumen.

Einiges davon könnt ihr sicherlich in euren Arbeitstag mitnehmen.

Aber verdient solch ein Team eigentlich diese Bezeichnung und was ist der Unterschied zwischen Operations- und Plattform-Teams?

In diesem Vortrag spreche ich außerdem darüber, was interne Development Plattformen eigentlich ausmachen, warum ein Operations-Team keine solche Plattform anbieten kann und was das ganze eigentlich mit DevOps und Einhörnern zu tun hat.

“GitOps ist doch nichts anderes als Infrastructure-as-Code.” Dieses Missverständnis von GitOps hält sich hartnäckig und ist vermutlich der Grund, weshalb das Verständnis über die Vorteile von GitOps noch nicht bei allen Entwickler:innen angekommen ist. Git wird dabei als Schnittstelle für einen Operator verwendet, der Deployment- und Betriebsaufgaben innerhalb der Zielumgebung ausführt. In dieser Session räume ich mit Vorurteilen auf und zeige, welche Fallstricke bei der Anwendung dieser neuen Deployment- und Betriebsstrategie lauern. Außerdem gebe ich Tipps bei der schrittweisen Transformation – weg von traditionellen CI/CD Pipelines hin zu Cloud-Native Deployment und Betrieb mit GitOps.

Bounded Contexts gehören zum strategischen Domain-Driven Design und sind derzeit in aller Munde. Viele Teams versprechen sich durch die Modularisierung mit Bounded Contexts einen guten fachlichen Schnitt für ihre Software. Es stellt sich jedoch häufig die Frage, wie wir denn überhaupt zu einem guten Bounded-Context-Schnitt kommen.

Genau um diese Frage dreht sich der Vortrag. Ich werde zeigen, wie man mithilfe kollaborativer Modellierungsmethoden (z.B. Event Storming) eine Abgrenzung seiner Problemdomäne erreichen kann und wie man von dort unter Berücksichtigung verschiedener Perspektiven (Regeln, Sprache, Schnittstellen, etc.) zu einem ausgewogenen Bounded-Context-Schnitt kommt.

Langsame Entwicklung? Unter Last ächzende Server? Unglückliche User? Es gibt viel anzupacken in der Softwareentwicklung! Aber wo anfangen?

In diesem Vortrag gebe ich eine Einführung in den systematischen Umgang und der Lösung von vertrackten Situationen für Softwarearchitekt:innen. Wir sehen uns fundamentale Denkfehler an, die Problemlösende bereits bei der Sammlung und der Formulierung von „Problemen“ oft begehen. Damit gewappnet, suchen wir systematisch nach den echten Knacknüssen. Wir nutzen die „Landkarte der Probleme“, um zusätzlich Ursachen und Auswirkungen in Beziehung zu setzen. Der neu gewonnen Überblick erlaubt es dann, die uns möglichen Maßnahmen zu finden, die ein Softwaresystem immer mehr ein kleines Stückchen besser machen.

Historisch gewachsene Softwaresysteme befinden sich häufig in einem hybriden Betriebs-Setup, das die Vorteile verschiedener Betriebsplattformen nutzt. Legacy-Systeme werden häufig aufgrund bestimmter Compliance-Anforderungen für Datenschutz und Sicherheitsprüfungen On-premises betrieben oder schlicht, weil sie technisch nicht in eine dynamische Betriebsumgebung passen. Weniger kritische und neu entwickelte Systeme finden ihren natürlichen Weg in die Public oder Private Cloud. Mit der Verteilung der Systemkomponenten auf unterschiedliche Betriebsplattformen und dem Wachstum der IT-Organisation wachsen jedoch auch die Herausforderungen, Compliance effektiv sicherzustellen. Zu den wirksamsten Maßnahmen zählen unserer Erfahrung nach die Schaffung unterstützender Teamstrukturen und die Anpassung der Software-Delivery-Prozesse.

Das Entwickeln von komplexen CI/CD-Pipelines gestaltet sich oft mühsam, da wir bei Änderungen immer wieder den Lauf der Pipelines abwarten müssen. Besonders für Teams mit einem Fokus auf Infrastruktur-, DevOps- und Plattform-Themen sind Pipelines häufig ein zentraler Aspekt ihrer Produkte und schnelles, iteratives Arbeiten ist dort essenziell. Aber wäre es nicht generell großartig komplette Pipelines lokal laufen lassen zu können? Genau da setzt dagger.io an. Durch clevere Kombination von Containern als Laufzeitumgebung für Build-Steps und der (Dependency-)Graph-Execution-Engine BuildKit (Ja, die aus Docker) entsteht ein sehr flexibles Buildsystem, welches sich über SDKs nativ in gewohnten Programmiersprachen verwenden und erweitern lässt. Es ist keine neue Syntax zu lernen und wer schon mit Containern gearbeitet hat, kann die grundlegenden Konzepte schnell erfassen.

Im Talk schauen wir an einem Beispiel auf die verwendeten Konzepte / Komponenten und lernen wie die Brücke zwischen Buildsystem, CI/CD-Server und Plattform geschlagen werden kann. Und das alles ohne YAML.

Data Mesh ist ein neuer sozio-technischer Ansatz für eine dezentrale Datenarchitektur mit dem Ziel, auch in großen Unternehmen Mehrwert aus Daten zu schöpfen. Im Vortrag geht es um die vier grundlegenden Prinzipien von Data Mesh. Es wird auch explizit darauf eingegangen, was Data Mesh nicht ist. Anschließend lernen wir eine Methodik kennen, um das Herzstück von Data Mesh: ‘Daten Produkte’ zu designen.

Flutter ist ein Cross-Plattform UI-Framework, das in den letzten Jahren immer mehr an Popularität gewinnt. Flutter verspricht aus einer Codebase Apps für IOS, Android, Web, Desktop, MacOS, Linux & Embedded erzeugen zu können, die mit einer ähnlichen Performance wie native Apps laufen. Dem werde ich in dem Vortrag auf den Grund gehen und Empfehlungen geben für welche Anwendungsfälle Flutter eine sinnvolle Wahl ist.

Developing innovative software products starts with an understanding that AI/ML should solve a real problem. However, the whole process, from identifying the use case to the introduction of ML models in the company, is not trivial. Larysa will talk about EventStorming and the ML Design Canvas, which help domain experts and developers get a shared understanding of a business domain and identify use cases for AI/ML technologies. We formulate each use case as an ML problem using the ML Design Canvas.

Wir kennen das alle, die neue Unternehmensstrategie liest sich auf den ersten Blick aufregend: mehr Kundenfokus, bessere Produkte bei gleichzeitiger Kostensenkung. Die neue IT-Strategie schlägt dazu eine Cloud-native-Transformation vor, um diese Ziele zu erreichen. Hierzu gehören die neuesten Cloud-Technologien, Self-Service Infrastruktur und Two-Pizza Teams, die kontinuierlich neue Features ausliefern. Natürlich all das, während der Chaos Monkey munter wütet. Aber wie sieht die Welt aus, fünf Jahre später? Wir haben keines der Unternehmensziele erreicht, nur die Infrastrukturkosten sind explodiert.

Um tragfähig in die Cloud zu gehen, bringt oft ein alleiniger Fokus auf neueste Cloud-Technologien nicht den erhofften Erfolg, sondern es braucht auch unterstützende Teamstrukturen und Interaktionsmodi für Entwicklungsteams. Aus unserer Consulting-Praxis bringen wir realistische Fallstricke mit und zeigen, wie wir sie überwunden haben oder besser überwunden hätten. Wir sprechen dabei über Ideen aus Team Topologies, Produktmanagement und interne Entwicklungsplattformen.

Um Anwendungen zu deployen haben sich Container mittlerweile flächendeckend etabliert. Doch bevor wir einen Container deployen können müssen wir diesen erst einmal bauen. Hierzu gibt es innerhalb des Java-Universums mittlerweile eine große Anzahl an Möglichkeiten. Neben dem bauen gibt es zudem den ein oder anderen Fallstrick um einen Java-Prozess sauber innerhalb des Containers laufen zu lassen.

In dieser Session schauen wir uns deshalb mehrere Wege an eine kleine Spring Boot Anwendung in einen Container zu packen und diese anschließend sauber in diesem auszuführen. Die vorgestellten Tools und Tipps können dabei fast alle auch auf eine nicht Spring-Anwendung angewandt werden.

Das Repository mit Beispielcode ist unter https://github.com/mvitz/javaspektrum-spring-container zu finden.

In diesem Vortrag durchleuchten wir das „Es kommt drauf an!“ etwas genauer. Dazu nutzen wir das Denk- und Kommunikationswerkzeug „Wardley Maps“. Wardley Maps sind evolvierende Strategielandkarten, welche ein kontextspezifisches Situationsbewusstsein für die eigenen Softwaresysteme schaffen. Sie bieten uns einen Ort zum Diskutieren: Welches Entwicklungspraktiken wollen wir einsetzen? Welches Vorgehensmodell ist das Richtige? Auf welche Technologie sollen wir umstellen? Was bauen wir selbst und was holen wir uns woanders?

Mit Wardley Maps erstellen wir für diese Art von Fragen Landkarten, um unsere eigene Situation besser verstehen zu können. Somit lernen wir unser eigenes „Es kommt drauf an!“ besser kennen, um in Zukunft weniger oft den letzten Hypes zu verfallen.

Der Umfang der MLOps-Prozesse und -Technologien hängt von dem AI „Maturity Level“ der jeweiligen Organisation ab. Das Umsetzen von kanonischem MLOps kann zu einer unnötigen Komplexität in der Architektur und Organization führen. Das “AI Readiness”-Framework definiert den Reifegrad einer Organisation bei der Nutzung von ML/AI und ordnet es in eine der drei Stufen ein: Tactical, Strategic und Transformational. In dem Vortrag gehe ich auf die drei “AI-Readiness”-Stufen ein und zeige, wie man eine MLOps Roadmap ableitet.

Durch KI-Systeme wie ChatGPT werden auch als komplizierter eingestufte Angriffe heutzutage immer leichter. Diese neue Generation von KI-unterstützten Angreifern und Angreiferinnen sind effektiver als vorausgehende Generationen und können Organisationen ernsthaft bedrohen.

Der Vortrag zeigt die Methoden auf, die von der neuen Generation von KI-unterstützten Angreifern und Angreiferinnen eingesetzt werden können, beschreibt die Herausforderungen der Erkennung und Abwehr und teilt Best Practices für den Schutz von Systemen und Daten.

Ein Einstieg in die visuelle Welt des strategischen Denkens für Softwareentwickelnde

Wardley Maps ist eine Methode, um dein Situationsbewusstsein für Softwaresysteme zu verbessern und deine nächsten Schritte bei Umbauarbeiten zu motivieren: Warum sollten wir besser nicht mehr unser liebgewonnenes, selbstgeschriebenes Logging-Framework weiterentwickeln? Warum müssen wir uns nun plötzlich doch um Dokumentation kümmern? Wie schaffen wir es, unseren Marktmitbegleitern einen Schritt voraus zu sein? Mit Wardley Maps werden komplexe Zusammenhänge zwischen Business und Technik visualisiert und nachvollziehbare Lösungen für die Zukunft aufgezeigt.

Der Vortrag bietet dir anhand zahlreicher Beispiele und Erfahrungen aus dem Entwicklungsalltag einen praxisnahen Einstieg in die visuelle Welt des strategischen Denkens mittels Wardley Maps. Abgerundet wird der Vortrag mit zahlreichen Tipps und Tricks für die nächsten, eigenständigen Schritte.

Aufzeichnung des Talks auf Vimeo: https://vimeo.com/875184620

“Stellt euch vor, ihr seid Teil eines kleinen Teams von vier Softwareentwickler:innen, die von zu Hause aus arbeiten. Ihr trefft euch jeden Tag um 9 Uhr in eurem Zoom-Teamraum. Nach dem obligatorischen Kaffee und etwas Smalltalk wählt ihr die wichtigste User Story aus, diskutiert diese gemeinsam und beginnt dann mit der Umsetzung. Eine Person teilt den Bildschirm und fungiert als Typist, während die anderen über die Umsetzung diskutieren und dem Typist Anweisungen geben. Nach 10 Minuten übergibt der Typist seine aktuelle Arbeit an den nächsten Typist. Dies wird so lange wiederholt, bis die User Story fertig ist, woraufhin ihr die nächst-wichtige User Story auswählt. Um 17 Uhr haltet ihr inne, reflektiert kurz gemeinsam über den Tag und macht dann Feierabend. Klingt verrückt? Ich habe das über drei Jahre lang gemacht. Und ich möchte nicht mehr anders arbeiten. In diesem Vortrag möchte ich euch unsere Geschichte erzählen. Ich möchte euch erzählen, wie wir zusammengearbeitet haben und was die Konsequenzen für uns waren. Kurz gesagt, ich möchte euch erzählen, wie wir trotz Homeoffice zusammengewachsen sind. Aber lasst mich an dieser Stelle ein Wort der Warnung aussprechen: Wenn ihr diese Art der Zusammenarbeit einmal ausprobiert habt, werdet ihr vielleicht nie wieder zurückkehren können!”

Bio

Dr. Simon Harrer ist ein neugieriger Tech Lead bei INNOQ, der es liebt, zusammenzuarbeiten und sein Wissen zu teilen. In seinem letzten Projekt entdeckte er seine bevorzugte Arbeitsweise, nämlich Remote Mob Programming, für die er natürlich eine Website und ein kurzes Buch als Co-Autor verfasste und dabei Remote Mob Programming einsetzte. Neben seinen typischen Beratungsprojekten coacht er heute Remote-Teams, damit sie nicht nur besser zusammenarbeiten, sondern auch zusammenwachsen.

Auf Basis von über 6 Jahren Java Lehre an der Uni Bamberg und dem Korrigieren von unzähligen Java-Aufgaben haben wir - Jörg Lenhard, Linus Dietz und Simon Harrer - ein Buch geschrieben, welches die typischen Fehler in einer innovativen Vorher/Nachher-Darstellung aufzeigt und erklärt: Java by Comparison. Durch diese Vergleiche können Einsteigerinnen und Einsteiger schneller eine Intuition für “Clean Code” entwickeln, Profis hilft es, ihre Denkweisen Einsteigern besser zu erklären und vielleicht das eine oder andere aufzufrischen. Wir stellen erst die Geschichte des Buches vor und gehen dann konkret auf ein paar der Vergleiche aus dem Buch ein. Danach wollen wir gemeinsam kreativ sein und mit euch ein von uns entwickeltes Spiel namens Comparison Jeopardy spielen.

Wir freuen uns auf euch!

Alle wollen gute Software schnell entwickeln. Alle möchten in ihren Rollen dazu beitragen und bringen aus ihren Sichtweisen gut gemeinte Maßnahmen mit ein:

• Agile Coaches führen SCRUM ein. Also auch JIRA.
• Entwickler:innen entwickeln flexible Lösungen.
• Architekt:innen definieren Referenz-Architekturen.
• Operations führt Kubernetes ein.
• Security Experts erstellen Checklisten.
• HR stellt Ninjas ein.
• Team-Leads wollen den Teams helfen und stellen Jour-Fixes ein.
• CIO fordert Vendor-Independence.
• Irgendjemand führt plötzlich MS Teams ein.

In der Theorie sind diese gut gemeinte Maßnahmen sehr hilfreich. In der Praxis zeigt sich jedoch oft ein anderes Bild: Alle sind irgendwie unzufrieden. Software-Projekte dauern immer länger.

Ihr begleitet in diesem kurzweiligen Vortrag ein initial engagiertes Team, das immer mehr gut gemeinte Maßnahmen aufgedrückt bekommt. Lernt, wie ihr solche Maßnahmen erkennen könnt und wie ihr erfolgreich dagegensteuert.

Analytische Daten werden häufig von einem zentralen Daten-Team eingesammelt und verwaltet. Aber wir (als Entwickler:innen) bekommen kaum Feedback. Und das, was wir sehen, ist auch häufig noch falsch. Dabei werden Datenauswertungen immer wichtiger, um unsere Kund:innen zu verstehen und den Nutzen von User Stories zu bewerten. Mit Machine Learning werden zudem ganz neue Funktionen für unsere Systeme ermöglicht.

Mit Data Mesh wird ein soziotechnischer Ansatz vorgestellt, der basierend auf Konzepten wie Domain-driven Design, Product Thinking und Team-Topologies die Verantwortung für Daten an die Entwicklungsteams zurückgibt.

Jochen Christ, Co-Autor von datamesh-architecture.com, zeigt, welche Vorteile sich daraus ergeben, aber auch vor welchen Herausforderungen Entwicklungsteams stehen werden.

Daten endlich sinnvoll nutzen! Data Mesh befähigt Entwicklungsteams, innerhalb ihrer Domäne Datenanalysen selbstständig durchzuführen, um ihre Services selbstständig verbessern zu können. Über definierte Schnittstellen werden qualitativ hochwertige analytische Daten als Produkte auch anderen Teams zur Verfügung gestellt.

Zielpublikum: Architekt:innen, Entwickler:innen, Entscheider Voraussetzungen: Keine Schwierigkeitsgrad: Fortgeschritten

… and escape YAML-hell along the way

Build and CI/CD systems are powerful tools which complement each other well.

Systems like Gradle or maven take us a long way from code to running software artifacts. But if we get into a highly collaborative setting the need for a central CI/CD system will emerge soon. Scalable and reproduceable build environments for a team are just too helpful to go without them.

Sadly testing and developing complex pipelines often turns out to be tedious, because we have to wait for the central system to pick up and process our jobs. Wouldn’t it be fabulous if we could develop and run our pipeline steps locally without modifying them? Exactly this is where dagger.io is coming into play.

Through the smart combination of using containers to isolate build steps and cuelang for expressive, declarative and type safe configuration of our pipeline dagger.io creates a flexible build system which - thanks to containers - can be extended in different programming languages.

In the talk we will look into the concepts and components of dagger.io by example and learn about its inherent advantages in comparison to other build and CI/CD systems. We will learn why we definitely want to use cuelang instead of YAML in the future and define our first own build steps.

Jeder kennt sie. Niemand mag sie. Einige fürchten sie. Die Rede ist von Software-Dämonen. Verhältnismäßig große Commits mit aussageloser Commit-Nachricht – z.B. „some little changes“ bei mehr als 35 betroffenen Dateien – oder verwirrende Methodennamen wie „void actReqInter4ProcUp(string aHaMesCo)“ sind nur zwei Exemplare von derartigen Dämonen.

Die folgenden zwei Fragen müssen wir uns unter anderem stellen, um solche Dämonen nicht zu beschwören:

• Was genau soll in Commit-Messages stehen?
• Wie benennt man diese Funktion/dieses Member?

Beide Fragen zielen auf das Gleiche ab: das Benennen von Dingen, die wir geschaffen haben. Dieser Vortrag gibt mit vielen zum Teil lustigen aber auch schrecklichen Beispielen aus dem Projekt-Alltag auf beide Fragen Antworten. Und praktische Tipps stellen dar, wie ihr in Zukunft selbst Dämonen austreiben könnt.

Dieser Vortrag richtet sich an unerfahrene sowie auch an erfahrene Entwicklerinnen und Entwickler, die sich genau diese Fragen immer wieder stellen und bisher keine zufriedenstellende Antwort gefunden haben.

Aufzeichnung des Livestreams

Beim nächsten Mal dabei sein

Als Kim frisch von der Uni in ihr erstes Projekt kommt, merkt sie schnell, dass selbst heute Werkzeuge und Prozesse zur Qualitätssicherung selten vorhanden sind: unsauberer Code, keine Regeln und kaum Tool-Unterstützung. Kim führt Coding-Guidelines, Qualitätstools und Reviews ein, oft gegen den Willen der Teammitglieder. Sie merkt nicht, wieviel Kraft sie diese Konflikte kosten - und dass sie sich dabei zwar sehr einbringt, aber den Erfolg gefährdet.

Kim wechselt den Arbeitgeber und findet eine ähnliche Situation vor: keine Regeln, keine Automatisierung und keine gute Softwarequalität. Doch dieses Mal macht sie alles anders und erarbeitet gemeinsam mit ihrem Team verschiedene Maßnahmen.

Dieser Vortrag zeigt mit zwei Beispielen, dass Softwarequalität eine wichtige Rolle spielen muss und nicht Werkzeuge entscheidend sind, sondern die Einstellung der Teammitglieder zu verbessern, zum Beispiel über “Collective Ownership of Code” oder die “Pfadfinderregel”.

Hast du letztens in nem Blog ein Framework entdeckt und es gleich am nächsten Tag ins eigene Projekt „zum damit Spielen” eingebaut? Musstest du deine Anwendung schon öfter „skalierbarer”, „performanter” oder „zuverlässiger” machen und zogst dir einen Tech-Stack von den “Big Five” rein, um damit das nächste Amazon, Netflix, WhatEver zu werden?

Wahrscheinlich klang das zu dem Zeitpunkt logisch und nach einer superguten Idee. Aber ein paar Monate später weiß man selbst oft gar nicht mehr, was der eigentliche Grund für den Einsatz war. Man macht es, ohne genau zu wissen, warum: Cargo Cult par excellence!

In diesem Vortrag zeige ich, wie sich Entscheidungen für Technologien, Vorgehen und Praktiken strukturiert auswählen und nachvollziehbar motivieren lassen. Wir sehen uns an, was uns bei der Auswahl (oft unerkannt) antreibt. Dazu fischen wird zuerst die geforderte Qualität für Features aus User Stories und bauen uns ein Netz aus den qualitativen Ansprüchen für den Überblick. Mit einer ordentlichen Portion Architekturtaktiken in den Segeln schippern wir in den sicheren Hafen der fundierten Entscheidungen.

Key takeaways

• You will learn, how to use data contracts as a collaboration tool to discuss data requirements.
• You will also learn, how data contracts be used for automation, later in the development process.
• You will understand, that a data contract is more than just a schema.
• You will be able to write your first data contract as a YAML document.

In the world of software engineering, we know how important explicit, clearly documented, and stable interfaces are, and what effects unannounced breaking changes can have. We use Swagger, OpenAPI or AsyncAPI for this purpose, and on top of that tools for code generation or contract-based testing. In the world of data, there has never been anything comparable, and unannounced breaking changes, such as schema changes, are unfortunately common there.

Data contracts are something like OpenAPI, but for data. Data contracts bring the producer of data and their consumers together. Data Contracts allow the specification of the structure of the data, and its quality requirements. Data contracts contain sample data, and a semantic description. Data contracts specify terms of use for the data. Consumers can rely on data contracts.

In this talk, I want to introduce the Data Contract Specification (datacontract.com) in more detail. I want to show how interfaces are described in the world of data, and how this interface documentation differs from the world of software engineering. We will design an interface together in Data Contract Studio (studio.datacontract.com), and then use the Data Contract CLI (github.com/datacontract/cli) to simulate detecting a breaking change.

Large Language Models (LLM) are a new technology that has taken over the world in no time. AI chatbots like ChatGPT have made AI controllable by using natural language and thus accessible and extremely useful to the general public.

Most people have probably already experimented with this or another chatbot and had similar experiences: They know the answer to almost every question, write detailed texts and even respond to counter-questions. There is one very big problem: The chatbots hallucinate, i.e. they invent content that sounds correct but is not correct. In addition, due to the vast amount of training data, it is no longer possible to reconstruct where a piece of information came from.

We have dealt with this problem and tried to find a solution by which a chatbot builds its answers within a given domain and gives sources for the origin of the information used from the domain.

Such knowledge-based chatbots can be used in practically any domain, for example, to chat with documentation, contents of a database or website, using natural language, without the risk of hallucination. We also looked at ideas such as the use of open source LLMs (e.g. LLama2), scalability and cost management.

‍

Unsere Systeme werden immer komplexer und wir verwenden Ansätze wie Microservices oder Functions, um unsere Systeme immer kleinteiliger aufzuteilen. Dadurch verlieren wir jedoch schnell den Überblick über das gesamte System. Wir stellen uns Fragen wie: Welche Services und Libraries gibt es? Wer ist für sie verantwortlich? Wo finde ich den Code und die API-Dokumentationen? Welche Services werden von anderen genutzt und wo befinden sie sich im Lebenszyklus? Ist der Service aktiv und wann wurde er zuletzt aktualisiert? Die Antworten auf diese und weitere Fragen sind im gesamten System verstreut - einige sind in Wikis, andere in der Betriebsplattform oder in der Build-Umgebung. Im schlimmsten Fall besitzt nur ein kleiner Kreis das notwendige Wissen. Um diese Informationsflut unter Kontrolle zu bekommen, benötigen wir eine Einstiegshilfe, die die Informationen zentralisiert und auffindbar macht. In diesem Vortrag werden wir Backstage vorstellen, ein Framework für die Entwicklung und den Betrieb eines solchen zentralen Entwicklungsportals. Wir werden einen Blick hinter die Kulissen werfen, um zu sehen, wie es funktioniert und wie man es auf die eigenen Bedürfnisse anpassen kann.

„Hättet ihr das nicht früher sagen können, dann hätten wir das System anders gebaut!“. Wie seltsam und frustrierend das Leben in der IT manchmal ist, merkt man, wenn spätestens zum dritten Mal Dinge, die “garantiert nie passieren” werden, dann doch passieren. Schade, wenn dann die Aufwände unnötig hoch sind, um unsere Systeme an diese Veränderung anzupassen.

Architekturoptionen können in solchen Situationen Gold wert sein. Dabei investieren wir zu einem früheren Zeitpunkt für einen günstigen Preis (also vergleichsweise wenig Aufwand) in das Bauen einer Architekturoption (z. B. das Einziehen eines Interfaces), die es uns ermöglicht, später zu einem wesentlich günstigeren Preis eine Option zu ziehen (z. B. das Herauslösen eines Moduls als eigener Microservice).

In diesem Talk erkunden wir den schmalen Grat zwischen Overengineering und fahrlässiger Hartcodierung. Ich werde euch die Theorie der Realoptionen vorstellen und zeigen, wie sie euch als Softwarearchitektinnen oder Softwarearchitekten helfen kann, über Projektrisiken nachzudenken und diese gegebenenfalls abzumildern. Anschließend werden wir uns verschiedene Beispiele für Architekturoptionen ansehen und ihr werdet sehen, dass einige dieser Optionen eine Investition sind, die nahezu jedes Softwaresystem eingehen sollte.

Was haben Entwicklung und Architektur mit dem Business und den Nutzer:innen zu tun?

Die Antwort ist einfach: sehr viel. Das gesamte Team sollte verstehen, für wen das Produkt gedacht ist, an dem es arbeitet, und welchem höheren Ziel die einzelnen Aufgaben dienen. Niemand sollte Aufgaben einfach nur abarbeiten, die in Tickets beschrieben sind.

Die digitale Produktentwicklung ist nicht nur Bestandteil eines Teams, das sich „die Produktmenschen“ oder „die UXler“ nennt. Sie ist ein elementarer Bestandteil der digitalen Transformation und bildet die Basis für erfolgreiche – oder eben nicht erfolgreiche – digitale Produkte.

Die Digitalisierung schreitet kontinuierlich voran. Daher müssen Prozesse, Strukturen und Wertschöpfungsketten flexibel und regelmäßig angepasst werden. Das bedeutet, dass unsere Software und die zugrundeliegende Architektur ebenso reagieren müssen.

Wie schaffen wir es jedoch, als Team mit dieser Geschwindigkeit Schritt zu halten und unsere Software, Services und Produkte dennoch qualitativ hochwertig zu liefern? Wie müssen wir zusammenarbeiten, um flexibel auf den Markt und die Menschen dahinter reagieren zu können?

In diesem Talk fokussieren wir uns auf digitale Produktentwicklung – jedoch mit dem Bewusstsein, dass ein harmonisches Zusammenspiel von Mindset, Menschen und Methode gegeben sein muss.