Optimizing Organizational Flow with Wardley Mapping & Domain-Driven Design

Approach to Flow and Tools

James Lewis: Hello, and welcome to another episode of "GOTO Unscripted." My name is James Lewis. I'm here at GOTO Amsterdam with Susanne Kaiser. We're probably gonna talk today a little bit about a joint interest, which is the idea of flow. So maybe, Susanne, you can introduce yourself and what you've been talking about here.

Susanne Kaiser: Yeah, thank you so much for having me. It's really lovely. I am Susanne Kaiser. I am an independent tech consultant, and I am trying to help organizations of different sizes to unlock their blockers to flow and try to support them to design, build, implementing adaptive socio-technical systems that are optimized for a fast flow of value, a fast flow of change, and constant feedback, and bringing different toolsets.

So I remember from your talk, for example, that one of our expectations is that we have a suitcase of tools and bring them. And so I also come with my tiny suitcase of tools as well with my toolset to bring them in and turn to, depending on the context of the client, what makes most sense to apply there and to analyze the current situation and where their blockers to flow are and what could be then the vision for the future target architecture from different perspectives.

James Lewis: So the North Star, I guess, to aim towards.

Susanne Kaiser: Yeah, it is. It's more like a North Star in terms of, like... It's also about something that you can approach in increments and iteratively. So it's not like that we sit there in our ivory tower and decide where to go, and not me because I usually work with the teams together because otherwise, it's not very helpful because I'm not implementing them together with them to just like, yeah, designing the future architecture.

James Lewis: It's not sitting in a room and sort of drawing the pictures. It's being with people who are actually doing the work then, basically.

Susanne Kaiser: Exactly. So that is my main way of working together was the teams and also to identify and analyze their blockers to flow. What are the pain points, starting from where the teams are right now and what is blocking them delivering value to the customers and also what are the pain points, what are the challenges, and also what works well? So what would we like to keep as well? And bringing in different perspectives.

Recommended talk: Software Architectures, Team Topologies & Complexity Science • James Lewis • GOTO 2023

Combining Methodologies: Wardley Mapping, Team Topologies, and Domain-Driven Design

James Lewis: So you mentioned bringing a toolbox or toolkit, and obviously I've seen your talk this week also previously and it's brilliant. You have to go and watch it when it's published. There's a lot of really interesting tools in that toolkit, right? So I guess counting, there's Wardley mapping, there's Team Topologies, there's domain-driven design. Where did you get the idea to bring all these things together originally?

Susanne Kaiser: That evolved organically over the time. So first of all, I used to be a startup CTO. Like, there was a journey from models to microservices, so that's where domain-driven design came in back then. So I remember when I gave my first talk and you, James, were sitting in the front row. So I really got inspired by your articles about microservices and also Sam Newman was sitting there. So yeah, that's the moment where I was diving more into domain-driven design to find potential domain logic-specific boundaries to split your system apart.

And then when I was more into the field of microservice and domain-driven design, and then serverless came along and I was also interested in, okay, how does this technology work? I was attending serverless technology conferences. And at every serverless conference, Simon Wardley was giving a talk. So that was by coincidence. So it was just like... And then I was listening to his keynote and it was really entertaining and I was thinking, "Oh, that sounds amazing, but how can I apply it to my own context?"

The first thing was that I tried to combine a Wardley map with domain-driven design to have added... So I modified a little bit of the Wardley map back then. So I added a separate layer, like, from bringing domain-driven design together with Wardley maps because the user, usually when you create this Wardley map, the value chain on the y-axis with user and user needs, describes beautifully the problem domain from domain-driven design.

Then when you go then to the components that fulfill the user needs directly or indirectly when you have this chain of components on your value chain, that then comes in where the solution space comes in where you can then apply a bounded context and so on on the problem space. You can then combine, bring in subdomain times of the core domain, what provides competitive advantage, why is the supporting sub-domain and the generic sub-domains on the problem space.

