Bericht von der OOP 2026

Unter dem Motto »Embrace Change« fand die OOP 2026 vom 10. bis 13. Februar erstmals im MOC in München statt. Wir waren vor Ort und teilen unsere Eindrücke der besuchten Vorträge.

Nach 35 Jahren hat die OOP Konferenz [1] ihren angestammten Platz verlassen und ist in das MOC München umgezogen. Ein Wandel, der zum diesjährigen Motto »Embrace Change« passte, auch wenn die Konferenz auf uns in der neuen Umgebung etwas kleiner wirkte als in den Vorjahren. Trotz widriger Umstände – ein Streik legte am Mittwoch den Münchener ÖPNV weitgehend lahm – war die Anreise dank guter Parksituation am neuen Standort entspannt.

Inhaltlich war die diesjährige Ausgabe natürlich stark vom Thema Künstliche Intelligenz (KI) dominiert: Nahezu die Hälfte des Programms drehte sich direkt um AI, GenAI und Agentic Engineering. Aber auch die klassischen Themen wie Softwarearchitektur, Soziotechnische Systeme und 25 Jahre Agiles Manifest kamen nicht zu kurz – und waren an vielen Stellen von KI “durchzogen”.

Die Konferenz ist mit über 120 Fachvorträgen in thematische Tracks unterteilt, die das gesamte Spektrum der modernen Softwareentwicklung abdecken:

• Software Architecture – Building Software That Adapts: Strategien für flexible, zukunftsfähige Systemarchitekturen.
• Software Architecture – The Impact of Generative AI: Einfluss generativer KI auf Design-Paradigmen und Architekturprozesse.
• AI and the End of Business-as-Usual: Transformation von Geschäftsmodellen und Arbeitsprozessen durch KI.
• Product Ownership, User Experience & Requirement Engineering: Nutzerzentrierte Produktentwicklung und Anforderungsmanagement.
• Back to Basics of Design, Architecture, and Programming: Rückbesinnung auf fundamentale Prinzipien des Software-Handwerks.
• Domain-Driven Design (DDD): Beherrschung komplexer Fachdomänen durch kollaborative Modellierung.
• Platform Engineering: DevOps, thought further(?): Effizienzsteigerung durch interne Entwicklerplattformen und DevOps-Evolution.
• Legacy & Innovation: Modernisierung von Altsystemen bei gleichzeitiger Aufrechterhaltung der Innovationskraft.
• Testing & Quality: Qualitätssicherung, Test-Automatisierung und Validierung von KI-/Cloud-Systemen.
• Agility, Leadership & Social Integration: Führungskultur, psychologische Sicherheit und moderne Agilität.
• Emerging Changes: Externe Einflüsse wie Green IT, Nachhaltigkeitsgesetze und Regulatorik.

Die OOP2026 reflektiert „25 Jahre Agiles Manifest“ und hinterfragt, was nach der Agilität kommt. Die Eröffnungs-Keynote setzt sich kritisch mit der Vorherrschaft von US-Hyperscalern und politischen Einflüssen auf die IT-Infrastruktur auseinander und ist schon fast eine politische Ansage. Besonders hervorgehoben wird über alle Tracks der soziotechnische Ansatz – die Verbindung von Architektur, Teamkultur und Psychologie. Künstliche Intelligenz ist nicht mehr nur ein Trend-Thema, sondern zentraler Aspekt der OOP 2026. 

So nimmt das Thema KI/AI (inkl. GenAI und Agentic AI) etwa 30-40% des Gesamtprogramms ein. Es gibt einen dedizierten KI-Track („AI and the End of Business-as-Usual“), aber KI-Inhalte finden sich cross-funktional in fast allen anderen Tracks (z.B. KI in der Software-Architektur, KI-gestütztes Testing, Ethik der KI). Zentrale KI-Themen sind:

• Agentic Engineering: Der Übergang vom bloßen „Prompting“ zu autonomen KI-Agenten in der Entwicklung.
• GenAI-Ethik: Kritische Diskussion über die „ethische Nutzung“ und soziale Folgen (Vereinsamung in Teams durch KI-Automatisierung).
• KI-native Produktentwicklung: Wie Produkte von Grund auf neu gedacht werden müssen, wenn KI die Basis ist.
• EU AI Act: Regulatorische Anforderungen und deren Umsetzung in der Software-Architektur.

