Simone Cicero 

Hello, everybody, and welcome back to the Boundaryless Conversations podcast. On this podcast, we meet with pioneers, thinkers, and doers, and we talk about the future of business models, organizations, markets, and society in our rapidly changing world. Today, I won’t have any co-hosts, and I’m joined by Susanne Kaiser, who is an independent tech consultant from Germany with more than 20 years of experience in software development industry. 

 

She has been doing some incredible novel and seminal work in putting together a lot of useful techniques and practices that exist in this liminal space between how we organize and the artifacts we create, especially with software-based products. Hi, Susanne, it’s truly a great pleasure to have you here.

 

Susanne Kaiser 

Thank you so much for having me, Simone.

 

Simone Cicero

Looking forward to our conversation. I was exposed to Susanne’s work for the first time earlier this year, as I was researching ways to approach, let’s say a process of   and rebundling an organization in ways that are market-driven, product-aware, product portfolio-aware.

 

And I encountered a piece on InfoQ titled “Adaptive Sociotechnical Systems with Architecture for Flow, Wardley Maps, Domain-Driven Design, and Team Topologies”, which I would say, Susanne, correct me if I’m wrong, but I would say is some sort of culmination of several years of work, right?

 

Susanne Kaiser 

Of course, decades of work, I would say, from others. So building up on the shoulders of giants. Exactly.

 

Simone Cicero 

So not only your work, actually work of somebody else as well. So it’s great. And I believe that there is also a book coming up, if I’m right.

 

Susanne Kaiser

Exactly, still in the process, in the review process, but it’s hopefully going to be published next year.You can pre-order on Amazon, by the way, and also in other places, I guess. 

 

Simone Cicero 

And I believe, let’s say, that your work is really embodying some kind of coalescing that we are seeing of these three key elements when we speak about organizing. So first of all, organizations are becoming more product-centric. 

 

So for example, the importance of understanding product differentiation and portfolio management and so on. Software is hitting the world. So a lot of the work we do as companies now is actually software. And evolution is also becoming faster and faster. The world is changing faster. So Wardley mapping is a very good technique to understand evolution. And evolution is accelerating, so we have to understand it. So.

 

I know that, let’s say that, you know, we need to acknowledge that there is, as we discussed, an inherent challenge in explaining your work without visuals, but we’ll try. And from time to time, especially for our YouTube listeners, we may be using some pictures. So if you’re listening to this through a podcast platform, we suggest you to switch maybe to YouTube where we can also watch some of these pictures it would be helpful. 

 

And we’ll certainly put some links in the show notes where you can find the article and maybe listening to the podcast as you watch the article would be helpful. But maybe as a starting point, Susanne, what I would like to ask you is maybe to introduce us a bit of, as you said, the work that you have been doing and the three core methodologies that you used. Maybe you can introduce our listeners.

 

I’m sure some of them will be familiar with this, but maybe you can introduce these three techniques and explain how you put them together into a new novel approach that you are now experimenting with your customers, with your partners, and so on.

 

Susanne Kaiser 

Yeah, so I was inspired more by Dr. Russell Ackoff, one of the pioneers of system thinking, because he stated that the system itself, it’s more than the sum of its parts, it’s the product of the interaction. So the way parts fit together determines the performance of a system, not on how they perform taken separately.

 

And that brought me, like, so when I started my career, I was just, I was focusing on local optimization of separate parts instead of like thinking of the whole of the system. But, but as Dr. Russell Eckhoff said that we have to focus on how they are interacting with each other and not only how they are composed of each other. 

 

And so that brought me then more to a holistic view from to bring three different perspectives together. So one perspective from business strategy, for example, with Wadley mapping, invented by Simon Wadley. Then the other one more about like software design. So for example, domain driven design from Eric Evans. And then the third perspective that came later into my tool set by the team organization was team topology by Mr. Skeleton and Manuel Paes.

 

So I’d like to bring this tool set together as a holistic approach in order to build adaptive socio-technical systems that are optimized for fast flow of change so that then can respond to changes quickly in our ever-changing environment where we have to equip ourselves or equip organizations to absorb changes gracefully so that they do not get overrun by their competitors. Instead, they can act ahead of their competitors and also try to figure out what future opportunities come up in terms of like combining these three perspectives together. 

 

And we’re also to strategically invest in most. So for example, we try to focus our strategic investment on our core domain, which provides a competitive advantage instead of reinventing the wheel or custom-building commodities that are not core to our business. So then we also, it’s all combined together. 

 

