For a technology company, building a strong engineering culture is essential for long-term success. Today's software industry is growing so fast that a large proportion of developers will inevitably have less than 5 years experience. At the same time, many software systems contain code that is ten, twenty or even thirty years old.

It's a constant challenge to communicate a healthy culture to newcomers and prevent technical debt from getting out of control. Technical coaching is all about tackling those issues: culture and skills.

Target Audience: Developers, Architects
Prerequisites: None
Level: Basic

Extended Abstract:
The Samman method is a concrete coaching method for spreading skills and culture within an engineering organization. There are two main parts to the method:
- Learning Hour
- Ensemble working

In the learning hour the coach uses exercises and active learning techniques to teach the theory and practice of skills like Test-Driven Development and Refactoring. In two-hour Ensemble sessions the whole team collaborates together with the coach in applying agile development techniques in their usual production codebase.

In combination with strong technical leadership, the Samman method can enable the spread of skills and culture to bring a healthy engineering organization to the next level.

"Ich hatte keine Zeit, den Zaun zu flicken" - Dieses Zitat kennt wohl jeder, und doch ertappen wir uns selbst, unseren Zaun nicht geflickt, sondern stattdessen die Hühner gesucht zu haben.
Doch wie ändere ich das?
Dieser Vortrag zeigt mit dem Konzept der MLCs ein Tool auf, dieser Falle zu begegnen und sich selbst und andere in den Modus des kontinuierlichen Lernens zu versetzen.
Am Ende haben die Zuhörenden einen ersten MLC durchlaufen und ein Tool erlernt, um sich und anderen den Freiraum zum Lernen zu erschaffen.

Zielpublikum: Coaches, Entscheider, Projektleiter:innen, Transformation Manager, Architekt:innen, Lebenslange Lernende
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Micro-Learning-Cycles sind kein theoretisches Konstrukt, sie sind tatsächlich aus der Notwendigkeit entstanden, trotz vollem Terminkalender Zeit zum Lernen zu finden.
Neben der Vermittlung und Anwendung von MLC zeigt die Referentin auch aus der Praxis, wo sie MLCs einsetzte, was funktionierte und wo auch Limitierungen sind.

"If you can't measure it, you can't improve it." Although it is (relatively) easy to measure objectively quantifiable decision criteria such as profit, how does one measure "soft" attributes, such as psychological safety or team dynamics, to judge an intervention's success?

This talk will present insights into the practical application of leading-edge research into what makes intelligent, high-performing teams and organisations, exploring the science behind the current buzzwords of psychological safety, diversity, and empathy.

Target Audience: Managers, Coaches, ScrumMasters
Prerequisites: None
Level: Advanced

Extended Abstract:
"If you can't measure it, you can't improve it." This quote, attributed to Peter Drucker, emphasises that the ability to measure something is essential for seeing changes in it. Although it is (relatively) easy to measure objectively quantifiable decision criteria such as profit, how does one measure "soft" attributes, such as psychological safety or team dynamics, to judge an intervention's success? The problem with most team/organisational assessments is that they say more about the persons who designed the evaluation (and what they want to sell) than about the persons taking it.

This talk will present insights into the practical application of leading-edge research into what makes intelligent, high-performing teams and organisations, exploring the science behind the current buzzwords of psychological safety, diversity, and empathy.

Measuring quality requires many questions to be answered. The most obvious ones may be: “What is quality?”, but also “How can we measure it?”, “Which metrics are most accurate?”, “Which are most practical?”.

In this talk, I share some general motivations for measuring quality. I review commonly used metrics that claim to measure quality, I rate them with regards to how they may be helpful or harmful to achieve actual goals. I give some examples how the weaknesses of one metric might be countered by another one to create a beneficial system.

Target Audience: Developers, Project Leader, Manager, Decision Makers, Quality Engineers, Testers, Product Owners
Prerequisites: Basic Software Project Experience, Rough Understanding of Software Development
Level: Advanced

Extended Abstract:
Measuring quality requires many questions to be answered. The most obvious ones may be: “What is quality?”, but also “How can we measure it?”, “Which metrics are most accurate?”, “Which are most practical?”.

In my experience, one question is often not answered or postponed until it is too late: “Why do we want to measure quality?” Is it because we want to control how well our developers are performing? Is it to detect problems early? Is it to measure the impact of changes? Is it the product or the process we care about? Is it to improve locally in a single team or globally across the company? Is there a specific problem that we are trying to solve, and if so, which one?

Instead of trying to define what software quality is – which is hard and depends on a lot of factors – we should first focus on the impact of our measuring. Some metrics may work great for one team, but not for the company as a whole. Some will help to reach your team or organizational goal, some will not help at all, and some will even have terrible side effects by setting unintended incentives. Some can be gamed, others might be harmful to motivation. Consider an overemphasis on lead time, which can lead to cutting corners. Or measuring the number of bugs found, which can cause a testers versus developers situation.

In this talk, I share some general motivations for measuring quality. I review various commonly used metrics that claim to measure quality. Based on my experience, I rate them with regards to how they may be helpful or harmful to achieve actual goals and which side effects are to be expected. I give some examples how the weaknesses of one metric might be countered by another one to create a beneficial system.

UI testing is an essential part of software development. But the automation of UI tests is still considered too complex and flaky.
This talk will cover the "state of the art" of UI testing with an overview of tools and techniques. It will be shown which kind of representations are used by today's test tools and how the addressing of elements in the UI is done.
In addition, the role of artificial intelligence in the different approaches is shown and a prediction of testing tools of the future is presented.

Target Audience: Developers, Testers
Prerequisites: Basic Knowledge of UI-Testing
Level: Advanced

Extended Abstract:
UI testing is an essential part of software development. Despite technological progress, the automation of UI tests is still considered too complex to function completely without manual intervention.
In addition to classical selector-based approaches, more and more image-based methods are being pursued.
This talk will cover the "state of the art" of UI testing with an overview of tools and techniques. In particular, current problems and future developments will be discussed. Furthermore, it will be shown which kind of UI representations are used by today's test tools and how the addressing of elements in the user interface is done.
In addition, the role of artificial intelligence in the different approaches is shown and a prediction of testing tools of the future is presented on the basis of current research.

When we talk about leadership and balance, we also need to talk about how we handle toxic behaviour in our midst and how we protect ourselves and our communities from it. As a full-time open source maintainer and project leader, I've sadly had to encounter many ungrateful, entitled or outright toxic people.

In this session I'll first show some examples, then share some coping strategies that I've successfully used to deal with them. I'll also share some things that everyone can do to help with responding to negativity.

Target Audience: Developers, Project Leaders, Open Source Users
Prerequisites: None
Level: Basic

Extended Abstract:
It's no secret that running an open source project has its dark sides, and one of these is having to sometimes interact with quite ungrateful, entitled or outright toxic people. As a project's popularity increases, so does the frequency of this kind of interaction, adding to the burden shouldered by maintainers and possibly becoming a significant risk factor for maintainer burnout.

I've been the project leader and maintainer of a quite popular project for almost ten years straight now, and had to develop the one or other coping strategy to deal with these interactions, in order to not let them drag me down and negatively affect my motivation and mental health. In this talk I want to first give a classification of the most common forms of bad and toxic behaviour I've seen, and then share my personal approach to dealing with them, explaining why this has worked for me along the line.

In the end, the viewer should take away some concrete advice on how to handle possibly volatile interpersonal situations in the context of an open source project and beyond without compromising on their own mental well-being.

Zero Trust Architecture has become the norm for how to modernize IT security in an age of growing network complexity and fewer ways to define hard network boundaries. Today, APIs are a standard way of how organizations expose both technical and business capabilities. But what does it mean for an API to be "Zero Trust Ready"?

In this presentation we look at some of the general patterns that APIs need to follow for Zero Trust readiness. We also look at some concrete practices for how to follow those patterns in your own APIs and API landscape.

Target Audience: Architects, Developers, API Designers, API Program/Platform Managers, Security Leads
Prerequisites: Basic knowledge of API terminology
Level: Advanced

For a microservices architecture to be successful it is crucial to have the right boundaries between the microservices. But where are the right boundaries? We would like to present a tool that helps us answer this question.

Domain Storytelling is a collaborative modeling method. It brings together domain experts and development teams. We let our users tell us stories about their work. While listening, we record the stories using a pictographic language.

In this talk we show how to find subdomains and which heuristics can help us.

Target Audience: Architects, Developers
Prerequisites: Project experience
Level: Advanced

