#86 - Adaptive Systems with Wardley Mapping, Domain-Driven Design, and Team Topologies - Susanne Kaiser

[00:01:22] Episode Introduction

Henry Suryawirawan: Hello to all of you, my friends and listeners. Welcome to the Tech Lead Journal podcast, the show where you can learn about technical leadership and excellence from my conversations with great thought leaders. And today is the episode 86 of the podcast. Thank you for tuning in today listening to this episode. If this is your first time listening to Tech Lead Journal, subscribe and follow the show on your podcast app and social media on LinkedIn, Twitter, and Instagram. If you are a regular listener and enjoy listening to the episodes, support me by subscribing as a patron at techleadjournal.dev/patron.

My guest for today’s episode is Susanne Kaiser. Susanne is an independent tech consultant from Germany, supporting organizations with building socio-technical systems. She is the author of the upcoming book “Adaptive Systems with Domain-Driven Design, Wardley Mapping, and Team Topologies: Architecture for Flow”, which will be part of the Addison-Wesley Vaughn Vernon Signature Series.

In this episode, Susanne explained how she connected the dots between three different popular methodologies, which are the Wardley Mapping, Domain-Driven Design and Team Topologies, to design and build adaptive systems to support for a fast flow of change. And she explained further why it is important for any organization to have adaptive systems. Susanne went in depth to explain about the Wardley Mapping strategic framework, its five different sections, and how they support designing and evolving effective business strategies based on situational awareness and movement following a strategy cycle. She then explained how to translate from a Wardley map into Domain-Driven Design, and how DDD actually helps in applying the Wardley Mapping doctrine principles, which are the principles that you can apply in any industry, regardless of the context. Afterwards, Susanne then explained how Team Topologies can help to create effective team boundaries based on DDD’s bounded contexts and optimize team’s cognitive load to support fast flow of change. Towards the end, Susanne shared her experience, how we can apply this process in our organizations, as well as in legacy systems.

I really enjoyed my conversation with Susanne, learning how to align and connect the dots between the 3 popular methodologies – the Wardley Mapping, Domain-Driven Design and Team Topologies, and personally, I didn’t know much about Wardley Mapping before this conversation with Susanne. She explained how these three techniques can beautifully work with each other to provide a holistic approach, translating user’s needs and business strategy, to system design, and then team formation. Some parts of this conversation may sound abstract to you without seeing them in a diagram. Thus, I would encourage you to check out Susanne’s presentation notes that I include in the show notes. Make sure that you also check out other Tech Lead Journal episodes that cover Domain-Driven Design and Team Topologies. There are a number of them which are very popular among all of this podcast listeners.

And if you enjoy and find this episode useful, help me share it with your friends and colleagues who can also benefit from listening to this episode. Leave a rating and review on your podcast app, and share your comments or feedback about this episode on social media. It is my ultimate mission to make this podcast available to more people, and I need your help to support me towards fulfilling my mission. Before we continue to conversation, let’s hear some words from our sponsor.

[00:06:13] Introduction

Henry Suryawirawan: Hello, everyone. Welcome to another new episode of the Tech Lead Journal podcast. Today I have with me a guest named Susanne Kaiser. She’s actually a tech consultant based in Hamburg, Germany. And she is actually working on a book, which is up and coming. Part of the Vaughn Vernon series, actually. It’s talking about Adaptive Flow, Wardley Mapping, Domain-Driven Design and Team Topologies. So all this sounds like a very, very hippie terms these days. Everyone wants to learn. I, personally, haven’t heard much about Wardley Mapping. So today, I hope I can learn a lot of things about Wardley Mapping, and about building adaptive architecture in general. So Susanne, I’m really looking forward to this conversation. Thank you so much for spending your time here.

Susanne Kaiser: Thank you so much for having me, Henry. It’s a very pleasure to be on your podcast, so thanks a lot.

[00:07:00] Career Journey

Henry Suryawirawan: So maybe in the beginning, if you can help to introduce yourself, telling us more about your career highlights or maybe any turning points.

Susanne Kaiser: Yes. So I am, and as you mentioned, an independent tech consultant and I’m helping organizations with building their products, or focusing on architecture for flow, optimizing for fast flow of change. But my career has not started in tech. At the beginning, when I was graduating from school, I was really puzzled what to do next. I had no clear path at that time. I have to tell you that was at the beginning of the nineties. So I didn’t have so much access to internet at that time, and the options were quite restricted. So, out of options at that time, or out of creativity, I started a career in sales. I’d started a sales traineeship at that time, and after a while, I was figuring out that sales is not my passion, to be honest. So there are far better people in this market of sales than me.