And also from Conway’s law, we know that the communication structure in your organization has a huge impact on your software design later on. And so also like how the teams are split, how they’re interacting with each other, then also resembles in your software architecture and your software design later on as well. So from my perspective, bringing business strategy with wadley mapping, software design, with domain driven design and team organization with team topologies together is for me a great toolset to equip an organization for fast flow of change and also enable organizations to incorporate fast feedback as well.

 

Simone Cicero 

Mm-hmm. So if I can try to provide our listeners with some kind of navigating map, when we look into your work and we see these three big pieces, the first piece you told me, for example, you always start with Wadley mapping. And it feels like you have to start with setting up the situational awareness, right?

 

So first step, situational awareness, for who are we building? What is the context around our company? How are things evolving around our companies? Then you move into domain-driven design, which is for me at least is a lot about what are we building. So I would say what is the ontology of the things that we are building? What are the uses? What are the pieces? How the pieces connect and differentiate?

 

The team topology piece is more like “how” we organize to produce flow and to produce an organization that can continuously evolve. So I would like to ask you maybe to tell me a little bit more of what are the key steps in the process. And I would love to hear from you. What are the key, I don’t want to say surprises, but – I mean, I see this most of the time when we work with organizations, there’s a lot of gap between what it takes to be performative in a market like the one we live today and how organizations are at the moment. So really, maybe if you can stress a bit and explain a bit the gaps that you are going to overcome by applying this approach, that will be helpful.

 

Susanne Kaiser 

Yeah, so I guess one of the greatest benefits is in this approach. So the first benefit that I encounter a lot is the common understanding or shared understanding of the landscape on the one side. Like, oh, I get a lot of like feedback like, oh, I didn’t know that we are doing this. Oh, really? We also have this user and they have this user need. So it’s to generate this shared understanding and also to understand the problem first before we provide a solution – is very important. Yeah, and in every organization that provides services or products in the market. So, and so for example, to create this shared understanding, I start first with creating the workload map. That is visualizing the landscape and organizations operating and competing in. And it’s composed of a y-axis and an x-axis. And on the y-axis, you’re trying to find or to try to identify first your user and your user needs. These are the anchor of your map. And your users could be your customers, but it could be business partners. And this could also be internal users as well. And you can also generate different Wadley maps in your organization does not have to be just one. 

 

It could, for example, be one Wadley map for one user or even one Wadley map for one user needs. So it depends on your context. And so, and they usually start with like, okay, let’s collect all users that you have that are using your services currently. And then also switch to the internal perspective as well for your internal product. So just like collect all the users first. So I don’t, I don’t restrict it. 

 

And then, and first, the first conversation, oh, we only have one user. So when, before we start this workshop, but when we bring all together, then, uh, a lot of new users come up that, that others were not aware of and I guess there’s like oh yeah we also have this users and then I go into then I scope the Wadley map or the first Wadley map it’s an iterative process so it’s not have to it it’s not perfect it’s not like it’s just an abstraction. You can start with picking just one user for example and then okay what are their user needs you can follow user journey if you want to

 

And the users and the user need that are representing them, the problem domain later when we come to domain-driven design, it’s like, OK, what is the subject area for which we build a product for or service for? And then from there, after each of them have understood the problem itself and what we try to solve, then we can go into the solution space and that’s where we come to the value chain and the y-axis or what components are necessary to fulfill the user needs directly or indirectly. 

 

So it’s a chain of dependencies or chain of dependent components. And on the top of the value chain, we have components that are most visible to the users for where users are touching your 

product or services directly. And on the top, it gets less and less visible to the users. And then you, this is the y-axis, and then you try to plot those components on the x-axis, and you try to plot them to assign evolution stages from left to right. So from Genesis that’s on the left side with brand new things and custom build and product and rental such as off the shelf products are open source software solutions and commodity and utility on the right for example cloud hosted services and this also like trying to map the components like towards the evolution stages gives you also an indication or an understanding of your landscape. So for example

 

One question is that are you custom building commodities, as I mentioned earlier, that are not core to your business, that can be kind of like identifying some outliers. Like, oh, we could use utility services, for example, for that one. Also with the trade-off, of course, it has to be integrated and so on. It’s not just like that everything is out of the box. We have to put in some adjustments as well. 

 

Yeah, you don’t have to build everything from scratch. And the other thing is then also how identify instabilities and potential risks.

 

Each evolution stage itself addresses different characteristics. So towards the left spectrum, towards genesis and custom build, components are changing far more frequently and more uncertain. Like there, we are dealing with unknown unknowns on the right spectrum, towards the right spectrum, towards commodity and utility. There we have standardized components, widespread, well-understood markets, and the change rate. They are changing not as frequently at the components on the left spectrum.

 

