Software-Architecture Revolution is the process of making profound, large-scale changes to the fundamental structures of software systems to improve its attributes, such as availability, scalability, and maintainability, or to enable new requirements that are incompatible with the current capabilities. Architectural revolution demands substantial effort from the organization and needs effective leadership to be successful. This talk draws from practical experiences (patterns) to improve the effectiveness of architectural revolution initiatives.

Target Audience: Architects, Managers, Project Leaders, Coaches, Developers, Product Owners, Decision Makers
Prerequisites: Leadership, Architecture, Project Management, Working with Teams, Agile mindset
Level: Advanced

Extended Abstract:
Pressure to adapt to and shape the market requires agile organizations to add new features, accommodate new interactions, and have new teams work on adapting the software. Sometimes a straightforward software architecture that starts out small when communication is easy can support guided, incremental architectural changes and can gradually evolve with its environment, remaining fit for its purposes. Other times it is not so simple: the initial software architecture can be poorly suited for supporting required changes, or the accumulation of suboptimal architectural decisions (also known as architectural technical debt) can be too severe; in either case, the architecture needs an extensive revision; especially for the organization to remain agile and adapt to the changing market.
Software architecture revolution can be defined as the process of making profound, large-scale changes to the fundamental structures of a software system to improve its attributes, such as availability, scalability, and maintainability, or to enable new requirements that are incompatible with the current capabilities. Architectural revolution usually demands substantial effort from the organization and thus depends on effective leadership to be successful. However, while there is plenty of research on the technical aspects of any architectural transformation, not much is available from the leadership perspective. The role of managers and other leaders include championing the revolution initiative, prioritizing activities, negotiating the allocation of people and resources, evaluating results, taking corrective actions, and reporting achievements. This talk draws from practical experiences to describe patterns to improve the effectiveness of architectural revolution initiatives.

Der Wert von Software-Reviews wird allgemein akzeptiert. Bei klassischen Methoden steht diesem gleichzeitig ein erheblicher Aufwand gegenüber. Das macht es Entwicklungsteams schwierig, ihre Vorhaben zum richtigen Zeitpunkt angemessen zu beleuchten, um Risiken aufzudecken und die Architektur abzusichern. In diesem Vortrag skizziere ich praktikable Ansätze, mit denen Sie und Ihr Team mit überschaubarem Aufwand und im Extremfall im Alleingang wertvolle Ergebnisse erzielen.

Zielpublikum: In erster Linie Architekt:innen und Entwickler:innen, ansonsten alle in Softwarevorhaben Beteiligte
Voraussetzungen: Erfahrung in Software-Entwicklungsvorhaben
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Der Wert von Software-Reviews wird allgemein akzeptiert. Bei klassischen Methoden wie ATAM steht diesem gleichzeitig ein erheblicher Aufwand gegenüber. Das macht es Entwicklungsteams schwierig, ihre Vorhaben zum richtigen Zeitpunkt angemessen zu beleuchten, um Risiken aufzudecken und die Architektur abzusichern. In diesem Vortrag skizziere ich praktikable Ansätze, mit denen Sie und Ihr Team mit überschaubarem Aufwand und im Extremfall im Alleingang wertvolle Ergebnisse erzielen.
Zur Motivation: Es gibt einige "große" Methoden zur Architekturbewertung wie ATAM oder CBAM, oder sehr "flapsige", die nur Bauchgefühl haben. Da einen Mittelweg zu finden ist nicht leicht.
Aus der Praxis von 50+ Reviews konnten wir aber einen funktionierenden Kern ableiten, der fundiert und trotzdem schlank ist. Das Ergebnis stelle ich in dieser Session vor und gebe Orientierung, wie Sie das Schritt für Schritt auf Ihre eigenen Softwarelösungen anwenden.
Der Clou: Die gezeigte Methodik ist darauf getunt, durch Fokussierung bereits früh verwertbare und vorzeigbare Ergebnisse zu liefern. Weitere Schritte liefern wo nötig tiefere Erkenntnisse und mehr Sicherheit.

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

Test coverage: 100% - Check!
And why do we still have bugs?
OK, tests don't prove the absence of errors.
And at the end of the day, they are just code which could contain bugs as well.
And perhaps they give us a false sense of security.
But how do I know, that my test are good?
One way to find out is using Mutation Testing.
In this talk I want to explain, what Mutation Testing is, how to do it and when it is helpful.

Target Audience: Developers, Achitects, Testers
Prerequisites: Basic knowledge in Programming, some experience in writing tests
Level: Basic

Extended Abstract:
More and more teams are writing tests for their production code, be it by applying concepts like TDD or BDD or by just writing them "after the fact". Sometimes there is also a test coverage metric that needs to be met. The positive effect is definitely that there are tests. Be it for my future self or a future colleague or as a form of documentation.
Tests are a means of telling something about the quality of production code. Mutation testing can help tell something about the quality of tests. It helps to find missing tests and potential bugs.
The concept of mutation testing is already more than 50 years old, but its application has not yet become widespread.
This talk should encourage you to take a closer look at mutation testing to find out what possibilities it offers in your own project, but also to see what disadvantages or pitfalls there are.

How often have you heard that ‘Yes this is important, but we don’t have the capacity right now’ or ‘sure let’s put it in the backlog’?
This is something we should not brush off or take lightly. Accessibility testing is vital especially when your product is a user facing application.
We need to be socially aware as a team and build quality towards our product with making it more accessible.

Target Audience: Everyone as Accessibility is for social awareness
Prerequisites: None
Level: Basic

Extended Abstract:
At least 1 in 5 people in the UK have a long term illness, impairment or disability. Many more have a temporary disability. A recent study found that 4 in 10 local council homepages failed basic tests for accessibility.
This is quite vital and the sooner we as testers can advocate this into our teams, we make our product more accessible, reduce the risk of bad product reviews, reputation and also be more socially aware. Let's shift left and make accessibility testing built-in our teams.

1. Understand why accessibility testing is important?
2. How I adapted accessibility mindset?
3. How to coach team and bring accessibility into your teams?
4. Demonstrate various tools available to perform accessibility testing (with demo)

Eine auf (Micro-)Services 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 dieser Session beantwortet werden. So viel vorab: Umdenken ist gefragt!

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen
Voraussetzungen: Kenntnisse modularer Systeme sind hilfreich
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Im Rahmen der Session beschäftigen wir uns mit den Auswirkungen des Datasource-per-Service Patterns und wie man diesen sinnvoll begegnet. Die aufgezeigten Lösungsansätze sind das Resultat aus mehr als 5 Jahren praktischer Erfahrung in Microservices-Projekten.

How can a deterministic function possibly give random results? We will find out and learn how to use various random number distributions.
Random numbers haven't changed much since C++11, though new features can make these easier to use. Card games and similar need randomness to be fun and make good teaching examples. We will also discover a way to code ourselves (or blobs at least) out of a paper bag in the process.

Target Audience: intermediate. There will be some code and simulations of blobs escaping paper bags
Prerequisites: None but there will be some algorithms and C++
Level: Advanced

Extended Abstract:
Most of us need a random number at some point if we write code. We will discover how they are generated. We will see how to ensure simulating a dice roll makes the numbers 1 to 6 equally likely, and note some pitfalls to be aware of in some programming languages.
We will have a brief aside into stochastic outcomes from deterministic models, also known as chaos. Applying a function iteratively can’t possibly give non-deterministic results, right? We shall see.
After this aside, we will return to using random numbers. We will consider common mistakes and how to think clearly about "random" code. To round off, we will think about how to test code which uses random numbers.
By the end we’ll be familiar with terms like pseudorandom number generator (PRNG), linear congruential generator and random distribution. Finally, we’ll use various distributions to race some blobs out of a paper bag. Seeing a visual demonstration will solidify some the learning outcomes.

In this session we will walk through various techniques to significantly reduce the resource consumption of regular Spring Boot applications, including using Spring AOT for regular Spring apps, compiling Spring Boot apps to native images (using GraalVM), and using CRaC for instant startup (for scale-to-zero scenarios). We will compare the different approaches, discuss pros and cons for each technology, and share concrete numbers from real-world applications to give the audience an idea of what can be achieved using these technologies.

Target Audience: Developers, Architects
Prerequisites: Basic Spring Boot knowledge required
Level: Advanced

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

User-centred design is one of the default modes of teams working with software, but the consequences are often unsustainable in a densely networked world as we privilege users over all other stakeholders and systems. How might teams approach building products, services and organisations from a more sustainable standpoint than 'user-centricity'? This talk looks at how the techniques of game design, community development, platform operations and security practices can support a practice focused on hyperobjects for multi-centric design.

Target Audience: Leaders, Builders, Architects, Designers, Community Members
Prerequisites: No previous knowledge, only enthusiasm for systems, building things and design
Level: Advanced

Extended Abstract:
The key feature of a 'tragedy' is when everybody does the right thing but it goes wrong anyway. The aim of this session will be to look at why user-centred design goes wrong even if everyone's intentions are pure. This talk (gently!) brings in ideas from feminism, design thinkers, political science and anthropology to focus on very practical, grounded approaches to sustainable design in software teams. We'll look at how building things and designing organisations that have increased levels of friction can improve users' experience and how 'seamless' design can lead to disempowerment. And we'll also draw on the speaker's practical experience of building products used by millions of citizens as part of the UK's digital transformation. By the end of the session we'll have a sense of what might replace the shallow seamlessness of 'user-centred' design — a multi-centric, transcendental design aimed at manufacturing enthusiastic consent.

Je mehr sich die Arbeit der Menschen vom Taktilen in Richtung digitaler Arbeit verschiebt, desto wichtiger wird das Design der Oberflächen für die Interaktion mit dem Digitalen. Wir haben uns in den vergangenen Jahren gefragt: Wie kann der Designprozess so in agile Software-Entwicklung integrieren, dass ein gut verwendbares System mit einer auf Dauer flexiblen und anpassbaren Software-Architektur entsteht? Wir haben auf verschiedenen Ebenen Antworten gefunden, die wir den Zuhörern in diesem Vortrag gerne vorstellen wollen.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager:innen
Voraussetzungen: Erfahrung mit Software-Entwicklung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Je mehr sich die Arbeit der Menschen vom Taktilen in Richtung digitaler Arbeit verschiebt, desto wichtiger wird das Design der Oberflächen für die Interaktion mit dem Digitalen. Wir haben in den vergangenen Jahren in verschiedenen Anwendungsbereichen mit zwei Fragen gerungen: Wie lässt sich Arbeit in ein Interaktionsmodell überführen, bei dem die bisherigen Arbeitsabläufe wiedererkennbar sind, aber hilfreiche neue digitale Features eine echte Verbesserung darstellen? Wie kann der Designprozess für solche Interaktionsmodelle in agile Software-Entwicklung integriert werden, so dass ein gut verwendbares System mit einer auf Dauer flexiblen und anpassbaren Software-Architektur entsteht? Wir haben auf verschiedenen Ebenen Antworten gefunden, die wir den Zuhörern in diesem Vortrag gerne vorstellen wollen.

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

In meinem Vortrag analysiere ich Statistiken zum Scheitern agiler Übergänge und enthülle dabei die entscheidenden Erfolgs- oder Misserfolgsfaktoren. Im Zentrum steht das Produkt-Management – der Schlüssel, um diese Transitionen zu meistern. Wir decken nicht nur Hindernisse auf, sondern präsentieren auch praxiserprobte Ansätze, um diese zu umgehen und den Weg zum Erfolg zu ebnen. Erleben Sie eine kompakte Reise durch die Welt der agilen Transitionen, die Ihnen wertvolle Erkenntnisse für die Zukunft bietet.

Zielpublikum: Leiter:innen, Product Owner:innen, Product Manager:innen, Agile Coaches, Entscheider:innen
Voraussetzungen: Projekt-, Produktmanagement-Erfahrung, Produkt-Owner-Erfahrung
Schwierigkeitsgrad: Experte

In großen Unternehmen entwickeln viele Teams REST APIs. Dabei gibt es einige Aufgaben, die sich wiederholen: z.B. Validierung, Test und Publikation. Der Aufbau einer API Operations Pipeline zur Automatisierung dieser Aufgaben ist aufwändig. Dieser Talk zeigt am Beispiel von Azure DevOps Templates, wie so eine Pipeline als Service angeboten werden kann. So kümmert sich ein spezifisches Team um die Entwicklung und Wartung der Pipeline, während alle anderen sich auf das Design und die Entwicklung ihrer APIs fokussieren können.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: OpenAPI, DevOps
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Folgendes lernen die Zuhörenden in der Session:

• Welche Vor- und Nachteile hat es, eine API Operations Pipeline zentral zur Verfügung zu stellen?
• Welche Aufgaben kann eine API Operations Pipeline übernehmen?
• Wie können konkrete Aufgaben wie Validierung und Test umgesetzt werden?
• Wie können Azure DevOps Templates für eine API Operations Pipeline als Service eingesetzt werden?
• Wie kann das Einbinden und die Nutzung dieser Pipeline für andere Teams vereinfacht werden?

Der Talk enthält eine interaktive Live-Coding Session zu API Contract Testing.

Wenn man eine gute Übersicht über eine komplette Domäne mit einem einfachen Event-Storming-Workshop bekommt, warum machen wir dann nicht etwas Ähnliches, wenn wir eine Teststrategie entwickeln? Wir haben einen neuen kollaborativen Ansatz in Projekten erprobt und gute Ergebnisse erzielt. Am Ende hatten wir ein gemeinsames Bild, wie man mit dem Testen startet, sowie ein Backlog von offenen Punkten. Der Vortrag zeigt die Schritte, wie man in der Praxis zu einer "Minimum Viable Test Strategy" kommt.

Zielpublikum: Architekt:innen, Test Manager:innen, Tester:innen, Projektleiter:innen
Voraussetzungen: Grundkenntnisse Testen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Der Vortrag liefert ein Vorgehen, wie man eine grobe Teststrategie visualisieren kann und wie man sie mit den wesentlichen Stakeholdern kollaborativ entwirft. Als erster Schritt werden Teststufen und Testarten festgelegt. Danach werden Details wie Verantwortlichkeiten, Werkzeuge, Umgebungen und Metriken diskutiert. Dabei entstehen die ersten Regeln für das Testen und gleichzeitig ein Backlog für das Klären offener Punkte.
Die Methode ist analog zum Event Storming sehr leichtgewichtig, so dass sie direkt anwendbar ist.

Die Abstände zwischen Entwicklungsphase und Release werden kürzer. Das betrifft neue Produkte gleichermaßen, wie zusätzliche Features in App-/Webanwendungen. In der Projektleitung mangelt es oft an Integrations- und Abnahmeverfahren sowie einem Device-Setup passend zur Zielgruppe. Der Schlüssel: Kontinuität und Agilität. Am Beispiel des App-Testings für das ZDF beleuchten wir die größten Mythen über externes Testing und Automation und werfen einen Blick auf die Zukunft kombinierter QA-Verfahren.

Zielpublikum: Entscheider:innen, Projektleiter:innen, Product Owner:innen, Berater:innen, Softwareentwickler:innen
Voraussetzungen: Interesse an der Entwicklung von QA und Teststrategien
Schwierigkeitsgrad: Anfänger

Extended Abstract:
In diesem Vortrag erweitern wir die Perspektive der fachlichen Umsetzung von Testing und Automation um die Herausforderungen im agilen Prozess. Welche Anforderungen birgt eine schwer einzugrenzende Zielgruppe? Die Apps des ZDF stehen durch den öffentlich-rechtlichen Verbund in besonderer Weise auf dem Prüfstand. Wie gelingt es hier auf Seiten der Qualitätssicherung, effiziente und langfristige Lösungen zu schaffen? Unter dem Stichwort agile Testverfahren geben die Speaker Einblicke und Impulse und öffnen das Gespräch für die Seiten der Projektleitung, Entwicklung und des Testmanagements, um auf neue Methoden und die Zukunft der QA zu blicken.

Die Fähigkeiten der generativen KI-Systeme der letzten Monate verblüffen uns, so menschenähnlich wirken ChatGPT und Co teilweise. Aber was hat es mit den Fertigkeiten der Modelle tatsächlich auf sich? Verstehen KI-Modelle, was sie tun? Haben sie gar ein menschenähnliches Bewusstsein? Ausgestattet mit Informationen aus der Philosophie, der Neurowissenschaft und der KI-Technologie nähern wir uns der Frage, was Bewusstsein eigentlich ist und was wir daraus über KI-Modelle ableiten können.

This is not about what an "Agile Architecture" could be. It is about the view from the opposite direction:
How can architecture work look like in order to act as an enabler to work in the spirit of the Manifesto for Agile Software Development?
There are answers to questions like.
•    Why is architecture documentation so rarely read?
•    How much technology focus is helpful and why?
•    What knowledge needs to be built by yourself in the first place?
•    What does programming have to do with architecture?
And above all: what does it mean in practice?

Target Audience: (Senior) Software Developers, Architects, Knowledge-Managers
Prerequisites: Curiosity for why architecture work is still so difficult.
Level: Advanced

Extended Abstract:
This is not about the question "How does a good architecture emerge in an 'Agile environment'". Nor is it about whether hexagonal, clean or onion architectures are good for ‘agile projects’.
Rather, it is about the view from the opposite direction:
What should architecture work look like in practice to act as an enabler for working in the way of the Manifesto for Agile Software Development?
Covering (at least) these points:

• Being read is more important than writing or: The worm must taste good to the fish, not to the angler.
• Concepts are more important than technologies or: Kafka is not a business interface
• Parnas and Dijksta are more important than reddit/r/docker or: "Have we reinvented the wheel yet this year?"
• Software crafting is an architecture issue or: Riding a bike is only easy if you've learned how to do it

We look at what is actually meant by this in detail, and how we can arrive at "good practices" for the daily work.

Come and hear the story of a company that is on the journey from the old monolithic, on-premise, waterfall world to the new modular, agile, domain-driven, multi-tenant, cloud-based microservices world. The challenges come from different directions: both technical and organizational aspects have to be mastered. The domain has to be understood, so that the system can be structured right. The big bang has to be avoided.
In this talk we will look at how our “fictional” company has struggled with and finally overcome those challenges.

Target Audience: Architects, Developers, Project Leaders, Managers
Prerequisites: Programming Experience
Level: Advanced

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

Reducing the gender gap in technology companies is a critical goal for fostering diversity, promoting equality, and unlocking the industry's full potential. Despite significant progress in recent years, women remain underrepresented in technical roles and leadership positions. Diverse teams bring different perspectives, creativity, and innovation, leading to better problem-solving and successful businesses. By working together, we can create a future where women are equally represented and empowered in all aspects of the technology sector.

Target Audience: Leaders, C-Levels, Technical Leaders, Managers
Prerequisites: None
Level: Advanced

Extended Abstract:
The technology industry, a rapidly growing and influential sector, has made significant strides in innovation and progress. However, the underrepresentation of women in technical and leadership roles still needs to be addressed. This gender gap has far-reaching consequences, including limiting diversity in problem-solving and innovation, fostering a hostile work environment for women, and missing out on the untapped potential of the entire tech workforce.
A multifaceted approach is necessary to address this issue and build a more inclusive tech industry. For this, some actions can be performed, for example: Mentorship Programs: Establishing mentorship programs specifically for women in tech can be immensely beneficial. Having experienced mentors who understand the challenges and opportunities in the industry can help women navigate their careers, build confidence, and foster a sense of belonging. Addressing Unconscious Bias: Conducting unconscious bias training for all employees can lead to a more inclusive workplace. Tech companies can create a culture of equality and fairness by raising awareness of implicit biases and providing tools to challenge them. Retention and Support: Implementing retention programs focused on supporting women in tech careers is essential. Companies should prioritize creating an environment where women feel valued and respected and have equal opportunities for growth and advancement.
By collaborating and investing in these strategies, we can work towards a future where women are equally represented and empowered in all aspects of the technology sector. Embracing diversity and gender equality is the right thing to do and a crucial step toward driving innovation and progress in the technology sector. During this lecture, we discuss the global panorama, show some actions that have shown promising results, discuss the benefits of reducing the gap, and define joint actions that can be promptly implemented in their companies and teams.

Altersdiverse Teams tragen viel Konfliktpotenzial in sich. Sie zu führen ist oftmals eine große Herausforderung. Diskussionen über unterschiedliche Ansichten behindern den Projekterfolg. In diesem Talk möchten wir Verständnis schaffen, Missverständnisse aufklären und lösungsfokussierte Tipps für die erfolgreiche Führung von Teams mit Generationenmix anbieten.

Zielpublikum: Manager:innen, C-Level, Projektleiter:innen, Agile Coaches, Führungspersonen, geplagte Teammitglieder:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Was für ein Chaos! Derzeit arbeiten in unseren Teams bis zu 4 Generationen zusammen. Die ältesten Kolleginnen und Kollegen haben nur noch wenige Jahre bis zum Rentenantritt, die jüngsten kommen direkt von der Ausbildung und haben noch den ganzen langen Weg vor sich. Das wäre alles okay, wären da nicht diese sehr unterschiedlichen Ansichten, wenn es um Work-Life-Balance (was ist das überhaupt?), das Experimentieren mit neuen Technologien oder den Umgang mit Hierarchien und Rahmenbedingungen geht. Das Konfliktpotenzial ist riesig und die Euphorie dadurch schnell dahin. Dabei könnten die Beteiligten so viel voneinander lernen und profitieren!
In diesem Talk möchten wir ein paar wissenschaftlich fundierte Fakten über die Unterschiede und Gemeinsamkeiten der Generationen teilen und darauf aufbauend Ideen für hilfreiche Formen der Führung altersdiverser Teams anbieten - ganz nach dem Motto: Gemeinsam sind wir stärker!
Die Teilnehmenden

• erfahren, welche unterschiedlichen Bedürfnisse und Herangehensweisen Menschen unterschiedlicher Generationen mitbringen
• nehmen konkrete Ideen und Tools für den Umgang mit Mehrgenerationen-Teams mit
• lernen, wie sie im Alltag eine gute Teamkultur in solchen Teams fördern können

Programmierer:innen der Mainstream-Programmiersprachen sind schon sehr erstaunt über die Mächtigkeit eines Lisp-Makrosystems. Wir können dadurch Sprachfeatures ganz einfach selbst implementieren und die Programmiersprache auf natürliche Art und Weise erweitern.
Racket, ein besonderer Lisp-Dialekt, geht noch weiter: Nicht nur ist das Makrosystem besonders ausgefeilt (Stichwort Hygienic Macros) – die Sprache ist sogar darauf ausgelegt, Makros zu schreiben, die eigene Subsprachen (DSLs) realisieren und reibungslos zu integrieren.

Zielpublikum: Entwickler:innen, Architekt:innen
Voraussetzungen: Kein Vorwissen erforderlich
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Wir entwickeln damit komfortabel für verschiedene Domänen eigene Sprachen mit eigener Syntax. Dieser Stil wird deshalb "Language Oriented Programming" genannt – wir passen die Sprache ultimativ an die Domäne und die Anwenderin an.
Dieser Talk gibt eine kurze Einführung in Racket, dann wird das Makrosystem vorgestellt und die #lang-Funktionalität.
Es ist kein Vorwissen erforderlich.

KI hat Schattenseiten und birgt die Gefahr, Menschen in unserer eh schon vereinsamten Gesellschaft weiter zu isolieren. KI bringt aber die Chance, unserem Planeten etwas zurückzugeben. Unser Fortschritt und Technologielevel wären heute nicht da, wo sie sind, ohne dass wir so viel von unserer wunderbaren Erde genommen hätten. Jetzt ist ein genialer Zeitpunkt zurückzugeben, und das passiert auch schon.
In meinem Vortrag erzähle ich euch, wie KI zu den 17 UN-Zielen für nachhaltige Entwicklung beiträgt.

Zielpublikum: Keine Einschränkung: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager:innen, Entscheider:innen, ...
Voraussetzungen: Keine Vorkenntnisse erforderlich
Schwierigkeitsgrad: Anfänger

Extended Abstract:
KI hat Schattenseiten und birgt die Gefahr, Menschen in unserer eh schon vereinsamten Gesellschaft weiter zu isolieren. KI bringt aber die Chance, unserem Planeten etwas zurückzugeben. Unser Fortschritt und Technologielevel wären heute nicht da, wo sie sind, ohne dass wir so viel von unserer wunderbaren Erde genommen hätten. Jetzt ist ein genialer Zeitpunkt zurückzugeben, und das passiert auch schon.
In meinem Vortrag mache ich auf die Gefahren und Schattenseiten von KI aufmerksam, von der algorithmisch perfekten Diskriminierung über die Liebesbeziehung mit Robotern, die organisierte Kriminalität mit ausgeklügelter KI bis hin zum riskanten Spiel mit dem Fortbestand der Menschheit.
Weiter erzähle ich euch, wie KI zu den 17 UN-Zielen für nachhaltige Entwicklung beiträgt. Es geht um Chancen, die die rasante Entwicklung künstlicher Intelligenz für unsere Zukunft bringt: Wie leisten Ozeandaten und KI Artenschutz? Wie bekämpft KI die Flussblindheit in Afrika? Wie rettet KI den Amazonas, Bienenstöcke und vieles mehr?

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

