Susanne Kaiser - Optimizing for a fast flow of value with adaptive, socio-technical systems

[00:00:00] Oh, I guess that's the sign. The lights are going on. Hello everyone. Hopefully you have enjoyed your lunch. very delicious by the way. I ate too many sweets. So, uh, welcome to this talk about optimizing for fast flow of value with adaptive socio-technical systems. And I have to give you a little warning.
[00:00:28] So, uh, I have the tendency to cover a lot of content during my talks, but I will provide, um, a link to my slide deck at the end of my presentation. And second, I also am about writing a book about this topic, so in case you're interested to explore more.
[00:00:50] So, when building systems in general, we are facing the challenge between building the right thing and building the thing right. And building the right thing that addresses effectiveness and addresses questions such as, how aligned is our solution to our user needs? Or, um, are we creating value for our customers? Have we understood the problem and do we share a common understanding?
[00:01:13] And building the thing right on the other hand, that focuses on efficiency, for example, efficiency on engineering practices, and also it's not only crucial to generate value for our customers, but also being able to deliver that value to our customers, and how fast can we deliver changes and how fast and easy can we change and adapt to new circumstances.
[00:01:35] And one does not go without the other, but as Dr. Russell Eckhoff, one of the pioneers of the system thinking movement stated, doing the wrong thing right is not nearly as good as doing the right thing wrong, or as John Cutler summarizes, crap delivered quickly is still crap. And still, unless you're learning from it and you can act on that learning.
[00:02:00] So to build the right thing right, we need to build adaptive social-technical systems that are optimized for fast flow of value and fast and constant feedback. And one approach that I would like to share with you today that can help with building, designing, evolving adaptive socio-technical systems is combiningly mapping domain-driven design and team topologies as architecture for flow.
[00:02:26] And we can start with creating a wardley map that is visualizing the business landscape in which an organization is operating and competing in. And, um, a wardley map itself is part of wardley mapping a business strategy framework invented by Simon Wardley. So who of you have heard of Wardley mapping before? Oh yeah, quite hands I would say 75%. Um usually when I started giving talks about Wardley mapping maybe two, three hands were up. So in a Wardley map itself, that's part of Wardley mapping, it emphasize, um, to start with the users first.
[00:03:06] And starting from the user's perspective, that aligns very well with the goal of building the right thing. Clayton Christensen, the inventor of the innovation dilemma and also the inventor of the job to be done theory, he stated that people buy products and services to get a job done. So in order to help users to get their job done, we have to know, we need to know who our users are and what jobs they want to accomplish. So we need to identify, um, the desired outcomes as the user needs that they, that our users try to achieve when getting a job done. And the jobs to be done and the user needs, they describe the problem space, and will stay the same regardless of what kind of solution and solution space we we provide.
[00:04:04] So let's use an example of an online school solution for junior students. And the users of the online school solution are typically teachers and students. And let's keep it simple and let's focus on the teachers only. And, uh, the core functional job of teachers is to, um, uh, facilitate remote learning in an online school context. And to accomplish this job, the teachers need to prepare learning material, or, um, assess the students' understanding with assessment tests, quizzes, and so on. Or, um, track the students' progress over time, um, facilitate communication with the students and also ensuring and setting up secure access to the, um, learning platform. For example, through sign up and, uh, sign in mechanisms.
[00:05:00] And when we switch to the solution space, um, those users are directly or indirectly fulfilled by a chain of components that generate value for our users by satisfying our user needs. And that's where we can blend in then the value chain, um, the Y-axis of a Wardley map, where the users and user needs are becoming then the anchor of our map.
[00:05:28] And deriving this value chain that helps us to ensure that we are addressing the right problem and that we create value that is very closely aligned to our user needs. And this value chain shows like how different components connect in order to generate value and also visualize the dependencies of those components in our value chain. And we can start creating this value chain, we can start very simple and iterate later.
[00:05:56] So in the example of the online school solution, the teachers are directly interacting with an online school component, and it's most valuable, most visible to the teachers and it's located at the top of our value chain. And this online school component is depending on other components, for example, depending on foundational infrastructure components, and which are less visible to the teachers, less visible to the users, and are positioned or residing lower at the bottom of our value chain.
[00:06:34] And the components of our value chain are typically mapped along the evolution axis on the X-axis of our Wardley map going from left to right. So, for example, on the left with Genesis with brand new things, then custom built, then product and rental such as off-the-shelf products or open source software solutions, and commodity and utility at the right. And each evolution stage come with different characteristics. So towards the left spectrum of our Wardley map, um, the components are changing far more frequently than components on the right spectrum of our Wardley map towards commodity and utility.
[00:07:13] So on the left towards Genesis, we are dealing with high level of uncertainties, unknown unknowns and an undefined, poorly understood market. While on the right spectrum, the components become more standardized, stable, known, widespread, industrialized and the markets are typically well defined and mature.
[00:07:36] And in general, the the water map helps us to create a common understanding of our business landscape, um, and, um, while we create this water map together in a group and also try, um, also challenge our own assumption of our own business landscape. And it helps to identify areas where to invest, where to innovate, what to evolve or to outsource to gain competitive advantage.
[00:08:02] But we can also use the Wardley map, um, to assess our current flow of change. So to now switching from building the right thing, now we switch to building the thing right, and for to build this thing right, we need to optimize for fast flow of change. And for that purpose, we can go along the dependencies in our value chain and analyze how a change would flow through our system. For example, when introducing a functional change, we can analyze what components in our value chain are going to be affected following the dependencies in our value chain.
[00:08:45] And then we can also ask questions: so what team do own these components that are involved in this change? And how do these teams depend on each other and need to communicate and coordinate with each other in order to make this change effective?
[00:09:03] So, um, by evaluating how a change will flow through our system, we can also reveal potential blockers to flow. For example, by analyzing what is preventing our flow to change, um, along the value chain from various perspectives. So we can, for example, consider our architecture perspective. So from an architecture point of view, we need to analyze how the parts are coupled, uh how the parts are coupled together. So in our example of the online school, um, uh, the online school component itself has evolved over the over the time and became a monolithic big ball of mud with a messy model and no clear modular boundaries.
[00:09:50] And, um, which leads then to to tight change coupling, and with tight change coupling, uh, that is affecting or impeding our flow of change, so as changes in one part of our system, that can have unpredictable side effects on other parts of the system, which then increases the risk of breaking changes or, um, and also introducing delays.
[00:10:17] The next perspective we can bring in is the, um, uh, team ownership perspective. So, and a messy model with blurry and fuzzy boundaries, um, that makes it difficult to establish clear ownership boundaries, which leads to lack of ownership of or clear ownership, which decreases accountability. And also which potentially leads to a not my job syndrome. And that can also cause decision delays and also impeding our fast flow of change.
[00:10:52] And with, uh, business logic mingled together in a messy model with no clear modularity, that increases also to the our mental effort to understand a piece of code, including also grasping or understanding the dependencies in a large, very intertwined, very connected system.
[00:11:18] And when teams own too many or too large intertwined or too many dependent parts, coupled parts, um, their team's cognitive load can exceed, and if the team cognitive load is largely exceeded, it also can become a delivery bottleneck.
[00:11:38] And we also need to analyze, um, where the our team dependencies, so where do teams depend on other teams' activities and tasks, um, to to get their work completed. So, for example, do the teams need to repeatedly hand over work to other teams at a later stage of flow to get the work completed? So, the teams in our online school solution, they are currently organized as functional silo teams.
[00:12:08] So implementing and releasing changes from front end to back end, that requires to hand over changes between the UI, back end, and, uh, the infrastructure teams. So, but hand over itself, that requires a high level of communication and coordination efforts between multiple teams, which is also affecting and impeding our flow of change.
[00:12:30] And if teams are missing capabilities and needs to and if they need to bring in people from the outside with a particular expertise in order to that they do something to get our work completed, that can also impede the flow of change. And particularly when those people are not available when we need them.
[00:12:54] And also teams depend on decisions from others, for example, from management or, um, or if we need to wait for approval, that can also, um, so that also can hinder us from progressing and completing our work. So and every dependencies that require a kind of a level of communication and coordination efforts and increases also the probabilities of delays. And particularly when the people that we need are not available, or when the or when other teams that we rely on cannot keep up with the demands placed on them, so they then this other team become a constraint, and then it's also slowing down the overall performance.
[00:13:38] So, if teams have to interact with many other teams in order to get their work completed, that is slowing down our flow of value.
[00:13:50] Another aspect, um, that we need to consider to build the thing right is to assess our efficiency gaps. So if the evolution stage of components that we use in our organization internally differ from equivalent ones that are available in the market with a higher evolution, that might indicate an efficiency gap. So for example, um, are we custom building components that do not belong to our core domain where equivalent ones may be available as off-the-shelf products or utility? Or are we using components in our organization as off-the-shelf products, but equivalent ones are available as commodity or utility, for example, the on-premise infrastructure example versus using cloud hosted services? Um this could indicate that we might lack behind in terms of efficiency, and especially that comes becomes important when our competitors are building up their products on top of value chains that are using better evolved components than we are.
[00:15:04] So after we have identified blockers to flow and inefficiencies, one approach is to leverage modularity with high functional cohesion and loose coupling by designing a modular, well encapsulated, loosely coupled system.
[00:15:18] And we can use the Wardley map as a visual tool tool that steers us through the optimization. And to optimize for flow of change, we need to first analyze what will drive value and what will drive change in our organization. So that requires to identify the most important changes in our where the most important changes in our system occur, the streams of changes. And, um, the user needs of our Wardley map, they are representing good candidates of customer-driven activity or task-oriented streams of changes. So we need to structure our teams in this in the system in the interaction around the customer-driven stream of changes, ensuring a fast flow of value where it matters most.
[00:16:05] And the user and the user needs not only represent the anchor of our Wardley map, but also represent the problem domain.
[00:16:13] And that's where we can bring in domain-driven design. So domain-driven design helps us to gain a shared understanding of our problem domain and helps us to partition our problem domain into smaller parts, the subdomains.
[00:16:27] But not all subdomains are equal, some are more valuable to the business than others. We have different types of subdomains. So, um, the core domain, that is the essential part of our organization providing competitive advantage, that is a subdomain that we have to strategically invest in most, and and that's the one that we have to build in house.
[00:16:49] And the supporting subdomains, they help to support the core domain and they are complementing the core domain's offering. So they do not provide competitive advantage, but are necessary for the organization to succeed. And, uh, and they are typically prevalent in other competitive solutions as well.
[00:17:08] So if possible, we should look out for, um, buying off-the-shelf products or using open source software solutions for the supporting subdomains, and if this is not possible, if we, uh, have to custom build the support supporting subdomains, we should consider, uh, not to invest heavily in that part of the system because it does not provide competitive advantage.
[00:17:29] And the generic subdomains, these are subdomains that many business systems have, not only our competitors, but, uh, which is widespread in every large business system or online business system. So they are core, they provide no competitive advantage, but businesses can't work without them. So buying or, um, using off-the-shelf products or outsourcing to utility suppliers, that should be applied to the generic subdomains. For example, for authentication and registration, that is a good candidate for generic subdomains.
[00:18:04] So, uh, in general, the subdomain types, they help us, um, to focus our strategic investment and support us with build, buy and outsource decisions.
[00:18:18] So we have discovered our subdomain types and get an understanding where we should focus our development efforts. But when we switch to the solution space, um, the solution of our subdomains are currently solved or currently all mingled together in one monolithic big ball of mud with a messy model and no clear boundaries, modular boundaries. Which is causing then tight change coupling, as we said earlier, lack of clear ownership, high team cognitive load and an inefficient focus of development efforts of non-differentiating parts that are in total blocking our flow of value.
[00:19:01] To mitigate the blockers to flow and inefficiencies, one approach is to leverage modularity with high functional cohesion and loose coupling by designing a modular, well encapsulated, loosely coupled system.
[00:19:18] And that's is where, uh, we need to decompose our online school component into modular components, and that brings us to, um, the bounded contexts of domain-driven design.
[00:19:33] A bounded context in general groups related behavior together, groups behavior, um, domain logic together. And a bounded context defines where a single domain model can be applied that encapsulates particular business logic of a specific part of our system. to leverage modularity with high functional cohesion and loose coupling by designing a modular, um, well encapsulated, loosely coupled system. And that's is where, uh, we need to decompose our online school component into modular components.
[00:19:24] And that brings us to the bounded context of domain driven design. A bounded context in in general groups related behavior together, groups behavior, um, um domain logic together. And the bounded context defines where a single domain model can be applied and that encapsulate particular business logic of a specific part of our system. And a bounded context itself or bounded context in general, they are enforcing high cohesion and modularity, and they are indicating good domain logic specific themes to split our system apart into smaller parts. Um, and and they are then well encapsulated and modular.
[00:20:11] And they also serve very well as ownership boundaries, and we come to that one when we address the team perspective.
[00:20:20] So, and so to design bounded context and domain models, that usually involves a close collaboration between domain experts and development teams in order to gain a shared understanding of our problem domain. And there exist several techniques, for example, to to design these domain models and this bounded context, for example, event storming, domain storytelling. Example mapping, user story mapping and more. And the inventor of event storming also gives a talk Alberto Brandolini today, not about event storming, but he has invented the event storming model like modeling technique.
[00:20:56] Um, now at this stage with discovered sub-domain types and modular bounded context, we can then better target our strategic investment. And center, we can then center our major development efforts around our core domain related bounded context that provide competitive advantage and in order to build them also in house.
[00:21:24] And for the non-differentiators, um, so we need to evaluate whether we can leverage them with existing solutions in the market. So the generic sub-domain related bounded context, for example, of identity and access, they do not provide competitive advantage, but they entail a common standardized widespread processes and functionality that require little to no variation or customization. So there we can leverage existing off-the-shelf or open-source or utility services solutions that are available in the market.
[00:22:03] And for the supporting sub-domain related bounded context, the decision whether to build or buy is a little bit more nuanced. So they are not core, they provide no competitive advantage, but they play a significant role in supporting the core domain related bounded context. So, maybe for in our example, for our supporting sub-domain related bounded context, there might exist products in the market, but the the current analysis, um, result in that they fell short in in solving our our needs. And so they require a high amount, a higher level of customization, and so that building a custom solution can be justified in these cases, rather where the development and maintenance cost is lower than the integration cost with existing products, which requires, for example, a significant amount of adjustments.
[00:23:04] The next aspect to consider is, um, whether we can leverage better evolved components that currently, that we currently use in our organization and that would help to increase our efficiency.
[00:23:18] In our example, we could decide to migrate our on-premise infrastructure components to cloud-hosted services which are available as commodities in order to close our identified efficiency gaps.
[00:23:34] So far, we have unlocked some blockers to flow that are related to software architecture and efficiency gaps. And but we also need to consider the socio-technical aspect of our system and where we also need to bring in then the team perspective and the team ownership and the interaction between multiple teams. And that's where team topologies can help us with. So who has read the book from team or heard of team topologies before? From Michael Skelton and Mr. Skelton Manuel Pash, yeah. So a few I guess a lot of hands were going up, that's awesome. So, team topologies, um, provide well-defined team types and well-defined interaction types and interaction modes. The one team type are the cross-functional autonomous teams that are aligned to a continuous stream of work focusing on a fast flow of change. But to be able to produce a steady flow of feature delivery, to be able to focus on a fast flow of change, the streamline teams, they need to support, need to get the support from other teams, for example, from the platform teams.
[00:24:41] And the platform teams, they support the streamline teams delivering their work and they are responsible for platforms that the streamline teams can easily consume.
[00:24:51] And the platform can vary in its level of abstraction, so at a lower level, a platform can abstract away infrastructure, networking, cross-cutting capabilities, and at a higher level, a platform can also abstract away a design system, data platform and so on. So the platform teams, they provide internal self-service services and tools for using that platform they are responsible for.
[00:25:17] Or the enabling teams can get support from sorry, the stream line teams can get support from the enabling team, which work then facilitate the the um, um streamline teams as internal coaches and mentors, so and they help to identify and acquire messy capabilities, help to upskill the streamline teams.
[00:25:38] Or the streamline teams can get support from complicated subsystem teams as an optional team type, and they are supporting streamline teams on a particular complicated subsystem that requires very specialized knowledge.
[00:25:55] And all these team types, they are aiming for increasing the autonomy and reducing the cognitive load of the streamline teams so that then the overarching goal is to enable a fast flow of change in the end.
[00:26:11] But to arrange these teams in these team types is not enough to become effective, so how these teams are interacting with each other and when to change and evolve the the interaction mode between teams is also very important for organizational effectiveness. So and there team topology provides three different interaction modes, so with collaboration. Team teams are working very closely together over a limited period of time, and they are suitable for rapid discovery and innovation, for example, when exploring new technologies together. And um, but the collaboration itself is meant to be short-lived. Excess as a service that suits well when one team needs to use a code library or component, um, an API or a platform that can be effectively provided by another team as a service. And it works best where predictable delivery is needed. Facilitation, this interaction mode, um, comes into play when one team would benefit from active help from another team and this interaction mode is very typical for enabling teams.
[00:27:21] So, coming back to our map, um, the next step would be then when we switch to this to team perspective, the next step would be finding suitable team boundaries that are aligned to customer facing continuous streams of changes. And as I mentioned earlier, the bounded context serve as very well-defined ownership boundaries and that makes the bounded context then as suitable candidates, um, besides splitting a system into smaller parts, but they can also serve very well as good, well-defined ownership boundaries for streamline teams.
[00:27:58] So to, coming back to our blockers to flow, to mitigate or to reduce our previously identified blockers to flow that relates to team ownership, we need to optimize our team cognitive load. And to optimize our team cognitive load, we have to limit the number, size, complexity of software system, a single team has to work with. And that brings us back to the evolution stages of, uh, of a water map. So according to the characteristics that I have introduced in the beginning, the evolution stages, um, um, the further left a bounded context or component is located, for example, towards Genesis and custom build, um, um, the higher the level of uncertainty is. And um, and which then, the higher the level of uncertainty is, then requires practices that are focusing more on exploration and discovery. And components in in Genesis tend to change far more frequently than components in in commodity on the right. For components in commodity, we can draw on best practices providing a clear path to action. And if each evolution stage itself adjusts different practices for the related path to action ranging from best, good, emerging, and other practices.
[00:29:18] And as a heuristic, the more unclear the path to action is, the higher the level of team cognitive load might be. And that means that a single team could take ownership of more or larger bounded contexts residing in on the right, on commodity and utility then residing on the left in Genesis.
[00:29:41] And another aspect of optimizing for team cognitive load is to establish clear responsibility boundaries.
[00:29:49] For clear responsibility boundaries, we need to assign each bounded context to a single team only and not sharing bounded context across multiple teams because that would diffuse the ownership of teams and also lead to the not my job syndrome. However, one team can own several bounded context on the other way around it's possible.
[00:30:11] And to be able to focus on a fast flow of change, the uh, streamline teams are relying on other teams, as I mentioned earlier, to support them delivering the work so that the streamline teams are able to focus on their fast flow of changes. And um, so they are relying, for example, on platform teams providing platforms that the streamline teams can then easily consume and to reduce their cognitive load. And this requires to identify services that support a reliable flow of change and can be easily consumed by the streamline team providing self-service capabilities. So in our example, um, the infrastructure components related bounded context of our map residing in commodity and utility, that could, that could be good candidates that are suitable for forming a platform that can be effectively provided as a service by platform teams. And providing self-service capabilities that aims to make the cross-functional teams that consumes those those services,
[00:31:21] um, that makes them self-sufficient that eliminates the blocking dependencies of hand over.
[00:31:29] And also decreasing, uh, the corresponding high amount of communication and coordination efforts between teams.
[00:31:43] And when, um, when talking about team dependencies and ownership, we can also then create another map or another value chain. So we can now switch from currently we have addressed the external product view from our external users, our customers, our teachers. And now we can also to create a map for our internal products and to consider our platform as internal products that our internal teams are consuming and using. So, and when switching to the internal product view, we are can drive a platform value chain. That makes then the streamline teams becoming the users of the services that the platform team provide. And the streamline teams, they also have user needs, so they have the user needs of provision and managing infrastructure, they have the user needs of building and testing, releasing and deploying, operating and monitoring, um, um, services or bounded contexts they are responsible for. And to fulfill the user needs of the streamline teams, uh, the platform teams can provide a variety of platforms that the streamline teams can then easily consume as X as a services.
[00:32:59] For example, um, um, the stream line teams need infrastructure platform that allows them to provision and manage the infrastructure on demand and also spanning from from compute components, storage networking security components that can be provided by platform teams as X as a service. And in general, the platform can start small, it does not have to be a fully digital platform at the beginning. It can start with documentation or standards, best practices, templates and can evolve later into a digital platform with self-service APIs and uh, tools.
[00:33:41] And build and release platform supports then the streamline teams to build, test, deploy and release their services or bounded context. And can can be also built on top of various other components such as version control system, build server, CI CD pipeline, test automation and so on.
[00:34:01] And a platform as I said earlier can vary in its level of abstraction. And at a higher level, a platform can also reflect a design system, in order to, for example, to achieve a consistent well-defined visual language at scale. And the platform team owning this design system, they can, for example, then provide style guides, widget libraries, design, um, design principles as a service.
[00:34:31] And to operate and monitor services, the streamline teams might require dashboards, alerting mechanisms, uh, incident management, observability capabilities, lack management and so and so forth, so these capabilities can be provided by a platform team as operating and monitoring platform.
[00:34:54] Another aspect that we have to consider to optimize for flow is to identify and close capability gaps, and that's where the enabling teams can come in.
[00:35:04] So the cross-functional streamline teams need to cover a wide range of capabilities such as software design and architecture, um, um application security, um, user experience and accessibility, testing QA and also software development of course. And that is a lot to cover and where the specialists of an enabling team can then also can be pulled in on demand and upskill the streamline teams to make them self-sufficient in regards their skill levels at the end. But also enabling teams can facilitate platform teams, they can also upskill platform teams, for example, by coaching them about what is important to achieve a great developer experience or how to design a scalable, reliable and secure platform. Plus, the enabling teams can coach the streamline teams and the platform teams about, um, skills that are related to product management, effective communication, good documentation, improvement of processes, mentoring, coaching and so on. So enabling teams, um, facilitating as internal mentors and coaches and help to upskill the other teams on missing capabilities.
[00:36:23] And so that the other teams then become self-sufficient, which unlocks then the dependencies on people with a particular expertise to do something before the teams can complete their work.
[00:36:37] And enabling teams also blend beautifully into the concepts of uh, learning organizations. And so learning organizations, they embrace continuous shared learning experimentation. And continuous learning and experimentation are crucial to adaptability to be able to respond to complex situation with a lot of unknown unknowns. So in the context of architecture for flow, um, continuous shared learning and experimentation, that is supported by enabling teams that aim to identify and close capability gaps of the other teams, helping them to learn missing skills and to make them self-sufficient. Um, or another aspect is the short-lived collaboration between teams that is emphasized by team topologies to explore and rapidly discover uncharted domains. Um, or by the close collaboration between domain experts and development teams from the domain-driven design perspective in order to create a common understanding, a shared understanding of the problem domain and in order to align the software design to the business domain. And this can also be complemented with other team learning methods, for example, with establishing a community of practice in order to exchange, um, knowledge and develop expertise on a regular basis.
[00:38:02] But you also need to consider, um, that not only our skill set and capabilities are relevant, but also, um, that our preferences and mindsets of the team members is also crucial important when composing teams. So when composing teams, Simonley suggests to think aptitude and attitude. Which means that not only the skill set, uh, the aptitude is is relevant for team members, but also their mindset, their attitude. So, and dealing with components in different evolution stages, that require different mindsets. And Simonley he introduced, um, uh, the mindset of explorer, villagers and town planners mindset, which are formally, were formally known as uh, pioneer settlers and town planners. And my take here is that, um, there should exist a mix of mindset in each team and depending on the evolution stage that the specific team is owning, one mindset might be more prevalent than prevalent, more existing than dominating than other mindsets, for example. Teams owning components in Genesis or custom build, they might tend, they might tend towards an explorer mindset with a preference of discovering and experimenting, so they are very fine with failure and experimenting new and unknowns and uncharted domains. formally were formally known as uh pioneer settlers and town planners. And my take here is that um there should exist a mix of mindset in each team and depending on the evolution stage that the specific team is owning, um one mindset might be more prevalent than prevalent, more existing than dominating than other mindsets. For example, teams owning components in Genesis or custom build, they might uh tend they might tend towards an explorer mindset with a preference of uh discovering and experimenting, so they are very fine with failure and experimenting new and unknowns and uncharted domains. And teams owning components in product rental, they might to rather improve and stabilize with a villager mindset. And teams owning uh components uh in commodity and utility, they might prefer to mature and optimize with a town planner mindset. So this mix of mindsets uh in each team allows teams to respond in different ways to different situation. So a team owning commodity components can also switch to exploration modes using agile techniques and closely collaborate with other teams um for a limited period of time, for example, when exploring new technology, for example, when transitioning from on-premise infrastructure to cloud-hosted services where they have no prior knowledge. Coming back to our um blockers to flow. So far, uh this architecture for flow approach that helps us to um identify and unlock um a variety of blockers to flow in theory.
[00:40:45] But now the question is how to put it into practice and how to transition into the designed architecture for flow that we that we have um yeah designed for. And one approach is to transition with a team first approach, following a reverse Conway maneuver. And Conway's law uh states that um an that organizations, they design systems that are copying their communication structure, so the system design is a copy of their communication structure. And the reverse Conway maneuver suggests that we should first restructure our organization in order to achieve to achieve a desired architecture at the end. And we are going to apply this reverse Conway maneuver through incremental uh dynamic re-teaming and small steps involving um the team interaction along this transition.
[00:41:50] So optimizing our system for fast flow of change is in this case led by dynamically reteaming um the functional silo teams into platform and streamline teams step by step incrementally.
[00:42:03] And we are evolving their interaction along a cloud migration journey, so um and this transition could start with forming the platform team first that kicks off the replatforming cloud migration journey. And with replatforming uh from the cloud migration journey perspective, the on-premise infrastructure components, they are going to be incrementally replaced um by um by cloud-hosted services while we keep the existing application architecture the same. So we are only uh replacing the underlying infrastructure during the replatforming cloud migration journey. And when we have um replatformed our infrastructure components to cloud-hosted services after time, then uh the the first streamline team can form and the streamline team then can take care of starting to refactor the application. And with refactoring in this uh context, in the cloud migration context, we are splitting the existing application architecture into smaller parts and that's where we can use the previously designed bounded contexts um um as a as a basis.
[00:43:18] And the refactoring journey supported by an evolution of team typologies interaction modes. So the first form of streamline teams that can closely collaborate with the first form platform team at the beginning in order to assess potential cloud options that uh um that can that are applicable for the future bounded context that the future streamline teams is going to be responsible for. And this close collaboration then can evolve later into to limited collaboration on demand and then eventually become ex as a service where then the platform team provides best practices or standards, tools, APIs that uh in order to easily consume cloud services. And then the next streamline team can form and refactor their bounded context and they get then support during their refactoring journey from the previous platform and from the previous streamline teams where they are facilitating the new streamline teams, sharing knowledge and coaching them along their refactoring journey. And then the next streamline team uh can form and they get also support from the other teams sharing their knowledge and coaching um their best practices that they have applied.
[00:44:40] So that in the end we were able to resolve our blockers to flow by um an incremental um team first approach um uh through dynamic reteaming and an evolution of team interaction modes um um evolving the team interaction along a cloud migration journey path. So that as a summary, the combination of what mapping domain-driven design and team typologies helps us to generate a sustainable value aligned to user needs. Helps to unlock blockers to flow and focus our development investment on our differentiator providing competitive advantage. It helps us to close potential efficiency gaps and aligning our teams and evolving their interaction to the system we build and the strategy we plan. And also establish a learning organization that embrace continuous shared learning and experimentation in order to able to respond also to to complex situation with unknown unknowns and uncharted domain. So this combination provides a powerful tool set to design, um evolve, build adaptive socio-technical systems that are um optimized for fast flow of sustainable value for our users. and fast and constant feedback that can thrive then in the face of rapid changes in order to build the right thing right at the end.
[00:46:13] And it's also that we when we are able to to have optimized our system for fast flow of value and fast and constant feedback, we can also look ahead. Then we are now in a position that we are not only able to respond to changes introduced by others, but also can lead future changes introduced by us. So that's where we then um can can apply effective business strategy actions in terms of like, for example, creating additional differentiating values in order to increase our competitive advantage or being the first mover to commoditize components that other can innovate on or by building cooperation alliances with others in order to accelerate the evolution of components and grow our ecosystem. So now we are in the driving seat of change.
[00:47:03] And if you are interested in some more details, so there are different resources that I collected, they are far more, but it's just a small extract. And as I mentioned earlier, um I am writing a book about this topic, still, to be honest, and um. I thank you so much for your attention and she has this link to the slide that you can use if you would like to download it. Thanks a lot.
[00:47:31] Do you have any questions that you would like?
[00:47:45] Uh, thank you what. Uh, that's uh, a whole lot of interesting stuff. Uh, you mentioned about uh, I don't know if you mentioned it, but something you said was about core domains, or close to it.
[00:47:59] I'm sorry, say it again.
[00:48:02] Uh, about core domain and core domain, that made me think of core domain charts and um, the question is, um, there are probably a balance in the size of the team between streamline, platform, enabling team, what what's the balance in number of people, obviously, uh that that the sweet spot in your opinion?
[00:48:20] Yeah, so um it depends on your context of course, and of your core domain related bounded context, but I usually try to like in terms of like how many team members are in in this teams that own core domain related bounded context, for example, depends really on the complexity level and also on the change rate, for example, and uh um to to figure out like who which which team can own what bounded context and also uh how big the teams are, so there's a recommendation from team topologies in terms of to to um focus on small, long-lived stable teams and this they recommend a team size of five to nine people. And uh usually I would say that it depends on the complexity of your core domain is that sometimes one team can own one core domain related bounded context, sometimes it depends also like maybe more than one core domain related bounded context, it depends really on the complexity and the change rate that's that's involved in that uh bounded context itself. On the other side, like the less complex or the less uh let's say like for supporting generic subdomains, then the teams can own at least, yeah, more than two or three bounded contexts depending on the size um and the complexity of of the other subdomains that they are um owning.
[00:49:47] Thank you, I have a question.
[00:49:49] here I'm standing. Yeah, here. Yes.
[00:49:50] Thanks for your talk. Um so you had a picture where you had like components or parts of the system and the teams and there were arrows, like teams would own that code, right? And I think you would make sure uh there were no component which is owned by more than one team, somehow. So what happened to the idea of collective code ownership that was famous 20 years ago in the extreme programming community?
[00:50:23] Yeah, so um as I said earlier that um shared ownership is is sometimes a challenge in terms of like um that you um that you diffuse the ownership of a specific part of the system. And um and specifically if no one feels responsible to take action, for example, when a bug is introduced or something like that, so that it's leads to job, not my job syndrome. And so there in some areas you have shared services and uh at the beginning you might not find um a clear ownership to that specific part of the shared part. And then you can, for example, introduce um uh so I would recommend to that at least one team is responsible for a shared service, but others can, for example, with um in source like development, uh instead of open source, can also um add uh um yeah change request to that specific bounded context. For example, if other teams need a specific system to be to be changed. So I would highly recommend not to share services, but um on the other side, you can of course, you can still um apply mechanisms such as uh uh mob or on some programming to to to work together, collaborate together in order to to build a system.
[00:51:48] Clarify, so, thank you. just to clarify, are you guys promoting private code ownership versus collective code ownership these days?
[00:51:58] private code ownership, yes.
[00:52:00] Interesting.
[00:52:00] But it can also be um could also be uh um. Of course you can also say, um, so the shared services themselves, they should, um, mostly, so the tendencies or the the aim is not that the shared services are not changing that that often. So that you have stable services that you share. The moment where you see that shared services is is is changing a lot, maybe that it's not the right seems to split or to to to create a shared service, maybe there's domain logic involved that should not belong into a shared service. And um and that maybe it belongs to to to another team, but for example, the moment you share something, you can consider, is it something that other teams can use, consume as excess a service, and where then more the platform idea comes into place where a platform team provides internal service to other teams.
[00:53:05] Thank you. Uh in term of uh leading the change, uh do you have a recommendation about the time it should take to switch from one state to the other?
[00:53:24] Um, do you mean to to dynamically re-team your organization or how long it might take? So yeah, it um it depends of course on your um on how big your system itself in general is and how tightly coupled it is. So um but I recommend so it also depends on the context, I would then try to do a trade-off analysis with pros and cons, starting, for example, with small uh um. parts first, where you can move on quickly and then within maybe a month or something like that. Or that and then later on pull in other teams into that aspect. But what I've seen that the the velocity of moving forward and the is correlated to a successful transition. Um so and specifically um buy-in from both sides, also from management uh and and and that one. But in terms of of um time aspect, um it's also like some maybe some bounded context you can't decompose, for example, I was not talking about microservices or something like that, because it could also maybe at some point you will leave some parts in your monolithic big ball of mud. But refactor it, so it's more modular, but it remains, stays in that monolith, so that's also still an option that you at some point you are not. carving out everything into a separate independent, for example, microservice or something like that. So and there's a kind of like at the beginning you're faster than when reaching the point where you can't really decompose uh very interdependent intertwine part of the system then it's slowing down. And um so I would suggest like the faster you can go at the beginning, uh it's correlating to the success in the end.
[00:55:16] Thank you.
[00:55:17] Thank you.
[00:55:21] We are good. Okay. Thank you so much, and I'm around, so please ask other questions. Thank you.

Transcript