Then on the evolution space, it's like, okay, where to build versus buy or outsource decisions and combine them. So that was the first combination, like, combining Wardley mapping with domain-driven design. And the next one was when the book came out, "Team Topologies" end of 2019, I was like, "Oh, that is the missing piece." Because of Conway's law, we have to deal also with the socio-technical system with also the team organization. And that was then the missing piece where I then was bringing in also, yeah, the team organization as well.

James Lewis: I have to say that... So I've read "Team Topologies," I've read obviously a lot of stuff around domain-driven design over the years. I've been practicing it for many years. And then obviously, Wardley mapping has become quite a thing in the industry. I know certainly in ThoughtWorks, we use it a lot as part of our engagements now, our more strategic engagements certainly. I think the first time when I saw your talk, I think it was the first time I actually was able to line up some of these concepts in my head. So I should thank you for that, yeah, absolutely. So for example, you talk about value streams along teams in "Team Topologies," and there's a tendency of like, "Well, is that..." because I think about value streams, but then actually you explore those ideas, don't you?

Susanne Kaiser: Yes, and you can also compliment because you talked in your talk about value stream mapping. So in a Wardley map, we talk about value chain, like what is necessary to fulfill user needs, what components connect in order to generate value for the customers, but you can also beautifully compliment it with value stream mapping as well, where you go more into the process view, for like maybe every component in the value chain can have its own value stream. And you have to bring in both perspectives in order to identify constraints, so where do we have a lot of, like, wait time? Like, you talked in your talk about waiting times, like, different types of waiting, like coordination, scheduling.

James Lewis: Synchronization.

Susanne Kaiser: Synchronization.

James Lewis: Was it... No, queuing. That's it. 

Susanne Kaiser: Queuing, exactly.

James Lewis: Coordination, scheduling, and queuing, yeah.

Susanne Kaiser: And that makes total sense, and it's us who have to bring this to have a more dense picture, which can then block our, yeah, flow of change and value.

Recommended talk: Adaptive Socio-Technical Systems with Architecture for Flow • Susanne Kaiser • GOTO 2024

Challenges in Implementing Domain-Driven Design

James Lewis: For me, I mean, maybe looking back a bit to the ivory tower thing, I think that's where a lot of people go, a lot of organizations go wrong when applying some of these ideas. But then also with things like domain-driven design, it can be quite hard to know where to start, like to tend to try and you get into this, I certainly have fallen into this sort of analysis paralysis. Is this correct? Is this precise? Have I got the right domain boundaries? How do you sort of deal with that kind of thing in your workshops?

Susanne Kaiser: Definitely, that is one of the biggest challenges to see. I guess on the one side it's crucial to find the right boundaries, and on the other side, like, how to validate it, like how is this really like? And so it's kind of like an iterative process, and it goes along the...so that we also gain feedback, for example, where do we... So, for example, when we try to find the right boundaries to the so-called bounded context when forming a boundary around domain models. And yeah, I do this also together with, for example, my clients' teams together, because I am absolutely the domain noob in the room, so I have no clue about their domain. So I have to...I try to drive this conversation about a lot of the questions. And I guess I try to, like...

James Lewis: But does that help, though, right, often, being the noob?

Susanne Kaiser: Exactly.

James Lewis: Because you get to ask the stupid questions.

Susanne Kaiser: That is so deliberating because I can ask so many stupid questions. Maybe other people have the same question but didn't dare to ask them because they were already working there for a couple of years and they're supposed to know it or think that they're supposed to know, and, in fact, it's still... So asking. It's really, really, really relieving to be the noob in the room. But what we try to do then, to picture then, like, when we have these boundaries, how we try to make a kind of scenario plan, how a change would flow through the system. But this means that these are changes we know, like, that we are...the known knowns that we're dealing with.

And then we try to, like, okay, when we make...coming from the user needs, like, when we have a change, maybe a customer is requesting a change, how would this change flow through the system? Like, what bounded context might be affected? And also, what is the integration, the relationship between the bounded context versus context map patterns, and what teams are owning these bounded contexts? Do they have to interact and coordinate in order to make this change effective?