Extended Abstract:
For a microservices architecture to be successful it is crucial to have the right boundaries between the microservices. But where are the right boundaries? We would like to present a tool that helps us answer this question.

Domain Storytelling is a collaborative modeling method. It brings together domain experts and development teams. We let our users tell us stories about their work. While listening, we record the stories using a pictographic language.

The experts can immediately see if we understand their story. After very few stories, we understand the language of our users and find different areas of the domain. Each of these areas (called a subdomain) is a good candidate to become a microservice in our architecture.

In this talk we show how to find subdomains and which heuristics can help us.

At first glance, testing AI systems seems very different from testing “conventional” systems. However, many standard testing activities can be preserved as they are or only need small extensions.

In this talk, we give an overview of topics that will help you test AI systems: Attributes of training/testing/validation data, model performance metrics, and the statistical nature of AI systems. We will then relate these to testing tasks and show you how to integrate them.

Target Audience: Developers, Testers, Architects
Prerequisites: Basic knowledge of testing
Level: Basic

Extended Abstract:
From a testing perspective, systems that include AI components seem like a nightmare at first glance. How can you test a system that contains enough math to fill several textbooks and changes its behavior on the whims of its input data? How can you test what even its creators don’t fully understand?

Keep calm, grab a towel and carry on - what you have already been doing is still applicable, and most of the new things you should know are not as arcane as they might seem. Granted, some dimensions of AI systems like bias or explainability will likely not be able to be tested for in all cases. However, this complexity has been around for decades even in systems without any AI whatsoever. Additionally, you will have allies: Data scientists love talking about testing data.

In this talk, we give an overview of topics that will help you test AI systems: Attributes of training/testing/validation data, model performance metrics, and the statistical nature of AI systems. We will then relate these to testing tasks and show you how to integrate them.

The developers have instrumented the applications with OpenTelemetry — great! But that doesn't mean you're ready to roll it out in production yet. What do you need to keep in mind for your instrumentation infrastructure?

* Quick OpenTelemetry overview.
* Tradeoffs between the three architectures you use with OTel (depending on your vendor): vendor exporter vs OTel Collector vs OTel protocol support
* Sampling, including head vs tail based, and how to keep it representative and / or useful.

Target Audience: Architects, Developers
Prerequisites: Software development knowledge and some monitoring experience is also helpful
Level: Advanced

Extended Abstract:
The developers have instrumented the applications with OpenTelemetry — great! But that doesn't mean you're ready to roll it out in production. What do you need to keep in mind for your instrumentation infrastructure? OpenTelemetry is THE emerging standard for monitoring and creating more observable systems. Starting with an overview, this talk then dives into two areas that make a big difference in cost, flexibility, and insights:

Firstly, the three possible integration architectures with vendor exporter, OpenTelemetry Collector, and native protocol support; and why a combination of Collector and native protocol are the most common choice today.
Secondly, sampling or how to get the big picture from a subset of the data (and cost). Here the tradeoffs evolve around head- vs tail-based sampling and how to keep the collected data representative and / or useful. It generally comes down to simpler and cheaper with the head-based approach, while the tail-based one is potentially more useful with higher overhead. And now it's time to roll it out in production!

Many approaches to software architecture assume that architecture be planned at the beginning from the project's quality goals. This is problematic as the macroarchitecture is hard to change, and the quality goals it's based on tend to be unknown at the beginning of a project, or change later. Consequently, it would really be preferable if we could defer the macroarchitectural decisions until later.

This talk shows how to do this using systematic modelling and functional programming.

Target Audience: Developers, Architects
Prerequisites: Basic architecture knowledge
Level: Advanced

Extended Abstract:
What should we do first then? We should write down what we know, at the time we know it, and do it in such a way that we generate reusable components that can be assembled into any macroarchitecture.

Concretely, this can be done by using staple techniques from functional programming:
•    building small, flexible combinators instead of fixed attribute-structure OO models
•    decoupling pervasively using abstraction
•    using immutability to avoid hidden dependencies

The talk shows how to do this, and report on our experience in several concrete projects.

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

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

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

Extended Abstract:
The journey will have the following stages:

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

Stage 2: Customisation of an Open Source product

Stage 3: Migration - decisions and actual experiences during migration

Stage 4: Rollout and staying alive

In recent decades, our scientific and clinical understanding of how our nervous system works has increased tremendously. I’ve recently completed an education for trauma-informed work (NARM informed professional). It has changed many key aspects of how I teach and coach and will continue to have a large impact.

In this session, I’m presenting those key learnings, connecting them to well-known parts of Agile knowledge and inviting into a discussion of what a more trauma-informed approach to leading people in Agile organisations could look like.

Target Audience: All kinds of Leaders, Product Owners, People Managers, Decision Makers, Coaches, Scrum Masters
Prerequisites: No prerequisites
Level: Advanced

Extended Abstract:
In recent decades, our scientific and clinical understanding of how our nervous system develops and works has increased tremendously. Its implications are so profound, they radiate far beyond the field of psychology. Topics such as trauma-informed law, trauma-informed volleyball coaching, legal counseling, education, social activism have arisen. It is time to think about how it affects leadership.

Your speaker Anton, a Scrum trainer and coach, has recently completed a NARM-informed professional education. It has tremendously changed some key aspects of how he leads, teaches and coaches and will surely continue to have a large impact. In this session, he is presenting those key learning, connects them to well-known parts of Agile knowledge and invites into a discussion of what a more trauma-informed approach to leadership could look like.

In this talk you will:
•    experience a more calmer vulnerable space
•    learn what developmental trauma is and how it plays out in the workplace
•    learn about regulation and states of our nervous systems and its connection to creativity and cognitive capacity
•    get a new angle to think and act about topics such as responsibility, clarification of assignments and setting goals, teaching, mentoring and more
•    reflect on how these topics affects your own line of work and exchange on ideas

I will share our hands-on experience with a cloud native (container) transformation that is currently unfolding. Technically, implementing an Open Shift Container Platform (bare metal) is pretty challenging. Doing this in a way that we will have pretty stuff in our data centers and at the same time making sure that our technical possibilities are actually being used effectively by product developers ... is a different challenge all together.

Join this session if you'd like to hear what we figured out about the people side of this kind of change!

Target Audience: Architects, Management, Developers, Operational Heroes, Product Owners, Agile Coaches, Scrum Masters
Prerequisites: Basic knowledge of DevOps concepts
Level: Advanced

Extended Abstract:
In this session I will share our hands-on experiences implementing a container-based architecture in our organisation. Choosing to implement Open Shift (bare metal) as your container platform is pretty difficult and challenging technically. It is also rather exciting and not too difficult to find smart people willing to help you build and run this new platform. However, it turns out that there is far more to this challenge than just the technology. Therefore, we are adopting an evolutionary implementation approach - stringing together small experiments - towards a flexible, more experimental and proactive culture that will allow us to actually benefit from the technical possibilities our new platform offers. This session is our story of our evolutionary and experimental approach and what we discovered along the way that works in this kind of transformation. Our main "discovery" is that even though at first it seemed mostly a technical transformation, it actually is far more of a human challenge.

We are right in the middle of this transformation so in this talk, I will bring you the latest and most valuable insights and experiences regarding this organisational and cultural transformation that is needed to turn the potential of our container platform into actual value for our organisation. We will summarise our ideas in a practical "this might work" list (bear in mind however there are no best practices, just patterns that might work in your specific situation).

An example of an experiment that turned out useful in our situation is: "create a small separate team that will drive this change". In our organisation we strive to build end-to-end teams, so at first we tried to get this new platform started from within the regular Infra DevOps team (as a huge Epic on the backlog). But people however got swamped in work and annoyed by all the context switching this required. Team members got tired and frustrated with the huge amounts of work, sky high ambitions and lack of progress. So, in the end we did a small experiment by creating a separate, dedicated, core team to get things going. This experiment turned out to be successful (and was thus extended) because it allowed team members to focus on the development of the platform and to build, document and share their experiences along the way, so that this team is also able to incrementally onboard the other teams along the way. Busy OPS-teams and product teams can't just develop the new platform on the side, next to all their other ongoing work. Building a container platform is epic and needs dedicated time and focus, also to keep people in their best energy.

I will share some of our most useful experiments and experiences, all having to do with the human side of this container transformation.

This session is not meant for decision making on going cloud native or not. If you do go cloud native, please bear in mind it is still about people, most of all!

