Susanne Kaiser on DDD, Wardley Mapping, & Team Topologies

Welcome and Introduction [00:04]

Wes Reisz: Domain-Driven Design is an approach to modeling software focused on a domain, or a logical area that defines a problem that you're trying to solve. Originally popularized in the early 2000s by Eric Evans, DDD's focus on making software a reflection of the domain it works with has found a resurgence in the isolation and decoupled nature, or at least the promise of it, with microservices. Wardley Maps is a strategic way of visualizing a value chain or business capabilities in the grid characterized by a spectrum towards commodity on one axis, and most commonly something like visibility on another axis. It helps you understand and makes important strategic decisions such as like a build versus buy decision. Finally, team topologies is an approach to organizing business and technology teams for fast flow. It's a practical kind of step-by-step adaptive model for organizational team design interaction.

When combined, Domain-Driven Design, Wardley Maps, and team topologies provides a powerful suite of tools to help you think about modern software architecture. My name is Wes Reisz, I'm a principal technologist with Thoughtworks and co-host of The InfoQ podcast. Additionally, I chair the QCon San Francisco Software Conference happening in October, and November this year. Today on the InfoQ podcast, we're talking to Susanne Kaiser. Susanne is an independent tech consultant, software architect, and an ex-startup CTO who has recently been connecting the dots between Domain-Driven Design, Wardley Maps, and team topologies. She recently gave a fantastic talk at QCon London diving into the intersection of the three. So on today's show, we like to continue the conversation talking about Domain-Driven Design, Wardley Maps, and team topologies. We'll first tap the recap three, and then we'll dive into some of the success stories and some of the understanding that Susanne has when she's talking to the folks about the consulting work. As always, thank you for joining us on your jogs, walks and commute. Susanne, thank you for joining us on the podcast.

Susanne Kaiser: Thank you so much for having me, I'm looking forward to it.

Wes Reisz: Okay. We talked about Domain-Driven Design, Wardley Maps, and team topology in the introduction, at least I did like a high level overview. Anything you want to add to the overview that I kind of gave?

Susanne Kaiser: No, it was a great overview. So I like to hear, to listen to stories that other bring into the table because whenever I make the introduction that it's like, oh yeah, it's so either going too far into details. And then the podcast host, they then tend to bring very great summaries, so nothing to add. Great introduction.

What made you bring together Team Topologies, Domain-Driven Design, and Wardley Map? [02:30]

Wes Reisz: Great. There's so many things that are in software. What made you decide to bring these three things together to kind of a story?

Susanne Kaiser: Yes. So for me, the combination of Wardley Mapping, Domain-Driven Design and team topologies evolved naturally over time, but it was at its core driven by system thinking. So, Dr. Russell Ackoff, one of the pioneers of the system thinking movement, he stated that a system is more than the sum of its parts. It's a product of their interaction. So the way parts fit together, that determines the performance of system, not on how they perform taken separately. So, and when we are building systems in general, we are faced with the challenges of building the right thing and building the thing right. Right? And building the right thing addresses effectiveness, and addresses questions such as how aligned is our solution to the users and business needs. Are we creating value for our customers? Have we understood the problem and do we share a common understanding and building the thing right?

Focuses on efficiencies, for example, efficiency of engineering practices, and it's not only crucial to generate value, but also being able to deliver that value. How fast can we deliver changes, and how fast and easy can we make a change effective and adapt to new circumstances. So, the one doesn't go without the other, but as Dr. Russell Ackoff pointed out doing the wrong thing right is not nearly as good as doing the right thing wrong. So, by considering the whole, and having effectiveness and efficiency in mind to build the right thing right, that we need a kind of like holistic perspective to build adaptive systems. One approach out of many is combining these three perspectives of business strategy with Wardley Mapping, software architecture, and design was Domain-Driven Design, and team organization was team topologies. So, in order to build and design and evolve adaptive socio-technical systems that are optimized for fast flow of change.

Wes Reisz: Yes, absolutely. That really resonates with me, building the right thing and then building the thing right. Those two phrases really resonate with me, a trade-off and understanding what you're doing and how you're thinking about these problems. So, where do you start? You have these three things and you start with domain-driven design? Where do you start when you kind of apply these three techniques?

