Podcast: Susanne Kaiser on Joining the Dots Between Wardley Mapping, Domain Driven Design and Team Topologies

Charles Humble talks to Susanne Kaiser, an independent tech consultant from Hamburg, Germany, supporting organisations with building socio-technical systems. They explore her thinking on combining Wardley Mapping with Domain Driven Design and perspectives from Team Topologies, and how this fits into broader ideas around socio-technical systems and optimising for fast flow.

Subscribe: Amazon Music | Apple Podcasts | Google Podcasts | Spotify

About the interviewee

Susanne Kaiser is an independent tech consultant from Hamburg, Germany, supporting organisations with building socio-technical systems. She is passionate about connecting the dots between Wardley Mapping, Domain-Driven Design, and Team Topologies as a holistic approach to design and build adaptive systems for a fast flow of change. Susanne was previously working as a startup CTO and has a background in computer sciences and experience in software development and software architecture since 2002. She is the author of the book "Adaptive Systems with Domain-Driven Design, Wardley Mapping, and Team Topologies: Architecture for Flow" (Addison-Wesley Signature Series (Vernon), 2022).

Resources mentioned

Full transcript

Introductions

Charles Humble:

Hello, and welcome to the second episode of "Hacking the Org", the podcast from the WTF is Cloud Native team here at Container Solutions. With this podcast, we're aiming to bring together some of the most experienced software engineering leaders, and talk to them about their experiences covering topics such as building and leading high performing software engineering teams. I'm Charles Humble, Container Solutions Editor In Chief, and for this episode, I'm joined by Susanne Kaiser. Susanne has worked as a startup CTO, and has a background in computer science and experience in software development and software architecture dating back to around 2002. She's now working as an independent tech consultant and is perhaps best known for her work joining the dots between Wardley Mapping, Domain-driven design and Team Topologies. And that will be the focus of the show today. Susanne, welcome to the podcast.

Susanne Kaiser:

Thank you so much for having me. I'm looking forward to it.

Can you maybe start by giving us just a bit of an overview of what Wardley Mapping is, and why I might want to use it?

Charles Humble:

Thank you. It's lovely to have you on the show. So we've talked a little bit about Wardley Mapping on WTF before, and I'll make sure I link to the relevant article in the show notes. But can you maybe start by giving us just a bit of an overview of what Wardley Mapping is, and why I might want to use it?

Susanne Kaiser:

Yes, Wardley Mapping itself, it's a strategic framework invented by Simon Wardley, a researcher from the UK. And Wardley Mapping helps to design and evolve effective business strategies that is based on situational awareness and movement following a strategy cycle. And the strategy cycle according to Simon Wardley is a representation of change and how we need to react it. And it's composed of five sections. The purpose, that is the why of our business. The landscape, that is the environment the organisation is operating and competing in visualized with a Wardley Map. I'll come back to that one in a second. Then the climate, these are the external forces, the external rules that are impacting our landscape over which we have no control. Then the doctrine, these are universal principles that every industry can apply regardless of their context. And then the leadership, these strategic decisions that are appropriate to our context, that's where we are then shaping or influencing the landscape itself.

Susanne Kaiser:

So in general, the strategy cycle reflects more the concept of a meantime to respond to changes. And so, the better we understand our purpose, the better we understand our landscape, and being able to anticipate changes, and the more doctrinal principles we have applied, the faster we can respond to changes. Either introduced externally by the climatic patterns that are influencing our landscape, or internally when we come to leadership and when we are changing the landscape itself. And this leads then to competitive advantage and yeah, it differentiates us for example from our competitors in our market. So this is like Wardley Mapping in a nutshell.

Charles Humble:

It feels somewhat similar to value chain mapping. What is it that makes Wardley Mapping distinct?

Susanne Kaiser:

Value chain mapping is more like something that is just trying to figure out what is necessary to deliver a value, for example, to your customers. And tries to figure out bottlenecks along the way. So for Wardley Mapping itself, a value chain itself is also part of Wardley Mapping, but it's more about how evolved is our value chain. For example, when we come back to the Wardley Map that is representing the landscape and organisation is operating and it's composed of a Y axis representing the value chain, and an X axis representing the evolution stages going from left to right, from Genesis, with brand new things, then custom build, then product and rental, such as off-the-shelf products, open source software solutions, and then commodity and utility on the most right side of the Wardley Map. So what you do here is at first, you try to derive a value chain that is composed consisting of users, and the users can be your customers, could be shareholders, business partners, internal users, and so on.