"We're looking for passionate programmers!" says the job ad. Passion is used to evoke single-mindedness, drive and intensity. There is more than one kind of passion, and when raw passion is tempered with compassion and dispassion, we start to see a more balanced way of development.

Good development draws on both creativity and rationality, on both experience and experimentation, on both focus and connection, on both individual skill and group intelligence. Let's explore the many passions of programming.

Target Audience: Developers, Architects, Managers, Coaches, Leaders
Prerequisites: No specific prerequisites
Level: Advanced

Extended Abstract:
"We're looking for passionate programmers!" says the job ad. For a love-in or a development role? Passion is used to evoke single-mindedness, drive and intensity, but it also has many other meanings, surely not all of which can be intended. Love aside, passion also spills over into irrationality, aggression — e.g., crimes of passion — and unconditional and unquestioning pursuit of ideas. Our acceptance of this word and this quality should be partial and conditional. But there is more than one kind of passion, and when raw passion is tempered with compassion and dispassion, we start to see a more balanced way of development.

Good development draws on both creativity and rationality, on both experience and experimentation, on both focus and connection, on both individual skill and group intelligence. The dry language of productivity needs to admit the possibility of enjoyment; the culture of burn-out needs to give way to humanity and empathy. Let's explore the many passions of programming.

IT is always changing ... In this talk I'll do some crystal ball gazing from two perspectives. At heart, I’m a tester. For two years I’ve also been a CEO. I’ll look at what factors are at work and what kinds of effects will they have on how we work and the roles of testers and software professionals.

Alongside musings about the future, I’ll talk about concrete activities on an individual and company level to best prepare ourselves for this nebulous future.

Target Audience: Everyone
Prerequisites: None
Level: Basic

Extended Abstract:
I’m not the first person to notice that the world is constantly changing and that everything is impermanent. Most especially after the last two years, we have really been forced to come to terms with how quickly and drastically things can change. As IT professionals, we are aware of the intrinsic changeability of projects, contexts and our business, but the events of the last couple of years have put this into sharper focus.

But let’s not get too generally philosophical about the whole world. Let’s look at what is in our more immediate context and perhaps even in our sphere of influence. If our future is anything, it’s nebulous (and I don’t just mean the cloud). How will external changes shape our teams and our work, and how can we shape ourselves proactively in order to be able to respond to changes, make changes or our own and even thrive?

In this talk I’d like to do some triangulated crystal ball gazing from two perspectives. At heart, I’m a tester. For two years I’ve also been a CEO. From my passion for testing and my experience of business and people in organisations, I’ll look at what factors are at work now, what known unknowns we have and what kinds of effects will they have on how we work and the roles of testers and software professionals.
Alongside musings about the future, I’ll talk about concrete activities on an individual and company level to best prepare ourselves for this nebulous future.

Discipline, determination, a highly visible area, and a few sticky notes, are all you need to move beyond problems with technical debt.

Target Audience: Developers, Project Leader, Designers, Product Owners, Decision Makers
Prerequisites: Basic Knowledge of Software Development Process
Level: Basic

Extended Abstract:
## Making great software is challenging
It doesn't matter how qualified a team is, it will never be able to produce perfect, flawless, entirely bug-free software.
While teams are discovering how to build the right software in the right way, the environment the team operates in changes.
This results in a constant reorientation of the product, and the corresponding software solution, which will cause gaps between how things work, and how they should work.
Unfortunately, the market won't wait infinitely until teams have addressed these issues in the software, and organizations tend to run out of patience too.
That is why teams often have to move forward with designs and code that are ... let's call them sub-optimal.
These gaps, they are technical debt: a loan against the future, where things will be fixed, at some point ... Hopefully.
According to a global survey performed by Stripe, Inc. amongst software engineers in 2018, researchers found that **engineers estimate to spend 17,3 hours per week on addressing technical debt**.
That same research established that developers work about 41.1 hours per week. With that in mind, addressing technical debt constitutes well over a third of the time a typical engineer spends per week.
**If engineers are spending that much time, how could they better utilize their attention?**
Why do they seem unable to gain control over this metric and push it downwards?
While technical debt sounds nice and predictable: "you just have to pay interest", it really is like a loan with a mobster, and not with a bank.
It will show up unannounced at your doorstep at 3.30 in the morning, demanding that you pay up now!
How can you prevent being surprised by this goon?! And what can you do to leverage the benefits of borrowing against the future?
Because when the conditions are right, taking out a loan and paying it back Tomorrow might just help you ship a better product today.

## Imagine...
- A lightweight process to discover technical debt without a big investment up front
- A data-driven approach to identify the technical debt that needs attention right now
- A system that is easy to introduce, and simple to enforce
- Something that will guide engineers to articulate technical debt in terms of our roadmap
- Which will ultimately improve the flow of work in your organization

## The Wall of Technical Debt™️
A few years ago [Mathias Verraes coined the term "_The Wall of Technical Debt_"][1]. During this presentation Marijn Huizendveld will show you how to institute such a process for managed technical debt. Doing so will provide you with a safety net that allows you to make "naive" design choices every now and again to ship your ideas as fast as possible, without sacrificing sustainable delivery in the long run.
[1]: verraes.net/2020/01/wall-of-technical-debt/

Even in the time of agile software development and devOps, maintenance and evolution of large-scale software systems remain challenging. This is not only caused by technical debt, but is heavily caused by lost knowledge, high complexity of micro-service architectures, difficult requirements management, not available documentation, and the complexity of communication among and coordination of the many stakeholders. In our session we will talk about the challenges we identified in our study and present new approaches to address these challenges.

Target Audience: Architects, Developers, Project Leader, Manager, Decision Makers
Prerequisites: Project Management Experience, Software Maintenance
Level: Expert

How much design is enough design? How much is overdesign? When does — or should — design happen? How big is 'design'?
Anyone who has ever looked at the methodology landscape or has juggled different roles in software development — programmer, architect, coach, therapist, code paramedic, politician — knows that there are many answers to these questions, and they often contradict one another.

In this talk, we will consider different scales and time frames of design in software, bringing some balance to competing perspectives and recommendations

Target Audience: Developers, Architects, Tech Leads, Project Leads
Prerequisites: Interest in software architecture and design
Level: Advanced

Unfortunately, this presentation has to be cancelled at short notice for personal reasons.

Traditional (i.e. hands-off, blessed-few) approaches to architecture rarely (if ever) work. But in the world of microservices, autonomous teams, and continuous delivery, architecture is more important than ever. Is there an alternative?

Target Audience: Architecture Practitioners (Architects, Lead Developers, etc.)
Prerequisites: Experience delivering software architecture
Level: Advanced

Extended Abstract:
I’m an architect, and I think a lot about architecture. Mostly I think about how irrelevant architecture is if it doesn’t get shipped to production. I worry a lot too. I worry about how to help all the teams I’m supposed to be helping, without slowing them down, getting in their way, or making their lives harder rather than easier.

This paper introduces a mindset and an associated set of practices which do away with the traditional idea of “Architects” while bringing the practice of “Architecture” to the fore. I’ll explain how I and colleagues have used this approach at multiple clients to help everyone become an architect, without things reducing to chaos (though there is a healthy dose of anarchy).

Firmen können kaum noch IT-Systeme neu entwickeln, ohne dass existierende Funktionalität mitwandert. Vor die Aufgabe gestellt, ein System von einem Fremdanbieter in eine Public Cloud zu überführen, hat sich gezeigt, dass hilfreiche Wanderführer rar sind.
Diese Session strukturiert Entscheidungswege und Erkenntnisse bei Cloud-basierten Migrationsvorhaben - abgeleitet aus der Migration und Modernisierung von einem Konsumenten-Service mit 6 PB Daten und ca. 2 Mio. Nutzern.

Zielpublikum: Business-Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider
Voraussetzungen: Erfahrung mit IT-Projekten
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Wanderungen versprechen Entspannung, Panorama oder Sehenswürdigkeiten auf dem Weg. Selten steht bei der Planung die erwartete Anstrengung im Vordergrund. Ähnlich ist es mit Cloud-Migrationen: Der positive Beitrag zur geschäftlichen Entwicklung lockt, aber nicht ohne Mühe.