Keynote: Eine Unterschrift Trumps und US-Hyperscaler sind illegal

Sprecher: Max Schrems

Den Auftakt machte Max Schrems mit einer juristisch-technischen Realitätsprüfung, die es in sich hatte. Schrems, bekannt für seine erfolgreichen Klagen gegen Facebook, beleuchtete die massive Abhängigkeit europäischer Unternehmen von US-Cloud-Anbietern im Kontext der aktuellen geopolitischen Lage.

Sein Kernargument: Durch Gesetze wie FISA 702 sind US-Anbieter („Electronic Communication Service Provider“) verpflichtet, US-Behörden Zugriff auf Daten (“Foreign Intelligence Information«, also somit eigentlich alles) von Nicht-US-Bürgern zu gewähren – was im direkten Konflikt mit der DSGVO und der EU-Grundrechtecharta steht. Microsoft soll ihm zufolge im Schnitt die Daten von ca. 200.000 Accounts pro Halbjahr offenlegen. Da dies auch Firmenaccounts umfasst, sind so Millionen Anwender außerhalb der EU betroffen.

Und wie die gezeigte Seite aus Originalunterlagen der US-Regierung dazu eindrucksvoll (“Yahoo!, AOL, …”) dokumentiert, gilt dies auch schon seit mehr als 15 Jahren:

In gewissen Ländern wie bspw. Kuba und Nordkorea dürfen US-Tech-Dienste aufgrund entsprechender Vorgaben der US-Regierung derzeit schon nicht operieren. Außerdem werden Einzelpersonen regelmäßig durch die US-Regierung sanktioniert, siehe das Beispiel eines Richters des Internationalen Strafgerichtshofs, dessen sämtliche Konten bei US-Unternehmen wie Amazon, Airbnb oder PayPal von den Anbietern sofort geschlossen wurden [2]. Schrems stellte die berechtigte Frage, was nun mit Dänemark wegen Grönland passieren wird.

Er verdeutlichte darüber hinaus, dass eine einfache „Executive Order“ des US-Präsidenten ausreicht, um Datentransfers für illegal zu erklären, Sanktionen zu verhängen oder den USA weitergehenden Zugriff auf Daten von Nicht-US-Bürgern zu gewähren.

Hierbei lieferte er auch noch spannende Details zum Instrument “Executive Order”, welches sich wohl aufgrund der immer schwierigeren Gesetzgebungsverfahren mit dem Kongress schon seit Jahren zum Mittel der Wahl der US-Regierungen gemausert hat. Die Executive Order ist dabei kein Gesetz, sondern eine Dienstanweisung an Bundesbehörden. Sie kann bestehende Gesetze, die vom Kongress verabschiedet wurden, zwar nicht außer Kraft setzen oder umschreiben, durch geschickte Formulierung aber bspw. die Arbeit einer Behörde so einschränken, dass dies dem gleich kommt. Außerdem bestehen Möglichkeiten für den Präsidenten, die Inhalte von Executive Orders (und ähnlichen präsidialen Anweisungen) geheim zu halten. 

Besonders kritisch sah er die sogenannten „Supplementary Measures“ (wie Verschlüsselung) der Hyperscaler, die oft mehr Marketing als echter Schutz seien, solange der Anbieter selbst den Schlüssel hält oder durch US-Recht zur Herausgabe gezwungen werden kann. Mehr Details siehe bspw. auch hier [3]. 

Sein Fazit war ernüchternd, aber klar: Eine rechtlich saubere Trennung wäre zwar möglich, insofern die großen Player ihre europäischen Dependancen bspw. als reine Finanzbeteiligungen führen würden, was aber  bisher nicht konsequent umgesetzt wurde. Und da wir faktisch auch gar nicht wissen, welche Daten wirklich mitgelesen werden (Stichwort: geheime Executive Order), wäre es auch so oder so skeptisch zu bewerten. Für uns als Software Architekten bedeutet dies: Das Risiko ist real, „Compliance“ ist mehr als nur Papierkram und Digitale Souveränität wird und muss unseren Arbeitsalltag beherrschen.

