Konferenzprogramm

 

 

 

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

Zur PDF-Broschüre

 

 

Nach Tracks filtern
Nach Themen filtern
Alle ausklappen
  • Montag
    06.02.
  • Dienstag
    07.02.
  • Mittwoch
    08.02.
  • Donnerstag
    09.02.
, (Montag, 06.Februar 2023)
10:00 - 17:00
Mo 2
Domain-Driven Design Bootcamp
Domain-Driven Design Bootcamp

In den Zeiten von Microservices wird klar, wie wichtig Domain-Driven Design (DDD) nach wie vor ist. Denn nur mit Strategischem Design und dem Aufteilen der Domäne in Bounded Contexts kann ein sinnvoller (nämlich fachlicher) Schnitt für die Microservices gefunden werden.

Aber auch Taktisches Design mit der Ubiquitous Language und den Building Blocks haben nichts an Aktualität verloren.
In diesem Workshop nehmen wir uns einen Tag Zeit, um DDD näher anzuschauen. Der Workshop besteht aus abwechselnd Vortrag, Diskussion und Übungen.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheidungsträger, Domain Experts
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
In den Zeiten von Microservices wird klar, wie wichtig Domain-Driven Design (DDD) nach wie vor ist. Denn nur mit Strategischem Design (also DDD im Großen) und dem Aufteilen der Domäne in Bounded Contexts kann ein sinnvoller (nämlich fachlicher) Schnitt für die Microservices gefunden werden.

Aber auch Taktisches Design (also DDD im Kleinen) mit der Ubiquitous Language und den "Building Blocks" Entities, Value Objects, Aggregates, Services und Co. haben nichts an Aktualität verloren.
In diesem Workshop nehmen wir uns einen Tag Zeit, um DDD näher anzuschauen. Der Workshop besteht aus abwechselnd Vortrag, Diskussion und Übungen.

Der Aufbau wird so sein, dass wir zunächst einen Überblick über DDD geben und dann die einzelnen Themen detailliert betrachten. Dabei nähern wir uns DDD gewissermaßen von außen nach innen. Inhaltlicher Aufbau:

  1. Einführung und Überblick
  2. Domäne kennenlernen
  3. Domäne aufteilen
  4. Sprache lernen und bauen
  5. Domäne modellieren
  6. Modell implementieren

Henning Schwentner loves programming in high quality. He lives this passion as coder, coach, and consultant at WPS – Workplace Solutions in Hamburg, Germany. There he helps teams to structure their monoliths or to build new systems from the beginning with a sustainable architecture. Microservices or self-contained systems are often the result. Henning is author of “Domain Storytelling – A Collaborative Modeling Method” and the www.LeasingNinja.io as well as translator of “Domain-Driven Design kompakt”.

Henning Schwentner
Henning Schwentner
Vortrag: Mo 2
flag VORTRAG MERKEN

Vortrag Teilen

10:00 - 17:00
Mo 3
Führung neu gedacht: Neue Autorität und Host Leadership für mehr Balance in der (Selbst)Führung
Führung neu gedacht: Neue Autorität und Host Leadership für mehr Balance in der (Selbst)Führung

Viele reden von moderner Führung. Doch was genau heißt das? Du sollst auf vertraute Führungswerkzeuge verzichten, doch niemand sagt dir, was du stattdessen tun kannst. Wir möchten dir die beiden Ansätze „Die Neue Autorität in der Führung“ und „Host Leadership“ näherbringen, mit denen du deinen Führungsalltag anreichern kannst, um so eine neue Führungsbalance für dich und deine Mitarbeitenden zu kreieren.

Im Workshop wirst du direkt an einer eigenen Führungschallenge arbeiten, und so mit hoffentlich neuen Ideen und Lösungsansätzen hinausgehen.

Zielpublikum: Manager, C-Level, Projektleiter:innen, Menschen, die Menschen führen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Führen und Folgen gehören aus unserer Sicht zusammen. Wenn dir niemand folgt, dann führst du auch nicht. Und wenn dir Leute folgen, dann führst du – auch ganz ohne Titel. In den letzten Jahrzehnten haben sich die Führungsaufgaben teilweise stark geändert. Klassische Autorität und heldenhaftes „Nur ich kann das machen“ passen nicht mehr in eine sich ständige wandelnde Welt, in der die Mitarbeitenden oft über mehr fachliche Expertise verfügen als die Führungspersonen selbst. Führung bekommt neue Bedeutungen. Statt Ansagen zu treffen, geht es darum, Verantwortung zu fördern. Statt Entscheidungen selbst zu treffen, sollen die Mitarbeitenden befähigt werden, diese selbst zu fällen. Und noch einiges mehr ist zu beachten.

Das Konzept der Neuen Autorität wurde ursprünglich für den pädagogischen Kontext entwickelt. Daraus hat Frank Baumann-Habersack die Sieben Säulen der Neuen Autorität in der Führung abgeleitet und wir haben seine Arbeit verwendet und sie mit dem uns so vertrauten Lösungsfokussierten Ansatz für Coaching und Beratung kombiniert. Dieses Konzept erarbeiten wir gemeinsam und du wendest es auch gleich auf deine eigene aktuelle Führungschallenge an.

Vermutlich hast du schon von Servant Leadership gehört. Wir erleben leider, dass dieses Bild häufig ungünstige Verhaltensweisen aufseiten der Führungspersonen, wie auch der Geführten hervorruft. Führen ist stark durch die Beziehung zwischen den agierenden Personen geprägt. Das Thema „Augenhöhe“ kommt im Bild des Servant zu kurz (auch wenn es von Greenleaf durchaus gemeint war). Da uns Bilder allerdings stark leiten, möchten wir ein alternatives Modell anbieten, das für uns in unserer Praxis hilfreicher ist – das Führen als Gastgeberin bzw. Gastgeber („Host Leadership“), von Mark McKergow und Helen Baily. Wir stellen dir diese vielschichtige Metapher vor, sodass du sie für deine Herausforderungen im Führungsalltag nutzbar machen kannst.

Am Ende des Tages wirst du viele Ideen mitnehmen, wie du als Gastgeber:in mit Neuer Autorität deine Mitarbeitenden kooperativer und situativ hilfreicher führen kannst.

Ralph Miarka ist Lösungsfokussierter Agile Coach und Co-Gründer von sinnvollFÜHREN in 2015. Er möchte die Arbeitswelt nachhaltig verändern. Ehem. Leiter des SC PM der PSE, Siemens AG Österreich.

Veronika Jungwirth ist Lösungsfokussierte Coach und Co-Gründerin von sinnvollFÜHREN. Sie unterstützt das Miteinander in Führungsteams und Führung auf Augenhöhe. Ehem. Führungsperson bei der UNIQA Vers. AG.

Ralph Miarka, Veronika Jungwirth
Ralph Miarka, Veronika Jungwirth
flag VORTRAG MERKEN

Vortrag Teilen

10:00 - 17:00
Mo 4
Software Architecture 101 with Spring Boot
Software Architecture 101 with Spring Boot

This highly interactive workshop is all about software architecture - with Spring Boot, the Java microservice framework. Using an example application, we will discuss and try out the following topics in code:

  • REST API design
  • Hexagonal architecture
  • Bean validation
  • Single sign-on with Keycloak
  • Role-based security
  • Optimistic locking with ETags
  • OWASP dependency check
  • Structured JSON Logging
  • Error handling
  • Integration tests with Cucumber
  • Architecture tests with ArchUnit
  • Local deployment with Docker
  • Reverse proxy with NGINX

Please install the following software before the workshop (if not already available):

  • Java 17+
  • Gradle 7.3+
  • Docker 19+
  • git
  • an IDE of your choice (like IntelliJ IDEA)

On Windows, we also highly recommend you install the Windows Subsystem for Linux 2+.

Target Audience: Software Architects, Software Engineers, Java Developers
Prerequisites: Basic knowledge in Java, Interest in software architecture
Level: Advanced

Extended Abstract:
Prerequisites:
This workshop is highly interactive. You will benefit greatly from trying it out for yourself as well.
Please install the following software before the workshop (if not already available):

  • Java 17+
  • Gradle 7.3+
  • Docker 19+
  • git
  • an IDE of your choice (like IntelliJ IDEA)

On Windows, we also highly recommend you install the Windows Subsystem for Linux 2+.

The example application "Chameleon" that will be used in this workshop has been designed as an educational example project for learning the basics of the Spring Boot ecosystem. But project "Chameleon" tries to be more than just a simple "hello world". It has all the needed parts in place to be as close to a "real world" production-ready software as possible.

Project "Chameleon" currently contains the following features:

General

  • Backend with Spring Boot
  • Yaml configuration file
  • Hexagonal architecture
  • Build with Gradle
  • Local deployment with Docker
  • Reverse proxy with NGINX

REST API

  • Definition of RestController with GET, POST, DELETE and PATCH
  • Description of REST API with OpenAPI
  • Swagger UI
  • Dtos
  • Model mapper
  • Bean validation
  • Global error handler
  • Local error handler
  • Request ids
  • Optimistic locking with ETags

Database

  • Storage in relational database with PostgreSQL
  • JPA, JpaRepository (Spring Data)
  • Database migration with Flyway

Security

  • Integration of SSO (single sign-on) with Keycloak
  • Role-based security (JSR250)
  • OWASP dependency check

Logging

  • JSON logging
  • Structured logging
  • Logging of request ids
  • Logging of user and roles

Testing

  • Unit tests with JUnit 5
  • Assertions with Google Truth
  • Architectural unit tests with ArchUnit
  • Coverage report of unit tests with JaCoCo
  • Integration tests with Cucumber

Dr. Christoph Ehlers is the Head of Software Engineering at ConSol. As a project lead, agile coach and software architect, he ensures the successful completion of IT projects. After studying computer science at the University of Passau, where he also earned his doctorate, Christoph Ehlers found his way to ConSol more than seven years ago. He is particularly interested in software architecture and databases. Caution: His enthusiasm for technology is contagious!

Christoph Ehlers
Christoph Ehlers
flag VORTRAG MERKEN

Vortrag Teilen

10:00 - 17:00
Mo 5
Taktisches Domain-Driven Design mit Java
Taktisches Domain-Driven Design mit Java

Taktisches Design in DDD definiert atomare Designkonzepte für Domänenmodelle. Der Workshop betrachtet verschiedene Ansätze und Werkzeuge, die Entwickler:innen dabei unterstützen, diese in Java zu implementieren: die jMolecules-Bibliothek ermöglicht es, DDD-Konzepte direkt in Code auszudrücken, und bietet Integration in weitverbreitete Technologien. Für Spring Boot-Applikationen bietet das Moduliths-Projekt Unterstützung bei der Umsetzung von Modulen, deren Interaktion, bei der individuellen Testbarkeit und dem Erzeugen von Dokumentation.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: DDD, Java, Softwarearchitektur, Spring (optional)
Schwierigkeitsgrad: Experte

Extended Abstract:
Die Kernbausteine des taktischen Designs in Domain-Driven Design (DDD) definieren atomare Designkonzepte für Domänenmodelle. Sie definieren Semantik, Regeln und leiten Entwickler:innen dabei, fachlichen Code zu strukturieren und so komplexe Geschäftslogik zu implementieren. Die Umsetzung in Java birgt dabei jedoch einige technische Herausforderungen.

In diesem Workshop betrachten wir verschiedene Ansätze und Werkzeuge, die Entwickler:innen dabei unterstützen, reichhaltige Domänenmodelle in Java zu implementieren: Die jMolecules-Bibliothek ermöglicht es, DDD-Konzepte direkt in Code auszudrücken, und bietet darüber hinaus Integration in weitverbreitete Technologien wie Spring, Jackson und Persistenztechnologien. Für Spring Boot-Applikationen unterstützt das Moduliths-Projekt Entwickler:innen bei der Umsetzung von Modulen, der Interaktion dieser über Events, bei der individuellen Testbarkeit und dem Erzeugen von Dokumentation über diese.

Oliver Drotbohm ist Teil des Spring Engineering Teams bei VMware. Seine Arbeitsschwerpunkte liegen im Bereich Softwarearchitektur, Domain-Driven Design, REST, Spring und Persistenztechnologien. Sein neues Buch "Modulithic Applications with Spring" erscheint 2022.

Oliver Drotbohm
Oliver Drotbohm
flag VORTRAG MERKEN

Vortrag Teilen

10:00 - 17:00
Mo 6
Systemische Dynamik zwischen agilen Teams: Konflikte und Entscheidungen
Systemische Dynamik zwischen agilen Teams: Konflikte und Entscheidungen

Koordination von mehreren agilen Teams im skalierten Produktentwicklungsumfeld ist nicht selten eine Herausforderung: Konflikte zwischen Teams treten auf, Entscheidungsfindung dauert lange oder führt zu Unzufriedenheit, Verantwortung wird hin- und hergeschoben. Die Dynamik zwischen diesen Teams unterscheidet sich wesentlich von der innerhalb eines einzelnen Teams. Das führt zu Spannungsfeldern.

In diesem Workshop nehmen wir eine systemische und organisationsdynamische Perspektive ein, um Konflikte besser zu verstehen und adäquat damit umzugehen.

Zielpublikum: Agile Coaches, Organisationsentwickler:innen, Scrum Master, Prozessverantwortliche
Voraussetzungen: Basiskenntnisse von agilen Arbeitsweisen und skalierter Produktentwicklung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Bei der Zusammenarbeit von mehreren Entwicklungsteams in skalierten Scrum-Umfeldern entsteht immer wieder die Frage, wie teamübergreifend Entscheidungen getroffen werden und Verantwortung über Teamgrenzen hinweg verteilt wird. Dabei entstehen strukturelle Konflikte, die in ihrer Dynamik verstanden werden sollten, um konstruktiv genutzt werden zu können.
Gerade bei Fragen zu Softwarearchitektur, Technologiestandards und Umgang mit Bugs braucht es Abstimmung. Will man hier nicht zentralistisch vorgehen – d. h. eine Person entscheidet für alle – braucht es Mechanismen und Strukturen, die selbstorganisierte Zusammenarbeit ermöglichen.

Nun ist die Schwierigkeit, dass es kaum möglich ist, Konsens über viele Teams hinweg herzustellen. Dabei spielt es eine untergeordnete Rolle, ob LeSS, SAFe, Nexus oder andere Ansätze verwendet werden.
Die Teilnehmenden können im Workshop anhand von Übungen, Fallbeispielen und Diskurs lernen, welche strukturellen Konflikte zwischen Teams in skalierten Umfeldern auftreten können (bei denen die beteiligten Akteure austauschbar sind), welche Arten der Entscheidungsfindung in skalierten Umfeldern möglich und welche sinnvoll sind und wie Selbstorganisation mit mehreren Teams praktisch umsetzbar ist.

Joris Wachter ist als Agile Coach bei andrena in München tätig und beschäftigt sich dabei mit Team- und Organisationsentwicklung sowie Gruppen- und Organisationsdynamik in sozialen Systemen. Als Psychologe, Informatiker und Gruppendynamiker (öggo) unternimmt er gerne Perspektivwechsel und analysiert Methoden, Praktiken und Theorien, um sich selbst und andere zum Nachdenken anzuregen.

Joris Wachter
Joris Wachter
flag VORTRAG MERKEN

Vortrag Teilen

10:00 - 17:00
Mo 7
ScaleAgility: Principles Over Frameworks for Sound Agile Organisations
ScaleAgility: Principles Over Frameworks for Sound Agile Organisations

Do you like some of what you find in the common scaling frameworks but don't buy-in to everything? Then, go to the essence!
This session will present and share a set of principles for scaling, which you can use to roll-your-own approach or properly contextualise the usage of an existing framework such as LeSS, Scrum@Scale or Nexus.

Unlike other scaling approaches, these guidelines are non-prescriptive and recognise the value of elements in many scaling frameworks.

Target Audience: Managers, Decision Makers, Agile Coaches
Prerequisites: Basic understanding of agile. Having been exposed to agile at scale projects is a plus
Level: Advanced

Extended Abstract:
ScaleAgility is a set of principles to create sound scaled organisations.
Devised by a group of five trainers and coaches with a total of more than 70 years of experience in large-scale agile implementations, these principles aim to expose the tensions inherent in any organisational development initiative and provide guidance to discuss and develop strategies and tactics for transforming a company.
In this workshop we will discuss:

  1. A set of general principles to consider when creating large-scale agile organisations
  2. How properly defining products and the way the product definition evolves are fundamental for large-scale agility
  3. A path for Teams to evolve from localised responsibility to feature Teams
  4. How the Leadership should accompany the change

Pierluigi Pugliese is active as Agile Coach, Systemic Consultant and Trainer. He has a long experience in various roles in software development organisations and complex international projects.
He started hacking code so long ago that he cannot remember exactly when anymore. After many years various roles in the mobile telecommunication business, he works as a consultant for software organisations and coach for individuals and teams, focusing on software development and software processes, helping them implementing sound and agile solutions.

Blog: http://www.connexxo.com/blog

Simon Roberts is an agile and leadership coach and Certified Scrum Trainer. He has used lightweight/agile methods since the late 1990s and works with organisations large and small to help them achieve better results by leveraging the power of self-organising teams. He has consulted for and led several large-scale agile transitions at DAX companies in Germany, is the author of several articles and speaks regularly at conferences on the subject of agile leadership. Simon holds an MBA specialising in Creativity, Innovation and Change from the Open University Business School.

Since 2005 Colin Bird is assisting organisations in many sectors to wrestle with the challenges of retaining agility as the scale of the challenge moves beyond a single team.

Pierluigi Pugliese, Simon Roberts, Colin Bird, Matt Roadnight, Jan Olsen
Pierluigi Pugliese, Simon Roberts, Colin Bird, Matt Roadnight, Jan Olsen
Vortrag: Mo 7
Themen: Agilität
flag VORTRAG MERKEN

Vortrag Teilen

10:00 - 13:00
Mo 8
Limitiert Balance in Testing
Balance in Testing

Today we must deal with shorter time-to-market, increasing complexity and more agility while keeping quality and other key system properties high.
To address these challenges the right balance in testing w.r.t. independence, timing, automation, and formality is critical but often not explicitly tackled.

Therefore, in this interactive tutorial we reflect on our current approach on balancing testing, investigate and discuss needed strategies, tactics, and practices, and share experiences to improve and sustain our testing approaches!

Max. number of participants: 40

Target Audience: Test Architects, Test Engineers, Product Owners, Quality Managers, Software Architects, Developers
Prerequisites: Basic knowledge about testing and quality engineering
Level: Advanced

Extended Abstract:
Today we must deal with shorter time-to-market, increasing complexity and more agility while keeping quality and other key system properties high. Our test systems increase in size, volume, flexibility, velocity, complexity, and unpredictability. Additionally, digitalization requires more than just a face lift in testing.

To address these challenges the right balance in testing w.r.t. independence, timing, automation, and formality is critical but often not explicitly tackled. Therefore, in this interactive tutorial we reflect on our current approach on balancing testing, investigate and discuss needed strategies, tactics, and practices in different areas, and share experiences and lessons learned to improve and sustain our testing approaches!

The following areas in testing are covered w.r.t. their appropriate balancing:

  • Level of independence – independent vs. fully integrated with development
  • Timing – too early vs. too late
  • Degree of automation – automated vs. manual
  • Formality – formal vs. informal, scripted vs. exploratory
  • Test case design – structured vs. experience-based, black-box vs. white-box

Peter Zimmerer is a Principal Key Expert Engineer at Siemens AG, Technology, in Munich, Germany. For more than 30 years he has been working in the field of software testing and quality engineering. He performs consulting, coaching, and training on test management and test engineering practices in real-world projects and drives research and innovation in this area. As ISTQB® Certified Tester Full Advanced Level he is a member of the German Testing Board (GTB). Peter has authored several journal and conference contributions and is a frequent speaker at international conferences.

Peter Zimmerer
Peter Zimmerer
flag VORTRAG MERKEN

Vortrag Teilen

10:00 - 13:00
Mo 9
Limitiert Spotlight "Lean-Agile Leadership"
Spotlight "Lean-Agile Leadership"

Unsere Welt verändert sich rasant, wird immer weniger vorhersagbar, komplexer und widersprüchlicher. Und damit geht auch ein Wandel der traditionellen Rolle der Führungskraft einher. Bisher funktionierende Führungsmethoden, erfolgreiche Verhaltensweisen und ein bewährter Führungsstil stoßen nun an ihre Grenzen.

Es verändert sich etwas im Gefüge zwischen Führungskräften und Mitarbeitern. Eine Antwort darauf kann lean-agile Leadership sein. Die erfordert ein neues Rollenbild und Selbstverständnis von Führung. Doch was bedeutet das?

Zielpublikum: Führungskräfte, Entscheider, "Geführte", Interessierte an Agile Leadership
Voraussetzungen: Erste Führungserfahrungen von Vorteil, aber nicht Bedingung
Schwierigkeitsgrad: Fortgeschritten

Max. Teilnehmendenzahl: 30

Extended Abstract:
Unsere Welt verändert sich rasant, wird immer weniger vorhersagbar, komplexer und widersprüchlicher. Und mit dieser Veränderung geht auch ein Wandel der traditionellen Rolle der Führungskraft einher. Bisher funktionierende Führungsmethoden, erfolgreiche Verhaltensweisen und ein bewährter Führungsstil stoßen nun an ihre Grenzen.

Es verändert sich etwas im Gefüge zwischen Führungskräften und Mitarbeitern. Organisationen und Menschen verlangen nach einem neuen Führungsverhalten. Eine Antwort darauf kann lean-agile Leadership sein. Die erfordert ein neues Rollenbild und Selbstverständnis von Führung. Doch was bedeutet das?

In diesem Spotlight beleuchten wir,

  • welche Herausforderungen mit lean-agile Leadership bewältigt werden können,
  • welches Mindset und welche Verhaltensweisen der ideale agile Leader mitbringt,
  • und was das konkret für die Zusammenarbeit bedeutet.

Wir haben uns die folgenden Lernziele gesetzt:
In diesem 2 1/2-stündigen Workshop lernen die Teilnehmer:innen die Grundlagen von lean-agile Leadership kennen und verstehen, welche Vorteile dieser Führungsstil bringt.
Du erhältst Inspiration für konkrete Umsetzungsmaßnahmen und wendest Tools in praktischen Übungen an. Wir werden viel miteinander diskutieren und von den Erfahrungen der anderen profitieren können.

Themengebiete

  • Warum muss Führung agil werden?
  • Grundhaltung / Mindset agiler Führungskräfte
  • Verhaltensweisen von agilen Führungskräften
  • Viele praktische Übungen

Voraussetzungen: Offenheit & Lernbereitschaft

Dieser Kurz-Workshop richtet sich an Führungskräfte im agilen Kontext, Führungskräfte, die vor einer agilen Transition stehen, Agile Coaches, SAFe Programm Consultants, Personalentwickler, Scrum Master sowie an alle Interessierte, die mehr über lean-agile Leadership lernen möchten.

Peter Schnell ist Dipl.-Informatiker und seit 1994 in der IT-Branche tätig. Sein beruflicher Werdegang führte ihn von der IT-Projektleitung einer Versicherung über das Beratungs- und Trainingsgeschäft in die Leitung eines IT-Bereiches. Nun ist er Partner der KEGON AG und als agiler Management-Berater und Coach tätig. Seine Schwerpunkte sind das agile Coaching, agile Transitionen, Management 3.0, Management von klassischen und agilen Projekten im Banken- und Versicherungsbereich, Interims- und Personalmanagement. Er hat seine langjährige Erfahrung in eine Vielzahl von Vorträgen und Publikationen eingebracht.

Susanne Bauer ist Management-Beraterin für die KEGON AG. Sie arbeitet als Systemische Business Coachin und Trainerin im agilen Kontext. Ihr Fokus sind die zwischenmenschlichen Aspekte bei agiler Führungsarbeit, Veränderungsprozessen oder agiler Transformation. Dabei greift sie auf ihre langjährige Erfahrung als Führungskraft im Marketing und Trainingssektor, als Ausbildnerin im Coaching und auf fundierte wirtschaftliche, Coaching- und Change-Management-Ausbildungen zurück.

Peter Schnell, Susanne Bauer
Peter Schnell, Susanne Bauer
flag VORTRAG MERKEN

Vortrag Teilen

10:00 - 13:00
Mo 10
Mach mir hier (k)ein Szenario – Szenario-basierte Entwicklung von Software-Architekturen
Mach mir hier (k)ein Szenario – Szenario-basierte Entwicklung von Software-Architekturen

Bekanntlich haben nichtfunktionale Eigenschaften den größten systemischen Einfluss auf Software-Architekturen.

  • Attribute-Driven Design illustriert, wie sich Qualitätsattribute gezielt in Architekturen einfügen lassen.
  • Methoden wie ATAM und CBAM sind nützlich, um Software-Architekturen hinsichtlich nichtfunktionaler Eigenschaften zu überprüfen.

Alle genannten Methoden basieren auf Szenarios.
Das Tutorium führt in die Grundlagen Szenario basierter Architekturerstellung und -bewertung ein.

Zielpublikum: Software-Architekt:innen, Key-Developer
Voraussetzungen: Wissen über Software-Architektur
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Bekanntlich haben nichtfunktionale Eigenschaften den größten systemischen Einfluss auf Software-Architekturen.
Attribute-Driven Design (ADD) illustriert, wie sich Qualitätsattribute gezielt in Architekturen einfügen lassen.
Methoden wie ATAM (Architecture Tradeoff Analysis Method) und CBAM (Cost Benefit Analysis Method) sind nützlich, um Software-Architekturen hinsichtlich nichtfunktionaler Eigenschaften zu überprüfen. Alle genannten Methoden basieren auf Szenarios.

Das Tutorium führt in die Grundlagen Szenario basierter Architekturerstellung und -bewertung ein. Um das konzeptionelle Wissen gut zu verankern, führen die Teilnehmer praktische Übungen durch. Das Tutorium adressiert dabei auch Fallstricke und wie sie sich umgehen lassen sowie die Beteiligung und Verantwortlichkeiten verschiedener Rollen beim Szenario basierten Vorgehen.

Vorgehen:
Mix aus Präsentation und kleinen praktischen Übungen

Lernziele des Tutoriums:
Die Anwendung Szenario basierter Methoden verstehen und praktisch kennenlernen Verstehen, wie sich die Methodik in die Arbeit des Software-Architekten integrieren lässt, Kennenlernen potenzieller Fallstricke und wie sie sich vermeiden lassen

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

Michael Stal
Michael Stal
Vortrag: Mo 10
flag VORTRAG MERKEN

Vortrag Teilen

10:00 - 13:00
Mo 11
Limitiert Agile Games Facilitation – Spiele wirksam machen
Agile Games Facilitation – Spiele wirksam machen

Agile Games sind in aller Munde. Viel wird gespielt.
Dass Spielen kein Selbstzweck ist, hat sich herumgesprochen.
Doch was braucht es, um Spiele wirksam zu machen? Und was bedeutet das überhaupt?

Dieser Workshop zeigt auf, was es braucht, um ein Spiel wirksam zu facilitieren.
Dabei durchlaufen die Teilnehmenden ein 4-Schritte-Modell und erfahren interaktiv, welche Schritte notwendig sind, und wenden diese selbst an.
Am Ende des Workshops haben die Teilnehmenden so die Erfahrung gemacht, was es braucht, um Spielen wirksam einzusetzen.

Max. Teilnehmendenzahl: 40

Zielpublikum: Agile Coaches, Entscheider, Projektleiter:innen, Change-Manager, Transformationleads
Voraussetzungen: Neugierde
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Im Rahmen des Workshops benutzen wir das 4-Schritte-Modell als Denkanleitung, um in Kleingruppen das Modell anhand eines Spieles anzuwenden und die Schritte kennenzulernen.
Da das Modell universell ist, können Teilnehmende es anschließend auf eigene Spiele und im eigenen Kontext anwenden.

Bei Interesse kann ggf. ein Spiele-Canvas oder eine Checkliste zur Spielevorbereitung zusätzlich vorgestellt werden.
Am Ende nehmen Teilnehmende eine persönliche (todo-) Liste mit, wie und an welchen Stellen sie Spiele in ihrem eigenen Kontext einsetzen können.

Ihr Motto „You go first! – Nimm dein Leben in die Hand!", steht für ihr Tun: Rein in den nachhaltigen Erfolg durch Eigenverantwortung und Selbstführung.
Anne Hoffmann unterstützt Menschen und Organisationen dabei, erfolgreich ihre Ziele zu erreichen. Als Expertin für Selbstführung und mit ihrem Motto „You go first!“ erinnert sie daran, dass nachhaltiger Erfolg durch hohe Eigenverantwortung insbesondere dann entsteht, wenn diese Selbstführung vorgelebt wird.
Anne benutzt oft Spiele, um Erkenntnisse weiterzugeben.

Anne Hoffmann
Anne Hoffmann
Vortrag: Mo 11
Themen: Agilität
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 17:00
Mo 12
Limitiert Approval Testing: Get Legacy Code Under Control
Approval Testing: Get Legacy Code Under Control

Approval testing is a technique that helps you to get a difficult codebase under test and begin to control your technical debt. Approval testing works best on larger pieces of code where you want to test for multiple things and interpreting failures is challenging.

In this hands-on session we'll introduce a commonly-used Approval testing tool for Java and through hands-on exercises learn to get control of some example code. The same tool is also available for many other programming languages, see https://approvaltests.com/

Bring a laptop.
Max. number of participants: 30

Target Audience: Developers, Architects
Prerequisites: Basic knowledge of Java and unit testing, bring a laptop
Level: Basic

Extended Abstract:

Introducing Approval Testing (55 minutes)

  • Code Review: examine existing test case, discuss strengths & weaknesses
  • Demonstration: Convert an assertion-based test to use Approval testing
  • Hands-on exercise: Add some tests using Approvals.Java.

Break (5 minutes)

Approval Test Design (50 minutes)

  • Presentation: Approval testing characteristics and design patterns
  • Exercise: Using the default XML printer with Approvals.Java
  • Demonstration: Using scrubbing with an XML printer
  • Discussion: when to print, when to scrub

Printer Design (30 minutes)

  • Exercise: Designing a printer for a domain object
  • Presentation: Case studies
  • Q&A (10 minutes)

Emily Bache is a Technical Coach with ProAgile. She has worked with software development for over 20 years in diverse organizations from start-up to large enterprise. These days Emily specializes in coaching development teams in agile practices like Test-Driven Development, refactoring and agile design. Emily has written two books, authored Pluralsight courses and regularly speaks at software conferences. Originally from the UK, she currently lives in Gothenburg, Sweden.
Twitter: https://twitter.com/emilybache
Linkedin: https://www.linkedin.com/in/emilybache/
Github: https://github.com/emilybache
Website: https://sammancoaching.org/

Emily Bache
Emily Bache
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 17:00
Mo 13
Limitiert Gesprächsformate zur Konfliktlösung
Gesprächsformate zur Konfliktlösung

Nicht nur Teams mit hoher Diversität treffen auf polarisierende Themen und Konflikte, die es scheinbar unmöglich machen, einen Konsens oder gar ein gemeinsames Vorgehen zu finden. Denkmodelle, die auf Argumentation und Objektivität beruhen, scheitern hier oft bereits im Ansatz.

Eine Einführung in die psychologische Forschung erklärt, warum das so ist, und welche Denkmodelle hier weiterhelfen können. Dann sammeln Teilnehmer praktische Erfahrung mit Gesprächsformaten, die helfen, Polarisierung und Konflikte zu behandeln oder zu vermeiden.

Max. Teilnehmendenzahl: 30

Zielpublikum: Team Coaches, Führungskräfte, Entscheider, Projektleiter:innen
Voraussetzungen: Bereitschaft
Schwierigkeitsgrad: Anfänger