Wir streifen die folgenden Etappen:
1. Tourenplanung: Wie wähle ich den richtigen Migrationsweg, aka. die "Migrationsstrategie"
2. Lohnt sich der Weg: Wie überzeuge ich Entscheider, ein solches Vorhaben zu sponsoren
3. Auf dem Weg bleiben: Wie managt man den Migrationsfortschritt?
4. Bleibende Erinnerungen: Wie begegnet man übergroßen Erwartungen und vermeidet Enttäuschung bei Endkunden und Produktverantwortlichen?

Modernization projects are not a straight line as there’s no one-stop shop. Balance is definitely the right word: we talk here about finding the proper trade-off between quality/costs/timeframe requirements and customized patterns for a successful legacy system modernization. Based on actual use cases, we’ll discuss the available solutions (ERP implementation, code rewriting, middleware, cloud…), and see why combining the relevant tools is key.
Let us take you on a modernization journey and get your IBM mainframe to embrace innovation!

Target Audience: Architects, Developers, Project Leaders, Chief Information Officers
Prerequisites: IBM i (AS400) and IBM z environments, mainframes, software development
Level: Advanced

Extended Abstract:
Trusted by major players in the insurance, banking, industrial and public services, IBM i and IBM z mainframes are undoubtedly powerful and reliable. Yet, the core business applications developed decades ago are no longer suited for today's requirements nor for tomorrow's innovations. Issues are piling up: maintenance, regulations, cybersecurity, mobility, UX/UI, technical debt … all made worse by the lack of skilled and motivated developers able to untangle layers of spaghetti legacy COBOL or RPG codes.

When the Total Cost of Ownership (TCO) is rising, some may consider simply shifting to modern architectures. Remember the massive rush to a famous ERP in the 2000s? Disarray, downtime, sleepless nights dreading data loss … History has taught us that forced march towards efficiency is possible but also that balance to consider the actual business environment and needs could have been a far better solution, both for systems and people.
Successful modernization is about making the most of the existing mainframe (remember, IBM i and IBM z systems are powerful and reliable!), adapting it to the latest IT trends and strategically relocating applications, inside or outside the mainframe.

Let us introduce you to an interesting use case we had a few years ago: this financial institution, specialized in consumer loans, is struggling with the obsolescence of its mainframe core business applications:
•    Accounting
•    Human resources and payroll
•    Customer Relationship Management (CRM)
•    Documentary reporting

Lately, legacy applications had had issues to address new demands from their various users (accountants, HR, sales, management):
•    How to work over 2 accounting exercises?
•    How to add new data and issue monthly statements of account?
•    How to call an external webservice to check customer solvency?
•    How to cope with the stricter compliance checks requested by financial regulations?
•    How to secure remote access for other branches?
•    How to provide a modern, secure and multi-session interface?
•    How to offer mobile access to all kinds of devices?

We’ll discuss a fully customized and easy to implement solution to modernize:
developers’ workstations: Java Integrated Development Environment (IDE)
systems and software: migration, decommissioning, revamping, middleware, runtime, mobile connectivity, web services, cloud
Let’s dive together into this real-world use case and deploy the full array of modernization tools to support this financial institution in her quest for innovation.

There are many discussions, slogans, and myths out there when it comes to sustainability. But what is behind all those slogans? What does “carbon neutral” really mean and how does it compare to “net-zero”? Is my cloud really running on renewable energy? What are the low-hanging fruits when it comes to reducing carbon emissions? And how does “carbon offsetting” really work?

This session explains all those slogans and concepts, sheds some light at common myths, and provides the audience with a solid understanding of the topic.

Target Audience: Architects, Developers, Managers, Project Leaders
Prerequisites: No prerequisites
Level: Basic

The topic of Green Software is very important because software is everywhere and affects the environment indirectly through the usage of hardware. Jochen Joswig explains what Green Software means and more detailed how energy demand can rise through software usage. There are different degrees of software effects on the environment that can be considered and evaluated. Jochen Joswig is furthermore researching green software metrics, approaches, quality criteria and how they can be applied in the daily business of software development.

Target Audience: Software Engineers, IT-Architects, IT-Consultants, Manager, ESG-Consultants, Sustainability Manager
Prerequisites: None
Level: Basic

Extended Abstract:
Information and communication technology (ICT) is both a curse and a blessing when looking for solutions to environmental problems like the climate crisis. On the one hand, things like video calls and instant messaging reduce the need for travel and thereby reduce greenhouse gas emissions. On the other hand, the total energy consumption and natural resource demand of ICT is growing. Therefore, in his opinion it is the responsibility of everyone involved in software development to use these resources as sparingly and efficiently as possible. Ideally during all parts of a software’s lifecycle.

There has been extensive research in recent years about Green Software. In this talk, Jochen Joswig will introduce some of the key ideas and methods from his research and make the matter of Green Software more accessible. Furthermore, he will introduce some areas in which in his opinion research is still lacking and provide a personal view on how this could be changed.

This talk explains how Scenario Casting enables agile teams to pull together despite diverse ideas and concerns - in three iterative collaborative steps:
1. Find example scenarios of how ideas and concerns affect the domain - strictly in domain language! This provides an initial Scenario Backlog outlining the problem space.
2. Prioritize the Scenario Backlog and agree on scope.
3. Combine the top scenarios into coherent overarching Orientation Scenarios.

Let the agile teams focus on their parts of the Orientation Scenarios over the next iteration(s).

Target Audience: Stakeholders, Non-IT Domain Experts, BAs, Developers, Architects, QMs, Agilists
Prerequisites: Project experience, basic knowledge of DDD, basic knowledge of agile methods
Level: Advanced

Extended Abstract:
Scenario Casting is a collaborative planning and requirements engineering method that has emerged over the past four years in various Domain-Driven Design projects. It is used intensively with dozens of teams most of them involved in ambitious transformation projects.
Scenario Casting is especially helpful for getting a handle on complex or even overwhelming domains. If your domain feels like this and there are a lot of people involved too, you should give Scenario Casting a try.
Scenario Casting lays the groundwork for focused collaborative modeling sessions using domain storytelling or event storming. It ensures that all relevant points are addressed step by step. Also, it helps to quickly identify your domain's subdomains and determine the people who should be involved.

More relevant scenarios are discovered during collaborative modeling. They all go into the Scenario Backlog and will be considered in future Scenario Castings.
Unlike other concepts that try to scale agile, the Scenario Backlog is strictly limited to DDD's problem space, thus avoiding upfront design and premature planning.
Instead, Scenario Casting sets a common focus in problem space for agile teams by defining Orientation Scenarios. An Orientation Scenario illuminates parts of the problem space very precisely. It defines the actual results that solutions must deliver from a domain perspective - but without prescribing specific solutions. Finding and implementing good solutions remains the responsibility of the individual agile teams!

This talk contains examples from real projects and gives you best practices - so you get a good idea of how to try Scenario Casting yourself!

With GraphQL a modern and flexible way of providing APIs for our data is emerging.
The clients specify which data they need, the provisioning of data becomes more flexible and dynamic. Over-fetching or under-fetching are history.
But does this mean we have to rewrite all APIs to benefit? How can we retrofit a GraphQL API onto our existing API landscape?
We will explore three different approaches.

Target Audience: Architects, Developers
Prerequisites: Basic knowledge in API design and Java
Level: Advanced

Extended Abstract:
In this talk we explore three different alternatives:
- The Developer Way: Writing a GraphQL API layer by hand
- The Cloud-native Way: Using lightweight API gateways such as Gloo or Tyk
- The Serverless Way: Using Cloud Provider native services
We will look at all three approaches conceptually and justify when and why each makes sense. Additionally, we will show in a live demo how GraphQL APIs can be added to an existing REST API.

The cloud has fundamentally changed how we design applications and introduced whole new categories of software-development disasters. With a focus on Java, this talk will introduce some of the new tools, patterns, and best practices for modern distributed application development. It also gives a tour of some of the most painful anti-patterns Holly has seen as a cloud consultant.

Target Audience: Architects, Developers, Strategic Decision Makers
Prerequisites: Basic experience of cloud computing, Knowledge of Java
Level: Advanced

Extended Abstract:
The cloud is just someone else's data center, but it has fundamentally changed how we design software and what we expect from our platforms. Our applications have gotten bigger, more distributed, and more complicated, and there are whole new categories of mistakes we can make. Some things that were a good idea ten years ago turn out to be a terrible idea in the cloud; and what used to be ‘good enough’ for testing really isn’t anymore. Managing microservices architecture demands a lot of us, to ensure observability, operational resiliency, and organisational agility. With a focus on Java, this talk will introduce some of the new tools, patterns, and best practices for modern distributed application development. It also gives a tour of some of the most painful anti-patterns Holly has seen as a cloud consultant.