Susanne Kaiser:

And then what kind of user needs do they have? So what kind of problems they want to get solved. And so that are the subject area for which we build a product, and what components are necessary to fulfil the user needs? It could be either directly fulfilling the user needs directly, or indirectly by facilitating other components in that value chain. So they are plotted on the Y axis of our Wardley Map. And then we take these components and plot them along the evolution access going from left to right, as I said, like from Genesis custom build product and rental and so on. So we are using then characteristics. So while a component evolves through the evolution stage, their characteristics changes. For example, in Genesis, we are dealing with constantly changing, rare, little understood components on the left, and while it can become more and more industrialised evolving through the evolution stages going to the right, where we are then dealing with very mature, stable, well understood widespread components on the right.

Susanne Kaiser:

For example, if we map a landscape of our current state at our organisation, it's that we are putting the components and the evolution stage that we are currently using in our organisation. And this helps us to identify on the one side instabilities and associated risks. For example, the distribution of the components on the evolution stages, they visualise how balanced and stable the value chain is. For example, if you built your custom volatile services in custom build on top of mature standardised components that are then located on the right side of the map, that provides stability. But if you do it the other way around, so if you have stable services that are on the right side of the value chain, and they are built on top of volatile components sitting then predominantly on Genesis and custom build, that confronts your business with uncertainty, instability, frequent changes and a higher potential of failures as well.

Susanne Kaiser:

So there's one thing that you can identify instability and associated risks. And then also, it helps you to identify efficiency gaps. So for example, if the evolution stages of the components we use in our organisation differ from the ones that are available in the market, that might indicate an efficiency gap. So for example, at the current state, if we are using custom built components, but the components in the market are available as commodity, we are lagging behind, and might encounter potential inefficiency. And the bigger the gap, the less efficient our organisation might be. So this can also help you with identifying with assessing your current situation in regards to instabilities and potential risk or instability and potential risk. And also in identifying an efficiency gap that you would like to avoid and minimise, because inefficiency also hold your back in being able to innovate or any fast flow of change, and impede yourself a delivery of performance as well.

Charles Humble:

I think it's a fascinating idea, Wardley Mapping. And one of the things that I really like about it is it depersonalises those kind of strategy conversations, which can sometimes get quite heated if someone is particularly invested in one approach or another approach, and it can start to feel quite personal. I've certainly sat in executive team meetings where things have got quite fractious. And the interesting thing about mapping is it somehow makes the process quite collaborative.

Susanne Kaiser:

Exactly.

Charles Humble:

And I found the map itself is actually quite throw away, but there's tremendous value in working together to produce a map, and getting a common understanding of where you are. It's a really powerful idea, I think.

Susanne Kaiser:

Also, the conversation, I guess, that's the most worth that you get out of it, and to generate a common understanding. So for example, if you share maps and you are not included involved in the conversation to create it, sometimes you look at it. Yeah. That sounds interesting, but what does it mean?

Charles Humble:

Right. Yes, exactly.

Susanne Kaiser:

So sometimes it's more the conversation around and to generate a common understanding. I guess, that is one of the biggest benefit to create this Wardley Map.

What are the connections for you between Wardley Mapping and Domain-driven design?

Charles Humble:

And Simon Wardley himself says, "All models are wrong, but some are useful." That the value of creating the map is very much in this reaching a common understanding of the landscape in which your business is operating. That's where the value is, I think. What then are the connections for you between Wardley Mapping and Domain-driven design?

Susanne Kaiser:

Oh, there are multiple aspects where they fit together. So, one smaller part is that the users and the user needs of your Wardley Map of the value chain that are representing the anchor of your map, that all subsequent components relate to. They are also representing the problem domain in the context of Domain-driven design. And another aspect is that you can use the user needs and partition it, or you can address the problem domain and partition it into smaller parts, the subdomains. So not each subdomain has the same value to the business than others. So there are different types of subdomains, such as core, supporting and generic. And the core domain that's this part of the software as a part of the problem domain that provides competitive advantage. That's the part of the system that you strategically invest in most. Then the supporting subdomain that supports the core domain, and is necessary for the organisation to succeed. But there you should more look out for buying off-the-shelf products or use open source software.