Die Zeit des blinden Vertrauens in Scrum als Allheilmittel ist vorbei. Wir müssen der Wahrheit ins Auge blicken: Scrum funktioniert nicht immer, besonders wenn es um die Bewältigung der Herausforderungen unzureichender Anforderungen geht.
Dabei gewinnt das Verständnis der Fachlichkeit unserer Kunden zunehmend an Bedeutung. Dennoch scheitern viele Softwareprojekte aufgrund unzureichender Anforderungen.
Aber keine Sorge, es gibt Alternativen!

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Entscheider:innen, Product Owner:innen
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Wir müssen der Wahrheit ins Auge blicken: Scrum funktioniert nicht immer, besonders wenn es um die Bewältigung der Herausforderungen unzureichender Anforderungen geht.
Dabei gewinnt das Verständnis der Fachlichkeit unserer Kunden zunehmend an Bedeutung, was an der aktuellen Domain-Driven-Design-Bewegung zu erkennen ist. Hier wird die enge Zusammenarbeit zwischen Entwicklungsteams und fachlichen Experten betont. Dennoch scheitern viele Softwareprojekte aufgrund unzureichender Anforderungen.
Aber keine Sorge, es gibt Alternativen!
In diesem Vortrag werfe ich einen kritischen Blick auf Scrum und präsentiere verschiedene Tools und Methoden, mit denen unsere Entwicklungsteams tief in die Fachlichkeit eintauchen. User Story Mapping, Event Storming und Domain Storytelling sind nur einige der Werkzeuge, die wir erkunden werden. Sie helfen dabei, die Fachlichkeit besser zu verstehen, Lücken in den Anforderungen aufzudecken und eine gemeinsame Sprache zwischen dem Entwicklungsteam und den fachlichen Experten zu etablieren.
Dieser Vortrag ermutigt die Teilnehmer, das veraltete Scrum-Paradigma zu überdenken und sich stattdessen auf wirkungsvollere Methoden zu konzentrieren. Nur so können wir hochwertige Produkte entwickeln, die den Bedürfnissen unserer Kunden gerecht werden.
Lasst uns die Grenzen des Bekannten überschreiten. Es ist an der Zeit, den Status quo zu überdenken und den Weg zu bahnbrechenden Innovationen zu ebnen. Sei ein Teil dieser Veränderung und tauche ein in die faszinierende Welt der Fachlichkeit!

As more organizations are moving to the cloud, cloud architectures are getting more sophisticated by having a kind of technology diversity. This includes for example container orchestrators, database services, networking components & virtual machines.
When it comes to security, observability on this diversity is paramount. The main question here is, do you really perceive when your app landscape is under attack?
In this session, you'll have the opportunity to see various attack vectors & ways to mitigate them using different technologies.

Target Audience: Architects, Developers, Software Engineers
Prerequisites: Basic cloud & security knowledge
Level: Advanced

Extended Abstract:
Come and watch a live attack on a real-world based cloud architecture and see the attacker scan web applications and start lateral movement with the goal of exfiltrating data. Furthermore, become a part of the blue-team, defending and securing the architecture with modern open source tools.

Prozessunterstützende Werkzeuge erleichtern uns die tägliche Arbeit. Sie helfen uns, Software zu entwickeln und zu testen oder das Projekt zu steuern. Doch es gibt einen blinden Fleck: das Testdesign. Gute Tests scheinen vom Himmel zu fallen. Man muss sie nur niederschreiben oder programmieren.
Tatsächlich gibt es ein enormes Verbesserungs- und Einsparungspotenzial, welches in den meisten Organisationen ungenutzt liegen gelassen wird. In diesem Vortrag zeigen wir, welche das sind und wie modellbasiertes Testen zur Lösung beitragen kann.

Zielpublikum: Tester:innen, Testmanager:innen, Manager:innen, Projektleiter:innen Entscheider:innen
Voraussetzungen: Erfahrung mit Tests in Projekten
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Während die Industrialisierung der Software-Entwicklung in vielen Bereichen vorangekommen ist (Stichwort „CI/CD“), gibt es im Test noch immer einen grauen Fleck: das Testdesign. Von außen wenig wahrgenommen, bemühen sich Fachexperten – meist völlig ohne Werkzeugunterstützung – ihr Bestes zu geben. Das ist bestenfalls Handwerk, wenn nicht gar Kunst!
Wieso „ohne Werkzeugunterstützung“? Wir haben doch ein ALM-Tool eingeführt! Sehr gut, nur war nicht von Testmanagement die Rede, sondern von Testdesign; also von der Erstellung geeigneter Testfälle, die mit möglichst wenig Aufwand möglichst viele Aspekte abprüfen. Testdesign ist eine entscheidende Aktivität im Testprozess, die obendrein hohes Verbesserungspotenzial besitzt. Es gibt also keinen Grund, weshalb Tester sich mit einem Text-Editor zufriedengeben sollten, während die Kollegen aus der Entwicklung diverse Tools zur Unterstützung ihrer Arbeit einsetzen.
Dieser Vortrag macht auf ein Manko aufmerksam, welches nicht länger akzeptiert werden sollte, und zwar weder von Testern noch von Managern. Wieso verbringen wir Stunden mit Besprechungen zur Klärung von Anforderungen, wenn es etablierte Methoden gibt, dies zu verbessern (Stichwort: modellbasiertes Testdesign)? Wieso überarbeiten wir Testfälle und Testskripte mühsam per Hand, wenn es auch hier Werkzeuge gibt, die uns einen Teil der Arbeit abnehmen könnten?
Wir werden zeigen, welche Aktivitäten dringend Werkzeugunterstützung benötigen und wie diese aussehen kann. Ein ganz wichtiger Aspekt ist dabei selbstverständlich der Einsatz von KI, die auf vielfältige Weise hilfreich sein wird. Doch es gibt auch andere, eher prozess-basierte Ansätze wie ATDD.

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

-Intel AI everywhere – what Intel can offer you to start your AI journey 

-Intel – Intro to Intel LiftOff AI program for startups 

-live demo

-Unlock the Full Potential of Your Code and Data with GenAI with demo

-Running your own LLM in the Intel Developer Cloud - Best Practices 

-Q&A

Gute Software-Architektur strukturiert komplexe Software-Systeme so übersichtlich, dass Menschen sie verstehen und weiterentwickeln können. Also geht es bei der Software-Architektur um den Faktor Mensch. Deswegen kann sich Architektur aber nicht auf Maßnahmen für die Strukturierung der Software begrenzen, sondern muss sich auch mit den Menschen beschäftigen. In diesem Vortrag geht es um einige konkrete Ansätze und Erfahrungen, die Entwicklung durch Maßnahmen in Bezug auf den Faktor Mensch zu verbessern.

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

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

Microfrontends are a popular concept for development in an enterprise project, where a large number of teams want to work independently.
But what is the cost achieving run-time integration and independent framework versions?
JS frameworks intended to build SPAs have solved many problems like deep-linking between pages without reloading the application.
This talk will give you some real life experience which challenges are to be considered using different integration patterns, using webcomponents, module federation and "classic" libraries.

Target Audience: Architects, Developers, Project Managers
Prerequisites: Basic knowledge of Angular or other JS SPA Frameworks
Level: Advanced

Extended Abstract:
How often do project managers wish for a microfrontend architecture? Contrary to microservices in the backend, microfrontends are not always the recommended future choice.
You might have to solve a lot of problems, that have already been solved in frameworks like Angular or React.
If we start separating UI elements in encapsulated webcomponents, we risk a lot of effort re-creating capabilities like deeplinking (routing) or event handling across components.
Or: we need to add additional frameworks that solve the challenges of navigation, context transfer and layouting.
The talk provides an overview, what default architecture patterns Angular provides and how to mitigate problems that might come with classical architectures or a monorepo.
The talk will mention use cases, when the usage of microfrontends is feasible and recommended. It will also provide workarounds if a microfrontend architecture is needed.

Statische Analysetools liefern Security-Findings, aber ihre Wirksamkeit wird durch hohe Fehlalarme beeinträchtigt. Entwickler ignorieren diese, während das Management sie als kritisch betrachtet, sowohl aufgrund möglicher Angriffe als auch im Hinblick auf Security-Audits. Dadurch entstehen unnötige Kosten und Verzögerungen. In unserem Vortrag teilen wir 10 Jahre Erfahrung, präsentieren typische Sicherheitsprobleme und effektive Analyseansätze. Zudem stellen wir bewährte Methoden für kontinuierliches Monitoring und Schwachstellenabbau vor.

Zielpublikum: Entwickler:innen, Architekt:innen und Manager:innen mit Verantwortung für Security
Voraussetzungen: Interesse an hoher Sicherheit von Software
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Es gibt inzwischen viele statische Analysetools, auch kostenlose, die Security-Findings für die eigene Code-Basis erzeugen. Diese potenziellen Sicherheitslücken werden jedoch sehr unterschiedlich wahrgenommen: Aus Entwickler-Perspektive ist es oft frustrierend, wie hoch der Anteil an False Positives (also Fehlalarmen) ist. Daher sehen wir in vielen Projekten, dass die Findings ignoriert oder im Analysetool abgeschaltet werden. Aus Management-Perspektive werden solche Findings jedoch oft als kritisch bewertet. Einerseits, weil einige davon tatsächliche Angriffe ermöglichen. Andererseits, weil solche Findings bei einem (vorgeschriebenen) Security-Audit oft selbst dann aufschlagen, wenn es sich um False Positives handelt. Allerdings sind diese Findings dem Management oft bis zu einem konkreten Audit unbekannt. In Kombination führen diese beiden Perspektiven dazu, dass die Findings ignoriert werden, bis es knallt. Das ist nicht nur schmerzhaft für alle Beteiligten, sondern auch unnötig teuer, da die späte Behebung von Findings viel teurer ist, als ihre frühe Vermeidung. Im Vortrag fassen wir 10 Jahre Erfahrung aus der Analyse von vielen Systemen in unterschiedlichsten Branchen zusammen. Dabei geben wir einen Überblick, welche Security-Probleme wir typischerweise finden und durch welche Analyseansätze sie aufgedeckt werden können. Außerdem präsentieren wir ein Vorgehen zum kontinuierlichen Monitoring und Abbau von Schwachstellen, das sich bei verschiedenen Teams bewährt hat.

A successful start-up was acquired and needed to scale to at least three times its size. Leadership, processes, tools and mindsets were not ready, nor aligned on how to make that transition. Through our work supporting them, the company changed, scaled and grew. The company did so well, that the leadership team eventually had the choice to leave, knowing their creation would thrive.

Target Audience: Leaders, Managers, Coaches, Decision Makers, CTO, Engineering Managers
Prerequisites: Basic Leadership experience
Level: Advanced

Extended Abstract:
As the company was still on the brink of scaling up and the CTO was very hands on and in control, our primary mission was to take him out of the process.
Because as good as he was, he was only one person. Which doesn’t scale and he set himself up to be THE bottleneck in the system.
So how could we leverage his skills and know-how, without making him an even bigger bottleneck and at the same time empower the team?
The company was fast paced, releasing software several times per day. They were extremely customer focused and gaining traction in the market at a high speed.
When we joined, we also became part of the rave party, building, testing and shipping so quickly. It was exhilarating
The problem was that the CTO acted as a final safety check. We got hired to make this scaleable: How?

• We identified the current situation, next steps and goals.
• We made strategic hires.
• We removed waste that kept us from our goal.
• We showed progress through useful data.

We like to call this ”Overcoming The End Boss”. Together, we learned his weapons, his moves, his strategies and devised ways to master them.
Step-by-step, the team grew in numbers and so did the quality of their work. So much so that the CTO at some point told us ‘It’s the first time in the 4 years since creating this start-up, I had time to mow my lawn.’
That’s when we knew our job was done.
In this talk we’ll take you on our journey from Quality Audit to making ourselves redundant. Our wins, our failures & our learnings.

This technical session aims to unravel the unique facets of Rust's memory management, including Ownership/Borrowing, Stack/Heap allocation, Reference Counting, and Lifetimes. Rainer Stropek aims to provide an in-depth understanding of these core elements and their interplay in providing memory safety, concurrency, and abstraction in Rust. This session, designed for developers with a strong programming background, will provide insight into the mechanisms that help Rust minimize common runtime errors.

Target Audience: Developers
Prerequisites: Strong development background
Level: Expert