As Product Leaders, the methods we use are fairly easy to understand but the collaboration with others to get to the desired results sometimes is a hard nut to crack in a complex software engineering world. This talk will provide insights in solution-focused coaching skills being used in the product role and break the common belief that coaching is only relevant for Agile Coaches. It will show how solution-focused coaching skills have been used to solve several challenges on individual, team and organizational level.

Target Audience: Product Leader, Product Owner, Product Executives, Agile Coaches, Scrum Master
Prerequisites: Experience in Product Management / Product Ownership
Level: Advanced

Extended Abstract:
In product management, there are a lot of methods we use (user stories, product backlogs, impact mapping, etc.) and usually they are easy to understand. However, to be truly successful we have to closely work together with people to get to the desired results and in a complex world - this sometimes feel tedious. We have to communicate strategy, manage different expectations, have to lead great user interviews, get devs and all other stakeholders on board, deal with "resistance" and emotional customers and users. Our stakeholders expect a lot from us and sometimes it just feels overwhelming.

Solution-focused coaching skills can help to improve communication towards stakeholders, deal with "resistance" in a helpful way, come to collaborative (and also better) results much faster and much more. The solution-focused mindset and toolbox helped me personally to improve collaboration not only in my Scrum team but also in the Product Leader team and the overall organization. It enabled me to benefit from emotional customers to the advantage of the product. I lead much more efficient meetings now and use the full potential of user interviews to get and understand the core need. And in the end, everything leads closer to the general goal of Product Leaders: maximizing the value for the user.

The goals of this talk are to provide insights in solution-focused coaching skills being used in Product Leader roles and break the common belief that coaching is only relevant for Scrum Masters and Agile Coaches. It will provide small learning nuggets (f. e. linguistic turns, powerful questions for "resistance") and real-life examples how solution-focused coaching skills have been used to solve several challenges on individual, team and organizational level.

Over 95 % of companies in the EU are small businesses with less than 250 employees. Many of them would like to reduce their carbon emissions but very few have the knowledge and time needed to take action.
Reaching a sizable fraction of these companies with actionable information about their carbon footprint has a huge potential for climate impact. But is that possible for an organization with less than 10 employees? While also working at a sustainable pace?

Target Audience: Everybody willing to explore how to build software for our future
Prerequisites: none
Level: Basic

Extended Abstract:

Humanity of today is faced with several very serious challenges: environmental problems such as climate change are changing our conditions for living and producing food, making social problems like poverty and global inequality worse.  A good future for our Planet Earth and the humans it supports is possible, but only if we act for it. The aim of this session is to give more people the confidence and tools to get more people to do exactly that: act for a better future.

We’ll spend most of the session exploring the story of GoClimate, a company founded for the sole purpose of stopping climate change. From the example of GoClimate’s journey we’ll extract a toolbox for making an impact on a global problem with a small team. Hopefully you’ll leave this talk convinced that your actions matter and with concrete ideas on how you can act.

• The race for performance and the variety of specialized workloads drives the industry to build more parallel, more heterogenous (multi accelerator), and distributed computing systems.  
• These systems introduce programming challenges and barriers of entry to developers.
• Software solutions can make technologies like AI accessible, safer and easier to use by wider communities.
• We will present some of the driving forces, world trends, challenges, and emerging solutions such as oneAPI, AI reference Kits, federated learning and more and demonstrate how SW can be made simpler, safer, and more profitable.

How to structure your program right? This has been a central question since the beginning of software development. Layers are a start, but not enough. Hexagonal, Onion, and Clean Architecture have joined the club together with DDD's Tactical Design and Pattern Languages. Great system design is not achieved with one of these alone. Putting all the ingredients together we can build the Architecture Hamburger – the combination that makes high quality software possible.

Target Audience: Architects, Developers
Prerequisites: Experience in mid-size to large projects
Level: Advanced

Green software engineering is an emerging discipline and being a part of the climate change solution is a relatively new part of many software companies' strategy. For some of us, building resource efficient solutions is something we have already done for a long time, but we called it performance work. Where do the two meet and when are they different? This talk introduces the field of green software engineering and explains where it intersects with performance optimizations, giving you the tools to take an active part in the climate solution.

Target Audience: Architects, Developers
Prerequisites: Basic understanding of software and performance metrics like latency and resource utilization
Level: Advanced

Extended Abstract:
Software has a huge carbon footprint and impact our global commitment to keep global warming to no more than 1.5°C – as called for in the Paris Agreement. To reach this goal, emissions need to be reduced by 45 % by 2030 and reach net zero by 2050. The rising interest in getting a better handle on the carbon emissions of software has garnered interest from the research and practitioner communities across industry, government, academia, and civil society.

The objective of this session is to break beyond surface-level discussions and dive deep into understanding the challenges and opportunities related to assessing and mitigating the carbon impacts of software systems, through the lens of high performing software.

Requirements engineering like testing require balance of value and risk. Agile requirements engineering and testing with test-driven requirements engineering (TDRE) balances project risks and cost. Clear advantage: Requirements are understandable, testable, and directly applicable as test case. Lead time and costs in testing are reduced by up to thirty percent.

This presentation at OOP 2023 will practically introduce to agile requirements engineering and test with TDRE. A case study demonstrates an industry use of TDRE.

Target Audience: Project Managers, Architects, Analysts, Requirements Engineers, Product Owners, Software Engineers
Prerequisites: None
Level: Advanced

Extended Abstract:
Requirements engineering like testing require balance. Balance is about balancing value and risk. Requirements must be good enough to mitigate risks but yet not overly specific to contain effort. Same for test, which though never complete needs to address those areas with highest risk.

Requirements engineering and testing belong together. Historically, testers have often only seen the requirements after the system has already been partially implemented. This had two serious disadvantages. On the one hand, insufficient requirements quality came far too late to the table. On the other hand, it was quite a lot of extra work without deriving suitable test cases in the context of requirements definition. A lot of additional work and long correction loops were the result.

Only an agile balance of risk-oriented coverage and testable requirements can improve test effectiveness. Such risk-oriented work also optimizes requirements engineering. Instead of paralysis by analysis in defining numerous requirements, test-driven requirements engineering (TDRE) focusses on specifying what is necessary and of high risk or high value.

TDRE is straight-forward: Test cases are developed in parallel to the requirements. Thus, the feasibility of the requirements is analyzed much faster than in the traditional sequential approach, in which tests are specified relatively late. The test cases are initially described in the same structure as the requirements and as a supplement to the respective requirements. This shifts Test-Driven Development (TDD), which has already proven itself as relevant agile methodology, to the specification level. Regression tests are attributed in order to prepare for later automation. The effort required for testing can be better estimated on this basis, and project and quality risks are thus reduced.
TDRE follows a triple peak model, which is connecting requirements (i.e., needs), design (i.e., solution) and test (i.e., the product).

It intertwines three perspectives:
•    Market perspective: “How can I meet customer satisfaction and needs?”
•    Design perspective: “How can I implement the solution to meet requirements?”
•    Testing perspective: “How can I find a defect and cause the product to fail?”

Here some guidance from our projects, which we will further illustrate in this presentation:
•    Every single functional requirement has at least one acceptance check, which is either fulfilled or not fulfilled and serves as the agile DoD (definition of done).
•    Each individual quality requirement is described with numerical values that can be measured.
•    Business rules are defined so that it can be determined whether they are true or false.
•    Business and data objects are defined with all their attributes, types and states so that they can be set and validated at test time.
•    System interfaces such as GUIs, reports and service interfaces are included in the requirements document so that values can be assigned to them.
•    All use cases have pre- and post-conditions that can be generated and validated.
•    All text is marked so that it can be automatically processed to generate test cases.

Agile requirements engineering and testing with test-driven requirements engineering (TDRE) balances project risks and cost. Clear advantage: Requirements are understandable, testable, and directly applicable as test case. Lead time and costs in testing are reduced by up to thirty percent. This presentation at OOP 2023 will practically introduce to agile requirements engineering and test with TDRE. A case study from medical cybersecurity demonstrates an industry use of TDRE.

Learn key patterns, practices, tools, and techniques which lead to successful cloud adoption. Lynn's work with research teams around genomic-scale data pipelines for human health will be highlighted in this keynote.

