Wir müssen Teams in die Lage versetzen, den größten Teil der architektonischen Arbeit selbst zu erledigen. An dieser Stelle kommen Team Topologies (M. Skelton und M. Pais) ins Spiel. Dort gibt es die Topologie des "Enabling Teams", welches knapp zusammengefasst, andere Teams mit Wissen und Methodik unterstützt. Dieser Vortrag gibt Ihnen einen Überblick sowie eine praktische Anleitung, wie Sie ein Architekturteam in ein Enabling Team umwandeln können, welches andere Teams unterstützt und befähigt. Der Vortrag enthält viele praktische Beispiele.

Zielpublikum: Architekt:innen, Manager:innen
Voraussetzungen: Eigentlich keine, aber ein paar Architektur-Basics schaden nicht.
Schwierigkeitsgrad: Anfänger

Extended Abstract:
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:
1.    Welche Stakeholder Sie in diesen Prozess einbeziehen sollten
2.    Warum das künftige Enabling-Team ebenfalls befähigt werden muss und wie man das macht
3.    Wo häufige Fallstricke auf dieser Reise liegen
4.    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.

Der Begriff „Plattform“ ist leider „überstrapaziert“. Wegen der Popularität großer Plattformen und Plattform-Unternehmen wird der Begriff inflationär gebraucht. Dadurch reden selbst Experten in der IT-Industrie kontinuierlich aneinander vorbei.
Der Vortrag präsentiert eine Landkarte mit Architektur-Big-Picture durch den Plattform-Dschungel, die dabei hilft, verschiedene Arten von Plattformen zielsicher zu erkennen und zu verstehen. Sie erlaubt Architekten, den Überblick zu behalten und alle anderen sicher durch den Dschungel zu führen.

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

Extended Abstract:
Der Begriff „Plattform“ existiert schon sehr lange und wird aktuell extrem viel und vielfältig verwendet, man muss leider schon sagen, er wird „überstrapaziert“.
Beispiele sind die Begriffe Cloud-Plattform, Plattformökonomie, iOS-Plattform, Platform Engineering oder Plattform-Industrie 4.0.
Wegen der Popularität großer Plattformen, dem Erfolg von Plattform-Unternehmen und den Verheißungen der Plattform-Ökonomie wird der Begriff mittlerweile inflationär gebraucht. Dadurch entsteht viel Verwirrung und selbst Experten in der IT-Industrie reden kontinuierlich aneinander vorbei.
Zeit, um etwas Ordnung zu schaffen und einen Überblick über verschiedene Arten von Plattformen und Verwendungen des Begriffs Plattform zu geben.
Der Vortrag hat zum Ziel, eine Landkarte durch den Plattform-Dschungel zu präsentieren, die es ermöglicht, verschiedene Arten von Plattformen zu erkennen und vor allem auch ihre unterschiedlichen Eigenschaften und Daseinsberechtigungen zu verstehen. Dadurch wird auch klar, wie große Unterschiede existieren und dass teilweise die einzige Gemeinsamkeit ist, dass Software im Spiel ist …
Die Zuhörer bekommen im Vortrag die Landkarte in die Hand, um sich nicht mehr zwischen Plattformbegriffen zu verirren. Der Vortrag ist nicht technisch motiviert oder orientiert, sondern soll eine bessere Kommunikation und Diskussion zwischen allen Professionen in der Digitalen Welt ermöglichen

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/matthias.naab , https://www.sigs.de/autor/dominik.rost

In den letzten Jahren kamen immer öfters Microservices zum Einsatz. Durch den Einsatz vieler kleinerer Services wurde der Einsatz der synchronen Kommunikation immer schwerer und komplexer. Wir können nicht mehr sicherstellen, dass zu jedem Zeitpunkt alle Systeme verfügbar sind und dass alle Änderungen zu jedem Zeitpunkt Konsistent sind. Denn die synchrone Kommunikation sorgt für eine enge Kopplung zwischen den einzelnen Diensten und kann dafür sorgen, dass beim Ausfall eines Dienstes zeitgleich eine Reihe weiterer ausfallen. Typische Resilience Patterns wie: Circuit-Breaker, Retries, Service Meshes, etc. erhöhen wiederum die Komplexität des Gesamtsystems und lösen auch nur teilweise das wirkliche Problem. 