Lean Compliance as Strategic Asset in Agile Organizations

Sprecher: Felix Rüssel, Erika Schüttfort

Passend zum Thema Regulierung zeigte dieser Vortrag einen pragmatischen Weg aus der „Death by Checklists“-Falle, die wir in Europa mit im Schnitt einer neuen Regulierung alle drei Stunden schon lange erreicht haben. Und sich durch immer neue Anforderungen (Lieferkettensorgfaltspflichtengesetz, Digital Operational Resilience Act, …) auch auf unsere Arbeit als Softwarearchitekten und Produktentwickler niederschlägt:

Die Referenten legten dar, dass viele Unternehmen Compliance fälschlicherweise als nachgelagerte Kontrollinstanz missverstehen. Stattdessen sei Compliance als integraler, wertschöpfender Baustein innerhalb des Wertstroms zu betrachten, dessen Fehlplanung oder Engpässe ein fundamentales Fluss-Problem („Flow“) darstellen.

Statt Compliance als nachgelagerten Bremsklotz zu behandeln, sollte sie als „Lean Compliance“ integraler Bestandteil des Entwicklungsprozesses sein (“Shift Left”). Das Ziel ist eine echte Zusammenarbeit zwischen „Makers“ (Entwicklern) und „Checkers“ (Compliance Officers), statt eines Gegeneinanders. 

Besonders interessant war der Ansatz der „Minimum Viable Compliance“ (MVC) – also Compliance iterativ und parallel zum Produkt zu entwickeln, statt am Ende vor einem Berg an Anforderungen zu stehen.

Die Redner adaptieren hierbei Kernprinzipien agiler Frameworks wie Scrum und Kanban für den Compliance-Sektor. Anstatt als isolierte Prüfinstanz zu agieren, integriert sich die Compliance-Funktion unmittelbar in cross-funktionale Produktteams, um regulatorische Anforderungen als kontinuierlichen Teil des Entwicklungsprozesses zu begreifen.

Gerade in Deutschland ist die Klage über eine vermeintliche Überregulierung allgegenwärtig. Die Referenten schlossen ihren Vortrag jedoch mit einem pointierten Gegenentwurf ab: Nicht die Menge der Regulierung sei das primäre Hindernis, sondern deren ineffiziente Einbindung in die Wertschöpfungskette:

»Organisationen scheitern selten an der Regulierung selbst, sondern daran, dass ihr Betriebsmodell diese nicht absorbieren kann.«

Strategien für die Analyse großer Softwaresysteme mit Sprachmodellen

Sprecher: Michael Stal (Principal Key Expert Engineer, Siemens AG)

Michael Stal, eine der zentralen Figuren der OOP-Konferenz (Conference Chair, regelmäßiger Sprecher, Autor zahlreicher Fachpublikationen sowie Chefredakteur JavaSPEKTRUM) gab einen tiefen Einblick in das Projekt „SARA“ (Siemens Architecture Review Agent), ein Versuch, die millionenschweren Codebasen des Siemens-Konzerns mittels LLMs zu analysieren. Plakatives Ziel ist dabei, z.B. dem Software-Korpus des ICE die Frage stellen zu können, warum eine spezielle Baureihe des ICE unter gewissen Umständen nicht bremst. Hierzu haben sie ein komplexes System aufgesetzt, welches sowohl moderne KI-Ansätze als auch klassische Code-Analyse-Tools verbindet.

Der Vortrag war dabei auch erfrischend ehrlich bezüglich der Grenzen aktueller KI-Modelle. Stal zeigte auf, dass LLMs zwar stark im Pattern-Matching sind, ihnen aber oft das Verständnis für den zeitlichen Verlauf (Code-Historie) und den Projektkontext fehlt. Um Halluzinationen und Kontext-Probleme in den Griff zu bekommen, setzten sie auf fortgeschrittene Prompting-Strategien wie „Chain of Thought“ und Multi-Agenten-Systeme, bei denen ein Agent Lösungen vorschlägt und ein anderer (Critique Agent) diese prüft – ein sogenannter Adversarial Approach.

