On this page you will only see the English-language presentations of the conference. You can find all conference sessions, including the German speaking ones, here.
The times given in the conference program of OOP 2024 correspond to Central European Time (CET).
By clicking on "VORTRAG MERKEN" within the lecture descriptions you can arrange your own schedule. You can view your schedule at any time using the icon in the upper right corner.
Track: Architecture – for Humans?
- Architecture – for Humans?
- C++ and possible Alternatives
- Domain-Driven Design expands our horizons
- Embedding AI into your Products: Practical Applications of Foundation Models
- Full Day Tutorial
- Half Day Tutorial
- Shaping the future: Overcoming Boundaries with New Ideas in Product Ownership, UX & Requirement Engineering
- Social Integration
- Software Architecture – Systematically Handling Quality Attributes
- Special Event
- Testing & Quality
- Thinking DevOps further
- Trends & Techniques
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
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".
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.
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.
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.
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
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.
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
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 angjä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.
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
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.