Can you apply some heuristics, like, to drive this bounded context? But you're not sure at the end. So it's always constantly validating, I would say. How do you do this? How do you usually validate...

James Lewis: I think it's the same. I mean, well, I don't have the methodology. I haven't previously used the methodology that you're talking about. I mean, we tend to talk about tracer bullets, maybe it's a bit...maybe the metaphor isn't great, but the idea of asking questions of the domain and working out, again, which parts of the domain would be affected. I mean, it's the classic thing around tiered architectures.

In the old school, when you had, like, a web tier, then you had data services, then you had a database, and you'd ask the question, which part of it changes when you have to add a new feature or you need to add a new field to a form or something, and the answer is all of it. Like, you'd have to change everything and deploy everything, and suddenly it becomes a bit more obvious when you're using these sorts of techniques.

Susanne Kaiser: Absolutely.

James Lewis: Have you seen Barry O'Reilly's work on residuality in recent...

Susanne Kaiser: No, unfortunately not yet. So I would love to. I'm going to plan to look at his talks. I guess he also gave talks at DDD Europe, and I would love to watch those. Yeah.

James Lewis: Because he's got this really interesting idea of stressors. He's talking specifically about software architecture, which I guess we are as well, but he talks about how the architecture or the system that you have at the moment is the result of everything that's happened in the past, I guess is obvious. So with that sort of thinking, and the stressors that were applied in the past, the stressors the system was put under, and the code bases were put under, can you use the same idea in the future? So when you talk about these, I call them traceability, you talked about, what was it, the future changes?

Susanne Kaiser: Yes, flow of changes.

James Lewis: Thinking about the different types of stressors, the unknown unknowns, and coming up with a set of these unknown unknowns, and then applying it to Wardley maps.

Susanne Kaiser: That is a great technique. This seems to be very interesting to see, specifically when you...like stressors in forms, what could happen, and you're not aware of, and to see how your system would react to that. That's how I understood it, to apply some stress patterns or something like that, and to see where your system would respond to, or where might we apply some changes, and does this part of the system need some change? And that part, at the same time, maybe that's an indication they belong together, and maybe they have to revalidate or reiterate on our bounded context and, yeah, to bring them together, for example. 

Insights on Organizational Dynamics and Ownership

James Lewis: One thing I'm kind of fascinated by as well because I spend a lot of time doing this sort of work with teams as well, one of the things I often find and get feedback afterwards on is when you get disparate people together, and you get a lot of people from different parts of the organization together all talking together for the first time, and that seems like a super energizing thing, and you almost get... I've seen teams almost get as much out of just being able to talk to their colleagues that they didn't know new stuff. Do you know what I mean?

Susanne Kaiser: So really the conversation that sparked from bringing different domains together or different roles or departments together, and then they come up with, or revealing some situations like, "Oh, we have never known that you do this manually. Ah, we could have supported you in your daily work by..." And it's just like we can just add it to our code and it could generate something, yeah, and maybe just integrating another system that they're manually using, they are copying, for example, one part of the software into another part of the software manually. And when we bring them together, it's like, "Damn it, we haven't known it because we have never talked to each other before." Like, this was a problem and they just accepted it. And so it was like, "Yeah, okay, we have to do it manually. Okay, we'd copy it." No. It's just, like, really revealing sometimes.

James Lewis: I mean, that sort of almost shadow IT stuff that you find as well, right, where it's like, "Oh, no, we do that in Excel." Why are you doing that in Excel? This thing does it." "Oh, no, we've always done it in Excel."

Susanne Kaiser: Exactly.

James Lewis: Then the other thing I think with domain-driven design, in particular, we talk a lot about ubiquitous language in domain-driven design and the importance of having the ubiquitous language. Another thing I've noticed is that often different parts of the organization, different domains.

Susanne Kaiser: Absolutely.

James Lewis: It becomes really clear that they've got these different languages, right?