One of the fundamental strategies of Agile Modeling is that artifacts, including architecture models, should be just barely good enough (JBGE). Another way of saying this is your models should be sufficient for the task at hand, no more and no less. But sufficiency is contextual in nature, it depends.
In this session we will look at the issue of model sufficiency, exploring the risk factors that motivate us to model more as well as the conditions that enable us to model less.

Target Audience: Software Architects, Software Developers
Prerequisites: Basic knowledge of agile, understanding of software architecture
Level: Advanced

Extended Abstract:
One of the fundamental strategies of Agile Modeling is that artifacts, including architecture models, should be just barely good enough (JBGE). Another way of saying this is your models should be sufficient for the task at hand, no more and no less. But sufficiency is contextual in nature, it depends.

In this session we will look at the issue of model sufficiency, exploring the risk factors that motivate us to model more as well as the conditions that enable us to model less. We model to think things through, to identify potential avenues for moving forward so that we can choose what we believe to be the most likely path for success. But the more effort we spend doing so potentially motivates us to make commitments earlier than we should and to lose time, and value, doing so. Balancing these tensions is how we determine model sufficiency in the context that we face. Proven agile architecture strategies that enable us to invest in less up-front modeling will also be explored. It's never just about modeling.

Agenda:
1. Architecture throughout the agile lifecycle.
2. What is initial architecture modeling?
3. What does it mean to be just barely good enough (JBGE)?
4. What risk factors motivate us to invest in more up-front modeling?
5. What factors enable us to invest in less up-front modeling?
6. What are the development practices that support an agile approach to architecture?

In 2022, is having a dedicated software architect still useful, or are there better ways to fulfil this role? The answer, as usual, is "it depends”.

Target Audience: Software Developers and Architects
Prerequisites: None
Level: Advanced

Extended Abstract:
Traditional approaches to software architecture usually trigger thoughts of ivory tower dictators who are a long way removed from the process of building software, probably because they no longer write code anymore. This unfortunate stereotype of “architecture astronauts” delivering large design documents to the development team before running away to cause havoc elsewhere has unfortunately resulted in a backlash against having a dedicated architect on a software development team, particularly in environments where teams are striving to be autonomous and self-organising.
But, in 2022, is having a dedicated software architect still useful, or are there better ways to fulfil this role? The answer, as usual, is “it depends”.

We all live in an increasingly complex world and decision making for leaders isn't getting any easier. However, a long time ago, it probably was equally challenging for the Roman Emperor - Philosopher King - Marcus Aurelius. When dealing with our current challenges as leaders (e.g. as product owners, scrum masters or in management), we can learn from ancient Stoic ideas that we are in control of our own decisions, but we cannot control outcome. This interactive session will leave you with focus on your own discipline, intent and decision making.

Target Audience: Leaders, Managers, Decision Makers, Product Owners, Scrum Masters, Project-, Programme Managers
Prerequisites: None
Level: Basic

Extended Abstract:
We live in a world of ever-growing complexity - however in his time it probably was just as complex for Philosopher King Marcus Aurelius, Roman emperor from 161 till 180. Stoicism teaches us we cannot control outcome, we have no influence on external factors. We can however control how we make decisions, how much effort we put into things and how we react to circumstances. And we can actively strive to do all of these things a bit better, every day.
Since Stoicism is a practical philosophy for people in real life, this session aims to leave you with some theoretical knowledge on Stoicism, the Stoic notion of what is in your control and what isn't, and mostly with practical suggestions and new habits to start with. Reflection on decision making and journalling is key, so please bring a journal to this session to make the most of the interactive parts of this session.

You've heard about this new feature in C++20, Coroutines, but it's the first time you have encountered this term? Then this talk is what you're looking for. We start from the beginning with just "normal" functions. Next, we introduce Coroutines. Using them, we explore the various customization points C++ offers. Another distinction we make is cooperative and preemptive multitasking, opening the door for another beauty of Coroutines, why we don't need locks.
By the end of this talk, you've learned what coroutines are and where you can use them.

Target Audience: Developers
Prerequisites: C++ knowledge
Level: Basic

Extended Abstract:
You've heard about this new feature in C++20, Coroutines, but it's the first time you have encountered this term? Then this talk is what you're looking for. We start from the beginning with just "normal" functions. Next, we introduce Coroutines.
Using them, we explore the various customization points C++ offers. We look at what the new keywords co_await, co_yield, and co_return are for.
Sadly, we also have to talk about how to write a generator for a coroutine since there is no STL part for that in C++20.
Another distinction we make is between cooperative and preemptive multitasking, opening the door for another beauty of
Coroutines, why we don't need locks.
By the end of this talk, you've learned what coroutines are and where you can use them.

Change happens one person at a time. As a leader, you are responsible for helping to persuade people to accept the change. Many of us have been taught persuasion techniques that focus on giving information … and then more information. How is this working for you? Might there be a better way? This session will give you the opportunity to prepare other methods of persuasion for the changes you want to make.

Target Audience: Anyone who sees problems in their organization and would like to help make change happen
Prerequisites: A desire to learn (and have some fun while you do)
Level: Basic

Extended Abstract:
Change happens one person at a time. As a leader, you are responsible for helping to persuade people to accept the change. Many of us have been taught persuasion techniques that focus on giving information … and then more and more information. How is this working for you? Might there be a better way? This session will give you the opportunity to prepare other methods of persuasion for the changes you want to make. These will include an "elevator pitch" with a wake-up call, an "imagine that" exercise, and some stories to build an emotional connection with the people you are trying to persuade.

Sustainability needs change-ability. This 90-min panel will have on three speakers on change. How to move many people or a company to change the status quo. This question addresses the needs of organizations and likewise the needs of our society.

Target Audience: Change Management People, Everyone
Prerequisites: None
Level: Advanced

Extended Abstract:
We will combine three speakers with 20 min Impulse talks. There will be biological brewed beer in different flavors to accompany the tasteful and inspiring talks. The audience will be able to ask questions and supply suggestions, the speakers will respond to that. Anke and Hannes will serve as referees and sommelier(e)s.
The three talks are:

Gina Häußge: Adventures in Open Source Development - how to change OS
Oftentimes when imagining how Open Source Software is developed, the following sort of picture is painted: teams of dozens of developers coordinating happily, handling constant software maintenance with a smile on their faces and often provided with company funding. This is an ideal picture that sadly and all too often doesn't reflect reality. So, the question remains: what is it like to create, develop, and maintain an Open Source project independently or with a small-sized team and an unsure funding situation?

Michael de Zan: Sect or state religion? Agile rituals from a cultural-historical perspective
As a team, do we enjoy going to the retro as much as young people go to church on Sundays? Do we help shape agile events, or do we delegate them to priestly rite experts? Are we passionate about agile values, or do we live with the agile framework as with a state religion whose rituals we have to serve externally? The lecture takes a look at the agile rituals from a ritual-theoretical and cultural-historical perspective, shows parallels and offers a change of perspective in order to reflect on and further develop one's own rituals.

Anke Nehrenberg: “To boldly go …” - Definitions - Reflections - Observations - Predictions on ‘Culture of Growth’
We will start by exploring the concept of culture and continue with a self-localization: where are we today, what aspects does ‘growth’ bring to the party? Culture and organization not only are interdependent, they affect each other reciprocally. Most of this will sound familiar and may be boring, so let’s take it a bit further and explore the edges of our known universe: I will draw on observations and reflections of organizational culture and what may become important in a (galaxy) future not so far away.