Bernhard Bockelbrink erforscht als Coautor von „Soziokratie 3.0” die Verbindung von agilen Methoden mit den Ideen der Soziokratie und veröffentlicht dazu gemeinfreie Materialien auf [sociocracy30.org](http://socoicracy30.org/resoures). Zudem unterstützt er als Agile Coach und Organisationsberater Unternehmen dabei, eine agile und soziokratische Geisteshaltung herauszubilden und dabei ihre eigene Form von bewusster, erfolgreicher und wertschätzender Zusammenarbeit zu entdecken und zu entwickeln.

Susanne Mühlbauer ist selbstständiger Agile Coach und systemischer Business Coach. Mit Leidenschaft und viel persönlichem Engagement arbeitet sie mit Menschen, Teams und Organisationen auf deren Weg zu mehr Agilität.

Bernhard Bockelbrink, Susanne Mühlbauer
Bernhard Bockelbrink, Susanne Mühlbauer
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 17:00
Mo 14
Limitiert Seven Steps to Walking Your Why
Seven Steps to Walking Your Why

Join this tutorial to experiment with a self-reflection process, designed to bring balance into your own development journey.

Rooted in professional coaching practices from Co-Active Coaching, connected with several Liberating Structures, and inspired by ideas from Emotional Agility, this session will help you clarify your goals and aspirations as well as find the right balance for 2023.

Why do you do what you do? What’s important to you about it? What’s next?
Discover answers to these questions in this innovative and impactful tutorial.

Max. number of participants: 50

Target Audience: Architects, Developers, Technical Leaders, Managers, Agile Coaches
Prerequisites: None
Level: Basic

Extended Abstract:
When was the last time you had a chance to reflect on your career path, your goals and learning aspirations for the upcoming year?
This tutorial will be an opportunity to do this reflection in a very meaningful and innovative way. Rooted in professional coaching practices from Co-Active Coaching, connected with several Liberating Structures, inspired by ideas from Emotional Agility and Positive Intelligence, this session will help you clarify your goals and aspirations as well as find the right balance for 2023. Should you continue developing your technical mastery? Should you spend more time growing your leadership skills? What could you take on, if you were brave enough? How to find the time?

You will explore these and many other questions! Working individually and in small groups, we will start by clarifying your own core values. We will then explore what’s on your plate today, and what you are hoping to gain in 2023 with Ecocyce Planning Liberating Structure. We will explore in depth your Ecocycle traps: good ideas that you are not moving forward with as well as skills and practices that are no longer relevant for your self-actualisation.

Next, you will practice to apply your core values as a filter to activities and aspirations on your Ecocycle. You will seek patterns, and take a systemic view with W3 structure, gaining new insights and re-evaluating your Ecocycle. Next, in a silent brainstorming, you will come up with a list of actions you would (and would not) take in 2023, if you were 25 time bolder. Once again, you will apply your core values as a filter to find the most impactful actions on your list. We will wrap up the tutorial with 15% Solutions Liberating Structure, asking you to make a choice of the immediate next steps toward more impact and more balance on your development journey.

This session will take you deep into what really matters for you as a professional and as a human being. Learn from the case studies of applying this framework in individual coaching, team workshops and leadership coaching. Be prepared to be surprised by your own insights and Aha! Moments of other session participants.

Dana Pylayeva is an Agile Leadership coach, passionate about unleashing leadership potential in individuals and teams. International speaker and the author of “DevOps with Lego and Chocolate”, “Fear in the Workplace” and “Safety in the Workplace” agile games, Dana brings a powerful combo of multiple coaching styles (Co-Active, Positive Intelligence, Executive Coaching), facilitation with Liberating Structures, and a deep knowledge of Agile and DevOps.

Dana Pylayeva
Dana Pylayeva
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 17:00
Mo 15
Limitiert Accessibility Workshop to Help Capture Best Practises and Shift Left
Accessibility Workshop to Help Capture Best Practises and Shift Left

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”?

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.
Bring a laptop.

Max. number of participants: 20

Target Audience: Everyone
Prerequisites: None
Level: Basic

Extended Abstract:
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.

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. create a checklist
  2. look at some plugging (wave, lighthouse, arc toolkit, developer tools)
  3. Screen readers (mac/windows inbuilt)
  4. Have a healthy discussion on what they have learnt in the session and how can we bring accessibility sooner in an SDLC?
     

Laveena Ramchandani is an experienced Testing Consultant with a comprehensive understanding of tools available for software testing and analysis. She aims to provide valuable insights that have high technical aptitude and hopes to inspire others in the world through her work. Laveena holds a degree in Business Computing from Queen Mary University of London and regularly speaks at events on data science models and other topics.

Laveena Ramchandani
Laveena Ramchandani
Vortrag: Mo 15
flag VORTRAG MERKEN

Vortrag Teilen

18:30 - 20:00
Nmo 1
Architecture as Knowledge
Architecture as Knowledge

It is common to consider software architecture as structure, as infrastructure, as code, as technologies, as models, and so on, but what if we consider software architecture as knowledge? The idea that software architecture is the set of significant decisions about a system is not a new one, but those decisions represent knowledge.

When we embrace the idea of knowledge as a first class concept, that has implications for our documentation (such as architecture decisions records), for our code and for our development process.

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

Extended Abstract:
It is common to consider software architecture as structure, as infrastructure, as code, as technologies, as models, and so on, but what if we consider software architecture as knowledge? The idea that software architecture is the set of significant decisions about a system is not a new one, but those decisions represent knowledge.

When we embrace the idea of knowledge as a first class concept, that has implications for our documentation (such as architecture decisions records), for our code and for our development process.
This session will explore a number of concepts and practices that relate architecture to existing development practice and agile approaches. It will revisit patterns, explore ADRs, relate architecture to lean thinking, PDSA, hypothesis-driven development, and more.

Kevlin Henney is an independent consultant, speaker, writer and trainer. His development interests are in programming, practice and people. He is co-author of two volumes in the ”Pattern-Oriented Software Architecture” series, and editor and contributor for multiple books in the ”97 Things” series. He lives in Bristol and online.

Kevlin Henney
Kevlin Henney
Vortrag: Nmo 1
flag VORTRAG MERKEN

Vortrag Teilen

18:30 - 20:00
Nmo 2
Auf dem Weg zum API Ecosystem
Auf dem Weg zum API Ecosystem

Die Allianz ist ein weltweit agierender Versicherungskonzern, der auch mit vielen Partnern zusammenarbeitet. Diese Partner sind sowohl im Verkauf – z. B. Versicherungsmakler – oder auch im Schadensfalle – z. B. Autowerkstätten – aktiv.

Um die Geschäfte einfach und verlässlich durchführen zu können, verlangt es eine hohe Automatisierung. Diese Automatisierung verlangt nach einem API Ecosystem, das durch Partner einfach und effizient genutzt werden kann.

Zielpublikum: Architekt:innen, Entwickler:innen, Entscheider
Voraussetzungen: Prinzipielle Architekturkenntnisse, Prinzipielle Kenntnisse in API-Design
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Der Beitrag diskutiert den Weg der Allianz zu eine API Ecosystem und beleuchtet Stolperfallen genauso wie die Erfolge.

  1. Die ersten Ideen
  2. Das erste Proof of Concept
  3. Ein standardisiertes Vorgehen
  4. Wo wir sind und wie es weitergeht

Annegret Junker ist Lead Architect bei Allianz Deutschland. Sie arbeitet seit mehr als 30 Jahren in der Software-Entwicklung in unterschiedlichen Rollen und unterschiedlichen Domänen wie Automotive, Versicherungen und Finanzdienstleistungen. Besonders interessiert sie sich für DDD, Microservices und alles, was damit zusammenhängt. Derzeit arbeitet sie in einem großen Versicherungs-Projekt als übergreifende Architektin.

Annegret Junker
Annegret Junker
flag VORTRAG MERKEN

Vortrag Teilen

18:30 - 20:00
Nmo 3
SUSTAIN_ability – Wandel gestalten aus innerer Kraft und Freude
SUSTAIN_ability – Wandel gestalten aus innerer Kraft und Freude

Unsere Welt wandelt sich, und wir brauchen Wandel. Jedoch nicht zufälligen, sondern bewusst gestalteten Wandel. Gemeinsam statt durch Einzelne.
Aktuell packen wir das nur völlig ungeschickt an. Durch Druck, Zeigefinger auf andere, Schuld und Scham kommen wir gesellschaftlich nicht weiter. Schlimmer noch: All das raubt uns die notwendige Energie für echten Wandel im Alltag.
Wir können Wandel leben und gestalten, aus innerer Kraft heraus, mit Freude und Kreativität. Dazu braucht es Raum, Innehalten und ein Sich-wieder-verbinden.

Zielpublikum: Alle, denen dämmert, dass sie viel mehr können, als sie täglich tun
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Unsere Welt wandelt sich, und wir brauchen Wandel. Jedoch nicht zufälligen, sondern bewusst gestalteten Wandel. Gemeinsam statt durch Einzelne.
Aktuell packen wir das nur völlig ungeschickt an. Durch Druck, Zeigefinger auf andere, Schuld und Scham kommen wir gesellschaftlich nicht weiter. Schlimmer noch: All das raubt uns die notwendige Energie für echten Wandel im Alltag.

Viel unserer menschlichen Energie verfällt auf zwei Bereiche:
Erstens in die Aufregung über Dinge, die geschehen sind oder geschehen werden - und die wir (scheinbar) nicht beeinflussen können. Damit nähren wir nicht nur unser Ohnmachtsgefühl und stärken in unserem neuronalen Netz die Gewohnheitsbahnen für Ärger und Aufregung - was zur Folge hat, dass wir uns über die Jahre hinweg immer besser aufregen können und uns dazu immer kleinere Anlässe reichen.
Sondern, viel schlimmer noch, wir verleugnen unsere Verantwortung und Gestaltungskraft. Dadurch können wir gut weiter in dem Job "funktionieren", den wir zwar nicht mögen, aber der unserer Komfortzone so gut entspricht, dass wir damit genug Geld verdienen. Wir können dann beruhigt unsere Zeit beim Sudoku oder vor der Playstation totschlagen, weil es auf uns ja eh nicht ankommt. Und wir können uns wunderbar in allen Feldern von Ersatzbefriedigung austoben, weil der Großteil unseres Lebens zwar ganz angenehm ist, uns aber nicht glücklich macht, uns nicht erfüllt.

Wenn wir uns nachhaltigen Wandel auf dieser Welt wünschen - und inzwischen sollte klar sein, dass wir genau das brauchen, wenn wir als menschliche Spezies überleben wollen -, dann sollten wir unsere Energie nutzen, um zu diesem Wandel beizutragen.

Und in diesem Beitrag gibt es keinen moralischen Zeigefinger. Ich werde Ihnen nicht sagen, was zu tun und zu lassen ist. Ich werde keinen 5-Punkte-Plan vorstellen und Ihnen keinen nächsten Schritt vorschlagen.

Warum nicht?
1. Weil ich es nicht kann. Ich bin ein Mensch - Sie sind ein anderer. Jede(r) hat eigene Baustellen zu meistern und zugleich auch ureigene Motivationsquellen: Tätigkeiten und Wirkungsfelder, die uns so begeistern, dass sie uns Energie geben, statt uns Energie zu kosten. Diese gilt es, individuell zu finden!
2. Weil ich es nicht möchte. Es wäre anmaßend, denn es würde meine Ziele über Ihre Ziele stellen. Und das ist genau das, was uns den Großteil des Leides unserer aktuellen Welt eingebracht hat - und immer noch einbringt. Wir alle dürfen lernen, mehr unseren eigenen Zielen, statt denen anderer zu folgen. Nicht den Zielen des Egos, sondern den Zielen unseres Herzens.

Wir können Wandel leben und gestalten, aus innerer Kraft heraus, mit Freude und Kreativität. Dazu braucht es Raum, Innehalten und ein Sich-wieder-verbinden.

In dieser Session werde ich Ihnen dazu ein paar Tools zeigen und wir werden diese gemeinsam ausprobieren. Einige, die uns helfen, unseren wirklichen Wünschen ein bisschen besser auf die Schliche zu kommen. Und einige, die dazu dienen, überhaupt in einen Gestaltungsmodus zu kommen. (Denn Studien zufolge befinden wir Menschen uns im Durchschnitt mindestens 50 % im Autopilotmodus und haben 95 % der heutigen Gedanken auch gestern schon gedacht. Wir drehen uns also, gelinde gesagt, unbewusst im Kreis.)
Auch das Miteinander wird hierbei nicht zu kurz kommen.

Melanie Wohnert ist Diplom-Mathematikerin, ehemalige IT-Führungskraft und begeisterte Agilistin.
Achtsamkeit veränderte ihr Leben in kleinen Schritten und in vielerlei Hinsicht. Heute ist sie selbstständige Trainerin, lehrt Agilität, Achtsamkeit und Mitgefühl (MSC) in Unternehmen sowie in Schulen. Sie leitet zudem den Trainer-Zertifizierungslehrgang für "Mindfulness in Organisationen" (MIO) in Süddeutschland.

Melanie Wohnert
Melanie Wohnert
flag VORTRAG MERKEN

Vortrag Teilen

18:30 - 20:00
Nmo 4
Closing the Developer Experience Gap of your Container Platforms
Closing the Developer Experience Gap of your Container Platforms

Due to the lack of user focus, lots of container platforms have a big developer experience GAP.

That's not only because building a Kubernetes platform is complex but also because deploying applications on Kubernetes requires expertise in many Container and Kubernetes concepts.
Developers today shouldn’t have to care how their applications run and focus on adding business value.

In this session, we will explore some of the powerful open source technologies available within the Kubernetes ecosystem to close the developer experience gap.

Target Audience: Developers, DevSecOps
Prerequisites: Basic knowledge in Kubernetes and software development
Level: Advanced

Extended Abstract:
Due to the lack of user focus, lots of container platforms have a big developer experience GAP.

That's not only because building a Kubernetes platform is complex but also because deploying applications on Kubernetes requires expertise in many Container and Kubernetes concepts. And once developers learn them, they still must spend a lot of time maintaining containers, writing YAML templates, and orchestrating many moving Kubernetes parts.

Like in the days when the Waterfall model was the standard for software development, developers today shouldn’t have to care where and how their applications run and focus on adding business value by implementing new features.

In this session, we will explore some of the powerful open source technologies available within the Kubernetes ecosystem to close the developer experience gap.

Timo Salm is based out of Stuttgart in southwest Germany and in the role of the first VMware Tanzu Solutions Engineer for Developer Experience in EMEA with a focus on VMware Tanzu Application Platform and commercial Spring products. In this role, he’s responsible for educating customers on the value, vision, and strategy of these products, and ensuring that they succeed by working closely on different levels of abstractions of modern applications and modern infrastructure.
Before Timo joined Pivotal and VMware, he worked for more than seven years for consulting firms in the automotive industry as a software architect and full-stack developer on projects for customer-facing products.

Timo Salm
Timo Salm
flag VORTRAG MERKEN

Vortrag Teilen

18:30 - 20:00
Nmo 5
Red Pills for the Leadership
Red Pills for the Leadership

The Middle Management, who has the required knowledge for successful Digital Transformations, is not appropriately engaged and won as change agents.

This interactive session walks the audience through seven steps of an implementation path. Each step is heavily interwoven with leadership challenges, skills, and practices. Most often, those are tacit.
The right path helps move from tacit transactional management to explicit transformational leadership, a prerequisite for successful Digital Transformations.

Target Audience: Manager, Decision Makers, Change Agents, Enterprise Transformation Implementers
Prerequisites: Basic knowledge of current digitization topics on management and frameworks
Level: Advanced

Extended Abstract:
Leadership is vital for successful Digital Transformations.
However, the leadership or managers, the "System Masters" of the "Frozen Middle Layer" having the required knowledge, are often not appropriately engaged and won as change agents. They continue to do what they successfully have done in the past —applying "tacit" personal knowledge and "managing," not "leading." Tacit knowledge was first defined by Michael Polanyi in the Tacit Dimension and later on used by Nonaka and Takeuchi in the SECI model.

Blindly applying highly standardized implementation roadmaps and so-called playbooks force leadership into orthodox paradigms and mental management models.
This interactive session walks the audience through seven steps of an implementation path — a good practice based on personal experience and linked to the theoretical foundation from various sources. It is about the early phase when the transformation initiatives are outlined. We stop at critical junctions and typical roadblocks. Each step is the foundation for further progress.

We look at a viable path through the roadmap of implementing Digital Transformation on the Enterprise level with an unleashed leadership team.
The path is not "train the teams and pray for help" but about winning the system masters as change agents right from the start.

After the introduction ( 5 / >0 / 5>), we stop at:

  • Red Pill or Blue Pill - the (pretended) commitment and wrong junction to Agile Theater or Cargo Cult ( 5 / >5 / 10>)
  • VUCA - we, the agile folks, know what we mean, but we altogether do not share a truly common language - the second disconnect ( 5 / >10 / 15>)
  • Perspectives, paradigms, again language, and culture ( 15 / >15 / 30>)
  • Leadership - away from transactional to transformational management for people, processes, managers, leaders, and teams ( 15 / >30 / 45>)
  • Leaders vs. managers as "System Masters" in the "Frozen Middle Layer" and their crucial contribution ( 5 / >45 / 50>)
  • "Knowledge and Know-How," tacit and explicit or what is it and how to unlock this for future success. The SECI model and Mindfulness as tools to tap hidden gems in ourselves and the organization ( 15 / >65 / 80>)
  • Postcard from the Future - how to fill the Backlogs of managers to unleash them as leaders ( 10 / >80 / 90>)

At every stop, there is an overview of what is so special about it

  • What we should avoid
  • What we should try
  • An interactive hybrid exchange and a game (not at every stop and depending on the votes of the audience)
  • deas on how to dig deeper into the rabbit hole - the gimmicks

This session links personal experience and anecdotes with the already available methods, practices, and theories. The "Red Pills for Leadership" session does not claim to introduce a new silver bullet. It is not another snake oil potion. It is a set of good practices that have been around for some decades, and many of us most probably at least partially already know. The audience will get a fully packed travel bag filled with the gimmicks and the takeaways from the interactive discussion at the various stops and junction points.

Depending on the personal experience level, the audience will get an idea for a potential good path or optimize their own path through the exchange with others on this leadership topic.
This is the way ;-)

Kurt Cotoaga started as a research assistant using evolutionary algorithms to solve np-hard problems. Those fascinating problems are still unsolved ...
His first pivot brought him into the product manager role for large online brokerage websites where he fooled himself and others into mixing up causality and correlation. It was a tough ride in the epicenter of the dot-com bubble burst ...
Having been perpetually torn apart between trying to create business value and pretending to be predictable, he pivoted around 2005 towards agility as a survival kit. From projects via programs to portfolios via products - this finally worked!
The last pivot beamed him into the consulting world, where he helps clients thrive in the digital age as a Business Value addicted Digitalization Evangelist or Enterprise Transformation Implementer.

Kurt Cotoaga
Kurt Cotoaga
flag VORTRAG MERKEN

Vortrag Teilen

, (Dienstag, 07.Februar 2023)
09:00 - 10:45
Di 1.1
Software Architect Playbook: Was macht gute Software-Architekten?
Software Architect Playbook: Was macht gute Software-Architekten?

Software-Architektur ist allgegenwärtig. Trotzdem gibt es in vielen Organisationen kaum eine weitgehend anerkannte Definition der Rolle. Somit stellt sich die Frage, wie wir feststellen können, ob wir unseren Job "gut" machen.

In diesem Vortrag werden wir konkrete Wege kennenlernen, wie wir Architekturarbeit effektiv gestalten können. Wir streifen Themen wie Dokumentation, Entscheidungsfindung, Kommunikation und Skillset. Außerdem lernen wir Prinzipien kennen, die uns im Alltag als Software-Architekten eine Stütze sein können.

Zielpublikum: Software-Architekt:innen, Software-Entwickler:innen, Manager, Entscheider
Voraussetzungen: Grundwissen in Software-Entwicklung und -Architektur
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Die Rolle von Software-Architekten ist in vielen Organisationen nicht klar oder gar explizit definiert, geschweige denn gibt es eine Definition der Rolle, die allgemein anerkannt ist und entsprechend gelebt wird. Oft fehlt für diese Rolle im Berufsalltag eine klare Zielsetzung. Somit stellt sich die Frage, wie wir feststellen können, ob wir unseren Job "gut" machen.

Wir könnten nun versuchen, den Rollenbegriff von Software-Architekten bestmöglich zu schärfen. Doch ist das wirklich zielführend? Gerade in der Software-Entwicklung haben wir mit unterschiedlichsten Kontexten zu tun, die sich obendrein ständig ändern. Das macht eine einheitliche Definition der Rolle umso schwieriger.

Ein anderer Ansatz wäre, dass wir von Good Practices und (mehr oder weniger) etablierten Prinzipien ausgehen, um unseren Berufsalltag effektiv zu gestalten. Der Vorteil dieses Ansatzes ist, dass wir kontextspezifisch entscheiden können, welche Prinzipien für uns passen. Somit ergibt sich die Jobbeschreibung von Software-Architekten nicht aus einer allgemein gültigen Definition, sondern immer aus konkreten, kontextabhängigen Richtlinien.

Die Good Practices und Prinzipien versuchen wir im Vortrag aus folgenden Fragen abzuleiten:
-    Sollte man in der Rolle als Software-Architekt coden?
-    Ist breites oder tiefes technisches Wissen wichtiger?
-    Wie viele Vorgaben sollen effektive Architekturentscheidungen machen?
-    Wann ist der beste Zeitpunkt, um Architekturentscheidungen zu treffen?
-    Wie viel Kontrolle soll man in der Rolle als Software-Architekt ausüben?
-    Sollte man Top-Down oder Bottom-Up vorgehen?
-    Wie kann man die Zielerreichung von Software-Architektur unter ständiger Veränderung sicherstellen?
-    Sollte es die Rolle "Software-Architekt" überhaupt geben?

Aufgrund der oben erwähnten kontextspezifischen Unterschiede der Architekturrolle soll dieser Vortrag Raum für Interaktion bieten, um die Fragestellungen aus verschiedenen Gesichtspunkten durchleuchten zu können.

Teilnehmer sollen die Session mit Anregungen zum Nachdenken verlassen, wie sie ihre eigene Architekturarbeit effektiver gestalten können.

Alexander Kaserbacher ist Berater für Software-Architektur bei embarc. Mehrjährige Erfahrungen aus der agilen Software-Entwicklung helfen ihm dabei, den Mehrwert von Software-Architektur zu vermitteln und diese effektiv umzusetzen. Neben Cloud-Anwendungen, Microservices und evolutionärer Architektur umfasst seine Leidenschaft für Technologie auch die verschiedensten Auswirkungen von Software auf Unternehmen und gesellschaftliche Faktoren.

Der Technical Software Architect – Was macht der eigentlich?
Der Technical Software Architect – Was macht der eigentlich?

Mal angenommen, es gäbe ein (natürlich fiktives) Großprojekt zur Implementierung einer Microservices-Architektur. Die Entwickler:innen sind in zahlreichen Teams organisiert. Zudem gibt es ein übergreifendes Architekturgremium. Selbstverständlich wird auch ein proprietäres Framework programmiert. In jedem Team existiert die Rolle des "Technischen Architekten".

Kommt Ihnen das bekannt vor? Und haben Sie sich auch schon öfters gefragt, was er/sie eigentlich die ganze Zeit macht? In diesem unterhaltsamen Praxisbericht können Sie es herausfinden.

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

Extended Abstract:
Tatsächlich erscheint es für viele Projektmitarbeitende immer wieder fraglich, was der/die Technical Software Architect eigentlich den ganzen Tag so macht. Scheinbar werden doch die Architekturvorgaben vom dafür verantwortlichen Gremium erarbeitet. In der Praxis ist es jedoch oft so, dass tatsächlich zahlreiche Themen anstehen.

Dazu zählt die Bewertung der Folgen solcher Technologievorhaben für das eigene Team, genauso wie der Versuch der Beeinflussung des Gremiums bei der Entscheidungsfindung. Hinzu kommen diverse "politische" Themen oder die Sicherstellung der Einhaltung von Architekturvorgaben und der Softwarequalität. Über die Jahre habe ich hier eine Reihe sehr interessanter und oftmals auch (rückblickend) amüsanter Erfahrungen gemacht, die ich gerne weitergeben möchte.

Thilo Frotscher arbeitet als freiberuflicher Software-Architekt und Trainer. Als Experte für Java, APIs und Systemintegration unterstützt er seine Kunden überwiegend durch die Mitarbeit in Projekten, Reviews oder die Durchführung von Schulungen. Thilo ist (Co-) Autor mehrerer Bücher in den Bereichen Java, (Web-) Services und Systemintegration, hat zahlreiche Fachartikel verfasst und spricht regelmäßig auf Fachkonferenzen und Schulungsveranstaltungen sowie bei Java User Groups.

Alexander Kaserbacher
Thilo Frotscher
Alexander Kaserbacher

Vortrag Teilen

Thilo Frotscher
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:30
Di 2.1
Selbstführung Debugged – Ist dein Mindset eine Monolith- oder eine Microservice Architektur?
Selbstführung Debugged – Ist dein Mindset eine Monolith- oder eine Microservice Architektur?

Alles hat eine API: Wir ITler sind megagut darin, Software-Architekturen zu durchleuchten und neue Integrations-Patterns für technische Komponenten zu entwickeln. Warum wenden wir diese Fähigkeiten nicht auch auf unser Mindset und unsere Teams an?

In diesem Workshop üben wir uns in der Transferleistung: Warum sind unsere Reaktionen oft hard-coded statt loosely-coupled und wie können wir das ändern? Ist meine Gedankenwelt wie ein Monolith aufgebaut, die sich nur mühsam weiterentwickelt oder lässt sie schnelle Updates zu, wie Microservices?

Zielpublikum: Entwickler:innen, Projektleiter:innen, Manager, Entscheider, Architekt:innen
Voraussetzungen: Architekturmuster- und Projekterfahrung ist von Vorteil, aber kein Muss
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Dieser Workshop macht Lust auf Selbstführung. Die Hypothese, zu der dieser Workshop einlädt, ist:
Das Gesetz von Conway gilt nicht nur für Abteilungen, sondern auch für die Teammitglieder: „Organisationen, die Systeme entwerfen, sind gezwungen, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen abbilden.“

Je mehr Dynamik das Umfeld und die Systeme einfordern, desto dynamischer muss mein Mindset im Team sein. Nicht nur, damit die Systeme funktionieren, sondern damit ich in dem Umfeld glücklich sein kann.
So kann ich beispielsweise das ganze Team inklusive mir selbst als Microservice-Architektur betrachten. Ich kann analysieren: welche Schnittstellen biete ich nach außen an, und sind die auch gut dokumentiert? Wissen die Anderen dass die meisten Schnittstellen vor dem ersten Kaffee nicht ansprechbar sind? Welche Reaktionen sind hart-verdrahtet, wo bin ich anfällig für eine Denial-of-Service Attacke, und was kann ich dagegen tun?

Mit interaktiven Übungen finden wir die richtige Balance für die eigene Mindset und Team-Architektur. Am Ende des Workshops haben Sie einige Entwurfsmuster im Gepäck, mit denen Sie die eigene Mindset-Architektur Step by Step refactoren können (wenn Sie das wollen). Und das spannende dabei: Die meisten Tools haben sie schon im Gepäck - Sie haben sie nur noch nicht auf sich selbst angewendet.

IT und Theater: Christoph Diefenthal arbeitet seit mehr als 15 Jahre als Entwickler und IT-Führungskraft - den kreativen Ausgleich fand er im Theater. Als Schauspieler hat er soviel über Perspektiven + Rollenwechsel gelernt, dass ihm irgendwann klar wurde: Das bringe ich in die Firmenwelt - und zwar mit Spaß!
Seit er die Mutual Empowerment GmbH mitgegründet hat, kombiniert er Team- und Führungsworkshops mit Werkzeugen des systemischen Coachings und Übungen aus dem Impro-Theater. Begeisterung zum Mitnehmen!

Christoph Diefenthal
Christoph Diefenthal
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Di 3.1
Technical Coaching with the Samman Method
Technical Coaching with the Samman Method

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.

Emily Bache is a Technical Coach with ProAgile. She has worked with software development for over 20 years in diverse organizations from start-up to large enterprise. These days Emily specializes in coaching development teams in agile practices like Test-Driven Development, refactoring and agile design. Emily has written two books, authored Pluralsight courses and regularly speaks at software conferences. Originally from the UK, she currently lives in Gothenburg, Sweden.
Twitter: https://twitter.com/emilybache
Linkedin: https://www.linkedin.com/in/emilybache/
Github: https://github.com/emilybache
Website: https://sammancoaching.org/

Micro-Learning-Cycles (MLCs) – Lernen ohne Zeit
Micro-Learning-Cycles (MLCs) – Lernen ohne Zeit

"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.

Ihr Motto „You go first! – Nimm dein Leben in die Hand!", steht für ihr Tun: Rein in den nachhaltigen Erfolg durch Eigenverantwortung und Selbstführung.
Anne Hoffmann unterstützt Menschen und Organisationen dabei, erfolgreich ihre Ziele zu erreichen. Als Expertin für Selbstführung und mit ihrem Motto „You go first!“ erinnert sie daran, dass nachhaltiger Erfolg durch hohe Eigenverantwortung insbesondere dann entsteht, wenn diese Selbstführung vorgelebt wird.
Anne benutzt oft Spiele, um Erkenntnisse weiterzugeben.

Emily Bache
Anne Hoffmann
Anne Hoffmann
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:30
Di 4.1
Ein Werkzeugkoffer für erfolgreiche(re) Software-Architekten
Ein Werkzeugkoffer für erfolgreiche(re) Software-Architekten

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

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

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

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

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

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

Michael Stal
Michael Stal
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:30
Di 5.1
Data, not Opinions: The Psychometrics of Team and Organisational Dynamics
Data, not Opinions: The Psychometrics of Team and Organisational Dynamics

"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.

A quiet and reserved researcher and practitioner with over 25 years experience, Joseph Pelrine is considered by cognoscenti to be one of the pioneers and top experts on Agile methods. As a psychologist, his focus on people and his experience in applying leading-edge techniques from social complexity and psychology to process optimisation goes far beyond the domain of software development, and extends to the whole organisation.

Joseph Pelrine
Joseph Pelrine
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:30
Di 6.1
Validierung & Positionierung deiner Geschäftsidee – (Schnell und effizient wie ein Start-up!)
Validierung & Positionierung deiner Geschäftsidee – (Schnell und effizient wie ein Start-up!)

Deine Idee ist super, sagt deine Mutter. Du wirst reich, sagen deine Freunde. Aber denken das auch deine zukünftigen Kunden? Wir zeigen dir, wie du deine Mutter stolz und deine Freunde neidisch machst: Schaffe wirklichen Mehrwert für deine Kunden und entwickle ein Produkt, das erfolgreich vermarktbar ist.

Um dies zu erreichen, musst du deine Geschäftsidee erfolgreich validieren und positionieren. Dazu brauchst du kein bestehendes Geschäftsmodell (nicht mal eine Geschäftsidee!) – Glaubst du nicht? Komm zum Vortrag und wir zeigen dir, wie es geht!

Zielpublikum: Entwickler:innen, Product Manager, Projektleiter:innen, Entscheider, Founder, Product Owner
Voraussetzungen: Liebe für neue Produkte
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
1. Einführung in Lean Management & Business Modelling mit dem Lean Canvas
2. Warum Validierung so wichtig ist! (Nutzenhypothese und Wachstumshypothese)
- Perfect Product vs. Sales & Marketing
3. Wie validiert man richtig?
- Arten der Validierung und Experimente
- Build/Iterate/Abandon, Qualitativ vs. Quantitativ, Discovery vs. Validation, B2B vs. B2C
- Pretotyping, Prototyping, MVP
4. Hands-on: Zielgruppenanalyse, Nischendefinition, Konzept & Umsetzung
- Leitfäden für Pretotyping, Validierungsgespräche und User Tests

Sergio Morazan ist Geschäftsführer von 01 Digital Age. Er verfügt über Erfahrung als Co-Founder mehrerer Start-ups: eventgrated, 01 Digital Age etc.
Insgesamt haben wir mit 01 Digital Age bereits über 50 SaaS-Start-ups zum Erfolg geführt, über 5000 Leads generiert und über 1.000.000 Zeilen Code geschrieben.
Seine berufliche Erfahrung als Entwickler, Head of Sales, Marketing-Manager sammelte er unter anderem bei Capgemini, Deutsche Post, Sigs Datacom etc.
Unser Team umfasst 30 Experten aus den Bereichen Softwareentwicklung, Projektmanagement, Design, Growth, Sales & Marketing. Growth Hacking & Coding für SaaS-Start-ups. Wir führen Start-ups in kürzester Zeit zu einem marktfähigen Software-as-a-Service-Produkt. Dabei konzentrieren wir uns auf Growth und Tech, denn das eine kann ohne das andere nicht funktionieren. Du willst ein innovatives und stabiles SaaS-Produkt bauen? Mit zukunftsfähigen Technologien und agilen Methoden entwickeln wir dein skalierbares SaaS-System. Du willst schneller wachsen und mehr Leads und Umsätze generieren? Mit unserem Growth-Programm bringen wir dich in kürzester Zeit zu planbaren Umsätzen.

Sergio Morazan
Sergio Morazan
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Di 7.1
Woran man mit DDD scheitert!
Woran man mit DDD scheitert!

Fast 20 Jahre nach dem Start von Domain-driven Design (DDD) ist der Ansatz weit verbreitet - aber das ist noch keine Garantie dafür, dass DDD-Projekte auch erfolgreich beendet werden.

Dieser Vortrag zeigt typische Fehler, Missverständnisse und Probleme, die bei Domain-driven Design und insbesondere bei Strategic Design auftreten. Natürlich diskutiert die Präsentation auch, wie man solche Probleme sinnvoll lösen kann, um vielleicht nicht nur ein Scheitern zu verhindern, sondern sogar einen echten Erfolg zu landen ...

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

Eberhard Wolff ist Fellow bei INNOQ und arbeitet seit mehr als fünfzehn Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u. a. zu Continuous Delivery und Microservices, trägt regelmäßig als Sprecher auf internationalen Konferenzen vor und streamt wöchentlich zum Thema Software-Architektur. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Continuous Delivery, DevOps und Microservices.

Die Domäne ist alles – 15 Jahre Erfahrung mit Domain-Driven Design
Die Domäne ist alles – 15 Jahre Erfahrung mit Domain-Driven Design

Bei der Erstellung von Software werden großartige Technologien, Programmiersprachen und Werkzeuge eingesetzt. Aber leider wird oft aus den Augen verloren, dass der entscheidende Faktor nicht die Technologie, sondern die Domäne ist.