Susanne Kaiser: So, it depends on your context. You can start each of the perspectives. What I like to start with is first analyzing the team situation, regards to their team cognitive load and their delivery bottlenecks that they're currently facing. So, what of kind of problems do they have right now? Are they are dealing with high team cognitive load because they have to deal with a big ball of mud when you deal with a legacy system which evolved over the time? Are there organized as functional silo teams where handover is involved? Are these large teams or do the teams need to communicate and coordinate with each other when they want to implement and deliver changes? So, this are kind of questions that I like to address first, like analyzing the current situation of your teams. And then the next step is-

How do you talk to teams about cognitive load? [05:32]

Wes Reisz: Let me ask a question before you go there. Let's talk about cognitive load for a second. How do you get people to understand the cognitive load that they're under? A lot of teams have been operating in a certain way for so long, they don't even realize that their cognitive load is so high that they don't know of any other way. They don't know how to adapt to that. How do you have that conversation and get people to understand that the cognitive load that they're seeing is actually a detriment to flow?

Susanne Kaiser: So, there is different aspect that I like to bring into the conversation, for example. So how much time does it need for them to understand a piece of code? How long does it take to onboard new team members? How long does it take to make a change effective and to implement changes and kind of also comes to software quality in teams and in terms of like testing as well. Are there side effects involved that they could not be easily anticipated, and then also bring it back to a Wardley Map itself. So, what kind of components they are responsible for, and if we have our Wardley Map with the value chain matched to the Y axis, and if you use this, your user needs and components that fulfill the user needs directly or facilitating other components in the value chain. And then the evolutions axis going from left to right from Genesis, custom build, product and rental, and commodity.

And the more you are on the spectrum of a left spectrum of your Wardley Map, then you are dealing with high uncertainty, then also unclear path to action. And the components that are located on the right spectrum of your Wardley Map, there you are dealing with mature stable components where you have a more clear path to action. And if your teams are responsible for components that are located on the left spectrum of your Wardley Map, then there's a potential high cognitive load involved because you need to experiment more, explore more, discover more and applying then merchant and novel practices instead of best and a good practices on the right part.

Wes Reisz: Yes, that really resonated for me in particular, being able to visualize the value chain onto a Wardley Map, and then be able to say things on the left, things that are more towards Genesis require more cognitive load to keep in your mind. Things that are more towards that commodity side, right side, are definitely less. That really resonated to me when you said that. So, I interrupted you, you said step two. Okay. So, that's step one, applying some things out. What about step two?

Susanne Kaiser: It doesn't need to necessarily be step two, but one of the steps could be creating a Wardley Map of your current situation and to look at what is your current landscape you are operating in, what are your users, what are the users' needs? What are the components of fulfill this user needs? And then also to identify the streams of changes in order to optimize for fast flow change, that requires to know where the most important changes in your system are occurring. The streams of changes, and there could be different types of stream of changes. And with the Wardley Map, this visualized activity oriented streams of changes reflected or represented by the user needs. So, if we look at the user needs, these are then the potential stream of changes that we need to focus on when we want to optimize for fast flow of change.

So, that is then first identifying then the stream force changes, the user needs, could be then the next step and using this Wardley Map as a foundation for future discussions, how to evolve then our system. And then we can also go from there to address the problem domain next. And that's where we are then landing in Domain-Driven Design, and the users and the user needs of a Wardley Map, they are usually representing the anchor of your map, but also constitute the problem domain in regards to Domain-Driven Design. You can then analyze your problem domain and try to distill your problem domain into smaller parts, the sub domains. Different sub domains have different value to the business, so some are more important to the business than others. So, we have different types of sub domains, such as core, supporting and generic. And we can try to identify what are the sub domains that are core, which provides competitive advantage, which tend to change often, which tend to be quite complex and where we should focus on building these parts of our system in-house, because that's the one that we would like to differentiate ourselves.

So, that requires the most strategic investment so this gives us combined on a Wardley Map, the co-domain related aspects then are then located in Genesis or custom build and needs to be built in-house. Then, supporting a generic that's then where go to the right spectrum of the Wardley Map, either buying off the shelf product or using open source software for supporting, for example, and then generic, that is something where we can also use go some product and rental, or then commodity and utility where we have can then outsource to, for example, cloud housing services.

Can you give me some examples of bringing these together? [10:17]