Susanne Kaiser: The thing is, I talked to an attendee at this GOTO today about, for example, use, like, customer. Whenever you talk to different departments, it has different meanings, but across the context, across departments...it has different meanings across the departments, but within that department is a clear meaning. So they look at you confused, like, no, for us, customers this and this. But if you talk to another department, customers have totally different meanings. For example, invoicing has a different meaning than, I mean, if you are elite or in the e-commerce system. So it has a different meaning, different attributes, different business logic behind it.

And so I guess that's also the source of so much confusion, right? And we can't have one god object of customer because then this is like this goes into the system and it introduces then tight change coupling or tight coupling if you have... For example, at another client, I had an account object with 400 different fields.

James Lewis: Wow, that was a big construct.

Recommended talk: Structures Shape Results: Software Insights • Elisabeth Hendrickson & Charles Humble • GOTO 2024

Susanne Kaiser: It was kind of, like, really large. And who introduced that field? So when we changed that one, what side effect did it have then? So I don't know if you changed the name or even worse than, yeah, the type of it then. You just change it, and maybe it's just something like others. It's exploding because you had one huge, massive god object. And so that's the reason, that ubiquitous language in terms of, like, that has a different meaning there and it might be a totally different domain model there. So it's really important.

James Lewis: I remember being on one account we just started. We found this god object in the codebase and it was a transaction handler, I think it was called transaction handler because, of course, maybe even transaction handler factory input or something, you know, and it just had a do transaction method on it, and that took 48 parameters, which was nice, in an array. So it wasn't even typed. You had to infer.

Susanne Kaiser: Oh, damn it.

James Lewis: I have no idea how they ever changed it ever, you know.

Susanne Kaiser: And this cognitive load, right, this mental effort to understand this piece of code, and, like, specifically when onboarding new people, and when you make a change there, and then, oh, gosh, it's...

James Lewis: It's pretty awful. I mean, you mentioned microservices, it's interesting because we both go back a long way in that. I mean, it's 10 years this year since Martin and I published that, and we started talking very shortly afterwards, and I know, you know, talk about god objects and things. One of the things I had at the start was no shared domain code, because if you start sharing domain code in libraries...

Susanne Kaiser: Exactly. I guess Sam Newman also mentioned this, and maybe it also stems from you, like, the don't repeat yourself principle doesn't apply to microservices, because if you try to share everything, specifically when it's, like, domain code or domain logic, which changes frequently, that is then...yeah, you introduce coupling, and yeah, a distributed monolith again, and it's even worse than your monolith. So I don't want to call a monolith bad, so sorry if it's... It's like…

James Lewis: You hear it here, monoliths are fine, modular monoliths are fine.

Susanne Kaiser: Exactly.

James Lewis: Simon Brown is around. He'll storm through the door and shout at us if we don't make that clear.

Susanne Kaiser: Exactly. Absolutely.

Recommended talk: When To Use Microservices (And When Not To!) • Sam Newman & Martin Fowler • GOTO 2020

Conclusion and Reflections

James Lewis: So back to I guess the Wardley mapping, back to architecture for flow, team topologies, and things. What sort of changes have you seen organizations go through when you've been applying these sorts of techniques?

Susanne Kaiser: So I guess more like a clear ownership boundaries and also, like, that they have then freeing energy to focus on their core domains or all the core activities of the teams themselves so that they get a clearer picture and reduce team cognitive load and have also energy and time to think new ideas through. So that is something relieving for the teams that I've seen so far. And also, like, that they have this clear purpose, and also, even though they have not split it yet, but for example, just visualizing the status quo.

For example, I had one client, we do so many things but we can't really express it and we have then identified that these were mostly platform teams, but they were also enablers, so they are also facilitating, which takes a long time to upskill other teams. It is a different interaction mode when you are coaching others than providing access services. And they had different interaction modes and just only to make this clear, explicit that, yes, of course, you have your spending. It's not boiled down into user stories because there are some activities that you do on the side, right? And to make it explicit, and then they brought this one seat, that's the reason why we stuck sometimes, and either, like, yeah, we have a dedicated team at some point or we change something.

