Architecture Ownership Patterns for Team Topologies. Part 3: Multi-Team Patterns
As a system grows, higher-order abstractions are needed for ease of understanding, communication, and management. In Geography, continents are a higher order abstraction that allow us to collectively describe a large number of countries in a single word. As businesses grow, higher order abstractions are needed to organize groups of teams working on related challenges, like products or domains.
When I worked with Salesforce, the top-level organizational abstractions were clouds. The Salesforce Marketing Cloud was a substantial business in it’s own right, employing thousands of people and generating close to a billion dollars in revenue per-year.
Part 2 of this series looked at the lowest organzational abstraction level — individual teams. This part moves one level higher, looking at patterns for grouping small numbers of teams. I prefer the term Group although you may be familiar with the phrase Tribe emanating from the Spotify Model.
This article represented my mental model at the time of writing, but I’m always iterating on it. You can get an idea of how some of my thinking has changed since this post here: https://github.com/NTCoding/prod-domain-biz-arch-building-blocks
Group Patterns
The following list is as a sample of archetypical patterns rather than a definitive list. The goal of these patterns is to inspire deeper thinking rather than to define a precise model which you must conform to.
Standalone Product Group
At Salesforce, the Marketing Cloud was composed of a selection of marketing-related products that formed a cohesive suite, some of which were also standalone products. In the case of Salesforce, some actually were previously standalone products that got acquired.
A Standalone Product Group is defined by it’s ability to function as a revenue-generating organization with little to no extra assistance from within the parent organization. This implies owning all of the products and domains required to deliver the product.
It’s worth pointing out that standalone products are not entirely a good thing. A customer does not want to deal with many standalone products from a single company, they want a cohesive experience. Shared identity services and product branding providing a more consistent experience, and shared infrastructure can enable greater productivity.
Standalone Capability Group
A Standalone Capability Group is a collection of teams which own one or more product features or areas, and the domain capabilities that power them. Unlike a Standalone Product Group a Standalone Capability Group’s functionality does not provide value as an independent product. It must be combined with other capabilities to form a complete product. However, it does provide a complete service in isolation (and potentially could be an independent product).
A common example of a Standalone Capability Group is Identity and Accounts. There are a variety of features including log in, password reset, account linking, permissions, multi tenancy administration etc. Each team in an Identity group may own one or more features. Individual teams may be full-stack/end-to-end or dedicated presentation/domain teams.
Experience Group
Some digital products are sufficiently complex that a group of teams must work closely together just to deliver the experience, with no ownership of the domains that power the product features. An Experience Group is a collection of teams which handle only experience and presentation concerns.
There are some companies out there that have many teams dedicated just to building their mobile application(s). One example is the mobile department, a group of mobile development teams who each own a part of a mobile app.
The problem of dedicated frontend and backend groups shares many of the same trade-offs as dedicated frontend and backend teams discussed in Part 2.
Domain Group
Related parts of a system combine to provide higher level functionality, and those parts of a system are highly likely to change together often, as a business evolves existing capabilities and develops new ones. There is usually a high cost to cross-team dependencies, so grouping teams that own related parts of a domain reduces the cost of synchronisation.
By modelling your business as domains and subdomains, you can organise groups of teams around domains with each team owning one or more subdomains within the parent domain.
A supermarket chain have a group of teams working collectively to develop capabilities within the customer contact domain. This domain includes subdomains for building and sending communications, and managing customer preferences, like their preference for email, SMS, or postal messages. Each subdomain is owned by a separate team.
A domain group is an internal service provider, exposing domain data and business process operations to experience-layer groups or other domain groups.
Productivity Platform Group
A core concept in Team Topologies is the platform. Platforms provide the foundation for higher levels of innovation. In smaller organizations, platforms may be composed of a single team, and in larger organizations there may be multiple platforms each composed of multiple teams.
One category of platform is the productivity platform. These are platforms which provide tooling and infrastructure so that higher-layer teams can build and deliver their products and domains more easily and more rapidly.
Lot’s to Think About
The example patterns in this post provide a small insight into the types of approach that can be taken when organizing individual teams into collaborative groups with a shared mission. There are countless variations on each of these patterns which will depend on the industry, culture, and current setup of an organization.
It’s unlikely there will be a single model that fits all organizations while remaining useful. However, a structured model with clear definitions can help your company to define guidelines that make sense in your context. I hope that the patterns in this series can be a useful starting point on your journey.