Wes Reisz: You've used some examples as we've talked, let's try to put this into a journey, like a little example that kind of walks through it. Then as we go through it, I want to ask some questions, things that are about team size, particularly smaller team sizes. When you have a lot of people and large engineering teams, like QCon London had a talk on my track with Twitter that just in the GraphQL API side, they have an enabling team that has 25 engineers just to support the GraphQL side. So, they have a huge team just in one particular area of their API surface, but in smaller organizations, you may not have that kind of depth of talent to be able to pull from. So, as we kind of walk through this, I want to ask kind of drawing on some of that experience you had as a CTO startup, how do you deal with different sizes when you don't necessarily have huge teams to be able to handle different areas within the platform? So, you used an example I think in your talk, you want to use that as an example? Let's try to apply this to something. Does an example come to mind?

Susanne Kaiser: In my talk, I was addressing a fictitious example of an online school for uni students, which was at that state, a monolithic big ball of mud, which was run and supported by functional silo teams and running on top of on-premises infrastructure components.

Wes Reisz: Okay. So do you just take this big ball of mud and put it right in the middle of a Wardley Map? How do you start to tease apart those big ball of mud?

Susanne Kaise:  I start to map the current state of the online school. This monolithic big ball of mud is, for example, so I start with what users needs first, right? So, the users could be the teachers and the uni students with their user needs of creating course content, or evaluating student progress. Or these students would like to study courses and requesting or receiving help, and also receiving evaluation feedback.

Wes Reisz: So a full slice, but basically a full slice of what the user's trying to accomplish.

Susanne Kaiser: Exactly, what needs do they have and what is necessary to fulfill this user need? And then I can start with what is necessary to fulfill the user need directly. So, that is at the top of the value chain of the Y axis of our Wardley Map. And when I reflect, when I derive the value chain of the current state, where we have a monolith right now, I start with one component, even knowing that it's too large, because that's something that we would like to decompose later on. But at first I would like to bring this big ball of mud as one component, and then bringing in, then the second aspect of Domain-Driven Design, where we split it, decompose it into modular components where we then solution space of strategic design and where we decompose it into modular components within the bounded context.

When it comes to Wardley Maps, how do you think about sizing of the things on the value chain? [12:50]

Wes Reisz: That was my first question, is about sizing. Like, how do you pick the right size? I mean, when you put this big bottle of mud in there, it's going to be too big, right? So you put that big ball of mud in there, and then you move into kind of the domains and start to break out the bounded context between that big ball of mud. So, that way you can focus on each individual pieces within it?

Susanne Kaiser: The Wardley Map, this is kind of like a continuous improvement, right? So, you have a continuous conversation about it. So is the Wardley Map that they once created will change over the time. So, you can also say, okay, we know that this is a big ball of modern, too large component. You can define it as your scope. Usually when you create a Wardley Map, you also define the scope of your Wardley Map. What is included, what is excluded for example. And you can also say at this point, we are putting in the monolith as one component, we are going to decompose it in a different Wardley Map, or we just replace it. So, if there's one heuristic is if one component is too large to be handled by a small cross-functional team, that is an indicator that your component is too large. So, if we have this monolithic online school component as one component, it's an indicator that it's too large.

So we need to address it then coming to after we know what is our problem domain, what kind of problems we would like to solve, the user needs, we need to then identify where we do high level design decisions and moving to the solution space of strategic design and decompose our big ball of mud into modular components. There we can blend in other techniques from Domain-Driven Design, such as event storming, domain storytelling, user story, mapping, example mapping, and so on to have a conversation about what is behavior that shall sit together? Where we have a boundary around a domain model, the domain model reflecting business rules of a specific area of your system, and where bounded context forms a boundary and could also be then later on be suitable team boundaries. When we come to team topologies, where we blend in the next perspective, making team decisions then.

Wes Reisz: How does it change when maybe you're just focused on an API, building an API and you don't have control of say the front end or something along those lines? Does it change? Do you think about it any different when there's this team abstraction that handles the UI, and then you're kind of only working at the API surface and below. How do you think about that kind of problem?

Susanne Kaiser: In an ideal situation, there's end-to-end responsibility for the streamline teams, including the user interface, including the front end, because what we would like to avoid is handover. And when we have front-end teams and back-end teams, it's definitely a handover involved when we want to make a change effective, that is then distributed to the client that the client can use through the user interface. So, team topologies aims to establish cross-functional teams and that means also that the streamline teams, they need to have at least that much of skills for creating user interface and also having user experience, UX focus as well, involved. That could get support by enabling teams helping them.

