Adaptive, Socio-Technical Systems with Architecture for Flow: Wardley Maps, DDD, and Team Topologies

In a world of rapid changes and increasing uncertainties, organizations must continuously adapt and evolve to remain competitive and excel in the market. Designing for adaptability sounds easier said than done. How do you design and build systems that can evolve and thrive in the face of constant change? My suggestion is to take a holistic approach that combines different viewpoints from business strategy, software architecture, and team organization.

This article provides a high-level introduction to combining Wardley Mapping, Domain-Driven Design (DDD), and Team Topologies to design and build adaptive, socio-technical systems optimized for a fast flow of change.

This article highlights evolving an example of a legacy system of an online school solution for junior students. It describes creating a Wardley Map visualizing its business landscape and demonstrates connecting the map with DDD to discover its core domain and decompose its monolithic big ball of mud into modular components (bounded contexts). Additionally, this article covers identifying suitable team boundaries for Team Topologies’ team types leveraging the previously created Wardley Map as a foundation.

A systemic approach for optimizing organizations

Most initiatives that try to change or optimize a system are usually directed at improving parts taken separately. They tend to focus on the local optimization of separate parts of the system.

According to Dr. Russell Ackoff - one of the pioneers of system thinking - local optimization of separate parts of a system will not improve the performance of the whole. He stated that "a system is more than the sum of its parts. It’s a product of their interactions. The way parts fit together determines the performance of a system - not on how they perform taken separately." In addition, when building systems in general, we need to consider effectiveness (building the right thing) and efficiency (building the thing right).

[Click on the image to view full-size]

Figure 1 - General challenges of building systems

Building the right thing addresses questions related to effectiveness, such as how aligned our solution is to user needs. Creating meaningful value for its customers is vital for an organization's success. That involves understanding the problem and sharing a common understanding. Building the thing right focuses on efficiency, in particular, the efficiency of engineering practices. Efficiency is about utilization. It’s not only crucial to generate value but also to be able to deliver that value well. It’s about how fast we can deliver changes, how quickly and easily we can make a change effective and adapt to new circumstances. The one (building the right thing) does not go without the other (building the thing right). But as Dr. Russell Ackoff points out, "doing the wrong thing right is not nearly as good as doing the right thing wrong."

Designing organizations for adaptability

To build adaptive, socio-technical systems that can evolve and thrive in the face of constant change - with effectiveness and efficiency in mind to build the right thing right and considering the whole -  we need a holistic approach combining various perspectives. It requires understanding the context-specific business landscape in which an organization is operating and competing, including the external forces impacting the landscape, in order to design effective business strategies. It requires gaining domain knowledge and understanding the business domain to build a system that is closely aligned with the business needs and strategy. It requires aligning not only the technical solution but also aligning the teams and evolving their interactions to the system we build and the strategy we plan.

[Click on the image to view full-size]

Figure 2 - Combining Wardley Mapping, Domain-Driven Design, and Team Topologies

Or in other words: one approach to designing, building, and evolving adaptive, socio-technical systems optimized for a fast flow of change could be connecting the dots between Wardley Mapping, Domain-Driven Design (DDD), and Team Topologies as Architecture for Flow.

Using Wardley Maps to visualize the landscape

Creating a Wardley Map is a good starting point for gaining a common understanding of the business landscape in which an organization is operating and competing. A Wardley Map is part of Wardley Mapping - a business strategy framework invented by Simon Wardley. A Wardley Map visualizes the landscape and the evolution of a value chain. It provides a structured way to discuss the landscape in a group, and it helps to identify areas where an organization can innovate, improve efficiency, or outsource to gain a competitive advantage.

When creating a Wardley Map, we typically start with identifying users and their user needs - they represent the anchor of the map. The users could be customers, business partners, shareholders, internal users, etc. In an example of an online school solution for junior students, as illustrated in Figure 3, the teachers and students represent the users. The teachers would like to create course content, plan a class, and support the students during their studies. The students have the user needs of studying courses, requesting and receiving help, and receiving evaluation feedback. Both need to sign up and sign in as well. Those user needs are directly or indirectly fulfilled by a chain of components delivering value to the users representing the value chain. The teachers and students are interacting directly with an online school component. That component is most visible to the users and located at the top of the value chain. At this point, the online school component is reflecting a monolithic big ball of mud that we can decompose into smaller parts when we come to the DDD perspective.

[Click on the image to view full-size]

Figure 3 - The value chain (y-axis) of a Wardley Map

The online school component depends on other components, such as infrastructure components, e.g., data storage, search engine, message broker SMTP server, compute platform components running on top of a virtual machine component. They are less visible to the user and placed further down the value chain.

