Konferenzprogramm

Die im Konferenzprogramm der OOP 2024 angegebenen Uhrzeiten entsprechen der Central European Time (CET).

Track: Architecture – for Humans?

Nach Tracks filtern
Nach Themen filtern
Alle ausklappen
  • Dienstag
    30.01.
  • Mittwoch
    31.01.
  • Donnerstag
    01.02.
, (Dienstag, 30.Januar 2024)
09:00 - 10:30
Di 1.1
Leading a Software-Architecture Revolution
Leading a Software-Architecture Revolution

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

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

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

Joseph (Joe) Yoder is a research collaborator at IME/USP, owner of The Refactory, and president of the Hillside Group which is dedicated to improving the quality of life of everyone who uses, builds, and encounters software systems. Joe is best known for the Big Ball of Mud pattern, which illuminates many fallacies in software architecture. Recently, the ACM recognized Joe as a Distinguished Member in the category of "Outstanding Engineering Contributions to Computing".

Joseph Yoder
Raum 01
Joseph Yoder
Raum 01

Vortrag Teilen

14:00 - 14:45
Di 1.2
These are not the architectures you’re looking for… What agile development needs from architecture
These are not the architectures you’re looking for… What agile development needs from architecture

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

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

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

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

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

English below

Heutzutage verbringt Michael die meiste Zeit in der Organisationsentwicklung und unterstützt Kunden bei ihrer Suche nach effektiveren Arbeitsmethoden. Oft durch die Anwendung von Lean- und Agile-Konzepten. Michael macht seit den 1990ern Zeugs, das heute Agil heißt (wie z.B. FDD und XP), hatte um 2005 eine intensivere Scrum Phase und ist seit 2008 mit der Kanban-Methode involviert. Unter anderem war er 2011 Co-Gründer der  Kölner "Limited WIP Society" (Kanban User Group) und ist regelmäßiger Sprecher auf diversen Konferenzen zum Thema. Obwohl –oder eigentlich gerade weil– er derzeit vor allem größere Organisationen übergreifend im Wandel begleitet, ist ihm der hilfreiche Einsatz von Methoden gerade auf persönlicher Ebene und auf Teamebene eine Herzensangelegenheit. Michaels Mantra: Accept Reality.
----------
These days, Michael Mahlberg spends most of his time in organizational development, helping clients find more effective ways of working. Often by applying concepts from Lean and Kanban. His strong commitment to software architecture makes him change hats every now and then and the collaboration with software architects from the last 20 years is the basis for this talk.

Michael Mahlberg
Raum 13a
Michael Mahlberg
Raum 13a

Vortrag Teilen

16:15 - 17:15
Di 1.3
Architektur: Den menschlichen Faktor verbessern!
Architektur: Den menschlichen Faktor verbessern!

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

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

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

Eberhard Wolff ist Head of Architecture bei SWAGLab und arbeitet seit mehr als zwanzig Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Geschäft und Technologie. Er ist Autor zahlreicher Artikel und Bücher, 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, Domain-Driven Design und Microservices.

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

Eberhard Wolff
Raum 01
Eberhard Wolff
Raum 01

Vortrag Teilen

17:45 - 18:45
Di 1.4
Klonen nicht möglich – Wie man seine Architekturkompetenzen trotzdem schnell skaliert
Klonen nicht möglich – Wie man seine Architekturkompetenzen trotzdem schnell skaliert

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

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

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

Steffen Fischer ist IT-Architekt im Architekturmanagement bei der Provinzial Versicherung AG. Er hat langjährige Erfahrung als Chefarchitekt in komplexen IT-Projekten bei Finanzdienstleistern.

Dr. Philipp Saalmann arbeitet als Unternehmensarchitekt im Architekturmanagement der Provinzial Versicherung AG mit Schwerpunkt EAM-Methodik und -Werkzeuge.

Dr. André Wickenhöfer leitet den Bereich „IT-Standards & zentrale Aufgaben“ bei der Provinzial Holding AG und hat dort als Unternehmensarchitekt das Architekturmanagement mit aufgebaut und weiterentwickelt.