For example, they could provide a style guide that can help the streamline teams to not to reinvent the UI wheel every time they introduce a new dialogue and there it is interface. So, there are some standards that enabling teams can provide for example, and help them also to acquire missing capabilities in that regard. But they only there not permanently be available, but instead every other team type from team topologies tried to make the streamline team self-sufficient so that they can focus on their steady flow of future deliveries, flow of changes, autonomously, and then request some help in specific circumstances.

Wes Reisz: Team topologies talks about four different types of team structures that are created. There is a streamline team, which is the main way that work is done. And as you said, it's cross-functional, it has all these different pieces to it. There's a platform team, there's enabling team, and then there's a complicated sub-process team. So how do, say, like a platform to you, like particularly in a case of a smaller company, I keep coming back to the smaller size because when you've got lots of people, you've got lots of different ways that you can create this. But in a smaller organization, how do you leverage the streamlined teams with platform teams, for example, to be able to get started? Like, you mentioned some of the best practices and things that you can start with. Can you talk a little bit about kind of that interaction and how some of these tools help you get started with this?

Susanne Kaiser: So first of all, if you have a really small organization, you can still apply it, but you don't have to have a dedicated platform team from the very first beginning because maybe you only have two streamline teams, right? But you can establish a temporary task force that can provide a sentence viable platform. That's how Matthew Skelton and Manuel Pais describe in their team topology book, where you provide first this kind of platform that is big enough to fulfill the consumer's need and not become bigger than needed. And it could start with documentation like how to provision your infrastructure in cloud ecosystem or how to use the serverless framework, or how to use this and that. And with documentation, it can then also describe also standards and best practices. Later on, it can evolve into a digital platform with self-service services, and APIs, and tools that the streamline team can then easily consume. But it does not necessarily have to be full-blown digital platform from the very beginning, but just as big enough as it's necessary to fulfill the needs of the consumers.

How do you walk the line between standards and standardization? [18:16]

Wes Reisz: As you mentioned there, when you start off in that journey with platform teams, how do you walk the line between standard and standardization? Like you want to have high standards, but as I think you said before, you don't want a standardization to become like a bottleneck. How do you walk the line between those two things?

Susanne Kaiser: At the moment when you make something mandatory to use, right, that is then where it becomes potentially a bottleneck. So, it's always like addresses. Does we introduce bottlenecks in our journey because we would like to enable the streamline teams that they are able to focus on fast flow of changes, that they are able to produce a steady flow of feature deliveries. So, if there is a moment where we are blocking them and for example, where we say, no, you are only allowed to use this technologies or that technologies. This is an indication that we might then introduce the next bottleneck that we try to avoid from the very first beginning. For example, one possibility is also when we look at establishing cloud centers of excellence, where we empower teams to innovate on cloud host of infrastructure, we don't want to block innovation by saying you're only allowed to use this technologies.

Instead, we would like to spark that these streamline teams can also learn, that we don't want to hold them back. And I guess the moment where we are not enabling them and supporting them, instead of telling them what to use, it's a challenge that we address. On the other hand, it's also like we already had this conversation when we had this DevOps movement, right? Where we have stability on the one side where the operation teams were focusing on and want to keep your production system stable and want to have as minimum, least changes to the system. But the development teams back then wanted to deliver a lot of changes. And so there was a kind of contradiction in between them and also kind of like different forces involved. I guess we have to look at what enables the fast flow of change. I guess that's the most important focus that they both need to have in mind.

How do you get started with a process like this? [20:12]

Wes Reisz: I want to ask a question that often comes up when I've had conversations about this. And it's about like getting started. When a company, like you talked about, you can start off by talking to the team, you can find out what their friction points are. You talked about them maybe using Wardley Maps and then Domain-Driven Design and some of the concepts and things, the techniques within Domain-Driven Design to be able to dive deeper, like you've been storming. So, it's kind of like a way that you could use these concepts together to be able to be get started, but let's dive into a specific team on how you get started. If there's a company that sees this and they know that they can rearchitect this big ball of mud using these strategies that you've talked about, and use the Inverse Conway Maneuver to be able to enable fast flow of change and all these wonderful things that you talked about.

But how do you get started? Do you just like come in Monday morning and say, "All right, we're breaking up into three teams. We've got a platform team, we've got two enabling teams and go." I mean, do you start with one team, one uber team knowing full well it's the team that's going to live, but not the people on the team? How do you talk to people about day one, and day two, and then day three, when it comes to these strategies?