So it gets more...increased clarity of purpose, then the increased clarity of ownership, and also when to collaborate together when exploring and also when to provide access services or, like, how to interact with other teams. So that was very, like, more kind of freeing some energy and focus. And yeah, that's what I could say so far.

James Lewis: Well, so everything, more clarity is always gonna be good, right? I think that's...I mean, that's fantastic. And do you see the teams then? Because one of the things I'm quite passionate about is, I mean, I've said it before, but we turn up with these toolboxes as you sort of alluded to and often as consultants or as independents, we get hired because of the toolboxes. But I feel it's incumbent on us to leave those tools behind in a way, right, and actually ensure that the organizations we're working with actually can use those in an ongoing way. Have you got experience to teach other people? Do you coach the teams to do this themselves as well?

Susanne Kaiser: It's sometimes a combination of training and then working together with this tool together. I guess it's to bring in the fundamentals, so also the why, why we are using it, the purpose of those tools. And sometimes it's that I don't say we have to always use those, maybe we can complement others. So it's not like...

James Lewis: Things like brainstorming and lots of other…

Susanne Kaiser: Exactly, so it's not a rigid framework.

James Lewis: No.

Susanne Kaiser: Sometimes I tell them, like, the purpose behind it and the fundamentals and the concepts. And then we also involve them in their workshops. Sometimes the workshop starts with the fundamentals, sometimes not, it depends on the context itself. And then afterwards, they then can... So I hope that they... So my role is then to enable them to use those tools so that they can explore their own domains because we start with only a few domains and then that they can go on their own and apply those.

James Lewis: I remember being at a client where we use that sort of technique where you sort of use a bit of theory and then you use a toy. Liz Keogh, who, well, she's a former colleague and she's awesome, was behind JBehave originally, one of the people that really took behavior-driven development forward. But she talked about this idea of breakable toys and how you can use sort of experiments or you can use simplified versions in order to teach people how to do stuff. And we did that with value stream mapping.

So you kind of explain what a value stream map is and people go, "Okay, fine." And then you sort of explain the different types of waiting and wait times and these sorts of things. And then you say, "Okay, well, imagine you're at home and you've just closed the door and you're on your way to work. Create the value stream of getting to work as a group," or whatever. And using those sort of really simple examples, it really lands with a lot of people. And I've had a good experience, especially when there's lots of people to train, doing the simple things. And then that seems to get quite good results. So yeah, it's cool.

Susanne Kaiser: Also bridging the gap from the general or generic example to apply it to their own context. I guess then it clicks like, "Okay, now I've understood the concepts, but now I can apply it to my own context," and it's then more tangible when we then dive into their domain. And...

James Lewis: What do you think about the future of this? I know you've got a book on the way.

Susanne Kaiser: Yes. Sorry, it took so long. Yeah, it's...

James Lewis: I'm just annoyed because I can't wait to read it.

Susanne Kaiser: I'm sorry. You'll get an extra version. You'll get an extra version. So we will drink some beverages later on. So yeah, I hope that it's usable for other organizations as well. And I also would love to see how you apply it in your context. And maybe you say, like, every... Also learning from feedback of the readers in terms of, like, if this is applicable to their context and they have applied it, or maybe what obstacle they had to apply it. And also, like, what was valuable to have on both sides and to see it as a continuously improving method to...yeah, a toolset that helps you, as I said, to design and build and evolve adaptive social-technical systems. And it also adapts. That's what I see. It's also an adaptive system as well. So that's what I see for the future.

James Lewis: I think what's brilliant about this work you've been doing is you've taken three things that sort of I think almost become canonical ways of looking at certain parts of our world in the work we do in big organizations building big software systems. And you've managed to combine these three canonical things to create something that's actually bigger than all of them I think. So for me, thank you, because there's a lot of techniques that I'm gonna borrow, steal in the future for my work. And I suggest you all take a look at Susanne Kaiser's talks and buy a book when it's out. So I think on that note, I'll say thank you very much, Susanne Kaiser, for coming into "GOTO Unscripted." And I've been James Lewis, and goodbye for now, bye-bye.

Susanne Kaiser: Thank you, and goodbye.