Kenny Baas-Schwegler
Domain-Driven Deep Democratic sociotechnical system designer
Amsterdam, The Netherlands
Actions
I believe in collaborative software design where ‘every voice shapes the software’. Leveraging a domain-driven design approach with Team Topologies, I facilitate clearer communication between stakeholders and software creators by collaborative modelling and deep democracy, decoding complexities, resolving conflicts and ensuring software remains agile to business demands.
As an independent software consultant and trainer, I specialize in technical leadership, software architecture, and sociotechnical system design. I work with organizations and teams to design and build software architectures that are both sustainable and resilient.
Links
Area of Expertise
Topics
In the Absence of Collaborative Modeling, Our Software Design Decisions Fade into Obscurity
In software design, we frequently overlook a vital step: collaboratively visualising the understanding of needs and design decisions alongside stakeholders and teams. Skipping this collaborative visualisation fosters misunderstandings and expectation mismatches. This confusion often steers us toward solutions that miss the mark, causing a rift between stakeholders and the development team. Moreover, this absence of a mutual understanding weakens our software architecture's resilience. Developers, without a thorough understanding of the domain, find it challenging to design systems resilient and adaptable enough to navigate the complex future of uncertainties. The principle is clear: without visualisation, our discussions and design decisions might as well not exist—they remain obscure. This highlights the importance of collaborative modelling in designing architectures that are not only resilient but also prepared for future challenges.
This presentation aims to navigate you through the strategic use of collaborative modelling to build a common understanding crucial for developing architectures ready for the challenges ahead. We'll take you through various practical design challenges encountered while consulting organisations. You'll learn about our choices of collaborative modelling tools, the rationale behind these choices, and a peek into our heuristic toolkit. This toolkit, which you'll be equipped with by the end of our session, will empower you to start integrating collaborative modelling into your company's practices. We'll share insights into making these practices stick and times they didn't—and the lessons learned. This talk is designed to jumpstart your journey in collaborative modelling within your team or organisation, not just to clarify design decisions but to ensure comprehensive alignment and understanding of these choices among stakeholders and developers alike.
Navigating Conflicts in Software Architecture Decision Making
Software architecture forms the backbone to building successful software systems, but the decision-making process can be a hassle to navigate due to complexity and conflicts. These conflicts can originate from a lack of complete information to emotionally charged personal preferences, leading to decisions that may not fully align with the system's overall objectives. This misalignment can result in a less than ideal software architecture for the business and it also can leave the team members unhappy and resist the decision. Our goal should be to ensure decisions are sustainable – benefiting both the technical needs and the human needs involved.
Drawing from our co-authored book “Collaborative Software Design”, this concise one-day workshop is focused on understanding conflicts during collaborative modelling and architectural decision-making and navigating them effectively.
In this workshop, you will:
* Get an overview of the importance of collaborative modelling for clear communication and its role in sustainable software design.
* What are architectural decisions?
* Delve deep into the heart of decision-making conflicts in software architecture and how they can hamper the overall system design.
* Explore the concept of "role theory" from Deep Democracy, understanding how it forms the basis for inclusive and sustainable decision-making.
* Learn practical techniques to manage conflicts, ensuring every voice is heard, and the minority opinion is incorporated.
This workshop is a must for software engineers, architects, tech leads, and managers who are looking to elevate their decision-making processes, ensuring they are effective, inclusive, and sustainable. Join us to navigate the intricate maze of software architecture decision-making with clarity and confidence.
Deep Dive into Model-Driven Design: Refining Domain Models in Code
Most software products begin with an initial software model, one that is typically naive and superficial, grounded in basic understanding. This initial phase is natural, as it aligns with the early stages of discovering and exploring a new product with stakeholders. Initially, the process involves identifying nouns and verbs to create the first objects and methods in our code. While this early model enables quick feedback for the product, it often becomes less effective over time. As more feedback is gathered, the model usually fails to accurately reflect the main concerns of domain experts, becoming less relevant for the product's development. The absence of a model that mirrors the domain's core aspects can prevent adjustments to the code based on changing stakeholder needs, potentially blocking product innovations. Additionally, the gap between the code and the domain model leads to missed opportunities for insights, as the code no longer represents our domain knowledge accurately.
Join us in this hands-on modelling and coding session focused on the significance of continuously refining your core domain models in code. We will introduce you to the context by guiding you through collaborative modelling techniques such as Eventstorming, Domain Storytelling, Context Mapping, CRC cards and more. Dive into coding challenges using C# and Java, where you'll witness firsthand the transformative power of supple design and a deeper model. By the end, you'll understand how continuously refactoring the model can be pivotal in driving product development breakthroughs. Whether you prefer pairing or ensemble programming, you'll depart with enriched practical insights and a kickstart into Deep Diving into Part III of Evans’s groundbreaking work on Domain-Driven Design (DDD), specifically designed for those looking to advance beyond basic concepts like aggregates, entities, and value objects.
Deep Dive into Model-Driven Design: Refining Domain Models in Code
Most software products begin with an initial software model, one that is typically naive and superficial, grounded in basic understanding. This initial phase is natural, as it aligns with the early stages of discovering and exploring a new product with stakeholders. Initially, the process involves identifying nouns and verbs to create the first objects and methods in our code. While this early model enables quick feedback for the product, it often becomes less effective over time. As more feedback is gathered, the model usually fails to accurately reflect the main concerns of domain experts, becoming less relevant for the product's development. The absence of a model that mirrors the domain's core aspects can prevent adjustments to the code based on changing stakeholder needs, potentially blocking product innovations. Additionally, the gap between the code and the domain model leads to missed opportunities for insights, as the code no longer represents our domain knowledge accurately.
Join us in this live coding talk session focused on the significance of continuously refining your core domain models in code. We will introduce you to the context by guiding you through several collaborative modelling techniques such as Eventstorming, Domain Storytelling, Context Mapping, CRC-cards and more. We then dive into coding challenges using C# where you'll witness firsthand the transformative power of supple design and a deeper model. By the end, you'll understand how continuously refactoring the model can be pivotal in driving product development breakthroughs. You'll depart with enriched practical insights and a Deep Dive of Part III of Evans’s groundbreaking work on Domain-Driven Design (DDD) that goes beyond basic concepts like aggregates, entities, and value objects.
Tackling Social-technical complexity in the heart of your team
As a software engineering team, we want to solve complex business problems in the most efficient way possible. We invest a lot in technology to improve our team flow and try to make our technology process sustainable. We’ve got quite compulsive about automation and autonomy in achieving this. However, we are still tribal creatures that require tribal safety. Which means that if we want to make our technology process sustainable, we must also invest in people. For that, we need to tackle socio-technical complexity in the heart of our team.
In this session, Evelyn and Kenny will introduce you to the concept of socio-technical systems. We will explain what socio-technical complexity we are facing when building software to improve our team flow. How you can get a sense of the type of complexity you’re dealing with by using the Cynefin framework. Cynefin can aid your decision-making process by helping you make less biased decisions on how to approach your software development flow with your team. Finally, we’ll show you how visual collaboration tools like EventStorming and many others that can help you visualise complexity. You will leave this session knowing how to start tackling socio-technical complexity in your team. Making sure you create a sustainable technology process for your team flow!
Reshaping Cultural Perspectives in Software Design
Software stakeholders and users approach technology through the lens of their cultural norms and worldviews. As software designers, we often introduce new concepts and terminology to better address those needs. This can mean adapting or even reshaping their cultural perspectives. But culture, by nature, seeks consistency and conformity, providing a framework to our daily chaos. This consistency can make language and models rigid, often leading to ambiguity. So, how can we navigate and reshape these ingrained cultural perspectives and behaviours during software design?
Join our interactive workshop exploring the dynamic interplay between organisational culture and software design. We delve into the crucial role of culture in influencing software design, with a focus on 'symbols' as a key cultural element. We engage with a domain model that showcases how language, as a cultural symbol, has significant implications in both domain-specific and software contexts. Through practical exercises, we'll explore methods to understand the cultural importance of these symbols, guiding participants in either adapting to work effectively with them or using strategies and heuristics to change them. We will wrap up with a series of case studies, presented through interactive discussions. These studies will demonstrate the application of different techniques and heuristics in collaborative software design, highlighting both successful and failed experiences in navigating and reshaping cultural symbols and behaviours.
Reshaping Cultural Perspectives in Software Design
Software stakeholders and users approach technology through the lens of their cultural norms and worldviews. As software designers, we often introduce new concepts and terminology to better address those needs. This can mean adapting or even reshaping their cultural perspectives. But culture, by nature, seeks consistency and conformity, providing a framework to our daily chaos. This consistency can make language and models rigid, often leading to ambiguity. So, how can we navigate and reshape these ingrained cultural perspectives and behaviours during software design?
Join us for an insightful discussion on the dynamic interplay between organisational culture and software design. We delve into the crucial role of culture in influencing software design, with a focus on 'symbols' as a key cultural element. Our presentation will feature real-world examples that showcase how language, as a cultural symbol, has significant implications in both domain-specific and software contexts. We will explore methods to understand the cultural importance of these symbols, guiding participants in either adapting to work effectively with them or using strategies and heuristics to change them. Our conclusion will present a series of case studies where various techniques and heuristics were applied in collaborative software design. These cases will highlight both successful and failed experiences in navigating and reshaping cultural symbols and behaviours.
How Domain-Driven Design enabled scaling a big ball of mud product
Many products start out with a simple, naive model able to prove market fit. And most of the time that one model grows, because more features need to be put in at a fast pace. This can have a huge impact once the product needs to scale. Because that face pace can turn the model into a big ball of mud, and most of the time that model isn’t the most useful model to solve the core business problems anymore. Everyone in the team knows we need to change that big ball of mud, but we also don’t want to close shop. We want to keep adding features to attract more customers, scale the product and turn into a profitable product. So how can we both get ourselves out of the big ball of mud while also scaling the product?
In this talk I will tell the story of how our software development team decoupled their big ball of mud, to several bounded contexts all within the same monolith. I present several heuristics, practices, tools and a strategy to decouple the current model while continuously adding features to the product and gaining feedback from the customers. One of the bigger challenges was that the team had no knowledge of Domain-Driven Design, and I will show you how the team with their stakeholders started embracing DDD. Ending up with a strategy to disentangle the model, an idealised bounded context design and monitoring domain events from the bounded context that drove collaboratively drives the product roadmap.
Facilitating collaborative design decisions
If we want to make sustainable design decisions for our architecture that are embraced by everyone, the most effective way is to do this collaboratively. Everyone can feel a part of the decision, and can potentially give the input they have. The group is aligned and knows what is to be expected onward. On paper this sounds great, but in reality we know it is hard to do because we need to deal with all sorts of group dynamics. Dynamics like cultural differences, conflicts of opinions, cognitive biases, and polarities that the group are part of. These dynamics cause people to stop sharing what they want, which ends up in resistance behaviour from sarcastic jokes, to stopped communication or leaving the session. No wonder a lot of people resort to a more autocratic form of decision making, where the architect analyzes and makes the decision. So how can we make collaborative decision decisions better?
Join Gien, Evelyn and Kenny in this hands-on workshop where we explore different models of decision making that can help facilitate collaborative design decisions. We will dive into a variety of facilitation techniques such as:
Working with climate reports to trigger hidden group conflicts
Visualising trade-offs of different models with the pro-con-fix list
Taking group decisions with full buy in with Deep Democracy
Does culture impact software design?
(This is a hands-on lab with limited capacity)
DDD is about understanding and communicating complexity. We have long recognized that the most effective way to communicate complexity is via human language. But language poses a challenge when working in a team comprised of members of different (sub)cultures and nationalities, each with a native language that might not be the same as the language we are communicating in. Each of these cultures has a different perception about how to communicate effectively. By way of example, in some cultures, it is considered appropriate and respectable to use the tentative voice “perhaps we should consider trying X”. Whereas in other cultures it is the assertive voice that is valued “This is how we should do it”.
Assuming that everybody in the room wants to communicate effectively, what aspects can we define that impact our design? What organizational culture fits better with what type of architecture (microservices, monolith)? And what cultural needs must these architectures and boundaries address to succeed? Join us in this hands-on where we together explore these challenges!
Does culture impact software design?
One of the objectives of software architecture is the understanding and communicating complexity. We have long recognized that the most effective way to communicate complexity is via human language. But language poses a challenge when working in a team comprised of members of different (sub)cultures and nationalities, each with a native language that might not be the same as the language we are communicating in. Each of these cultures has a different perception about how to communicate effectively. By way of example, in some cultures, it is considered appropriate and respectable to use the tentative voice “perhaps we should consider trying X”. Whereas in other cultures it is the assertive voice that is valued “This is how we should do it”.
Assuming that everybody in the room wants to communicate effectively, what aspects can we define that impact our design? What organizational culture fits better with what type of architecture (microservices, monolith)? And what cultural needs must these architectures and boundaries address to succeed? Join us in this interactive talk where we together explore these challenges!
Designing software to withstand the complexities of organisational power dynamics
As software designers and engineers, our primary focus often gravitates towards the technical aspects when crafting solutions. We align these solutions with stakeholder needs using well-established design patterns, drawing inspiration from industry "best" practices and current trends. While we often consider organisational constraints like business capability maps, domain architectures, and organisational structures, there's an intricate web of power dynamics within organisations that often remains unaddressed. This spectrum ranges from biases in action or planning, the tension between centralised and decentralised decision-making, to the deeply rooted culture of “that won't work here”. Overlooking these dynamics can be a recipe for brittle software architectures, unable to withstand the complexities of these organisational power dynamics.
In this session, we will delve deep into how you can design software architecture to be antifragile against the complexities of organisational power dynamics and culture guided by Barry M. O'Reilly's residuality theory. This innovative approach to software architecture uses the concept of "stressors", unforeseen events that challenge system stability. Recognising the diverse nature of these stressors is pivotal to architecting software with resilient and antifragile behaviour. By weaving in organisational dynamics and culture as stressors, we lay the foundation for a more resilient software design. We will explore how to pinpoint these stressors by observing cultural symbols and understanding fractal social behaviours. I'll further illustrate the significance of using the symbols and fractals as stressors through a real-world case study. Attendees will depart with practical insights, ready to include the social dynamics into their next software design, enhancing its resilience against the complexities of organisational power dynamics.
Collaborative Software Design: How to facilitate domain modeling decisions
Software is becoming more central to our lives every day, yet creating high-quality software systems remains a significant challenge. This issue largely arises because many software teams focus too heavily on finding solutions rather than understanding the organisational context. To effectively address this, developers must engage and communicate with relevant stakeholders, cutting across various organisational settings and contexts. However, communication with the business side is fraught with potential pitfalls: misunderstandings can occur, individuals may feel intimidated to speak up, tensions might escalate, and conflicts can emerge. These social dynamics can lead to a breakdown in knowledge sharing, manifesting in resistance behaviours ranging from sarcastic comments to complete disengagement or even leaving discussions altogether. As a result, many organisations default to a more autocratic decision-making style, where a single individual, typically the architect, analyses the situation and makes decisions. However, to achieve sustainable and widely supported design decisions for our architecture, it's more effective to employ visual techniques to make assumptions clearer, which in turn improves collaboration between developer teams and domain experts.
In this talk, we will explore collaborative modelling and the social dynamic challenges it presents. Collaborative modelling is a visualisation technique designed to analyse complex and dispute-ridden decision-making processes, bringing together all relevant stakeholders and decision-makers to develop a common understanding. A significant aspect of this approach is the facilitation of sessions to ensure everyone feels included in the decision-making process and is able to contribute their insights. We will highlight the importance of developing a diverse skill set that includes observing, listening, remaining neutral, and showing empathy to foster better collaboration. The objective is to enable software teams to collaborate with their stakeholders, understand their needs, and allow this understanding to guide their software architecture. This is the core of what we define as engaging in collaborative software design!
Collaborative software design for team cognitive load
When navigating the complexities of software design and development, new ideas and future requests frequently cross software and team boundaries. The most effective approach to these design challenges is through collaborative modelling sessions, where teams are directly involved in crafting the software design. Yet, this approach leads us to a critical dilemma: What happens when new capabilities increase the cognitive load on a team, hindering their ability to deliver on both new and ongoing business needs? And how do we address situations where these new capabilities clash with our current architecture, leading to necessary changes that don't fit our existing team structures? Our goal is always to create the best architecture for our business challenges, but this depends heavily on our teams' delivery capabilities. This brings us to a fundamental question: If our teams face difficulties in implementing what is ideally the 'best' architecture, can we still consider it the most effective solution?
Join us in this interactive, hands-on session, where you will delve into a real-world software design challenge that intersects both software and team boundaries. Equipped with detailed context and comprehensive software diagrams, you will design in groups two potential software designs. You are free to approach the challenge in any way you prefer, and we will provide a message flow modelling template to help you quickly start addressing your challenge.
From those initial two designs, we will introduce you to the fundamental principles of Team Topologies, focusing on how cognitive load affects the teams involved and your software design. This understanding of cognitive load will be crucial as we further explore more solutions to the design challenge. Throughout this session, you will gain practical insights into how cognitive load influences your approach to software design. You will learn how to effectively incorporate Team Topologies into your design decisions. By the end of this experience, you will have hands-on software design experience, tackling complex design challenges with a team-first approach.
Autonomy, is that what we really want?
There has been a focus on autonomy in information technology; From autonomy in code, autonomy while coding, autonomous systems with microservices to autonomous high-performing teams. When you read Daniel Pink's research in the book Drive, it makes sense; autonomy is one of the three things that motivate us; it is the ability of the person to make his or her own decisions. However, often autonomy can lead to isolation and disconnect from the rest of the code, team, or organisation. So how can we balance the individual needs while staying connected to the team/organisation to stay autonomous?
In this talk, we will go through all the levels we deal with in IT, from code to organisation collaboration. We will go into autonomy at each level and explain how we often confuse autonomy with individual needs. These individual needs can turn into isolation and disconnect from the code, team and organisation. Through examples, we will show how our compulsiveness towards autonomy gives us both downsides of being isolated and coupled in the code, within the team and organisation. You will leave the talk knowing how polarity management can help you manage this paradox between the individual and the team/organisation and get the benefits from the whole and the individual to be balanced.
The Impact of Team Cognitive Load on Software Design
When navigating the complexities of software design and development, new ideas and future requests frequently cross software and team boundaries. The most effective approach to these design challenges is through collaborative modelling sessions, where teams are directly involved in crafting the software design. Yet, this approach leads us to a critical dilemma: What happens when new capabilities increase the cognitive load on a team, hindering their ability to deliver on both new and ongoing business needs? And how do we address situations where these new capabilities clash with our current architecture, leading to necessary changes that don't fit our existing team structures? Our goal is always to create the best architecture for our business challenges, but this depends heavily on our teams' delivery capabilities. This brings us to a fundamental question: If our teams face difficulties in implementing what is ideally the 'best' architecture, can we still consider it the most effective solution?
Join us in this talk as we delve into a real-world software design challenge that spans both software and team boundaries. We will explore the case of an online food delivery service, outlining their current software landscape and the emerging challenges they face. We will present potential solutions to these challenges, illustrating our typical approach to such issues. By introducing you to the fundamental principles of Team Topologies, we will demonstrate the impact of cognitive load on software design. Understanding cognitive load is crucial as we examine more solutions to the design challenge. This talk will provide practical insights into how cognitive load influences your approach to software design and how to effectively integrate Team Topologies into your design decisions.
Effective software design: The role of men in debugging patriarchy in IT
Effective software design relies on integrating diverse perspectives throughout its development process. Research shows that teams with a neuro-diverse background excel in decision-making due to their ability to consider a wider range of ideas, foresee a greater variety of potential challenges, and develop more creative solutions. This becomes particularly clear in collaborative modelling for Domain-Driven Design. The inclusion of varied viewpoints enhances the ability of software models to address business problems effectively, increasing the likelihood of achieving significant product breakthroughs.
However, one social system significantly blocks the flow of development of these diverse perspectives: patriarchy. Patriarchy is a social construct where men predominantly hold power and exercise dominance in areas such as political leadership, moral authority, social privilege, and property ownership. Feminists have been actively working to challenge and change this patriarchal system for the better. Despite these efforts, the system still favours men, maintaining their dominant status, and will not evolve without their active involvement. Additionally, patriarchy limits men as well, endorsing only traits traditionally seen as 'masculine' and disregarding those seen as 'feminine.' This raises the question: how do we start the process of eMANcipation, involve men in the movement towards feminism, and as a result, improve our software design practices?
Join me in this talk as I explore patriarchy and its significant effects on software design. Drawing from personal experiences, I will discuss how patriarchy affects men and argue that for genuine equality, men need to undergo changes too. I will demonstrate how incorporating Process Work and Deep Democracy into software design can bring about the necessary transformation. By adopting the idea of role fluidity, we can start breaking down the patriarchal system in software design, ensuring that every perspective is appreciated and nurtured. You will leave with a deeper understanding of how patriarchy influences software design and practical steps you can immediately apply to foster a shift towards a more inclusive environment.
Newcrafts Paris 2024 Sessionize Event
iSAQB Software Architecture Gathering – Digital 2022 Sessionize Event
KanDDDinsky 2022 Sessionize Event
Techorama Netherlands 2022 Sessionize Event
Kenny Baas-Schwegler
Domain-Driven Deep Democratic sociotechnical system designer
Amsterdam, The Netherlands
Links
Actions
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