At the time, we didn’t have all the great online courses that you can attend nowadays. If you don’t have access to books or if you don’t know what to read in that perspective, you’re kind of lost, left alone. By coincidence, I chose a traineeship that has also programming involved. That sparked my curiosity. I liked programming. It was at the beginning, at the very, very beginning. It was just like little riddles to solve, and I was so proud when the first sentence on the monitor appeared, “Hello World”. I was thinking, yes, the universe is mine. I was really proud, and it sparked a lot of curiosity and a lot of joy, and I was thinking, maybe that is the kind of career that I would like to follow. But I had to earn some money in order to support my studies financially. So I had to stay a little longer into sales to collect money and then to start then with computer sciences.

So when I started computer sciences, my gosh, a long time ago, 1997. And that’s where I did a career shift. This was the moment that was changing my life when I started my career in tech. I started as a software developer and became team lead. Then also later on I became a startup CTO. Then I started to go on public stages, talking about sharing the experiences that we were doing at the startup from moving from monolith to microservices back then. There was also another, I would say, sparking moment for me since going on stage and talking and sharing your ideas or your learnings with others was also very helpful for me because I also learned from others what their journey was. So these were, I guess, starting the career in tech and also going on public stages and also the network around it. That was the second turning point in my career, I would say.

Henry Suryawirawan: Thanks for sharing your journey. So it happened to all of us engineers. “Hello World”. It will be one of the most common program that you wrote whenever you learn any new programming language, in fact. It’s not just when you started your computer science degree.

[00:09:56] DDD, Wardley Mapping & Team Topologies

Henry Suryawirawan: So you have been a tech consultant, and you have been doing a lot of things including as a startup CTO, right? Now you are writing a book titled “Adaptive Systems with Domain-Driven Design, Wardley Mapping, and Team Topologies: Architecture for Flow”. So tell us more, how did you come up with this topic? It’s like very long and three different techniques all in one. So maybe, can you tell us a little bit more story about that?

Susanne Kaiser: Yeah. So, it started first with Domain-Driven Design in my career. So when I was starting the journey from monolith to microservices, then Domain-Driven Design came along. It put its focus on partitioning your problem domain into smaller parts, and then decomposing your problem domain into modular components, the bounded contexts where related behavior shall sit together, and also where bounded contexts reflect good candidates for microservices. So that was the first encounter with Domain-Driven Design back then.

The second encounter was when I was listening to Simon Wardley’s keynote at a Serverless conference back in 2018 in Hamburg. He talked about what Wardley Mapping is about. How to create situational awareness and to design and evolve effective business strategies. And I’ve to admit that moment when I listened to his very entertaining keynote, I was really puzzled. Because it was really interesting. It also sparked my curiosity again, and I was sitting there in the audience and was thinking. " Oh, yeah, that sounds really interesting, but how can I apply it to my case? How can I apply this to my context?" So I was then diving deeper in that because it was sparking some curiosity. And then it came along with that it is very combinable with Domain-Driven Design because Wardley Mapping itself is a strategic framework that was invented by Simon Wardley, and it helps to design and evolve effective business strategies that is based on situational awareness and movement following a strategy cycle.

The strategy cycle is a representation of change and how we need to react to it, and it also comes with five different sections. One of them is the doctrinal principles that you can apply as an industry, regardless of your context, and that prepares you to respond to changes and how the application of doctrinal principles prepares you to create or to respond better to changes. This was also the moment where Domain-Driven Design and Wardley Mapping are beautifully working together because Domain-Driven Design helps with applying this doctrinal principles of Wardley Mapping.

So one doctrinal principle is, for example, that you should partition your landscape into smaller parts. So, for example, where we have Domain-Driven Design decomposing and partitioning your problem domain into sub-domains, or decomposing when you go to the solution space of strategic design, where you decompose your problem domain into the modular components. And also, another aspect is also using a common language that, for example, Wardley Mapping suggest, that is also one core aspect of Domain-Driven Design where the collaboration between the domain experts and the development teams is an essential part in order to gain domain knowledge, which is described in terms of the ubiquitous language, the shared language, where we come back then to the common language that is subscribed from the doctrinal principles.

There are a lot of more doctrinal principles that a Domain-Driven Design is automatically applying or you apply automatically doctrinal principles while applying Domain-Driven Design. So that’s where they were beautifully working together. And also, another aspect is, for example, the landscape. So the strategy cycle also have one section that is the landscape that is the representation of your environment as an organization is operating and competing in. It is visualized with a Wardley Map composed of a Y-axis and an X-axis. The Y-axis is representing the value chain composed of users and user needs, and components that fulfill these needs either directly or indirectly. The user needs, on the other hand, also reflect the problem domain in a Domain-Driven Design. And also, Domain-Driven Design lets you also discover your core domain, that is then providing competitive advantage. That’s where you should strategically invest in most. So it creates also situational awareness that is also supported by Wardley Mapping.

