On this site, there is only displayed the English speaking sessions of the OOP 2022 Digital. You can find all conference sessions, including the German speaking ones, here.
The times given in the conference program of OOP 2022 Digital correspond to Central European Time (CET).
By clicking on "EVENT 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.
There are several architecture models with prescribed views and notations. The Keep It Short & Simple architecture model is different. We create pieces of documentation iff they benefit stakeholders. We do so using drawing tools, not modeling tools. We say no to BDUF and yes to Important Design Up Front. We follow 7 tips for creating diagrams that are expressive, not ambiguous, and help you to successfully understand and evolve them, and build a system from them. We complement the design diagrams that describe structure and behavior with ADRs.
Target Audience: Developers and anyone else who plays the role of architect.
Prerequisites: If you've ever developed software, you're ready.
Do you create or use architecture documentation? Have you ever been confused and wondered about the meaning of a box or arrow in a design diagram? Do you think architecture documentation is costly or time consuming? If your answer is yes to any of these questions, this tutorial has practical and valuable information for you. There are several proposed architecture models with prescribed views and notations. The Keep It Short and Simple architecture model is different. We create pieces of documentation if they benefit stakeholders. We do so primarily use drawing tools, not modelling tools. We say no to Big Design Up Front (BDUF) but say yes to Important Design Up Front (IDUF). We follow 7 guidelines for creating informal design diagrams that are expressive, not ambiguous, and effectively help you and others to successfully understand them, evolve them, and build a system from them. Finally, we complement the essential design diagrams that describe structure and behaviour with architecture decision records (ADRs) for the important design decisions.
In the tutorial we look at several example architectures from real world systems. Most are good examples, but we also turn a critical eye on known products' architecture diagrams with several opportunities for improvement. Participants can also share their experience throughout. The tutorial also includes a fun online game and a hands-on exercise.
Tutorial minutiae include: what is the minimum architecture documentation expected, what design decisions are important enough to deserve an ADR, examples of drawing tools, who should be responsible for architecture documentation, how to complement structural diagrams with behavior diagrams.
Micro-Frontends eigenen sich nicht in allen Szenarien! Diese Session stellt einen alternativen Ansatz vor: Frontend-Modulithen. Wir besprechen das Abbilden fachlicher Domänen, die Kategorisierung von Bibliotheken sowie Zugriffseinschränkungen zum Erzwingen entkoppelter Teilsysteme. Außerdem nutzen wir inkrementelle Builds und einen Build Cache zur drastischen Beschleunigung des CI-Prozesses. Am Ende wissen Sie, ob Frontend-Modulithen für Sie der richtige Ansatz sind und wie Sie Ihre Anwendungen damit aufbauen.
Zielpublikum: Architekt:innen, Entwickler:innen
Manfred Steyer ist Trainer, Berater und programmierender Architekt mit Fokus auf Angular, Google Developer Expert (GDE) für Angular und Trusted Collaborator im Angular-Team. Er unterstützt Firmen im gesamten deutschen Sprachraum, schreibt für O'Reilly, Heise und das Java-Magazin, spricht regelmäßig auf Konferenzen.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/manfred.steyer
Imagine you have an enterprise frontend monolith. Due to explosive growth, around 30 teams work on it, with about 100 different use cases. How do you keep this system scalable and consistent?
That's the question we faced inside Partner Home at Wayfair. I'm going to share our experience implementing a micro frontend architecture based on React to distribute shared concerns as long-lived applications. We used module federation, a new feature in Webpack 5.
I'll talk about the general architecture, plus an overview of our technical solution.
Target Audience: Architects, Developers
Prerequisites: English, Frontend Architecture, React
How will organizations keep agility alive after their initial agile transformation? The question of what happens if agile becomes daily business is even more intriguing in this post-pandemic COVID era. Will AGILE survive these unparalleled insecure times? Participants in this workshop will explore what is needed to sustainably ‘safeguard’ an enterprise agile delivery culture after the initial ‘agile transformation’. The workshop hosts will share their observations of working in a big financial organization and will invite participants to share theirs so that collectively, we can gain insight and define potential countermeasures.
Target Audience: Anyone interested in transformational agility challenges, e.g. Change Lead, Coach, BusArchitect
Participants in this workshop will explore what is needed to move forward after the initial ‘agile transformation’, to sustainably ‘safeguard’ an enterprise agile delivery culture. The question of what happens if agile becomes daily business is even more intriguing in this post-pandemic COVID era. How will organizations keep agility alive after their initial agile transformation? When organizational systems come under too much pressure; how ‘VUCA’* resistant are our agile enterprise cultures?
Lieke Jansen and Eric Abelen are senior Agile Enterprise Coaches at ING in the Netherlands. They both contributed to ING's Spotify inspired, big-scale transformation towards an agile way of working, some seven years ago. As of then, they have successfully coached a wide variety of departments and organizations within ING to adopt and sustain an effective healthy agile delivery culture. Being key players of a massive enterprise agile transformation, they also observe some challenges related to upkeep of the resulting way of working. Because people come and go, and in our VUCA world business and process change is frequent. What options do we have in this reality of ongoing change to keep the ‘agile enterprise culture’ strong and resilient?
Also, in the Covid pandemic we learned that people and organizations can respond to change quickly, especially those organizations that adopted a culture of agility. But after a period of unparalleled social restrictions, how does this affect our agile corporate cultures? Has the trauma of the pandemic infected us with a renewed urge to feel ‘in control’ of the future and has this irrevocably injured our appetite for organic growth and agility?
In this workshop we will explore this interesting and urgent question together with you. We will share key observations from experience working with a wide variety of delivery and leadership teams and their related organizational structures. We hope that workshop participants are willing to add their observations and experiences to ours. In interactive dialogue sessions we hope to collectively engage in sense-making and to define basic anti-patterns and growth-paths.
( * VUCA = Volatility, Uncertainty, Complexity, Ambiguity)
While Rust is typically pitched as systems programming language, it is equally adept at application development thanks to its high level features and great tooling. In addition to increased performance, native code has the advantage that it can easily be reused across different system components, an advantage even more pronounced in polyglot environments. In this talk, we would like to present our experience of using Rust to write core components in such a polyglot system.
Target Audience: Architects, Developers
Prerequisites: Basic knowledge of Python, Java
While Rust is typically pitched as systems programming language, it is equally adept at application development thanks to its high level features and great tooling. In addition to increased performance, native code has the advantage that it can easily be reused across different system components, an advantage even more pronounced in polyglot environments.
In this talk, we would like to present our experience of using Rust to write core components in such a polyglot system. The systems spans different contexts, from client to cloud, and different programming languages, from Python to Java, respectively. We will showcase how the Rust language itself and its tooling simplified this task and discuss different integration patterns.
Software is often resistant to modernization efforts, no matter if it's about phasing out obsolete technologies, migration to the cloud, or establishing modern architecture. The culprit is usually a dependency or obsolete assumption that's too closely coupled to the codebase. But what's the underlying root cause of all that coupling? Often, it's shared, mutable, synchronous state. We will look at a real-world project, and we'll dig ourselves out of the hole it's dug itself into using refactoring, event sourcing, and functional programming.
Target Audience: Architects, Developers
Prerequisites: Some programming
As shared mutable state is the core paradigm of object-oriented programming, it tends to be ubiquitous in OO projects. How to avoid it then? The example has followed a familiar path: Convenient tooling allowed the project to get off the ground fast, but tied it to its underlying technologies. By the time support for those technologies has expired, coupling has gotten so strong that huge resources are expended on keeping things going "just one more day". If you've seen projects like this hit a wall, this talk is for you.
Michael Sperber is CEO of Active Group in Tübingen, Germany. Mike specializes in functional programming and has been an internationally recognized expert in the field: He has spoken at the top conferences in programming languages, authored many papers on the subject as well as several books. Moreover, he is an expert on teaching programming.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/michael.sperber
The purpose of Serverless is to focus on writing the code that delivers business value and offload undifferentiated heavy lifting to the Cloud providers or SaaS vendors. Today’s code quickly becomes tomorrow’s technical debt. The less you own, the better it is from the maintainability point of view. In this talk I will go through examples of the various Serverless architectures on AWS where you glue together different Serverless managed services, significantly reducing the amount of the code written to perform the task. Own less, build more!
Target Audience: Developers, Architects, Decision Makers
Prerequisites: Basic understanding of AWS Serverless Services
In a world of rapid changes and increasing uncertainties, organizations have to continuously adapt and evolve to remain competitive and excel in the market. In such a dynamic business landscape organizations need to design for adaptability. Designing for adaptability requires understanding the landscape organizations are operating in, identifying patterns of change, applying principles for organizational fitness, and making mindful strategic decisions to adapt change.
Target Audience: Software Architects, Tech Leads, Engineering Manager, VP of Engineering
Organizations need to aim for building systems and team organizations aligned to the business needs and business strategy and evolving them for adaptability to new changes and unknown environments.
This talk brings different perspectives and techniques together from business strategy (Wardley Mapping), software architecture (Domain-Driven Design), and team organization (Team Topologies) as a powerful toolset to design, build and evolve adaptive systems and team structures for a fast flow of change.
On-Call is an increasing reality for developers, especially when a site has strict uptime requirements. And sadly, the experience often sucks. It's easy to mandate 24x7 support, it's much harder to set it up in a way that doesn't make the life of the people in the rotation miserable.
I want to talk about improving alerting. I'm focusing on creating high-quality alerts that trigger when they should and don't trigger when nothing is happening. Continuous tuning, automation, and using the right metrics are core parts of this process.
Target Audience: Developers, Architects, DevOps, Operators
Prerequisites: Monitoring, operating production software
Do you believe in “you build it, you run it”? What if you have on-call rotations, where you are responsible 24x7 for the health of a system? Nothing is quite so infuriating as a collection of poorly structured alerts that trigger randomly.
So, let’s do better! I want to talk about how to improve your monitoring capabilities. There are a few topics I want to touch:
After this talk, you’ll have concrete actions to make your engineers’ life easier when on-call.
krankheitsbedingt ein kurzfristiger Wechsel
Content Management Systeme, Web-Browser oder Betriebssystem: Viele der Produkte und Services die wir täglich nutzen werden mittlerweile als Open Source Projekte realisiert. Durch den hohen Einfluss, den die Open Source Entwicklung mittlerweile auf die digitale Welt hat, findet man allerdings auch viele unterschiedliche Aussagen über dieGefahren und Vorteile von Open Source Produkten. Vor allem wenn man sich selber noch nicht intensiv mit der Thematik auseinander setzen konnte ist es hierdurch schwer, fachlich korrekte Bewertungen zu Open Source Produkten treffen zu können.
Basierend auf der Mitarbeit an verschiedenen großen Projekten in der Eclipse Foundation und des Java Ökosystems werde ich in diesem Vortrag nicht nur die theoretische Definition von Open Source vorstellen, sondern auch zeigen, wie Open Source Projekte in der Praxis entstehen und weiterentwickelt werden. Wir werden uns auch anschauen, warumOrganisationen Software als Open Source veröffentlichen und welche neuen und interessanten Geschäftsmodelle sich hierbei ergeben. Hierbei werden auch die Themen wie Lizenzen, Security und Support von Open Source Produkten angesprochen, welche durch Beispiele wie OpenSSL und den 2014 veröffentlichten Heartbleed-Bug konkretisiert werden.
Das im Vortrag vermittelte Wissen soll helfen, Open Source Software besser verstehen und einschätzen zu können. Mit diesem Fachwissen können die verschiedenen Gefahren und Vorteile, die durch die Nutzung von Open Source Komponenten entstehen, in Zukunft besser beurteilt werden.
Hendrik Ebbers ist Co-Founder der Karakun AG und leitet das Office der Karakun GmbH in Dortmund. Hendrik ist Java Champion, JavaOne Rockstar und Mitglied im Technical Steering Committee bei Eclipse Adoptium. Hendrik Ebbers hat die Java User Group Dortmund gegründet und konnte hierdurch kostenlose Fachvorträge mit verschiedenen internationalen Experten in Dortmund anbieten. Hendrik Ebbers hält regelmässig Vorträge über aktuelle Themen zu Java, OpenSource und Softwareentwicklung auf internationalen Meetups und Konferenzen. Sein Buch „Mastering JavaFX 8 Controls“ wurde von Oracle Press 2014 veröffentlicht.
The idea of looking at your organization as a single coherent system is tempting, but is it realistic? If it isn't, what does that mean for software developers, and how can we make discoverable what we are developing? This talk looks at organizations as ecosystems rather than as systems, and asks what that difference means for software development. It all boils down to focusing on software as components implementing business capabilities, and how to best capture these capabilities and make them findable and useful as reusable components.
Target Audience: Developers, Architects, Project Leaders, API Strategists
Prerequisites: API Basics, Large-scale information systems
Erik Wilde works in the Catalyst team at Axway. The team's mission is to help customers do the right things in the API and digital transformation space. Erik has been working in a variety of software companies, always focusing on questions of architecture and strategy. Erik's background is in computer science and he holds a Ph.D. from ETH Zurich, but over the course of his career it has become increasingly clear to him that technology rarely is the factor holding back organizations. So now he is helping organizations with their strategy to make sure that they are successful on their journeys.
Some codebases are nicer to work with than others. This is true for applications, services, libraries, frameworks, even programming languages themselves. Is this a purely personal choice or are there universal characteristics of software that can make code a joy to work with? Daniel has been thinking about this for a long time, especially since he poked a stick at the SOLID principles for fun a few years ago and people came after him with pitchforks.
His recent post about why he feels SOLID is outdated ended up on the front page of Hacker News! Now he has codified his thoughts into his own pithy five-letter acronym, CUPID: Composable, Unix philosophy, Predictable, Idiomatic, Domain-based. Why these characteristics, what do they mean, and why should you care? Can they improve your coding experience or is this just more programmer navel-gazing?
In this talk, we will give an overview about all the different aspects that affect climate change from the software engineering perspective and discuss a number of concrete actions that every software engineer can take (and should keep in mind day-in day-out) to help fight climate change. During the talk, we will not only provide an overview of the landscape, but also cover topics in more depth and discuss the challenges that come with them.
Target Audience: Architects, Developers, Project Leads
In this talk, we will give an overview about all the different aspects that affect climate change from the software engineering perspective and discuss a number of concrete actions that every software engineer can take (and should keep in mind day-in day-out) to help fight climate change, including:
In 2020, the three big cloud providers signed us all up for a revolution in the way we write and operate software. The deadline is 2030. Are you ready?
Target Audience: General techie. This works for all
In 2020, Google Cloud, AWS, and Azure all committed to be carbon zero by 2030. It's the incredibly tough goal of zero emitted carbon as a result for operating our applications and services. They can't do it alone. AWS says "we optimize for sustainability of the cloud, while customers are responsible for sustainability in the cloud, meaning they must optimize their workloads and resource utilization." I don't think this is a request. They've signed up to be carbon zero by 2030. That means we have too. The clock is ticking.
Big Bang rebuilds of systems are so 20th century. With our users expecting new functionality to be shipped more frequently than ever before, we no longer have the luxury of a complete system rebuild. In fact, a big bang migration of a monolithic architecture into a microservice architecture can be especially problematic, as we’ll explore in this talk.
We want to ship features, but we also want to improve our architecture, and for many of us this means breaking down existing systems into microservices. But how do you do this while still regularly releasing new features?
In this talk, I’ll share with you some key principles and a number of patterns which you can use to incrementally decompose an existing system into microservices. I’ll also cover off patterns that can work to migrate functionality out of systems you can’t change, which are useful when working with very old systems or vendor products. We'll look at the use of strangler patterns, change data capture, database decomposition and more.
Coming out of this talk you’ll have a better understanding of the importance of evolving an architecture, along with some concrete patterns to help you do that on your own projects.
Target Audience: Developers, architects, operations, testers and anyone actively involved in software delivery
Prerequisites: Basic knowledge about microservices and software delivery
This talk describes how to build and run a successful product development organization that delivers business value, not just features. I will cover what makes effective product development teams, how to structure, loosely couple, align and choreograph them, especially in larger organisations with up to 100 teams. Methods I will talk about include OKRs and Kanban Flight Levels. In this context I will also show when and how decentralised product teams can benefit from centralised platforms.
Target Audience: CTO, Manager, Decision Makers
Prerequisites: Experience with software development at scale
Matthias Patzak is a Principal Advisor at Amazon Web Services. Before joining Amazon Web Services, Matthias was Vice President IT at AutoScout24 and Chief Digital Officer at Home Shopping Europe. In both companies he introduced lean-agile operational models at scale and lead successful cloud transformations resulting in shorter delivery times and increased business value.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Matthias.Patzak
The primary cause of technical debt in your organization is very likely your project managers – not your programmers nor your architects. In this keynote Scott Ambler explores the root causes of technical debt within organizations, many of which trace back to the project management (PM) mindset and the strategies that result from it. Scott works through how to make leadership aware of technical debt and its implications, how to evolve your management practices, and strategies to embed technical debt thinking and behaviors into your culture.
Target Audience: Developers, Architects, Leaders, Managers
The primary cause of technical debt in your organization is very likely your project managers – not your programmers nor your architects. The management desire to be “on time and on budget” often motivates deployment of poor-quality assets and rarely leaves room for investment in long-term quality. Although technical professionals may readily realize this problem managers often do not, or if they do they don’t view technical debt as a priority. It is time for a change.
In this keynote Scott Ambler explores the root causes of technical debt within organizations, many of which trace back to the project management (PM) mindset and the strategies that result from it. Just like the technical challenges of addressing technical debt must be addressed by technical solutions, the management challenges of technical debt must be addressed by management solutions. Scott works through how to make leadership aware of technical debt and its implications, how to evolve your management practices to avoid and address technical debt, and enterprise-level strategies to embed technical debt thinking and behaviors into your culture. Results from industry research will be shared throughout.
• Connect project management practices to their impact on technical debt
• Learn how to describe technical debt, its impact, and solutions to leadership
• Discover how to embed technical debt thinking and practices throughout your way of working (WoW)
Scott Ambler is the Chief Methodologist of Ambysoft Inc. He is the creator of the Agile Modeling and Agile Data methods, as well as co-creator of PMI's Disciplined Agile tool kit. He has worked with organizations around the world to improve their software development ways of working (WoW). Scott is an award-winning author of 20+ books and an international keynote speaker.