If you, for example, have a value chain, which is where you have a lot of components and maybe in product and rental and they are built on top of like volatile components on the left spectrum, that could indicate some instabilities to make them so because you’re building on top of constantly changing components and maybe that was some purpose, maybe you have decided we would like to introduce this new technology.

 

But at least it creates awareness, it reveals it, and something which was happening before, like why are we wasting so much time in trying to stabilize components, for example, and this the Wadley map can help you to reveal those situations like outliers, instabilities and risk. 

 

And also when we can combine it then later on with domain-driven design, we can also identify areas, like for example, with the subdomain types that comes from domain-driven design with core domains supporting generic subdomains. So core domain providing competitive advantage, that’s where you should strategically invest the most. These are the elements that you should build in-house, supporting that is like – that are components that support the core domain, but do not provide competitive advantage, are existing and other competitive solutions as well. And there you can decide, well, should we custom build or should we use rather an off-the-shelf product? It does not jeopardize your solution or your business if you are using also off-the-shelf products. And Genesis, these are elements or components, for example, authentication, registration that every business system has or a lot of other business systems have. They are very widespread and ubiquitous.

 

So there you can definitely look out, watch out for components that are available in the market as commodity service or off-the-shelf products. You should not focus on custom building those, because they do not provide competitive advantage unless they are your core domain. So I mean, that is the conversation that I have when we are going towards looking at the Wardley  Map of some of my clients and at least like.

So the Wadley Map provides a visualized structured way to generate a common understanding, and challenge also your own assumptions and creating a shared understanding of the landscape. And then from there, we can use this one as foundation to look into details.

 

Simone Cicero 

It’s really important to kind of objectivize visually the understanding, the knowledge that there is in a leadership team or in a portfolio team, right?

 

Susanne Kaiser 

Definitely. So it is because usually it definitely helps you to detach personal preferences from the conversation because it’s like, because you bring, yeah, you try to bring this on the Wadley map. And also, and if, for example, if you then decide, ok, we would like to custom build this component, you can then run into a trade-off analyzer. It’s like, ok, what does it bring us? What are the pros and cons? And I also try to have a structured way for discussion. And it starts with sharing this map, or yeah, with creating this map altogether, like the conversation that you have around, and bringing in different assumptions together.

 

Trying to create this Wadley map. So it does not like that one person is like okay it’s this way, only this way instead it’s like this collaborative approach to create a shared understanding of the landscape. It’s not only one, it’s all the team that creates this world map together.

 

Simone Cicero 

So, Wardley Map gives you a lot of understanding in terms of what is the value that the user perceives, what is the stage of evolution of certain components. And I think lots of organizations fail to understand, at least this is my experience, that the business, the products they create, the services they create exist in a competitive environment. And it’s the market that dictates.

 

The evolutionary stage of the technologies they use, the tools that they develop, and so on. So for example, when you have a, I don’t know, maybe an easy example would be a data center or something like that. Data center at the moment is something that has evolved to become ubiquitous and cloud-based. And so it’s not that you, as a company or as a team inside a company, can decide what is the stage of evolution of a certain component, but it’s rather the market that defines the stage of evolution. 

 

And I think in my experience, that’s something that companies sometimes fail to understand. You know, it’s not something you can define internally. It’s rather something that gets defined by the market. I would like you to double click quickly on instead, the advantages of, because, you know, I think Wadley mapping in general give you I would say something that companies can understand, understanding their situational awareness. 

 

But it’s rather rare to see companies understanding the concepts in domain-driven design. So maybe you can spend a few more words in terms of why applying domain-driven design and understanding, you mentioned this before, the core domain, the generic subdomains, supporting domains. What does it mean for an organization to understand in the stack that generates the value proposition to understand what domains are the core ones that create an advantage, constitute an advantage, what are the supporting ones that can support different products may be, and what are the generic ones? And maybe they should be outsourcing. Maybe you can double-click a bit on the second strategic piece that emerged from the analysis that you do.

 

Susanne Kaiser 

Yeah, definitely. So yeah, so as you already mentioned, the subdomain types of domain driven design from strategic design perspective enables us to prioritize our strategic investment. So we would like to focus our strategic investment in terms of like, okay, where put we all the development effort into, for example, into those parts that are generating the value where we see that we are differentiating ourselves from competitors, so where we can innovate on. And so these are the core domain related parts that differentiates ourselves from our competitors. 

 