In diesem Vortrag zeige ich, wie mit einem Event-first Mindset ganze Systeme ereignisgetrieben entworfen werden können. Wir werden mit Hilfe des CAP-Theorem analysieren, wie sich die Konsistenz in einem verteilten System ändert. Wie Transaktionssicherheit gewährleistet werden kann und wie Microservices zu autonomen Services werden, die komplett voneinander getrennt sind und nur über Events miteinander kommunizieren. Und wie sich Entwickler mit Hilfe von Serverless und FaaS auf das konzentrieren können, was wichtig ist: Business Value zu liefern.

Zielpublikum: Architekt:innen, Entwickler:innen, Entscheider:innen
Voraussetzungen: Grundlegende Kenntnisse in Cloud (-Ressourcen), Grundlegendes Verständnis von Software-Architektur
Schwierigkeitsgrad: Anfänger

Vielen Anwendungen steht der Schritt zu einer Cloud-native Entwicklung noch bevor.
Wie bei jeder guten Reise beginnt das mit den eigenen Anforderungen und vorhandenen Möglichkeiten.
Welche Optionen und Herausforderungen gibt es dabei zu beachten?
Für eine Java-Webanwendung wird in mehreren Szenarien gezeigt, wie man diese mit AWS-Diensten betreiben kann.
Dabei werden die Vor- und Nachteile der Replatforming- und Rearchitecture-Wege diskutiert und Fragen beantwortet.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager:innen, Entscheider:innen
Voraussetzungen: Cloud Grundkenntnisse, Erfahrung mit Anwendungsmodernisierung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Um sich nicht naiv in die Cloud aufzumachen, lohnt es sich, erfahrene Begleiter mit an Bord zu holen und folgende Fragen zu klären. Die hier gezeigten Erfahrungen helfen, in Zukunft mehr cloud-native unterwegs zu sein.

1. Welche Qualitätsziele können wie am besten erreicht werden?
2. Wie müssen Prozesse angepasst werden, um sicher und effizient Anwendungen in der Cloud zu betreiben?
3. Wie kann ich meine Daten am einfachsten mitnehmen?
4. Was muss sich wo ändern, um das volle Potenzial der Cloud zu heben?

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/frank.pientka

Domain-driven Design (DDD) steht für eine Vielzahl an Techniken wie strategisches DDD, taktisches DDD und kollaborative Modellierung. Dieser Vortrag gibt einen Überblick über das DDD-Universum. Dabei stellt er nicht nur die verschiedenen Konzept vor. Er zeigt außerdem auch die jeweiligen Vor- und Nachteile der Praktiken auf und weist auf die typischen Fallstricke hin - und wie man sie vermeiden kann.

Zielpublikum: an Software-Architektur Interessierte
Voraussetzungen: Grundlegendes Verständnis von DDD
Schwierigkeitsgrad: Anfänger

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/eberhard.wolff

Organizations are drawn to migrate their systems into the cloud, but in practice, cloud transformations do not always succeed in achieving the advantages often promised by cloud providers, such as scalability, availability, and cost effectiveness.
We give an overview over Kevin Hoffmann's fifteen factors for cloud-native applications and how they help us achieve success in our cloud migrations.

Target Audience: Architects, Developers, Operations, DevOps
Prerequisites: Basic understanding of web services
Level: Basic