So I combined Wardley Mapping with Domain-Driven Design first. Later on, Team Topologies came out in 2019. I was like, oh why didn’t I have this book already available when I was starting the monolith to microservices journey with my teams, with my colleagues at the startup? Because we were not really optimizing for fast flow of change. Everyone was trying to solve the complexities, the infrastructure and operational complexities of microservices that come with it. Instead, we should have the stream-aligned teams and then, later, the platform teams and we mingled everything together so the team’s cognitive load was largely exceeded. So that was the moment like, oh, no, gosh. That should have been available when I started the journey.

But anyhow, when I read this book, I was also thinking, yeah, it’s also applicable, and these connecting the dots between these three perspectives because also the well-defined team types and the well-defined interaction modes of Team Topologies promoting organizational effectiveness, and also have the focus on the stream of changes, fast flow of changes. Then by applying them, we also already apply the doctrinal principles of Wardley Mapping in terms of like flow optimization and also think small teams and provide a purpose, mastery, and autonomy. So they are all connected somehow together. I was thinking like we need to consider our system that we built as sociotechnical systems. When we go into a broader perspective, that brings the system thinking perspective in that the system is more than the sum of its parts. It’s a product of their interactions. That’s the reason why I like to connect the dots between these three perspectives, because they have more focus on improving the performance of the whole, instead of separate parts of the system.

[00:15:57] Adaptive System

Henry Suryawirawan: Thanks for sharing all this. For people who are probably trying to scramble, like how does it look like the interaction? So maybe later on, we can put in the show notes. You have a beautiful diagram, actually, to represent all this. I’ll make sure to put it in the show notes. But in the first place, all these three techniques, in your book, you mentioned they will support you to build a more adaptive system. You also mentioned about a fast flow of change, lesser cognitive load and things like that. How does this three actually help you to build a more adaptive system? And in the first place, why adaptive system is actually important for us?

Susanne Kaiser: So you focus on where the most important changes in your system occur. So to know where your stream of changes occur, and to focus on that one in order to improve a fast flow of changes. So that’s the first aspect, and then also the other one is to find suitable team boundaries, and also to optimize their team cognitive load and avoiding bottlenecks in terms of also minding the dependencies and the coordination or communication efforts between teams. Having also Conway’s law in mind that the communication structure is reflecting also the resulting or resembling system design. And also, we have to break our monoliths into smaller parts. We have to split our teams into smaller teams. We need to focus on clear team ownership boundaries, and that also brings it all together. So it’s like we have to have an organization or we have to prepare that change itself can flow through our organization without constant reorganization with constant restructuring.

And also that comes to our software design with Domain-Driven Design. So when we have a change and we want to change our system, we need to focus that this change is not affecting the entire system, so that we have to rebuild everything in order to make this change effective. That means that we have to concentrate behavior in specific places, or we have to identify the seams or the bounded context–the boundaries–where related behavior sits together, and although, when we change that behavior, we only have to change it in one place. So, in order to prepare for adopting flow, fast flow is to mind the dependencies, like where we have context mapping with Domain-Driven Design to visualize then the change coupling. So if we have a tightly coupled system, then, of course, you can’t adapt to changes quickly, because we have to touch so many pieces of our system to make this change effective, not only the parts of our system but also the teams that are responsible for these separate parts.

So it’s not only about the technical aspect of tight change coupling due to model propagation where you change the data structure of one component or one bounded context, or one domain model within one bounded context and affects other bounded contexts, but also do the teams owning this bounded context needs to coordinate and communicate in an ongoing manner in order to make this change effective. That is also related to the team communication, the team coordination. So we have to focus on cross-functional autonomous teams that are responsible for the system or the part of the system they are responsible for. They don’t have to constantly coordinate and communicate with other teams, and also like having other teams helping them, the stream-aligned teams in the team topology sense, that they can focus on a steady flow of feature deliveries, for example. So bringing in the perspective also the reason why we should also then break it into smaller parts is that we should not exceed the team’s cognitive load. Because when exceeding the team’s cognitive load, we are then running into delivery bottlenecks again, and with quality issues and also decreasing the team’s motivation as well.

Henry Suryawirawan: So thanks for sharing how all these three techniques can actually help you to be more adaptive and also support change. So change doesn’t become a constraint for all the teams and parts involved, but at the same time also change just flows through the system, and we can also isolate the change, not to be impacting so many areas.