In diesem Vortrag zeige ich euch, wie ihr die Domäne in eurer vorhandenen Software wiederentdecken und als wichtiges Mittel der Architekturverbesserung einsetzen könnt.

Zielpublikum: Architekt:innen, Entwickler:innen, Product Owner, Projektleiter:innen, Requirement Engineers
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Bei der Erstellung von Software werden großartige Technologien, Programmiersprachen und Werkzeuge eingesetzt. Das ist gut und richtig. Aber leider wird oft aus den Augen verloren, dass der entscheidende Faktor nicht die Technologie, sondern die Domäne ist. Wenn wir die Fachsprache und die Geschäftsprozesse nicht in der Software abbilden, dann hilft sie unseren Anwender:innen nicht bei ihrer Arbeit. Keine Technologie der Welt kann uns davor schützen.

In diesem Vortrag zeige ich euch, wie ihr Probleme in eurer vorhandenen Software mit Domain-Driven Design angehen könnt.

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

Eberhard Wolff
Carola Lilienthal
Eberhard Wolff

Vortrag Teilen

Carola Lilienthal
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Di 8.1
How (Not) to Measure Quality
How (Not) to Measure Quality

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.

Michael Kutz has been working in professional software development for more than 10 years now. He loves to write working software, and he hates fixing bugs. Hence, he developed a strong focus on test automation, continuous delivery/deployment and agile principles.
Since 2014 he works at REWE digital as a software engineer and internal coach for QA and testing. As such his main objective is to support the development teams in QA and test automation to empower them to write awesome bug-free software fast.

The State and Future of UI Testing
The State and Future of UI Testing

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.

Johannes Dienst is Developer Advocate at askui. His focus is on automation, documentation, and software quality.

Michael Kutz
Johannes Dienst
Johannes Dienst
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Di 9.1
In wenigen Schritten zum sicheren Kubernetes-Cluster
In wenigen Schritten zum sicheren Kubernetes-Cluster

Immer häufiger werden Anwendungen auf einem Kubernetes-Cluster betrieben. Umso wichtiger ist die Absicherung gegen Angriffe von außen, aber auch innerhalb des Clusters.

Wir demonstrieren anhand von praktischen Beispielen, wie mit wenigen Schritten ein Cluster abgesichert werden kann. Ausreden, warum nicht mehr Sicherheit möglich ist, gibt es dann nicht mehr.

Zielpublikum: Entwickler:innen
Voraussetzungen: Grundkenntnisse in Kubernetes und Security, Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
In den letzten Jahren hat sich Kubernetes als Plattform für Anwendungen etabliert. Es verspricht, das Deployment deutlich zu vereinfachen, birgt aber auf der anderen Seite eine höhere Komplexität.

Oft wird der Betrieb auf einem Kubernetes-Cluster als zusätzliche Aufgabe auf das Entwicklungsteam übertragen, ohne die entsprechende Expertise aufzubauen. Das Wissen um Kubernetes bleibt dann lückenhaft, das Management des Clusters steht nicht im Fokus. In der Konsequenz stehen viele Kubernetes-Cluster ungeschützt im Netz.

Im Vortrag konzentrieren wir uns auf den Aspekt der Sicherheit eines Kubernetes-Clusters gegen Angriffe von außen, aber auch innerhalb des Clusters. Dabei gehen wir Schritt für Schritt durch die verschiedenen Schichten und zeigen anhand praktischer Beispiele, mit welchen Maßnahmen der Cluster abgesichert werden sollte.

Dehla Sokenou fühlt sich in allen Phasen der Software-Entwicklung zu Hause, besonders im Testen. Bei WPS - Workplace Solutions ist sie als Test- und Qualitätsmanagerin und Software-Architektin tätig.

Adrian Metzner ist seit 2014 als Software-Entwickler unterwegs. Schwerpunkte sind dabei Sicherheit und DevOps. Bei WPS - Workplace Solutions ist er als Software-Architekt und Trainer für das ISAQB Cloud-Infra Modul tätig.

DevOps-Betriebsmodelle mit Site Reliability Engineering etablieren
DevOps-Betriebsmodelle mit Site Reliability Engineering etablieren

Ein Erfolgsmuster zur Umsetzung von DevOps ist Site Reliability Engineering (SRE). Sie fördert objektiv die Zusammenarbeit zwischen Teams in einem skalierenden Umfeld. Besonderheit: Die System-Zuverlässigkeit wird zum Nummer 1 Feature! In diesem Vortrag werden die SRE-Prinzipien erläutert und SRE-Praktiken veranschaulicht. Abgerundet wird der Vortrag durch die Veranschaulichung des Aufbaus von Betriebsmodellen mit SRE.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider
Voraussetzungen: Grundkenntnisse in agilen Methoden und Betriebsmodellen
Schwierigkeitsgrad: Anfänger

Halil Hancioglu ist als Solution Architect für die OPITZ CONSULTING Deutschland GmbH tätig. Er verfügt über langjährige Erfahrung in der Erstellung von individuellen Enterprise-Applikationen und der Einführung von DevOps-Praktiken. Seine Stärken liegen in der Analyse und der Restrukturierung von Abläufen mit besonderem Fokus auf SRE, DevOps, Continuous Delivery und Infra-as-Code.

Dehla Sokenou, Adrian Metzner
Halil Hancioglu
11:00 - 12:00
KeyDi 1
KEYNOTE: Schluss mit den digitalen Menschenrechtsverletzungen! Oder: Sind wir nicht alle ein bisschen behindert?
KEYNOTE: Schluss mit den digitalen Menschenrechtsverletzungen! Oder: Sind wir nicht alle ein bisschen behindert?

Auch im digitalen Leben gilt das Menschenrecht auf Teilhabe. Durch Hindernisse bei digitalen Lösungen werden Nutzer oft erst zu Behinderten gemacht. Die gewünschte Inklusion wird „online“ so fast eher zur Exklusion. Das muss sich dringend ändern! Alle Menschen müssen am digitalen Leben teilhaben können – als ihr Menschenrecht. Der Vortrag rüttelt wach im Hinblick auf die vielfältigen Miss-Stände in der digitalen Welt. Die öffentliche Hand ist längst verpflichtet, digitale Teilhabe durch Barrierefreiheit sicherzustellen. Ab 2025 gilt dies auch für die Privatwirtschaft – dank dem Europäischen Gesetz für Zugänglichkeit. IT-Entscheider und IT-Schaffende müssen dem Thema digitaler Barrierefreiheit also dringend Beachtung schenken. Emotional und empathisch setzt Peggy Reuter-Heinrich Impulse und inspiriert so zum Mitfühlen, Mitdenken und Mitwirken an gelingender digitaler Inklusion. Ziel der Expertin ist, den entscheidenden Wandel beim Publikum anzustoßen. Nach diesem Vortrag werden auch Sie zum überzeugten Mitgestalter digitaler Inklusion.

Peggy Reuter-Heinrich ist IT-Unternehmerin, UX-Designerin und Expertin für digitale Barrierefreiheit. Mit jahrzehntelanger Erfahrung aus über 500 Design-Lösungen, über 100 IT-Projekten und über 2.000 Trainings-Stunden weiß sie, was die Nutzer digitaler Lösungen wirklich brauchen und wollen. Nun strebt die mit einigen Awards geehrte UX-Designerin nach der höchsten Form von UX – nämlich sozial verantwortungsvolle Nutzer-Erlebnisse, welche die Teilhabe aller Menschen an der Digitalisierung ermöglicht. Ihre Mission einer menschenfreundlichen IT-Welt und ihr Wissen teilt Peggy in Büchern, Videos, Vorträgen, Schulungen und Beratungen. Mit Passion und Profession setzt sie sich für soziale Gerechtigkeit und Barrierefreiheit in der digitalen Welt ein. Das tut sie auch als Gründerin einer gemeinnützigen GmbH, die mittels IT hilft. Alles in allem inspiriert sie mit dem femininen Charme einer „Women in Tech“ andere Menschen zum Mitfühlen, Nachdenken, aber insbesondere zum Handeln.

Peggy Reuter-Heinrich
Peggy Reuter-Heinrich
Track: Keynote
Vortrag: KeyDi 1
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 14:45
Di 1.2
Data Mesh – Der nächste Schritt zur perfekten Datenarchitektur?
Data Mesh – Der nächste Schritt zur perfekten Datenarchitektur?

Vor drei Jahren als Idee gestartet, gibt es heute viele Produkte & Unternehmen im Data-Bereich, die mit dem Mesh werben. Höchste Zeit zu schauen: Was ist die Kernidee? Welche Probleme soll es eigentlich lösen?
Was ist der Unterschied zwischen Mesh und Data Lake & Data Warehouse? Wie kann es technologisch umgesetzt werden und welche weiteren Bereiche müssen angegangen werden: Organisatorische Aspekte wie Teamschnitt & Skills, Abstimmung zwischen Teams und notwendige Skills in Produkt- und Entwicklerteams.

Zielpublikum: Architekten:innen, Entscheider
Voraussetzungen: Grundlegende Erfahrungen mit Datenarchitekturen, insbesondere für analytische Zwecke
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Die bessere Nutzung von Daten im Unternehmen ist schon seit Langem ein viel diskutiertes Thema. In diesem Kontext entstand die Idee des Data Mesh. In diese Session wird diese Idee nach einer kurzen Vorstellung kritisch hinterfragt: Wo sind Chancen? Wo sind Nachteil zu sehen? Insbesondere im Vergleich zu den bisherigen Konzepten, wenn es um die Bereitstellung und Nutzung von Daten für analytische Zwecke geht: Dem Data Warehouse und einem Data Lake.

So kommen wir in dem Talk auch zu der Frage, welche Unternehmen und Organisation die Prinzipien des Data Mesh näher betrachten sollten. Und wer diesen Hype auch getrost ziehen lassen kann.

Matthias Niehoff ist als Data Architect sowie Head of Data & AI für die codecentric unterwegs und unterstützt Kunden bei Design und Umsetzung von Datenarchitekturen. Dabei liegt sein Fokus weniger auf dem Modell, sondern viel mehr auf der notwendigen Infrastruktur & Organisation, um Daten & KI-Projekten zum Erfolg zu verhelfen.

Matthias Niehoff
Matthias Niehoff
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 14:45
Di 2.2
How to Deal with Toxic People
How to Deal with Toxic People

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.

Gina Häußge is a passionate code monkey, gamer, hobby baker, and creator and maintainer of OctoPrint. She has always been in love with code, and loves tinkering and helping others. Gina has written open source software for most of her adult life and has been in the lucky position to do it full time — and 100% crowdfunded by the community for her project OctoPrint for several years now. During this time, she has learned a lot about leading open source projects and managing communities.

Gina Häußge
Gina Häußge
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 14:45
Di 3.2
Zero Trust for APIs: Patterns and Practices
Zero Trust for APIs: Patterns and Practices

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

Erik Wilde works in the Catalyst team at Axway. The team's mission is to help customers do the right things in the API and digital transformation space. Erik has been working in a variety of software companies, always focusing on questions of architecture and strategy. Erik's background is in computer science and he holds a Ph.D. from ETH Zurich, but over the course of his career it has become increasingly clear to him that technology rarely is the factor holding back organizations. So now he is helping organizations with their strategy to make sure that they are successful on their journeys.

Erik Wilde
Erik Wilde
flag VORTRAG MERKEN

Vortrag Teilen

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

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

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

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

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

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

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

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

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

Johannes Mainusch
Johannes Mainusch
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 14:45
Di 5.2
Gratis Teamentwicklung: Lieblingswerkzeuge zum Mitnehmen
Gratis Teamentwicklung: Lieblingswerkzeuge zum Mitnehmen

Hoch performante Teams entstehen nicht von selbst – da sind wir (und die Forschung) uns mittlerweile einig. Doch was hilft nun einem Team weiter? Und welche Tools wende ich in welcher Situation an?

Zielpublikum: Führungskräfte, Teamleiter, Scrum Master, Agile Coach, Teammitglieder
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Nach über zehn Jahren Arbeit in, mit und an verschiedenen Teams quer durch die Industrie haben wir viele Tools und Werkzeuge ausprobiert, einige Mal völlig danebengegriffen, aber auch echte Perlen gefunden. Wir haben acht Erfahrungsräume herausgearbeitet, in denen Teams unterstützt werden dürfen.

Dieser Vortrag bringt Orientierung in den Team-Entwicklungswerkzeug-Dschungel, indem ich dir meine meistgeliebten freien Tools zur Teamentwicklung vorstelle und einordne. Mit der einen oder anderen Geschichte aus dem Alltag und der dazugehörigen Forschung – praxisnah und pragmatisch.

Jasmine Simons-Zahno ist „Agile Psychologin“, die sich leidenschaftlich für die menschliche Seite der Produktentwicklung einsetzt. Ihr Masterstudium in Organisationspsychologie qualifiziert sie auf einzigartige Weise für die Auseinandersetzung mit den Hindernissen und Widerständen, welche entstehen, wenn das agile Paradigma mit traditionellen Organisationsstrukturen kollidiert. Sie hat es sich zum Ziel gesetzt, Unternehmen dabei zu unterstützen, produktive und motivierende Umgebungen zu schaffen, die Mitarbeiter ermutigen und inspirieren, ihre beste Arbeit mit Freude zu leisten.

Jasmine Simons-Zahno
Jasmine Simons-Zahno
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 14:45
Di 6.2
Viel hilft viel! – Netzwerkeffekte der Plattformökonomie für Nachhaltigkeit nutzen
Viel hilft viel! – Netzwerkeffekte der Plattformökonomie für Nachhaltigkeit nutzen

Nachhaltigkeit lebt vor allem davon, dass sehr viele einen Beitrag leisten und sich ihrer Verantwortung bewusst sind. Ein Hebel dafür liegt in der Plattformökonomie! Sie basiert darauf, schnell Communities aufzubauen und Unternehmen und Menschen zum gegenseitigen Vorteil durch Netzwerkeffekte zu verbinden. Das lässt sich auch für Nachhaltigkeit nutzen.

Wir zeigen konkrete Beispiele, wie existierende Geschäftsmodelle nachhaltiger oder neue Plattformmodelle etabliert werden können. So kann ein balanciertes Ökosystemdesign letztlich viel erreichen.

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

Extended Abstract:
In Digitalen Ökosystemen und der Plattformökonomie gibt es einen großen Gestaltungsspielraum und oft vielfältige Optimierungsmöglichkeiten hinsichtlich der Nutzung von Ressourcen in der realen Welt. So kann z. B. Schüttflix als Broker von Schüttgut und Schüttguttransporten über ein immer größer werdendes Netzwerk von Spediteuren optimieren und sowohl teure als auch umweltschädliche Leerfahrten minimieren.

Weil in Digitalen Ökosystemen immer das Streben nach einer gewissen Größe von Partnern und Teilnehmern da ist, lässt sich das sehr gut mit Nachhaltigkeitszielen verbinden. Sei es, dass der Hauptzweck des Digitalen Ökosystems der Nachhaltigkeit dient oder dass ein Sekundärzweck stärker auf Nachhaltigkeit ausgerichtet wird.

Digitale Ökosysteme und Plattformökonomie zielen immer darauf ab, es den Teilnehmern so einfach wie möglich zu machen: und das ist gerade bei der Erzielung von Beiträgen für Nachhaltigkeit extrem hilfreich. Wenn es (nahezu) genauso einfach ist, sich nachhaltig zu verhalten, dann werden es auch mehr Menschen tun. Wir müssen Bewusstsein schaffen, den Menschen ihre Aktionen und deren Auswirkungen transparent machen und es ihnen so einfach wie möglich machen, sich gut und nachhaltig zu verhalten.

Dieses Potenzial wird oft noch nicht ausreichend genutzt und wir wollen im Vortrag die Möglichkeiten dazu aufzeigen und bei allen Verantwortlichen im Design von Business-Modellen und Softwaresystemen dafür das Bewusstsein schärfen und Empfehlungen an die Hand geben.

Matthias Naab ist Software-Architekt und engagiert er sich seit Jahren dafür, Unternehmen digitale Ökosysteme und die Plattformökonomie besser verständlich zu machen. Er macht sich stark dafür, digitale Ökosysteme nicht nur zur Gewinnerzielung, sondern auch für Nachhaltigkeit zu nutzen.

Marcus Trapp unterstützt als Digital Designer seit vielen Jahren Unternehmen dabei, digitale Potenziale zu nutzen, insbesondere bei der Ideenfindung und initialen Ausgestaltung digitaler Ökosysteme.

Matthias Naab, Marcus Trapp
Matthias Naab, Marcus Trapp
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 14:45
Di 7.2
Carving Microservices Out of the Monolith
Carving Microservices Out of the Monolith

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.

Henning Schwentner loves programming in high quality. He lives this passion as coder, coach, and consultant at WPS – Workplace Solutions in Hamburg, Germany. There he helps teams to structure their monoliths or to build new systems from the beginning with a sustainable architecture. Microservices or self-contained systems are often the result. Henning is author of “Domain Storytelling – A Collaborative Modeling Method” and the www.LeasingNinja.io as well as translator of “Domain-Driven Design kompakt”.

Henning Schwentner
Henning Schwentner
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 14:45
Di 8.2
Testing AI Systems
Testing AI Systems

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.

Gregor Endler holds a doctor's degree in Computer Science for his thesis on completeness estimation of timestamped data. His work at Codemanufaktur GmbH deals with Machine Learning and Data Analysis.

Marco Achtziger is a Test Architect working for Siemens Healthcare GmbH in Forchheim. He has several qualifications from iSTQB and iSQI and is a certified Software Architect by Siemens AG.

Gregor Endler, Marco Achtziger
Gregor Endler, Marco Achtziger
flag VORTRAG MERKEN

Vortrag Teilen

14:00 - 14:45
Di 9.2
Klimawandel trifft DevOps – DevGreenOps
Klimawandel trifft DevOps – DevGreenOps

Angetrieben durch Bewegungen wie Fridays For Future hat sich unser Fokus wieder auf die Klimaveränderung gerichtet. Unternehmen achten immer mehr darauf, klimaneutral zu werden und/oder klimaneutrale Produkte zu liefern.

Was hat das eigentlich für Auswirkungen auf unser herkömmliches IT-Verständnis? Machen wir einfach weiter wie bisher? Gibt es Einflüsse auf die DevOps-Bewegung?

Dieser Vortrag versucht Aufklärung und gibt erste Schritte, wie wir unsere Denkweise anpassen können.

Zielpublikum: Alle DevOps-Fans, Entscheider
Voraussetzungen: Cloud Verständnis, DevOps
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
DevOps und eigentlich auch die agile Bewegung stellen eine hohe Valueorientierung in den Fokus, und zwar Valueorientierung für den Kunden.

Ist das überhaupt noch gültig? Oder können wir bestehende Methodiken wie Wertstromanalysen noch weiterhin benutzen?

Zudem schauen wir uns an, wie uns Cloudprovider helfen bei der Unterstützung, CO2-Emissionen erst mal zu verstehen. Wie schon in Gemba, heißt es zunächst, den Verbrauch zu sehen und danach Maßnahmen zur Verbesserung durchzuführen.

Was können Maßnahmen sein? Da werden wir uns auch paar Beispiele ansehen. Unter anderen neue Faktoren in der Auswahl einer Cloudregion.

Justus Graumann hat es nach dem Studium in die IT-Branche verschlagen und seit 20 Jahren ist er, meistens im Java-Bereich, für verschiedene Unternehmen tätig. Seit nun mehr einigen Jahren ist er an verschiedenen Transformationsprojekten in der SwissRE beteiligt und gerade dabei, in seiner Domaine IT DevOps-Themen voranzutreiben. Nebenbei hält er auf diversen Konferenzen & MeetUps Vorträge.

Justus Graumann
Justus Graumann
flag VORTRAG MERKEN

Vortrag Teilen

16:15 - 17:15
Di 1.3
The Best Architecture is Late Architecture
The Best Architecture is Late Architecture

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.

Michael Sperber is CEO of Active Group in Tübingen, Germany. Mike specializes in functional programming and has been an internationally recognized expert in the field: He has spoken at the top conferences in programming languages, authored many papers on the subject as well as several books. Moreover, he is an expert on teaching programming.

Michael Sperber
Michael Sperber
flag VORTRAG MERKEN

Vortrag Teilen

16:15 - 17:15
Di 2.3
Wenn Bosse streiten ...
Wenn Bosse streiten ...

Eine geteilte Unternehmensführung ist heute in vielen Unternehmen gelebte Praxis. Meist setzt sich das Führungsteam aus erfahrenen Experten zusammen, die unterschiedliche Fokuspunkte und Stärken mitbringen. Diese Unterschiedlichkeit der Bosse kann ein wahrer Segen sein - wenn sie zusammenwirken und einander ergänzen. Weit häufiger ist sie allerdings ein Fluch, unter dem das ganze Unternehmen leidet.

Ergründen Sie mit uns, wie die Einigkeit der Führungsspitze gelingen kann - und zu einem nachhaltig gesunden und ausbalancierten Unternehmen führt.

Zielpublikum: Manager, C-Level, Projektleiter:innen, Agile Coaches, Scrum Master, Menschen, die Menschen führen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Wenn Führungspersonen streiten oder gar Machtkämpfe austragen, ist das unangenehm für alle, die mit ihnen zu tun haben. Wenn diese Führungspersonen jedoch die Spitze eines Unternehmens besetzen, krankt es nachhaltig überall - und unter Umständen ist sogar der Fortbestand des Unternehmens selbst in Gefahr.

Das spüren natürlich alle Mitarbeitenden: Die Zahlen stimmen nicht, es gibt eine Kultur der Intransparenz, Vorwürfe, Unzufriedenheit und Kündigungen sind an der Tagesordnung. Der Ruf nach Veränderung wird laut. Und die wird dann mannigfaltig angestoßen. Da gibt es Dutzende von parallellaufenden Change-Projekten, Werte-Workshops, Feedback-Trainings, Führungsretreats, externe Coaches werden gerufen ... Nur an einer Stelle ändert sich nichts: an der Führungsspitze. Und deshalb bringen alle diese wunderbaren Initiativen zwar kurzfristige Erleichterung, jedoch kaum nachhaltige Verbesserung mit sich. Die Kosten-Nutzen-Rechnung geht nicht auf.

Doch wer soll sich in die Höhle der Löwen wagen? Wer soll ansprechen, was tatsächlich im Argen liegt - und vor allem wie?

Wir coachen seit Jahren immer wieder Geschäftsführungs-Teams, die aus dem Gleichgewicht gekommen sind und darunter leiden. Dabei haben wir eines gelernt: Fast immer gibt es ein Gefühl der fehlenden Wertschätzung durch die jeweils anderen. Die betroffenen Personen denken, dass sie in ihrer Sichtweise, Expertise und Meinung von den anderen nicht gewürdigt werden, und so kommt es zu einem erbitterten Kampf um die Richtung der Unternehmensentwicklung, die natürlich niemand gewinnen kann.

In diesem Talk möchten wir aus dem Coaching-Nähkästchen plaudern und geradeheraus aussprechen, was ohnehin viele ahnen. Und dann geht es natürlich darum, wie Sie Ihr Führungsteam unterstützen können, künftig wieder besser an einem Strang zu ziehen - oder, wenn Sie selbst betroffen sind, wie Sie wieder zueinanderfinden und das Wohl Ihres Unternehmens gemeinsam in den Fokus rücken.

Veronika Jungwirth ist Lösungsfokussierte Coach und Co-Gründerin von sinnvollFÜHREN. Sie unterstützt das Miteinander in Führungsteams und Führung auf Augenhöhe. Ehem. Führungsperson bei der UNIQA Vers. AG.

Ralph Miarka ist Lösungsfokussierter Agile Coach und Co-Gründer von sinnvollFÜHREN in 2015. Er möchte die Arbeitswelt nachhaltig verändern. Ehem. Leiter des SC PM der PSE, Siemens AG Österreich.

Veronika Jungwirth, Ralph Miarka
Veronika Jungwirth, Ralph Miarka
flag VORTRAG MERKEN

Vortrag Teilen

16:15 - 17:15
Di 3.3
Warum es bei der Digitalisierung auch auf das richtige Mindset ankommt
Warum es bei der Digitalisierung auch auf das richtige Mindset ankommt

Die Digitalisierung schreitet voran! Geht es den einen zu langsam, gibt es andere, denen es zu schnell geht.

Beiden Parteien gemeinsam ist, dass es das richtige Mindset braucht, um den Herausforderungen der Digitalisierung und der damit einhergehenden Transformation Tempo zu verleihen oder mit ihr Schritt halten zu können.

In dem Vortrag schauen wir uns die unterschiedlichen Dimensionen an, für die ein Umdenken angesagt ist. Dabei spannen wir den Bogen von der Fachlichkeit über die Technologie hin zu den organisatorischen Herausforderungen.

Zielpublikum: Manager, Entscheider, Architekt:innen, Projektleiter:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Aufseiten der Technologie muss man sich einfach mal die Landkarte der Cloud Native Computing Foundation ansehen, um zu erkennen, dass wir hier vor neuen Herausforderungen stehen. Es müssen geeignete Architekturen entworfen und die Technologien sorgfältig ausgewählt werden.

Damit ist es aber nicht getan, denn wir müssen uns auch überlegen, wie wir Domänen finden und schneiden, wie wir in Zukunft mit unseren Daten umgehen, wie wir die Herausforderungen der KI meistern werden und welche Auswirkungen all diese Themen auf die Organisation und Kultur in den Unternehmen haben.

Bei allen Beteiligten, vom Kunden über den Product Owner zum Software-Engineer bis hin zum Management, kommt es in Zukunft auf das richtige Mindset an, um als Unternehmen oder Institution erfolgreich zu sein und am Markt bzw. bei den Bürgern bestehen zu können.

Dabei klären wir abschließend die Fragen:
•    Kann man jetzt noch von "einem" oder dem "richtigen" Mindset sprechen?
•    Wenn es das nicht gibt, wie bekommt man mehrere Mindsets unter einen Hut?

Als Software- und IT-Architekt mit über 30 Jahren Berufserfahrung wurde Peter Diefenthäler geprägt durch die Entwicklungen in der IT vom Mainframe bis hin zu modernen Cloud-Plattformen.
Der Wandel von der EDV zur modernen IT ist zu einem seiner Steckenpferde geworden. Es liegt ihm am Herzen, Brücken zwischen Technologie und Organisation zu bauen und sich dafür einzusetzen, dass man alte Zöpfe ein Stück weit abschneidet, um das Maximum aus den heute verfügbaren Möglichkeiten herauszuholen.

Peter Diefenthäler
Peter Diefenthäler
flag VORTRAG MERKEN

Vortrag Teilen

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

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

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

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

Extended Abstract:
The journey will have the following stages:

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

Stage 2: Customisation of an Open Source product

Stage 3: Migration - decisions and actual experiences during migration

Stage 4: Rollout and staying alive

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

Bernd Rederlechner
Bernd Rederlechner
flag VORTRAG MERKEN

Vortrag Teilen

16:15 - 17:15
Di 5.3
Trauma-informed Agile – How I Adapted my Practice to Latest Knowledge in Psychology
Trauma-informed Agile – How I Adapted my Practice to Latest Knowledge in Psychology

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

Anton Skornyakov is an Agile Coach and CST® for Scrum Alliance®, an experienced speaker and facilitator at many conferences, user groups for topics around Agile, facilitation, non-violent communication and leadership. Largest spaces were GSG Munic 2016, GSG Vienna 2019, OOP Munic 2019. However, there were many more at local conferences, user groups and meetups.
Most relevant to the topic Anton is speaking about, is his recently finished education as a NARM®-informed professional with the NARM® Training Institute. NeuroAffective Relational Model® (NARM®) is a unique and powerful approach to developmental trauma.

Anton Skornyakov
Anton Skornyakov
flag VORTRAG MERKEN

Vortrag Teilen

16:15 - 17:15
Di 6.3
User-Experience-Design mit Explainable AI
User-Experience-Design mit Explainable AI

Erklärbare KI (Explainable AI, kurz XAI) ermöglicht es, automatisiert situations- und zielgruppenspezifische Begründungen für die Empfehlungen, Prognosen und Entscheidungen von KI-Systemen zu erzeugen.

Hierdurch lassen sich nicht nur Nachvollziehbarkeit und Akzeptanz automatisierter Entscheidungen bei Endanwender:innen steigern, sondern auch Reaktions- und Handlungsmöglichkeiten aufzeigen. Anhand praxisnaher Beispiele demonstrieren wir, wie die Methodenvielfalt Erklärbarer KI für das UX-Design genutzt werden kann.

Zielpublikum: Produktdesigner, UX-Designer, Projektverantwortliche, Datenwissenschaftler, Entscheidungsträger
Voraussetzungen: Grundkenntnisse im UI/UX-Design
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Methoden der Erklärbaren KI (Explainable AI, kurz XAI) werden vor allem zur Analyse und Kontrolle von komplexen KI-Systemen eingesetzt. So nutzen Data Scientists Ansätze wie Partial Dependence Plots oder SHAP, um zu ergründen, welchem Teil der Eingabedaten ein Machine-Learning-Modell besondere Bedeutung zugemessen hat.

Doch Erklärbare KI lässt sich auch zur Gestaltung der User Experience für Endanwender:innen nutzen. “Warum erhalte ich ausgerechnet diese Empfehlung?” “Woran wurde bei dieser E-Mail ein Phishing-Verdacht erkannt?” “Warum ist der prognostizierte Verkaufspreis meiner Immobilie so niedrig?” Fragen dieser Art stellen sich häufig, wenn Nutzer:innen mit Anwendungen und Prozessen in Kontakt kommen, bei denen im Hintergrund ein KI-System am Werk ist, das auch für seine Entwickler:innen eine “Black Box” darstellt.

Erklärbare KI ermöglicht es, automatisiert situations- und zielgruppenspezifische Begründungen für KI-Entscheidungen zu erzeugen. Hierdurch lassen sich nicht nur Nachvollziehbarkeit und Akzeptanz automatisierter Entscheidungen steigern, sondern auch Reaktions- und Handlungsmöglichkeiten aufzeigen.

Neben einer allgemeinen Einführung in das Thema “User-Centric Explainable AI” demonstrieren wir anhand von praxisnahen Beispielen, wie die mittlerweile verfügbare Methodenvielfalt Erklärbarer KI ausgeschöpft und zur Gestaltung der Interaktion von Endanwender:innen genutzt werden kann.

Kilian Kluge arbeitet als Co-Gründer von Inlinity daran, mit Explainable AI Anwendungsbereiche für KI-Systeme zu erschließen, in denen bislang regulatorische oder unternehmerische Risiken einem Einsatz entgegenstehen. Zuvor war er mehrere Jahre als IT-Berater und Entwickler in der deutschen Finanzbranche tätig und hat an der Universität Ulm zu nutzerzentrierter KI promoviert.

Kilian Kluge
Kilian Kluge
flag VORTRAG MERKEN

Vortrag Teilen

16:15 - 17:15
Di 7.3
DDD und weiter? Die Welt von Team Topologie und Co.
DDD und weiter? Die Welt von Team Topologie und Co.

Eure Domänen sind identifiziert? Event Storming gemacht? Anti-Corruption Layer definiert? Sehr gut, das ist die halbe Miete.

In der Praxis geht es danach um technische Basisplattformen, zentrale Sicherheitskonzepte, UX-Strategien usw., aber auch um die Abbildung dieser Themen auf Teams und deren Zusammenarbeit.

Wir präsentieren Erfahrungen aus echten Projekten und zeigen, wie es nach dem ersten DDD-Aufschlag weitergeht. Wir vertiefen Konzepte wie Team Topologies und streifen Themen wie den Ideal Present Canvas oder soziotechnische Architekturen.

Zielpublikum: Entwickler:innen, Agile Coaches, Management-Rollen
Voraussetzungen: DDD Grundlagen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Domain-Driven Design und verwandte Techniken eigenen sich sehr gut, um den fachlichen Schnitt einer Anwendung und den Teamschnitt von Produktteams zu definieren bzw. weiterzuentwickeln. Blicken wir auf ganze Entwicklungsvorhaben in der Praxis, gibt es jedoch eine Menge an Themen, die nicht zwangsläufig in Domänenservices landen: Wie gehen wir mit technischen Basisplattformen um? Wo entstehen zentrale Sicherheitskonzepte? Wo UX-Strategien oder Logging und Tracing-Konventionen? Die Abbildung dieser Themen auf Teams und deren Zusammenarbeit ist schwierig zu besprechen.

Team Topologies beinhaltet Konzepte und Prinzipien, aber auch eine Notation, um hier zu helfen. Es spielt gut mit Praktiken aus dem DDD-Bereich zusammen und kann um weitere Werkzeuge (wie den Ideal Present Canvas) ergänzt werden. So wird es möglich, komplexe Softwaresysteme über die fachliche Gliederung hinaus zu besprechen und Teamschnitt sowie Team-Zusammenarbeit explizit weiterzuentwickeln.

Wir haben in mehreren Branchen - wie E-Commerce, E-Mobilität, Logistik und anderen - Erfahrung in der Anwendung gesammelt. In dieser Session präsentieren wir unsere Erkenntnisse aus dieser Praxis, zeigen Beispiele und geben Hinweise zur eigenen Anwendung. Wir sprechen über Minimal Viable Platforms, Interaction Modes für Teams, die Herausforderungen bei Enabling Teams in Ramp-up-Phasen usw. Alles ausgehend von der gängigen DDD-Praxis.