At least like It has so competitive advantage from Michael E. Porter. He says competitive advantage is composed of differentiation advantage and or cost advantage. And so and the core domains, a core domain is also subject to evolve. Right. So Simon Wadley says everything evolves through the forces of demand and supply competition. So everything evolves through the stages at some point in time. You don’t know when. But if you have demand and supply competition, then definitley the component will evolve, also your core domain at some point. So usually, I guess the majority of core domains might reside in like Genesis custom-built evolution stage where you have a high level of change rate, high level of uncertainties, high level of differentiation advantage. So that’s something that you should focus on building in house for example. You should not because if you’re outsourcing these elements you might you bear the risk of jeopardizing your business success. There were some companies who did that and they failed. I would love to have some data like how many people are, how many organizations try to outsource their years ago they tried to outsource their core domains. It was highly expensive for them and also high risk, high level of risk as well. So definitely you should custom build your core domains in-house.

 

And then also like your system usually does not or your product that you provide usually consists of also other subdomain types, for example supporting subdomains that are not necessarily provide competitive advantage but are necessary for, yeah, for example user experience, for example notification handling, like that could be something that you could consider as, and it depends on your own context. And then there is something, okay, you can decide on custom building that in-house, but you have to be aware that you should not put a lot of strategic investment in that part of the system. Or if there exists an off-the-shelf product that is easily to integrate, you can think of that one. It does not jeopardize your business success if you’re using third party solutions. 

 

And then the generic subdomains, these are like authentication registration, as I mentioned earlier, these could be, these are potential candidates for generic subdomains that exist not only in your competitive solutions but are far more widespread in other business solutions as well. And definitely, these are candidates where you should not custom-build it.

 

Or yeah, if you are intending or planning to do that, then you have to have a good strategic reason for that one, why you should custom build these part of the solution that does not provide competitive advantage at all in your subdomain types. And yeah, so it helps you that the subdomain tips from domain-driven design, that is happening in the problem space, right? So these are like for example reflected in new users and their user needs. And then you can also switch to the solution space of strategic design, of domain driven design, and that’s where we then try to identify boundaries that encapsulate domain models that represent a particular business logic of a specific part of your system. 

 

And the bounded context helps to enforce modularity and high cohesion in the bounded context itself, related business behavior that should sit together. So whenever you change a specific business behavior that you need to change it only in one part of the system. And these bounded context on the other side, can also then be good candidates for suitable team boundaries for stream-alignlined teams. And that’s why we switched then to the team organization and tried to go into like, yeah, identify suitable team boundaries, what teams also in order to establish clear ownership boundaries so that we don’t have shared responsibilities like one component shared by multiple teams that is usually not a good idea because then you diffuse the ownership instead that one bounded context should be owned by one team only however one team can own several bounded contexts that depends then on their team cognitive load how many context they can own.

 

So yeah so that is so Domain Driven Design to summarize is on one side is to prioritize your strategic investment, what to build in-house, where to make, you have to make build, buy or outsource decisions, together combined with the Wadley Map. And then the bounded context, when we switch to the solution space, they help you then also to decompose your system into modular parts, well encapsulated parts, but also are good candidates for team boundaries, ownership boundaries, and there we come to team topologies, for example, where streamlined teams could own specific parts of the system.

 

Simone Cicero

The impression that I have is that even if you start with Wadley mapping, as you said, it looks like the domain design, so this idea of understanding bounded context, which is, to be honest, very alien to most of the organizations I talked to, especially those that do not make software, or at least make software very rarely, or small part of maybe more complex business processes, which may entail, I don’t know, manufacturing or hardware or service delivery, whatever. 

 

So Domain Design and in general, this idea of understanding bounded context, it’s a competence that is very rare and looks like instead in your practice, it becomes really the anchor of the work. 

 

Because if I understand well, for example you kind of draft your first Wadley map that represents your organization as a chain of value from your users into your capabilities and so on. But then when you apply DDD, “Domain Driven Design”, you start to understand these bounded contexts. And the bounded context become, on one side, the piece that you can move in the map. So you can, for a certain bounded context, you can say this is a Genesis, something new, or maybe this is a commodity, or whatever. 

 

So it’s really important for you to understand the bounded context, to understand the level of evolution. And secondly, given the Conway Law implications, bounded contexts are, as you said, normally very good entry points, very good initial starting points to build your team structures, right? 

 

Because, you know, in an ideal world, let’s say if you have an organization with five bounded contexts, maybe you want to have five teams, I’m just making it simple, because each team can run its own inside its own system and the concepts and the ideas and the domain elements that are inside this bounded context normally are not overlapped across bounded context. 

 