[00:19:53] Wardley Mapping

Henry Suryawirawan: So in your book, you mentioned you have these three techniques. Obviously, they represent three different perspectives how to build adaptive system. The first one, Wardley maps, right? It maps to actually business strategy. Domain-driven itself maps to software design and architecture. And Team Topologies actually align to team organization, the sociotechnical aspect. So, to be honest, I haven’t heard much about Wardley Mapping, so the business strategy part. If you can probably explain to us what is actually Wardley Mapping for people who are not very familiar with this concept.

Susanne Kaiser: Yeah. So, Wardley Mapping is a strategic framework invented by Simon Wardley. It helps you to design and evolve effective business strategies based on situational awareness and movement following a strategy cycle. According to Simon Wardley, the strategy cycle, as I mentioned earlier, is a representation of change and how we need to react to it. It’s not static. It’s very dynamic. So then it has five sections.

It starts with the first section of purpose. That’s the “Why” of the business, why we are doing what we are doing. And then the next section is the landscape. That is the representation of the environment an organization is operating and competing in, and it is visualized with a Wardley map. So Wardley map is just a part of Wardley Mapping itself. But usually when you talk about, or when you see Wardley Mapping aspects, then usually they share a Wardley map that is the visual representation. It’s a representation of the evolution of a value chain. And it tries to focus on your users and your user needs so that they are the anchor of your map. It’s on the top of the Y-axis that represents the value chain. And then you try to identify what are the components are filling the user needs directly? And what are the components that facilitate other components in the value chain? They are plotted along the Y-axis. On the top, it’s more visible to the users where the users are interacting with your components directly, and that the lower part, it’s getting more invisible to the user itself. And then you try to plot this value chain along the evolution axis. The evolution axis is composed of genesis for brand new things, then custom-built, then product and rentals such as off-the-shelf products and open-source software and then commodity and utility evolution stage at the end. So you try to determine the stage of evolution for each component, its value chain and the movement of a component along its evolution axis. So the component itself is evolving through the evolution stages. That’s where climatic patterns come in.

Climatic patterns, that is the third section of the strategy cycle. They are describing external forces that are impacting the landscape over which we have no control. But we can anticipate these climatic patterns or some of them to give us an idea how the landscape might change. So, one climatic pattern is for example, that the map is never static, but very dynamic. So everything evolves through the forces of demand and supply competition. While the component evolves, going from one evolution stage to the other, their characteristic changes. So in genesis, we are dealing with brand new things that are constantly changing, that are uncertain, that we have to explore with, then it goes into custom-built, become more and more industrialized where we go to commodity and utility, where we are dealing with stable, well-known, well-defined, commonly understood market. And understanding these climatic patterns gives us an idea where the landscape might change, brings us also competitive advantage as well.

The fourth section is doctrine, and it describes universal principles that are applicable to every industry, regardless of the context. They describe that you need to know your users, that you need to focus on your user needs, and that you also need to use appropriate methods per evolution stage. Usually when people say we have to go agile. Yes, of course, it makes sense, but not across the entire organization. Because Simon Wardley suggests to use appropriate methods, for example, for components in genesis and custom-built, those components need to be built in-house with preferably agile methods. The components in product and rental, they need to more focus on, like, using buying off-the-shelf products or using open-source software, with preferably lean methods. For components in commodity and utility, you should outsource these components to utility suppliers or using Six Sigma methods. So there is also the doctrine principles, they are a catalog of 20-30 different doctrinal principles, and also the climate is described in 25 something climatic patterns. So it was just to give you an idea how you should prepare yourself, or to give you an idea where the landscape might change, and how to prepare yourself for this change and how well you can respond to changes itself.

And at the end, there is leadership. So that is something where Simon Wardley talks about gameplays. These are scenario plans on how to attack a space. When we’re applying these scenario plans, they have context specific on your specific context, then we are changing the landscape. But going directly from your purpose directly to the scenario plans, that is just a strategy by gut feeling. Instead, we should at least to know where the landscape is changing, and it’s by understanding the climatic patterns. We need to know where we are in terms of having the landscape visualized with a Wardley map, and also applying doctrinal principles to prepare ourselves to be able to adapt to a fast flow of change. So then at the end, we are then in the position to apply the scenario plans.