Charles Humble:

And then the generic subdomain?

Susanne Kaiser:

That is the one that many business systems have, for example, authentication and payment. So they are not core, they provide no competitive advantage, but businesses cannot work without them. And you can use these subdomain types of Domain-driven design, core, supporting, and generic and map them to evolution stages. So that is another part. So for example, the core domain with the most strategic investment that we have to innovate on, they usually go into the evolution stages of Genesis of custom built, because that's the one that we have to strategically invest in most. The supporting subdomain does not provide competitive advantage, and there are already solutions on the market already. Then it goes into product and rental evolution stage, and if this is not possible, then we have to custom build it, then goes into custom build. But we should not heavily invest in that part of the system.

Susanne Kaiser:

And then the generic subdomains there exist, usually solutions on the market already. So buying off-the-shelf products or using open source software or outsourcing to commodity suppliers should be applied then to the generic subdomain. So that is the mapping of subdomain types to evolution stages, where they fit very well together. And another aspect also, when I talked to the instabilities before is also the context mapping, the dependencies between bounded context in regards to Domain-driven design. So I talked first about subdomains, splitting a problem domain into smaller parts. The subdomains, there we are in the problem space of strategic design of Domain-driven design and discover the core domain. And then the bounded context there, we switch to the solution space of Domain-driven design, where we do actually high level software design decisions, and where we are solving then the problem.

Susanne Kaiser:

So a subdomain in an ideal situation can be mapped to one bounded context and the bounded context itself forms a boundary around a domain model, and forms a unit of mastery purpose and autonomy. And between these bounded context, we have dependencies and these are in the Domain-driven design comes with context maps pattern, addressing the change coupling between them. So what level of dependencies is in between that. So they can be loosely coupled, or they can be tight coupled, and it's related to model propagation or team relationship, for example. And when we have context maps patterns. So when we are doing context mapping and strategic Domain-driven design, we can see when we put this on the Wardley Map of the bounded context and the context map patterns between them, then we can visualise problematic dependency that potentially lead to tight change coupling.

Charles Humble:

Can you give us an example of what you mean there?

Susanne Kaiser:

If you have a bounded context in Genesis in custom build, and you are integrating with a bounded context in Genesis and custom build, then you are integrating with, as I said earlier, with a volatile upstream bounded context that requires a lot of attention. And if you have the context map pattern in between them, that is by itself already leads to tight change coupling. Then you are in a situation where you have to keep your downstream bounded context that might be on that right side of the Wardley Map. You need to keep this one stable, and this potentially can drag your attention from building customer value to constantly handling the resources of risk. And there are some other context map patterns like how they are placed on the Wardley Map, which bounded context are interacting in what manner, is then can you give an indication about potentially problematic dependencies?

Charles Humble:

And then is there also a connection with strategic design?

Susanne Kaiser:

Strategic design helps also to apply doctrinal principles of Wardley Mapping. So while we are applying strategic design, we are already applying doctrinal principles of Wardley Mapping, one of the sections of the strategy cycle. So for example, at Domain-driven design centre is the close collaboration between the domain experts and the development teams that also support with analyzing the business domain and challenge assumptions. That is the doctrinal principle of Wardley Mapping. Through collaboration, we are gaining domain knowledge, and that let us get [to] knowing the details of the business domain and another doctrine principle and so on. So there are a lot of doctrine principles that Domain-driven design helps us to apply automatically. So that is another part where Domain-driven design and Wardley Mapping in general helps us fit together very well.

What perspective do you like to bring in from Team Topologies when building adaptive systems?

Charles Humble:

And then I mentioned at the top of the show that you also reference Team Topologies. And actually, we'll have one of the co-authors of the book, Manuel Pais, on the show next month, all being well. I hope I'm not tempting fate there. But what perspective do you like to bring in from Team Topologies when building adaptive systems?

Susanne Kaiser:

Yeah, so I like to use the Wardley Map as a foundation for discussions about reflecting your current state, but also designing your future state. And that's where I like to bring in then the Team Topologies perspective, having your Wardley Map at hand. And it then helps you to identify, for example, the suitable streams of changes for us, because in order to optimise for faster change, we need to know where the most important changes occur with streams of changes. So there are different types of streams. We have task, role, activity, customer segment, geography related types of streams that can vary from organisation to organisation. When you have a Wardley Map, the user needs, for example, they are good candidates for activity oriented streams of changes. So this can identify these streams of changes using the user needs that we can focus on when we try to optimise for fast flow of change.