Vom Engineering-Standpunkt betrachtet, hat uns das Vorhaben hier umgehauen, da wurde modernste Technologie intelligent verbaut, um die Komplexität, die vermutlich tausende Entwickler und Architekten über Jahrzehnte geschaffen haben, zukünftig noch beherrschbar zu halten. Unsere Erkenntnis hier war jedoch auf unsere Nachfrage auch wirtschaftlicher Natur: Mit initialen Entwicklungskosten von rund 1,5 Millionen Euro und hohen Betriebskosten für private Cloud-Instanzen und Betriebsaufwänden für die durchaus komplexe Infrastruktur ist der Return on Invest (ROI) solcher Eigenentwicklungen noch nicht abschließend geklärt. Es bleibt der Eindruck: Man hat es gebaut, weil man es sich als Konzern leisten kann, aber der breite Nutzen muss sich erst noch beweisen.

Wie die Natur Probleme löst – und was IT-Projekte daraus lernen können

Sprecherin: Anna Melbinger

Dr. Anna Melbinger ist promovierte Physikerin, die nach mehrjähriger internationaler Forschungstätigkeit im Bereich der theoretischen und biologischen Physik in die Beratung wechselte, wo sie aktuell Transformations- und IT-Strategieprojekte leitet.

Ihr Vortrag, der biologische Strategien auf IT-Herausforderungen übertrug, war für uns einer der Höhepunkte der diesjährigen Konferenz – auch wenn keine Keynote. Die Natur, Meisterin im Schaffen langlebiger, komplexer Systeme, liefert ihr zufolge „Vorlagen“ und Hilfestellungen für unsere alltäglichen IT-Probleme.

Dabei optimiert die Natur nicht auf Effizienz, sondern auf Robustheit – ein Prinzip, das wir in der Softwarearchitektur oft vernachlässigen, sind doch gerade aktuell wieder Produktivität und Effizienz präsenter denn je.

Spannend war der Vergleich mit Bakterien (Chemotaxis) und Motten (Infotaxis), die Ziele nicht auf direktem Weg, sondern durch „Run-and-Tumble“ oder das Sammeln von Informationen erreichen. Für uns bedeutet das: In unsicheren Projektumgebungen ist es oft besser, Entscheidungspunkte zu setzen und sich an der Entwicklung von Kennzahlen (bspw. einem Abwärtstrend bei den Bugs) statt stur Meilensteine abzuarbeiten und absoluten Kennzahlen hinterherzurennen.

Eine wichtige Erkenntnis: Evolution passiert am Engpass und dementsprechend ist auch eine Entlastung am Engpass blinder Optimierung überlegen. Die Rednerin brachte hier das Beispiel der Laktose-Toleranz, welche in nördlichen Ländern aufgrund des veränderten Nahrungsangebots zu einem Überlebensvorteil geführt hat.

Auch das Konzept, dass Innovation Vielfalt (wie bei T-Zellen) und nicht vorzeitige Fokussierung benötigt, ist ein starkes Plädoyer für diverse Teams und Lösungsansätze, offenes Brainstroming und Design-Thinking-Ansätze.

Die Evolution, ein fundamentaler Prozess in der Natur, bewältigt die Herausforderungen der Anpassung und Optimierung durch das gnadenlose Prinzip des „Survival of the fittest“, sprich das Aussterben der weniger geeigneten. Ein solches Vorgehen ist in IT-Projekten, wo Zeit, Ressourcen und der Erfolg des Projekts auf dem Spiel stehen, weder wünschenswert noch praktikabel. Die „natürliche Auslese“, bei der ungeeignete Elemente erst in der späten Phase oder nach dem Scheitern des Gesamtprojekts identifiziert werden, ist ein kostspieliges und riskantes Unterfangen.

Die zentrale Herausforderung in IT-Projekten lautet daher: Wie können wir dieses natürliche Prinzip umkehren? Wie können wir proaktiv und im Voraus erkennen, welche Teile unseres Projekts – seien es Code-Architekturen, Prozesse oder Anforderungen – nicht „fit“ (geeignet, nachhaltig, wartbar) sind, bevor sie Schaden anrichten oder das Projekt in eine Sackgasse führen?

