How companies move during changes can determine their success, but also nurture eventual failure. In this episode, we will explore how Software Consultant Susanne Kaiser uses Wardley mapping and Domain-Driven Design to identify the core domain of businesses and apply the appropriate method per evolution stage, how to improve team organization, and how evolution changes teams.
Edited transcription
Susanne Kaiser’s diverse experience in the software development industry —she has worked as a software developer, software engineer, team lead, and startup CTO— has equipped her with a comprehensive understanding of the software development lifecycle. Besides, it allows her to take on diverse responsibilities and roles as a consultant; given her coding background, she refers to herself as a “coding software architect.”
Wardley mapping to determine business strategy
Wardley mapping is an invaluable asset in Susanne’s consulting toolbox. Using Wardley maps we can visualize, from left to right, the evolution of the components of a business over time, from the unstable beginning to more stable, standardized components, typically categorized into four stages: genesis, custom-built, product, and commodity: Genesis components are novel and new, custom-built are specifically created for a particular use case, product components are standardized and widely available, and commodity components are ubiquitous and often provided as a utility.
By analyzing their own Wardley map, organizations can identify which components are —and are not— critical to their business. Wardley maps help organizations to focus on innovation in the areas that matter the most given the value they provide and let them know where to use standardized and commoditized components where possible to reduce costs. Note: For more information about Wardley mapping, check our conversation with Simon Wardley, its creator.
Even though Susanne initially struggled to figure out how Wardley mapping could be useful in her work, she later realized that she could create Wardley maps of the value chain from users, user needs, the components that fulfill those needs, and the evolution stages of these components.
Sussane learned to combine Wardley mapping with Domain-Driven Design (DDD) to outline the many subdomains within organizations and find their core domain and its evolution. Her work as a consultant starts by identifying the pain points and bottlenecks of the organization and its teams, the pace at which they change, and their value chain using Wardley mapping —or team topologies in some cases.
As they are drawn, Wardley maps become a landscape of users and their needs that help her “understand the domain and challenge assumptions within the team.” Sussane uses this map as a foundation for future architecture, that is, how it should look and what is the ideal landscape the company would like to deal with, in which, for example, they could have gotten rid of the less efficient components in the value chain.
Once Sussane has identified the components, she “brings in the lens of Domain-Driven Design” to challenge the value chain. Domain-Driven Design (DDD) allows her “to decompose some of these components into smaller modular components, the bounded context, and also how to ensure high cohesion and loose coupling between those bounded contexts with context patterns.”
Once the domains have been identified, Sussane reviews how companies look upon their core domain. Since the core domain is “the business critical part of your system that shall provide a competitive advantage,” she encourages clients to increase their efforts in developing it. In like manner, at this stage, she expands her Wardley map “to figure out whether there are custom-building commodities that are not quartered to the business” and learn if her clients are “investing a lot of effort into something where they’re not differentiating themselves.”
Wardley mapping recognizes that the core domain can also evolve, and when this occurs, “the differentiation advantage of all competitive advantages increases or decreases” Sussane explains. As such, after specifying the core domain and its evolution stages, the next step is implementing the appropriate methods per evolution stage: “Build components in Genesis and custom built in-house with preferably agile methods or use off-the-shelf products, a bio use of the shelf products, or open source software solutions for components in product and rental with preferably lean methods or outsource to utility suppliers for components in commodity and utility or preferably Six Sigma methods,” Sussane recommends.
Team organization and evolution through Wardley maps and DDD
In Wardley maps, the components on the left side, those closer to the Genesis stage, demand more exploration and are characterized by uncertainty. They require more cognitive load than components on the right side, which are more stable and well-known. On this ground, Sussane suggests allocating more bounded context ownership to teams on the left side of the map.
In DDD, a bounded context is a well-defined boundary within which a particular domain model applies. It is an area of the system where the domain concepts, entities, and rules are clearly defined and understood. Sussane suggests identifying team boundaries that correspond to bounded contexts in the value chain, which are areas of the system where a specific team is responsible for a particular aspect or function. By allocating more bounded context ownership to teams who have to deal with exploration and discovery, we can ensure that these teams have the autonomy and resources they need to explore and experiment with the domain using new ideas. Simultaneously, the teams at the right side of the spectrum can focus on their specific area of expertise and reduce cognitive load by not having to switch between areas constantly and instead focus on routine tasks or maintenance activities.
In terms of team composition, Sussane reminds us of one of the doctrinal principles of Wardley mapping: thinking of aptitude and attitude as a way of distributing power and decision-making: “We have in our organization not only aptitude skills that are relevant for team consolidation but also attitude,” she says. From this perspective, aside from their technical skills, teams should also have a personal preference for their specific area of expertise. A team dealing with constant changes and unknown components needs a different attitude than a team dealing with established components and best practices. More importantly, each will perform tasks according to their ability. In Susanne’s view, we should consider which components a team is responsible for when building or bringing teams together so they can perform at their best. In this same regard, depending on which stage the product is, its ownership might be passed to another team.
However, Susanne also points out that teams should have a t-shaped skill model not completely oriented toward a skill or attitude, but a tendency that will not exclude having different skills aside from their personal preference. The idea is to have teams collaborate to help each other in the way they know best. She emphasizes that although teams may be stable, the organization itself is not and changes over time, and so do the interaction modes between teams depending on the context. Similarly, given their different skill sets, we should expect teams to interact and collaborate in different ways over time.
At the same time, knowledge sharing between areas as part of the company’s culture will align teams and help them adapt to change faster. In turn, a lack of communication, says Sussane, equals “introducing bottlenecks where others have to wait and get frustrated to get their changes delivered to production.” In like manner, Susanne mentions the importance of having architectural principles in place (that is, documented and accessible for everyone) to ensure that the organization’s architecture is aligned with the principles and characteristics.
Lastly, Sussane points out that as companies grow from a handful of engineers to hundreds and thousands, leaders will be demanded new skills and are expected to take decisions that they might not be fit to take: “The same people can rarely handle the same context at the same scale,” says Sussane, who encourages changing leadership altogether as the company grows. Former leaders can remain in the organization, fulfilling other roles while handing over the leadership responsibility to a new generation.
The bottom line
Sussane Kaiser is working on her book Adaptive Systems for a Fast Flow of Change which will hopefully be published this year. She can be followed on Twitter, Mastodon, and LinkedIn. She has also given talks at tech conferences available on Youtube about the concepts she shared with us and others. Sussane is open to discussing any challenges that her readers or followers may be facing and is always willing to answer questions. Keep an eye out for her book and don’t hesitate to reach out to her for support.