The components of a value chain are typically mapped to evolution stages, such as genesis, custom-built, product (+rental), e.g., off-the-shelf products or open-source solutions, and commodity (+utility). Each evolution stage comes with different characteristics, as Figure 4 illustrates. Towards the left spectrum of the Wardley Map, the components are changing far more frequently than components towards the right spectrum. On the left, we are dealing with a high level of uncertainty and an undefined, poorly understood market. While towards the right spectrum, the components become more stable, known, widespread, and standardized, and the markets are well-defined and mature.

[Click on the image to view full-size]

Figure 4 - Characteristics (extract) of the evolution stages

We can use these characteristics to determine the stage of evolution for the components of the value chain or our online school solution representing the current landscape - as depicted in Figure 5. The online school component is reflecting a volatile component that is changing frequently and is providing a competitive advantage. It shall go into the custom-built evolution stage. For the infrastructure components, such as search engine, data storage, message broker, etc., we are currently using open-source solutions, and the VM component is provided by a server hosting provider as an off-the-shelf product at the current state. The infrastructure components of the current state go into the product (+rental) evolution stage.

[Click on the image to view full-size]

Figure 5 - The components of a value chain mapped to evolution stages (x-axis)

This Wardley Map represents the very first iteration. A Wardley Map is not supposed to perfectly represent a landscape at precision, but provides a useful abstraction and approximation. A considerable value comes from creating a Wardley Map together with a group of people. It fosters a common understanding of the landscape among participants. Sharing the map with others allows for challenging one’s own assumptions. These conversations help to jointly discuss and understand the current and future landscape. We can use this map of the current landscape as a foundation for future discussions to evolve our system.

A Wardley Map is just one part of Wardley Mapping. In general, Wardley Mapping helps to design and evolve effective business strategies based on situational awareness and movement following a strategy cycle. Figure 6 illustrates the strategy cycle that "is a representation of change and how we need to react to it", according to Simon Wardley.

[Click on the image to view full-size]

Figure 6 - The strategy cycle of Wardley Mapping

The strategy cycle consists of five sections and starts with the purpose as the why of the business describes the reason and motivation for the organization’s existence. The landscape represents the competitive environment in which an organization operates - visualized by a Wardley Map, as already described earlier.

To anticipate changes and identify areas to innovate requires understanding the external forces impacting the landscape - described as climatic patterns. For example, one climatic pattern is that the landscape is never static but very dynamic: everything evolves through the forces of demand and supply competition. Cloud-hosted services reflect this climatic pattern. What was decades ago non-existent evolved through genesis, custom-built, became product and now commodity.   

To be able to respond to changes quickly and absorb changes gracefully, Wardley Mapping recommends applying context-independent doctrinal principles. Doctrinal principles are universal principles that each industry can apply regardless of their context. For example, the doctrinal principle of "Using appropriate methods per evolution stage" recommends building components in the genesis or custom-built evolution stage in-house using preferably agile methods, using or buying off-the-shelf products or open-source software for components in product (+rental) with preferably lean methods, or outsourcing components in commodity to utility suppliers using preferably six-sigma methods. Later in this article, we will address how to apply this doctrinal principle with DDD’s subdomain types supporting make-buy-outsource decisions.

Leadership is the last section of Wardley Mapping’s strategy cycle and is about context-specific decisions about what strategy to choose considering the landscape, climate, and doctrine. Simon Wardley provided a collection of gameplays that describe strategic actions an organization can take in terms of creating new markets, competing in established markets, protecting existing market positions, and exiting declining markets.  

Requirements for flow optimization from a team perspective

To optimize for a fast flow of change from a team perspective, we need to avoid functional silo teams with handovers. Instead, we need to aim for autonomous, cross-functional teams that are designing, developing, testing, deploying, and operating the systems they are responsible for. We need to avoid repeated handovers so that work is not handed off to another team when implementing and releasing changes. We need to use small, long-lived teams as the norm. The teams need to own the system or the subsystem they are responsible for. They need to have end-to-end responsibility to achieve fast flow. We need to reduce the teams’ cognitive load. If the teams’ cognitive load is largely exceeded, it becomes a delivery bottleneck leading to quality issues and delays. While communication within the teams is highly desired, we have to restrict ongoing high-bandwidth communication between the teams to enable fast flow (see Figure 7).

[Click on the image to view full-size]

Figure 7 - Requirements for flow optimization from a team perspective

Fundamentals of Team Topologies