Extended Abstract:
In the arena of systems programming, memory management is a fundamental concern. How a language approaches memory safety, concurrency, and performance has substantial implications for the efficacy of the programs it produces. Rust's unique approach to these concerns through its intricate yet robust memory management system is the focus of this technical session.
We will explore Rust's ownership rules which hinge on three key concepts: ownership, borrowing, and lifetimes. Rust's Ownership system is unique in its way of maintaining a clear distinction between mutable and immutable references and strictly enforces a single ownership policy to ensure safe memory access. We'll delve into the 'borrow checker' system, which keeps track of scopes to enforce these rules at compile-time, effectively minimizing runtime errors.
Next, we'll look at how Rust deals with memory allocation on the Stack and Heap, providing a safer and more explicit interface to these lower-level details. A clear understanding of these processes allows developers to write efficient, error-free code.
The session also takes an in-depth look at Reference Counting (Rc and Arc), Rust's form of memory management for data that has multiple owners. This approach ensures the automatic cleanup of resources, contributing to Rust's promise of memory safety.
Lastly, we'll dissect Lifetimes, a powerful concept Rust introduces to ensure references are always valid. By defining and enforcing Lifetimes, Rust ensures that memory safety is guaranteed without any cost to runtime performance.
This session is tailored for developers who already have a strong programming background and are considering delving deeper into Rust or are interested in the unique aspects of its memory management.

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

Der Anteil der CO₂-Emissionen durch IT nimmt weltweit exponentiell zu. Verantwortlich dafür ist zum Großteil Software – von uns entwickelt.
Wer Software optimiert, kann eingesetzte IT-Ressourcen dauerhaft reduzieren und damit Kosten und Emissionen senken.
Wir diskutieren ein flexibles Vorgehensmodell, das

• mehr Aufmerksamkeit für Software-Optimierung in Unternehmen schafft
• optimale Rahmenbedingungen motiviert,
• schlummerndes Effizienzpotenzial bemisst und
• schnelle erste Erfolge ermöglicht.

Ziel: Etablierung von mehr Green-Software.

Zielpublikum: Entscheider:innen, Manager:innen, Architekt:innen, Umsetzende (fachl./techn.), PL, ESG-Berater:innen
Voraussetzungen: Der Wunsch, den CO₂-Fußabdruck oder die Kosten der IT zu senken
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Nachhaltigkeit – insbesondere die Verringerung unseres ökologischen Fußabdrucks – ist in vielen Bereichen unseres Lebens immer wichtiger geworden. Der Anteil der CO₂-Emissionen durch IT nimmt weltweit exponentiell zu. Hardware verursacht diese Emissionen. Verantwortlich dafür ist aber nur die Software. Nur was Software anfordert, muss Hardware leisten. Wir sind für die wachsenden ökologischen Auswirkungen der von uns entwickelten und betriebenen Software-Lösungen verantwortlich.
Viele wandern in die Cloud, um Kosten und den CO₂-Fußabdruck zu reduzieren. Damit werden die Symptome behandelt, aber nicht die Ursache der Probleme beseitigt. Wer Software optimiert, kann eingesetzte IT-Ressourcen dauerhaft reduzieren und damit auch den CO₂-Fußabdruck und Kosten.
Dem Management ist nicht immer transparent, wie groß der Einfluss der Applikationen auf den CO₂-Fußabdruck und die IT-Kosten ist.
Wir werden ein flexibles Vorgehensmodell diskutieren, welches

• Aufmerksamkeit für gezielte fachliche und technische Software-Optimierungen bei bestehender Software schafft,
• optimale Rahmenbedingungen für ressourcenschonende Software-Entwicklung motiviert,
• das schlummernde Effizienzpotenzial in Software initial abschätzen lässt,
• schnelle erste Erfolge ermöglicht und
• begeistert.

Dabei berücksichtigen wir zu machende Kompromisse und Erfolgsfaktoren für die Umsetzung. Grundlage dafür sind praktische Erfahrungen in einem erfolgreichen Umsetzungsprojekt.
Nach dieser Sitzung verfügt Ihr über mehrere Ansatzpunkte zur Etablierung von mehr Green-Software in Eurem Unternehmen.

Digitale Ökosysteme und Plattformökonomie begegnen uns überall: z.B. Airbnb, Uber oder Schüttflix haben das Potenzial eindrucksvoll bewiesen. Gleichzeitig gibt es immer noch zahlreiche Chancen für neue Digitale Ökosysteme und viele Unternehmen sind mutig: Trotzdem fällt es ihnen oft schwer, die Weichen richtig zu stellen. Wir präsentieren viele praktische Tipps (positiv wie negativ), die wir teils auf die harte Tour in zahlreichen Branchen gelernt haben: Vom Design des Ökosystemkerns über die Software-Entwicklung bis hin zu den nötigen Skills.

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

Extended Abstract:
Digitale Ökosysteme und Plattformökonomie haben als Geschäftsmodell zahlreiche Branchen tiefgreifend verändert und gezeigt, dass sie noch viel Potenzial für neue Geschäftsideen bieten.
Keineswegs ist das ein Hype, der am Abklingen wäre, vielmehr sind viele Unternehmen damit extrem erfolgreich positioniert und bauen ihre Position weiter aus.
Gleichzeitig können auch immer wieder neue, kleine Unternehmen in Nischen stoßen und dort neue Digitale Ökosysteme etablieren und zu beachtlicher Größe skalieren. Die Chancen sind nach wie vor riesig.
Leider gelingt es immer noch zu selten deutschen und europäischen Unternehmen, solche Geschäftsmodelle zu etablieren. Gleichzeitig ist dies aber extrem notwendig, weil sonst internationale Player den Markt beherrschen, die Regeln diktieren und ihre Vermittlungsgebühren steueroptimiert ins Ausland zu den Muttergesellschaften transferieren.
Wir haben unsere Erfahrungen beim Aufbau Digitaler Ökosysteme aus mehr als 10 Jahren zusammengestellt und möchten sie in diesem Vortrag teilen. Sie stammen aus unterschiedlichsten Branchen und Projekten und sind teils auf die harte Tour erlernt.
Die Erfahrungen umfassen sowohl Dinge, die sehr gut funktioniert haben, als auch Dinge, die nicht gut funktioniert haben.
Damit möchten wir den Horizont für alle erweitern, sich auch an Digitale Ökosysteme zu trauen und nicht Fehler zu wiederholen, die vermeidbar sind. Gleichzeitig zeigen wir auf, wo sich Digitale Ökosysteme hin entwickeln könnten und wie dies nutzbar ist.
Die Gestaltung digitaler Ökosysteme umfasst zahlreiche Aspekte von Digital Design/Innovation Design/User Centricity/Software Engineering.
Unsere Erfahrungen und Tipps sind nach unterschiedlichsten Bereichen geclustered, startend vom Design des Ökosystem-Kerns über die Software-Entwicklung, gehen weiter über den Aufbau einer passenden Community und bis hin zu Personalthemen und welche Skills besonders notwendig sind.
Denn: Wir dürfen das Feld nicht alleine den Tech-Giganten aus dem Silicon Valley überlassen!

Mehr Inhalte dieser Speaker? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/matthias.naab, https://www.sigs.de/autor/marcus.trapp

"Which programming language is the fastest" usually is everyone's first thought when green software is mentioned! It's a common deduction that the fastest code is, therefore, the most efficient, which then, of course, can save us from this climate disaster. However, code efficiency is not even half of the story! In this talk, Sarah will review the three approaches that make software green. She will also introduce efficiency-achieving practices that can take us closer to fighting this pesky climate change.

Target Audience: Architects, Developers, SRE/DevOps
Prerequisites: Basic knowledge of any Programming Language, Introductory Familiarity with DevOps Space
Level: Basic

Extended Abstract:
In this talk, I will go over the following:

1. My journey so far with green software emphasizes how I don't need to leave my climate enthusiasm at home every day when I go to work
2. Brief facts about WHY we need to take action now in the tech industry
3. 3 approaches that make software green
4. Why code efficiency is not the answer to most green software problems with an example
5. Going over why DevOps practices are much more effective in achieving greenness in software with a couple of examples
6. Wrapping up with fruit for thoughts, especially highlighting the close connection between DevOps practices and Green Software practices
7. Encourage the audience to look at their software engineering problems through a green software lense

While AI systems differ in some points from "traditional" systems, testing them does not have to be more difficult - knowing the right questions to ask will go a long way. In this talk we will:

• Arm you with a checklist of questions to ask when preparing to test an AI system
• Show you that testers and data scientist have common ground when testing AI systems

Keep calm and test on - AI systems are not that different from "normal" systems.

Target Audience: Testers, Data Scientists, Developers, Product Owners, Architects
Prerequisites: Basic knowledge of software testing
Level: Advanced

Extended Abstract:
If you're a tester about to test your first AI system, or wanting to move into that area, you're probably wondering how you can prepare for the role. While we usually do not deal with complexity in the magnitude of Large Language models like chatGPT, AI systems still seemingly offer different challenges than "traditional" systems.
You're not the first person to deal with these questions. In fact, a group of us got together to explore it in more detail. Is there a general framework of questions that testers can use to help develop a quality strategy for systems that use AI? We wanted to see if we could design one. To this end, we got together a group with diverse roles: tester, test architect, data scientist, project lead and CEO.
Join us in this talk to hear how we approached the task and what our results are, including an example of using our checklist of questions to analyse a system that uses AI. Along the way we also addressed questions like "What is the role of a tester in such projects?" and "How much math do I need?" - we'll talk about those discussions, too. We encourage participants to use our checklist and give us feedback on it!

Nach einer Fusion standen wir vor vielen Herausforderungen: Konsolidierung zweier großer IT-Landschaften auf eine, Integration und technologische Modernisierung. Dabei müssen wir Anforderungen aus Markt und Regulatorik weiter bedienen. Hierfür benötigen wir Architekturkompetenz.
Im Vortrag zeigen wir, wie wir unsere Architekturkompetenz durch Einführung einer neuen dezentralen Architekturrolle stark skaliert haben.
Wir stellen vor, wie wir die neue Rolle ins Architekturmanagement eingebettet haben und was die kritischen Erfolgsfaktoren waren.

Zielpublikum: Architekt:innen, Projektleiter:innen, Manager:innen, Entscheider:innen
Voraussetzungen: Grundlegende Kenntnisse im Architekturmanagement sind hilfreich
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Wir benötigten eine erheblich größere Anzahl von Architekturkompetenzen (ca. 25-30 Architekt:innen), als wir für die Bewältigung unserer Aufgaben hatten. Verstärkung durch externe Berater:innen ist eine Möglichkeit, aber kein Allheilmittel und auch nicht nachhaltig. Neue Kolleg:innen einzustellen ist in einem sehr engen Arbeitsmarkt nicht erfolgversprechend.
Unser Ansatz war daher, uns organisch aus der eigenen IT-Organisation heraus zu verstärken. Neben einer zentralen Architekturabteilung haben wir dezentral in den einzelnen IT-Teams eine neue Rolle etabliert, die des "Solution Architect".
In unserem Vortrag stellen wir vor, wie wir diese neue Rolle etabliert haben. Dabei betrachten wir organisatorische Aspekte, z.B. wie sich diese neue Rolle in bestehende Architekturmanagementprozesse einbettet und wie zentrale und dezentrale IT-Architektur zusammenarbeiten. Wir gehen darauf ein, welche Verantwortlichkeiten und Aufgaben diese Rolle mitbringt und wie wir Handlungsspielräume z.B. in Form unseres Technologiemanagements über Mikro- und Makroarchitekturentscheidungen managen.
Ein Schwerpunkt des Vortrags wird das Change-Management sein. Es beginnt damit, wie wir die Kolleg:innen identifiziert und von der Rolle überzeugt haben. Ohne richtige Ausbildung funktioniert die Übernahme einer solchen Rolle nicht. Daher zeigen wir, welche kurz- und mittelfristigen Maßnahmen wir für Schulung in IT-Architekturthemen unternommen haben. Dabei fußt unser Schulungskonzept auf drei Säulen: Methodik (eng angelehnt an ISAQB), Technologie und Leadership. Wir stellen dar, was wir darüber hinaus an spezifischer Ausbildung in unseren speziellen Themen durchführen und wie wir Mentoring und Coaching etablieren.
Kritische Erfolgsfaktoren (davon gibt es reichlich) und welche Stolpersteine und Skeptiker:innen uns auf dem Weg begegnet sind und wie wir im Rahmen des Change-Managements darauf reagiert haben, runden den Vortrag ab.

Ein großer Teil der Software-Entwicklung 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 Software-Entwicklung 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 langlebigen Softwaresystemen zurechtzukommen.