Steffen Fischer, Philipp Saalmann, André Wickenhöfer
Raum 13b
Steffen Fischer, Philipp Saalmann, André Wickenhöfer
Raum 13b

Vortrag Teilen

, (Mittwoch, 31.Januar 2024)
09:00 - 10:30
Mi 1.1
Moderne Architekturarbeit: Vom Vorgabenmachen zum Enabling
Moderne Architekturarbeit: Vom Vorgabenmachen zum Enabling

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

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

Extended Abstract:
Viele große Unternehmen arbeiten immer noch mit zentralisierten architekturbezogenen Teams. Deren Aufgabe besteht häufig darin, anderen Teams architektonische Spezifikationen vorzugeben und dafür zu sorgen, dass diese Spezifikationen bei der Umsetzung eingehalten werden. Diese Teams werden oft als "Elfenbeinturm-Architektur"-Teams bezeichnet, die darauf abzielen, hochqualifizierte Architekt:innen zu bündeln. Diese Rolle ist auf dem Markt sicherlich nicht in Hülle und Fülle vorhanden.
Sie passen jedoch nicht in eine agile Umgebung, in der wir den Teams die Möglichkeit geben wollen, ihre eigenen Entscheidungen zu treffen. Bestimmte Leitplanken sind dennoch notwendig, um sicherzustellen, dass das Gesamtkonstrukt funktioniert. Darüber hinaus können gut gewählte Leitplanken auch den Abstimmungsbedarf zwischen den Teams drastisch reduzieren.
Wir müssen diese Teams in die Lage versetzen, den größten Teil der architektonischen Arbeit selbst zu erledigen, und gleichzeitig dafür sorgen, dass die einzelnen Teile zusammenpassen. An dieser Stelle kommen Team Topologies ins Spiel, eine von Matthew Skelton und Manuel Pais eingeführte Methode. Dort gibt es den Teamtyp des "Enabling Teams", welches knapp zusammengefasst, andere Teams mit Wissen und Methodik unterstützt.
Dieser Vortrag gibt Ihnen einen Überblick über diesen Wandel sowie eine praktische Anleitung, wie Sie ein zentralisiertes Architekturteam in ein Enabling Team umwandeln können, dessen Aufgabe es ist, die Architekturarbeit in anderen Teams zu verbessern. Sie werden lernen:
1.    Welche Stakeholder Sie in diesen Prozess einbeziehen sollten
2.    Warum das künftige Enabling-Team ebenfalls befähigt werden muss und wie man das macht
3.    Wo häufige Fallstricke auf dieser Reise liegen
4.    Warum diese Reise auf agile Weise mit kontinuierlichem Lernen und Retrospektiven durchgeführt werden muss
Dieser Vortrag wird auch viele Beispiele aus der Praxis enthalten, die eine solche Transformation begleiten.

Michael Plöd ist Fellow bei INNOQ. Seine aktuellen Beratungsschwerpunkte sind Domain-driven Design, Team Topologies, soziotechnische Architekturen und die Transformation von IT-Delivery-Organisationen in Richtung Kollaboration und lose gekoppelter Teams. Michael ist zudem Autor des Buchs „Hands-on Domain-driven Design - by example“ auf Leanpub sowie regelmäßiger Referent auf nationalen und internationalen Konferenzen.

Landkarte für den Plattform-Dschungel: Orientierung im Plattform-Begriffswirrwarr
Landkarte für den Plattform-Dschungel: Orientierung im Plattform-Begriffswirrwarr

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

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

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

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

Matthias Naab engagiert sich seit Jahren dafür, Unternehmen digitale Ökosysteme und Plattformökonomie besser verständlich zu machen. Er ist Co-Founder von Full Flamingo mit dem Ziel, Plattformökonomie nicht nur zur Gewinnerzielung, sondern auch für Nachhaltigkeit zu nutzen.

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