Stefan Toth berät Entwickler, Teams und Unternehmen in Sachen Agilität und Software-Architektur. Fundiert, klar und effektiv. Seine Erfahrungen reichen vom Banken- und Versicherungssektor über sicherheitskritische Branchen bis hin zur Unterstützung von Internet Start-ups. Neben dem breiten technologischen Kontext ist die methodische Erfahrung aus agilen Projekten, Architekturbewertungen und IT-Transformationen sein größtes Kapital.

Peter Götz ist IT Consultant und agiler Coach. Er hat in mehr als 20 Jahren Softwareentwicklung aus verschiedenen Perspektiven und in verschiedenen Rollen begleitet.
Als aktives Mitglied im iSAQB liegen ihm Software-Architektur und die Arbeit als Software-Architekt besonders am Herzen.
Er ist Professional Scrum Trainer der Scrum.org und hat langjährige Erfahrung in agilen Softwareentwicklungsprojekten.
Weitere Informationen zu Peter gibt es unter: https://pgoetz.de/

Stefan Toth, Peter Götz
Stefan Toth, Peter Götz
flag VORTRAG MERKEN

Vortrag Teilen

16:15 - 17:15
Di 8.3
Test Intelligence für manuelle Tests
Test Intelligence für manuelle Tests

Manuelle Tests wirken altmodisch, aufwendig und langsam. Trotzdem spielen sie in vielen wichtigen Softwaresystemen eine zentrale Rolle, auch langfristig.

In diesem Vortrag stelle ich Analysetechniken vor, die den Aufwand und die Durchführungszeit von manuellen Tests optimieren. Diese Techniken sind ursprünglich für automatisierte Tests entwickelt worden, lassen sich aber für manuelle Tests adaptieren, oft sogar mit besseren Ergebnissen.

Ich stelle die Grundlagen dieser Analysen vor und zeige Erfahrungen im Einsatz in der Praxis.

Zielpublikum: Tester, Test-Manager
Voraussetzungen: Erfahrungen mit manuellen Tests
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Manuelle Tests wirken altmodisch, aufwendig und langsam: Im Vergleich zu automatisierten Tests haben sie einen sehr hohen manuellen Aufwand für die Durchführung. Test-Phasen dauern damit oft Wochen statt Stunden und verhindern dadurch potentiell kürzere Release-Zyklen.

Trotzdem spielen sie bei vielen missionskritischen Softwaresystemen eine entscheidende Rolle in der Qualitätssicherung: Weil sich einige Tests nicht oder nur mit unverhältnismäßig hohem Aufwand automatisieren lassen, oder weil manuelle Tests komplementär zu automatisierten eingesetzt werden, um andere Fehlertypen zu finden, etc. Unser Survey [1] unter 38 Testern aus 16 internationalen Firmen hat aufgezeigt, dass diese Firmen auch weiterhin manuelle Tests als integralen Bestandteil ihres QS-Prozesses sehen und beibehalten werden.

In diesem Vortrag möchte ich Analysetechniken vorstellen, um den Aufwand und die Durchführungszeit von manuellen Tests zu optimieren. Diese Techniken sind ursprünglich für automatisierte Tests entwickelt worden, lassen sich aber auch für manuelle Tests adaptieren. Da die Kosten für die manuelle Ausführung oft viel höher sind als bei automatisierten Tests, erzielen sie oft bei manuellen Tests die viel höheren Ersparnisse.

Ich gehe im Vortrag unter anderem auf folgende Analysen ein:
•    Test-Priorisierung: Selektionsalgorithmen, die eine Teil-Testsuite ermitteln, die in kurzer Zeit einen möglichst großen Teil der Funktionalität testet. Diese „optimale Smoke-Test-Suite“ kann am Anfang einer Testphase ausgeführt werden, um zu verhindern, dass eine sehr fehlerhafte Version einer Software in den manuellen Test kommt, wo sich viele Fehler gegenseitig überdecken.
•    Test-Impact-Analyse: Auswahl der Tests, die eine spezifische Änderung am Code durchlaufen. Dadurch können bei Hotfix-Tests in kurzer Zeit neue Fehler gefunden werden, die ggf. durch den Hotfix entstanden sind.
•    Test-Gap-Analyse: Aufdeckung von Änderungen/neuen Features, die im manuellen Test übersehen und nicht getestet wurden (oder sich nach dem manuellen Test ergeben haben, und die Wiederholung des Tests erfordern).

Im Vortrag stelle ich sowohl die Grundlagen und Grenzen dieser Analysen vor, als auch Erfahrungen und Erfolge im Einsatz in der Praxis.

[1] "How Can Manual Testing Processes Be Optimized? Developer Survey, Optimization Guidelines, and Case Studies". Roman Haas, Daniel Elsner, Elmar Juergens, Alexander Pretschner. In Proceedings of the 29th ACM Joint Eurpoean Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE '21').

Dr. Elmar Juergens hat über statische Codeanalyse promoviert und für seine Doktorarbeit den Software-Engineering-Preis der Ernst Denert-Stiftung erhalten. Er ist Mitgründer der CQSE GmbH und begleitet seit zehn Jahren Teams bei der Verbesserung ihrer Qualitätssicherungs- und Testprozesse. Juergens spricht regelmäßig auf Forschungs- und Industriekonferenzen und wurde für seine Vorträge mehrfach ausgezeichnet. Elmar Juergens wurde 2015 zum Junior Fellow der Gesellschaft für Informatik ernannt.

Elmar Juergens
Elmar Juergens
Vortrag: Di 8.3
flag VORTRAG MERKEN

Vortrag Teilen

16:15 - 17:15
Di 9.3
If it is About Cloud Native Transformation ... It Is Still About People! (Experience Report)
If it is About Cloud Native Transformation ... It Is Still About People! (Experience Report)

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!

Maryse Meinen is a product leader, currently working in a product owner role, building a full-blown container platform for a new IT infrastructure, together with an awesome team. She is also an active practitioner of Stoic philosophy, trying to live according to values like "humans are made for cooperation", "wisdom" and "perseverance". Always keeping an eye on the human aspect of our work, she strives to humanise our workplace a bit more every day.

Maryse Meinen
17:45 - 18:45
Di 1.4
Integrationsarchitekturen in einer VUCA World
Integrationsarchitekturen in einer VUCA World

Integrationsarchitekturen sind der entscheidende Schlüssel in einer sich schnell entwickelnden Welt. Dabei ändern sich sowohl Geschäftsmodelle als auch technologische Grundlagen schnell und nachhaltig. Wir können aber nicht bei jeder Änderung die Software neu auf der grünen Wiese entwickeln.

Der Beitrag diskutiert den Prozess des Architekturdesigns und typische Integrationsmuster in hybriden Cloud- und On-Promise-Umgebungen.

Zielpublikum: Entwickler:innen, Architekt:innen
Voraussetzungen: Prinzipielle Architekturkenntnisse
Schwierigkeitsgrad: Anfänger

Extended Abstract:
1. Entwicklung einer Architekturvision mit Domain Storytelling und Event Storming
2. Anwendung der Vision in der realen Welt
3. Allgemeine Architekturmuster für Integrationen
4. Eventintegration für Server-zu-Server-Integrationen
5. REST-Integrationen für Benutzerzugriffen
6. Take Aways

Annegret Junker ist Lead Architect bei Allianz Deutschland. Sie arbeitet seit mehr als 30 Jahren in der Software-Entwicklung in unterschiedlichen Rollen und unterschiedlichen Domänen wie Automotive, Versicherungen und Finanzdienstleistungen. Besonders interessiert sie sich für DDD, Microservices und alles, was damit zusammenhängt. Derzeit arbeitet sie in einem großen Versicherungs-Projekt als übergreifende Architektin.

Annegret Junker
Annegret Junker
flag VORTRAG MERKEN

Vortrag Teilen

17:45 - 18:45
Di 2.4
Why Your OKR Is As Bad As Your Agile
Why Your OKR Is As Bad As Your Agile

Ever wondered why the new buzzword is OKR? What does it bring to your company? Did you already try it? Did it help?

In this talk I'll reflect on some of the current industry issues with this valuable tool. Why its adoption often struggles, what to do about it and how to detect issues early on.

Target Audience: Everyone, actually. Decision Makers, Devs, Architects, Coaches, All sorts of Managers
Prerequisites: None
Level: Basic

Extended Abstract:
We may all have heard of - or even suffered under - the current big buzzword: OKRs. Google does it, so it must be great. However, in many orgs it has turned out to not turn them into Google in an instant. Why is that? What can we learn from how the adoption of Agile currently is? What could orgs do better? Is OKR a valid tool after all or just the new hype that will vanish soon? Will it turn into "Dark OKR" like Scrum probably did?

This session consists of an interactive part, some analysis, lots of storytelling and then some conclusions.

Since selling his first software at the age of 17 Dennis Wagner is all about developing.
In such different roles like software architect, team lead, developer or product manager he has searched for and travelled on different paths to successfully develop software better.
Being open, curious, surely extrovert and agilist by heart since he first discovered XP and Scrum more than a decade ago.
Today he is helping teams and organisations of all sizes as coach to identify and live up to their potential.

Dennis Wagner
Dennis Wagner
flag VORTRAG MERKEN

Vortrag Teilen

17:45 - 18:45
Di 3.4
Von „agil sagen“ zu „agil machen“ zu „agil sein“: Motivation, Mindset, Menschen, Missverständnisse
Von „agil sagen“ zu „agil machen“ zu „agil sein“: Motivation, Mindset, Menschen, Missverständnisse

Agil(ität) ist in Zeiten der Pandemie, des gesellschaftlichen Wandels und der digitalen Transformation en vogue. Viele Unternehmen geben an, agil zu sein – und Aufträge, Projekte oder Produkte agil umzusetzen. Doch wie viele dieser Unternehmen sind tatsächlich agil, oder sagen dies lediglich (vielleicht ohne zu wissen, dass sie es nicht sind)?

Diese Session liefert einen exemplarischen praktischen Einblick, wie Fujitsu den Herausforderungen der agilen Transformation begegnet, mit Fokus auf den Unterschied zwischen Business- und Teamagilität.

Zielpublikum: Entscheider (Fach- und Linienvorgesetzte), Projektleiter:innen, Agile Köpfe
Voraussetzungen: Grundkenntnisse agile Vorgehensweisen und (agile) Transformation
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Auch ohne Covid-19 waren gesellschaftlicher Wandel und digitale Transformation bereits in vollem Gange, der Blick in eine nachhaltigere Zukunft gerichtet. Die Pandemie schob diesen Wandel noch stärker an. Viele Prozesse in Unternehmen veränderten sich stark, genau wie Bedarfe und Anforderungen der eigenen Belegschaft, von Kunden und Partnern. Verteiltes und mobiles Arbeiten oder verteilte Meetings sind nur einige Schlagworte, die immer mehr in den Fokus rückten, genau wie eine Erweiterung oder Kombination der digitalen Transformation um die Facette Agilität bzw. agiles Arbeiten. Speziell in Verbindung mit dem Thema DevOps erhielt die Agilität einen weiteren Anschub.

Um sich den Herausforderungen dieses gesellschaftlichen (und agilen) Wandels im Zuge der eigenen agilen Transformation zu stellen, startete Fujitsu Deutschland verschiedene Initiativen. Eine davon ist das Agile Pioneer-Programm. Diese berufsbezogene inhaltliche Weiterbildung soll dabei helfen, nachhaltig ein gemeinsames Verständnis von Agilität zu schaffen, und damit einen Mehrwert generieren – sowohl unternehmensintern als auch beim Kundeneinsatz.

Nachhaltigkeit steht dabei nicht allein beim Thema „gemeinsames Verständnis” auf der Agenda, sondern ergibt sich aus den Lehr-Inhalten, die bspw. bei Themen wie verteiltem und hybriden Arbeiten sowie der Vermeidung von Verschwendung stark unterstützen. Diese hauseigene Lösung ist an dem Fujitsu Way of Life sowie der Vision und Kultur des Unternehmens ausgerichtet und bietet einen ganzheitlichen Ansatz bei der Betrachtung von Agilität. Die größte Herausforderung bestand darin, die Frage zu beantworten: „Wie kommen wir von agil ‚sagen‘ via etwas agil ‚machen‘ dazu, tatsächlich agil zu ‚sein‘?“ Schlüsselfaktoren bei der Beantwortung dieser Frage waren Motivation, Mindset, Menschen und Missverständnisse, die in dieser Session genauer unter die Lupe genommen werden.

In dieser interaktiven Session erhalten die Teilnehmer:innen einen Überblick über eine der Facetten der (agilen) Transformation bei Fujitsu. Dabei wird der Unterschied zwischen Business-Agilität und Teamagilität herausgearbeitet. Zudem stehen die Mehrwerte, Stolpersteine und Hindernisse eines internen Weiterbildungsprogramms zur Unterstützung der Transformation im Fokus. Zu all diesen Punkten werden die Teilnehmer:innen in Gruppen gezielte Frage- und Problemstellungen bearbeiten – und so ein tieferes Verständnis bezüglich der möglichen Tragweite und Wirkungskraft des Themas Agilität erfahren.

Sebastian Mühleis - Agile Mind – ist Analyst, Consultant, Coach, Scrum Trainer, Scrum Master (PSM II), Product Owner (PSPO II), Scrum with Kanban (PSK), Professional Agile Leader (PAL I).

Sebastian Mühleis
Sebastian Mühleis
Vortrag: Di 3.4
Themen: Agilität
flag VORTRAG MERKEN

Vortrag Teilen

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

Die Architekturkritik bezeichnet bahnbrechende Bauwerke als Architekturikonen.

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

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

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

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

Stefan Zörner
Stefan Zörner
flag VORTRAG MERKEN

Vortrag Teilen

17:45 - 18:45
Di 5.4
The Passions of Programming
The Passions of Programming

"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.

Kevlin Henney is an independent consultant, speaker, writer and trainer. His development interests are in programming, practice and people. He is co-author of two volumes in the ”Pattern-Oriented Software Architecture” series, and editor and contributor for multiple books in the ”97 Things” series. He lives in Bristol and online.

Kevlin Henney
Kevlin Henney
flag VORTRAG MERKEN

Vortrag Teilen

17:45 - 18:45
Di 6.4
Shift Left: Der Turnaround der digitalen Produktentwicklung
Shift Left: Der Turnaround der digitalen Produktentwicklung

Shift Left ist, unterschiedliche Prozesse möglichst frühzeitig und direkt im Rahmen der Software-Entwicklung einzusetzen. Während es aus dem Test-Umfeld kommt, hat es große Auswirkungen auf alle Felder der Produktentwicklung. Product Owner und Unternehmen sind nicht auf diesen Mindset Change vorbereitet.

Alte Prozesse, Big Design upfront, Legacy, mangelnde Kenntnis bei der Produktentwicklung: Mit der ganzheitlichen Shift-Left-Denke gelingt der Turnaround zu äußerst werthaltigen Produkten.

Zielpublikum: Product Owner, Produktverantwortliche, Manager, Projektleiter:innen, Entscheider
Voraussetzungen: Produkt-/Projekt-/Management-Erfahrung, agile Methoden
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Der Vortrag führt in Shift Left ein und erklärt, wie in der Produktentwicklung anders gehandelt werden muss.

Product Owner, Produktverantwortliche und Manager in Organisationen erfahren, welchen Upskill sie benötigen, und wie Rahmenbedingungen zu verändern sind, damit die Benefits dieser Denkweise gehoben werden können.