Extended Abstract:
You think you are already reaping the cloud's harvest by lifting and shifting your apps to some cloud-provided VM or container infrastructure?
You've already read about Heroku's (original) twelve factors, maybe even skimmed though Kevin Hoffmann's book, and think your app is good enough, because you are using Git, have a CI pipeline, and someone in the team once ran the app in a Docker container?
Or you think your team isn't going to the cloud any time soon and this advice does not apply to you anyway?
Maybe you're right. Chances are, you are in for a surprise, though.
The original twelve factors for cloud-native application development are (reasonably) well established and widely agreed upon. Yet, in practice, there appear to be some misunderstandings regarding their meaning, and we see cloud migrations fail precisely due to reasons that could be avoided by following these factors correctly. The extension to fifteen factors by Kevin Hoffmann is less widely known, but no less important for modern, cloud-native application landscapes, especially since this extension also revisits and updates the original twelve factors.
The goal of this talk is to disseminate and discuss the fifteen factors, as well as to emphasize their interrelations and embed them in the greater context of modern application development, in order to help reduce pain for many teams tasked with bringing their software to the cloud.

In der leidigen Diskussion um Technologieoffenheit wird übersehen, dass für zukunftsfähige Organisationen Denkoffenheit zentral ist. Unser Bildungssystem schafft es nicht, diese bei jungen Menschen zu fördern. Daher wurde im April '23 ehrenamtlich die Initiative ZUKUNFTschaffen gegründet, die jungen Menschen Kreativität anhand Projektarbeit an den 17 SDGs* vermittelt.
In der interaktiven Session wird ein Win-Win-Win präsentiert, bei dem Nachhaltigkeit, Unternehmen & deren Mitarbeitende durch ZUKUNFTschaffen-Projekte in Organisationen profitieren.
*SDGs = UN Sustainable Development Goals

Zielpublikum: Menschen, die an Nachhaltigkeit interessiert sind
Voraussetzungen: Interesse, Neugier, Reflexion
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Mit den 17 UN-Zielen zur nachhaltigen Entwicklung (SDGs) zu mehr Kreativität in der Welt
ZUKUNFTschaffen adressiert die Lücke zwischen akademischem Grundlagenwissen, welches das deutsche Bildungssystem mehr schlecht als recht vermittelt, und den Kompetenzen, die in unserer heutigen Arbeits- und Lebenswelt erforderlich sind.
Wie könnte man diese Chance, etwas für Individuen zu tun, das gleichzeitig positive gesellschaftliche Auswirkungen hat, nun für Unternehmen gewinnbringend weiterdenken? Das Durchlaufen des ZUKUNFTschaffen-Programms in der betrieblichen Ausbildung oder z.B. kurz nach dem Berufseinstieg bietet Unternehmen die Möglichkeit, die Zukunfts-Kompetenzen ihrer Mitarbeitenden oder „Neuzugänge“ zu stärken. Über die Vernetzung in den Projektteams und ins Unternehmen hinein stärkt bzw. beschleunigt es ihre Integration und Unternehmensbindung. Gleichzeitig schärft das Programm den Blick der Menschen für Themen rund um Nachhaltigkeit. Durch die inhaltliche Arbeit an den 17 SDGs werden gesellschaftlich relevante Probleme, vorzugsweise auch mit Unternehmensbezug, adressiert und idealerweise gelöst oder zumindest abgemildert.
In diesem Vortrag wird in einem Mix aus Case Study und wissenschaftlichen Hintergrundinformationen vorgestellt, wie das Programm ZUKUNFTschaffen entsprechend konzipiert wurde.
Die Teilnehmer:innen werden in dem Vortrag

1. Ein pragmatisches und praxisorientiertes Konzept kennenlernen, um Nachhaltigkeit mit der Förderung von Zukunftskompetenzen zu verknüpfen
2. Denkanstöße bekommen, wie sie Menschen in ihrer Organisation zur Nachhaltigkeit befähigen können
3. Argumentationshilfen erhalten, um in ihren Organisationen für Nachhaltigkeitsprojekte zu „werben“
4. Inspiriert werden, von den Projektergebnissen junger Menschen zu den 17 UN-Zielen der nachhaltigen Entwicklung.