Hierzu lieferte die Rednerin keinen Blueprint, unserer Erkenntnis nach bieten agile Prinzipien aber einen wesentlichen Lösungsansatz. Sie bieten Methoden und Rahmenwerke, um das Unsichtbare sichtbar zu machen. Eine Kultur der kontinuierlichen Inspektion und Adaption zwingt durch kurze Iterationen (Sprints in Scrum) oder den ständigen Fluss in Kanban das Team, regelmäßig innezuhalten (z.B. in Retrospektiven) und kritisch zu hinterfragen, was funktioniert und was nicht. Dies ist die künstliche, menschlich gesteuerte Alternative zur „natürlichen Auslese“: Wir erkennen die Mängel, bevor das „Aussterben“ (das Scheitern des Projekts) droht, und korrigieren den Kurs.

Keynote: State of Play: KI-unterstütztes Programmieren

Sprecherin: Birgitta Böckeler (Thoughtworks)

Birgitta Böckeler lieferte einen sehr fundierten Überblick über den aktuellen Stand von KI in der Softwareentwicklung. Wir bewegen uns ihr zufolge weg vom reinen „Autocomplete on Steroids“ hin zu „Agentic Engineering“ und komplexen Workflows.

Besonders wichtig erschien uns der Hinweis auf das „Context Engineering“: Der Erfolg von KI-Tools hängt entscheidend davon ab, wie effektiv der Kontext – also Regeln, benötigte Fähigkeiten und Schnittstellen – gemanagt und der KI bereitgestellt wird. Man könnte dies als eine Art „Prompt Engineering on steroids“ oder „RAG on steroids“ bezeichnen. Im Kern geht es dabei nach wie vor darum, ein großes „Standard“-Sprachmodell, das die wenigsten aus Kostengründen selbst trainieren können, mit den notwendigen Informationen zu versorgen – entweder direkt über den Prompt oder „intelligent“ aus angeschlossenen Drittsystemen. 

Wobei die auch hier von der Rednerin u.a. referenzierte Agents.md nicht das Allheilmittel ist, mit dem sie derzeit durch die entsprechenden Fachmedien geht. Eine aktuelle Studie [4] fand dazu heraus: 

»Across multiple coding agents and LLMs, we find that context files tend to reduce task success rates compared to providing no repository context, while also increasing inference cost by over 20%.«

Die Rednerin war ebenso wie wir davon überzeugt, dass lokal betriebene, kleine Modelle mittelfristig aus Komplexitäts- und Performancegründen aussterben werden. So sind ihrer Einschätzung nach selbst die guten kleinen Modelle 8-12 mal langsamer als die großen:

Gleichzeitig warnte sie vor den Kosten („The Honeymoon is over“) und Sicherheitsrisiken wie Prompt Injection. Ihr Rat: Kenne dein Werkzeug und nutze es, auch wenn du skeptisch bist – denn KI wird die Art, wie wir Software bauen, fundamental verändern, auch wenn Halluzinationen ein “Feature” und kein Bug bleiben.

Im Vortrag wurden auch einige aufschlussreiche Zahlen zu den Kosten von KI in der Entwicklung präsentiert, die in all dem Marketing-Hype (“Wir brauchen dank KI keine Entwickler mehr”) gerade untergehen. Während die KI-Generierung von 100 Zeilen Code Anfang 2024 lediglich 12 Cents kostete, stiegen diese Kosten bis zum Sommer 2025 auf 2,5 $ – in anderthalb Jahren also um den Faktor 21! Bei intensiver Nutzung in der Entwicklung – man darf nicht außer acht lassen, dass all die Agenten, die da gerade am Werk sind, extrem Token-hungrig sind, können die KI-Kosten schnell auf jährlich rund 90.000 $ steigen. Ein Betrag, für den man wiederum auch einen Entwickler einstellen könnte…

Und obwohl KI die Code-Erstellung beschleunigen mag, bleiben die Ergebnisse noch aus. So kommt ein Working Paper der Harvard University vom 7. Januar 2026 [5] bspw. zu folgender Erkenntnis:

»Generative AI tools like Copilot and Cursor lead to moderate [~8 %], but not transformational, improvements in engineers’ productivity […and] does not translate to effects on downstream outcomes.«