Susanne Kaiser: First of all, make it transparent, make the change transparent and communicated along the organization. Because I guess the most fear that people have is about change, that they get laid off. So whenever there's a reorganization in place, because if we are transforming to a team of topologies team types and their interaction modes, there will be reteaming involved. And first of all, I like to make it transparent through the entire organization, what are the team types? What is the interaction mode? When does it make sense that teams are collaborating? When does it make sense to provide excessive service? That is very essential for a transformation? Also there, I would like also to bring in Heidi Helfand's brilliant book about dynamic reteaming.

She also brings in that you can start with forming one team first on site, for example, by isolating one team, for example. That you can start, for example, with a platform team first where you form first your platform team on a site from members of the back end and the infrastructure team, and then put them on site to discover and assess infrastructure options. For example, if you'd plan to, instead of running the system on premises infrastructure, you would like to migrate to the cloud and have this isolated platform team. As a first team working on the site, they don't have to follow the processes. They are there to discover and explore new cloud strategies for example, and cloud options that are available and they're suitable for their first bounded context that they would like to extract.

It can then form next the first streamline teams, collaborating closely together with the platform teams that has been built from first and assessing potential cloud options for the bounded context that the streamline teams is responsible for. And who will be member of which teams is also another question, right? So, Heidi Helfand described a different levels, who decides who will be member of what team. It could be from the top down, from management. It could also be self-selecting process as well, where you let your members of your current teams decide in what teams they would like to become member of. And so there are different levels involve, and also that you can also calibrate when you form a team, when you reteam, you need to also to calibrate your team. So, you can calibrate on different aspects like how you would like to work together, what you like to do, peer programming or more programming.

And what is your mission of your team that you introduce new team members, that they can onboard very easily? And so they have different team calibration sessions that help you to bring the journey forward towards team topologies, team types. But also for example, if you focus on account migration strategy as well, so there are different aspects there where you can gradually transform your existing team incrementally and transform them into team topologies, team type. Also, with the highest level of self-selection then, letting the team members select themselves. That could also be a suggestion, or like that the team members say, "I would like to be into that team." Then the management can decide in getting this input from the teams and they decide, so there are different levels applicable for forming these teams.

How do you leverage contractors delivering components for the stream-aligned teams? [24:31]

Wes Reisz:  I have one more question in this kind of space. What about a company that uses contractors, brings in contractors to deliver units into the value chain? How do you integrate that type of work when you don't have a streamlined team that has complete code ownership of everything that they're actually delivering? How do you deal with it?

Susanne Kaiser: If you bring in contractors to the streamline team, you mean?

Wes Reisz: Yes, so like you've got a streamline team that owns an area of the business that's doing some kind of work, but they contract to bring different pieces in. A mobile app that may expose some things, or a capability that might be on a mobile app that maybe they don't have the like internal experience to develop themselves. How do you deal with that?

Susanne Kaiser: Yes, so it depends what part of the system they are integrated in. So, one thing is that either through well defined APIs of what they are going to provide, so is it excessive server that they provide or not, that they can easily consume or not. But also if they are just temporary support, for example, I would suggest to have them involved where you share the knowledge from the very beginning, having them being part of your peer programming sessions or more programming sessions where you don't have a team that is building expertise and then leave later, and then the knowledge is gone. So that you incorporate them in your processes, having them involved in your knowledge sharing sessions as well, so that they are becoming part of your team.

And they might rotate later on, also Team Topologies says that you should aim for long life stable teams, but this does not mean that they need to be static. So, team members can switch over the time, either freelancers or contractors from outside, but also Heidi Helfand also recommends to enable or to provide that team members can switch teams because that is one of the opportunities to retain your talents in-house. Right? So, for personal growth you sometimes would like to switch teams and if they can't grow within your organization, they will find growth opportunities outside of your organization.

Wes Reisz: It's the team structure that's long live, not the people on the team. Right?

Susanne Kaiser: Exactly. Yeah.

Wes Reisz: We talked about cognitive load in context of Wardley Maps. We talked about platform and streamlined teams. We talked about standard and standardization. We talked about Domain-Driven Design and then diving deeper into some of the components once you've identified some areas that you want to break out. What'd we miss?