Die Cloud hat bereits heute einen größeren CO₂-Fußabdruck als die Luftfahrtindustrie, mit steigender Digitalisierung und Cloudifizierung wird sich dieser Trend fortsetzen, wenn wir nichts dagegen unternehmen. Viele Kubernetes-basierte Installationen sind gemessen am eigentlich benötigten Ressourcen-Bedarf stark überdimensioniert und tragen so unnötig zur globalen Erwärmung bei. Wie sieht die Energiebilanz Ihres Clusters und Workloads aus?

Zielpublikum: Architekt:innen, Platform Engineers, Entwickler:innen, #CloudNativeNerds
Voraussetzungen: Grundlegende Kenntnisse von Public Clouds und Kubernetes
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
In diesem Vortrag zeigen wir Ansätze und Technologien, die dabei helfen, K8s-Cluster grün(er) zu machen. Zunächst braucht es Transparenz: Wie sieht die Energiebilanz des Clusters und seiner Workloads aus? Erst danach lassen sich diese gezielt auf ihre Energiesparsamkeit hin optimieren. Und das ist gar nicht so schwer, also packen wir es an!

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Mario_Leander_Reimer

Kubernetes ist omnipräsent. Entweder laufen die Anwendungen in Kubernetes oder sollen in Kubernetes laufen. Entwickler mögen sich jetzt denken "Aber was hat die Kubernetes-Infrastruktur mit mir als Entwickler zu tun?"
Dieser Vortrag gibt eine Kurzeinführung, was Kubernetes ist und aus welchen Komponenten es besteht. Beim Durchgehen der Komponenten und Konzepte steht die Sichtweise eines Entwicklers im Vordergrund. Am Ende nehmen die Zuhörer Good Practices anhand von Beispielen mit nach Hause.

Zielpublikum: Entwickler:innen, Architekt:innen
Voraussetzungen: Allgemeine Software-Entwicklungskenntnisse
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Kubernetes ist omnipräsent. Entweder laufen die Anwendungen in Kubernetes oder sollen in Kubernetes laufen. Entwickler mögen sich jetzt denken "Aber was hat die Kubernetes-Infrastruktur mit mir als Entwickler zu tun?"
Mit der Einführung von Kubernetes bekommen die Entwickler aber oft die Aufgabe, neben dem Anwendungscode jetzt auch noch Deployment-Skripte in Form von Kubernetes-Deskriptoren zu schreiben. Dafür brauchen sie ein Grundverständnis der Kubernetes-Komponenten.
Dieser Vortrag gibt eine Kurzeinführung, was Kubernetes ist und aus welchen Komponenten es besteht. Beim Durchgehen der Komponenten und Konzepte steht die Sichtweise eines Entwicklers im Vordergrund. Am Ende nehmen die Zuhörer Good Practices anhand von Beispielen mit nach Hause.

At Tchibo we wanted to reduce our server and energy consumption with our product development teams. But why would we care? We all like fast snappy development and test systems. And our shop needs to survive Black Friday’s shopping traffic. Annual Google Cloud consumption forecasts do not trigger us to consume less. But when we started to show teams their related carbon dioxide footprint, we created a feedback loop that will help us to become better CO₂-developers.
As developers, we have an impact - to program CO₂ reduction.

Target Audience: Everyone, Developers, DevOps People
Prerequisites: None
Level: Advanced

Extended Abstract:
We will present the idea and first measurements on the server side. The planned client side measurements are still work in progress and very difficult to perform. Nevertheless is the client side induced CO₂ consumption at large websites probably a large lever for reduction.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/johannes.mainusch

High traffic during business hours, no traffic at night, weekends and vacations, multiple teams, and several staging environments - these characteristics of a typical enterprise application. Pay-as-you-go, "scale-to-zero" and managed services make serverless architectures appealing for enterprise applications.
On-premise, on the other hand, you get the maximum flexibility and full access to machines with less automation and so more plumbing.
I will compare both approaches with focus on architecture and answer your questions in real time.

Target Audience: Developers, Architects
Prerequisites: Basic Cloud and Java Knowledge
Level: Advanced