Björn Schotte ist Geschäftsführer der MAYFLOWER GmbH. Er berät Kunden in Fragen der Digitalen und Agilen Transformation. Die mehr als 100-köpfige Crew der MAYFLOWER realisiert moderne, zukunftsweisende Software-Lösungen in agilen Teams.
Mit Erstaunen und forschender Neugier ist er seit 2005 auf lebenslanger agiler Reise unterwegs. Er ist auf Xing (https://www.xing.com/profile/Bjoern_Schotte), LinkedIn (https://www.linkedin.com/in/bjoernschotte/), Twitter (https://twitter.com/BjoernSchotte) und Slideshare (https://de.slideshare.net/BjoernSchotte) zu finden.

Björn Schotte
Björn Schotte
flag VORTRAG MERKEN

Vortrag Teilen

17:45 - 18:45
Di 7.4
DDD und DevOps sind das perfekte Team – warum?
DDD und DevOps sind das perfekte Team – warum?

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

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

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

Extended Abstract:
Das DevOps-Versprechen "You build it, you run it" wird mittlerweile in zahlreichen Unternehmen ernst genommen und erfolgreich etabliert. Durch die enge Zusammenarbeit zwischen Entwicklung und Betrieb können zahlreiche Hürden überwunden und Release-Prozesse beschleunigt werden.

Darüber hinaus wollen wir mit einer agilen Denkweise weg von einem traditionellen Projektdenken hin zu einem Produktdenken kommen. Für Letzteres ist jedoch eine weitere Fähigkeit relevant: das Wissen über die Geschäftsdomäne.

Hier kommt die Softwarearchitekturdisziplin Domain-driven Design (DDD) ins Spiel, die eine sehr enge Zusammenarbeit zwischen Domänenexpert:innen und Entwicklungsteams propagiert.

Dieser Vortrag gibt Ihnen einen Überblick über Domain-driven Design und zeigt auf, wie sich die Ideen von DevOps und DDD ergänzen und welche Vorteile sich aus der Kombination der beiden Ideen ergeben. Darüber hinaus wird kurz erörtert, wie Microservices mit Domain-driven Design harmonieren. Zusammenfassend werden wir im Laufe der Präsentation sehen, dass aus einem "you build it, you run it" dank Domain-Driven Design ein "you design it, you build it and you run it" werden kann.

Michael Plöd ist Fellow bei INNOQ. Seine aktuellen Interessengebiete sind Microservices, Domain-driven Design, Alternativen zu alt eingewachsenen Softwarearchitekturen, Event Sourcing und Präsentationstechniken für Entwickler und Architekten. Michael ist zudem Autor des Buchs „Hands-on Domain-driven Design - by example“ auf Leanpub.

Michael Plöd
Michael Plöd
flag VORTRAG MERKEN

Vortrag Teilen

17:45 - 18:45
Di 8.4
The Shape of Testing, Teams and the World in the Future
The Shape of Testing, Teams and the World in the Future

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.

Alex Schladebeck ist ein Wirbelwind aus Begeisterung für Qualität, Agilität und Menschen. Aus der anfänglichen Testerrolle ist eine spannende Karriere als Product Owner, Berater und Führungskraft entstanden, bevor sie 2020 Teil der Geschäftsführung bei der Bredex GmbH wurde.
Sie verbringt ihre Zeit in Kommunikation mit verschiedenen Menschen. Dazu gehört Wissensvermittlung durch Workshops und Coaching, Zusammenarbeit mit Entwicklern und Testern, Kundenberatung, Mitarbeiterentwicklung sowie strategische Themen mit anderen Führungskräften umzusetzen. Sie hält sich bei ihrem Lieblingsthemen auf dem Laufenden, indem sie weiterhin Kunden und Teams berät und unterstützt.
Alex spricht häufig auf Konferenzen als Speaker oder Keynote-Speaker über Agilität, Qualitätssicherung und Führung aus Sicht ihrer Erfahrung. In ihrer Freizeit ist sie leidenschaftliche Sportlerin, Musikerin und Tante. Sie beschreibt sich selbst als „explorer“ und liebt es, Orte, Kulturen, Perspektiven und Menschen zu entdecken.

Alex Schladebeck
Alex Schladebeck
flag VORTRAG MERKEN

Vortrag Teilen

17:45 - 18:45
Di 9.4
Infrastructure as Code – Betrieb ohne Handarbeit
Infrastructure as Code – Betrieb ohne Handarbeit

Mit Terraform, Ansible/Nixos und Continous Deployment per Knopfdruck zum Betrieb.

In diesem Vortrag betrachten wir Herausforderungen, die bei der Inbetriebnahme von Software aufkommen und setzen Infrastructure as Code mit Terraform, Ansible/NixOS und Continous Deployment beispielhaft um. Wir legen für ein Beispielprojekt live Infrastruktur an, konfigurieren diese und spielen die Software darauf. Bei allen Schritten gehen wir auf die Vorteile und die wenigen Nachteile von Infrastructure as Code ein.

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

Extended Abstract:
Mit Terraform, Ansible/Nixos und Continous Deployment per Knopfdruck zum Betrieb. Der Mehrwert jeder Software kann frühstens erlangt werden, wenn sie betrieben wird. In vielen Fällen ist das dann der Fall, wenn sie auf entsprechender Infrastruktur installiert und betriebsbereit ist. Dafür benötigen wir die Infrastruktur, müssen diese mit Betriebssystemen und nötigen Softwarekomponenten versehen und konfigurieren. Dies ist bei kleinen Systemen oft trivial, doch bei zunehmender Komplexität stellt sich schnell heraus, dass der Aufbau und die Wartung einer stabilen Infrastruktur schwierig ist.

Daher sollen alle nötigen Schritte automatisiert werden, nachvollziehbar sein und jederzeit reproduzierbar durchgeführt werden können. Dafür kommt Infrastructure as Code zum Einsatz. Alle nötigen Definitionen und nötigen Schritte werden mit Konfigurationsdateien, als Code oder mit Domain Specific Languages (DSL) zum eigentlichen Quellcode der Software festgehalten.

Mit Terraform wird die Infrastruktur an sich definiert. Dabei wird z. B. festgelegt, wie viele virtuelle Maschinen mit welchen Ressourcen benötigt werden, wie die Netzwerk- und IP-Konfiguration erfolgen oder in welchem Rechenzentrum die Software betrieben werden soll.

Sobald die Infrastruktur vorhanden und zugänglich ist, muss diese konfiguriert werden. Mit Ansible und NixOS gibt es zwei Ansätze jeden Installations- und Konfigurationsschritt zu definieren und automatisch zur Anwendung zu bringen.

Im Betrieb stellt man sich dann der nächsten Herausforderung: Software muss häufig und regelmäßig aktualisiert werden. Eine Automatisierung ist nahezu unumgänglich. Mit Continuous Deployment und als Code definierten Schritten in z. B. Github Actions gelangt die Software vollautomatisch auf die Infrastruktur.

In diesem Vortrag betrachten wir Herausforderungen, die bei der Inbetriebnahme von Software aufkommen und setzen Infrastructure as Code mit Terraform, Ansible/NixOS und Continous Deployment beispielhaft um.

Wir zeigen das Werkzeug Terraform, mit dem Infrastruktur providerabhängig definiert und einheitlich angewendet und erstellt werden kann. Mit Ansible oder NixOS stellen wir eine (oder beide) Möglichkeiten vor, das Betriebssystem eines Servers mit Quellcode und Konfigurationsdateien automatisiert zu konfigurieren.

Mit einem kurzen Einblick einer möglichen Continous Deployment Konfiguration in Github Actions zeigen wir eine weitere Möglichkeit, Code zu schreiben, anstatt händische Arbeit zu verrichten.

Bei allen Schritten gehen wir auf die Vorteile und die wenigen Nachteile von Infrastructure as Code ein. Ein größeres Augenmerk liegt auf der Dokumentationseigenschaft von Infrastuktur, die auf diese Weise definiert werden. Dies erspart viel weitere Arbeit im Betriebskonzept. Sofern zeitlich machbar wird im Vortrag live Infrastruktur angelegt, konfiguriert und eine Software darauf aufgespielt werden.

Tim Digel (Netze BW GmbH)
Seit 2010 Web Development, IT Operations
2007-2016 Uni Tübingen, Diplom Mathematik
2016-2021 Software developer for Active Group, functional programming (Elixir, Scala, F#, Scheme, ...)
Seit 2021 Software developer für Netze BW, functional programming with Elixir, IT Operations (Azure Cloud, Ansible, Terraform, CI/CD)

Tim Digel
Tim Digel
flag VORTRAG MERKEN

Vortrag Teilen

, (Mittwoch, 08.Februar 2023)
09:00 - 10:45
Mi 1.1
API Expand Contract – Was ist das und wie geht das?
API Expand Contract – Was ist das und wie geht das?

API Expand Contract ist ein Pattern zur Weiterentwicklung von APIs. Aber was verbirgt sich hinter der Idee? Wie kann ich damit eine API weiterentwickeln, ohne dass Client und/oder Server im Wartungsaufwand alter Schnittstellen(-Versionen) ersticken?

In der Realität erweist sich Management von APIs und deren Versionen als gar nicht so einfach. Diese Session zeigt mögliche Wege und Alternativen, um der Versionierungshölle zu entkommen und dabei das oberste Gebot beim API-Design - nämlich „Don’t break the Client“ - jederzeit einzuhalten.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen
Voraussetzungen: Kenntnisse in der API-Entwicklung, Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Der Thoughtworks-Technologie-Radar empfiehlt, das Pattern „Expand-Contract“ auf APIs anzuwenden.
Aber was verbirgt sich hinter der Idee?
Und wie kann ich das in der Praxis realisieren?

Wie kann ich sicherstellen, dass trotz Weiterentwicklung alle meine Clients weiterhin funktionieren und dennoch APIs unabhängig vom Server aktualisiert werden können - und das Ganze am besten ohne, dass Client und/oder Server im Wartungsaufwand alter Schnittstellen(-Versionen) ersticken?

Welche Versionierungsstrategie sollte ich in welcher Situation fahren und wie implementiere ich die verschiedenen Strategien geschickt?
In der Realität erweist sich Management von APIs und deren Versionen als gar nicht so einfach. Diese Session zeigt mögliche Wege und Alternativen, um der Versionierungshölle zu entkommen und dabei das oberste Gebot beim API-Design - nämlich „Don’t break the Client“ - jederzeit einzuhalten.

Arne Limburg ist Lead Architect bei der open knowledge GmbH in Oldenburg. Er verfügt über mehrjährige Erfahrung als Entwickler, Architekt und Trainer im Enterprise- und Microservices-Umfeld. Zu diesen Bereichen spricht er regelmäßig auf Konferenzen und führt Workshops durch. Darüber hinaus ist er im Open-Source-Bereich tätig, unter anderem als PMC Member von Apache Meecrowave, Apache OpenWebBeans und Apache DeltaSpike und als Urheber und Projektleiter von JPA Security.
 

Modulare Monolithe für Euren Architektur-Werkzeugkoffer
Modulare Monolithe für Euren Architektur-Werkzeugkoffer

Microservices sind der Hammer, aber nicht alles ist ein Nagel. Trotzdem ist man leicht in der Versuchung, immer diesen Hammer auszupacken, wenn man eine gut modularisierte Software-Architektur zimmern will. Genau das hatten wir mit unserem System auch vor. Wir erzählen euch die Geschichte, warum wir unsere erste Entscheidung revidiert und mit modularen Monolithen ein passenderes Architektur-Werkzeug für uns gefunden haben.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Grundlagen zu Architektur- und Designpatterns
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Woran lässt sich erkennen, ob das jeweilige Architekturproblem in die Kategorie „Nagel“ fällt oder nicht? Das kommt auf die Rahmenbedingungen an: Hat man die Domain schon so gut verstanden, dass die Modellgrenzen oder „Bounded Contexts“ klar sind? Ist es wichtig, einzelne Bausteine unabhängig ausrollen zu können? Wenn nicht, können Modulare Monolithe anstelle von Microservices zwei Vorteile bringen: Erstens verbinden sie ein einfaches Deployment mit einer fachlichen Modularisierung. Damit gewinnt man die Flexibilität, den Code einfach umzubauen. Zweitens spart man sich den Verwaltungs-Overhead von Microservices, ohne dabei den Weg zu einer stärkeren Trennung zu verbauen.

Das klingt attraktiv, aber der Teufel steckt im Detail. Wie stellt man sicher, dass die einzelnen Module getrennt bleiben und kein „Big Ball of Mud“ entsteht? Wie kann man auf der anderen Seite eine Kommunikation zwischen den Modulen erlauben, um fachliche Abhängigkeiten abzubilden?

Wir zeigen euch an unserem System, wie wir die Trennung der fachlichen Module, aber auch die Kommunikation zwischen ihnen umgesetzt haben, auf welche Probleme wir gestoßen sind, welche Lösungen wir gefunden haben und welche Kompromisse wir eingegangen sind.
Damit möchten wir euch einen Eindruck vermitteln, welche Herausforderungen wir mit dem Werkzeug „Modularer Monolith“ meistern konnten, damit ihr es ebenfalls in euren Architektur-Werkzeugkoffer aufnehmen könnt.

André Kappes ist seit 2015 Software Craftsman aus Leidenschaft. Auf seiner Suche, wie man handwerklich gute Software entwickelt, sammelt er immer wieder neue Erkenntnisse rund um Clean Code und Test-driven development, um Software-Architektur, Domain-Driven Design und Continuous Delivery. Zu seinem Glück hat er in jedem seiner bisherigen Projekte zuhauf spannende Fragen gefunden und neue Einsichten bekommen. Er begleitet derzeit ein internes Ausbildungsprojekt als technischer Coach.

Arne Limburg
André Kappes
André Kappes
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:30
Mi 2.1
Schluss mit Lustig – Was gute Führung wirklich braucht (Leadership Development 2.0)
Schluss mit Lustig – Was gute Führung wirklich braucht (Leadership Development 2.0)

Leadership benötigt es auf allen Ebenen moderner Organisationen. Alle Beteiligten sind auf ihren Positionen gefordert, situativ "richtig" zu führen. Führung darf und muss entsprechend verteilt und gefördert werden. Doch wen und was braucht es dafür? Leadership ist nichts, was man schnell in einem Wochenendkurs lernt. Die Aspekte sind dafür zu breit gefächert. In unserer Session breiten wir die Leadership-Landkarte aus und helfen den Teilnehmenden, im eigenen Kontext ihren Standort und weiteren Weg der Leadership-Entwicklung zu identifizieren.

Zielpublikum: Führungskräfte, Projektleiter:innen, Entscheider, Manager
Voraussetzungen: Führungserfahrung
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Leadership benötigt es auf allen Ebenen moderner Organisationen. Alle Beteiligten sind auf ihren Positionen gefordert, in der jeweiligen Situation "richtig" zu führen. Hier kommt es natürlich auch darauf an, Leadership "richtig" zu fördern und sie unter den Beteiligten zu verteilen. Das führt direkt zu der Frage, wen und was es dafür braucht.
Leider ist Leadership nichts, was man schnell in einem Wochenendkurs lernen kann. Die Aspekte von Leadership sind so breit gefächert, dass wir uns erst mal einen Überblick darüber verschaffen müssen, wie die Leadership-Landkarte aussieht und wo wir uns bereits darin befinden.

In unserer Session breiten wir gemeinsam die Leadership-Landkarte aus und helfen den Teilnehmenden im Kontext ihrer eigenen Leadership-Herausforderungen, den eigenen Standort und den weiteren Weg auf der Leadership-Reise zu identifizieren.

Learnings der Session:
* Leadership ist nichts, was man in einem Wochenendkurs lernen kann.
* Welche Aspekte hat Leadership?
* Wachstumsmöglichkeiten in der Leadership-Rolle
* Leadership in Practice (situative Anwendung der verschiedenen Führungsstile)
* Transfer auf die eigene Rolle und in die eigene Umgebung

Marc Bless ist seit vielen Jahren Agile Coach, Autor, Entwickler und Führungskraft. Als lösungsfokussierter Coach und Certified Enterprise Coach hilft er Organisationen auf ihrem Weg zur Business Agility.

Björn Jensen ist Certifed Scrum Trainer (CST) & Certified Team Coach (CTC). Seit den frühen 2000er Jahren ist er in agilen Kontexten unterwegs und begleitet Unternehmen seit 2008 in ihren Wandlungen.
Marc Bless, Björn Jensen
Marc Bless, Björn Jensen
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Mi 3.1
Beyond Taming Technical Debt
Beyond Taming Technical Debt

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/

Marijn Huizendveld – In a small backstreet of Tokyo lives a man named Aki, a 78 years old former chef. Aki spent most of his life trying to perfectly cook the rice he buys from his friend Mato. He's been at it for 57 years now, and still searches for ways to improve his cooking methods. There is probably not too much anybody else could tell Aki about cooking this specific type of rice. When it comes to his process, Aki's understanding is unrivaled.
After years of trial and error, Marijn Huizendveld could be called the Aki of Domain-Driven Design, due to his extensive background in both programming and strategy. He uses this experience to show teams and organizations how to recognize and act on problems and opportunities in an autonomous, self-learning fashion.

Maintenance and Evolution of Large Scale Software Systems – Business, Dev & Ops Challenges
Maintenance and Evolution of Large Scale Software Systems – Business, Dev & Ops Challenges

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

Martin Kropp is professor for Software Engineering at the University of Applied Sciences Northwestern Switzerland. His interest is in everything that makes software development more efficient, build automation, testing, refactoring and development methodologies.

As a software engineer, Janick Rüegger worked in different teams from web development to platform engineering. In his master’s degree, he focuses on the challenges of large-scale software development.

Marijn Huizendveld
Martin Kropp, Janick Rüegger, Andreas Meier
Marijn Huizendveld

Vortrag Teilen

Martin Kropp, Janick Rüegger, Andreas Meier
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Mi 4.1
Integrationsarchitekturen auf Basis von Microservices, APIs und Events
Integrationsarchitekturen auf Basis von Microservices, APIs und Events

Integration war und ist immer noch relevant - vielleicht mehr denn je. Insbesondere, wenn wir über Anwendungsmodernisierung sprechen. In Zeiten von Cloud- und Microservice-Architekturen müssen wir neu darüber nachdenken, wie wir Integrationsherausforderungen bewältigen können. Klassische ESB-Lösungen sind meist veraltet - was aber ist die Alternative?
Anhand der Erfahrungswerte aus unserem eigenen IT-Modernisierungsprojektes, werde ich vorstellen, wie Integrationsherausforderungen heute mit Hilfe moderner Technologien adressiert werden können.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Cloud, Integration, API, Events
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Integration ist ein wichtiges Thema. In jedem Modernisierungsprojekt existieren entsprechende Herausforderungen, die nach einer entsprechenden Integrationsstrategie verlangen.
In der Regel starten wir ja nicht auf der grünen Wiese, sondern müssen die alte und neue Welt zusammenbringen. Auch ein Monolith kann nicht im Rahmen eines Big Bang Ansatzes einfach mal eben so abgelöst werden.

Im Kontext des Vortrages werde ich von unserem eigenen IT Modernisierungsprojekt berichten, im Kontext dessen wir einen über 30 Jahre gewachsenen Oracle Forms Monolithen in einem inkrementellen Vorgehen ablösen und durch SaaS-Lösungen ersetzen wollen. Die Integration zwischen alter und neuer Welt erfolgt basierend auf modernen Technologiekonzepten wie Containern, API Gateway, Service Mesh und Event Hub mit Kubernetes als zentrale Runtime Plattform.
Dies ermöglicht uns perspektivisch mehr Flexibilität und Agilität sowie eine Steigerung der Developer Productivity durch die Verwendung entsprechender Konzepte und Technologien sowie eine hochgradige Automatisierung im Kontext der Applikationsbereitstellung.

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

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

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

Die Welt der operativen, transaktionalen Systeme und der analytischen Systeme ist seit jeher getrennt. Unterschiedliche SW-Entwicklungsparadigmen, andere Technologien, andere Datenmodelle, usw. prägen die jeweiligen Systeme. Statt Silos zu bauen, geht es darum, eine Balance zu finden zwischen Dev und Data: DevDataOps? Wie können Data Mesh und Data Lakehouse dazu beitragen?

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

Extended Abstract:
Die Welt der operativen, transaktionalen Systeme und der analytischen Systeme ist seit jeher getrennt. Unterschiedliche SW-Entwicklungsparadigmen, andere Technologien, andere Datenmodelle, usw. prägen die jeweiligen Systeme. Statt Silos zu bauen, geht es darum, eine Balance zu finden zwischen Dev und Data: DevDataOps? Wie können Data Mesh und Data Lakehouse dazu beitragen?

Data Mesh ist ein Ansatz, der mit Prinzipien wie domänengetriebener Entwicklung, Produktorientierung oder Self-Service Infrastruktur die Welten verschmelzen möchte. Beim Data Lakehouse stehen dagegen technische Eigenschaften im Mittelpunkt der Veränderungen gegenüber gängigen Architekturen. DevDataOps wird von beiden Architekturen unterstützt – die Gewichtung ist jedoch grundverschieden. Auch die Anforderungen an die Umsetzung sind unterschiedlich: Data Mesh führt beispielsweise organisatorische Änderungen nach sich. Im Vortrag werden solche Fragestellungen anhand praktischer Erfahrungen vertieft.

 

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

Sven Bernhardt
Andreas Buckenhofer
Sven Bernhardt

Vortrag Teilen

Andreas Buckenhofer
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Mi 5.1
Code Wars: Bringing Balance to the Design Force
Code Wars: Bringing Balance to the Design Force

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

Kevlin Henney is an independent consultant, speaker, writer and trainer. His development interests are in programming, practice and people. He is co-author of two volumes in the ”Pattern-Oriented Software Architecture” series, and editor and contributor for multiple books in the ”97 Things” series. He lives in Bristol and online.

Frank Buschmann ist Senior Principal Engineer bei Siemens Corporate Technology in München. Dort erforscht er moderne Software-Architektur und Entwicklungsansätze für die industrielle Digitalisierung. Die Produktentwicklung unterstützt Frank bei der effizienten Anwendung dieser Technologien. Seine aktuellen Forschungsschwerpunkte sind Architekturen für Cyber-Physikalische Systeme, das Internet of Things, Intelligente Systeme sowie industrielles DevOps. Frank ist Co-Autor von vier Bänden der von John Wiley & Sons veröffentlichten 'Pattern-Oriented Software Architecture'.
A Commune in the Ivory Tower? – A New Approach to Architecture
A Commune in the Ivory Tower? – A New Approach to Architecture

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).

A highly enthusiastic, self-starting and responsible Tech Principal; Andrew Harmel-Law specialises in Java / JVM technologies, agile delivery, build tools and automation, and domain-driven design.
Experienced across the software development lifecycle and in many sectors including government, banking, and eCommerce, what motivates him is the production of large-scale software solutions, fulfilling complex client requirements. He understands that people, tooling, architecture and process all have key roles to play in achieving this.
Andrew has a passion for open-source software and its communities. He has been interested in and involved with OSS to a greater or lesser extent since his career began, as a user, contributor, expert group member, or paid advocate.
Finally, Andrew enjoys sharing his experience as much as possible. This sharing is not only seen in his formal consulting engagements, but also informally through mentoring, blog posts, conferences (speaking and organising), and open sourcing his code.

Kevlin Henney, Frank Buschmann
Andrew Harmel-Law
Kevlin Henney, Frank Buschmann

Vortrag Teilen

Andrew Harmel-Law
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Mi 6.1
Kleiner Wanderführer für IT-Systeme
Kleiner Wanderführer für IT-Systeme

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?

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

Balancing Legacy and Innovation: Taking your IBM Mainframe on the Modernization Journey
Balancing Legacy and Innovation: Taking your IBM Mainframe on the Modernization Journey

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.

Firas Al-Shawi is passionate about software modernization and always has the focus to keep softwares future-proof. He is Senior Consultant and Productmanager working for EasiRun Europa GmbH.

Julie Dumortier is a lifelong entrepreneur with a passion to ‘Simply solve complex problems'. She is President of Metrixware Systemobjects, the French ISV specialized in mainframe modernization.

Bernd Rederlechner
Firas Al-Shawi, Julie Dumortier
Firas Al-Shawi, Julie Dumortier
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Mi 7.1
The Sustainability Mythbuster
The Sustainability Mythbuster

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

Martin Lippert is Spring Tools Lead and Sustainability Ambassador @ VMware.

Applying Green Software in the Real World
Applying Green Software in the Real World

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.

Jochen Joswig studied Computer Science at the Friedrich-Schiller-Universität Jena (B.Sc.) and Universität Hamburg (M.Sc.). Since then, he has been especially interested in developing ESG and CSR software. He sees great potential in the cloud, when creating software solutions that provide added value, are satisfying to use and are eco-friendly, all at the same time. Jochen Joswig works as software engineer at MaibornWolff and is doing research in Green Information and communication technology (ICT).

Martin Lippert
Jochen Joswig
Jochen Joswig
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:30
Mi 8.1
3 Amigos und die Entwicklung eines Produkts (BDD)
3 Amigos und die Entwicklung eines Produkts (BDD)

Dieses Problem kennen wir alle: In Projekten führt eine unzureichende Kommunikation oft dazu, dass die Software am Ende nicht so umgesetzt ist, wie die Auftraggebenden es sich am Anfang vorgestellt hatten.
Behaviour-Driven Development (BDD) setzt von Anfang an darauf, alle Stakeholder an einen Tisch zu holen und ein gemeinsames Verständnis über das gewünschte Verhalten der Software herzustellen. Daraus entsteht eine ausführbare Spezifikation, die zum richtigen Produkt nebenbei noch automatisierte Tests und eine lebendige Dokumentation liefert.

Zielpublikum: Product Owner, Entwickler:innen, Tester, Business-Analysten
Voraussetzungen: Grundkenntnisse in Java
Schwierigkeitsgrad: Anfänger

Extended Abstract:
SZENARIO: OOP Konferenz 2023

ANGENOMMEN DASS du wenig über BDD weißt
WENN du zu diesem Vortrag kommst
DANN lernst du das Grundprinzip kennen
ANGENOMMEN DASS du BDD bisher als Testmethode nutzt
WENN du zu diesem Vortrag kommst
DANN siehst du, dass noch viel mehr dahintersteckt

Behaviour-Driven Development ist ganz sicher keine neue, aber eine häufig missverstandene Methode. In vielen Teams wird BDD nur zum Testen eingesetzt. In diesem Talk gehen wir einmal gemeinsam den Weg von der ersten Beschreibung der Software bis zur Umsetzung im Code, um zu erkennen, dass der Fokus von BDD auf der Kommunikation zwischen allen an der Entwicklung Beteiligten liegt.

Katrin Rabow hat viele Jahre als selbstständige Beraterin kleine Unternehmen in ihrem kaufmännischen Alltag unterstützt, ehe sie sich 2015 für ein Studium der Wirtschaftsinformatik an der TU Darmstadt entschied. Sie sucht immer wieder nach Wegen, „harte“ Themen wie Software-Engineering mit „weichen“ Themen wie der Unternehmenskultur zu verbinden. Seit ihrem Masterabschluss arbeitet sie als IT-Consultant in Frankfurt.

Katrin Rabow
Katrin Rabow
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:30
Mi 9.1
Scenario Casting – Agility Starts in DDD's Problem Space!
Scenario Casting – Agility Starts in DDD's Problem Space!

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!

Jörn Koch is an agile and DDD coach and trainer. He worked many years as a developer and architect. Jörn loves ambitious projects in highly collaborative environments. He has practical experience as an agile coach for 15 years, and as a DDD coach for 6 years.

Jörn Koch
Jörn Koch
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Mi 1.2
Your APIs on Steroids: Retrofitting GraphQL by Code, Cloud-native or Serverless
Your APIs on Steroids: Retrofitting GraphQL by Code, Cloud-native or Serverless

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.

Sonja Wegner is Lead Software Architect at QAware. Her current focus is on design and implementation of complex systems and software architectures.

Stefan Schmöller is Senior Software Engineer at QAware. He is mainly interested in Java frameworks and microservice architectures.

Sonja Wegner, Stefan Schmöller
Sonja Wegner, Stefan Schmöller
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Mi 2.2
Introversion / Extraversion – Warum Führung die Balance finden muss
Introversion / Extraversion – Warum Führung die Balance finden muss

“Wenn wir davon ausgehen, dass stille und laute Menschen in etwa dieselbe Anzahl an guten Ideen haben, dann sollte der Gedanke, dass nur die lauteren Menschen sich durchsetzen, uns besorgt aufhorchen lassen.“ (Susan Cain)

Missverständnisse und Vorurteile ranken sich um die scheinbaren Gegensätze von Introvertierten und Extrovertierten.
Dabei bringen beide Seiten unterschiedliche Stärken, aber auch Bedürfnisse ein. Es ist die Aufgabe von Führung, eine Balance zwischen beiden Polen zu schaffen, um das volle Potenzial ihrer Mitarbeiter zu nutzen.

Zielpublikum: Führungskräfte, Scrum Master, Projektleiter:innen, Agile Coaches, Manager, Personaler
Voraussetzungen: Offenheit, Neugier, Reflexionsfähigkeit
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Die Teilnehmer:innen lernen ...
•    die unterschiedlichen Stärken, Fähigkeiten und Bedürfnisse von eher introvertierten und eher extrovertierten Menschen kennen
•    sich selbst zu führen durch ein besseres (Selbst-)Verständnis dieser zentralen Persönlichkeitsmerkmale
•    wie sie ein Umfeld schaffen können, in dem sich intro- und extravertierte Menschen gleichermaßen wohlfühlen, effektiv arbeiten und sich gegenseitig inspirieren können
•    wie Führung dazu beitragen kann, eine neue Balance zu schaffen, um das volle Potenzial ihrer Mitarbeiter zu nutzen
•    was dies ganz konkret bedeutet in Bezug auf Teamarbeit, Büro-Räumlichkeiten, Führung und Selbstführung

Als leidenschaftlicher Feuerkünstler jongliert Till Weinert regelmäßig mit brennenden Gegenständen. Und das nicht im übertragenen Sinne – sondern wortwörtlich.
Da ist Aufmerksamkeit gefragt, damit man sich nicht verbrennt – und nichts anbrennen lässt. Im Arbeitsalltag sieht das nicht anders aus: In einer immer schneller und komplexer werdenden Welt sind wir gezwungen, zahlreiche Bälle in der Luft zu halten.
Als Agile Leader ist er in genau solchen Arbeitsumgebungen unterwegs. Mit viel Kreativität, Geschick und Erfahrung erforscht Till Weinert gemeinsam mit seinen Teams, wie sie mit solchen Situationen umgehen können.
Denn genauso wie beim Jonglieren macht es erst richtig Spaß, wenn wir uns im Team die Bälle zuwerfen – und keiner runterfällt.

Till Weinert
Till Weinert
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Mi 3.2
Raus aus der Wartungshölle ... zumindest ein bisschen
Raus aus der Wartungshölle ... zumindest ein bisschen

Irgendwann trifft es mal jeden. Anwendungen veralten automatisch, egal, ob ein oder zehn Jahre alt, ob sie "fertig" entwickelt sind oder nicht. Die Gründe sind vielschichtig: Die Programmiersprache entwickelt sich weiter, Bibliotheken brauchen ein Update, Good Practices entwickeln sich weiter. Diese Wartungsarbeiten werden nicht gerne gemacht, da sie scheinbar unnötige Aufwände erzeugen und zum Teil recht stupide sind. Ignoriert die Entwicklerin sie, dann sammelt sie automatisch technische Schulden und die Aufwände sind in der Zukunft höher.

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

Extended Abstract:
Irgendwann trifft es mal jeden. Anwendungen veralten automatisch, egal, ob ein oder zehn Jahre alt, ob sie "fertig" entwickelt sind oder nicht. Die Gründe sind vielschichtig: Die Programmiersprache entwickelt sich weiter, Bibliotheken brauchen ein Update, Good Practices entwickeln sich weiter. Diese Wartungsarbeiten werden nicht gerne gemacht, da sie scheinbar unnötige Aufwände erzeugen und zum Teil recht stupide sind. Ignoriert die Entwicklerin sie, dann sammelt sie automatisch technische Schulden und die Aufwände sind in der Zukunft höher und bei Sicherheitslücken schmerzhafter.

Dieser Vortrag zeigt, was alles unter Wartungsarbeiten zu verstehen ist und in welche Probleme Unternehmen laufen können, wenn sie es unterlassen. Außerdem stellt es Vorgehensweise und Werkzeuge vor, die bei Wartungsarbeiten helfen können und somit zumindest den stupiden Teil reduzieren.

Sandra Parsick ist Java Champion und arbeitet als freiberufliche Software-Entwicklerin und Consultant im Java-Umfeld. Seit 2008 beschäftigt sie sich mit agiler Softwareentwicklung in verschiedenen Rollen. Ihre Schwerpunkte liegen im Bereich der Java Enterprise-Anwendungen, Cloud, Software Craftsmanship und in der Automatisierung von Softwareentwicklungsprozessen. Darüber schreibt sie gerne Artikel und spricht auf Konferenzen. In ihrer Freizeit engagiert sich Sandra Parsick in verschiedenen Programmkomitees und Community-Gruppen.

Sandra Parsick
Sandra Parsick
flag VORTRAG MERKEN

Vortrag Teilen

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

Die Zertifizierung von Energie aus erneuerbaren Quellen in Europa weist Mängel auf. Wir stellen die Architektur einer Anwendung für Herkunftsnachweise mit einem reaktiven System und einer vertrauenswürdigen Buchführung vor. Sie ist in der Lage, das heutige Verfahren aus Sicht von Endkunde und Energielieferant durch eine zeitnahe Zuordnung von erzeugter und verbrauchter Energie sowie durch Nachvollziehbarkeit maßgeblich zu verbessern. Unser Vorschlag fügt sich in das aktuelle System ein und hat das Potenzial, dieses mittelfristig zu ersetzen.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Interesse an heterogenen Software-Architekturen und vertrauenswürdigen Systemen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Heutzutage legen Kunden großen Wert auf elektrische Energie, die aus erneuerbaren Quellen stammt. Sie sind bereit, dafür einen höheren Preis zu bezahlen, erwarten aber im Gegenzug einen vertrauenswürdigen Herkunftsnachweis. Vertrauenswürdig bedeutet hier, dass der Weg vom Produzenten zum Konsumenten von elektrischer Energie lückenlos transparent aufgezeichnet wird, eine doppelte Zuordnung unmöglich ist und die Buchführung jederzeit überprüfbar ist.

Gemäß europäischem Regelwerk können Herkunftsnachweise in einem Zeitfenster von einem ganzen Jahr nach der Erzeugung entwertet werden. So kann beispielsweise im Winter um Mitternacht erzeugter Strom aus Wärmekraftwerken zusammen mit einem im vorhergehenden Sommer um die Mittagszeit erzeugten Solarstromzertifikat als Ökostrom verkauft werden.
Herkunftsnachweise können sogar unabhängig von der Energielieferung gehandelt werden, wodurch es möglich wird, dass Nachweise für Energie aus Wasserkraft in Island in Deutschland entwertet werden, obwohl keine Möglichkeit zum Energieaustausch besteht. In der Schweiz und in Europa gibt es Vorstöße, die «mehr Transparenz bei der Stromherkunft» fordern.

Wir messen den Verbrauch und die Erzeugung von elektrischer Energie mit geeichten und plombierten «intelligenten» Zählern, die digital signierte Messergebnisse liefern. Die Anwendung empfängt diese Messwerte und legt diese unveränderbar als Erzeugungs- oder Verbrauchs-Datensatz ab. Anschließend ordnet der Matcher dem Verbrauchs-Datensatz die entsprechende Menge an nachhaltig erzeugter Energie zu. Damit wird der Herkunftsnachweis erbracht. Der Erzeugungs- und Verbrauchs-Zeitpunkt darf maximal 15 Minuten auseinanderliegen, damit Erzeugung und Verbrauch einander zugeordnet werden können. Andernfalls erfolgt keine Zuordnung, der Herkunftsnachweis kann nicht erbracht werden.

Ausgehend von der Problemanalyse leiten wir mögliche Geschäftsmodelle und Anforderungen an eine Lösung ab. Wir stellen verschiedene Varianten vor und begründen unsere Wahl. Wir erläutern außerdem, wie wir das System konzipiert haben, damit es robust ist, nachweislich eine korrekte Buchführung gewährleistet und gleichzeitig einen hohen Durchsatz ermöglicht.
Zusätzlich zu den digital signierten Messwerten muss die Vertrauenswürdigkeit der gesamten Kette von Systemkomponenten und Technologien nachgewiesen werden. Dies umfasst sowohl technische Aspekte wie verifizierbare Datenhaltung als auch organisatorische Aspekte wie Vertrauen zwischen Geschäftspartnern.

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

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

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

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

Vortrag Teilen

11:00 - 11:45
Mi 5.2
Cloud Chaos and Microservices Mayhem
Cloud Chaos and Microservices Mayhem

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.

Holly Cummins is a Senior Principal Software Engineer on the Red Hat Quarkus team. Before joining Red Hat, Holly was a long time IBMer, in a range of roles from cloud consultant, full-stack javascript developer, WebSphere Liberty build architect, JVM performance engineer, to innovation leader. Holly is also a Java Champion, author, and regular keynote speaker. You can follow her on twitter at @holly_cummins or at hollycummins.com.

Holly Cummins
Holly Cummins
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Mi 6.2
Modern Product Leadership – Solution-Focused Coaching Skills as Enabler for High Performance
Modern Product Leadership – Solution-Focused Coaching Skills as Enabler for High Performance

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.

The one thing that Alexander Angelo Giurca enjoys most is when he sees that he can support individuals or teams to get one step further. He has done this since he started his professional career. His begin was building up a boutique consultancy focusing on unconventional business modelling and change formats for big corporations (mostly management teams) which helped them one step towards more innovation. Then he was in a consultant role focusing on executives, supporting them in product development. Now he is Product Owner at Untis GmbH for a 5 mio. users software that enables schools to run smoothly. And when he comes to OOP, he is in the solution-focused consultancy team at sinnvollFÜHREN GmbH. He also supports other product companies and leaders as a solution-focused coach and sparring partner and run Training from the BACK of the Room workshops as a certified trainer. He is really passionate about what he does and always very excited to share his knowhow!

Alexander Angelo Giurca
Alexander Angelo Giurca
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Mi 7.2
Climate Bookkeeping – Making a Big Impact with a Small Team
Climate Bookkeeping – Making a Big Impact with a Small Team

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: Basic technical knowledge helps - there will be system design diagrams and tech buzzwords
Level: Basic

Extended Abstract:
Fighting the climate crisis is urgent today and it will continue to be urgent for years and years to come. That means we must approach the fight at a sustainable pace to keep on working for a better future for a long time.

GoClimate is a company founded for the sole purpose of stopping climate change, but also with the ambition of creating a healthy organization with the resilience to withstand the challenges of today and tomorrow. But is it possible to have an impact on such a huge problem with a team of only 10 people and no overtime?

Using GoClimate’s endeavors to scale climate consciousness in small businesses as an example, we’ll explore the topic of working for sustainability in a sustainable way: the constraints, the workarounds, the dead ends and the liberation of rethinking what a company needs to be.

Since many years Pia Fåk Sunnanbo is a software engineer with experience from a wide range of languages, environments and domains. She loves deleting code and using the simplest tools possible. Fascinated how humans create technology and technology changes human behavior and lives. She holds a firm belief that software engineering knowledge is a huge power in today's society. It's our responsibility to use it for good. Works full time to stop climate change.

Pia Linnea Fåk Sunnanbo
Pia Linnea Fåk Sunnanbo
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Mi 8.2
Warum ist Code so schwer zu verstehen?
Warum ist Code so schwer zu verstehen?

Wann ist Code verständlich?

Wenn die Methoden kurz sind, wenn sprechende Namen verwendet werden, wenn ... diese Liste ist lang und zumindest in Auszügen bekannt. Verständlichkeit wird meist mit Faustregeln und Code-Smells beschrieben.
Wir möchten hier anders ansetzen: Verständlichkeit entsteht im Gehirn. Leicht verständlich bedeutet, dass das Gehirn gefordert wird, schwer verständlich, dass es überfordert wird.

Zielpublikum: Entwickler:innen, Architekt:innen, alle, die es interessiert
Voraussetzungen: Programmiersprachenkenntnisse (nur für die Beispiele)
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Wir erarbeiten gemeinsam anhand eines Modells den Verständnisprozess, lernen wo unser Verständnis an seine Grenzen stößt, und demonstrieren Erkenntnisse an anschaulichen Code-Beispielen.
Interessant für jeden, der sich nicht nur für Code-Smells und Code-Konventionen interessiert, sondern auch gerne ein Blick auf das "Warum" wirft.

Stefan Mandel ist Full-Stack-Entwickler bei andrena objects und beschäftigt sich seit fast 20 Jahren mit Programmiersprachen, Prinzipien und Refactoring.

Als studierter Mathematiker findet Peter Guntermann eigentlich großen Gefallen daran, sich das Hirn über kniffligen Problemen zu zermartern. Doch wenn es darum geht, robuste und leicht wartbare Software zu entwickeln, hält er es am liebsten so simpel und gehirngerecht wie möglich. Clean Code und Domain-driven Design sind hierbei seine wichtigsten Begleiter, um die Herausforderungen im agilen Alltag zu bewältigen.

Stefan Mandel, Peter Guntermann
Stefan Mandel, Peter Guntermann
Vortrag: Mi 8.2
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Mi 9.2
DDD-Projekte profitieren von funktionaler Architektur
DDD-Projekte profitieren von funktionaler Architektur

Funktionale Programmier:innen empfehlen meist "FP-first". Dieser puristische Ansatz passt leider nicht zu den Realitäten existierender Projekte, die objektorientiert auf DDD aufsetzen. Schade, weil diese Projekte von funktionalen Techniken profitieren können.
Der Vortrag beschreibt eine Kooperation zwischen Blume2000 (fest in OO-Hand) und der Active Group (alles FP-Puristen), um Probleme in einer hexagonalen DDD-Architektur (implementiert in Kotlin) mit funktionalen Techniken zu lösen.

Zielpublikum: Entwickler:innen, Architekt:innen
Voraussetzungen: OO-Grundkenntnisse
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Dazu gehören:
- Validierung mit applikativen Funktoren
- freie Monaden, um die Domäne von den Ports zu trennen
- funktionale Dependency Injection, auch mit Monaden

Wir zeigen, wie wir's gemacht haben - und wie auch andere Projekte von funktionaler Programmierung profitieren können.
Das alles harmoniert wunderbar mit dem Kotlin/Spring-Boot-Kontext des Projekts.

Es gab aber durchaus auch Reibungspunkte: Die strikte Domänen-/Technik-Separierung des hexagonalen Modells hilft Entwickler:innen, sich zurechtzufinden - funktionale Programmierer:innen benutzen normalerweise feingranularere Abstraktionen im Rahmen der Functional-Core/Imperative-Shell-Architektur. Entsprechend präsentieren haben wir auch einige Vorschläge, wie Spring Boot verbessert werden könnte, um diesen Ansatz besser zu unterstützen.

Michael Sperber is CEO of Active Group in Tübingen, Germany. Mike specializes in functional programming and has been an internationally recognized expert in the field: He has spoken at the top conferences in programming languages, authored many papers on the subject as well as several books. Moreover, he is an expert on teaching programming.

Benedikt Stemmildt ist CIO von Blume2000. Er ist leidenschaftlicher Software-Architekt, Full-Stack-Entwickler und Speaker mit Begeisterung für Technologie, Architektur und Organisation.

Michael Sperber, Benedikt Stemmildt
Michael Sperber, Benedikt Stemmildt
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Mi 1.3
The Architecture Hamburger – Software Achitecture for the Golden 20s
The Architecture Hamburger – Software Achitecture for the Golden 20s

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

Henning Schwentner loves programming in high quality. He lives this passion as coder, coach, and consultant at WPS – Workplace Solutions in Hamburg, Germany. There he helps teams to structure their monoliths or to build new systems from the beginning with a sustainable architecture. Microservices or self-contained systems are often the result. Henning is author of “Domain Storytelling – A Collaborative Modeling Method” and the www.LeasingNinja.io as well as translator of “Domain-Driven Design kompakt”.

Henning Schwentner
Henning Schwentner
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Mi 2.3
Der kleine (Selbst-)Führungswerkzeugkasten und die Praxis
Der kleine (Selbst-)Führungswerkzeugkasten und die Praxis

Die Bettdecke ist immer zu kurz und es macht einen Unterschied, bewusst zu entscheiden, welcher Zeh gerade herausschaut. Nach mehrjähriger Erfahrung in Leitungsfunktionen und in der Zusammenarbeit mit Führungskräften ist das unser Eindruck der Führungsherausforderungen und eines hilfreichen Umgangs damit. In diesem interaktiven Vortrag geben wir Einblicke in Haltungen und Werkzeuge, die uns und unseren Kunden im Alltag helfen, wirkungsvoll zu sein. Wir machen ausgewählte Werkzeuge erlebbar und hoffen auf neue Impulse und ergänzende Blickwinkel.

Zielpublikum: Menschen mit impliziter und expliziter Führungsverantwortung
Voraussetzungen: Neugierde, Offenheit für Selbstreflexion
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
In einer Führungsrolle ist es einfach, in Arbeit unterzugehen. Diese Situation wird nicht besser, wenn man versucht, der eigenen Erwartungshaltung gerecht zu werden und pflichtbewusst das stetig wachsende Aufgabenspektrum zu bewältigen. Ohne Weitblick und Reflexion ist das effiziente Verrennen vorprogrammiert und kann je nach Führungs- oder Verantwortungsspanne dem eigenen Unternehmen ziemlich teuer kommen. Dies gilt gleichermaßen in unserer eigenen Organisation als auch bei unseren Kunden. Dort nehmen wir Führung auch aus der Außenperspektive wahr und geben Impulse, um Erwartungen an Führung und Führungsverhalten sichtbar zu machen und zusammenzubringen.

Irene versucht, Menschen Strukturen zu bieten, um sich so einzubringen, wie sie es gerne möchten. In der Arbeit mit Führungskräften und an sich selbst haben sich einige Werkzeuge herausgeprägt, die sie häufig nutzt.
Maximilian hilft eine Vorstellung von Führung, eine Haltung Menschen gegenüber ergänzt mit ein paar Werkzeugen, auf die er ohne viel nachzudenken - quasi nach Schema F, wenn eben keine Zeit zu Reflexion bleibt - zurückgreift, um in der eigenen Rolle in der Standortleitung wirksam zu sein.

Wir stellen aus unseren unterschiedlichen Perspektiven Herausforderungen und unsere Werkzeuge gegenüber und probieren sie mit den Teilnehmern aus, um sie gemeinsam zu reflektieren.

Maximilian Aulinger begleitet Entwicklungsteams mit einem Augenzwinkern und einer Prise Lösungsfokus. Die kontinuierliche Verbesserung trägt er auch in seine Arbeit in der Münchner Standortleitung von andrena.

Irene Kuhn ist Scrum Masterin mit Leidenschaft für das Coaching. Neugier, Potenziale erkennen und Raum und Struktur geben, sodass sie sich entwickeln können, sind ihr Markenzeichen.

Maximilian Aulinger, Irene Kuhn
Maximilian Aulinger, Irene Kuhn
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Mi 3.3
Continuous Discovery am Beispiel der SPIEL.digital
Continuous Discovery am Beispiel der SPIEL.digital

In der Produktentwicklung unterscheidet man zwischen Discovery („Identifizieren von Features“) und Delivery („Umsetzen von Features“). Im Gegensatz zum Wasserfall findet die Discovery nicht am Anfang, sondern kontinuierlich statt. Wie wechselt man regelmäßig zwischen Discovery und Delivery und verfällt nicht wieder in den Wasserfall? Ich berichte anhand der Umsetzung der SPIEL.digital aus der Praxis, mit welchen Methoden wir Discovery, Design und Entwicklung verzahnt haben.

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

Extended Abstract:
In der agilen Produktentwicklung unterscheidet man zwischen Discovery („Identifizieren von Features“) und Delivery („Umsetzen von Features“). Im Gegensatz zum Wasserfall findet die Discovery nicht am Anfang, sondern kontinuierlich statt. Wie aber geht man damit um, regelmäßig die Flughöhe zwischen Discovery und Delivery zu wechseln und nicht in dieselben Muster wie in der Analysephase des Wasserfalls zu verfallen? Ich berichte anhand der Umsetzung der SPIEL.digital aus der Praxis, mit welchen Methoden wir Discovery, Design und Entwicklung verzahnt haben. Und das alles bei einem festen Endtermin.

Konstantin Diener ist CTO bei cosee. Er ist leidenschaftlicher Software-Entwickler und brennt für Clean Code und Test-Driven Development. Als CTO kümmert er sich mittlerweile mehr um die Rahmenbedingungen für cross-funktionale Entwicklungsteams. Er spricht regelmäßig auf Konferenzen und war Autor der Kolumne "DevOps Stories" im Java Magazin, die sich mit Agilität, DevOps & New Work befasst.

Konstantin Diener
Konstantin Diener
Vortrag: Mi 3.3
flag VORTRAG MERKEN

Vortrag Teilen

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

Wir entwickeln heute Software nicht mehr auf der grünen Wiese, sondern wir erweitern und verändern vorhandene Systeme. Dabei wird der Code immer komplexer und sammelt technische Schulden an. Im Entwicklungsteam ist uns das allen klar, aber wie erklären wir dem Management, dass es sinnvoll ist, frühzeitig technische Schulden abzubauen?

In diesem Vortrag berichte ich von meiner Erfahrung aus verschiedensten Kontexten und gebe Empfehlungen, wie die Kommunikationsbarriere zwischen Management und Entwicklungsteams übersprungen werden kann.

Zielpublikum: Architekt:innen, Entwickler:innen, Product Owner, Projektleiter:innen, IT-Management
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Anfänger

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

Carola Lilienthal
Carola Lilienthal
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Mi 5.3
Can High Performing Software Solve the Climate Crisis?
Can High Performing Software Solve the Climate Crisis?

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.

Sara Bergman is a Senior Software Engineer at Microsoft Development Center Norway working in a team which owns several backend APIs powering people experiences in the Microsoft eco-system. She is an advocate for green software practices at MDCN and M365. She is a member of the Green Software Foundation and the chair of the Writer's project which is curating and creating written articles on the main GSF website and the GSF newsletter.

Sara Bergman
Sara Bergman
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Mi 6.3
Wirklich wirkungsvolle Produkte entwickeln mit Business Stories
Wirklich wirkungsvolle Produkte entwickeln mit Business Stories

Häufig liegt unser Fokus bei der Entwicklung auf Ergebnissen. Wir betrachten Produktinkremente und bewerten die Geschwindigkeit des Teams. Dabei vergessen wir oft, dass die Ergebnisse Wirkung für alle erzielen sollen, die Interesse am Produkt haben.
Business Stories richten unsere Aufmerksamkeit auf Wirkung und helfen uns, diese zu formulieren. Um frühzeitig eine Wirkung zu erzielen, lassen sich Business Stories ähnlich wie Epics und User Stories klein schneiden. So können wir die Wertschöpfung optimieren und früh Feedback zur Wirkung erhalten.

Zielpublikum: Product Owner, Produktmanager, Projektleiter:innen, Requirements Engineers, Business Analysten
Voraussetzungen: Die Teilnehmer sollten agile Vorkenntnisse haben und mind. die Scrum-Nomenklatur kennen
Schwierigkeitsgrad: Anfänger

Extended Abstract:
In agilen und nicht-agilen Entwicklungen liegt unser Fokus nach wie vor auf Ergebnissen. Wir betrachten Produktinkremente, bewerten die Geschwindigkeit / Velocity des Teams und zählen die Anzahl der Features. Dabei vergessen wir allzu oft, dass die Ergebnisse am Ende wertvoll sein müssen. Sie sollen Wirkung für alle erzielen, die irgendein Interesse am Produkt haben.

Die bekannten Artefakte wie Epics und User Stories konzentrieren sich auf die Ergebnisse. Business Stories hingegen richten unsere Aufmerksamkeit auf Wirkung und helfen uns, diese zu formulieren. Um frühzeitig eine Wirkung zu erzielen, lassen sich Business Stories ähnlich wie Epics und User Stories klein schneiden. So können wir die Wertschöpfung optimieren und früh echtes Feedback zur Wirkung erhalten.

Take aways:
1. Planung sollte sich immer an den Wirkungen für Kunden und das eigene Unternehmen ausrichten (und nicht am Ergebnis/Produkt).
2. Die so entstandenen Business Stories lassen sich so zerlegen, dass kleinere Business Stories entstehen und früher Wert geschaffen wird.
3. Business Stories brauchen i.d.R. bereichsübergreifendes Arbeiten.

Stefan Roock (it-agile) hilft Unternehmen, Führungskräften und Teams dabei, ihre Potenziale zu entfalten - hin zu erfolgreichen Unternehmen, die ihre Kunden und Mitarbeiter begeistern. Er ist davon überzeugt, dass dazu strukturelle, personelle und interpersonelle Themen im Zusammenspiel adressiert werden müssen.
Stefan Roock hat seit 1999 agile Ansätze in Deutschland maßgeblich mit verbreitet und weiterentwickelt. Zunächst hat er als Entwickler in agilen Teams, später als Scrum Master/Agile Coach und Product Owner gearbeitet. Heute arbeitet er zusammen mit seinen Kollegen daran, dass Unternehmen langfristig mit agilen Denk- und Arbeitsweisen erfolgreich sind. Dabei fokussiert er auf agile Leadership.
Er ist regelmäßiger Sprecher zu agilen Themen auf Konferenzen, bei User Groups und in Unternehmen. Außerdem schreibt er Bücher und Artikel zu agilen Themen.

Dr. Wolf-Gideon Bleek ist Agile Engineering Evangelist bei der it-agile GmbH. Er verfügt über langjährige Erfahrung aus agilen Softwareprojekten unterschiedlicher Größe aus der Perspektive Entwickler, Architekt, Projektleiter, Berater und Abteilungsleiter. Sein Schwerpunkt liegt in der Verknüpfung von Softwaretechnik und agilem Vorgehen. Dabei versucht er, Technik so einzusetzen, dass sie für das Projekt angemessen und dem Prozess dienlich ist.

Stefan Roock, Wolf-Gideon Bleek
Stefan Roock, Wolf-Gideon Bleek
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Mi 7.3
Digitalisierung & Nachhaltigkeit – Was haben wir aus 100 Experten-Interviews gelernt?
Digitalisierung & Nachhaltigkeit – Was haben wir aus 100 Experten-Interviews gelernt?

Die Klimakrise ist da. Digitalisierung verändert unsere Welt mit einer Geschwindigkeit, die wir noch immer nicht begreifen. Unsere digitale Welt hat einen riesigen Fußabdruck, der uns gar nicht bewusst ist. Gleichzeitig lassen sich 13 der 17 SDG der UN ohne (digitale) Technologie gar nicht umsetzen.

In unserem Podcast "Software for Future" befragen wir Expert:innen aus allen Branchen zu der Frage: Wie können wir mit Digitalisierung die Welt retten, ohne mit Digitalisierung die Welt zu zerstören.
In diesem Vortrag verraten wir das Ergebnis!

Zielpublikum: Entscheider, Architekt:innen & Umsetzende
Voraussetzungen: Der Wille, die Welt zu retten
Schwierigkeitsgrad: Fortgeschritten

Nils Löwe is a software engineer with 20+ years of experience, co-founder of multiple companies and tries desperately to save the world using modern technology.

Friederike Löwe is a software engineer with 15+ years of experience, co-founder of the Lionizers and tries desperately to save the world using modern technology.

Nils Löwe, Friederike Löwe
Nils Löwe, Friederike Löwe
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Mi 8.3
Test-Driven Requirements Engineering: Agile Testing in Practice
Test-Driven Requirements Engineering: Agile Testing in Practice

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.

Christof Ebert is managing director at Vector Consulting Services. He supports clients around the world in agile transformations. Before he had been working for ten years in global senior management positions. A trusted advisor and a member of several of industry boards, he is a professor at the University of Stuttgart and at Sorbonne in Paris. He authored several books including "Requirements Engineering" published by dPunkt and in China by Motor Press. He is serving on the editorial Boards of "IEEE Software" and "Journal of Systems and Software (JSS)".

Christof Ebert
Christof Ebert
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Mi 9.3
Data Mesh aus Entwickler:innen-Perspektive
Data Mesh aus Entwickler:innen-Perspektive

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

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

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

Data Mesh überträgt die Prinzipien aus DDD, Team Topologies und Microservices auf die Datenwelt. Es hat aber auch weitreichende soziotechnische Auswirkungen, und lassen sich die zusätzlichen Aufgaben überhaupt mit dem Projektalltag vereinbaren?

In diesem Talk beschreibt Jochen Christ von INNOQ, wie eine Data Mesh-Architektur in der Praxis umgesetzt werden kann, welche organisatorischen Transformationen notwendig werden und welche Technologien sich dabei eignen.

Jochen Christ ist Tech Lead bei INNOQ und ist Spezialist für Self-Contained Systems und Data Mesh. Jochen ist (Co-)Autor von datamesh-architecture.com, http-feeds.org, whichjdk.com und remotemobprogramming.org.

Jochen Christ
Jochen Christ
flag VORTRAG MERKEN

Vortrag Teilen

15:45 - 16:30
KeyMi 2
KEYNOTE: Cloud Adoption Patterns
KEYNOTE: Cloud Adoption Patterns

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.

Independent Cloud Architect and Developer, Lynn is also the author of 35 cloud courses on Linked In Learning. She publishes GitHub (code) and Substack (articles).

Lynn Langit
Lynn Langit
Track: Keynote
Vortrag: KeyMi 2
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Mi 1.4
Initial Architecture Modeling: How Much is Too Much?
Initial Architecture Modeling: How Much is Too Much?

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?

Scott Ambler is the Chief Methodologist of Ambysoft Inc. He is the creator of the Agile Modeling and Agile Data methods, as well as co-creator of PMI's Disciplined Agile tool kit. He has worked with organizations around the world to improve their software development ways of working (WoW). Scott is an award-winning author of 20+ books and an international keynote speaker.

Scott W. Ambler
Scott W. Ambler
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Mi 2.4
Sustainable Pace?! How Self-Care Actually Boosts Teamwork
Sustainable Pace?! How Self-Care Actually Boosts Teamwork

Finding the right balance at work is neither an individual task nor is it only a team’s responsibility. It’s an interaction of both - and more! Leaders also play a vital role as they often (still) have a higher organizational lever.

In this session I will:
1. define what sustainable pace is
2. share common pitfalls that can “unbalance” a system (i.e. team, department, whole company)
3. offer simple yet powerful self-care practices for individuals and for teams
4. mix in psychological background (e.g. on stress & coping)

YOU are invited!

Target Audience: Developers, Architects, System Engineers, Managers of all kind, Human Beings :)
Prerequisites: Curiosity and openness, some work experience is beneficial but not required
Level: Basic