Susanne Kaiser: Sometimes I'm asked, so what kind of benefits brings Wardley Map? And it's also that I like to highlight that first of all, it helps you to visualize potential instability in an associated risk. So for example, if you have a value chain where you have volatile components, for example, bounded context of your core domain are volatile because they're changing a lot and they have embodied quite high level of complexities because it's the one that provides competitive advantage. And so if you build these volatile components on top of mature and stable components, that is reflecting a stable system, but if you switch it around, if you have stable components that build up on volatile components, then it is a potential candidate for instabilities and associated risk because you have a stable component, which is expected to be stable and it's built up on volatile components and all these introduces new changes. And you have to keep the stable component up to date, or you have to keep the stable component stable. That shifts your focus on handling the source of risks.

What are some the patterns you’ve seen when parts of the system are unstable? [27:58]

Wes Reisz: Let's talk about that for a second. So, when I hear you say that, what are the patterns? Is that a candidate for a complicated sub process team, then to be able to encapsulate that instability and be able to elevate the constraint? Are there patterns to address that you've seen?

Susanne Kaiser: First of all, it creates awareness. Maybe it's on purpose. Maybe you would like to discover a new technologies and that new technology is still in Genesis or custom build. First of all, it makes you aware that you are building stable components on top of volatile components and that could be a potential problem. And then the other thing that I would like to bring in are the efficiency gaps. Like for example, if you are using internally a component in Genesis or custom build, but there is a component in the market that is more evolved in reciting, for example, in commodity and utility. This gives you an indication, a hint that you could be less efficient in your organization, because you're building on less efficient components that are then reciting on the left part of your Wardley Map, and this is an indication for you.

Wes Reisz: I want to dive into that just a little bit more. Sometimes a component might be very unstable, but it might be more towards commodity. Like you might have a bunch of network partitions or something on top of something, so I guess I'm curious when you talk about from Genesis to commodity, it's not just Genesis to commodity. It's like a whole spectrum of things to consider on that left to right? Right. So, how do you talk to people about understanding that yeah, this might be a mature service, but because you have all these network partitions that are there, it actually is further left on the Wardley Map. How do you talk to people about that?

Susanne Kaiser: It's more about the characteristics and general properties of the components of your Wardley Map. So, it depends on the market perception, and the user perception, and so on. So if you have cloud services, you expect it to be stable and if there is a failure occurring, you are extremely surprised that this failure happens. But if you have brand new product on the market, you expect failures or you can deal with it easier than with a very stable component. Like for example, power on your coming out of the outlet. If there's no power available, you will definitely be surprised. But if you have a brand new product supporting or something like that, you are kind of expecting that there might be some phase, it doesn't have to be.

So, there are different characteristics and different properties. Some of Wardley has created this evolution cheat sheet to determine the stage of evolution pack component. So for example, designing for failure as a component, doesn't necessarily need to be a physical component. It could be activities, it could be data, it could be knowledge, so it could be different activities. Designing for failure is something that is more an activity component. Maybe could be a component of your Wardley Map, of your value chain. If you can apply best practices then is something that goes more on the right spectrum.

Wes Reisz: I love that because you're describing, if you're building a stable component on top of something that's instable, whatever characteristic that you want to describe it, it lets you make very strategic decisions on whether you can elevate that component, whether you can wrap that component into something that might give it the option for failure. It lets you just kind of isolate that and make very strategic decisions on it. So, I really like when you brought up the complexity of dealing with writing something that's very stable on top of it. It makes a lot of sense to me.

Susanne Kaiser: And that also brings us to the context map of Domain-Driven Design, right? Where we have context map patterns describing the dependencies between bounded context visualizing or making aware the change coupling between bounded contexts. Right? And if you have a bounded context that is more like a supporting sub domain integrating with a quarter domain related bounded context, and there is in context map pattern between those, maybe a partnership or something like that gives you also bringing in context maps with the distribution of your bounded context on the evolution stages gives you an indication whether you have introduced tight change coupling between those systems.

Wes Reisz: Very nice. So Susanne, we're about at time. So what's next for you? What's coming up in the next part of the summer for you?

Susanne Kaiser: Well, yes, finishing my book right now. It's now in a review process and I need to wrap it up and then also see if you can still publish it this year. Let's cross fingers. And then also, yeah, looking forward to new opportunities. Yeah. Training and something like that I'm doing also the second half.

Wes Reisz: As always Susan, I thank you so much for all that you do for InfoQ, for QCon and for the larger community as a whole when it comes to microservices, when it comes to thinking about microservices and architecture.

Susanne Kaiser: Thank you so much for having me. It was a pleasure.