In a microservices architecture, services shall be as loosely coupled as possible. Still, they need to communicate with each other in order to fulfill business requirements. This talk will help you shape an answer for the typical questions (like shall I be synchronous or asynchronous and what's a good protocol to use?). You will better understand not only the architectural implications but also the effect on the productivity of your teams.

Target Audience: Developers, Architects
Prerequisites: Basic programming skills helpful
Level: Advanced

Extended Abstract:
In a microservices architecture, services shall be as loosely coupled as possible. Still, they need to communicate with each other in order to fulfill business requirements. Now there are so many questions about this communication:

•    What are the general possibilities to communicate? For example, synchronous, asynchronous, or event-driven communication. What are the tradeoffs and which communication style should you prefer?
•    What is the influence on the coupling of your services? For example, asynchronous communication reduces temporal coupling between services.
•    What do I have to consider when selecting a certain communication style?

For example, you need to apply certain resilience patterns if you want to use synchronous communication.
This talk will help you answer these questions for your project. You will better understand not only the architectural implications but also the effect on the productivity of your teams.

This interactive workshop presents a practical approach for scaling agile. The approach is based on five shifts needed in typical organisations to get agile to work well at scale. It guides how to find the right balance for each shift, using the current context of the organisation. In this way it not only presents the end state, but also the possible steps to implement each shift.

In this practical workshop participants will learn to assess their own organisation against the five shifts.

Target Audience: Leaders, Agile Coaches, Product Owners, Scrum Masters, Managers
Prerequisites: Experience with Scrum and Agile at team level
Level: Advanced

Extended Abstract:
Our approach is based around five shifts in leadership, organisational structure, processes, trust and transparency, and the learning organisation.
Participants will learn how to assess their own organisation against the five shifts. The result is a heat map which enables the next iteration in the organisation’s development to be visualised.
The participants will learn how leadership at all levels (including at team level), are involved in creating an organisation where people thrive and better business results can be achieved.

As developers, our job is to deliver working software. With the shift to CI/CD and the move to the cloud, the need to have the right feedback at the right time only increases. There are many ways that testing can help us with that. Not only can testing help us verify our solution and prevent us from breaking things, it can also help us design our software, find flaws in our architecture and come up with better solutions. In this talk I will highlight some of the many ways that testing can help you to develop better software faster.

Target Audience: Developers
Prerequisites: Basic knowledge in Java
Level: Advanced

Extended Abstract:
Testing doesn't always get the attention it deserves in software development. Many developers claim to be bad at it, or are just not that interested. (These may or may not be related.)

As developers, our job is to deliver working software. With the shift to CI/CD and the move to the cloud, the need to have the right feedback at the right time only increases. There are many ways that testing can help us with that. Not only can testing help us verify our solution and prevent us from breaking things, it can also help us design our software, find flaws in our architecture and come up with better solutions.

In this talk I will highlight some of the many ways that testing can help you to develop better software faster.

In this session I’ll examine some of the things that can go wrong when organisations jump headfirst into micro-service architectures without understanding the potential pitfalls.

I'll explain contract testing from the ground up. You'll learn how it can decouple micro-service dependencies during development, allowing your teams to work effectively. And I'll describe sophisticated, free, open-source tooling that helps integrate contract testing into your software lifecycle, giving you the confidence to release micro-services independently.

Target Audience: Architects, Developers, Decision Makers, Release Managers, DevOps
Prerequisites: English, basic software design/architecture, software lifecycle
Level: Advanced

Unfortunately, this presentation has to be cancelled at short notice for personal reasons.

This talk covers the fundamentals of diversity, equity, and inclusion (DEI), including key definitions and statistics. Moreover, the link between DEI, sustainability, and innovation will be made, including reflections on the importance but also complexity of finding a balance.

As part of this talk, I will link theory and research to my work as the Global Head of Diversity, Equity, and Inclusion in a fintech company, including giving practical examples of how we are embedding DEI into our organization.

Target Audience: People Leaders, Managers, Decision Makers, C-suite
Prerequisites: Open-mindedness, interest in DEI
Level: Basic

Extended Abstract:
What does diversity, equity, and inclusion have to do with sustainability and this year’s conference focus on “finding the right balance?” Everything.

In this talk, I will cover the basics of D, E, and I including definitions and statistics, including introducing various “diversity dimensions” and the concept of “intersectionality.” Then, I will link the DEI agenda to the people sustainability agenda, including showing how the world is already diverse and if your organization is not: how you are likely missing out on learning, development, innovation, user experience knowledge, and even market share.

In doing so, I will link theory and statistics to my work as Global Head of Diversity, Equity, and Inclusion in a fintech company, including giving practical examples on how we are embedding DEI into processes and policies. Finally, I will give reflections on how DEI is a journey that also must be balanced and prioritized, just as any other business priority, before opening up to audience questions.

You know the story, one dev in the team found out about this amazing new framework which will solve potentially aaaall your problems; but the product owner stops him right away. There is definitely no time until the next roadmap milestone is reached and you’re already late. We have introduced the tool Tech Radar – in two different organisational setups – to make technology strategy explicit.

In this talk I’ll share our learnings on how we made sure our teams don’t drown in legacy, train them on time for new tech and foster exchange across teams.

Target Audience: Architects, Developers, Team Lead
Prerequisites: Everyone interested in technology strategy
Level: Basic

Java applications are widely used and often several years old. You can use these applications in the cloud via lift-and-shift (helps nothing) or you can rewrite the application in cloud-native style and use the advantages of the cloud.

An alternative for existing applications is missing here. It must be possible to go to the cloud and use advantages such as serverless and scale-to-zero WITHOUT having to rewrite the entire application.
I will show what is already working well today and where the rough edges are.

Target Audience: Architects, Developers
Prerequisites: None
Level: Basic

Additional information:
In the session, we'll move an existing application to the cloud and save over 70 % of operating and maintenance costs with serverless and scale-to-zero.

Since the dawn of software development, programmers have been perpetually occupied with migrating our "legacy" code to "the new platform". As soon as we finish, it is obsolete, and we need to start over. Today we are typically in the midst of moving to the cloud. We need DevOps, microservices, new frontend frameworks ... there is always some new tool that promises to deliver much better value than our existing solutions. Millions - even billions - are spent on these initiatives. Are they worth it? For whom?
In this presentation we will go through various strategies and their tradeoffs. How can we work with our code bases, staff and users to maximise the actual value delivered? The answer will depend on many things. Be conscious of what exactly you are aiming to achieve.

Artificial Intelligence (AI) and its sub-domain, Machine Learning (ML), have been developing quickly. Your organization could be planning for or be in the middle of an AI transformation.

In this talk, I will speak from my own experience managing the strategy and delivery for AI/ML programs and discuss practical steps for the executive leadership to ensure the success of their AI strategy and delivery.

Target Audience: Project Leaders, IT Leaders, Executives, Decision Makers
Prerequisites: None
Level: Basic

You have emotions? Congrats, you are a (professional) human being! Now, how can you actually handle your emotions smartly in our still tech- & tool-focused IT world?

In professional situations like:
- dealing with human "legacy experiences"
- integrating "personal silos"
- interacting with ease with other human beings
- tackling stressful situations (e.g. conflicts) within a team

This session offers a set of science-based, pragmatic tools that are (almost) always accessible - like a Swiss Pocket Knife for engineers (and other humans :-)).

Target Audience: Developers, Architects, System Engineers, Managers of all kind, Human Beings :)
Prerequisites: Curiosity and openness for new ways of thinking (and behaviour)
Level: Basic

Extended Abstract:
Oftentimes people think that having emotions or even “being emotional” means being unprofessional, being irrational or even being weak. That is wrong!

Being able to consciously deal with (your) emotions is a (professional) strength that can be learned and practised.

•    It contributes to better teamwork.
•    It promotes individual health.
•    It even is a leadership quality.

Join this session to bridge potential gaps between "tech" and "humans", between "hard" and "soft", between "us" and "them". Join and start right now with finding the 'right' balance...

Sustainability has become a huge topic. And software is eating the world. As a consequence, we are responsible for the growing ecological impact of the solutions we create.

In this session, we will discuss several sustainability patterns, ranging from the infrastructure level over design and development to requirements and processes that support us in reducing our carbon footprint - including trade-offs and tips for implementation.

After this session you will have a little toolbox for creating greener IT systems.

Target Audience: Architect, Lead Developer, Project Lead, Manager, Decision Maker
Prerequisites: Desire to create ecological sustainable IT solutions
Level: Advanced

Extended Abstract:
Sustainability - especially reducing our carbon footprint - has become a huge topic in many areas of our lives. And as software is eating the world, we are responsible for the growing ecological impact of the solutions we create.

In this session, we will look at more and less intuitive IT sustainability patterns at various levels that can help us to reduce our carbon footprint, including trade-offs and practical tips for implementation.

After this session you will have a better understanding how you can create greener IT systems and what it means in practice.

As tiny robots become individually more sophisticated, and larger robots easier to mass produce, a breakdown of conventional disciplinary silos is enabling swarm engineering to be adopted across scales and applications, from nanomedicine to treat cancer, to cm-sized robots for large-scale environmental monitoring or intralogistics. This convergence of capabilities is facilitating the transfer of lessons learned from one scale to the other. Larger robots that work in the 1000s may operate in a way similar to reaction-diffusion systems at the nanoscale, while sophisticated microrobots may have individual capabilities that allow them to achieve swarm behaviour reminiscent of larger robots with memory, computation, and communication. Although the physics of these systems are fundamentally different, much of their emergent swarm behaviours can be abstracted to their ability to move and react to their local environment. This presents an opportunity to build a unified framework for the engineering of swarms across scales that makes use of machine learning to automatically discover suitable agent designs and behaviours, digital twins to seamlessly move between the digital and physical world, and user studies to explore how to make swarms safe and trustworthy. Such a framework would push the envelope of swarm capabilities, towards making swarms for people.