Dominik Rost ist Software-Architekt und trägt mit Full Flamingo zur Rettung unseres Planeten bei. Als der Co-Founder für die Technik kümmert er sich um Systemdesign, Entwicklung und Technologie.

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

Michael Plöd
Raum 13a
Matthias Naab, Dominik Rost
Raum 13a
Michael Plöd
Raum 13a

Vortrag Teilen

Matthias Naab, Dominik Rost
Raum 13a

Vortrag Teilen

11:00 - 11:45
Mi 1.2
Mut zum Frontend ohne Framework – nativ, nicht naiv!
Mut zum Frontend ohne Framework – nativ, nicht naiv!

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

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

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

Jan Müller arbeitet seit 6 Jahren als Agile Software Engineer bei andrena objects ag. Aktuell ist er als Full-Stack-Entwickler in einem Scrum-DevOps-Projekt mit Java und TypeScript tätig. Bei seiner täglichen Arbeit liegt sein Augenmerk auf Clean Code und der pragmatischen Nutzung agiler Arbeitsweisen.

Jan Müller
Raum 12a
Jan Müller
Raum 12a

Vortrag Teilen

14:30 - 15:30
Mi 1.3
Von Microservices zu evolutionärer Systementwicklung in 60 Minuten
Von Microservices zu evolutionärer Systementwicklung in 60 Minuten

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

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

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

Stefan Toth ist Gründer der embarc GmbH und Autor zahlreicher Artikel sowie des Buchs "Vorgehensmuster für Softwarearchitektur" (Hanser). Als Berater begleitet er Start-ups, Mittelständler und Großkonzerne bei der organisatorischen, methodischen und technischen Neuausrichtung.

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, verteilten Systemen und evolutionärer Architektur umfasst seine Leidenschaft für Technologie auch die verschiedensten Auswirkungen von Software auf Unternehmen und gesellschaftliche Faktoren.

Stefan Toth, Alexander Kaserbacher
Raum 01
Stefan Toth, Alexander Kaserbacher
Raum 01

Vortrag Teilen

17:00 - 18:00
Mi 1.4
How Process Orchestration Increases Agility Without Harming Architecture
How Process Orchestration Increases Agility Without Harming Architecture

A main theme in modern architectures is around fine-grained, isolated, reactive components, that are managed by autonomous teams (think microservices). This is considered key to decoupling, which, in turn, leads to business agility. Unfortunately, this often goes wrong and people end up with more tightly coupled systems, that are hard to understand and change - the opposite of agility. In this talk, I will explore why this happens and provide my view on how process orchestration can improve the situation without harming any good architecture.

Target Audience: Architects, Lead Engineers, IT Decision Makers
Prerequisites: Basic knowledge in Microservice architecture
Level: Basic

Extended Abstract:
I will walk you through the challenges around event-driven systems and microservices, talking about orchestration and choreography, also showing you how to balance both architectural approaches.
I will further discuss the importance of looking at end-to-end processes before going into local automations, as local optimizations can actually harm the global result.
I will further compare different approaches to automate end-to-end processes, from batches over streaming to workflow engines. You will understand the impact on agility and get guidance on decision criteria, backed by examples collected in various real-life projects.
I will sketch what influence those architecture decisions have on the governance and enterprise architecture of organizations.

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

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 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". Additionally, he is a regular speaker at conferences around the world and a frequent contributor to several technology publications. He focuses on new process automation paradigms that fit into modern architectures around distributed systems, microservices, domain-driven design, event-driven architecture, and reactive systems.

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

Bernd Rücker
Raum 13b
Bernd Rücker
Raum 13b

Vortrag Teilen

, (Donnerstag, 01.Februar 2024)
09:00 - 10:30
Do 1.1
Where do we go from here? – mastering the changed needs of architectural work
Where do we go from here? – mastering the changed needs of architectural work

Designing good applications has become more demanding than ever: Extremely flexibility. Super-fast to change. Never down. Increasing user demands. Sustainability. Fewer developers. More AI. The list appears to be endless.
Many demands have not existed 10 or 15 years ago. Some have changed dramatically. Still, the discussions regarding architecture barely reflect that. In this session, we will take a look at how the architectural demands have changed and how to tackle the challenges of today best.