So as you said, you can and all impacts the subpart and then use interfaces for the other parts of the system. And in this way, you have a modular organization, you have a modular portfolio and so on. So first point, understanding bounded context emerges in your practice as a very important capability for organization. So understanding what you are building, what are the boundaries among the context, that’s becoming a very important point. 

 

So maybe a nother question that I would like to ask you is that maybe if you can double click a bit on this idea of bounded context in the business environment and maybe difficulties that teams normally encounter on defining this bounded context. And finally, as a second point, I would like to ask you, how do you kind of overlap the concept of products into this system, right? 

 

Because so far we discussed about bounded context as, let’s say, pieces of the organization that are more or less self-contained. Then we discuss about teams, but we never discussed about products. And normally in our practice, a lot of the work we do is about product-centric organizations. And when we think about a product, we are often, I would say, we tend to consider P&L, so something you can sell, something that can produce revenues, has some cost, and so on.

 

So again, two points. First of all, if you can jump into explaining a bit better what a bounded context is in this context. And secondly, how do you use the concept of products and portfolios when you use this bounded context and the team structures to construct, let’s say, product portfolios in the organizations?

 

Susanne Kaiser 

Yeah, so first of all, I guess identifying or driving bounded context or boundaries is not easy. And it’s totally fine if you struggle with that one. I guess everyone is struggling with that one. And it requires a few iterations. And maybe it’s something that you have to adjust along the journey as well. I try to identify areas where we have related behavior, and so that shall sit together. So when it change, that it should not. So the context itself, they try to enforce modularity and high cohesion, so high cohesion in terms of like that related business behavior shall sit together, but also they try to minimize tight change coupling. So whenever you make introduce a change, because we are the overarching goal is to optimize our system for fast flow of change, so when we introduce a change for example of a specific behavior, that this behavior is encapsulated in a specific part. And what I usually do is I introduce event-storming sessions to organizations. So I’m bringing then domain experts and development teams together. So it’s very crucial that we bring all the domain experts and development teams together to create this, again, shared understanding of the domain, which is then described in the shared language, the ubiquitous language, it was very important also to identify bounded contexts. And what I use is then event storming techniques from invented by Alberto Brandolini, a technique to express what happens in your domain expressed with domain events expressed in past tense. You have color coded sticky notes where you bring them, you collect. Start usually with Okay, express what happens in your domain was domain events, for example, auto-placed or user registered in-board or session proposal submitted or something like that. So that has you try to avoid crud terminology create, read, update, delete because sometimes it’s encapsulate more than just like create, read, update and delete.

 

So you try to have an explicit language that describes what happens in your domain, using domain events along a chronological order. Then you try to sort them in chronological order, and then you try to apply some heuristics. So you add also over the course of the event storming sessions, you also complement it with other color-coded sticky notes. I don’t go into detail of event storming right now, but it helps you to identify areas applying some heuristics. For example, there is also a great resource like the GitHub report of DDD Crew. 

 

It’s also great to use for that perspective and to try to apply some heuristics, for example, is it a start or end of a process or start or end of a user journey? Do you have a handover from one actor to the other? And this is something or like later on you also bring in then the aggregates that encapsulate like when you come down to software design, it has different formats. It starts with a big picture of the event, storming sessions, then process modeling and later on software design. And at the beginning you’re collaborate with the domain experts together and you try to like where you can identify some boundaries where for example an actor could be an individual person a department a group a team is involved in a sequence of domain events and then another actor comes in maybe that is something from one actor to the other it could be a boundary so and it’s like 

 

Simone Cicero

Like an hand over, right?

 

Susanne Kaiser 

Yeah, it hand over exactly. 

 

And also, sometimes what I see is, so God objects, when we come later to do software design, that causal events doming can help you to create your initial software design as well. And in a lot of monolithic big ball of mud solutions that have evolved over the time, I see a lot of God domain models, huge domain models was, I don’t know, 400 different fields. And every field has a different meaning and a different context. So all contexts in one God object or God domain model. And this is where then ubiquitous language comes in, for example. Let’s see, let’s talk about a call for paper solution where a conference organizer is publishing a call for paper that speaker can submit the session proposals and then you evaluate the submitted session proposals, create an agenda and something like that. if you create the agenda with the same object there you have time slot and room, for example, as attributes. And you have to apply business logic that avoids to duplicate booking of the same session or duplicating the same room. 

 

But this attributes and this logic is not relevant when a speaker is submitting a session proposal, right? If you have the same object and then maybe there are talk title, talk abstract tags and something that is relevant for submitting a session proposal. But they have different contexts, this is just one domain model. 

 