Susanne Kaiser:

And then the next area that I like to bring in when we go further down the value chain of our Wardley Map when we for example, come to the bounded context in this regard, talking about Team Topologies finding suitable team boundaries, and where we can then use bounded context itself. Also, very well defined ownership boundaries, and they serve as suitable team boundaries for Stream-aligned teams, for example. So that is another aspect that I like to bring in. And another thing is about optimising for Team Cognitive Load. That is another aspect from Team Topologies, because if the Team Cognitive Load is largely exceeded, then it leads to delivery bottlenecks, to quality issues and so on. And so we need to optimise the Team Cognitive Load. And by limiting, for example, the number, size, type, and complexity of components or bounded context, a single team can handle.

Susanne Kaiser:

And I like to put this then in regards to that one, when I talk about optimising Team Cognitive Load, we can use also again, the Wardley Map as a foundation to derive a heuristic. So for example, if a team is owning bounded context or components in general, that are located on the left part of our Wardley Map, they are confronted with frequent changes, with an unclear path to action, with uncertainties, a high level of uncertainty. So the Team Cognitive Load tends to be higher for components on the left side of your Wardley Map. And where you then have components on the right side of the Wardley Map, where you're confronted then where it's most mature, stable and clear path to action components on the right side, then the potential Team Cognitive Load could be lower. So that means a single team can own more or larger components of bounded contextthat are residing in product and rental and commodity than for example, in Genesis and custom build. So that is one thing that I like to bring in, combine it with a Wardley Map.

Susanne Kaiser:

And another one is also creating clear ownership boundaries to optimise for Team Cognitive Load that is independent from Wardley Map itself, but that one bounded context should be owned by one team only. However, one team can own multiple bounded contexts. So these are then some of the perspectives that I like to bring in from Team Topologies. And then also, identifying suitable services that support a reliable flow of changes. And there we come to the infrastructure and platform related components that usually at the lower part of our value chain located more on the right part of our Wardley Map, where we can build a platform team owning these components and providing a platform as a service that then the Stream-aligned teams can easily consume. So there are a lot of aspects that we can combine with Wardley Map in order to build then an adaptive systems that is optimised for fast flow of change.

How does this combination of Team Topologies, Domain-driven design and Wardley Mapping fit into broader ideas around socio-technical systems and optimising for fast flow?

Charles Humble:

I'd like to unpack that a little bit further if we can. If we step up a level, how does this combination of Team Topologies, Domain-driven design and Wardley Mapping fit into broader ideas around socio-technical systems and optimising for fast flow?

Susanne Kaiser:

So in general, the perspective taken separately already covers some socio technical and fast flow aspects already. For example, Wardley Mapping with Doctrinal Principles, considering small teams, small contracts, optimise for flowand domain driven design with bounded context and their ownership boundaries, or context maps addressing change coupling and so on. But in my opinion, the combination of these three perspectives, they provide a powerful tool set to design and build and evolve adaptive social technical systems for a fast flow of change, because in my opinion, they are complimenting each other and supporting each other. And it's also like coming back to system thinking, that a system is more than the sum of its parts. It's a product of their interaction. It helps us when we build systems in general, we are faced with building the right thing and building the thing right.

Susanne Kaiser:

And a combination of these three perspectives help us to reflect or to consider our system as a whole in order then to build the right thing right. So I like this, that we have a broader perspective from business strategy, also software design and team organisation, because I guess, they can't go in isolation. They need to be combined from my perspective, in order to build a system that is optimised for fast flow of change.

How do you keep sight of the overall goal?

Charles Humble:

And then if we step up one more level, something that I think can be really challenging for anyone working in software, is that as you get into the implementation details of a problem, you lose sight of the overall goal. Has that been something that you've experienced? And if it is, do you have any specific suggestions or an approach for mitigating that?

Susanne Kaiser:

Yeah, that feeling sounds very familiar to me, that you can easily lose sight. What I like to do is in the situations, that I try to step out a bit, and that I try to look at the problem from a broader perspective. And for example, that I look at, for example, previously created Wardley Map with users and user needs, and it's related bounded context components of core domains, supporting, generic subdomains mapping them to the evolution stages. And I tend to ask myself whether the problem that I'm currently trying to solve is fulfilling a user need in some sense, maybe not directly, but indirectly. And if the current development effort that I'm putting in right now, is it worth its investment? So, do I work on a core domain related bounded context or component providing competitive advantage, or yeah, and also is this investment that I'm currently doing, is it reasonable, or do I reinvent the wheel instead? So an existing wheel.

Susanne Kaiser:

So the question that I'm trying to ask myself is, am I custom building commodities and wasting time, because there already exist solutions on the market already. And then also in this case, as I mentioned earlier, then I'm less efficient, because there exists several solutions on the market already. Specifically, when my competitor is using more efficient components available on the market. Am I custom building something that is more efficient that I can use just off-the-shelf or use open source software for, or use cloud hosted services? So try to step out by looking at the Wardley Map and to figure out what kind of problem I'm currently try to solve. And do I reinvent the wheel, or is this development effort worth its investment?

If listeners want to introduce some of these techniques into their own organisations, how would you recommend they go about doing that?

Charles Humble:

If listeners want to introduce some of these techniques into their own organisations, how would you recommend they go about doing that?

Susanne Kaiser:

First of all, you do not need to apply all at once from the very first beginning. I would recommend to start with the parts that are most useful for you at the moment. And for example, you could start as Team Topologies suggests, to start with your team first and analyse their current situation in regards to the Team Cognitive Load and encounter delivery bottlenecks, and try to solve their problems from the team perspective first. You can also create a Wardley Map representing the landscape you're currently operating and competing in. You can create a Wardley Map of your current state and use this Wardley Map as a foundation for future discussions. So, as I said, you can see if it's an instable Wardley Map that's reflecting your current situation, or are you confronted with inefficiencies, visualised with Wardley Map and try to tackle this situation.

Susanne Kaiser:

And you can also address then, as I said, as next step, the problem domain next, as I said, the users and the user needs are representing the problem domain from the Domain-driven design context. And you can then distil your problem domain into smaller parts of subdomains, and what parts then give you more competitive advantage. So in terms of discovering your core domain, support, generic subdomains, in order to give you an indication where to strategically invest most development effort. And then also then, as I said, subdomain can ideally contain one or in some cases even more bounded contexts.

Susanne Kaiser:

And then that could be the next step, designing the bounded context, and they serve then as suitable team boundaries for the Stream-aligned teams. And then, as I said, optimising for Team Cognitive Load, like what kind of bounded context the teams are owning?

Susanne Kaiser:

And then also identifying the services next that support a reliable flow of changes coming to the platform teams themselves. So there are different aspects, and you don't have to do like a top down approach. When I introduce it to others, I introduce it as a top down approach, but it's not necessarily that you need to dogmatically follow this process. You can start with makes more sense to you. You can start with a platform team first. For example, if you try to close efficiency gaps that sometimes the case when you move from on premise infrastructure to cloud migration, and this is then the subject area where you address those components that are related to your infrastructure, where you first form, for example, a platform team first, and then doing, for example, following re-platforming cloud migration strategy.

Susanne Kaiser:

And then on top of it, you can, for example, if you're dealing with a legacy system composed of a monolithic big ball of mud with a messy model and fuzzy boundaries, you can try to re-factor a bounded context to break it apart into smaller modular components, and there you form your Stream-aligned teams, for example. And with Stream-aligned teams, if you are then for example, follow the cloud migration strategy of refactoring. There you can closely collaborate with the platform team to discover the new technology stack, if you're not familiar with that one. And later on, it can go from close collaboration to limited collaboration, and t then X-as-a-service where the platform team can provide X-as-a-services to consuming then the future cloud services itself. So there are current possibilities, opportunities to optimise your system for flow.

I know you are writing a book for Addison-Wesley on this subject. How's that going?

Charles Humble:

That's fantastic. Thank you. Now, I know you are writing a book for Addison-Wesley on this subject. How's that going? And when can we expect to see the book?

Susanne Kaiser:

Oh. Yeah. How to describe the current status in nice words.

Charles Humble:

It's going well then!

Susanne Kaiser:

Maybe it reflects the current status. First of all, I admire the patience of my editor. It takes far longer than I originally anticipated, but it's supposed to be published at the end of the year. So let's cross fingers. I'm still in the process. So that is the current status. And your second question was?