Henry Suryawirawan: Thanks for thoroughly explaining about this strategy cycle in Wardley Mapping. Is it in Wardley map or is it in Wardley mapping? So I’m a bit confused. But anyway, this strategy cycle starts with purpose, which is your “Why”? Why do you actually exist? Why you are there to solve customer problems, right? And then from there, you start to the landscape stage, which is where you probably come up with the competitive analysis. Like maps who are the players inside the landscape. And then you mentioned about the XY-axis, the value chain in evolution stages. I think this is also important because, in a particular organization, you have multiple systems and components. And each of those component actually resides on different evolution stage. Like you mentioned, some components might be a genesis, which is probably suitable for custom build or sub kind of experiments, while some others probably more commoditized, or you can even buy software as a service, for example.

How do you actually do this kind of exercise within a company? Do you always involve business stakeholders? Do you do this periodically, like every sprint, or is it every quarter? Maybe from your experience, how would you conduct this Wardley Mapping exercise?

Susanne Kaiser: Yeah, so it’s usually involved with those people that know the business. Specifically, for the purpose itself, deriving the purpose, like people or if management is involved in the discussions. Together, we are generating the Wardley map itself. So it usually start s with the purpose and the Wardley map. What is our purpose? What are our users? And users could be your customers. It could be business partners, internal users, and so on. Usually, I like this idea because when we are building a solution, a technical solution, I tend to focus on the technical solution first, and then, wait a second, do I generate value with this? Or this is something that helps you, because when you derive a Wardley map with your users and the user needs, and then the component fulfilling this user needs, this gives you an idea for who you are generating to.

It helps you to understand the problem better or the problem domain better. So far in my experience, it could be part of your retrospectives. It could be, usually we had monthly meetings, Wardley map was part of it, in terms of like, have we forgotten something, or has something changed? It depends on the context, I would say. So this could be part of your regular retrospectives or your monthly meetings, something like that.

Henry Suryawirawan: And then from the landscape, you move into the climate, which is the external forces that keeps changing outside of your control. Sometimes you are not aware of those changes, right? So you also put it in the Wardley map so that you actually understand how things shift within internal, your mapping as well. So maybe something is from custom build, you decide to move to commodity or some components you just replace it with something else.

[00:28:09] Doctrine Principles

Henry Suryawirawan: And then the next one is actually very interesting to me, right? This is called doctrine, which are the universal principles applicable, regardless of landscape. So why do you think this principle is universal? That’s the first thing. Does it always apply to any situation, no matter what? How does this help us to make things better in terms of adaptive design?

Susanne Kaiser: They are not context specific. Because every industry can apply it. So it doesn’t matter what industry you are in. The landscape is context specific, right, because they’re representing what your current landscape where you are operating in. But in the doctrinal principles, they are more about to focus on absorbing the change gracefully in your organization. The strategy cycle in total reflect the meantime to respond to changes, and how well you can respond to changes. The collection of doctrinal principles, they are supporting you in this journey. For example, to use appropriate methods per evolution stage. Because if you would like to be agile in commodity and utility, or if you, for example, are custom building components that are supposed to be in commodity and utility, then you are encountering an efficiency gap.

That’s also coming back to climatic patterns. So efficiency enables innovation. So the industrialization of one component enables the innovation of others. And the thing is when you have components that you custom build, but other components in the market are more evolved than the components that you use internally, you are definitely encountering an efficiency gap in terms of like, you are less efficient than, for example, your competitors that are building their system on top of more evolved components. Because the more evolved it is, it generates more efficiency.

To be aware of this one and to know where you are, where you stand, it’s really important to be able to move forward, to make a strategic decision. And that’s the doctrinal principles. They are then focusing on creating a transparent culture and it’s not only like technical related but also like sharing your knowledge and being transparent. Also, challenge assumptions by creating this map together and sharing this map and discuss it with others, and also, yeah, knowing the details. As I said, before we solve a problem, we need to understand the problem domain first. For example, all the decisions that are related to that. For example, let’s move to a Kubernetes cluster or something like that. Yeah. We can. But does it generate value in some aspects? So that we don’t lose the sight of all the users and the user needs. And I guess, that is kind of compass for us as an organization to prepare ourselves for then the strategic actions that are then reflected in the last section of the strategy cycle, the leadership.

Henry Suryawirawan: So, yeah, I hope to see all these principles mentioned in the book. The doctrine aspects to reflect and look back. Because these are universal principles. They will apply no matter what landscape you are in. And then from here, looking at the landscape, climate, doctrine, you start by building so-called the leadership, right? Your gameplays, your scenario planning, and hopefully, you have a good business strategy.

[00:31:16] Domain-Driven Design and Team Topologies

Henry Suryawirawan: So, moving on from there, let’s say you consult the customer. You have built these Wardley maps, and then moving on to the software design architecture, where now DDD plays a part. So tell us, how would you start once you have this Wardley map business strategy? And how do you move into the DDD phase?

