Michael Plöd
INNOQ - Fellow
Nürnberg, Germany
Actions
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
Lessons learned from introducing Team Topologies
This talk is an experience report from numerous transformations towards the ideas of Team Topologies.
Over the last years I have helped several organizations to work with Team Topologies. The activities were very diverse. Often it was about the identification of suitable team boundaries and the establishment of different Team Topologies such as Stream-aligned, Enabling, Complex Subsystem or Platform Teams and the appropriate modes of interaction to achieve a fast flow. The continuous evolution of the org model was also a frequent topic.
During these activities, some facets have emerged that work well, but also some challenges that are not mentioned in the book by Matthew Skelton and Manuel Pais. Examples of this would be salary bands, the role of HR or the topic of budget planning for the teams.
I will discuss these topics and many others in this presentation to give you valuable tips for working with Team Topologies.
DDD for agile coaches and product owners
Domain Driven Design is mostly known in the software engineering and -architecture communities and currently also branching out towards other disciplines like for instance the sociotechnical and to a certain degree to the DevOps communities.
But what about folks who are product owners, scrum masters or agile coaches? Isn't DDD agile by heart? A key message of this talk is: yes it is.
You will learn how to leverage Domain Driven Design for your daily work in one of the roles mentioned above. We will go through these aspects by digging deep into the key principles of the agile manifesto and evaluating how DDD can help you as an agile coach or product owner with those.
This talk is no hardcore DDD deep dive talk, it is rather aimed at building bridges to other communities and roles.
Cohesion in modeling and design
“Loose coupling & high cohesion” are key design principles for creating maintainable and understandable software. These principles can be applied on different levels of granularity ranging from classes to even systems. They also play an integral part when setting boundaries for domains and bounded contexts. While there have already been many talks and workshops on coupling at various conferences the topic of cohesion hasn’t been covered as much. This talk is all about cohesion.
We will begin by exploring the fundamental principles of cohesion in software design, illustrating its significance in creating clear, maintainable, and scalable systems. In this course you will learn what cohesion is and what kinds of cohesion there are. We will talk about types of cohesion in software design like functional, sequential, temporal or coincidental cohesion. But this talk will also look at the term cohesion in other disciplines like chemistry, geology, social behavior or soil mechanics.
In the second part this talk will cover cohesion in Domain Driven Design. A holistic approach to the topic of cohesion is especially interesting in the context of Domain Driven Design. For instance an Ubiquitous Language aims at a high degree of cohesion between terminology, conversations, code and documents within a Bounded Context. Special attention will be given to practical approaches for achieving high cohesion in domain models. We will explore real-world scenarios where cohesive design directly impacts the effectiveness of DDD, offering insights into overcoming common challenges faced in complex domain scenarios. Through this, attendees will gain a deeper appreciation of how cohesive design principles can simplify complex domain models, leading to more robust and adaptable software systems. But we will also look at the meaning of cohesion in other disciplines, which are mentioned in the intro of the talk, and learn how they can help us during collaborative and interdisciplinary design work.
This talk is designed not only for software architects and developers but also for non-technical stakeholders who wish to understand how cohesive software design can directly contribute to meeting business objectives. By the end of this session, attendees will be equipped with actionable strategies to enhance their domain models, ensuring that their software truly reflects and serves their business domain with clarity and precision.
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.
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