Michael Plöd
INNOQ - Fellow
Nürnberg, Germany
Michael works as a Fellow for INNOQ in Germany. He has over 15 years of practical consulting experience in software development and architecture. His main areas of interest are currently Domain-driven Design, Microservices and in general Software Architectures. Michael is a regular speaker at national and international conferences.
Area of Expertise
Topics
Failures and learnings during the adoption of DDD: examples from the real world
Domain-Driven Design is no silver bullet and does not solve any problem in magical ways. The challenges and complexity that we try to tackle with DDD are hard and there is no easy way out. Nevertheless there is a growing popularity and appreciation for the topic in the market which may lead to overly ambitious expectations and eventually to disgruntled expectations.
The speaker of this talk has been working with Domain-Driven Design for the last 17 years on many software systems and this talk is about my experiences with failure. Believe me: I have failed a lot but there is always a chance to learn. The talk aims at giving you a chance to learn from the mistakes of me as an consultant and of the teams / organizations I have been working with.
The talk will address topics like:
- Domain-Driven Design in the waterfall
- Ignorance for code (aka only focus on strategic design)
- Overusage of patterns for their own sake
- Cultural implications
- Cargo Culting
- Developer Experience
- Rare availability of domain experts
- Dealing with established modeling techniques / methods
- Ignorance for the definitions / meaning of heuristics and patterns
This talk aims at providing you with a sensibility for potential hazards when you try to adopt DDD for your team and your organization and will contain only real-worlds scenarios that have actually happened. Each described failure will also come with a learning on what to do better.
This will be an interacive talk during which you, the audience will be asked questions and polls (through an online tool). You will be able to participate.
QualityStorming: Collaborative Modelling for Quality Requirements
In various communities, several methods for the collaborative modeling of business requirements have been established in recent years. Well-known examples are EventStorming or Domain Storytelling. These approaches are based on achieving a better shared understanding of the business requirements in an interdisciplinary way. But what about the requirements for the quality of the software being developed?
This is where Quality Storming comes in, trying to bring together a heterogeneous set of stakeholders of a product or project to collect quality requirements. The goal is to gain a shared understanding of the real needs for the quality characteristics of a product. To achieve this goal, Quality Storming uses some techniques from various already existing collaborative modelling approaches.
It is not the claim to produce perfectly formulated quality scenarios with the help of Quality Storming. Instead, the method aims to create a well-founded, prioritized basis for later formalization, which is understood across different stakeholder groups. The more often teams work with the technique, the better the quality of this basis becomes over time. Advanced teams are quite capable of creating very well-formulated scenarios within the framework of such a workshop.
In this talks I will introduce the workshop and the ideas behind it. You will also learn many hints for facilitating such workshops and how to proceed with the learnings generated in Quality Storming workshops.
Pitching DDD to the C-Level Management
Over the last couple of months and years I have always been confronted with the question „how to I sell or pitch the ideas behind Domain-driven Design to our management“?
This session aims to give you some advices how to address this challenge. Many of these advices are practically tested in various presentations and pitches to various senior and C-Level managers. Some of those were successful, others not so much and I will share some stories from the trenches of both outcomes.
I‘ll give you hints how to structure an argument for DDD, which parts of our beloved practice are of interest for those stakeholders and why you should also look beyond the IT-management for your pitch.
This talks is all about riding to the penthouse of Gregor Hohpe's elevator with DDD in your backpack.
Introduction to Context Mapping
Context Maps, are a part of strategic Domain-driven Design whichs aims at delivering a holistic overview over the interactions between bounded contexts and teams. They make the implicitly hidden organizational dynamics explicitly visible.
This talk introduces you to the motivation and the benefit for Context Maps. You will also learn about the three team dependencies and nine patterns which make up a Context Map. The talk also aims at delivering a consistent visual presentation for context maps and will give you an overview of tools and free resources which are available.
This talks is explicitly aimed at newbies to the topic and is no deep dive for seasoned experts.
Riding the elevator: DDD in the penthouse
In his book "The Software Architect Elevator" Gregor Hohpe uses the analogy of an elevator in a high building for the daily work which software architects should be doing: They are supposed to talk to folks who build and maintain stuff in the engine room but also make sure that the managment which is residing on the penthouse floors understand and gain interest in what is happening in the engine room.
In my talk I will build upon Gregors ideas and show you how you can leverage ideas from Domain Driven Design in this daunting communication tasks. But rest assured: I will not only present the obvious strategic Domain Drivend Design elements like core / supporting / generic subdomains here. We will go deeper and explore links to other initiatives in an org like DevOps, Agile and / org Design Thinking as well which are of interest for the leadership of an organization.
We as a community should get better at this topic because Domain Driven Design needs a healthy, blame free and safe environment in order to flourish and this environment needs to be established and lived by the leadership folks.
PS: The talk idea and usage of Gregors elevator analogy have been approved by Gregor
Systems Thinking by combining Team Topologies with Context Maps
Team Topologies and Context Maps are two interesting approaches to visualize sociotechnical architectures. However using each method on its own you will not be able to capture a truly holistic view of the system as a whole but you can use both in combination and this is what this talk is about.
This talk will introduce a Systems Thinking perspective on those two approaches and explain how both can be leveraged in combination to get a deep dive on many interactions in a system of teams and software. Those interactions include:
- team relationships
- team dependencies
- propagation of domain models
- governance related communication
- provisioning of APIs / services
However we will also look at the components of the system with Team Topologies being team centric and Context Maps being bounded context centric.
I will finally explain how you can use both methods to visualize alignments between domains, bounded contexts and teams.
This talk assumes that you have a basic understanding of strategic Domain Driven Design (esp. Bounded Contexts and Context Maps)
Your tech stack is beautiful, but so is your domain
Of course we all love our favorite technologies and of couse it is important to understand your tech stack as a developer. Certainly you become a great developer or architect by understanding modern patterns and architectures.
But isn’t it a bit boring to just churn out code just for codes sake?
In this talk I want to motivate you to leave your comfort zone and to take a step back. This talk aims at motivating you as a developer or an architect to dig deep into the domain of your business and your product. I firmly believe that this will make you a great and especially a more valuable developer. If we understand the business we can make better design choices as developers / architects. We can highlight misalignments in our organization. We will be able to come up with better tests.
This talk will not just be limited to the motivating side of this topic. I will also give you tons of hints and tips how you can get started in this journey, who your allies may be and how to tackle this difficult task. This talk will also come with many examples of success and failure from the real world. I guess we will laugh a lot during this session but sometimes we’ll also shake our heads in utter disbelieve in those 50 minutes.
Modern architectural work: from defining to enabling
Many large organizations still work with centralized architecture-related teams. Their role is often to provide architectural specifications to other teams and ensure that these specifications are adhered to during implementation. These teams are often referred to as "ivory tower architecture" teams that aim to bundle highly skilled architects. This role is certainly not available in abundance on the market.
However, they do not fit into an agile environment where we want to give teams the opportunity to make their own decisions. Certain guard rails are nevertheless necessary to ensure that the overall construct works. In addition, well-chosen guard rails can also drastically reduce the need for coordination between teams.
We need to enable these teams to do most of the architectural work themselves, while ensuring that the individual parts fit together. This is where Team Topologies, a concept introduced by Matthew Skelton and Manuel Pais, comes into play. There is a team type called the " Enabling Team" which, in a nutshell, supports other teams with knowledge and methodology.
This presentation will give you an overview of this change as well as practical guidance on how to transform a centralized architecture team into an enabling team whose task is to improve the architecture work in other teams. You will learn:
- Which stakeholders you should involve in this process
- Why the future enabling team also needs to be empowered and how to do this
- Where common pitfalls lie on this journey
- Why this journey needs to be done in an agile way with continuous learning and retrospectives
This talk will also include many real-life examples that accompany such a transformation.
iSAQB Software Architecture Gathering 2021 Sessionize Event
Domain-Driven Design Europe 2021 Sessionize Event
Distributed Domain-Driven Design Day (DDDDD) Sessionize Event
Domain-Driven Design Europe 2020 Sessionize Event
KanDDDinsky Sessionize Event
microXchg 2018 Sessionize Event
BED-Con 2018 Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top