Talks & Hands-on

Designing a software system is difficult. Understanding the context in which a software system lives is more difficult. In order to understand that context, developers need to communicate with the business. But there is a lot that can go wrong while communicating with the business. For example people can misunderstand what is being said, they are scared to speak up, tensions could grow, and conflict can arise. These social dynamics cause groups to stop sharing their knowledge, which can end up in resistance behaviour from sarcastic jokes, to stopped communication or even not showing up or leaving the session. No wonder a lot of organisations resort to a more autocratic form of decision-making, where one person, the architect, analyses and makes the decision. If we want to make sustainable design decisions for our architecture that is embraced by everyone, it is better to use visual techniques to make assumptions more explicit which will improve collaboration between developer teams and the domain experts.

In this talk we will introduce you to collaborative modelling and its social dynamic challenges. Collaborative modelling is a visualisation technique to analyse complex and conflict-laden decision-making processes with all relevant stakeholders and decision-makers to create a shared understanding. And some, maybe even most of these sessions need to be facilitated so that everyone can feel a part of the decision and can potentially give the input they have. I will explain why it requires us to have a different skills set like observing, listening, trying to stay neutral and show compassion. Because that improved collaboration will let software teams understand better the context and underlying problems the business has. That understanding enables the software teams to design and build sustainable quality software products.

• LEADCommunity meetup / 1 March 2023 / Slides

There has been a focus on autonomy in information technology; From autonomy in code, to 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.

• Flowcon france 2022 / 18-19 October 2022 / Slides
• Lean Agile Scotland 2022 / 5-7 October 2022 / Slides
• Agile meets Architecture 2022 / 6-7 September 2022 / Video – Slides
• NDC Oslo 2021 / 29 November 2022 / Video – Slides
• DDD Taiwan 2021 / 16 October / Video – Slides
• End-to-End live 2021 / 18 June 2021 / Video – Slides

How can we get better as software designers? By becoming more aware of our design heuristics and being intentional as we cultivate and refine them. Heuristics aid in the design and even determine our attitude and behaviour. We each have our own (often implicit) heuristics acquired through reading, practice, and experience, especially when surrounded by legacy software. Let us share these heuristics during a modelling session! In this session, I’ll present you with a legacy modelling problem, which I will show you how we can solve with DDD legacy patterns. I will explain the four strategies for getting started with DDD when you have a big commitment to legacy systems by Eric Evans. To really understand the strategy, I will explain the bounded context pattern and show you how you can implement the strategy in your architecture. Finally, I will share some personal heuristics when dealing with legacy software. You will leave this session with shared knowledge from experience in dealing with legacy software and how you can start Context mapping for strategic Domain-Driven Design patterns while surrounded by legacy!

• Techorama 2022 – Slides

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 is 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

• iSAQB Software Architecture Gathering – Digital / 14-17 November 2022
• KanDDDinsky / 31 October – 1 November 2022 / Slides – Miro
• Domain-Driven Design Europe / 20-24 June 2022 / Slides – Miro
• OOP Konference / 31 January – 4 February 2022
• Software Architektur im Stream / 1 February 2022 / Video

The power of collaborative modelling comes from having a diverse group of people who, together, have a lot of wisdom and knowledge. You would expect that all this knowledge will be put to use, co-creating and designing a model. In reality, we don’t actually listen to all the available input and perspectives due to cognitive biases and ranking. Because not everything that needs to be said has been said, we will end up with sub-optimal models and architecture. Even worse, people don’t feel part of the solution and don’t commit to it. Good architecture and design need all the insights and perceptions. If we are not aware, cognitive biases and ranking will kill those insights and wisdom and kill your models’ effectiveness!

Join us in this talk where we will explain why we need collaborative modeling, and how that changes the role of architects to a facilitator of design. We will explore how we can improve our facilitation skills by being aware of ranking, and how to let the group go around cognitive biases they will have. We will show you that making use of the full potential and knowledge of the group this way, will lead to conflicts. Conflicts that need to be solved before we can collaboratively make decisions with the power of Deep Democracy. You will leave with a lot of powerful facilitation heuristics you can use in your next collaborative meeting!

• Deliberate Complexity Conferences / 29 June 2022 / Video & Slides
• Developer week management / 10-11 May 2022 / Slides
• BiL-T Modern Software Architecture / 10 February 2022 / Video – Slides
• Jfall / 4 November 2021 / Video – Slides
• Digital Architecture Design Day / 4 June 2021 / Slides
• DevOpsDays Amsterdam / 29 June 2021 / Video – Slides
• μCon: The Microservices eXchange / 13 April 2021 / Slides
• Spa Conference / 23 March 2021 /
• OOP Conference / 8 February 2021
• Domain-Driven Design Europe / 4-5 February 2021
• Flowcon france / 23 November 2020 / Video – Slides

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!

• Domain-Driven Design Europe / 20-24 June 2022 / Slides
• iSAQB Software Architecture Gathering / 11 – 14 October 2021
• Software Architektur im Stream / 14 October 2021 / Video
• DDDeXchange / 8 June 2021

I’ve been involved in several transformations over the years, from DevOps to Digital to Agile. These transformations typically focus on transitioning people into near-autonomous teams of no more than eight people who will work in an agile manner. Every company I’ve worked for asks the same questions at these transformations: How do we divide the current software between the teams, and how do we align these teams to our business architecture?

To address these questions, companies request my help to design microservices using a Domain-Driven Design (DDD) approach. This approach makes it easier to distribute the software between teams based on identified boundaries, called “bounded contexts.” While I believe enterprises involved in an Agile transformation need at least a Domain-Driven Design approach to create autonomous aligned teams with a loosely-coupled architecture, this process presents unique challenges. In this talk I will present my experience report, I share my experience over a period of six months using DDD to transition a financial enterprise towards Agile autonomous teams.

• Tweakers Developers Summit / 23 June 2022 / Slides
• Progressive Delivery Conf / 18 march 2021 / Slides