Software Development based on a distributed architecture provides both several advantages and new challenges. In order to take advantage of the distribution it requires implementation of service discovery, routing, load-balancing, resilience mechanisms and more. These requirements can be covered by language frameworks or the underlying platform.

This talk will walk through a comparison of various approaches with focus on frameworks, Kubernetes and extending options like Service Meshes and eBPF. The talk will be lecture style with demo.

Target Audience: Developers, Architects, DevOps
Prerequisites: Introductory style, basic IT and dev skills probably helpful, but not required
Level: Basic

Extended Abstract:
Software Development based on a cloud-native (or distributed) architecture provides both several advantages and new challenges. In order to take advantage of the distribution it requires implementation of service discovery, routing, load-balancing, resilience mechanisms and more. Initially software frameworks provided dedicated implementations for API Gateways, Service Registries, Circuit Breakers and many more. These functionalities are declared as code dependencies and need to be set at build time.

With Kubernetes there are alternative options to address these requirements. Kubernetes provides concepts for service discovery, load-balancing and resilience. So-called service meshes extend this functionality with more granular network interaction. They are not part of the application code and can hence be added during runtime. A fairly new approach is emerging with the eBPF technology, which claims to enable service meshes with minimal overhead.

With this talk Matthias wants to explain "the why" of cloud-native application design and how various cloud-native technologies facilitate this. It shows the possibilities and limitations of technologies and which forms of integration can make sense. The talk mostly consists of graphical visualisations/explanations and contains a live demo.

What should you do if you are promoted or hired to be the first Head of Architecture in a big, international organisation? What should you do to shape the role to deliver value to the organisation and its customers? How do you work with many development teams to shape the current legacy spaghetti mess into a coherent system, without becoming a bottleneck?

In this talk I'll respond to all questions and more, by sharing my experience in becoming the first Head of Architecture in a big international organisation.

Target Audience: Architects, Developers, Senior Managers
Prerequisites: Knowledge of software architecture
Level: Expert

Extended Abstract:
In this talk I'll share my experience in becoming the first Head of Architecture in a big international organisation, and on how I shaped the role to deliver value both to the organisation and its customers. Among other things, I'll share what I did to:

- Work productively with the development teams and be relevant.
- Navigate the political landscape to influence decisions.
- Create an architectural decision process tailored to the needs of the organisation.
- Provide guidelines and constraints to decentralise decision making while avoiding chaos.

The attendees will get a better understanding of what the role encompasses, and future heads of architecture may get a better view of what expects them in this role.

When you want to make a change, the skeptics are lying in wait throughout the process. You must continually recognize them if you want the change to be sustainable. Who are they and why are they resisting?

We want to be understanding but oh, they can be annoying. We are told to increase communication, but before shouting more information, we must understand why they are irritating us.

This presentation will provide some practical tips for identifying and dealing with resistance in your organization and perhaps in your personal life too.

Target Audience: Everyone who sees a need for change but also sees resistance
Prerequisites: None
Level: Advanced

Extended Abstract:
When you want to make a change, whether it be agile, AI, cloud, microservices, or anything (!), the resistors are lurking everywhere throughout the process. You must continually recognize them if you want to create a sustainable change. Who are they and why are they resisting? We want to be understanding but oh, they can be annoying. We are told to increase the communication, but first we must understand why they are irritating us before we are tempted to shout more information at them.

This fits into the conference theme of Finding the Right Balance because leaders must continually handle skepticism surrounding the change while, at the same time, moving the process forward at a rate that attempts to work for everyone. As the Signature Track describes, this presentation will, “illuminate the area of tension in which decisions can be made, but also to show practical tips and empirical values so that teams can make the appropriate decisions.”

In a fun and enlightening way, it will point out why resistors annoy us and offer some practical tips that attendees can use on Monday morning for identifying and dealing with this resistance in their organizations and perhaps in their personal lives too.

Climate action and green software engineering has risen to the top of many technology companies' agenda. With accuracy hungry algorithms ML software is consuming more and more computational resources, largely benefiting from the increasingly better hardware. Are the results worth the environmental cost?

This talk introduces the field of green software engineering, showing options to estimate the carbon footprint and discuss ideas on how to make Machine Learning greener, giving you the tools to take an active part in the climate solution.

Target Audience: Architects, Developers, Data Scientists
Prerequisites: Basic understanding of the AI lifecycle
Level: Advanced

Extended Abstract:
AI systems have a huge carbon footprint and impact our global commitment to keep global warming to no more than 1.5°C – as called for in the Paris Agreement. To reach this goal, emissions need to be reduced by 45 % by 2030 and reach net zero by 2050. The rising interest in getting a better handle on the carbon emissions due to the AI lifecycle has garnered interest from the research and practitioner communities across industry, government, academia, and civil society.

The objective of this learning series is to break beyond surface-level discussions and dive deep into understanding the challenges and opportunities related to assessing and mitigating the carbon impacts of AI systems.

This session will also walk through the Green Software foundation's Software Carbon Intensity specification and explain why how you measure impact matters.

When building systems, it can be too easy to focus on features and overlook software qualities related to architecture. If not enough attention is given to qualities related to the architecture, technical debt and design problems can creep in until it becomes muddy with the effect of teams being less agile. Sustainable architecture requires ongoing attention, especially when there are evolving priorities, technical risks, and many dependencies. This talk presents practices for creating and evolving an architecture while remaining agile.

Target Audience: Architects, Managers, Coaches, Developers, POs, QA
Prerequisites: Understanding of Agile and Architecture is useful
Level: Advanced

Extended Abstract:
Being Agile, with its attention to extensive testing, frequent integration, and focusing on important product features, has proven invaluable to many software teams. When building complex systems, it can be all too easy to primarily focus on features and overlook software qualities, specifically those related to the architecture. Some believe that by simply following Agile practices — starting as fast as possible, keeping code clean, and having lots of tests — a good architecture will magically emerge. While an architecture will emerge, if there is not enough attention paid to it and the code, technical debt and design problems will creep in until it becomes muddy, making it hard to deliver new features quickly and reliably.
It is essential to have a sustainable architecture that can evolve through the project lifecycle. Sustainable architecture requires ongoing attention, especially when there are evolving priorities, a lot of technical risks, and many dependencies. This talk presents a set of patterns that focus on practices for creating and evolving a software architecture while being Agile. These practices include a set of tools that allow teams to define “enough” architecture at the beginning of the project and to manage the state and the evolution of the architecture as the project evolves.

Language defines the boundary to our world: it sets what we can describe and what we can’t. This talk describes how to formalize a ubiquitous language into a domain-specific language. The resulting language is used for communication and collaboration as well as used as a basis for generating code, tests, configs, etc. The talk is based on industry cases from various domains, such as banking and insurance, industry automation and automotive.

Target Audience: Developers, Subject Matter/Domain Experts, Managers
Prerequisites: Experiences on applying some modeling language
Level: Advanced

Extended Abstract:
Language defines the boundary to our world: it sets what we can describe and also what we can’t. This talk describes how to formalize a ubiquitous language into a domain-specific language. The resulting language is then used for communication and collaboration, and also as a basis for generating code, tests, configuration, etc. The talk is based on industry cases from various domains, such as banking, insurance, industrial automation and automotive. A particular emphasis in industry cases is how experts from different fields can apply the same language. We will describe language definition cases from practice and illustrate how the created languages have become the cornerstone of development activities.

Sustainability is an emerging concern in software. However, advances in software technology over the past years appear to be in conflict with this goal. Data centers promise virtually unlimited compute power and consume a lot of energy. DevOps and modern programming demand high resource utilization. Are we on a wrong path? Must we return to highly optimized assembler code? Or can we achieve sustainability by consciously balancing the advantages of modern software engineering with the proven practices of writing efficient software. Let’s explore.

Moderator: Frank Buschmann
Panelists: Sara Bergman, Jutta Eckstein, Pia Fåk Sunnanbo, Martin Lippert, Marcus Trapp

Target Audience: Everyone interested in sustainability in software engineering
Prerequisites: None
Level: Advanced