Target Audience: Architects, Senior Developers, Decision Makers
Prerequisites: Sound architectural knowledge makes the ideas presented easier to grasp
Level: Advanced

Extended Abstract:
Designing good applications has become more demanding than ever: Extremely flexibility. Super-fast to change. Never down. Demand-based scaling. Increasing user demands. Sustainability. APIs as first class citizens. Secure like a fortress. Fewer developers. More AI. The list appears to be endless.
Many of today's architecture demands have not existed 10 or 15 years ago. Some have changed dramatically. Still, most discussions regarding architecture seem to be stuck in the early 2000s.
In this session, we will take a look at how our application design demands have changed, what it means today to design good applications and how to tackle the challenges best.
Let us catch up together and learn what architectural work today means!

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

Uwe Friedrichsen ist langjähriger Reisender in der Welt der IT, Dot-Connector, Kartograph von Neuland, Bewahrer zeitloser Weisheiten sowie Übersetzer zwischen den Etagen bei Themen wie Systementwurf, Widerstandsfähigkeit und Nachhaltigkeit. Uwe verabscheut lange Biografien und versucht, die IT (ein bisschen) besser zu machen.

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

Effective Practices for Continuous Software Architecture
Effective Practices for Continuous Software Architecture

Continuous Software Architecture is an approach to software architecture that tries to move architecture from a set of up-front blueprints to a continually developed set of architectural knowledge and decisions. While a simple idea, actually putting it into practice can be difficult. In this talk we will briefly recap the idea of Continuous Software Architecture and then explore the key practices that are usually needed to achieve it, as well as the common problems and how to address them.

Target Audience: Architects, Developers, Technical Project Managers
Prerequisites: Some familiarity with agile development and modern architecture practice
Level: Advanced

Extended Abstract:
Continuous Software Architecture is a philosophy and approach to software architecture that embraces the fact that doing most of the design before the implementation does not work very well, and perhaps never did. The approach tries to move architecture to a continually developed set of architectural knowledge and decisions, stressing collective ownership of the resulting architecture. This talk will provide attendees with practical and actionable advice on implementing the five key practices of Continuous Architecture: Technical Leadership, Achieving Quality Attributes, Driving Design Decisions, Managing Technical Debt and Implementing Feedback Loops.

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

Eoin Woods is the Chief Engineer at Endava (www.endava.com) where he is responsible for delivery capability and innovation. In previous professional lives he has developed databases, security software and way too many systems to move money around. He is interested in software architecture, software security, DevOps and software energy efficiency. He co-authored three books on software architecture and received the 2018 Linda Northrup Award for Software Architecture, from the SEI at CMU.

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

Uwe Friedrichsen
Raum 05
Eoin Woods
Raum 05
Uwe Friedrichsen
Raum 05

Vortrag Teilen

Eoin Woods
Raum 05

Vortrag Teilen

11:00 - 11:45
Do 1.2
The Bright Side of Software-Architecture Communication – Erfahrungen aus drei Jahrzehnten
The Bright Side of Software-Architecture Communication – Erfahrungen aus drei Jahrzehnten

Projekte unterschätzen des Öfteren die Rolle der Software-Architektur als Kommunikationsmittel zwischen den Beteiligten. Eine Architektur hat allerdings unmittelbar Einfluss auf Usability, Habitability, also sowohl beim Nutzen der Architektur als auch beim Nutzen der Implementierung. Um dem gerecht zu werden, müssen diese Qualitäten schon bei der Architekturerstellung Berücksichtigung finden.
Der Vortrag zeigt auf, wie sich dieses Problem durch einen systematischen Ansatz vermeiden lässt.