Great engineers often use back-of-the-envelope calculations to estimate resources and costs. This practice is equally beneficial in Machine Learning Engineering, aiding in confirming the feasibility and value of an ML project. In my talk, I'll introduce a collaborative design toolkit for ML projects. It includes Machine Learning Canvas and MLOps Stack Canvas to identify ML use cases and perform initial prototyping, thus ensuring a business problem can be effectively solved within reasonable cost and resource parameters.

Target Audience: Architects, Developers, Project Leader, Data Scientist
Prerequisites: Basic knowledge in machine learning
Level: Advanced

DevOps isn't dead yet and it will not die in the future. Platform engineering comes to leverage DevOps practices horizontally to support developers, operations and those in between. In this session, I will give you a perspective on how to move on from DevOps to Platform Engineering, how to design and shape your internal platform and build a vibrant community sharing best practices and enabling each other to overcome faster issues. In the end you will understand how we can reduce the cognitive load for dev teams to focus on features.

Target Audience: DevOps, Developer, Manager
Prerequisites: Experience in DevOps and an understanding of the pain of silos
Level: Advanced

Extended Abstract:
Platform Engineering is often seen as the evolution of DevOps. However, it is yet a new discipline using DevOps practices but focusing on the entire chain and breaking silos. I will show details from my experience on my job as well as 3 years of release engineering at Kubernetes where it wouldn't be possible to release without a proper platform.

Das Serverless-Paradigma existiert seit fast 10 Jahren. Und obwohl es für passende Szenarien extreme Vorteile mit sich bringen kann, trauen sich bisher nur wenige Cloud-Anwendungen, den Schritt Richtung Serverless zu gehen. Zu Recht?
Im Rahmen des Workshops wird ein komplexes Anwendungsszenario Schritt für Schritt aufgebaut und dabei in jedem Schritt ein Serverless-Pattern eingeführt und in seiner Motivation diskutiert. Darüber hinaus wird gezeigt, wie sich eine solche stark verteilte Anwendung sinnvoll testen und monitoren lässt.

Max. Teilnehmendenzahl: 30
Laptop (mit AWS-Account) wird benötigt. Ein einfacher Test-Account (https://aws.amazon.com/de/free/) reicht aus.

Im Workshop werden wir gemeinsam an einem Demo-Projekt arbeiten. Wer möchte kann gerne im Vorfeld schon einmal das Beispiel aus dem GIT Repository laden und den dortigen Anweisungen zur Installation der benötigten 3rd Party Libraries folgen. 

https://github.com/mobileLarson/serverless-workshop 

ACHTUNG: Das Demo-Projekt ist zwar in Java programmiert, aber auch Interessierte, die nicht aus der Java-Welt kommen, können problemlos an dem Workshop teilnehmen. Die dazu benötigten Deployables für die AWS Cloud liegen ebenfalls im Projekt. 

Bei Fragen im Vorfeld bitte einfach melden:lars.roewekamp(at)openknowledge.de 

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

Extended Abstract:
Eine einzelne Serverless Function zu schreiben und produktiv zu stellen, ist dank NoOps-Ansatz denkbar einfach. Nur leider macht eine Schwalbe noch keinen Sommer und eine einzelne Serverless Function noch keinen sinnvollen Anwendungsfall! Wie also konzipiert man eine Anwendung als Zusammenspiel von mehreren Serverless Functions und diversen weiteren Cloud-Komponenten? Gibt es spezielle Architektur-Patterns, die sich im Serverless-Umfeld anbieten? Und wie wirken sich diese auf den Software-Lifecycle aus? Was, wenn die niedlichen kleinen Funktionen sich zur Laufzeit nicht so verhalten, wie gewünscht? Wie sieht das Monitoring der einzelnen Funktionen und des Systems als Ganzes aus? Und was ist mit Testen? Muss die Funktion dazu immer in der Cloud deployt werden oder kann man das produktive System auch lokal emulieren? Diesen und vielen anderen Herausforderungen wollen wir uns in dem Workshop stellen - Aha-Effekte garantiert!