Susanne Kaiser: So I take usually this Wardley map, and I start then with the users and the user needs that they are reflecting, then the problem domain in Domain-Driven Design. And then I start to identify which of these user needs are, I try to distill then the subdomains and to discover the core. So one of these user needs belongs to a core domain. So that is the subdomain of our problem domain providing the competitive advantage, and which tends to be quite complex, which tends to change frequently. That is the one that is generating our business success. That’s the one we need to strategically invest in most. So I start then with identifying, partitioning the problem domain into the smaller parts, the subdomains, and discovering the core in order to know where to invest most development effort. And that’s in the core domain related aspects when it comes to bounded context, for example.

So I first like to create situational awareness. Where is the most strategic part of our system? And I identify usually the user needs, which belong to the core domain? Which of the user needs belong to a supporting domain, subdomain, which belongs to the generic subdomain. So the supporting subdomain is supporting the core domain. It does not generate competitive advantage, but it supports the success of the core domain related aspects. The generic subdomain is also not creating a competitive advantage, but a lot of other business systems have this generic subdomain. So, for example, authentication and payment services as generic subdomain related aspects capabilities. It gives me an idea where to put in the most development effort. And then I start go further down. So that is the problem space of strategic design of Domain-Driven Design, and then I switch into the solution space of strategic design. That’s where we now decompose our problem domain into modular components, the bounded contexts. That’s where we then try to solve the problem with software. And there, I usually start the conversation to derive the bounded context and their related domain models. So the domain model is abstracting the business logic of that specific area of the system, of specific subdomain. And the bounded context itself forms a boundary around the domain model. Then I take the next step to derive this bounded context and domain models by starting the conversation about what is the major outcome to fulfill the user needs directly? So that’s where I start the conversation with, what objects are related to each other? Do we encounter some ambiguity in meaning? And then you start to model to have your objects that are related to each other, and then could encounter some ambiguity. For example, that you have one object that is related by others, but it has different meanings wherever you come in a different context. So then I use also techniques.

There are several techniques available to derive, to design your bounded context and domain models. And this is event storming, domain storytelling, example mapping, user story mapping, and so on. I like to start then with event storming to focus on the specific part of the system to identify what is happening in your domain by focusing on the behavior of your system. And I go along the user needs. That is usually a reflecting a user journey on your Wardley map. I then start event storming sessions around them to then derive the bounded context and the potential domain models. And then later on, reflect it also in the different event storming format, going first in big picture then into process modeling and into software design event storming sessions as well. I am then in the center of Domain-Driven Design. But I also try to design the dependencies between bounded contexts with context mapping. So what are the dependencies between the bounded contexts that we have identified? What are the context and the patterns that are available in Domain-Driven Design? And to identify if there are some bottlenecks. Do we have a tight change coupling between bounded contexts? How to eliminate this? And then to design the current scenario, but also the future scenario, where I should go or evolve to in order to remove, eliminate bottlenecks, potential bottlenecks in your system.

From there, I then apply the Team Topologies aspects trying to bring in where are the potential stream of changes that are then reflected by the user needs. What are suitable team boundaries? That could be then the bounded contexts. Bounded contexts are now forming suitable team boundaries for stream-aligned teams. And then later on, what do they need to support a steady flow of feature deliveries or steady flow of changes? So stream-aligned teams then need support from the platform teams that they, for example, take care of the components that are mostly residing in product and rental, commodity and utility, when it goes further down the infrastructure components, like data storage components, message broker, search engine components that is a part of the value chain of the Wardley map itself. So that the platform team at the end can provide X-as-a-services, platform-as-a-service to the stream-aligned teams.

So that is going from users and user needs. Starting from there, trying to identify subdomains, bounded contexts, stream of changes, suitable team boundaries, then also finding the possible team constellations. Also, having the team cognitive load in mind. So components on the further left of Wardley map, they tend to require a high tech team cognitive load because there’s no clear path to action. They are constantly changing. They’re quite complex. The components on commodity, they have more clear paths to action, so the team cognitive load could be lower there then, so that we can distribute the number and size of components according to where the component or the bounded context itself is residing in the Wardley map, either more on the left side or on the right side.

Henry Suryawirawan: So I can see how the thing flows from your business strategy, from Wardley Mapping. So if I can try to summarize based on my interpretation. So in your landscape, you have the value chain and you have the user needs and the components. You will then try to map that into the Domain-Driven Design part, which is like you have the problem space in that landscape mapping. And then you’ll try to break them into subdomains. The three subdomains in Domain-Driven Design strategic design is the core subdomain, the generic subdomain, and also the supporting subdomain. This plays nicely into the evolution stages X-axis in the landscape where you have the genesis, custom-built, and so on and so forth. The core would probably be more towards genesis and custom-built, while the generic, supporting probably is more towards product and commodity.