Charles Humble:

You've actually kind of answered that. When can we expect the book out? So hopefully the end of the year, I guess.

Susanne Kaiser:

Hopefully, yes.

Charles Humble:

Yes. It's one of those things, isn't it? When you start writing a book, you think, oh, it's just like a very long series of articles or something. How hard can it be? And the answer is extremely hard, it turns out.

Susanne Kaiser:

Yes. So my ideas in my brain, so they are so fuzzy. So this is a like monolithic the big ball of mud. And I have to decompose it into sentences that everyone else can understand. So this process is so hard for me right now. And it's easier to say than actually doing it.

Charles Humble:

I think it's a really interesting thing about the process of writing, or putting a conference talk together, or writing a blog post or anything. But that process of trying to distil the ideas that you have in your head down into something that makes sense to other people.

Susanne Kaiser:

Yeah.

Charles Humble:

It's a real test of how well do I really know this subject, I think.

Susanne Kaiser:

Exactly. Yeah, and having your ideas in mind is totally different than really writing it down in a way, as you already said, that everyone else can understand it and can follow it. And I guess, that is specifically when you try to bring three complex contents together, you want to build up on this awesome books from Wardley Mapping, Domain-driven design and Team Topologies, but you don't want to rewrite the content. You want to connect the dots between them, and how far go you in detail describing the concepts and fundamentals. And then also applying and connecting the dots between them, and then also, bringing in an example that makes it tangible to the reader, so that they can see the benefits of how combining this perspective and connecting the dots, so that you have a storyline. So there's a lot of information that, "Oh no, I need to bring in that one. Oh, forgot that one."

Susanne Kaiser:

So there are a lot of areas that I guess, at the end that I have not forgotten, but I wanted to bring in, but I couldn't. And I guess, it takes yeah, even after I've published it, "No. Damn it. I should have written about this as well." I guess, there are a lot of regrets afterwards as well. So let's see.

What resources would you recommend to readers who maybe want to find out more about some of the topics we've talked about today?

Charles Humble:

I think it's absolutely inevitable though. I mean, I think with any long piece of creative work that you do, and I'm thinking about music for me, and whenever you put an album out, when you listen to it later, you're like, "Oh, why did I mix that kick drum too loud?" Or, "What was I thinking there." And actually the novelist Neil Gaiman's definition of a novel is, it's a long piece of prose writing with some mistakes in it. So you're certainly not alone, I think, in feeling that. But I am very much looking forward to reading the book when it comes out. In the meantime, what resources would you recommend to readers who maybe want to find out more about some of the topics we've talked about today?

Susanne Kaiser:

Of course, they are the core books of the three perspectives. So Simon Wardley's Wardley Mapping book, which is available, it is for free. He publishes under Creative Commons licence, so you can, I guess, download it in various formats. And then Eric Evans Domain-driven design book, and Matthew Skelton's and Manuel Pais' Team Topologies book. But also other resources, for example, Vaughn Vernon has created a series of Domain-driven design related books with implementing Domain-driven design and Domain-driven design distilled. And also, his new book, Strategic Monoliths and Microservices, for example. And also, Vladik Khononov, he has also written a fantastic book about learning Domain-driven design for those that start with the topic. And then of course, they are so many great community driven GitHub repos, for example, such as for Wardley Mapping, for example, it's a GitHub repo Wardley Maps community. And for Domain-driven design, there also exists this great GitHub repo called DDD Crew. So we can maybe add this to your show notes later on as well. So there are a lot of resources.

Susanne Kaiser:

And of course, for example, Ben Mosior, he's very active for Wardley Mapping, and he also provides little trainings or tutorials that he compiled together. And there are also other websites that help with his topics too, learningwardleymapping.com. So there are a lot of resources that are available to dive into that topic.

Charles Humble:

That's fantastic. I will make sure I include links to all of those in the show notes for this episode of the Hacking the Org podcast from the WTF is Cloud Native team here at Container Solutions. And Susanne, thank you so much for doing this. It's always a pleasure talking to you. I always feel like I learn so much. You are a brilliant thinker, and this has been an absolute joy for me. So thank you so much for doing it.

Susanne Kaiser:

Thank you so much for having me. I enjoyed it a lot.