And so this then becomes like a really big ball of mud over the time. And this happens.

 

So you have different meanings, different contexts involved in one got objecting, that’s where the bounded context come in. You try to split it where, for example, session, like in the session proposal, has a different meaning, a different context than the session that you create the agenda for later on when you publish the agenda for the conference event, for example. 

 

So, and this is like on the one side, you have a scheduled session or a session proposal, and then you adjust your ubiquitous language to make it explicit. And this is an indication also where we have two different contexts in the game. 

 

How I usually do it and a lot of feedback that I get is from these sessions, like, oh, we didn’t know that this happens there as well. It’s also not only for driving bounded context, but also for creating the shared understanding to have this big picture of what happens in your domain. And it could go across bounded context. You can start broad and then dive into a specific area and then go into details and that one.

 

So that is something how I approach it and also to then have the two benefits of creating a shared understanding of our domain knowledge, what happens in your domain, like a shared domain knowledge, and then also to derive them bounded context later on.

 

Simone Cicero 

Let me maybe clarify the second question that I made based on what you said, right? Because I feel like, of course, we can focus on understanding the domains. We can focus on using the techniques that you mentioned, like event storming. And by the way, Alberto was on the podcast, Alberto Brandolini was on the podcast a few episodes ago. So listeners, if you want to check it out, maybe you can look into the show notes where we will link the show. 

 

But my question for you is, when we do this kind of domain-driven design-based definition of the bounded context inside the reorganization, we tend to have kind of subdomains which resonate with certain capabilities that we have, certain processes that are fairly independent with each other.

 

And that Of course, that’s our aim, to isolate the pieces of the organization and its business process that are not very dependent on each other. That’s essentially the idea. But my question is, how do you balance this tendency of unbundling into process elements with, let’s say, some kind of constraint that, I would say, uses a product heuristic right? How do you avoid unbundling in pieces that are too small. And then, you know, people are not responsible of the business value or the customer value or the profit and loss and so on. So I think there is this kind of balance to seek, right? Into unbundling for the sake of unbundling and unbundling, let’s say, to a certain level where you can have a functional product, you can have a functional business process or a business model, right?

 

Susanne Kaiser 

Yeah, so definitely, I guess you have to relate your bounded context also in the context of others. And as you said, like if you are too fine granular, I guess it could happen. So I guess to unbundle tiny pieces what is the side effect like for example in Neil Ford and Mark Richardson they talked in Software Architects the hard part about disintegrators like how to decompose your system into modular so there’s service functionality that is good for example or functionality in general that could be a bounded context but also like volatility and then also so some other aspects as well that they put in for like this integrator, like when to decompose your system to smaller parts, but they were also talking about integrators when it makes sense to bring them back together because there’s something for example that if you have to have certain transactions. Bounded context are good candidates for microservices, but it does not necessarily mean that you have to unbundle your system into microservices. It could be also modular monoliths or domain services that are still accessing the same database, for example. So they don’t have end-to-end cut like the microservices have. So it depends – bounded context, they do not dictate a specific architecture style. They only give you an indication where you have modular boundaries, but how you implement it, like what architecture style you will then apply that is then not related to domain-driven design. So they don’t say, okay use microservices for that one. That is something that you can later on I would suggest to make this decision very late.

 

First of all, it’s important to identify the boundaries, but how you then implement it later on, and with all this trade-offs, later on when you introduce microservices, or if you even say, OK, let’s introduce serverless technologies and go even more fine granular, that is something not related to domain-driven design.

 

I always try to make trade-off analysis together with the teams. OK, what does it mean when we go this way or that way? And also then describe it documented in architecture decision records later on. What was the context we started with? What options do we have? What are the pros and cons? And if we decide for that one, what would be the consequence out of it? 

 

Because I have a very short-lived memories, so years later I don’t know why we decided that way and architecture decision records for example have you a lot with going back into your like what was the context back then. Maybe the context has changed and we can then revise our previous decision. 

 

We used microservices with its own data storage and decomposed everything from front end to business logic to data storage and we identify some areas where they should go together again and integrate them back again.

 

 So that could happen and I would say that is something to decide how you implement it also to do like a trade-off analyzers later on. And to introduce to identify a module like by bond context. It could be like a package structure or something like that but how you implemented this could be then was could be complemented with trade-off analyzers.

 

Simone Cicero

That’s really interesting. I think this is… And forgive me if I ask you again, who was the one you were referring to with this concept of integrators and disintegrators?

 

Susanne Kaiser 