Ein kritischer Punkt ist und bleibt der Mensch als limitierender Faktor bei der Verwaltung der Vielzahl von KI-Agenten. Die wesentlichen Schritte der Softwareentwicklung bleiben der Rednerin zufolge weiterhin in menschlicher Hand, nämlich die Spezifikation (Klärung der Anforderungen: „Was will ich?“) und die Verifizierung (Überprüfung des Ergebnisses: „Ist es das, was ich will?“).

Missverständnisse zu Softwarearchitektur

Sprecherin: Carola Lilienthal

Carola Lilienthal räumte gewohnt souverän mit gängigen Mythen der Softwarearchitektur auf. Basierend auf ihrer Analyse hunderter Softwaresysteme zeigte sie, warum Sätze wie „Wir machen Microservices, also brauchen wir keine Architektur mehr“ oder „Neubau ist besser als Refactoring“ gefährliche Trugschlüsse sind.

Ein Dauerbrenner für die Praxis der Softwareentwicklung und der Rednerin (und unserer Einschätzung) zufolge das Fundament modularer und wartbarer Architekturen: Die klare Unterscheidung und konsequente Anwendung hoher Kohäsion (engl. High Cohesion) innerhalb von Modulen und von loser Kopplung (engl. Loose Coupling) zwischen Modulen.

Hohe Kohäsion bedeutet, dass die Elemente innerhalb eines Moduls (z.B. Klassen, Methoden oder Funktionen) eine starke thematische und funktionale Zusammengehörigkeit aufweisen. Sie arbeiten eng zusammen, um eine einzige, klar definierte Verantwortung zu erfüllen (dem Single Responsibility Principle folgend). Module mit hoher Kohäsion sind leichter zu verstehen, zu testen und zu warten, da Änderungen an einer Verantwortung meist nur dieses eine Modul betreffen.

Lose Kopplung hingegen beschreibt das Ideal minimaler, wohl-definierter Abhängigkeiten zwischen verschiedenen Modulen. Module sollten so wenig wie möglich über die internen Details anderer Module wissen. Änderungen im Inneren eines Moduls sollen idealerweise keine oder nur minimale Auswirkungen auf andere, davon abhängige Module haben (lose Kopplung). Dies wird oft durch die Verwendung von klaren Schnittstellen (Interfaces), Abstraktionen und Dependency Injection erreicht.

Eine zentrale Gefahr und eine ständige Herausforderung in der Architektur ist die Entstehung zyklischer Abhängigkeiten (engl. Circular Dependencies). Hierbei hängt Modul A von Modul B ab, und Modul B hängt gleichzeitig von Modul A ab. Solche Zyklen bilden „Super-Module“ oder große, unflexible Abhängigkeitsringe, die die Vorteile von Modularität vollständig untergraben.

Die Warnung der Rednerin vor zyklischen Abhängigkeiten ist dabei besonders vehement, da sie auch durch Interfaces nicht verschwinden. Ein Interface kann zwar die Art der Abhängigkeit auf eine Abstraktionsebene heben und die Kopplung lockern, aber es löst den zyklischen Verweis selbst nicht auf. Wenn Modul A eine Schnittstelle I definiert, die Modul B implementiert, und Modul B dann wiederum direkt oder indirekt Modul A importiert, besteht der Zyklus weiterhin, was die Testbarkeit, die Wiederverwendbarkeit und die Deployment-Flexibilität massiv einschränkt. Die saubere Auflösung solcher Zyklen erfordert oft eine Umstrukturierung der Module oder die Einführung einer weiteren Abstraktionsebene (z.B. ein drittes Modul, das die Abhängigkeiten orchestriert).

Obwohl der Quellcode die „Wahrheit“ darstellt und KI uns immer besser beim Verständnis desselben unterstützt, bleibt eine grundlegende Dokumentation von Softwaresystemen unverzichtbar. Denn die Beweggründe für bestimmte architektonische Entscheidungen kann selbst eine KI nicht einfach aus dem Code ableiten, wie auch Michael Stal in seinem Vortrag eindrucksvoll verdeutlichte.

Sehr gut hat uns die kompakte Zusammenfassung des arc42-Ansatzes zur Architekturdokumentation [6] der Rednerin gefallen. Es gelang ihr, die zentralen Konzepte und die Struktur, die dieses Open-Source-Framework für eine effektive und verständliche Dokumentation von Software-Architekturen bietet, auf den Punkt zu bringen, ohne dabei wesentliche Details zu übergehen. 