And that’s where Team Topologies can help us with their well-defined team types (see Figure 8) and well-defined interaction modes (see Figure 9). Stream-aligned teams are autonomous, cross-functional teams that are aligned to a continuous stream of work focusing on a fast flow of changes. To be able to produce a steady flow of feature deliveries and to focus on a fast flow of changes, the stream-aligned teams need support from other teams, e.g., from platform teams. Platform teams support stream-aligned in delivering their work and are responsible for self-service platforms that stream-aligned teams can easily consume. Platform teams provide internal, self-service services and tools for using the platform they are responsible for. Enabling teams can be considered as internal coaches supporting stream-aligned teams to identify and acquire missing capabilities. Complicated subsystem teams - as an optional team type - support stream-aligned on particularly complicated subsystems that require specialized knowledge.

[Click on the image to view full-size]

Figure 8 - The four team types of Team Topologies

All of these team types aim to increase autonomy and reduce the cognitive load of the stream-aligned teams to enable a fast flow of change in the end.

To arrange teams into the aforementioned team types is not enough to become effective. How these teams are interacting with each other and when to change and evolve team interaction is very relevant for high organizational effectiveness.

Figure 9 illustrates the interaction modes promoted by Team Topologies. With collaboration, teams are working very closely together over a limited period of time. It is suitable for rapid discovery and innovation, e.g., when exploring new technologies. Collaboration is meant to be short-lived. X-as-a-service suits well when one team needs to use a code library, a component, an API, or a platform, that can be effectively provided by another team "as a service". It works best where predictable delivery is needed. Facilitating comes into play when one team would benefit from the active help of another team. This interaction mode is typical for enabling teams.

[Click on the image to view full-size]

Figure 9 - The three interaction modes of Team Topologies

The combination of stream-aligned teams, platform teams, enabling teams, and optional complicated subsystem teams and their interaction modes of collaboration, X-as-a-service, and facilitating promotes organizational effectiveness.

Identifying suitable streams of changes

To apply Team Topologies and optimize a system for flow, we can use the previously created Wardley Map of the online school as a foundation. Optimizing a system for a fast flow of change requires knowing where the most important changes in a system occur - the streams of changes. According to Team Topologies, the type of streams can vary from task, role, activity, geography, and customer segment oriented stream types. In the current online school example, we are focusing on activity streams represented by the user needs of our Wardley Map. The user needs of creating course content, planning classes, etc. - as depicted in Figure 10 -  are good candidates for activity-oriented stream types. They are the focus when optimizing for flow.

[Click on the image to view full-size]

Figure 10 - User needs as activity-oriented streams of changes

Partitioning the problem domain and discovering the core

The users and user needs are not only representing the anchor of our Wardley Map, but also represent the problem domain. And that’s where DDD can come in. DDD helps us to gain domain knowledge of our problem domain and to partition the problem domain into smaller parts - the subdomains. But not all subdomains are equal - some are more valuable to the business than others. We have different types of subdomains, as illustrated in Figure 11.

[Click on the image to view full-size]

Figure 11 - The subdomain types of DDD

The core domain is the essential part of our problem domain, providing competitive advantage. That is the subdomain in which we have to strategically invest the most and build software in-house. The user needs of creating course content, planning a class, learning support, and studying courses fall into the resort of the core domain. They provide a competitive advantage leading to a high level of differentiation. Buying or outsourcing the solutions of this subdomain would jeopardize the business's success, so we have to build the software for the core domain in-house.

The evaluation of student progress does not necessarily provide a competitive advantage, but it supports the teachers’ experience and is necessary for the organization to succeed. These user needs belong to a supporting subdomain - see Figure 11. The supporting subdomains help to support the core domain. They do not provide a competitive advantage but are necessary for the organization’s success and are typically prevalent in other competitors’ solutions as well. If possible, we should look out for buying off-the-shelf products or using open-source software solutions for supporting subdomains. If that is not possible and we have to custom-build the software for supporting subdomains, we should not invest heavily in that part of the system.

The user needs of signing in and signing up embody user needs of a generic subdomain. Generic subdomains are subdomains that many business systems have, such as authentication and registration. They aren’t core and provide no competitive advantage, but businesses cannot work without them. They are usually already solved by someone else. Buying off-the-shelf products or using open-source solutions, or outsourcing to utility suppliers should be applied to generic subdomains’ solutions.

The subdomain types help us to prioritize the strategic investment and support build, buy, and outsourcing decisions.

Bounded Contexts as suitable seams for decomposition and team boundaries