Extended Abstract:
Many of us have seen colleagues burn out or burned themselves out at work. Or even both. How many have seen successful “comebacks”, especially to the very same work context?
Burning out myself twice in my career, recovering from it, changing contexts, seeing other close colleagues struggling - all of this gave me a lot of first-hand experience.

Meanwhile I am independently working in the field as a professional coach with leaders, and as agile coach with teams. There I’ve witnessed lots of sustainable pace situations in organisations … and I've helped to change plenty of highly unsustainable conditions. Also, I dare to state, that the last two years of pandemic accidentally boosted unsustainable working conditions even more: borders between work and life started blurring for many, often without professional support how to cope and manage this. Uncertainty in life just added on top.

With my psychological background, focusing on health psychology, I have plenty of scientific models to build the practical experience I've gained with individuals and teams upon.
My session will enable especially tech people to get more aware of possible pitfalls. Yet awareness is only the first step!

After attending, YOU will have practices at hand and solid knowledge bits in your "backpack".
You will be ready to contribute finding the right balance - for you and your team(s).

Cosima Laube is an independent agile coach, leader & consultant with experience in a variety of industries (automotive, finance, healthcare, travel, public sector).
Having a strong background as developer and people lead in IT engineering, over the last decade Cosima enhanced her portfolio with solid coaching skills (ICF-PCC) and university studies focused on I/O- and Health Psychology. Besides work, you likely find her running or on a bike. Her credo at work and in life is: Achieving MORE - together!

Cosima Laube
Cosima Laube
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Mi 3.4
Log4j lessons learned – Vorbereitung auf den nächsten Zero-Day
Log4j lessons learned – Vorbereitung auf den nächsten Zero-Day

In der Vorweihnachtszeit 2021 wurden viele IT-Abteilungen von Zero-Day-Sicherheitslücken im weitverbreiteten Java-Logging-Framework Apache Log4j kalt erwischt. Diese Session fasst das Ereignis zusammen und sucht Parallelen zu ähnlichen Zero-Days. Hinweise zu proaktiven Maßnahmen helfen, zukünftig in ähnlichen Situationen schneller reagieren zu können. In diesem Zusammenhang wird u.a. auf Configuration Management und Infrastructure as Code nebst Automation eingegangen, aber auch auf Tools wie Web, DNS und Netzwerk-Firewalls.

Zielpublikum: Architekt:innen, Entscheider, Manager, IT-Sicherheitsbeauftragte
Voraussetzungen: Generelles Verständnis für IT-Sicherheitsherausforderungen bei Web-Anwendungen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
In der Vorweihnachtszeit wurden viele IT-Abteilungen von Sicherheitslücken im weitverbreiteten Java-Logging-Framework Apache Log4j kalt erwischt.

Diese Session fasst das Ereignis zusammen und beantwortet die folgenden Fragen, um zukünftig in ähnlichen Situationen schneller reagieren zu können:
•    Welche Möglichkeiten bieten Web, DNS und Netzwerk-Firewalls, um eine Ausnutzung derartiger Lücken zu verhindern?
•    Welche Tools kann ich nutzen, um bspw. mithilfe automatisierter Scans und Analysen des Netzwerkverkehrs festzustellen, welche Bestandteile meiner IT-Infrastruktur betroffen sind?
•    Wie kann ich mit Legacy-Anwendungen umgehen, die ich nicht aktualisieren kann?
•    Wie sollte ich mein Deployment und Betriebsabläufe modernisieren, um Patching zukünftig schneller realisieren zu können?

Automation in Verbindung mit Playbooks und Runbooks ist dabei ein Kernaspekt, um einen Incident Response-Prozess in einer großen IT-Landschaft skalieren zu können.

Dennis Kieselhorst ist Solutions Architect bei Amazon Web Services (AWS). Er hat 15 Jahre Erfahrung mit Java und verteilten, heterogenen Systemlandschaften. Dennis unterstützt verschiedene Open-Source-Projekte und ist Committer/PMC-Mitglied bei der Apache Software Foundation. Er wirkt in den Organisationskomitees der Java User Group (JUG) Bremen-Oldenburg und des Java Forum Nord mit.

Dennis Kieselhorst
Dennis Kieselhorst
flag VORTRAG MERKEN

Vortrag Teilen

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

Eine auf Microservices basierende Architektur umzusetzen bedeutet, dass auch die Datenhaltung auf die verschiedenen Services verteilt werden muss. Was aber bedeutet das in der Praxis? Was ist, wenn Daten einer Entität - vollständig oder in Teilen - in mehreren Services benötigt werden? Wie wird referenzielle Integrität über mehrere Services hinweg realisiert? Wie lassen sich serviceübergreifende Transaktionen realisieren?

Dies sind nur einige von vielen Fragen, die im Rahmen der Session beantwortet werden. So viel vorab: Umdenken ist gefragt!

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

Extended Abstract:
Die Session zeigt anhand eines praktischen Beispiels typische Data Pitfalls, die einem bei der Zerlegung eines Monolithen in eine Vielzahl von Microservices mit Sicherheit begegnen werden.
Für jede dieser Herausforderung werden mehrere Patterns als Lösungen vorgestellt und in ihrem jeweiligen Kontext bewertet.

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

Lars Röwekamp
Lars Röwekamp
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Mi 5.4
The Lost Art of Software Architects
The Lost Art of Software Architects

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”.