Zielpublikum: Software-Architekt:innen, Entwickler:innen
Voraussetzungen: Erfahrung mit optimierungsbedürftigen Softwaresystemen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Es ist wahrscheinlich, dass ihr in euren aktuellen Projekten damit beschäftigt seid, ältere Systeme am Leben zu erhalten, zu erweitern und zu aktualisieren. Dies kann zu Unmut, Überforderung und Zweifeln an der Berufswahl führen, da wir in der Ausbildung oft nur das Entwickeln von Neuem gelernt haben.
Für den richtigen Umgang mit Legacy-Systemen ist zuallererst ein spezielles Mindset für uns als Software-Architekt:innen erforderlich: das eines Softwareevolutionisten. Wie bei der Flickschusterei und Archäologie, wo Reparaturen und Nachforschungen wichtig sind, um etwas Altes funktionsfähig zu erhalten oder wichtige Erkenntnisse aus der Vergangenheit zu gewinnen, benötigen wir ähnliche Herangehensweisen bei der Arbeit an Altsystemen. Wir geben euch ein paar Tipps aus der Praxis, um die dafür benötigte Zeit und Energie im stressigen Entwicklungsalltag zu finden.
Wir gehen kurz auf konkrete Praktiken ein, die uns bei dieser Weiterentwicklungsreise unterstützen, wie etwa die Mikado-Methode, bei der wir inkrementell Schritte zur Umstrukturierung von Software vornehmen. Um hier das Big Picture der Evolution nicht aus den Augen zu verlieren, werfen wir einen Blick auf Kommunikationsmethoden größerer Umbauvorhaben mit Quality Views. Mit der iterativen Prozessverbesserung mittels des Popcorn-Flows geben wir euch ein Werkzeug an die Hand, um iterativ passende Vorgehen für eure Verbesserung auszuwählen und aus alten Gewohnheiten auszubrechen.
Wir möchten euch mit diesem Vortrag motivieren, stolz auf eure Arbeit mit Legacy-Systemen zu sein, und euch eure Bedenken bei der Modernisierung eines Systems nehmen. Es gibt viel zu tun, also fangen wir an: Es könnte ja gut werden!

Expanding Horizons, the motto of OOP 2024, invites exciting thoughts about the future of software engineering. What will a developer's working day look like in 2034? What environments, tools, and practices will they use to create, test, deploy, and operate software? What will our daily lives look like in a digitalized world in 2034? What types of software systems will be everywhere? What systems will we use at work? What architectures and technologies do these systems rely on? Frank and Kevlin look into the future.

Target Audience: Anyone curious about the future of software engineering
Prerequisites: Interest and sound knowledge in software engineering, architecture and development
Level: Advanced

Extended Abstract:
Expanding Horizons, the motto of OOP 2024, invites exciting thoughts about the future of software engineering. What will a developer's working day look like in 2034? What environments, tools, and practices will they use to create, test, deploy, and operate software? What will our daily lives look like in a digitalized world in 2034? What types of software systems will be everywhere? What systems will we use at work? What architectures and technologies do these systems rely on?
The view is not always clear, but we can look at past and present trends to ask questions and make some forecasts. How will AI affect the daily work of developers, but also everyone else's work? Digitalization is affecting everyone from government to individual — how far will it have taken us by 2034? The last couple of years have seen a lot of media around cryptocurrency, Web3 and the Metaverse, but to what extent will these hopes and hypes actually have affected software development and software usage? What new trends can we expect to see in software architecture, programming languages and workplace culture?
Join Frank and Kevlin as they look into the future, a decade from now.

This session will provide you with insights into the core skill of slicing work and how it is crucial to business agility. Using real-life scenarios, we'll explore the different dimensions of how slicing affects work, including ease of delegation, adapting scope, quality control, measuring and assessing progress, and improving using feedback.
This session will give you inspiration and practical tips for how to slice your projects differently.

Target Audience: Decision Makers, Managers, Project Leaders, Product Owners
Prerequisites: None
Level: Basic

Extended Abstract:
If you love to see and hear lots of real life examples that help you understand and communicate what agility in business is about, this session is for you.
Using real-life scenarios, we'll explore the different dimensions of slicing work, including delegation, scope, quality control, and feedback, and provide practical tips for how to do it effectively. We'll also examine how unpredictability can affect measuring progress and provide strategies to help you adapt. By the end of the session, you'll have a clear understanding of the art of slicing work and be able to apply it to your work for improved business agility.

Your Key Take-Aways:

• Understanding how slicing work affects adaptability, delegation, quality control, responsibility, effectiveness, and tracking of progress
• Learning several strategies to slice work that you can apply at your workplace
• Inspiration from several real-life examples

Python befindet sich seit Jahren unter den Top 3 der populärsten Programmiersprachen. Spätestens seit dem anhaltenden Hype um maschinelles Lernen führt selbst für normalsterbliche Entwickler praktisch kein Weg mehr an Python vorbei.
Aber wieso ist die Sprache eigentlich so beliebt – selbst außerhalb von Machine Learning? Welche Eigenschaften zeichnet sie aus? Ist es sinnvoll – und funktioniert das überhaupt –, so einfach von Java, .NET oder C++ auf Python umzusteigen?

Zielpublikum: Erfahrene Software-Entwickler:innen und -Architekt:innen
Voraussetzungen: Erfahrung in einer Hochsprache, typischerweise aus der Java-, .NET-Welt oder C++-Welt
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Als langjähriger Java-Entwickler ist dem Vortragenden natürlich v.a. die Java-Sicht sehr gut bekannt, sodass (hoffentlich) ein möglichst wertneutrales Bild davon gegeben werden kann, was Java von Python unterscheidet und wo beide Sprachen jeweils ihre Stärken und ihre Schwächen haben. Wie bitte? Schwächen? – Ja, auch die gibt es. ;-)

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

Nachhaltigkeit geht uns alle an. Auch bei der Software-Entwicklung und -nutzung. Weißt du, wie viel CO₂ du beim Streaming verursachst? Oder dass deine Software nicht nur im Betrieb, sondern auch bei der Entwicklung und Nutzung CO₂ verursacht?
Nach diesem Impulsvortrag weißt du, wie du Online-, Mobile- und OnPremise-Anwendungen optimierst und wie du mit kleinen Schritten bei dir und großen Schritten im Unternehmen nachhaltig(er) wirst. Neben ein bisschen Theorie haben wir auch jede Menge Praxisbeispiele im Gepäck.

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

Die Business-Verantwortlichen sind oft unzufrieden mit der Software-Entwicklung: "Wenn die Entwicklungs-Teams nur schneller arbeiten würden, wären wir viel erfolgreicher!" Und obwohl die Teams Feature um Feature ausliefern, will sich der Erfolg nicht einstellen – die Build Trap.
Meist ist in dieser Situation gar nicht klar, welches Ziel das Produkt eigentlich erreichen soll, weil es immer nur um Output geht und kaum Outcome. Ich zeige in dem Vortrag anhand praktischer Beispiele, wie man die Build Trap erkennt und wie man ihr entrinnt.

Zielpublikum: Entwickler:innen, Architekt:innen, Product Owner:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Data, the way that we process it and store it, is one of many important aspects of IT. Data is the lifeblood of our organizations, supporting real-time business processes and decision-making. For our DevOps strategy to be truly effective we must be able to safely and quickly evolve production databases, just as we safely and quickly evolve production code. Yet for many organizations their data sources prove to be less than trustworthy and their data-oriented development efforts little more than productivity sinkholes.

Target Audience: Developers, Data Engineers, DevOps Engineers
Prerequisites: Understanding of DevOps
Level: Advanced

Extended Abstract:
This presentation begins with a collection of agile principles for data professionals and of data principles for agile developers - the first step in working together is to understand and appreciate the priorities and strengths of the people that we work with. Our focus is on a collection of practices that enable development teams to easily and safely evolve and deploy databases. These techniques include agile data modeling, database refactoring, database regression testing, continuous database integration, and continuous database deployment. We also work through operational strategies required of production databases to support your DevOps strategy. If data sources aren’t an explicit part of your DevOps strategy then you’re not really doing DevOps, are you?

Security engineering from TARA and security requirements to security testing demand mechanisms to generate, verify, and connect the resulting work products. Traditional methods need lots of manual work and yet show inconsistencies and imbalanced tests. Generative AI allows novel methods with semi-automatic cyber security requirements engineering, traceability, and testing. In this industry presentation, we show two promising approaches with NLP and transformers and how to embed them into an industry-scale security pipeline from TARA to test.

Target Audience: Test Engineers, QA Experts, Security Experts, Requirements and Systems Engineers
Prerequisites: Some background on security and testing. We will hands-on introduce the AI methods.
Level: Advanced

Extended Abstract:
Security engineering from TARA and security requirements to security testing demand mechanisms to generate, verify, and connect the resulting work products. Traditional methods need lots of manual work such as for traceability and yet show little impact when looking at the many inconsistencies and imbalanced tests. NLP especially transformers allow novel methods with semi-automatic cyber security requirements engineering, traceability, and testing.
We focus here on using generative AI with NLP because they can support the methods described in the standard while there is no need to change the form of representation from what is required by cybersecurity standards and respective stakeholders. Especially the use of Large Language Models (LLM) for text generation, aggregation, and classification has recently proven promising to improve the efficiency and effectiveness of security analysis and tests.
Grey Box Penetration Testing is an approach where only publicly available information is used to perform an attack on the SUT. This often requires massive research effort. Threat catalogs were known and often used threats are recorded can increase the performance while testing. To provide additional aid we are currently working towards building an AI-supported threat catalogue. Therefore, we use a special transformer model which is specialized in searching and summarizing information. When fed with known information about the SUT this model searches all available databases like CVE or CAPEC, previously recorded attack patterns, and other contextual information available and gives the penetration test engineer an initial idea of how to approach an attack on the SUT.
Using the AI to generate both grey and white box attack paths is an approach to check how much information about the system or components such as libraries and dependencies which are used in the SUT are available. Having introduced these methods to the security life-cycle, we will in the next step better integrate the tools. This will facilitate a swift turn-around upon changes in an agile delivery pipeline and thus achieve consistency from TARA to security requirements and (regression) test cases.
Vector together with the University of Stuttgart has developed transformers and generative AI-based methodologies for the specification and validation of cybersecurity requirements with the goal to increase productivity and quality.
In this industry presentation, we practically show how generative AI can scale into an industry-scale security pipeline.

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

Lehnen Sie sich zurück und genießen Sie es, wenn Nicolai Josuttis mit Gästen aus der IT-Szene unser Business in gemütlicher Atmosphäre nicht ganz so ernst nimmt.

Zielpublikum: Software-Architekt:innen, Software-Entwickler:innen, Projekt-Manager
Schwierigkeitsgrad: Nominiert für Kabarett-Award

Die ideale Gelegenheit zum Netzwerken und Austauschen bietet die Welcome Reception. Lassen Sie den Konferenztag mit anderen Teilnehmern, Referenten, Ausstellern und Sponsoren bei Fingerfood und Getränken in der Expo ausklingen.

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

Menschen, die vom Imposter-Phänomen (meist Imposter-Syndrom genannt) betroffen sind, haben das Gefühl, Betrüger zu sein & ihren eigenen Erfolg nicht verdient zu haben, trotz nachweisbarer Kompetenz. Sind diese Menschen mit den damit verbundenen Unsicherheiten & Selbstzweifeln deshalb eine Bürde im Team? Wir glauben, das Gegenteil ist der Fall & dass hier ein Schatz für starke Teams in komplexen Umgebungen gehoben werden kann. In dieser Session werden wir diese Sichtweise fundiert herleiten & in konkreten Übungen Implementierungsideen mitgeben.

Zielpublikum: Menschen mit Interesse an starken Teams
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Selbst manche sehr erfolgreiche Menschen leiden unter dem Denkmuster des Imposter-Syndroms*. Vielleicht sind sie gerade wegen ihres Imposter-Syndroms so erfolgreich? Denn auch wenn das Imposter-Syndrom Menschen gefangen hält, indem es ihnen suggeriert, dass sie sich ihre Position nicht wirklich verdient hätten, wird es nicht für alle zum Hemmschuh. Auch wenn dieses Denkmuster sie glauben lässt, dass sie nicht ausreichend qualifiziert wären für die Tätigkeit, die sie ausüben, üben sie sie doch effektiv aus. Auch wenn besonders Frauen mit diesem Phänomen zu kämpfen haben, gibt es einige Beispiele von Menschen, die aus dieser vermeintlichen Schwäche Kapital gezogen haben. Ist es also vielleicht gar keine persönliche Schwäche?
Teilnehmer:innen an diesem Talk werden

1. Den Zusammenhang vom Umgang mit Komplexität und dem Imposter-Syndrom kennenlernen
2. Einen Perspektivwechsel vornehmen, um das Imposter-Syndrom aus der Sicht auf Kommunikation, Inklusion und den Umgang mit Risiken zu betrachten
3. In praktischen Beispielen erleben, wie die Stärken von Menschen mit Imposter-Syndrom für Teams aktiviert werden können.

 *Wir finden den Begriff „Imposter-Syndrom“ nicht gut gewählt, zum einen, da er impliziert, dass eine Form von Hochstapelei vorliegt, wo es doch eher um die Sorge geht, Erwartungen anderer nicht gerecht zu werden. Zum anderen ist ein Syndrom per Definition eine Kombination von Krankheitszeichen. Aus unserer Sicht liegen bei diesem Phänomen hinderliche Denkmuster vor, die Menschen das Leben schwer machen. Diagnosen möchten wir lieber Ärzt:innen oder Psycholog:innen überlassen. Allerdings ist der Begriff „Imposter-Syndrom“ der gängige Begriff, unter welchem Information z.B. im Internet auffindbar ist. Daher verwenden wir ihn – mit Einschränkungen.

