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

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

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

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

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

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

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

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

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

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

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

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.

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.

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.

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

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!

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.