The solutions of the subdomains are currently all mingled together in a tightly coupled monolithic big ball of mud with a messy model and no clear boundaries. To be responsive to changes, the architecture of our online school example needs to leverage modularity with high functional cohesion and loose coupling. We need to decompose our online school component into modular components. And that’s where we come to the bounded contexts of DDD. Bounded contexts group related business behavior together and reflect boundaries where a domain model can be applied. Bounded contexts not only help to split a system apart, but also work well as ownership boundaries. Designing bounded contexts and domain models involves a close collaboration between the domain experts and development teams to gain a shared understanding of the domain. There exist different complementary techniques for designing bounded contexts and domain models, such as EventStorming, Domain Storytelling, etc.

Figure 12 depicts the bounded context of the online school example. The bounded contexts of content creation, class management, course studies, and learning support fulfil the core domain related user needs. They are strategically important and require the most development effort. They go into the custom-built evolution stage and are built in-house.

The bounded contexts of student evaluation and notification handling belong to supporting subdomains. There might exist solutions on the market already. However, the teams decided that a higher level of specialization is necessary and to build them in-house, but the development investment should not be too high.

The identity and access management bounded context belongs to a generic subdomain. There exist several solutions on the market already. It should go either into the product (+rental) or commodity (+utility) evolution stage.

[Click on the image to view full-size]

Figure 12 - The bounded contexts of the online school example

Bounded contexts not only help to split a system apart but also work well as ownership boundaries forming a unit of purpose, mastery, and autonomy. Bounded contexts are indicating suitable team boundaries for stream-aligned teams, as Figure 13 illustrates.

[Click on the image to view full-size]

Figure 13 - Bounded contexts as well-defined team boundaries for stream-aligned teams

Identifying services supporting flow of change

To be able to focus on a fast flow of change, stream-aligned teams need support from other teams. They are relying on other teams to support them in delivering their work. And that requires identifying services needed to support a reliable flow of change that can form self-service platforms which can be provided as easily consumable x-as-a-services. In general, a platform can vary in its level of abstraction. At a higher level, a platform can reflect a design system, a data platform, etc. At a lower level, a platform can abstract away infrastructure or cross-cutting capabilities. In our example of the online school, the infrastructure-related components of our Wardley Map located in the product (+rental) and commodity (+utility) evolution stage are potential candidates for forming a platform that could be effectively provided as-a-service by platform teams (see Figure 14).

[Click on the image to view full-size]

Figure 14 - Services for reliable flow of change

A possible team constellation

The previous considerations might result in this team constellation as a first draft illustrated in Figure 15. In general, most teams in an organization will be cross-functional, autonomous teams with end-to-end responsibility. To achieve clear responsibility boundaries, one bounded context shall be owned by one team only. However, one team can own multiple bounded contexts. The four core domain related bounded contexts residing in the custom-built evolution stage are going to be split among three stream-aligned teams. The supporting and generic subdomain related bounded contexts of this example are going to be handled by another stream-aligned team. The infrastructure components will be taken care of by one or multiple platform teams.

[Click on the image to view full-size]

Figure 15 - The first draft of a possible team constellation

The platform teams could provide a variety of platforms to fulfil the user needs of stream-aligned teams. That could be visualized in a different Wardley Map where the stream-aligned teams become the internal users addressing their user needs. From there, we can continue with identifying and bridging capabilities gaps, where enabling teams can come in.  

You can start small

You do not need to learn and know Wardley Mapping, Domain-Driven Design, and Team Topologies in detail before applying and combining them. You can start with the parts that are most useful for your context. You could start by creating a Wardley Map in a group together to generate a shared understanding of your competitive landscape. A significant value comes already from the conversations when creating and sharing the map with others and challenging your own assumptions. You could use the map as a structured way to guide and continue future conversations, e.g., identifying suitable streams of change and team boundaries, as illustrated in this article.

You can also think of starting with your teams and analyzing their current cognitive load and delivery bottlenecks. Are they dealing with repeated handover and high levels of communication and coordination efforts, blocking dependencies, lack of ownership boundaries, high team cognitive load, etc.? The conversation could lead to alignment to streams and identifying suitable team boundaries, decomposing the system, etc.

Alternatively, you might want to start with your current software architecture and assess its responsiveness to change, e.g., by analyzing what parts are entangled in a specific change and how these entangled parts are coupled. That might bring the conversation towards identifying suitable seams for modularization, where DDD can help with subdomains and bounded contexts. At some point, the paths of each individual starting point eventually cross, leading to Architecture for Flow. This is just one approach to designing and building adaptive socio-technical systems. In addition, you can complement optimizing your system for a fast flow of change with additional techniques and frameworks, e.g., value stream mapping, independent service heuristics, Cynefin, and many more.