Pfleger:innen in Seniorenheimen arbeiten mit ganzem Körpereinsatz - und ansonsten vor allem mit Papier und Fax. Zeit und Ressourcen sind rar. Auf der Prioritätenliste steht Digitalisierung weit hinten. Wie schafft man es dennoch, künftige Nutzer:innen für ein digitales Produkt zu begeistern und ihr Wissen und ihren Support zu gewinnen? Diese Frage mussten Nelli Hergenröther und ihr Team beantworten, als sie 2020 ein Projekt für einen der führenden Anbieter für Pflegedienstleistungen in Berlin-Brandenburg übernahmen, das sie bis heute betreuen.

Zielpublikum: Projektleiter:innen, Produktmanager:innen, UX Designer:innen, Entscheider:innen, Digitalisierungs-Beauftragte
Voraussetzungen: Grundlagen digitale Produktentwicklung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Der Pflegeanbieter domino-world ist in der Branche für seinen seit 20 Jahren bestehenden, zertifizierten domino-coaching Prozess bekannt, der bis vor einigen Jahren komplett auf Papier durchgeführt wurde. Papier ist geduldig, deswegen haben auf Papier durchgeführte Prozesse oft die Flexibilität, die Software mangelt. Dennoch kann die richtige Software Prozesse vereinfachen und viel Arbeit sparen. Aber wie überzeugt man die zukünftigen Nutzer:innen, bei der Entwicklung mitzuwirken, vor allem, wenn es sich um den allerersten Digitalisierungsprozess im Unternehmen handelt? Der Erfahrungsbericht einer Agentur, die normalerweise auf Apps spezialisiert ist, hier aber schon bei der Beschaffung von E-Mail-Adressen eingestiegen ist.

Leider sind viele skalierte Entwicklungen bürokratisch träge.
Der Vortrag führt in den Agile Descaling Cycle ein, der als Werkzeug helfen kann, eine eigene schlanke Skalierungsstruktur zu finden; unabhängig davon, ob bereits skaliert gearbeitet wird oder nicht.
In der Session können die Teilnehmenden selbst ein paar Techniken ausprobieren, die ihnen helfen, die eigene Skalierungsstruktur zu finden.
Die Teilnehmenden haben nach der Session eine Idee, wie sie die eigene Skalierungsstruktur verschlanken können.

Zielpublikum: Manager:innen, Product Owner:innen, Scrum Master:innen, Projektleiter:innen, Release Train Engineers, Produktmanager:innen
Voraussetzungen: Erfahrungen mit agiler Skalierung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Ein Team, ein Produkt. So sind wir mit agil vor über 20 Jahren gestartet. Heute sieht die Realität häufig anders aus: Es werden mehrere Teams für die Entwicklung benötigt. Skalierte agile Entwicklung ist heute eher die Regel als die Ausnahme.
Leider sind viele skalierte Entwicklungen bürokratisch träge - mit der teamübergreifenden Zusammenarbeit kam die Bürokratie: zusätzliche Abstimmungsmeetings, Artefakte und Rollen. Im Lean-Sinne ist viel davon Waste - weil sie nicht direkt zur Wertschöpfung beitragen. Und das Extreme-Programming-Motto "Do The Simplest Thing That Could Possibly Work" scheint kaum noch gelebt zu werden.
Der Vortrag führt in den Agile Descaling Cycle ein, der als Werkzeug helfen kann, eine eigene schlanke Skalierungsstruktur zu finden; unabhängig davon, ob bereits skaliert gearbeitet wird oder nicht.
In der Session können die Teilnehmenden selbst ein paar Techniken ausprobieren, die ihnen helfen, die eigene Skalierungsstruktur zu finden.
Die Teilnehmenden haben nach der Session eine Idee, wie sie die eigene Skalierungsstruktur verschlanken können.

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

In this session, two co-creators of Org Topologies™, Alexey Krivitsky and Roland Flemm, will share a method to design, assess and improve your organizational ecosystem.
They will do that by familiarizing you with a set of organizational archetypes that are easy to spot. Hopefully, you will have much better clarity on which organization ecosystem you want to build and which behaviors you expect it to exhibit.
You shall be able to take this tool home and use it as a map in your ongoing, never-ending transformation journey toward agility.

Target Audience: Decision Makers, Transformation Team Members, Coaches, Leadership
Prerequisites: Challenges with scaling agility
Level: Advanced

Extended Abstract:
The legacy of the original lightweight barely sufficient Agile ideas (namely XP and Scrum) has been impeded by the difficulties of applying them beyond a single team without losing the key principles and the promised gains.
Over the last decade, that challenge has led to a rose in heavy-weight methods, especially SAFe™, which has become a go-to place for "everything agile". It provides the user with a profound variety of specific tools and techniques for "scaling agile". Many enterprises are on the path of "rolling out" these ideas by the book with the help of trained coaches. But will we eventually get the promised gains of agility once we fulfill the requirements of the framework in our enterprise? Is such a prescriptive approach agile itself? And more importantly: will we own the change and know how to keep improving beyond the rule book?
In recent years, we have seen the emergence of other methods: framework-agnostic org design DIY toolboxes. In this family of modern ideas, Team Topologies™ and unFix™ stand out from the crowd. Their approach is to offer us a "lunch buffet" to pick structures and processes that suit our situation. It is a flexible approach with a lot of freedom of choice. It offers a fresh path for some of us trying to avoid the burden of frameworks. But the freedom of freely picking org elements implies that we possess a clear bigger picture and won't get lost in the night-gritty details of the puzzle pieces. As leaders, managers, and coaches, how fluent are we in org design, queuing theory, and systems thinking? How can we be confident that we won't lose the plot by trying to put together those puzzle pieces? And more importantly: will we get long-term gains, or will we inflict more unforeseen problems by focusing too much on the small building blocks rather than the whole system?
Difficult questions. Org Topologies™ doesn't have all of them answered for us. But being a framework-agnostic approach for designing agile ecosystems where business and technology would work as one, it can provide us with a solid basis on which all other decisions can be grounded. Essentially, Org Topologies™ moves us from the dualism of frameworks vs. DIY methods into the realm of ecosystems - a unity of interdependent organizational parts that together exhibit well-recognized behaviors.
In this session, two co-creators of Org Topologies™, Alexey Krivitsky and Roland Flemm, will share a method to design, assess and improve your organizational ecosystem. They will do that by familiarizing you with a set of organizational archetypes that are easy to spot in any organization. Hopefully, by the end of the talk, you will have much better clarity on which organization ecosystem you want to build and which behaviors you expect it to exhibit. Eventually, you shall be able to take this tool home and use it with your leadership group as a map in your ongoing, never-ending transformation journey toward agility.

The introduction of ChatGPT, CoPilot X brings in a lot of hype over developer experiences, especially documentation. But are we ready to chat with our documentation, instead of reading, using these tools? How can we, as maintainers, leverage these tools to offer a better experience in documentation for developers as our users? Join my talk and let's find out.

Target Audience: Engineers, Developers
Prerequisites: Programming
Level: Advanced

Discover the transformative power of GenAI in software testing. This lecture showcases a powerful GenAI-powered test framework that enhances testing efficiency. Learn how GenAI analyzes applications to generate automated test cases, uncover hidden defects with generative AI's random exploratory tests. Experience AI-powered peer reviewers for code analysis and quality evaluations. Explore Smart Report AI, providing comprehensive analysis and insights into test execution, results, and defects. Join us to revolutionize your software testing with GenAI.

Target Audience: Quality Engineers, Architects, Developers, Project Leader, Managers
Prerequisites: Basic knowledge on modern software development
Level: Advanced

Extended Abstract:
In the rapidly evolving landscape of software development Generative AI holds immense potential to revolutionize the field of software testing. This lecture aims to explore the transformative capabilities of GenAI in software testing by showcasing the powerful GenAI powered test framework and its key components.
The lecture begins by introducing the main framework, which combines the power of GenAI and automation to enhance the efficiency and effectiveness of software testing. Attendees will learn how GenAI can analyze the application under test and generate automated test cases based on a predefined test framework. These test cases can be executed locally or seamlessly integrated into DevOps processes, allowing for efficient and comprehensive testing of applications.
Furthermore, the lecture delves into the utilization of generative AI for the generation of random exploratory tests. By leveraging the capabilities of GenAI, testers can uncover hidden defects and vulnerabilities that may go unnoticed with traditional testing approaches. This demonstration highlights the innovative potential of GenAI in driving comprehensive test coverage.
Additionally, the lecture showcases the Smart Peer AI component of the framework. Attendees will discover how AI-powered peer reviewers can anticipate functional and non-functional issues, providing insightful code analysis and quality evaluations. By incorporating specific coding best practices, architectural standards, and non-standard attributes, Smart Peer AI enhances code quality and accelerates the development process.
Finally, the lecture concludes by presenting the Smart Report AI, an AI-powered solution that analyzes test reports generated from automated testing processes. This component provides a comprehensive analysis of test execution, environment configuration, test results, defect severity automated analysis, reproducibility steps, and suggestions for fixes. Smart Report AI empowers testers with valuable insights and facilitates effective decision-making in the testing and development lifecycle.

The Product Owner role in Scrum is vital, but lacks comprehensive guidance. This talk presents the SMIQ Method (Single Most Important Question), derived from the "48 hour book method," empowering Product Owners and Managers to translate customer needs into software requirements. It simplifies complex techniques into user-friendly steps for effective requirements engineering. The speaker's success in using this method for writing books, organizing conferences, and developing software highlights its simplicity and effectiveness.

Target Audience: Product Owners, Product Managers, Requirements Engineers, UX, Project Managers
Prerequisites: Scrum, Product Owner role in Scrum, beginner level knowledge of User-centered design
Level: Basic

Extended Abstract:
Product Owner is one of the most critical roles in the Scrum Framework. However, beyond “the backlog” and “prioritization”, there’s very little guidance as to what that role entails. This talk presents a method (The SMIQ or Single Most Important Question Method, discussed in the “48 hour book method”) that guides Product Owners, and Product Managers in their discovery work, and helps them translate customer needs into Software requirements. It’s a simple method, but it offers the opportunity for in-depth understanding and effective requirements management. The method achieves it’s simple format by codifying some complex techniques into a simple set of steps that anyone can use, and this speaker has used to write books, create conferences, and develop software.
Key Learnings

1. The challenge of understanding the customer, and what is required to succeed
2. How to translate real life into software requirements, reliably, and quickly
3. Concrete practices and techniques to implement the method suggested
4. Practical application of the SMIQ method in the conference room, with the participants
5. How to bring the SMIQ method to our work as Product Owners and Product Managers

Stoic practitioners know they cannot control circumstances, other people or rather... they know they cannot control anything outside of the realm of their own choices. So as a Stoic Product Leader you should stop focussing on outcome (!). Outcome is always outside of your control. However the CHOICES you need to make the product vision and goals ARE within your power, within your control. So the best thing you can do as a (product) leader is improving the quality of your decisions and teach your teams how to do that too.

Target Audience: Project/Portfolio Leaders, Product Owners, Product Managers, Leadership, Decision Makers
Prerequisites: None
Level: Basic

Extended Abstract:
Stoic practitioners know they cannot control circumstances, other people, behaviour of other people in their teams, or simply: they know they cannot control anything outside of their own mind, the realm of their own choices.
So as a Stoic Product Leader you should stop focussing on outcome. Outcome is outside of your control as a leader. Your own choices are within your control. The choices you need to make in the long run (product vision) and the ones you need to make that are right in front of you (iteration goal).
So the best thing you can do as a (product) leader is improving the quality of your decisions and teach your teams how to improve their ability to make better choices.
(Sustainable) product leadership is far more like poker (with uncontrollable circumstances and emerging events that influence possible outcomes) than like chess (if you think long and hard you could predict what is the next best move).
* Learning goals

1. know how to move from outcome focus to focus on improving decision quality
2. know how to implement habits that will improve your decision making as a product leader

This session will help you make better, more sustainable product choices

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

Agile Transformation wird oft als obligatorische Aufgabe gesehen, ohne den tatsächlichen organisatorischen Bedarf zu berücksichtigen. Doch sie bietet Chancen zur
Prozessverbesserung. Der Haken ist aber oft, dass der genaue, eigene Bedarf im Unternehmen oft nicht bekannt ist und nach "best practices" der Industrie gehandelt wird.
Frei nach dem Motto „was bei anderen funktioniert, ist für uns nur recht“ werden Gilden und Tribes initiiert, Communities of Practice gebildet und die Re-Organisationen in die Wege geleitet.