Zielpublikum: Software-Architekt:innen
Voraussetzungen: Architekturgrundlagen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Projekte unterschätzen des Öfteren die Rolle der Software-Architektur als Kommunikationsmittel zwischen den Beteiligten. Die Architektur hat allerdings unmittelbar Einfluss auf Usability, Habitability, also sowohl beim Nutzen der Architektur als auch beim Nutzen der Implementierung. Um dem gerecht zu werden, müssen diese Qualitäten schon bei der Architekturerstellung Berücksichtigung finden. Ein weiteres Problem besteht darin, dass sich Architekten zu stark auf aktuelle Technologietrends wie Containerisierung, Microservices, KI/ML oder Cloud-Computing stützen, wo sie eher auf Qualitätsaspekte achten sollten. Das führt zu Systemen, die schwer verständlich, kommunizierbar, wartbar und erweiterbar sind.
Der Vortrag zeigt auf, wie sich dieses Problem durch einen systematischen Ansatz vermeiden lässt, in dem Software-Architektur seine Rolle als Kommunikationsmedium und Fundament für Usability-/Habitability-Aspekte erfüllen kann. Die Sicht der Beteiligten/Betroffenen auf die Architektur spielt dabei eine essenzielle Rolle.
Lernziele:

  1. Die Rolle von Software-Architektur als Kommunikationsmittel und Hilfsmittel für alle Projektbeteiligten und Betroffenen (zum Beispiel Nutzern) verstehen
  2. Einen systematischen Weg der Architekturerstellung kennenlernen, bei dem Usability und Habitability Beachtung finden
  3. Technologien gezielt einsetzen, ohne in die Technologiefalle zu tappen.

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

Michael Stal arbeitet bei der Siemens AG unter anderem an Software-Architekturen, verteilten Systemen und KI - sowohl in der Forschung als auch in Projekten. Zudem ist er als Professor an der Universität Groningen und als Chefredakteur von JavaSPEKTRUM tätig. Er verfügt über drei Jahrzehnte Erfahrung im Softwareengineering und hat Spaß daran, Wissen zu vermitteln.

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

Michael Stal
Raum 13b
Michael Stal
Raum 13b

Vortrag Teilen

14:30 - 15:30
Do 1.3
Zero Trust – Erfahrungsbericht
Zero Trust – Erfahrungsbericht

Zero Trust ist anfangs ein Schlagwort, das von jedem Unternehmen individuell interpretiert werden muss. Während Slogans wie "Never trust, always verify" allgemeine Zustimmung finden, gibt es schnell kontroverse Diskussionen, wenn man ins Detail geht. Steht das Netzwerk, die Identität, die Daten oder die Geräte im Vordergrund, oder geht es letztendlich um die Systeme?
In diesem Vortrag möchte ich unsere Erfahrungen mit Dir teilen, die wir bei der Implementierung von Zero Trust in der Deutschen Telekom gesammelt haben.

Zielpublikum: Architekt:innen, DevOps, technische Verantwortliche
Voraussetzungen: Basis-Verständnis von IT-Architektur
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Dieser Konferenzvortrag bietet einen Erfahrungsbericht zur Implementierung einer Zero-Trust-Sicherheitsarchitektur im organisatorischen Kontext. Die Teilnehmer erhalten Einblicke in die praktischen Aspekte, Herausforderungen und Vorteile der Übernahme von Zero-Trust-Prinzipien.
Die Sitzung beginnt mit einer Einführung in Zero Trust, wobei die Notwendigkeit eines Paradigmenwechsels in Sicherheitspraktiken betont wird. Der Redner teilt seine Erfahrungen aus der realen Welt und behandelt wichtige Komponenten wie Identität, Netzwerk, Clients, Daten und insbesondere Systeme. Es werden Herausforderungen während der Implementierung angesprochen, einschließlich organisatorischem Widerstand und Ressourcenzuweisung.
Die Teilnehmer gewinnen praktisches Wissen und handlungsorientierte Einblicke aus dieser aus erster Hand stammenden Implementierungserfahrung.
Während das Konzept für Zero Trust je nach Unternehmen stark variieren mag, bleiben doch stets dieselben Fragestellungen bestehen, denen wir begegnen müssen.