And then once you identify subdomains, of course, the usual in Domain-Driven Design, define your bounded contexts, ubiquitous language. As a rough idea as well, bounded context normally is a boundary of a team, which then now Team Topologies comes in. And then you have stream-aligned team, which is representing one bounded context. And then you mentioned about other Team Topologies like platform teams, enabling teams and all that. So all these actually interplays with each other really nice. Before, I only see, like, for example, okay. Domain-Driven Design is for software developer talking to the business. But there’s no strategy part of it. So this actually gives a very end-to-end thorough analysis. So thanks again for explaining this.

[00:38:49] How to Apply in Organization

Henry Suryawirawan: When you talk about this in corporate or any startups, for example, how long do you think for this exercise to finish? Because it seems pretty big and it in fact, involves major changes in the organization. Like, scrambling the team itself, explaining about domains and also business strategy. So maybe you can share a little bit more about this.

Susanne Kaiser: It’s challenging sometimes. And also, it also depends, of course, of the context itself. What I like to do is to get the training first. So to put everyone about the three perspectives. This is usually training of either three days of four hours or four days of three hours where I share with the organization the three perspectives to get everyone on the same level of understanding so that it could be one thing, or I can also just dive into directly creating a Wardley map while we are discussing something. So there are some different contexts, different approaches. In terms of like how long it takes, it’s not a maturity level or model. It’s an ongoing, evolving perspective because your landscape is constantly changing, and definitely, it would never end. So what was your core today, maybe later on go into supporting or generic. Because as one of the climatic pattern, everything evolves through the forces of supply and demand competition and also your core domain will evolve over the time. I can’t really say that goes from months to years. It’s an ongoing process, I would say. But I guess, my approach is that I facilitate this in the beginning, and then I support them that they are autonomous to go on without my interaction.

Henry Suryawirawan: I have another equally challenging question. So out of these three techniques in your view, which one is more difficult to actually convey the message to team or companies?

Susanne Kaiser: It depends to who you talk. But I guess the most challenging aspect right now, it could change, is Wardley Mapping. Because it comes with so many aspects, right? It comes from purpose, landscape, climatic patterns, doctrine, leadership. It has so much information, likely. We have so many things to learn. But I guess the good thing is that you can start small. You don’t have to know everything. When I introduce them to Wardley Mapping, I try also provide a lot of information, and sometimes it leads to information overflow. But in fact, Simon Wardley encouraged us to start with that part that you already understood and go on from there. That’s, I guess, what requires facilitation at the beginning. But also it deals with Domain-Driven Design with event storming sessions, for example. But, I guess, since this is a lightweight technique, it’s sometimes easier to address. But that’s my personal perspective. I might be wrong, totally wrong. I guess it takes a while until you understand the beauty of Wardley Mapping.

[00:41:30] How to Apply to Legacy

Henry Suryawirawan: And also when you apply this, I wish everyone could start from scratch. Everything is new, even you’re just starting a business. You don’t have any system, but I mean, in the real life, when you go to the organization, I’m sure they all have legacy. They have organization structure already. So how do you see them could easily change based on all these views that you’re giving them? Because changing teams probably is easy. Changing software, is it also that easy? Teams probably don’t have domains in the first place. Some teams built custom and using their own interpretation rather than business domains. So what would be your advice for people dealing with legacy? How can they start from all these three techniques? And then start having more adaptive architecture in their design?

Susanne Kaiser: Yeah. So I usually recommend starting with creating a landscape of the current situation to visualize it. Because you can describe it in a lot of strategic documents, describing with a lot of words, but for me personally works best to having it visualized in a Wardley map, provides a visualization of your landscape you’re operating in. I would suggest a map of your current state, of your current landscape. And from there, start asking your teams about their cognitive load. What kind of pains they are currently encountering? Do they need to have handovers? Are they dealing with functional silo teams? Or are they working with a monolithic big ball of mud with a messy model and no clear boundaries? How long does it take to onboard someone? How long does it take to make a change effective and something like that? Starting asking the team itself, what are the current problems, challenges, bottlenecks they are currently facing.

And from there, I would then take the Wardley map, and as I said, try to identify the suitable streams of changes, going through the activity oriented user needs or stream of changes. So the user need themselves, they represent activity oriented stream of changes and identifying those. From then, partitioning the problem domain into subdomains, and then it is discovering the core where you usually need to invest the most. That’s the one that you should custom-built, goes usually then in genesis and custom-built evolution stage, then decomposing your big ball of mud into the modular components, the bounded contexts, the suitable team boundaries, the stream-aligned teams, identify potential dependencies with context mappings, and to visualize or make a tight change coupling visible.