Simon Brown is a renowned consultant specializing in software architecture, and the author of some of the most popular software architecture books, including „Software Architecture for Developers” (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He is also the creator of the C4 model for visualizing software architecture, and the founder of Structurizr. Simon is a regular speaker at international software development conferences and travels the world to help organizations visualize and document their software architecture.

Simon Brown
Simon Brown
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Mi 6.4
Domain Storytelling – ein wirkungsvolles Werkzeug für modernes Produktmanagement
Domain Storytelling – ein wirkungsvolles Werkzeug für modernes Produktmanagement

Product Owner treffen regelmäßig Entscheidungen in der Produktentwicklung, die eine fundierte Kenntnis der Fachdomäne und versteckte Anforderungen an wertstiftende Anwendungsfälle und Features erfordern.

Am Beispiel einer komplexen Softwareentwicklung wird der flexible, zeitsparende Einsatz von Domain Storytelling aufgezeigt, um die Qualität fachlicher Entscheidungen zu verbessern. Dazu gehören u. a. die Problemraumanalyse, SOLL-Szenarios im Lösungsraum, strategisches Design (DDD), Releasemanagement (MVP) und arbeitssparendes Dokumentieren.

Zielpublikum: Product Owner (m/w/d), Business Analysts, Manager, Architekt:innen, Entwickler:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Was lernt man:
• Eine kurze Einführung in Domain Storytelling
• Konkrete Beispiele zum Einsatz des Werkzeugs in der Anforderungsermittlung und Softwareentwicklung
• Den Einsatz des Open-Source-Tools Domain Story Modeler Egon.io zum Entwickeln von Szenario-Diagrammen
• Den Zusammenhang von Domain Storytelling und Domain-Driven Design in der Aufgabenstellung Strategisches Design

Carsten Lill (WPS – Workplace Solutions GmbH) interessiert sich für alles, was hilft, Projekte von der Vision bis hin zur Anforderung kollaborativ aufzusetzen. Er berät Kunden im Kontext agiles Projekt- und Anforderungsmanagement, arbeitet als Agiler Coach und hat viel Freude daran, seine Erfahrungen als praxisnaher Trainer in Schulungen weiterzugeben.

Carsten Lill
Carsten Lill
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Mi 7.4
Wie nachhaltig ist ein agiles Team oder Unternehmen?
Wie nachhaltig ist ein agiles Team oder Unternehmen?

Zur Implementierung einer gemeinsamen Strategie orientieren wir uns in Unternehmen oft an OKRs und KPIs. Bisher wurde jedoch nicht viel getan, um zu messen, wo wir auf unserem Weg zu mehr Nachhaltigkeit stehen und/oder wie wir vorankommen.

In diesem (interaktiven) Vortrag gebe ich einen Überblick darüber, wie man einerseits den Status quo bezüglich Nachhaltigkeit eines agilen Teams oder Unternehmens herausfinden kann und andererseits, wie man diesen dann zur Definition der nächsten Schritte verwendet, um nachhaltiger zu werden.

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

Extended Abstract:
Nachhaltigkeit ist einerseits eine Notwendigkeit in der aktuellen Krise und andererseits muss man Nachhaltigkeit auch zunehmend als Schlüsselfaktor verstehen, der über das Überleben von Unternehmen sowohl bei der Suche nach Talenten als auch nach Kunden und Märkten entscheidet.

Ein datengesteuerter Ansatz für mehr Nachhaltigkeit bedeutet nicht, dass wir alle Antworten haben – aber, dass wir bessere Fragen stellen können. Ein Fokus auf Daten ist besonders in einer volatilen, unsicheren, komplexen und vieldeutigen Umgebung wichtig, um Anhaltspunkte für die gemeinsame Weiterentwicklung zu bieten.

Comparative Agile Sustainability ist ein Ansatz, den wir in einem kleinen Team mit Unterstützung von Data-Analytikern erstellt haben, und das dazu dient, das Bewusstsein von Nachhaltigkeit in einem (agilen) Team und/oder Unternehmen zu verankern und voranzutreiben. Die Evaluierung wurde unter creative commons veröffentlicht und steht somit allen Interessierten frei zur Verfügung. Durch die Nutzung der Ergebnisse dieser validierten Bewertung können agile Teams und Unternehmen besser verstehen, wie sie ihre eigene Wirksamkeit erhöhen und zur Steigerung von Nachhaltigkeit in der gesamten Branche beitragen können.

Jutta Eckstein arbeitet weltweit als Business-Coach, Change-Managerin & Beraterin. Ihr Fokus liegt auf unternehmensweiter Agilität in großen & verteilten Organisationen. Sie war von 2003 bis 2007 im Vorstand der AgileAlliance. Sie hat einen M.A. in Business Coaching & Change Management, einen Dipl.-Ing. in Product-Engineering und ist als Immissionsschutzbeauftragte (Umweltschutz) zertifiziert. Jutta wurde 2011 von der Computerwoche in die Top 100 der bedeutendsten Persönlichkeiten der Deutschen IT gewählt.

Jutta Eckstein
Jutta Eckstein
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Mi 8.4
QMS nach ISO 9001 – Das Ende der Produktivität oder eine Qualitätsverbesserung?
QMS nach ISO 9001 – Das Ende der Produktivität oder eine Qualitätsverbesserung?

Wir sind in 20 Jahren zu einer 100-Personen-Entwicklungseinheit herangewachsen, die große komplexe Software-Projekte umsetzt. Jetzt haben wir uns entschlossen, ein Qualitätsmanagementsystem (QMS) nach ISO 9001 einzuführen.
Wir haben dabei festgestellt, wie wichtig die Integration des QMS in unsere Kultur und wie notwendig ein iteratives partizipatives Vorgehen ist. In diesem Vortrag stelle ich einige Herausforderungen vor und wie wir diese so gelöst haben, dass unser QMS unsere Qualität verbessert, ohne die Entwickler:innen zu quälen.

Zielpublikum: Architekt:innen, Projektleiter:innen, Manager, Entscheider
Voraussetzungen: Grundlagen in Qualitätsmanagement
Schwierigkeitsgrad: Fortgeschritten

Dr. Torsten Fink ist Geschäftsführer der Berliner Einheit der akquinet. Neben der Leitung von Softwareprojekten führte er vor seiner Managementtätigkeit Architektur- und Technologieberatungen durch. Aus dem eher technischen Bereich verteilter Systeme kommend, beschäftigt er sich in letzter Zeit immer mehr mit qualitätsorientierten Prozessen und modernen Organisationsstrukturen.

Nach einem Studium in der Wirtschaftsinformatik arbeitet Jana Metz in der Berliner Niederlassung der akquinet als Qualitätsmanagementbeauftragte und IT-Projektmanagerin mit den Schwerpunkten E-Health. Telematikinfrastruktur und Medizinproduktentwicklung. Sie ist maßgeblich an dem Aufbau des firmeneigenen QM-Systems beteiligt und unterstützt dessen Einführung und Umsetzung in der agilen Softwareentwicklung.

Christian Koska ist Qualitätsmanagementbeauftragter der Berliner Einheit der akquinet. Er ist somit mitverantwortlich für die Einführung eines individuellen QM-Systems. Ursprünglich im klinischen Studien- und Controllingbereich angesiedelt, ist er heute fachlich beratend in Softwareentwicklungsprojekte für den Health-Sektor involviert. Die letzten Jahre widmete er zunehmend den regulatorischen Anforderungen an Medizinprodukte sowie dem Aufbau und Betrieb von QM-Systemen.

Torsten Fink, Jana Metz, Christian Koska
Torsten Fink, Jana Metz, Christian Koska
Vortrag: Mi 8.4
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Mi 9.4
Follow the Twin Peaks – Mehr Domänenwissen gleich bessere Softwarearchitektur
Follow the Twin Peaks – Mehr Domänenwissen gleich bessere Softwarearchitektur

Die Twin Peaks sind ein Modell, dass die Wichtigkeit des Zusammenspiels zwischen Anforderungen und Architektur beschreibt. Domain Storytelling hilft, das Twin Peaks Model in der Praxis zu leben. In drei Sprints erarbeiten wir gemeinsam das erste Inkrement eines praxisnahen Anwendungsfalls. Dabei wird die Methodik Domain Storytelling, Tipps und Tricks für die Moderator:in sowie der Übergang zur Software-Architektur interaktiv vermittelt.

Zielpublikum: Architekt:innen, Entwickler:innen, Product Owner, Agile Coach
Voraussetzungen: Projekterfahrung und Grundkenntnisse Domain-driven Design und Scrum
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Ersatzteil, Bestellung, Auftrag und Kunde. Alles klar, das kennen wir! Die im Planning gefühlte Klarheit endet, wenn Entwickler:innen bei der Implementierung von User Stories auf offene Fragen stoßen. Eine schnelle Klärung komplexer Fragen oder Annahmen seitens der Entwickler:innen führt oft nicht zum Erfolg.

Das Ergebnis: Die software-technische Realisierung deckt sich nicht mit den wirklichen fachlichen Anforderungen und es muss nachgearbeitet werden. In der Folge steigen Aufwand und Kosten. Das Projekt befindet sich in einer Abwärtsspirale aufgrund fehlenden Domänenwissens und einer daraus resultierender Softwarearchitektur, die die Domäne nicht unterstützen kann.

Die Twin Peaks sind ein Modell, das die Wichtigkeit des Zusammenspiels zwischen Anforderungen und Architektur beschreibt. Die Abwärtsspirale wird durchbrochen, indem wir die Twin Peaks von der Spitze an, mithilfe von Domain Storytelling, hinabsteigen.

In diesem Talk stelle ich euch Domain Storytelling vor und wie diese Methode dabei hilft, das Twin Peaks Model in der Praxis zu leben. In drei Sprints erarbeiten wir gemeinsam das erste Inkrement unseres Softwareprodukts. Dabei wird die Methodik Domain Storytelling, Tipps und Tricks für die Moderator:in sowie der Übergang zur Software-Architektur interaktiv vermittelt. Denn vermutlich liegt es nun an dir, die entscheidenden Impulse zur Verbesserung der Situation in deinem Projektkontext zu setzen.

Matthias Eschhold ist Softwarearchitekt und Managing Consulting bei der Novatec Consulting GmbH. Als Domain-driven-Design-Enthusiast und Experte für strukturelle Softwarequalität unterstützt er Kunden bei der Architekturarbeit in der agilen Anwendungsentwicklung und schreibt hierbei selbst aktiv Code. Außerdem vermittelt er als Trainer des iSAQB Foundation Level leidenschaftlich sein Architekturwissen.

Matthias Eschhold
Matthias Eschhold
flag VORTRAG MERKEN

Vortrag Teilen

18:30 - 20:00
Nmi 1
Technik, Menschen, Unternehmen: Wie Modernisierungsprojekte (vielleicht) besser laufen könnten.
Technik, Menschen, Unternehmen: Wie Modernisierungsprojekte (vielleicht) besser laufen könnten.

"Wir müssen dringend unser System modernisieren. Das, auf dem unser gesamtes Business beruht. Und wir wollen dabei alte Zöpfe abschneiden und moderne Technologien und Architekturen verwenden. Wir wollen mehr so wie Google werden." Guter Vorsatz, sehr hoher Anspruch. Und dementsprechend gibt es oft massive Probleme in solchen Projekten. Wir waren an einigen repräsentativen Exemplaren als Berater beteiligt und haben dabei beobachtet was schiefgegangen ist und was man besser machen könnte. In dieser Session erzählen wir Euch davon.

Zielpublikum: Architekten und Projektleiter
Voraussetzungen: Keine Spezifischen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Die Sprecher sind beide auf den Bau von domänenspezifischen Sprachen spezialisiert. In diesem Vortrag spielt dieses Thema aber keine Rolle, außer als Aufhänger für den Modernisierungsanspruch: man will die Fachlichkeit der Domäne per DSL ausdrücken. Um das tun zu können, muss man zunächst sehr genau verstehen, wie die Domäne funktioniert. Man analysiert also sehr präzise. Viele der Systeme unserer Kunden sind schon relativ alt und die Technologien sind entsprechend in die Jahre gekommen. Neben dem Verstehen und "Aufräumen" der Fachlichkeit soll also auch gleich die Architektur und Technologie gewechselt werden.
Diese beiden Dinge zusammengenommen sind wirklich anspruchsvoll. Das Projekt beginnt mit entsprechend viel Hoffnung und hohen Zielen. Im Laufe der (meistens) Jahre wird es aber schwierig. Hier sind einige Themengebiete, wo es oft klemmt:

  • Architektur und Hypes
  • Die notwendige Prozessanpassungen
  • Staffing und Skills im Projekt
  • Sinnvolle und der Projektreife angepasste Interpretation von "agil"
  • Kommunikation untereinander und Meetingstruktur
  • Umgang mit politischem "Störfeuer"
  • Führung, Entscheidungsfindung und Produktvision
  • Firmenkultur und deren Auswirkungen

Der Vortrag ist kein unkonstruktives Bashing oder Lästern über (anonymisierte) Kunden. Sondern wir greifen repräsentative Situation auf und geben konkrete Ratschläge, wie man die Dinge besser machen könnte. Einige davon sind vielleicht naherliegend und lassen sich mit gesundem Menschenverstand (der ja oft nicht umgesetzt wird) begründen. Andere sind weniger naheliegend und vielleicht auch unkonventionell oder regen zumindest zu Diskussionen an die wir im Rahmen des Vortrags auch gerne führen werden.
Unsere Rolle in diesen Projekten war die eines Beraters rund um DSLs und Domänenanalyse. Die Projekte als Ganzes waren nicht unsere Verantwortung. Aber wir haben natürlich viel mitbekommen, beobachtet, geredet und mit unserer jahrelangen Erfahrung in solchen Projekten abgeglichen. Es wurde auch sehr deutlich, dass bestimmte (angeblich) technische Probleme in Wirklichkeit eine Folge von organisatorischen Problemen waren. Als Folge sind wir dann von unserer Kernaufgabe "DSL-Bau + Domänenanalyse" auch immer mehr in Architektur- und Projektorga-Themen hineingerutscht -- an deren Lösung wir dann auch konstruktiv mitgearbeitet haben.
Unser Vortrag ist anhand dieser Entwicklung strukturiert. Wir beginnen mit Herausforderungen in der Technik, der Architektur und den Entwicklerskills und zoomen dann schrittweise heraus bis wir auf Ebene der Firmenkultur ankommen.
Im Ergebnis werden die Teilnehmer lernen, welche Faktoren den Erfolg eines Modernisierungsprojekte maßgeblich beeinflussen und dass diese in den wenigsten Fällen einzelne große Faktoren sind, sondern die Summe vieler kleiner Probleme – die alle lösbar sind, wenn man nur will.

Markus Völter ist freiberuflicher Berater zu (domänenspezifischen) Sprachen und Entwicklungswerkzeugen sowie den Systemarchitekturen und Prozessanpassungen um sie in Produkte/Projekte zu integrieren.

Kolja Dummann ist Berater und Architekt für domänenspezifische Tools und Sprachen bei der itemis AG mit besonderem Fokus auf Zusammenarbeitsmodelle und Prozesse.

Markus Völter, Kolja Dummann
Markus Völter, Kolja Dummann
flag VORTRAG MERKEN

Vortrag Teilen

18:30 - 20:00
Nmi 2
Better Decision Making with Stoic Agility: What Would Marcus Aurelius Do?
Better Decision Making with Stoic Agility: What Would Marcus Aurelius Do?

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.

Maryse Meinen is a product leader, currently working in a product owner role, building a full-blown container platform for a new IT infrastructure, together with an awesome team. She is also an active practitioner of Stoic philosophy, trying to live according to values like "humans are made for cooperation", "wisdom" and "perseverance". Always keeping an eye on the human aspect of our work, she strives to humanise our workplace a bit more every day.

Maryse Meinen
Maryse Meinen
flag VORTRAG MERKEN

Vortrag Teilen

18:30 - 20:00
Nmi 3
Coroutines From Scratch
Coroutines From Scratch

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.

Andreas Fertig, CEO of Unique Code GmbH, is an experienced trainer and consultant for C++ for standards 11 to 20.
Andreas is involved in the C++ standardization committee, in which the new standards are developed. At international conferences, he presents how code can be written better. He publishes specialist articles, e.g., for iX magazine, and has published several textbooks on C++.
With C++ Insights (https://cppinsights.io), Andreas has created an internationally recognized tool that enables users to look behind the scenes of C++ and thus understand constructs even better.
Before working as a trainer and consultant, he worked for Philips Medizin Systeme GmbH for ten years as a C++ software developer and architect focusing on embedded systems.

Andreas Fertig
Andreas Fertig
Vortrag: Nmi 3
flag VORTRAG MERKEN

Vortrag Teilen

18:30 - 20:00
Nmi 4
Persuasion: It Takes More Than Information
Persuasion: It Takes More Than Information

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.

Mary Lynn Manns, PhD, is the co-author of two books with Linda Rising, "Fearless Change: Patterns for Introducing New Ideas" and "More Fearless Change: Strategies for Making Your Ideas Happen". She has led numerous presentations and workshops on the topic of change throughout the world at conferences and in organizations that include Microsoft, amazon.com, Apple, Procter & Gamble, and Avon.

Mary Lynn Manns
Mary Lynn Manns
flag VORTRAG MERKEN

Vortrag Teilen

18:30 - 20:00
Nmi 5
Change Culture – Thing or Cult
Change Culture – Thing or Cult

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: Zwischen Sekte und Staatsreligion. Agile Rituale aus kulturhistorischer Perspektive
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.

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

@moeglichewelten is Anke Nehrenberg’s  twitter handle and philosophy: it integrates what is possible and what is feasible. Connecting people, transforming/enhancing/expanding companies, developing leaders and shaping the digital transformation of organizations is her thing. She wanders the world as a T-shaped non-binary, long-distance runner and mental meta-level.

Gina Häußge is a passionate code monkey, gamer, hobby baker, and creator and maintainer of OctoPrint. She has always been in love with code, and loves tinkering and helping others. Gina has written open source software for most of her adult life and has been in the lucky position to do it full time — and 100% crowdfunded by the community for her project OctoPrint for several years now. During this time, she has learned a lot about leading open source projects and managing communities.

Johannes Mainusch, Anke Nehrenberg, Gina Häußge, Michael de Zan
Johannes Mainusch, Anke Nehrenberg, Gina Häußge, Michael de Zan
flag VORTRAG MERKEN

Vortrag Teilen

, (Donnerstag, 09.Februar 2023)
09:00 - 10:30
Do 1.1
Loosely or Lousily Coupled? Understanding Communication Patterns in Microservices Architectures
Loosely or Lousily Coupled? Understanding Communication Patterns in Microservices Architectures

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.

Bernd Rücker is a software developer at heart who has been innovating process automation deployed in highly scalable and agile environments of industry leaders such as T-Mobile, Lufthansa, ING, and Atlassian. He contributed to various open-source workflow engines for more than 15 years and he is the Co-Founder and Chief Technologist of Camunda – an open-source software company reinventing process automation. He is the author of "Practical Process Automation" and co-author of "Real-Life BPMN".

Bernd Rücker
Bernd Rücker
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:30
Do 2.1
Pragmatic Scaling to Business Agility: Crafting Organisations for Innovation where People can Thrive
Pragmatic Scaling to Business Agility: Crafting Organisations for Innovation where People can Thrive

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.

Carsten Jakobsen is a Registered Scrum Trainer and one of the early Agile and Scrum pioneers in Denmark. His career started with Sun Microsystems in Silicon Valley, and later he returned to Denmark where he joined Systematic in 1998. Since 2006 Carsten has led change management and transformations in organizations to adopt Scrum and Agile values. He has written several articles with Jeff Sutherland and is a speaker at international Agile conferences. Since 2017, Carsten has worked primarily with larger organizations to drive agile transformations. In most organizations he has done this with Scrum training, Agile workshops, onsite consultancy, and close collaboration with leaders in the organization.

Simon Roberts is an agile and leadership coach and Certified Scrum Trainer. He has used lightweight/agile methods since the late 1990s and works with organisations large and small to help them achieve better results by leveraging the power of self-organising teams. He has consulted for and led several large-scale agile transitions at DAX companies in Germany, is the author of several articles and speaks regularly at conferences on the subject of agile leadership. Simon holds an MBA specialising in Creativity, Innovation and Change from the Open University Business School.

Carsten Jakobsen, Simon Roberts
Carsten Jakobsen, Simon Roberts
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Do 3.1
Use Testing to Develop Better Software Faster
Use Testing to Develop Better Software Faster

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.

Marit van Dijk is a software developer with 20 years of experience in different roles and companies. She loves building awesome software with amazing people and has contributed to open source projects like Cucumber and various other projects. She enjoys learning new things, as well as sharing knowledge on programming, test automation, Cucumber/BDD and software engineering. She speaks at international conferences, webinars and podcasts, occasionally writes blog posts and contributed to the book "97 Things Every Java Programmer Should Know" (O’Reilly Media).

Micro-Service Delivery without the Pitfalls
Micro-Service Delivery without the Pitfalls

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

Seb Rose has been a consultant, coach, designer, analyst and developer for over 40 years. He's now Developer Advocate with SmartBear Advantage, promoting better ways of working to the software development community.
Co-author of the BDD Books series "Discovery” and "Formulation" (Leanpub), lead author of “The Cucumber for Java Book” (Pragmatic Programmers), and contributing author to “97 Things Every Programmer Should Know” (O’Reilly).

Marit van Dijk
Seb Rose
Seb Rose
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Do 4.1
Ready for the Future: Enterprise Java in Zeiten von Modern Web, Cloud Native & Co.
Ready for the Future: Enterprise Java in Zeiten von Modern Web, Cloud Native & Co.

Auch nach mehr als 20 Jahren ist Jakarta EE (ehemals Java EE) DER Standard, wenn es um die Entwicklung Java-basierte Enterprise Computing-Lösungen geht. Dies gilt zumindest immer dann, wenn die Anwendung als Monolith in einem Application Server deployed werden soll. Wie aber steht es mit einer Anwendung, die aus einer Vielzahl autark laufender Microservices besteht? Und wie gut schlägt sich Jakarta EE in der Cloud, in der geringer Speicherbedarf und schnelle Startzeiten gefragt sind?

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

Extended Abstract:
Die Session zeigt, wie es Jakarta EE geschafft hat, mit der Zeit zu gehen und so, mithilfe von Side-Projekten wie dem Eclipse MicroProfile, den Anforderungen moderner Cloud-native-Anwendungen gerecht zu werden.
Ein Ausblick auf das Zusammenspiel mit GraalVM und Quarkus zeigt, dass Jakarta EE dabei auch in extrem verteilten Cloud-Szenarien, aka Serverless, eine gute Figur macht.

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

Gestern ging es noch! API Testing reloaded
Gestern ging es noch! API Testing reloaded

Webanwendungen ohne automatisiert getestete APIs machen im Betrieb und Weiterentwicklung schlechte Laune, egal, ob es um APIs zwischen Frontend und Backend, zwischen Microservices oder zu Drittparteien geht. Typischerweise beschreiben wir das erwünschte Verhalten der Anwendung, in dem wir uns selbst Beispiele als Testfälle ausdenken. Da geht mehr. In diesem Beitrag werfen wir einen Blick auf über "naive Integrationstests" hinausgehende Ansätze, von Contract Based bis hin zu KI-Unterstützung.

Zielpublikum: Entwickler:innen, Tester:innen
Voraussetzungen: Erfahrung in der Entwicklung und im automatisierten Testing von Webanwendungen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Die Älteren unter uns werden sich noch an die Anfänge der Webentwicklung erinnern: Tester:innen klickten sich wieder und wieder durch umfangreiche Testpläne durch, die typischerweise nach dem Entwickeln erstellt wurden. Dieser Ansatz ist leider gerade in Konzernen immer noch nicht ausgestorben. Schlecht getestete Schnittstellen werden schnell zur Achillesferse gerade in modularen Architekturen und vor dem Wunsch, fertige Software schneller in die Produktion zu bringen. Consumer driven contract testing ist zumindest theoretisch mittlerweile in den Teams angekommen, neuere Ansätze wie Search based Software Testing oder Property based Testing sind dagegen noch exotisch.

Die Session will einen praxisorientierten Überblick über unbekanntere Verfahren geben.

Dorthe Luebbert ist in der IT seit der 5 1/4 Zoll Diskette dabei und interessiert sich für Webtechnologien und die Menschen, die diese bauen. Als Freelancerin in der IT schätzt sie den entspannten Feierabend dank guter Architektur, Softwarequalität und vernünftiger Prozesse.

09:00 - 10:45
Do 5.1
XP – 25 Years Later: Balancing New Tech and Proven Practices
XP – 25 Years Later: Balancing New Tech and Proven Practices

When Extreme Programming (XP) was first described 25 years ago the IT industry was in a different place. Since then, we've seen widespread adoption of agile approaches, the rise of the open source and public cloud ecosystems, and much more. And while these trends have improved our ability to deliver complex software systems, the mastery of the actual craft — working effectively in a team, delivering quality software at a sustainable pace — is as important as ever.

This talk will place XP into today's world of modern software development.

Target Audience: Developers, Architects, Software Engineers
Prerequisites: None
Level: Advanced

Erik Dörnenburg is a software engineer and passionate technologist. At Thoughtworks he helps clients solve their business challenges using modern technologies, platforms, and practices. On his long journey through the tech industry Erik encountered an abundance of new technologies, always seeking to understand their potential while at the same time bringing along proven engineering practices. Throughout his career Erik has been an advocate of agile values and open-source software.

Take it Back
Take it Back

Das agile Manifest wurde vor über 20 Jahren von Entwicklern für Entwickler geschrieben. Mittlerweile fühlt es sich aber immer mehr an, als ob die agile Bubble eine eigene Welt ist, die von Scrum Mastern und Agile Coaches übernommen wurde. Developer nehmen eher passiv an den vorgeschriebenen Meetings teil, statt den Prozess aktiv zu gestalten.
Was läuft da schief? Und wie können wir das ändern?
In dieser Session geht es um Motivation, sinnvolle Konflikte und Empowerment.

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

Ina Einemann ist als Agile Coach bei der Open Knowledge GmbH in Oldenburg tätig. Ihr Tätigkeitsumfeld umfasst neben ihrer Arbeit als Scrum Master auch Aufgaben aus dem Bereich PO und Requirements Engineering. Sie beschäftigt sich mit agilen Methoden und Vorgehensmodellen und berät Teams bei der Umsetzung agiler Praktiken. Sie ist außerdem einer der Hosts des Podcast "Mein Scrum ist kaputt".

Erik Dörnenburg
Ina Einemann
Ina Einemann
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:30
Do 6.1
Glaubwürdigkeit von Agilisten – oder wie viel Integrität ist notwendig?
Glaubwürdigkeit von Agilisten – oder wie viel Integrität ist notwendig?

Zu den Aufgaben von Scrum Mastern und Agile Coaches gehören Servant Leadership, Coaching, Facilitation und Removing von Impediments. Damit versuchen wir, die Veränderungen für die gewünschten Ziele zu initiieren.

Bei vielfältigen Begegnungen sind mir Verhaltensweisen aufgefallen, die mich nachdenklich stimmen: Wie ist das mit Walk-Your-Talk? Leben wir Agilisten selbst, was wir anderen zumuten? Wie steht es mit unserem Mut, Commitment, unserer Fähigkeit zur Zusammenarbeit und unserem persönlichen Wachstum? Und wie gehen wir damit um?

Zielpublikum: Scrum Master, Agile Coaches, Manager, Team, Developers, Entscheider, Kund:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Glaubwürdigkeit von Agilisten oder wie viel Integrität ist nötig?

Die Aufgaben von Scrum Mastern und Agile Coaches sind vielfältig. Darunter fallen Servant Leadership, Coaching der Teams, Facilitation, Removing von Impediments. Mit diesen Tätigkeiten versuchen wir, die Veränderungen zu initiieren und zu begleiten, die für den gewünschten Wandel und Ziele unserer Kunden notwendig sind.

Bei den vielfältigen Begegnungen sind mir an mir selbst und anderen Kollegen immer wieder Verhaltensweisen aufgefallen, die mich nachdenklich stimmen und fragen lassen:
Wie ist das mit Walk-Your-Talk? Leben wir Scrum Master und Coaches eigentlich selbst, was wir anderen zumuten? Wo zeigt sich unser Mut, unser Commitment, unsere Fähigkeit zur Zusammenarbeit und unser persönliches Wachstum? Wo erleben wir Dilemmata? Wo erleben wir unsere eigenen Grenzen? Und wie gehen wir damit um?

In unserer Session werde ich euch eine kleine Geschichte zu meinen Beobachtungen erzählen und euch dann einladen, eure eigenen Beobachtungen zum Thema Integrität und Walk-Your-Talk zu sammeln. Wir werden nach Mustern schauen und Hypothesen bilden. Und daraus wollen wir dann Schritte und Ideen entwickeln, mit welchem Verhalten wir unsere Glaubwürdigkeit stärken können.

Ziel dieser Session ist, dass wir Agilisten Inspirationen mitnehmen, die unsere Glaubwürdigkeit stärken. Kunden und andere Interessierte können Einsichten gewinnen, worauf sie bei der Wahl eines Scrum Masters oder Agile Coaches achten möchten.

Bettina Ruggeri ist zertifizierter Coach und Path-to-CSP Educator (Scrum Alliance). Ihre Schwerpunkte sind die Lernende Organisation, Organisatorische Führung und Kultur. Sie hilft Organisationen, sich in diesen Bereichen weiterzuentwickeln. Sie hat sich weitergebildet in systemischem Coaching, Mediation, Gruppendynamik, Organisationsberatung und ist Trainerin für Gewaltfreie Kommunikation. Sie möchte zu nachhaltigem und freudvollem Wachstum beitragen.

Bettina Ruggeri
Bettina Ruggeri
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Do 7.1
Entzaubert KI und stoppt die Verschwendung von Ressourcen
Entzaubert KI und stoppt die Verschwendung von Ressourcen

Das Gros der Projektideen in Unternehmen basiert heutzutage auf der Verwendung von KI zur Problemlösung. Aus der Vielzahl von diskutierten Projektideen zeichnet sich ein immer gleiches Bild ab: Geschäftsproblem wird beschrieben, Vorteilhaftigkeit einer möglichen KI-Lösung wird beziffert, aber KI an sich wird leider häufig als eine Art "Harry Potter" mit Zauberfähigkeiten gesehen.

KI ist jedoch Handwerk und die Sinnhaftigkeit von KI zur konkreten Problemlösung lässt sich in 5 Schritten strukturiert feststellen. Dies ist Inhalt des Vortrags.

Zielpublikum: Projektleiter:innen, Fachseite, Manager, Entscheider
Voraussetzungen: Interesse am Thema - jedoch kein Fachwissen
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Angesichts der großen Flut von Investitionen und Einsteigern, die das Machine Learning-Spielfeld neu betreten, glauben wir, dass es an der Zeit ist, einige der Erkenntnisse zu teilen, die wir aus unserer Erfahrung in einem breiten Spektrum von Rollen und Projekten gewonnen haben; insbesondere das Wissen, welches für die Auswahl und die Umsetzung von ML-Projekten am wichtigsten ist.

Die meisten ML-Projekte scheitern zu spät: Erst nachdem Unternehmen enorme Ressourcen in die Vorverarbeitung von Daten, die Programmierung, die Durchführung von Berechnungen und den Bau von Prototypen investiert haben.

Unser Ziel ist es, die Teilnehmer in die Lage zu versetzen, 80 % ihrer ML-Projektideen bereits in der Konzeptionsphase verwerfen zu können.

Olaf Erichsen ist Co-Founder und CEO der Heldenkombinat Technologies GmbH und Dozent an der Hamburg School of Business Administration (HSBA).
Seit 2016 hat Olaf weltweit über 300 KI-Anbieter evaluiert und versteht, was hier versprochen und was tatsächlich gehalten wird. Seit 2018 berät Olaf zudem Unternehmen dabei, sich im ML-Bereich strategisch richtig aufzustellen und signifikant zu wachsen. Eines dieser US-Start-ups wurde in einem der Top-Technologie-M&A-Deals 2020 übernommen.

Sustainability-Thinking-Process – Unser Weg zu nachhaltiger IT
Sustainability-Thinking-Process – Unser Weg zu nachhaltiger IT

Die IT ist verschwenderisch, das Einsparpotenzial entsprechend hoch. Die Wertschöpfungsketten von IT-Unternehmen und IT-Abteilungen offenbaren eine Vielzahl von Aspekten, die verschiedenste Nachhaltigkeitsziele berühren. Die methodische Betrachtung und Wirkungsanalyse einer exemplarischen IT-Wertschöpfung im Kontext der 17 Nachhaltigkeitsziele der UN führte uns zur Entwicklung des Sustainability-Thinking-Process - auf Basis von Design Thinking. Der Vortrag stellt das Vorgehensmodell, unsere Motivation und mitunter kontroverse Erkenntnisse vor.

Zielpublikum: Alle auf dem Weg zu einer nachhaltigen IT
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Dass Nachhaltigkeit keine esoterische Randerscheinung ist, ist inzwischen auch in der IT angekommen. Das Bewusstsein für nachhaltiges Wirtschaften ist in den meisten IT-Unternehmen zumindest so weit geschärft, dass man sich in Bezug auf Energieverbräuche und CO2-Emissionen Gedanken macht, diese möglichst zu reduzieren und unvermeidbare Energieverbräuche aus Ökostrom bezieht sowie in Klimakompensationen investiert.
Nachhaltigkeit ist allerdings mehr, als sich „nur“ klimafreundlich zu organisieren. Denn die Potenziale der IT sind auch hierbei umfassenderer und vielseitiger, als man das auf den ersten Blick vermuten mag. Nicht zuletzt auch vor dem Hintergrund, dass jede verschwendete Kilowattstunde Ökostrom durch die IT die Einsparung von fossiler Energie an anderer Stelle hemmt.
Die Wertschöpfungskette eines IT-Unternehmens oder einer IT-Abteilung offenbart eine Vielzahl von Aspekten, die auch weitere Nachhaltigkeitsziele berühren. Die methodische Betrachtung und Wirkungsanalyse einer exemplarischen IT-Wertschöpfung, in Bezug auf die 17 Nachhaltigkeitsziele der UN - den Sustainability Development Goals (SDG's) - führte uns zur Entwicklung einer Vorgehensvariante des Design-Thinking-Process - dem Sustainability-Thinking-Process. Dieses Vorgehensmodell begleitete unsere praxisbezogene Ermittlung potenzieller Nachhaltigkeitsdefizite in der BizDevOps-Wertschöpfung sowie der kreativen Entwicklung von Maßnahmen, Policies und Good Practices, um diese Defizite zu verringern.
Ein Blitzlist durch unsere Nachhaltigkeitsmotivation, dem entwickelten Vorgehensmodell, aber auch der Weg über kontroverse Erkenntnisse während der Maßnahmenfindung sind Teil dieser Kurzvorstellung und Diskussion.

Oliver Lukas ist Executive Business Analyst und Requirements Engineer bei msg und seit Jahrzehnten in unterschiedlichen Rollen und Positionen in der IT tätig. Methodisches und modernes Vorgehen sowie zielorientierte Lösungsfindung sind dabei Attribute, die er in seiner langen IT-Laufbahn nutzt und seit 2020 als Berater für das Bundesministerium für Wirtschaft und Klimaschutz für die Umsetzung der "Klimaneutralen Bundesverwaltung" adaptiert und anwendet. Der geborene Münchner ist Autor von technischen Büchern und Artikeln sowie Erfinder von Patenten und hat sich nun zum Ziel gesetzt, seine Erfahrungen in der Digitalisierung auch im Sinne der Nachhaltigkeit zu fokussieren.

Olaf Erichsen
Oliver Lukas
Oliver Lukas
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Do 8.1
Evolutionäre Softwarequalität
Evolutionäre Softwarequalität

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

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

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

Extended Abstract:
Die Balance der passenden Qualitätszielen ist ein herausforderndes Thema. Qualitätsziele sind aber sehr wichtig in der Entwicklung passender Softwaresysteme. Sie helfen uns, Architekturentscheidungen fundierter zu treffen. Die „genau richtige Qualität“ hängt dabei stark vom Betrachtungspunkt verschiedener Stakeholder ab. Zudem ändern sich Ansprüche an die Qualitäten eines Softwaresystems über die Zeit hinweg. Dies macht das Arbeiten mit und an Qualitätszielen vor allem in langlebigen Softwaresystemen immer wieder spannend.

In diesem Vortrag stelle ich eine neue Sicht auf Softwarequalität vor, wo wir Qualität im evolutionären Kontext betrachten. Als Basis verwende ich hierzu das ISO 25010-Qualitätsmodell sowie Wardley Mapping. Damit lassen sich notwendige Qualitäten nach ihrer Wichtigkeit und Evolutionsstufen von Softwaresystemen kommunizieren. Der Vortrag verzahnt die evolutionäre Sicht auf Softwarequalität mit Beispielen aus der Praxis und zeigt, wie sich damit die richtige Balance zwischen zu viel und zu wenig Qualität gestalten lässt.

Markus Harrer arbeitet seit mehreren Jahren in der Softwareentwicklung und ist vor allem in konservativen Branchen tätig. Als Senior Consultant hilft er, Software nachhaltig und wirtschaftlich sinnvoll zu entwickeln und zu verbessern. Er ist aktiver Mitgestalter in Communities zu den Themen Software Analytics, Softwarearchitektur, Softwaresanierung und Java. Zudem ist er akkreditierter Trainer für den iSAQB Foundation Level und dem Advanced-Level-Modul IMPROVE.

Technische Schulden – warum der Begriff mehr Verwirrung als Klarheit stiftet. Und wie es besser geht
Technische Schulden – warum der Begriff mehr Verwirrung als Klarheit stiftet. Und wie es besser geht

Ist uns Softwerkern wirklich klar, was wir meinen, wenn wir von Technischen Schulden sprechen? “Klar”, ist die Antwort. Wirklich? Warum haben wir dann Schwierigkeiten, POs/Projektleiter/Abteilungsleiter vom notwendigen Budget zu überzeugen?
Im Vortrag zeigen wir, wie es datenbasiert besser geht. Wie man für Technische Schulden KPIs erfasst und wie man jeweils Code-, Architektur-, Test-Qualität, Team-Kollaboration mit den KPIs korreliert, um eine Kosten-Nutzen-Analyse durchzuführen. Trotz Microservices und DevOps - die Herausforderungen bleiben.

Zielpublikum: Architekt:innen, Projekt-/Technische Leiter:innen, Key Developer, Manager, Entscheider
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Ist uns Softwerkern wirklich klar, was wir meinen, wenn wir von Technischen Schulden sprechen? “Klar”, ist die Antwort, “es geht um Smells, Bugs, Bedarf an Refactoring, fehlende Tests …”. Zum Teil können wir deren Umfang und Bedarf sogar messen. Aber wie entscheiden wir, was wir zuerst angehen sollen? Wie und was messen wir, sodass andere Stakeholder uns überhaupt verstehen und wir POs, Projektleiter und Abteilungsleiter vom notwendigen Budget überzeugen können?
Im Vortrag zeigen wir, wie man datenbasiert bessere Antworten findet. Was man mit den Folgen der Technischen Schulden anfängt, Wartungs- und sich verstärkende Mehraufwände in der Entwicklung als KPIs erfasst und deren Hotspots im Code identifiziert. Wie man jeweils Code-, Architektur- und Test-Qualität usw. als Ursachen identifiziert und mit den KPIs korreliert. Und wie man Technische Schulden in der Architektur in Zahlen prognostiziert, um eine Kosten-Nutzen-Analyse durchführen zu können. Und wie sich Team-Kollaboration auch auf Technische Schulden auswirkt.
Diese Herausforderungen sind seit mehreren Jahrzehnten die gleichen. Daran haben auch Microservices nichts geändert.

Die Teilnehmer erhalten Antworten auf folgende Fragen:

•    Was sind Technische Schulden genauer?
•    Wie misst man die Folgen?
•    Wie sieht eine effektive Ursachenanalyse aus?
•    Wie überzeuge ich andere Stakeholder von der Notwendigkeit?
•    Wie wirkt sich Team-Kollaboration auf Technische Schulden aus?

Egon Wuchner hat mehr als 18 Jahre bei der Siemens Corporate Technology als Software-Engineer, Architekt und Projektleiter zu Software-Architektur-Themen wie Qualitätsattribute und Software-Wartbarkeit gearbeitet.
Konstantin Sokolov hat teilweise für Siemens als Freelancer an den Themen mit Egon zusammengearbeitet. Zusammen haben sie Cape of Good Code gegründet mit dem Ziel, Software-Analysen anzubieten, auf die es ankommt.
Markus Harrer
Egon Wuchner, Konstantin Sokolov
Egon Wuchner, Konstantin Sokolov
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 10:45
Do 9.1
Nix geht über Docker
Nix geht über Docker

Software containerisiert auszuliefern, ist mittlerweile sehr etabliert. Selbst bei Beachtung gängiger Best Practices ist es jedoch schwierig, Docker-Images reproduzierbar und sicher zu machen. Mögliche Folgen sind beispielsweise Versionskonflikte oder plötzlich fehlschlagende CI-Pipelines.

Mit dem Package-Manager Nix kann man einen großen Teil dieser Probleme vermeiden. Insbesondere das Nix-Tooling rund um Docker ermöglicht eine schmerzfreie Erstellung vollständig reproduzierbarer und minimaler Docker-Images.

Zielpublikum: Entwickler:innen, Architekt:innen, Dev-Ops-Ingenieure
Voraussetzungen: Docker-Basiswissen
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Es wird eine kurze Einführung in die Nix-Toolchain und -Programmiersprache geben. Wir schauen uns ein Beispielprojekt an, in dem verschiedene Technologien zum Einsatz kommen. Dabei identifizieren wir gemeinsam diverse Problem einer sehr naiven Dockerisierung des Projekts, und versuchen im Anschluss, diese mit einer "nixifizierten Variante" zu lösen. Als Resultat erhalten wir cache-freundlich minimale und reproduzierbare Docker-Images ‒ baubar sogar ohne Docker-Installation.

Grundlegende Erfahrung mit Docker wird vorausgesetzt. Vorwissen zu Nix ist keine Notwendigkeit.

Johannes Maier ist Software-Architekt bei der Active Group GmbH in Tübingen. Dort arbeitet er mit funktionalen Programmiersprachen, vorzugsweise Haskell, und nutzt dabei Nix, um komplexe Abhängigkeiten zu bändigen und Continuous Deployment zu erreichen. Wenn er nicht gerade mit seinen Kindern Lego baut, lötet er an seiner nächsten Tastatur oder konfiguriert Emacs.

Kubernetes Developer Survival Kit
Kubernetes Developer Survival Kit

Immer mehr Entwickler:innen schreiben Anwendungen, die später in einem Kubernetes Cluster laufen sollen. Was kann dabei so schwierig sein? Angefangen "Wie strukturiere ich meine Repositories?", "Wo lege ich meinen Code für das Deployment ab (Containerfiles, Helm Charts, Config Values)?", "Was muss bei der Entwicklung der Anwendung beachtet werden?", "Wie bekomme ich den Code lokal getestet?", "Wie bekomme ich mit, was im Test-Cluster passiert?"

Zielpublikum: Entwickler:innen, Architekt:innen
Voraussetzungen: Kubernetes-Kenntnisse, allgemeine Entwicklungskenntnisse
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Immer mehr Entwickler:innen schreiben Anwendungen, die später in einem Kubernetes Cluster laufen sollen. Was kann dabei so schwierig sein? Angefangen "Wie strukturiere ich meine Repositories?", "Wo lege ich meinen Code für das Deployment ab (Containerfiles, Helm Charts, Config Values)?", "Was muss bei der Entwicklung der Anwendung beachtet werden?", "Wie bekomme ich den Code lokal getestet?", "Wie bekomme ich mit, was im Test-Cluster passiert?"
Dieser Vortrag geht am Beispiel einer Java-Anwendung die typischen Entwicklungsschritte von der Ablage im VCS bis hin zum Deployment auf einem Cluster aus Sicht einer Entwicklerin durch.

Sandra Parsick ist Java Champion und arbeitet als freiberufliche Software-Entwicklerin und Consultant im Java-Umfeld. Seit 2008 beschäftigt sie sich mit agiler Softwareentwicklung in verschiedenen Rollen. Ihre Schwerpunkte liegen im Bereich der Java Enterprise-Anwendungen, Cloud, Software Craftsmanship und in der Automatisierung von Softwareentwicklungsprozessen. Darüber schreibt sie gerne Artikel und spricht auf Konferenzen. In ihrer Freizeit engagiert sich Sandra Parsick in verschiedenen Programmkomitees und Community-Gruppen.

Johannes Maier
Sandra Parsick
Sandra Parsick
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Do 1.2
Chaos im API-Dschungel? – Design-Guidelines als Orientierungshilfe
Chaos im API-Dschungel? – Design-Guidelines als Orientierungshilfe

APIs sind die Bindeglieder moderner Architekturen und nicht selten integriert ein System APIs im zweistelligen Bereich. Damit die API-Integration nicht zur Irrfahrt wird, unterstützen API-Guidelines die Developer Experience. Mit einem Blick auf öffentliche Guidelines und APIs gibt der Vortrag einen Eindruck von der allgemeinen Situation und liefert Impulse für das eigene API-Management. Da es in der Regel zu kurz gegriffen ist, einfach öffentliche API-Guidelines zu referenzieren, geben wir Tipps für eigene API-Guidelines und deren Etablierung.

Zielpublikum: Architekt:innen und Entwickler:innen
Voraussetzungen: Erfahrung oder Interesse am Design von Remote APIs
Schwierigkeitsgrad: Anfänger

Extended Abstract:
APIs sind die Bindeglieder unserer modernen, verteilten Systemarchitektur und nicht selten liegt die Anzahl der APIs im zweistelligen Bereich, wenn ein System integriert werden muss. Damit der Überblick gelingt und die API-Integration nicht zur Irrfahrt wird, unterstützen API Style Guidelines bei einer besseren Developer Experience und sind ein wichtiger Bestandteil der API Governance.
Mit einem Blick auf öffentlich zugängliche API-Guidelines und der Analyse öffentlicher APIs werden wir uns einen Eindruck von der allgemeinen Situation verschaffen und liefern Impulse für das eigene API-Management und -Design.

Hierüber wird auch schnell klar, warum es in der Regel zu kurz gegriffen ist, einfach eine öffentliche API-Guideline zu referenzieren. Deshalb werden wir auch Wege zur eigenen API-Design-Guideline aufzeigen und Tipps geben, die bei der Etablierung im Unternehmen helfen werden.

Benjamin Klatt ist Integrationsarchitekt und Agile Coach. Seine Schwerpunkte liegen in der Digitalisierung von Produkten und Prozessen, Integrationsarchitekturen sowie neuen Arbeitsweisen.

Constanze Klaar ist IT-Beraterin mit Fokus auf der Entwicklung von Java-basierten Enterprise-Anwendungen. Seit vielen Jahren setzt sie sich mit dem Design guter APIs und API-Management auseinander.

Benjamin Klatt, Constanze Klaar
Benjamin Klatt, Constanze Klaar
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Do 2.2
OODA-Cycle und IOHAI-Leadership-Prinzipien
OODA-Cycle und IOHAI-Leadership-Prinzipien

Der OODA-Cycle (Observe-Orient-Decide-Act) beschreibt, wie sich Menschen, Teams und Unternehmen in ihrer Umwelt orientieren und handeln. Im Wettbewerb in dynamischen Umgebungen gewinnt die Partei, die ihren OODA-Cycle schneller durchläuft; denn sie lernt und reagiert schneller. Die IOHAI-Leadership-Prinzipien beschreiben, wie Leadership dazu beiträgt, in Teams und Organisationen den OODA-Cycle schneller zu durchlaufen.

Der Vortrag führt in die Ideen von OODA und IOHAI ein und erläutert ihre Anwendung für Unternehmen.

Zielpublikum: Manager, Scrum Master, Projektleiter:innen
Voraussetzungen: Berufspraxis in Unternehmen :-)
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Der OODA-Cycle und die IOHAI-Leadership-Prinzipien stammen von Col. John Boyd. Den Ursprung haben die Konzepte im Luftkampf Kampfjet gegen Kampfjet. Sie werden inzwischen aber auch für militärische Konflikte verwendet.

Für Unternehmen sind OODA und IOHAI auf verschiedensten Ebenen nützlich. Sie können auf strategischer Ebene helfen, um einen nachhaltigen Wettbewerbsvorteil zu erlangen. Sie können helfen, bessere KPI-/Metriksysteme zu schaffen. Die können bei agiler Skalierung helfen. Und sie können ganz profan dabei helfen, die Meetingstruktur in Unternehmen aufzuräumen und effektiver zu gestalten.

Stefan Roock (it-agile) hilft Unternehmen, Führungskräften und Teams dabei, ihre Potenziale zu entfalten - hin zu erfolgreichen Unternehmen, die ihre Kunden und Mitarbeiter begeistern. Er ist davon überzeugt, dass dazu strukturelle, personelle und interpersonelle Themen im Zusammenspiel adressiert werden müssen.
Stefan Roock hat seit 1999 agile Ansätze in Deutschland maßgeblich mit verbreitet und weiterentwickelt. Zunächst hat er als Entwickler in agilen Teams, später als Scrum Master/Agile Coach und Product Owner gearbeitet. Heute arbeitet er zusammen mit seinen Kollegen daran, dass Unternehmen langfristig mit agilen Denk- und Arbeitsweisen erfolgreich sind. Dabei fokussiert er auf agile Leadership.
Er ist regelmäßiger Sprecher zu agilen Themen auf Konferenzen, bei User Groups und in Unternehmen. Außerdem schreibt er Bücher und Artikel zu agilen Themen.

Stefan Roock
Stefan Roock
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Do 3.2
Diversity, Equity, and Inclusion: Theoretical and Practical Reflections on Finding the Right Balance in your Organization
Diversity, Equity, and Inclusion: Theoretical and Practical Reflections on Finding the Right Balance in your Organization

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.

Elizabeth Benedict Christensen, Ph.D. has extensive theoretical and practical experience in diversity, equity, and inclusion in the academic and business worlds. Elizabeth has taught at university-level about Diversity, Cultural Analysis, Communication, Research Methods and beyond. She completed a Ph.D. on sense of belonging before returning to the business world in 2017 to bridge theory with practice, including sharing her passion for DEI globally.

Elizabeth Benedict Christensen
Elizabeth Benedict Christensen
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Do 4.2
Lose Kopplung im Frontend mit 'Hotwire: HTML over the wire' oder auch nieder mit den SPAs
Lose Kopplung im Frontend mit 'Hotwire: HTML over the wire' oder auch nieder mit den SPAs

Heutzutage führt kein Weg an Single-Page Applications vorbei. Ob React, Angular, VueJS oder eines der anderen Frameworks. Die Standardantwort auf die Frage nach der Frontend-Architektur heißt SPA. Doch was kaum jemand bemerkt:

Die SPA-Idee ist legacy! Mit AngularJS wurde vor 10 Jahren diese Idee bereits umgesetzt.

Ich möchte im Vortrag zeigen, aufgrund welcher Frontend-Probleme man ursprünglich SPAs entwickelt hat und ob es für diese Probleme nicht heutzutage innovativere Lösungen gibt: Hier kommt Hotwire ins Spiel!

Zielpublikum: Architekt:innen, Entwickler:innen, Frontend, Backend
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Hier kommt Hotwire ins Spiel, das mit einer sehr schlauen, auf low-level Standards setzenden Lösung ganz neue Möglichkeiten für saubere Architekturen schafft, ohne die UX-Vorteile einer SPA zu verlieren!
Ganz anders als SPAs lässt sich mit Hotwire eine lose Kopplung und geringe Abhängigkeiten zwischen verschiedenen Teams wahren und so Skalierungsfähigkeit erhalten.

Wenn ihr die Technologie kennenlernen und gleichzeitig ihren positiven Effekt auf Teams und Abhängigkeiten erfahren wollt, dann kommt gern vorbei!

Benedikt Stemmildt ist CIO von Blume2000. Er ist leidenschaftlicher Software-Architekt, Full-Stack-Entwickler und Speaker mit Begeisterung für Technologie, Architektur und Organisation.

Benedikt Stemmildt
Benedikt Stemmildt
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Do 5.2
You Don't Have to be a Conductor, to Make a Perfect Symphony Between Hype Driven and Legacy Development
You Don't Have to be a Conductor, to Make a Perfect Symphony Between Hype Driven and Legacy Development

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

Marita Klein works as Senior Cloud Architect at Bosch Engineering. She has worked in different domains and roles during her professional career: Frontend and Backend developer, Architect as well as team lead of a group of software engineers. In all these stations she has experienced the importance of technical exchange between experts and how making problems explicit and talking about them is the first step of a solution.

Marita Klein
Marita Klein
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Do 6.2
Modern Leadership – Wie kann moderne Personalführung in agilen Organisationen aussehen?
Modern Leadership – Wie kann moderne Personalführung in agilen Organisationen aussehen?

Bei der Umstellung einer Organisation in Richtung Agilität wird die Frage nach der Verortung der personellen Führung meist heftig diskutiert. Das Thema ist hoch-politisch und „Existenz-bedrohend“. Ergebnisse reichen von eher traditionellen Lösungen bis hin zu sehr progressiven.

Der Vortrag stellt vier grundlegende und unterschiedliche Modelle von personeller Führung in einer agilen Umgebung vor. Die vier Varianten decken die heute gängigsten Alternativen ab, von den bekannten agilen bis hin zu einer expliziten personellen Führungsrolle.

Zielpublikum: Manager, Entscheider, Personaler, Agile Coaches, Organisationsentwickler:innen
Voraussetzungen: Grundlegende Kenntnisse agiler Rollen in Teams und in der Skalierung
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Im Vortrag wird anhand eines Kundenbeispiels vorgestellt, wie eine Entscheidungsfindung für eine der vier Varianten anhand eines Anforderungskatalogs ablaufen kann. Das gezeigte Vorgehen ist anhand des Modells bzw. Anpassungen für den eigenen Kontext und den Rahmen des Anforderungskatalogs übertragbar, d.h. es gibt dem Zuhörer ein Schema an die Hand, wie er Lösungsoptionen für seinen eigenen Kontext erarbeiten kann.

Was Zuhörer mitnehmen:
* Kenntnis 4 grundlegender Varianten für personelle Führung in der Praxis
* ein Schema, wie diese Varianten gegen einen individuellen Kontext evaluiert werden können

Alex Birke ist Buchautor, Berater und Coach für Business Agility. Er leitet den agilen Bereich von Accenture, Accenture Business Agility, im deutschsprachigen Raum. Seit 15 Jahren fokussiert er sich auf die Nutzung lean & agiler Methoden bei der Skalierung von Bereichen mit mehreren hundert bis zu mehreren tausend Personen. Er spricht regelmäßig auf Konferenzen und war über 10 Jahre als Lehrbeauftragter an der Universität Passau tätig.

Alexander Birke
Alexander Birke
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Do 7.2
Scale to Zero with Java and Save the Planet (and Money)
Scale to Zero with Java and Save the Planet (and Money)

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.

Richard Fichtner is CEO and Principal Software Architect at XDEV Software GmbH and has worked in the software industry for more than 15 years, often at the interface between business and technology. He is involved in the open-source community to spread knowledge about Java technologies. He speaks at conferences and contributes to various open-source projects such as https://www.rapidclipse.com/. Richard is a leader of the Java User Group Oberpfalz, recognized as Oracle ACE and holds a Master of Science degree in applied computer science. He is passionate about enabling developer productivity and supports teams in the use of cloud solutions. His interests are Java, clean code, cloud, new technologies and everything pragmatic.

Richard Fichtner
Richard Fichtner
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Do 8.2
Hardware-in-the-Loop und Continuous Integration – wie passt das zusammen?
Hardware-in-the-Loop und Continuous Integration – wie passt das zusammen?

Jede kleine Änderung an einem Embedded System kann bösartigste Auswirkungen haben. Findet und behebt man die Probleme zu spät, ist die Behebung zudem sehr teuer.

In Vortrag und Demo wird gezeigt, wie man durch Verbindung von Hardware-in-the-Loop und Continuous Integration jede Änderung an einem Embedded System innerhalb von Minuten testen kann, statt lange auf die Durchführung von Systemtests zu warten.

Zielpublikum: Architekt:innen, Embedded Entwickler:innen, Qualitätsmanager, Projektleiter:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Jede kleine Änderung an einem Embedded System kann bösartigste Auswirkungen haben. Findet und behebt man die Probleme zu spät, ist die Behebung zudem sehr teuer.

Daher sollte jede Änderung an einem Embedded System innerhalb von Minuten getestet werden können. Nur so kann man sicherstellen, dass man die Probleme schnell entdecken und beheben kann.
Bei reinen Softwareprojekten hilft eine vollständige Automatisierung der Tests über Continuous Integration (CI). Hierbei löst jede Codeänderung automatisch den Bau und Test der kompletten Software aus. Dadurch kann innerhalb von Minuten ein vollständiger Regressionstest Fehler in bestehendem und neuem Code entdecken.

Aber wie kann man das für System- oder Integrationstests bei Embedded Systemen erreichen?

Dafür nötige Hardware-in-the-Loop-Tests (HIL-Test) oder manuelle System-Tests sind häufig schwer zu automatisieren.

* Echte Hardwareanteile im Testaufbau verhindern die Automatisierung und Wiederholbarkeit
* Häufig kann nur der "Happy Path", nicht aber ein Fehlverhalten getestet werden
* Der Teststand ist häufig zu teuer, um für jedes Projekt, jederzeit für Automatisierung verfügbar zu sein

Durch den leichtgewichtigen Hardware-in-the-Loop-Test mit dem miniHIL kann man die Tests vollständig über Continuous Integration automatisieren.
Wie geht das?

* Hardwareschnittstellen werden nur auf Signalebene simuliert und passen daher gut in die Test-Automatisierung
* Testhardware wird größtenteils durch Softwaresimulationen ersetzt
* Fehlverhalten kann einfach über fehlerhafte Signale simuliert und getestet werden
* Die dazu nötige Hardware ist signifikant einfacher, kleiner und preiswerter als traditionelle HIL-Systeme. Für jedes Projekt steht jederzeit ein eigener Testaufbau für die Automatisierung zur Verfügung.

So kann jede Änderung innerhalb von Minuten automatisch getestet werden. Erst durch die vollständige und schnelle Testautomatisierung kann effektiv in Teams gemeinsam komplexe Embedded Software entwickelt werden.
Der Vortrag schließt mit einer Live-Demo eines solchen Testaufbaus.

Thomas Schütz studierte Luft- und Raumfahrttechnik in München und gründete 1997 die PROTOS Software GmbH. Als Softwareprojektleiter oder Architekt konnte er seine Erfahrung in der Verbindung modellbasierter Ansätze mit den Anforderungen von Embedded Systemen in zahlreiche Projekte einbringen. Thomas Schütz berät Firmen beim Aufbau von domänenspezifischen Werkzeugketten und Testsystemen für Embedded Systeme und ist Projektleiter des Eclipse-Projektes eTrice.

Thomas Schütz
Thomas Schütz
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Do 9.2
OpenTelemetry from an Ops Perspective
OpenTelemetry from an Ops Perspective

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!

Philipp Krenn lebt für technische Vorträge und Demos. Nachdem er mehr als zehn Jahre als Web-, Infrastruktur- und Datenbank-Entwickler gearbeitet hat, ist er mittlerweile Developer Advocate bei Elastic — dem Unternehmen hinter dem Open Source Elastic Stack, bestehend aus Elasticsearch, Kibana, Beats und Logstash. Auch wenn er in Wien zu Hause ist, reist er regelmäßig durch Europa und darüber hinaus, um über Open-Source-Software, Suche, Datenbanken, Infrastruktur und Sicherheit zu sprechen.
---------
Philipp Krenn lives to demo interesting technology. Having worked as a web, infrastructure, and database engineer for over ten years, Philipp is now a developer advocate and EMEA team lead at Elastic — the company behind the Elastic Stack consisting of Elasticsearch, Kibana, Beats, and Logstash.

Philipp Krenn
Philipp Krenn
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Do 1.3
Komplexität beherrschbar machen – Ein Denkmodell für Strukturen im Systems Engineering
Komplexität beherrschbar machen – Ein Denkmodell für Strukturen im Systems Engineering

Eine der größten Herausforderungen im Systems Engineering ist die viel beschworene Beherrschung der Komplexität. Bisher in der Praxis etablierte Ansätze betrachten die Strukturierung von Anforderungen und die Dokumentation der Realisierung durch die entsprechenden Architekturelemente. Aber was ist mit den Testfällen, dem Feature-Tree für Produktvarianten und der Organisationsstruktur? Diese Strukturen gilt es im Rahmen der Systementwicklung angemessen zu berücksichtigen und nachvollziehbar mit anderen Arbeitsergebnissen in Beziehung zu setzen.

Zielpublikum: Entwickler:innen, Architekt:innen, Requirements-Engineers, Systems Engineers
Voraussetzungen: Verständnis zum Zusammenspiel der Entwicklungsdisziplinen
Schwierigkeitsgrad: Experte

Extended Abstract:
Bei der Entwicklung von komplizierten technischen Systemen treffen unterschiedliche Disziplinen wie Anforderungs- und Architekturentwicklung, Test und Abnahme etc. aus verschiedenen Gewerken (Software- und Hardwareentwicklung) aufeinander. Trotz unterschiedlicher Ausrichtungen und Schwerpunkte leisten alle Beteiligten einen Beitrag in Form von Arbeitsergebnissen zum fertigen Produkt. Jedoch unterscheiden sich diese Arbeitsergebnisse häufig in ihrer Darstellung, betrachten aber letztlich doch das gleiche System und stehen dadurch inhaltlich in einem Zusammenhang.

Eine wesentliche Herausforderung ist es, diese Zusammenhänge in den Arbeitsergebnissen (Anforderungen, Architekturdokumentation, Testfälle etc.) transparent zu machen und zu nutzen, um dadurch disziplinen- und gewerkübergreifend eine durchgängige Systementwicklung zu gewährleisten. Für Anforderungen und Architekturdokumentationen haben sich dafür sowohl das Twin-Peaks-Modell als auch das SPES 2020-Framework mit dem RFLP-Ansatz etabliert. Beide Modelle vernachlässigen allerdings weitere Disziplinen der Systementwicklung wie z. B. Integration, Test und Abnahme oder das Produkt- und Portfoliomanagement und verzichten auf eine Betrachtung der dabei erzeugten Arbeitsergebnisse. Und wie sind diese Disziplinen eigentlich in der Organisation verortet? Welche Abteilung oder welches Team leistet welchen Beitrag am Gesamtprodukt?

Ziel dieses Vortrages ist es, ein Denkmodell zu vermitteln, das unterschiedliche, graphen- oder baumartige Strukturen und Sichten miteinander in Beziehung setzt, um dadurch typische Probleme in der Systementwicklung wie z. B. unklare Verantwortlichkeiten transparent zu machen und zu lösen. Anhand eines durchgängigen Beispiels erfahren Sie, welche weiteren Sichten neben den Anforderungen und der Architekturdokumentation auf unterschiedlichen Abstraktionsebenen in der Systementwicklung (System, Subsysteme, Komponenten) sinnvoll sein können. Neben einer Motivation, den Inhalten dieser Sichten und deren Wechselwirkungen erhalten Sie einen Einblick, welche Probleme mithilfe dieses Denkmodells gelöst werden können.

Dominik Häußer ist Berater und Trainer bei den SOPHISTen. Er unterstützt Kunden unterschiedlichster Branchen bei der Erhebung von Anforderungen, der Dokumentation von Architekturen und der Weiterentwicklung unterschiedlichster Systeme. Im Bereich Systems Engineering hat er erfolgreich Methoden entwickelt, eingeführt und angewendet. Ihn inspiriert die Vorstellung, dass bessere Systeme das Leben von Menschen erleichtern und wir alle Potenziale besser nutzen.

Dominik Häußer
Dominik Häußer
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Do 2.3
Von sicher bis ambivalent. Bindungsmuster in der Führung.
Von sicher bis ambivalent. Bindungsmuster in der Führung.

Führung ist Beziehungsarbeit. Doch woher kommt unsere Kompetenz, Beziehungen zu gestalten?

In diesem Vortrag beginnen wir unsere Reise bei den Grundlagen der Bindungstheorie. Wir bekommen Antworten auf die Frage nach den Einflüssen unserer ersten Bindungserfahrungen als Mensch. Du erfährst deine Bindungstypen und bekommst am Ende der Reise Impulse an die Hand, was du tun kannst, um als Führungskraft und Coach deine Beziehungskompetenzen zu verbessern.

Zielpublikum: Manager, Entscheider, Scrum Master, Agile Coaches
Voraussetzungen: Führungserfahrung
Schwierigkeitsgrad: Anfänger

Extended Abstract:
- Grundlagen der Bindungstheorie
- Einfluss unserer ersten Bindung auf uns als Menschen
- Deine Bindungstypen
- Einfluss der Bindungstypen auf Beziehungsarbeit (in Führung und Coaching)
- Impulse zum Selbstcoaching

Emel Siegel hat langjährige Erfahrung als Software-Entwicklerin in agilen Umgebungen. Seit mehreren Jahren ist sie als Scrum Master und Team-Coach in Unternehmen – vom Großkonzern bis zum agilen Start-up – unterwegs und unterstützt selbstorganisierte Teams sowohl auf der prozessualen also auch auf der menschlichen Ebene, das Beste aus sich herauszuholen. Um ihre Teams und Menschen in ihrer Umgebung besser zu unterstützen, beschäftigt sie sich aktuell auch mit therapeutischen Inhalten. Sie brennt dafür, Menschen zum Lernen anzuregen.

Emel Siegel
Emel Siegel
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Do 3.3
Leadership auf Augenhöhe
Leadership auf Augenhöhe

Du hast das Gefühl, die Entwickler tun nicht das, was du ihnen sagst? Das Team übernimmt keine Verantwortung für das Sprintergebnis? Sie sind viel zu ruhig während des Meetings und freuen sich, wenn sie wieder in Ruhe arbeiten dürfen? Dabei hast du doch extra agile Methode eingeführt, um schnell, transparent und produktzentriert zu arbeiten.

Was läuft also schief? Diese Session liefert dir den notwendigen Rahmen und passende Antworten.

Zielpublikum: Projektleiter:innen, Entscheider, Product Owner, Management, Geschäftsführung
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Anfänger

Extended Abstract:
In dieser Session lernst du:

•    Welches Umfeld agiles Arbeiten erfordert.
•    Wie du näher an deine Entwickler rückst.
•    Wie wichtig Konflikte sind.
•    Wie wichtig es ist, dass dein Team wirklich enabled und auch empowered ist.

Ina Einemann ist als Agile Coach bei der Open Knowledge GmbH in Oldenburg tätig. Ihr Tätigkeitsumfeld umfasst neben ihrer Arbeit als Scrum Master auch Aufgaben aus dem Bereich PO und Requirements Engineering. Sie beschäftigt sich mit agilen Methoden und Vorgehensmodellen und berät Teams bei der Umsetzung agiler Praktiken. Sie ist außerdem einer der Hosts des Podcast "Mein Scrum ist kaputt".

Ina Einemann
Ina Einemann
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Do 4.3
Komponierbare UI-Komponenten
Komponierbare UI-Komponenten

Mit React kam die Welt der Webentwicklung zum ersten Mal mit der funktionalen Programmierung in Kontakt und war verliebt. Doch das Versprechen simpler, nachvollziehbarer Programmlogik wird bei komplexeren Anwendungen oft nicht eingelöst. Das grundlegende Problem ist, dass wir unsere Programmstücke im Frontend zwar Komponenten nennen, uns aber die wichtigste Zutat aus der funktionalen Programmierung fehlt, um diese Benennung rechtfertigen zu können: Komposition. Dass es auch anders geht, zeigt dieser Vortrag.

Zielpublikum: Architekt:innen, Entwickler:innen, Entscheider
Voraussetzungen: Grundlegendes technisches Verständnis moderner Frontend-Frameworks wie React, Vue, Angular etc.
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Ein Jahrzehnt ist es mittlerweile her, dass React das Frontend revolutionierte. Die Welt der Webentwicklung kam zum ersten Mal mit der funktionalen Programmierung in Kontakt und war verliebt. Doch das Versprechen simpler, nachvollziehbarer Programmlogik wird bei komplexeren Anwendungen oft nicht eingelöst. Wir greifen wieder auf Hilfsmittel zurück, die wir eigentlich abschütteln wollten: Globaler Zustand, mutierbare Daten. Das grundlegende Problem ist, dass wir unsere Programmstücke im Frontend zwar Komponenten nennen, uns aber die wichtigste Zutat aus der funktionalen Programmierung fehlt, um diese Benennung rechtfertigen zu können: Komposition.

Dass es auch anders geht, zeigt dieser Vortrag. Wir führen ein in die Welt komponierbarer Komponenten. Das ist eine Welt ohne Redux und ohne Callbacks, aber dafür mit guter Testbarkeit, exzellenter Wiederverwendbarkeit und hervorragendem seelischem Wohlbefinden. Wir setzen damit die Versprechen der funktionalen Programmierung fort, insbesondere für sehr komplexe Anwendungen.

Markus Schlegel ist Software-Architekt bei der Active Group GmbH in Tübingen. Wir entwickeln Software ausschließlich mit funktionaler Programmierung. Markus interessiert sich neben der funktionalen Programmierung auch für GUI-Design, Nebenläufigkeit und Formale Methoden.

Markus Schlegel
Markus Schlegel
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Do 5.3
Leading AI Transformations
Leading AI Transformations

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

Zorina Alliata is a Sr. Machine Learning Strategist at Amazon, working with global customers to find solutions that speed up operations and enhance processes using Artificial Intelligence and Machine Learning. Zorina helps companies across several industries identify strategies and tactical execution plans for their ML use cases, platforms, and ML at scale implementations.

Zorina Alliata
14:30 - 15:30
Do 6.3
Head ‘n’ HeartOps – A User's Guide to Emotions without “System Crashes”
Head ‘n’ HeartOps – A User's Guide to Emotions without “System Crashes”

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...

Cosima Laube is an independent agile coach, leader & consultant with experience in a variety of industries (automotive, finance, healthcare, travel, public sector).
Having a strong background as developer and people lead in IT engineering, over the last decade Cosima enhanced her portfolio with solid coaching skills (ICF-PCC) and university studies focused on I/O- and Health Psychology. Besides work, you likely find her running or on a bike. Her credo at work and in life is: Achieving MORE - together!

Cosima Laube
Cosima Laube
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Do 7.3
Patterns of Sustainability – Going Green in IT
Patterns of Sustainability – Going Green in IT

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.

Uwe Friedrichsen travels the IT world for many years, always in search of innovative ideas and concepts. His current focus areas are system design, resilience, sustainability and making IT a (bit) better place. Often, you can find him on conferences sharing his ideas, or as author of articles, blog posts, tweets and more.

Uwe Friedrichsen
Uwe Friedrichsen
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Do 8.3
Wie viele Grenzwerte sollte man testen?
Wie viele Grenzwerte sollte man testen?

Grenzwertanalyse ist ein weit verbreitetes Verfahren mit dem Ziel, Fehlerzustände bei Vergleichen aufzudecken. Populär ist die Abdeckung von zwei oder drei Werten je Grenze. An einem praktischen Beispiel zeigt der Autor, dass drei Werte nicht immer ausreichen.
Im Vortrag präsentiert er einen neuen Ansatz aus 2021, der auf Mutationsanalyse basiert. Anschließend geht der Autor darauf ein, wie die Anzahl der Grenzwerte eines Parameters bei mehreren Grenzen optimiert werden kann.

Zielpublikum: Tester, Testanalysten, Entwickler:innen mit Interesse am Testen (SDET)
Voraussetzungen: Grundkenntnisse in Testen, z. B. CTFL, Grundkenntnisse der Programmierung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Grenzwertanalyse ist ein weit verbreitetes Verfahren mit dem Ziel, Fehlerzustände bei Vergleichen aufzudecken. Populär ist die Abdeckung von zwei oder drei Werten je Grenze. An einem praktischen Beispiel eines nicht seltenen Codierfehlers in einer kritischen Anwendung zeigt der Autor, dass alle drei üblichen Grenzwerte den Test bestehen und den Fehlerzustand unentdeckt lassen. Im Vortrag präsentiert er einen neuen mutationsbasierten Ansatz von Kovács und Forgács (Paradigm Shift in Software Testing, 2021). Bei einem Mutationstest wird eine korrekte Implementierung der Spezifikation zu einer fehlerhaften Variante abgewandelt (mutiert), und es werden Eingaben gesucht, bei denen diese Mutation ein vom Erwarteten abweichendes Ergebnis verursacht. Die Herausforderung hierbei ist, dass es zu jeder endlichen Anzahl von Eingaben unendlich viele fehlerhafte Codes gibt, die bei den gewählten Eingaben das korrekte Ergebnis bringen, aber bei anderen nicht. Beim Mutationstest nimmt man deshalb an, dass der Programmierer kompetent ist und nur sporadisch Fehler macht. Gestützt auf empirische Studien beschränkt man sich auf Mutationen erster Ordnung (d. h., nur ein Element des korrekten Codes mutiert). Bei einem Vergleich kann es sich dabei um eine Mutation der Operanden oder des Operators handeln. Das führt zu einer gut begründeten Antwort auf die gestellte Frage, wie viele Grenzwerte man zu einer Grenze testen soll: so viele, dass alle Mutationen erster Ordnung des Vergleichs überdeckt werden. Es sind die vier Grenzwerte "ON, OFF, IN und OUT" von Offutt (Introduction to Software Testing, 2016), welche die richtige Balance von minimaler Anzahl von Testfällen (Effizienz) und vollständiger Überdeckung der Mutanten (Effektivität) erbringen.
Der Autor veranschaulicht die Anwendung an konkreten Beispielen von Spezifikationsfragmenten und geht auch auf die Möglichkeit der automatischen Testfallgenerierung ein. Schließlich wird die Frage auf Parameter mit mehreren Grenzen erweitert. Auch hier kann die Anzahl der Grenzwerte systematisch optimiert werden, indem man z. B. den IN-Wert der einen Äquivalenzklasse gleichzeitig als OUT-Wert der benachbarten Klasse nutzt. Die Lösung hängt davon ab, ob die Äquivalenzklassen zwischen den Grenzen aus einem, zwei oder mehreren Elementen bestehen.

Matthias Hamburg war bis zu seiner Pensionierung in 2019 Managing Consultant bei der Sogeti Deutschland GmbH. Seine fachlichen Schwerpunkte sind bei der Testanalyse, Testmanagement und Testprozessverbesserung. Im German Testing Board (GTB) und seinem Dachverband ISTQB engagiert er sich weiterhin ehrenamtlich. Unter anderem gibt er den Advanced Test Analyst Lehrplan und das Standardglossar der Testbegriffe in Englisch und in Deutsch heraus.

Matthias Hamburg
Matthias Hamburg
Vortrag: Do 8.3
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Do 9.3
Kontinuierlich und automatisiert dokumentieren – Docs-as-Code in der Praxis
Kontinuierlich und automatisiert dokumentieren – Docs-as-Code in der Praxis

Im Gegensatz zu den klassischen Ansätzen verfolgt Docs-as-Code das Ziel, die in Softwareprojekten relevante Dokumentation genau wie den Quelltext zu behandeln. Somit können die gleichen Werkzeuge wie für die Entwicklung verwendet werden, um die Erzeugung und Auslieferung in die automatisierten Build-Prozesse einzubinden.

Jedwede Art von Dokumentation gewinnt somit an Sichtbarkeit und durch die Eingliederung in die Entwicklungsprozesse und die damit verbundene kontinuierliche Weiterentwicklung steigen Qualität und Akzeptanz bei den Lesern.

Zielpublikum: Architekt:innen, Entwickler:innen, Entscheider
Voraussetzungen: Grundlegende Kenntnisse von Architekturdokumentation und für automatisiertes Build-Management
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Dokumentation wird häufig vernachlässigt. Mit dem Docs-as-Code-Ansatz wird die in Softwareprojekten relevante Dokumentation genau wie Quellcode behandelt, in der Versionsverwaltung abgelegt, mit leichtgewichtigen Entwicklerwerkzeugen (IDE/Texteditor, Build-Tools, CI/CD-Pipelines) bearbeitet und in die Softwareentwicklungsprozesse integriert. Die Inhalte können redundanzfrei verwaltet und manche Informationen aus Modellen oder dem Quellcode generiert werden. Durch die Verwendung leichtgewichtiger Text- und Grafikformate lassen sich die Ergebnisse einfach zielgruppenorientiert zusammenstellen. Die Verarbeitung erfolgt automatisiert über die schon vorhandenen Build-Prozesse.

Jedwede Art von Dokumentation gewinnt somit an Sichtbarkeit, durch die Eingliederung in die Entwicklungsprozesse und die damit verbundene kontinuierliche Weiterentwicklung steigt die Qualität und damit die Akzeptanz bei den Lesern. Dokumentation kann sogar ausgeführt werden, um zum Beispiel eingebettete Architekturregeln regelmäßig automatisiert zu testen. Die Zuhörer erfahren in diesem Vortrag an konkreten Beispielen, wie sie mit Documentation as Code starten können, welche typischen Fallstricke sie umschiffen und mit welchen konkreten Tools sie am besten arbeiten sollten.

Falk Sippach ist bei der embarc Software Consulting GmbH als Software-Architekt, Berater und Trainer stets auf der Suche nach dem Funken Leidenschaft, den er bei seinen Teilnehmern, Kunden und Kollegen entfachen kann. Bereits seit über 15 Jahren unterstützt er in meist agilen Softwareentwicklungsprojekten im Java-Umfeld. Als aktiver Bestandteil der Community (Mitorganisator der JUG Darmstadt) teilt er zudem sein Wissen gern in Artikeln, Blog-Beiträgen, sowie bei Vorträgen auf Konferenzen oder User Group-Treffen und unterstützt bei der Organisation diverser Fachveranstaltungen.

Falk Sippach
Falk Sippach
flag VORTRAG MERKEN

Vortrag Teilen

15:45 - 16:30
KeyDo 2
KEYNOTE: Making Sure the New Platform is Actually an Improvement
KEYNOTE: Making Sure the New Platform is Actually an Improvement

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.

Christin Gorman has more than 20 years experience with hands-on software development. She is currently working on a large migration project in the Norwegian healthcare sector. She has worked for both startups and large enterprises, on systems varying from real-time control systems to e-commerce. What is important in one field is not necessarily important in others. Both in writing and in presentations, she is known for her entertaining way of raising questions about established truths, and making people think about why they are working the way they do.
Sometimes controversial, but never boring.

Christin Gorman
Christin Gorman
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Do 1.4
Distributed Application Architecture Options – Frameworks, Kubernetes, Service Mesh & eBPF
Distributed Application Architecture Options – Frameworks, Kubernetes, Service Mesh & eBPF

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.

Matthias Haeussler ist Principal Cloud Advocate bei der NovaTec Consulting GmbH und der Veranstalter des Stuttgart Cloud Foundry Meetups. Er berät Kunden bei deren Cloud Strategie und unterstützt aktiv Implementierungen und Migrationen. Daneben unterrichtet er Cloud Native Development an den Hochschulen für Technik in Stuttgart und Esslingen. Davor war er über 15 Jahre bei der IBM R&D beschäftigt. Er hält regelmäßig Vorträge auf nationalen sowie internationalen Konferenzen und Meetups wie z.B. WJAX, OOP, den IT Tagen sowie der KubeCon, IBM InterConnect & Cloud Foundry Summit.

Matthias Haeussler
Matthias Haeussler
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Do 2.4
Die Balance ist nicht eine Art Mitte – sie schwebt über der Mitte und wird oft nicht gesehen
Die Balance ist nicht eine Art Mitte – sie schwebt über der Mitte und wird oft nicht gesehen

Normallogik verortet eine Balance irgendwo "in der Mitte" eines vorgestellten Kontinuums. Da ist sie nicht; dort sind die Kompromisse. Die kann man beschreiben, aber Balance muss systemisch verstanden werden. Sie ist den Unternehmen in vielen Aspekten verloren gegangen: Auslastung wurde zur Überlastung, Innovation zu Einsparungs-Manie; ade Vertrauen, gutes Betriebsklima und Kundenfokus. Es herrscht die irre Überzeugung, jede Art von "Rückkehr" zur Vernunft kostet Geld. Nein! Ein kompromissloser Aufruf zum Blick aus dem Jammertal.

Zielpublikum: Alle
Voraussetzungen: Normale Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Niedere Wissenschaft und landläufige Normallogik verorten eine Balance irgendwo "in der Mitte" eines vorgestellten Kontinuums. Da ist sie nicht; dort sind die Kompromisse. Die kann man beschreiben, aber Balance muss systemisch verstanden werden. Natürlich hat Aristoteles so eine Mitte zwischen Extremen beschrieben: mesotes - kein Übermaß, kein Mangel. Platon lässt Sokrates aber viel systemischer über Sophrosyne diskutieren, um weise Selbstbeherrschung, Besonnenheit und Maß als einen guten (tugendhaften) Zustand zu verstehen. Da geht es eben um dieses "Ganze über den Teilen", das es sich nicht mit einer bloßen "Kein-Mangel-kein-Übermaß-Betrachtung" zu einfach macht.

Der exzessive Fokus auf Gewinne hat zum Verlust von Sophrosyne geführt; es wurde an einer einzigen Stelle ein Überfluss zu erzeugen versucht, der überall sonst im Mangel mündete. Ein gutes Unternehmen aber hat alles im Lot, im Maß und in der Balance: gute Kundenbeziehungen, Vertrauen, Wohlfühlklima, Innovation etc. UND Gewinn. Das unbesonnene Unternehmen mag eine Zeit lang Gewinne scheffeln, verausgabt sich aber und endet vielleicht schnell in einem Burnout.

Es hat schon in den 90er Jahren Warner gegeben, die den Verlust der Balance anprangerten. Es wurde eine Weile Mode, sogenannte Balanced Scorecards einzuführen. Die Unternehmen wollten sie aber nicht nutzen, um in der Balance zu bleiben, sondern um noch MEHR Gewinn zu erzielen. Dieses Laster leg(t)en sie nicht ab ... Heute gibt es Hype um Resilienz und der Balance ähnliche Hypes, die wieder nur den Fokus auf "das Eine" nicht lassen: Gewinnsteigerung.

Diesen Ganz-Zustand der Sophosyne muss man systemisch verstehen, um ihn zu erreichen oder um wieder zu ihm zurückzukehren, wenn Innovation, Exzellenz etc. verloren gingen, keine Reserven mehr da sind und geschundene Mitarbeiter innerlich kündigen.

Wie kehrt man zurück? Die Unternehmen schaudern vor dem Gedanken, den erkannten und beraterbestätigten Mangel bei der Mitarbeiter-Bezahlung, im Kundenvertrauen oder bei Innovationen zu beheben - für sie sieht es nach einem finanziellen Desaster aus, dessen Erfolg ihnen zudem vollkommen ungewiss erscheint. Sie scheuen die Balance, weil sie sie nicht mehr verstehen.
In meinem letzten Buch ("Keine Sinnfragen, bitte!") habe ich diesen Missstand in einem Wort zusammengefasst: "das Ausreichend-Unternehmen". Es versteht das Ganze nicht, versteht nicht, dass man es verstehen sollte, und vergrätzt die letzten vorhandenen "Einser-Mitarbeiter", die enttäuscht und ohne Hoffnung gehen. Es fixt nur noch Probleme, um nicht zu einem Mangelhaft-Unternehmen zu verkommen. Es erhebt nicht mehr den Blick zur Balance. Es fokussiert sich auf das Kontinuum zwischen "null Fehler" und "viele Fehler".

Wie kommen Unternehmen da heraus? Ich habe oft zu erklären versucht, dass ein guter Schüler ("Balance") weniger arbeiten muss als einer, dessen Versetzung bedroht ist und der Nachhilfe bekommt. Nicht einmal diese Wahrheit wird als solche erkannt. Ich bekomme die Antwort, dass die guten Schüler eben Talent hätten. Das kann sein, aber eigentlich leben sie "besonnen", was der Ausreichend-Schüler nicht versteht und zudem meist als eine lustfeindliche Haltung (zu wenig Gewinn) ablehnt.

Balance heißt nicht, mehr nach rechts oder links zu rücken. Meist müssen "die Gewohnheiten neu geprägt werden". Vielleicht ist das doch eine Art Intelligenz-Unterschied? Zwischen gut und ausreichend? Zwischen Agilität und "Wasserfall"? Dann wäre die Balance als Mitte verstanden das, was jeder versteht, aber Sophrosyne läge höher?

Gunter Dueck (Jahrgang 1951) lebt als freier Schriftsteller, Philosoph, Business Angel und Speaker bei Heidelberg. Nach einer Karriere als Mathematikprofessor arbeitete er fast 25 Jahre bei der IBM, zuletzt bei seinem Wechsel in den Unruhestand als Chief Technology Officer. Er ist für humorvoll-satirisch-kritisch-unverblümte Reden und Bücher bekannt, zuletzt „Schwarmdumm“, „Heute schon einen Prozess optimiert?“ und „Keine Sinnfragen, bitte!“

Gunter Dueck
Gunter Dueck
Vortrag: Do 2.4
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Do 3.4
You're in Charge – Now What?
You're in Charge – Now What?

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.

Giovanni Asproni is a co-founder and CTO at Launch Ventures, https://launchventures.co. Before co-founding Launch Ventures he has worked for many years as a developer, architect, and consultant in projects of all sizes.
His expertise ranges from software design and programming to software project management, and agile software development. He has contributed two chapters to the book ’97 Things Every Programmer Should Know’ published by O’Reilly.

Giovanni Asproni
Giovanni Asproni
flag VORTRAG MERKEN

Vortrag Teilen