That was Neil Ford and Mark Richards, Software Architecture, the Hard Parts. So they have published two big books, Software Architecture, the Hard Parts, and the Fundamentals of Software Architecture. I don’t know exactly which one they would, which had the integrators and disintegrators, but this was more from a software architecture point of view. 

 

Simone Cicero 

Okay, that’s a very interesting idea, I think, you know, because if I look into, you know, the practices in your article and in your upcoming book, you basically… Let’s try to recap. 

 

You use bounded context to understand the boundaries of the pieces of the organization, let’s say the modules of the organization, then you understand their, I mean, it’s an iterative process, but then you understand their evolutionary stage, you start making considerations on what’s a competitive advantage, what is something that maybe is not a competitive advantage, but enables a lot of our capabilities, so we want to make it our own. And then also what are the commodities that we shouldn’t be building, but rather, buy from the market.

 

So it’s a very powerful strategic awareness, a strategic understanding of your company. Then you have the team topologies part that is one possible way to map this context, this bounded context into type of teams. So I would say when you say stream aligned teams for our listeners, it’s just a clarification to say a team that can basically perform a certain long-term development of a piece of a system, essentially it can have its own ownership then you can have platform teams and other types of teams that I don’t want to dig in now, but you have our listeners.- If you didn’t check team topologies yet, you should run and buy the book because it’s one of the most significant books on organizing companies and organizations that produce software. So it’s a way to map the bounded context with a certain type of teams. 

 

But if you add on top of this, and I think this is also a good hint for your further developments, if you add this idea of integrators, I think it’s really powerful because integrators, so these kind of functions that can tell you, you have unbundled your organization into pieces, but now we try to bundle them in a way that makes sense for the market, for example. 

 

So when I think about integrators, I was taking notes, I can think of, for example, something that needs to have a business model. That’s a way to integrate into a product unit, for example or maybe something you can define the total cost of ownership of, and it’s another integrative function. Or maybe even more socially wise, you can think of something for which you can have a leadership show up. So you can have someone showing up and taking ownership of a certain piece of this organization. So this is something you need if you want to build a business unit or a micro enterprise, for example, in our jargon, in our 3EO Rendanheyi jargon. 

 

So again, I think this idea of integrators that are kind of a heuristics and practices that can happen after you’ve bundled the organization into the bundled context and so on, it’s a very powerful way to, and gives a lot of also kind of pragmatism to the process. 

 

It really helps you to rebundle the organization in a way that is very market-oriented and leadership-oriented and product-oriented. Does it feel interesting or right to some extent?

 

Susanne Kaiser 

Yeah, so definitely because you’re addressing the more from a product, market, business perspective. So the integrators that Neil Ford and Mark Richardson were talking about were more about like software architecture, but it can be complemented with those elements that aspect that you were mentioning. So they were talking about more from the technical or software architecture in terms of database transactions or data dependencies, but also if they are part, and that blends over to your, what you were saying, workflow and choreography. So do we have to, if it’s too small and we have to implement a high level of choreography or high level of orchestration, and maybe then put them together in one service, something like that, for example, 

 

Simone Cicero 

or a product area or something like that.

 

Susanne Kaiser

so it, yeah, or product area. So, and I guess it’s something that you can reconsider and to see where it makes sense. And it could evolve over the time as well, right? What you have unbundled yesterday, maybe you have to integrate it together again tomorrow. So and yeah, to be, to see also like how your market will change or might change and to be adaptive to, to that change, I guess that, uh, that you can also say, okay, let’s, let’s bring this together again.

 

Simone Cicero 

Where is your work going, Susanne? So based on your intense consulting work, you speak at conferences all the time. So where is your work going, you know, even beyond the publication of the book, what are the signals you’re getting for the evolution of your work?

 

Susanne Kaiser

So from the evolution of my work, I guess it goes then like what you are building up on. So for example, right now I have more the smaller focus on maybe one product in an organization or multiple products in our organization and still talk about like teams.

 

But so for example, what you’re talking about, like having this from the higher model concept derived like this, having this micro entrepreneurial team, I guess that is the next evolution I would say that is very important where you are then coming in with your services and your ideas. 

 

For example, one scenario is like the global idea in our organization, a large corporate, that would like change from control mechanism to be enabler, to have this mindset, the culture and mindset shift in an organization. I guess that is the most critical part, that’s the most hard, yeah, difficult parts in an organization to have this cultural shift, how to become. Yeah, to change the mindset from where you control a lot of things like, for example, infrastructure and your organization and how to enable them, for example, business units, like one client is organized in business units and they are struggling a lot with, okay, how to, when we introduce the new change, like how can global IT help us with that one and becoming.

 