Waldemar Schäfer ist als Senior Enterprise Architect bei der Deutschen Telekom tätig und hat seinen aktuellen Schwerpunkt auf dem Thema "Security by Design". In den letzten 15 Jahren lag sein Fokus hauptsächlich auf der Entwicklung skalierbarer Frontend-Architekturen.

Waldemar Schäfer
Raum 13b
Waldemar Schäfer
Raum 13b

Vortrag Teilen

17:00 - 18:00
Do 1.4
Wie fit ist deine Architektur? Automatisierte Architekturtests & statische Codeanalyse mit ArchUnit
Wie fit ist deine Architektur? Automatisierte Architekturtests & statische Codeanalyse mit ArchUnit

Im Architektur-Entwurf treffen wir ständig Architekturentscheidungen, die im besten Fall explizit, dokumentiert und verstanden sind. Aber wie praktisch wäre es, wenn man kontinuierlich prüfen könnte, ob diese Richtlinien auch eingehalten werden? Hier helfen Architecture Fitness Functions. Wir zeigen, wie man mit ArchUnit solche Fitness Functions schreibt, die die Struktur unseres Codes überprüfen, und wie man diese in den Entwicklungsprozess integriert. Außerdem zeigen wir, wie man mit der API von ArchUnit statische Codeanalysen durchführt.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Basis-Kenntnisse Java
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Architekturentscheidungen zu treffen und zu dokumentieren, ist aufwändig und mühsam, mit der Folge, dass Entscheidungen oft nur implizit getroffen werden und dann in Vergessenheit geraten, geschweige denn im Lauf der ständigen Weiterentwicklung eingehalten werden.
Architecture Fitness Functions dienen dazu, Architekturentscheidungen im besten Fall automatisiert zu überprüfen. So bekommt das Entwicklungsteam jederzeit Feedback, ob die Architektur noch den festgelegten Regeln entspricht.
Manche Entscheidungen wie Namenskonventionen lassen sich schon lange über altbekannte Tools wie Checkstyle abtesten. Komplexere Entscheidungen aber lassen sich nicht immer einfach prüfen – oder sie erfordern ein komplexes Metamodell, das aufwändig zu erstellen und zu pflegen ist. Hier kommt ArchUnit ins Spiel.
In unserem Talk stellen wir anhand konkreter Fragestellungen vor, wie man mit ArchUnit automatisiert Architekturentscheidungen überprüft und in einen Standard-Testzyklus einbindet. Dazu bringt ArchUnit von Haus aus eine ganze Reihe von Standard-Hilfsmitteln mit. Besser noch: Eigene Architekturregeln lassen sich leicht in Form von Tests definieren und so im automatisierten Build überprüfen. Zugleich sind die Architekturregeln über die Tests dokumentiert.
Beispiele: Sind Abhängigkeiten zwischen Komponenten richtig definiert? Sind Strukturen innerhalb einer Komponente richtig modelliert, z.B. als Onion-Architektur?
Dieselbe API von ArchUnit kann man aber auch für statische Codeanalyse einsetzen, deren Output nicht in einem Test, sondern als Input in weitere Tools eingeht. Damit lassen sich einfach kleine Helferlein schreiben, um gezielt über statische Code-Analyse Handlungsbedarf identifizieren und analysieren zu können.
ArchUnit lässt sich demnach für kleine, mittlere und komplexe Fragestellungen einsetzen. Das skaliert gut und ermöglicht eine leichtgewichtige und automatisierte Absicherung von Architekturentscheidungen.
Wir zeigen zahlreiche Beispiele direkt im Code und geben damit einen ausführlichen Überblick über die Benutzung der ArchUnit-API.

Dr. Kristine Schaal ist als Software-Architektin seit fast 25 Jahren in der Software-Entwicklung tätig. In der Individualentwicklung arbeitet sie für Kunden verschiedener Branchen, überwiegend im Java-Umfeld.

Kristine Schaal
Raum 13b
Kristine Schaal
Raum 13b

Vortrag Teilen

Zurück