Doch wie können wir die eigenen Bedarfe identifizieren? Woher bekommen wir das Wissen über den Status Quo in der Organisation? Als Tester im Herzen hinterfragen wir gerne den Systemzustände und wie es dazu kam. In diesem Vortrag möchten wir gerne praktische Beispiele aus unserer Projekterfahrung mit Behörden und privaten Unternehmen einfließen lassen und aufzeigen, wie wir als Coaches und Berater einen nachhaltigen, individuellen Wandel begeleitet haben.

Zielpublikum: Tester:innen, Testautomatisierer:innen, Manager:innen, Führungskräfte, Entscheider:innen
Voraussetzungen: Projekterfahrung, Kenntnisse Software-Entwicklungs-Teams, Change-Management
Schwierigkeitsgrad: Anfänger

Extended Abstract:
In unserem Vortrag möchten wir skizzieren, wie wir den Wandel der IT-Abteilungen z.B. großer Behörden begleitet haben. Wir werden unsere Erfahrung von Beginn des Projekts
teilen und auch auf Ideen eingehen, die nicht funktioniert haben und wie wir damit umgegangen sind.

• Wie kamen wir an die notwendige Datenbasis? Wie können Interview-Leitfäden aussehen und wen sollte man befragen?
• Kann man überhaupt KPIs eines Change-Projekts bilden?
• Wie sieht eine Kommunikationsstrategie aus, von vorstandsgerechter Management- Summary bis zur detailreichen Kommunikation innerhalb der Abteilungen?
• Konnten wir Ideen generalisieren und wiederverwenden, oder ist alles individuell geschnitten?
• All das und noch viel mehr werden wir anhand eines agilen Lebenszyklusmodells behandeln und unsere Erfahrung mit Ihnen teilen.

Wir wollen in diesem Vortrag betonen, warum Quality Coaches in einer strategischen Position sind, um als Schnittstelle zwischen Test-Abteilungen, Management und Mitarbeiter:innen, den Wandel aktiv mitzugestalten.

Stell dir vor, wie viel Zeit UND Nerven du sparen könntest, wenn Kommunikation einfach mal funktionieren würde! Klingt wie ein Märchen für dich? Kennen wir. Richtige Kommunikation ist ein Skill, den unsere "T-Shape Teams" häufig erst noch erlernen müssen. Eine Möglichkeit ist durchs Coaching. Bei uns schlüpft der Quality Coach schnell mal in die Rolle des Übersetzers - ob von Wasserfall-Sprech zu Agile, von emotional zu sachlich, von technisch zu fachlich oder von kompliziert-chaotisch zu einfach-strukturiert. Geht nicht? Geht doch!

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager:innen, Entscheider:innen, Testmanager:innen, Quality Coaches, Tester:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Stell dir vor, wie viel Zeit UND Nerven du sparen könntest, wenn Kommunikation einfach mal funktionieren würde! Klingt wie ein Märchen für dich? Kennen wir.
Selbst mit einem Studium im Kommunikationsmanagement und als erfahrener Redakteur und Regisseur begegnen wir in unserem Alltag der Software-Entwicklung immer wieder Stolperfallen durch misslungene Kommunikation.
Auch Kommunikation ist ein Skill, den unsere "T-Shape Teams" häufig erst noch erlernen müssen. Eine Möglichkeit ist durchs Coaching. Bei uns schlüpft der Quality Coach schnell mal in die Rolle des Übersetzers - ob von Wasserfall-Sprech zu Agile, von emotional zu sachlich, von technisch zu fachlich oder von kompliziert-chaotisch zu einfach-strukturiert.
Und nicht nur das, die Rolle sensibilisiert und bringt den Leuten Tipps bei, ihre Kommunikation nachhaltig zu verbessern.
Setz dich in unser Theaterstück und erlebe ein Live-Coaching, aus dem du direkt einige wertvolle Tipps mitnehmen wirst. Wir werden einen Testmanager aus der Wasserfall-Welt mit einem agilen Tester auf der Bühne diskutieren lassen und schauen dann einem Quality Coach dabei zu, was ihm auffällt und wie sich das Ganze retten lässt. Am Ende schauen wir uns an, ob die beiden was daraus gelernt haben.
Wir werden Antworten auf folgende Fragen finden:
Sind Akzeptanzkriterien gleich Akzeptanzkriterien? Was können wir tun, um Kommunikation zu erleichtern? Wie arbeitet ein Quality Coach? Und warum tun sich Personen, die in der traditionellen Softwarelieferung arbeiten, so schwer, mit denen im agilen Liefermodus zusammen zu arbeiten, und andersrum genauso? Und natürlich: Was kann ich tun, damit mir Kommunikation gelingt?

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

Dieser Special Day muss separat gebucht werden.
» Jetzt direkt kostenfrei anmelden

Die Moderation über den Tag führt Rainald Menge-Sonnentag (iX) durch.

Daten sind der Schatz des modernen Unternehmens, ein Schlüssel zur fundierten Entscheidungsfindung und ein unmittelbarer Wegbereiter für den Erfolg – zumindest in der Theorie.

Doch die Realität sieht oft anders aus. Daten sind häufig in isolierten Systemen gefangen, ohne klare Verantwortlichkeit, ohne Transparenz über ihre Nutzung und ohne Klarheit darüber, in welchem Format oder welcher Qualität sie vorliegen. In einer Zeit, in der Microservices die IT-Landschaft revolutionieren, gerät die Integration von Alt und Neu oft aus dem Blickfeld. Statt der erhofften Harmonie entstehen neue, nicht integrierte Datensilos, die die Herausforderungen verschärfen.

In unserem Vortrag enthüllen wir, wie Unternehmen ihre IT-Architektur transformieren können. Wir zeigen, warum es entscheidend ist, über eine dynamisch belastbare Architektur und eine konsistente API- und Datenstrategie nachzudenken, um die richtigen Daten zur richtigen Zeit an den richtigen Ort zu bringen.

This Special Day must be booked separately.
» Register now for free

In diesem Vortrag stellen wir eine agile DataGrid-Architektur vor, die Datenproblematik und typische Abhängigkeitsprobleme in der Welt der Microservices vermeidet.
Wir zeigen, wie wir zu einer etwas anderen Architektur kommen, die die Vorteile der Agilität mit den Anforderungen an Datenqualität und Konsistenz vereint.

Für ein modernes Web-Frontend greift man am besten zu Angular, React & Co., oder? - Nicht unbedingt! Auch native Bordmittel, zusammen mit ein paar Libraries, können eine echte, leichtgewichtige Alternative sein. Und man kann sogar schrittweise dorthin migrieren. Basierend auf konkreter Projekterfahrung, möchte ich den Blick für diesen Ansatz schärfen, Vor- und Nachteile aufzeigen und das Ganze anhand von Codebeispielen illustrieren.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Wer schonmal etwas von JavaScript, HTML und Angular/React/... gehört hat, ist richtig
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
„Ein modernes Web-Frontend kann man nur mit Angular, React o. ä. bauen, weil die HTML- und JavaScript-Bordmittel bei Weitem nicht ausreichen. Da helfen auch ein paar kleine Libraries nicht.“
Dieser häufig anzutreffenden Ansicht möchte ich in diesem Vortrag widersprechen und dem reflexartigen Griff zu Angular & Co. eine Alternative gegenüberstellen: WebComponents ... also doch die nativen Bordmittel!
Mit WebComponents lässt sich eine Web-Applikation aus unabhängigen, wiederverwendbaren Komponenten entwickeln, ohne sich an ein schwergewichtiges Framework zu binden. Frameworks sind Gesamtpakete, die bequem sein können, aber auch Nachteile mit sich bringen. Zum Beispiel können sie durch ihren All-In-One-Charakter unflexibel sein und eine große Abhängigkeit auf sich einfordern, von der es sich zu lösen lohnen kann. Der vorgestellte Ansatz tut dies. Die üblicherweise vom Framework bereitgestellten Features und Tools werden dabei durch kleine Libraries ersetzt, die zu den individuellen Anforderungen des Projekts passen und jederzeit unabhängig voneinander aktualisiert/ersetzt werden können.
Basierend auf konkreter Projekterfahrung möchte ich aufzeigen, dass man auch ohne Framework ein voll- und hochwertiges Web-Frontend entwickeln kann. Sogar dass man Schritt für Schritt unter Beibehaltung der Lieferfähigkeit von einem Framework wegmigrieren kann, ganz im agilen Sinne. Ich bin auf jeden Fall glücklich damit, dass mein Team den Mut dazu aufgebracht hat, und dass wir dadurch bei einem besseren Frontend mit einer nachhaltigen Architektur herausgekommen sind.
Welche Vorteile bietet dieser Ansatz? Wie geht das denn konkret mit den WebComponents? Wie ersetzt man die „unverzichtbaren“ Vorteile eines Frameworks? Was genau verstehen wir hier eigentlich unter einem Framework? Wie schmerzhaft ist eine Migration weg von einem Framework, hin zu einer reinen WebComponent-Lösung? Geht eine solche Lösung nicht mit viel mehr Komplexität einher? Auf diese Fragen möchte ich eingehen, Live Coding inklusive.

Gefühlt stand das Akronym WWW lange Zeit eher für Wild Wild West. Architekturmuster und -Prinzipien waren im Frontend oft die Ausnahme. Erst mit der letzten großen Frameworkwelle und dem Siegeszug von SPAs begann ein längst notwendiges Umdenken.
Neuere Technologien führen aber nicht automatisch zu einer besseren Architektur. Es gilt, nach wie vor, Architekturmuster gezielt einzusetzen. Eines der bekanntesten Muster im Domain-Driven Design ist die Hexagonale Architektur. Wann lohnt sich der Einsatz und wie funktioniert das in der Praxis?

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Frontend-Erfahrung und TypeScript-Kentnisse sind hilfreich
Schwierigkeitsgrad: Fortgeschritten

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.

Leaders should be passionate, think strategically and influence their people (a.k.a. followers).
How is that possible without empathy, self-consciousness & resiliency?
How is that possible without emotional literacy?
Spoiler: It isn’t!
But - god forbid - nobody wants to be labelled as “being emotional” at work, right?
Join me to leverage your emotional data as the true assets they are. Expand your horizon with serious psychological background and get some of my real-life rants on top for free (some of them I wish would better be fiction).

Target Audience: Developers, Architects, Managers of all flavours, Leaders of all kinds, curious human beings
Prerequisites: Curiosity and some work/project experience is beneficial
Level: Advanced

Extended Abstract:
I have to confess, the "true rants" will only be a side dish in this session.
You also will be learning - mainly about R.A.N.T.-based leadership, of course:
RA - I’ll showcase why Relation & Acceptance is the core of sustainable leadership.
N - You will learn why 'the Now' matters that much - and how to leverage your presence as a (seasoned) leader.
T - Because in the end, we all want to get the things that matter done. Together! Don’t we?

You have to deal with people - always! Konflikte & Veränderungen fordern uns heraus. Wir schaffen es nicht, diese Themen zu bearbeiten. Das führt zu Unzufriedenheit & Frust.
In unserem Vortrag wollen wir konkrete systemische Prinzipien und Methoden von 2 erfahrenen Coaches mitgeben, die eine neue Perspektive auf Herausforderungen im Projektalltag geben und eine persönliche Weiterentwicklung unterstützen können. Laut Zukunftsforschern wird die systemische Perspektive immer mehr zu einer Kernkompetenz von Akteuren in der modernen Arbeitswelt.

Target Audience: Software Engineers, Leaders, Scrum Masters, Agile Coaches
Prerequisites: None
Level: Basic