And from there, to create clear team ownership boundaries in terms of that one bounded context should be owned only by one team. However, one team can own multiple bounded contexts. Then also what is necessary to support a reliable flow of changes? Identify those services that are needed to support the stream-aligned teams, that we come to the infrastructure components on the Wardley map on more on product and rental, commodity. Where then platform teams can evolve platform-as-a-services, X-as-a-services for the stream-aligned teams, so that we identify them. Then also, at the end, identify potential efficiency gaps. So where you have to move to make your system, the system that you would like to build, more efficient. So this is the design process. We have not touched or changed any teams yet. So to know where you are, and where you want to go with Team Topologies and Domain-Driven Design applied. And then going from one to the other by implementing the evolution of team interactions between the teams, like, for example, if you identify your future platform. For example, if you decide to follow one of the cloud strategies like replatforming your current system.

The platform team can be formed first as an isolated team that we can bring in a dynamic reteaming from Heidi Helfand in her book. So to first build a platform team in isolation that is then discovering, experimenting the new technology stack. And then later on, through the evolution of Team Topologies, onboarding the potential stream-aligned teams with close collaboration at the beginning between platform teams and stream-aligned teams. Switching then later on to limited collaboration and later once the new technology stack is better established, providing X-as a services, for example. And then onboarding the platform team, the stream-aligned teams at the beginning, and then onboard the other stream-aligned teams by facilitating them, like how to use the new CI/CD pipeline and the new ecosystem that you have established through replatforming. Because then you can go into the second cloud migration strategy to refactoring where you’re splitting apart your big ball of mud into smaller parts. And that’s where we come back to the design phase of decomposing it into the bounded contexts. And how to do this with decomposition patterns? Or how to apply hexagonal architecture and to implement your serverless functions in hexagonal architecture. That’s where the first stream-aligned team can facilitate the other ones. So that at the end, you then can replatform and refactor the entire system.

Henry Suryawirawan: Thanks for giving us a quick consultation of how we can actually adapt our legacy systems. So starting from the Wardley map itself. Again, you can start small. Doesn’t have to be very thorough. And from there, you have a look into your Domain-Driven Design, maybe your situation about your monolith or maybe situation about cognitive load. I think this is also sometimes unconsciously, we just take it for granted. But once you realize this cognitive load, I think you can do something about it, right? Maybe you restructure your team or maybe you rearchitecture and whatever that is. I am sure that all this will take some time to sink in even to the audience. They will be expecting your book. So when will the book be coming, Susanne?

Susanne Kaiser: I hope for end of this year.

[00:47:04] 3 Tech Lead Wisdom

Henry Suryawirawan: So we’ll be looking forward for that. Unfortunately, we reached the end of our conversation. Before I let you go, normally I have one last question. So I would like to ask you about three technical leadership wisdom. So this is for you to probably give us advice from your learning experience. What will be the wisdom that you would want to share with us today?

Susanne Kaiser: Yeah, so one of them would be stay authentic and follow your moral compass, of course. And then also spark and foster the curiosity for learning in your team. Support a blameless culture where failures, mistakes can happen. That also applies to you as a person in leadership that you can also, of course, make mistakes and being open about it, helps to create a trustful environment.

One thing that I’ve learned is don’t feel rushed to start a leadership position. If you’re not feeling to start it, it’s not necessary from my point of view that you have to. If you like programming and you would like to stay in that role, that is totally fine. So sometimes I have the impression that everyone needs to become a person in a leadership role. But I guess, if you’re fine with programming, that’s totally fine. So that’s something that I got rushed into that too early. So that’s when I know my programming expertise at the beginning was not as high than I wanted. So I compensated afterwards. To gain technical expertise for me is also very important to have confidence. That does not mean that you need to know everything. But at least to gain confidence in your technical expertise would be helpful.

Henry Suryawirawan: Thanks for sharing your personal perspective on this. I think some people also say that you should start from the fundamentals, the basics, going through the hoops and learning about everything in probably the technology, if you can, right? And start leadership when you feel like you are ready. So thanks for sharing that message.

So, Susanne, thank you so much for sharing about all these three concepts, Wardley Mapping, Domain-Driven Design and Team Topologies. I really learn a lot. In fact, too much. So I will need some time to actually digest all these concepts. Thank you so much for sharing. Looking forward for your book. Good luck for that.

Susanne Kaiser: Thank you so much. Thank you so much for having me, Henry. It was fun and sorry about for the information overload.

Henry Suryawirawan: That’s fine.

– End –