Yeah, evolving from a bottleneck because right now it’s a bottleneck because it’s a lot of handovers involved, which requires a lot of high level of communication and coordination efforts between multiple teams to make a change effective. And to change this and becoming an enabler, so and also make like providing access to services on the one side for services that are like, for example, HR, accounting, something that every business unit needs and how to provide these services on the one side, like for example components that are more located on the right spectrum of a Wadley map in the value chain, if we derive value chain for the business units that every business units have, but also like the role of global IT like on the one side, like becoming an enabler for the components where the business units are dealing with their competitive advantage where to help them to enable them for innovation and so and have both enablers and access to service coming from the team topology terminology combined and for the future organization the future. Yeah, that is then based on autonomy and trust and where we have not only different way of working established, but also a totally different culture. Going from the restroom, cultural topologies invented by introduced by Ron, from pathological bureaucratic to the generative culture. Where we have then the teams are then working in a safe trust, trustful environment and can then drive their own decisions become totally autonomous with micro entrepreneurial mindset, I would say. That is the next evolution, I would say.

 

Simone Cicero

It’s really interesting because I feel like we are kind of witnessing the transitions that are happening in the market, which have this powerful and disruptive nature towards organizations. And these new techniques like yours or how I work with 3EO and whatever are really emerging as a way for us to figure out what’s the meaning of organizations in a digitally transformed very easy to recombine, very low transaction cost market.

 

So we were used to the bureaucracy as a way to maintain, let’s say the meaning of an organization. And now that things have changed, it’s much more easy to recombine, much more easy to interoperate, to communicate and so on. What’s the real functional meaning of the organization? And I think we are really grappling with these questions in novel ways and probably from your work and maybe from our work as well.

 

We will have a new kind of theory of organizing that fits with the dynamics and the landscape of the 21st century. So really great work. Susan, can you just share with us, maybe in the last bit, a couple of breadcrumbs that you want to leave to the audience to dig more into things that you believe are very fundamental for them to check and understand?

 

Susanne Kaiser 

I would love to share also the books that have impacted me. Diving into, for example, domain driven design, I can highly recommend, for example, Vladik Kononov has published his book. Learning domain-driven design, also Vaughan Vernon with distilling domain-driven design, implementing domain-driven design, and also Eric Evans’ Blue Bible of Domain-Driven Design. That is something I would recommend to read later because it took me four times to go through it. So it’s a good, that is the work you have to read, but I would suggest to start with the other books and then go into that book, for example.

 

Then of course team topology as you also mentioned is very highly recommended and also all the materials that they have on their website including the academy, a short video courses, online courses that you can participate in. Then of course like a Wadley mapping, so Simon Wadley has also published his book under the Creative Commons license, so it’s for free. He was so generous to publish it for free for every one of us. But also I highly recommend also going into the material that Ben Mosior, one of the award-winning advocates, has published on it’s also great material that you can dive into. And currently I’m reading several books in parallel, to be honest.

 

So I currently read about corporate rebels, which I like a lot, about micro entrepreneurial teams, also a little bit going into the Haier model. I really like that one. And so, yeah. And then the other one is sooner, safer, happier from John Smart. And yeah, so there are trying now to go also more into the product development books as well.

 

 So that is something that I am explore next, and happy to get some useful resources from you or others as well. So happy to share also your recommendation, and I’ll go receiving recommendation from you as well. So these are just like few, few bits I can highly recommend.

 

Simone Cicero 

Thank you so much. I mean, this is work that is foundational to our work as well. So it’s really good to remind our listeners to check these bodies of work that you mentioned. It’s really, really important. So I think we managed to have a very deep conversation and yeah, probably for the listeners, we will kind of have to have the disclaimer that they have to be familiar with some of the topics that we discussed.

 

But yeah, I think we really kind of broke some ground here and introduced some new ideas. So I’m really, really thankful for the conversation. I look forward to more collaborations, more sessions maybe. And there’s something also that we’re working on together with our friends, the Simon Wardley and team topologists team. So probably coming up later on for our listeners. So stay tuned.

 

And Susanne, thank you so much. I hope you also enjoyed the conversation.

 

Susanne Kaiser 

I enjoyed it a lot. Thank you so much for having me. It was a great conversation. Thank you so much.

 

Simone Cicero 

And for our listeners, as always, and this time more than usual, because there’s a lot of books and references that Susanne has mentioned during the conversation, don’t forget to check the full show notes on our blog. If you go to boundaryless.io/resources/podcast, you will find the full transcript with the links, the notes and everything. So.

 

Check it out. And until we speak again, don’t forget to think Boundaryless.