Ein solider, fast zeitloser Vortrag, der daran erinnerte, dass die handwerklichen Grundlagen auch im KI-Zeitalter unverzichtbar bleiben.

Was Craftsmanship ausmacht

Sprecher: Marco Achtziger

Ergänzend wurden in diesem Vortrag Einblicke in die Implementierung von „Craftsmanship“-Programmen, konkret im Testumfeld von Siemens, gewährt. Die zentrale Erkenntnis war, dass exzellentes Handwerk nicht hierarchisch verordnet werden kann. Stattdessen erfordert es einen kulturellen Wandel, der sich an Daniel Pinks Werk Drive [7] orientiert. Dieser Wandel basiert auf den drei Säulen intrinsischer Motivation – Autonomie (Autonomy), Beherrschung des Fachgebiets (Mastery) und Sinnhaftigkeit (Purpose) –, die essenziell sind, um Leistung und Zufriedenheit in der modernen Wissensarbeit zu steigern.

Der Redner gab dabei auch einen interessanten Einblick in die Software Craftsmanship Bewegung, beginnend in den 1990ern mit Extreme Programming, über Robert Martins  Clean Code(r) und das “Manifesto for Software Craftsmanship“ im Jahr 2009 [8]:

Eines von Steven Jobs berühmten Zitaten bildete einen guten Abschluss zu dem Vortrag:

»When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.«

Unsere Einschätzung

Die OOP 2026 hat gezeigt, dass die Branche in Bewegung ist. Der Umzug in das MOC hat der Veranstaltung durch die bessere Verkehrsanbindung und die weiterläufigeren Räumlichkeiten gut getan, auch wenn sie etwas kompakter wirkte. Inhaltlich war die Dominanz von KI allgegenwärtig – nicht mehr als Hype, sondern in der Phase der konkreten, teils ernüchternden, teils hoffnungsvollen Anwendung (Agentic AI, RAG) – wo man das Thema in Gartners Hype-Cycle [9] aktuell verortet, mag dabei jeder für sich entscheiden:

Gleichzeitig war spürbar, dass die klassischen Tugenden – saubere Architektur, soziotechnische Gestaltung und solides Handwerk – nicht an Bedeutung verlieren, sondern gerade durch die KI-Unterstützung noch wichtiger werden, um die entstehende Komplexität beherrschbar zu halten.

Quellenangaben

Die Informationen basieren auf dem Besuch der OOP 2026 sowie den bereitgestellten Unterlagen und Vortragsbeschreibungen der Konferenz.

[1]: https://www.oop-konferenz.de/de
[2]: https://www.heise.de/news/Wie-ein-franzoesischer-Richter-von-den-USA-digital-abgeklemmt-wurde-11087453.html 
[3]: https://www.heise.de/news/Nicht-souveraen-Microsoft-kann-Sicherheit-von-EU-Daten-nicht-garantieren-10494684.html 
[4]: https://arxiv.org/abs/2602.11988
[5]: https://fion.ac/jellyfish.pdf
[6]: https://arc42.de/
[7]: https://en.wikipedia.org/wiki/Drive:_The_Surprising_Truth_About_What_Motivates_Us
[8]: https://manifesto.softwarecraftsmanship.org/
[9]: https://de.wikipedia.org/wiki/Hype-Zyklus 

Michael Schwarze

Geschäftsführer

Michael ist ein erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung in der Technologiebranche. Er hat sowohl in Startups als auch Konzernen auf Anwender- als auch Entwicklungs- und Beratungsseite gearbeitet.  Coden ist für ihn nicht nur Beruf, sondern Leidenschaft, am liebsten mit dynamisch-typisierten Sprachen wie Ruby. Neben der Entwicklung langlebiger Softwaresysteme liegt ihm auch die Verbesserung des Managements in der Softwareentwicklung am Herzen. Wenn er nicht gerade mit seiner Familie und seinen zwei Kindern beschäftigt ist, findet man ihn in den Bergen, beim Joggen oder anderen sportlichen Aktivitäten.

m.schwarze@atra.consulting    

• LinkedIn