Extended Abstract:
Wenn Menschen zusammenarbeiten, kann es immer wieder Situationen geben, die in uns Stress erzeugen. Termin- und Entscheidungsdruck, ungelöste Konflikte und eine rasante Veränderungsgeschwindigkeit fordern uns täglich heraus. Als Führungskraft möchte ich meine Mitarbeiter:innen in Entscheidungen einbeziehen, muss aber trotzdem meiner Führungsrolle gerecht werden. Als Team-Mitglied habe ich vielleicht einen Konflikt mit jemandem im Team und weiß nicht, wie ich damit umgehen soll. Als Scrum Master begleite ich agile Veränderungsprozesse und bin auf der Suche nach Ideen und Impulsen, wie ich besser mit auftretenden Widerständen umgehen kann.
Systemisch beobachten, denken und handeln ist eine Grundhaltung, die uns helfen kann, besser mit sozialer Komplexität und organisatorischen Paradoxien umzugehen. Laut Zukunftsforschern wird die systemische Perspektive, wie sie z.B. auch professionelle Coaches und Therapeuten nutzen, immer mehr zu einer unverzichtbaren Kernkompetenz von Akteuren in der modernen Arbeitswelt (siehe auch Harvard Business Manager 01/2022 „Führen wie ein Coach“ oder „Future Skills“ von Pechstein, Spiegel et al., 2021).
Die Systemische Perspektive einnehmen bedeutet z.B., Zusammenhänge, Wechselwirkungen, Rückkopplungen, Rollen und Wahrnehmungen (auch die eigene) in komplexen Systemen zu erkennen und darauf aufbauend achtsam zu kommunizieren und zu handeln. Weitere Prinzipien wie Wertschätzung, Ressourcen-Orientierung, Lösungsfokussierung helfen, den Menschen und seine Bedürfnisse in den Mittelpunkt der Betrachtung zu stellen, und dadurch anschlussfähigere Lösungsansätze zu gewinnen.
In unserem Vortrag wollen wir die Systemische Haltung als „Mindset“ der Systemiker vorstellen. Darüber hinaus stellen wir 10 Denkanstöße und konkrete Methoden vor, die jede/r im Arbeitsalltag ausprobieren und seine/ihre systemische Haltung ausprobieren bzw. üben kann.
Als Führungskraft und Agile Coach bringen wir zwei wertvolle Perspektiven auf Menschen und Organisationen mit und finden so große Anschlussfähigkeit für die täglichen Herausforderungen von Teams, Führungskräften, Scrum Mastern und Agile Coaches.

In today's economy, creating intelligent customer experiences is a key differentiator for organizations looking to compete and gain a competitive advantage. Use of AI and especially Generative AI became more prevalent in the business world. We will discuss some of the work we did on creating an AI-Driven CX Platform that offers data management, Customer360 views, personalization and chatbots infused with Generative AI, and advanced security features. We will also discuss practical use cases and outcomes of our approach.

Target Audience: Managers, Decision Makers, Leaders
Prerequisites: None
Level: Advanced

Softwaresysteme sind oft große, verwachsene Strukturen, welche Softwareschaffende nach einiger Zeit wieder in Form bringen müssen. Es ist aber eine Herausforderung, einen Überblick über das wuchernde Konglomerat von Softwarekomponenten und Funktionalitäten zu gewinnen, ganz zu schweigen von der Entwicklung eines klaren Plans für das weitere Vorgehen. Im Vortrag verwende ich Analogien aus der Pflege von Apfelbäumen, um Softwaremodernisierenden zu zeigen, wie sie ihre Softwaresysteme mit einem wertorientierten Ansatz weiterentwickeln können.

Zielpublikum: Architekt:innen, Produktentwickler:innen, Softwareentwickler:innen, Softwaremodernisierer:innen
Voraussetzungen: Erfahrung mit optimierungsbedürftigen Softwaresystemen
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Beim Zurechtstutzen eines Apfelbaums haben wir mehrere Optionen, die wir nutzen können. Wir können Äste etwa zurechtstutzen, abschneiden oder einfach komplett ignorieren. Auch Softwaresysteme können wir zurechtstutzen, Teile des Systems abtrennen oder gewisse Bereiche einfach ignorieren. Aber wie schaffen wir es, fundiert über diese verschiedenen Optionen bei der Weiterentwicklung von Softwaresystemen zu reden? Wir brauchen dazu ein klares Bild unseres Softwaresystems genauso, wie wir vor einem Obstbaumschnitt ein klares Bild des Baums benötigen.
In diesem Vortrag zeige ich daher, wie sich ein ähnliches Bild wie bei einem Apfelbaum mit Hilfe der Wardley-Mapping-Technik für komplexe Softwaresysteme gewinnen lässt. Auf Basis dieses Bilds lassen sich dann verschiedenen Optionen des „Systemzurückschnitts“ unter Produktentwickelnde diskutieren und kleine, handlungsorientierte Pläne für die weitere Entwicklung eines Softwaresystems kommunizieren.

Beim Analysieren und Zerlegen von Legacy-Systemen nach DDD sind wir auf Domänen gestoßen, die einfach in Subdomänen aufgeteilt werden konnten, und auf Domänen, bei denen es deutlich schwieriger war. Auch das Alter und der Entwicklungsgrad einer Domäne haben Einfluss auf unsere Möglichkeiten, gute Subdomänen zu finden und die Legacy zu modularisieren. Inzwischen können wir diese Unterschiede beschreiben und haben verschiedene Domain Patterns gefunden und benannt. Ich freue mich auf Feedback und Diskussionen von den Zuhörer:innen.

Zielpublikum: Architekt:innen, Entwickler:innen, Business-Analyst:innen, Projektleiter:innen
Voraussetzungen: Projekterfahrung, Basiswissen in DDD
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
In den letzten Jahren haben wie eine Reihe von Domänen mit Subdomänen gesehen und mit DDD zerlegt. Ziel war natürlich immer, ein oder mehrere Softwaresysteme auf die Subdomänen aufzuteilen und eine sinnvolle Zerlegung des Softwaresystems anhand des Domänenschnitts zu erreichen. Mit der Zeit haben wir den folgenden Eindruck gewonnen:

1. Es gibt (Sub-)Domänen, die sich leichter in (Sub-)Subdomänen zerlegen lassen, und solche, bei denen es deutlich schwerer ist.
2. Es gibt Umsetzungen in fachliche Kontexte, die es leichter oder schwerer machen, das Legacy-System zu zerlegen.
3. Die Entwicklung der Domäne und der Software beeinflussen sich gegenseitig und die Legacy-Software ist je nach Entwicklungszustand anders zu zerlegen.

In diesem Talk werde ich unsere Überlegungen zu Domain Patterns und ihrer Umsetzung vorstellen und hoffe auf Diskussionen und Feedback.

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

Many developers evoke technical debt to explain the misfortunes and troubles of their codebase and delivery. While unmanaged technical debt weighs down an architecture and exerts drag on its schedule, it is more often an effect than a cause. In this talk, we will look at what is and is not meant by technical debt with a view to properly attributing the root and recurring cause as technical neglect than technical debt. Without seeing technical neglect for what it is, we will continue to misattribute our problems to an effect rather than a cause.

Target Audience: Developers, Architects, Technical Managers
Prerequisites: Responsibility for software development, whether implementing it, guiding it or managing it
Level: Advanced

Extended Abstract:
Many developers evoke the mischievous spirit and day-to-day burden of technical debt to explain the misfortunes and troubles of their codebase and delivery. While unmanaged technical debt weighs down an architecture and exerts drag on its schedule, it is more often an effect than a cause. In this talk, we will look at what is and is not meant by technical debt — and other metaphors — with a view to properly attributing the root and recurring cause as technical neglect than technical debt. Without seeing technical neglect for what it is, we will continue to misattribute our problems to an effect rather than a cause.

Dieser Special Day muss separat gebucht werden.
» Jetzt direkt kostenfrei anmelden

Domain-Driven Design, Event-Storming Workshops, Microservices, Read/Write Separation, Kafka & Event Streaming, Event Mashups, Process Mining and Analytics, Internet of Things … Stets dabei: das Thema Events. Wir wollen es in dieser Session genauer erkunden. Was ist das für ein Konzept? Wir besprechen, was Events ausmachen als neue Art von Daten in der Organisation. Und wir besprechen, wie Events ein wesentlicher Schlüssel für erfolgreiche Digitalisierung sind:

• Entkoppelung von Microservices
• Basis für Mini-Workflows via Command Bus Pattern: IF THIS (event) THAN THAT (command)
• Basis für Analytics und die lernende Organisation – welche Prozesse laufen schlecht, wie können wir sie optimieren?
• Grundlage für Eingriff near real time (Beispiel: Kunde hat vor 5 Sekunden aufgehört, seinen Warenkorb zu bearbeiten).

Spätestens seit ChatGPT in die breite Nutzung gekommen ist, wird das Thema Künstliche Intelligenz öffentlich breit diskutiert. Neben technischer Faszination, verschiedenen Ängsten und teils überzogenen Erwartungen spielen dabei verschiedene Fragen von individueller und gesellschaftlicher Verantwortung eine Rolle. Wie können die enormen Chancen von KI genutzt und etwaige Risiken verringert bzw. vermieden werden? Im Vortrag werden die aktuelle ethische Debatte beleuchtet und Lösungsvorschläge diskutiert.

This Special Day must be booked separately.
» Register now for free

Discover how to modernize legacy applications using Business API facades and hybrid architectures, leveraging the API-first approach and the Kong Gateway.

In this session, you’ll learn the benefits of Business API facades as an intermediary layer and the flexibility of hybrid architectures in transitioning from monolithic to microservices-based systems. You’ll also gain practical insights into successful modernization strategies, ensuring your organization's adaptability and competitiveness.

Auch wenn ihr Microservices bereits umgesetzt habt, hängt ein wirklich erfolgreiches Produkt von technisch weiterführenden, methodischen und organisatorischen Themen ab. Wie stark ist die vertikale Idee ausgeprägt? Gibt es eine “Thinnest Viable Platform” und einen Pfad des geringsten Widerstands? Wie gut sind empirische Prozesse ausgeprägt und wie dezentral sind eure Entscheidungswege? In diesem Talk geben wir die Möglichkeit zum Self-Assessment und liefern damit Impulse, Microservices besser zu leben.

Zielpublikum: Architekt:innen, Entwickler:innen und alle, die an vertikalen Architekturen beteiligt sind
Voraussetzungen: Erfahrungen mit Microservices
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Viele Microservices-Anwendungen sind in Betrieb oder werden dort bereits weiterentwickelt und verbessert. Ob ein Microservices-basiertes System wirklich erfolgreich ist, hängt allerdings nicht nur von der technischen Migration ab, die initial geleistet wird. Um Versprechen in Bezug auf kürzere Release-Zeiten, bessere Agilität, höhere Innovationskraft und verbesserte Flexibilität und Skalierbarkeit einzulösen, braucht es weiterführende Impulse. Entwicklungsvorhaben und Teams müssen sich technisch, methodisch und organisatorisch weiterentwickeln.
In dieser Session zeigen wir einige weiterführende Themen, die unserer Erfahrung nach stark mit dem langfristigen Erfolg eines Microservices-Produkts korrelieren. Wie stark ist die vertikale Idee ausgeprägt? Gibt es eine “Thinnest Viable Platform” und einen Pfad des geringsten Widerstands? Wie gut sind empirische Prozesse ausgeprägt und wie dezentral sind die Entscheidungswege? Wie direkt und feinmaschig ist Feedback für qualitative Zielerreichung verfügbar? Aus einem Katalog von Fragen stellen wir hier einige vor. Sie führen allesamt zu einer evolutionären Idee der System- und Architekturentwicklung.
Um zum Nachdenken anzuregen und den Transfer auf den eigenen Kontext zu verbessern, liefern wir nicht nur Theorie, sondern zeigen auch Prüfmöglichkeiten für das eigene System und Reflexionsfragen für die eigene Organisation. Ein kleines Self-Assessment zieht sich durch den Talk und kann offline weiter vertieft werden. Insgesamt ein Schritt in die Richtung Microservices besser umzusetzen und die evolutionäre Idee dahinter besser zu leben.

Effizienz/Performanz gehört neben Sicherheit zu den meistgefragten Qualitätsattributen. Doch was heißt überhaupt Performanz und wie sollten Software-Architekten damit konkret umgehen? Gibt es einen Unterschied zwischen Performanz und Skalierbarkeit? Gibt es Architekturkonzepte, die sich beim Umgang mit Performanzkriterien als nützlich erweisen? Und wie lässt sich die Performanz eines Systems testen? Diese und andere Fragen möchte der Vortrag beantworten.

Zielpublikum: Entwickler:innen, Architekt:innen, Tester:innen
Voraussetzungen: Software-Architekturkenntnisse
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Effizienz/Performanz gehört neben Sicherheit zu den meistgefragten Qualitätsattributen. Doch was heißt überhaupt Performanz und wie sollten Software-Architekten damit umgehen? Gibt es einen Unterschied zwischen Performanz und Skalierbarkeit?
Gerade beim strategischen Design beziehungsweise Architekturentwurf ist der Umgang mit Performanzzielen schwierig. Zudem können Performanzziele mit anderen Qualitätsattributen in Konflikt stehen, etwa mit Sicherheit. Wie lassen sich aber solche Konflikte auflösen? Gibt es Architekturkonzepte, die sich beim Umgang mit Performanzkriterien als nützlich erweisen? Und wie lässt sich die Performanz eines Systems verifizieren bzw. testen? Diese und andere Fragen möchte der Vortrag beantworten.
Lernziele:

1. Verständnis für die verschiedenen Facetten von Performanz
2. Erlernen der systematischen Behandlung von Performanzzielen auch in Hinblick auf andere Qualitätsattribute
3. Erlernen von Architekturkonzepten und Vorgehensweisen

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