Architecture Ownership Patterns For Team Topologies. Part 1: A Business Architecture Model
Team Topologies has significantly advanced the discussion on organisation design for technology companies. The next step is to determine what Team Topology boundaries align to…what should Stream-aligned (and other) teams own?
When organising technology teams to build digital products and services, it is necessary to determine which parts of the product, user experience, and technology each team owns.
Should teams be frontend, backend, full stack or something else? There are more than just these three patterns to choose from, each with many trade-offs to consider.
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
A Model For Describing The Architecture of a Business
Before defining team responsibility ownership patterns and comparing their trade-offs, it’s necessary to have common ground on the language used to define responsibilities a team may own. We need a model that describes the different elements of a system that a team could own.
I’m not precious about any of the definitions used in this article. My goal is to create common ground so that we can discuss the trade-offs of organisational design patterns. It’s ok if you define these terms differently, but please make your definitions clear if you want to debate the content of this article so that we don’t end up arguing about definitions instead of design trade-offs.
Roman Pichler’s definition of a digital product and related concepts is the model I prefer to use.
An organisation may have one or more products. Products maybe internal used only by the company to increase productivity and/or reduce costs, or products can be external generating revenue and/or helping to sell other products. A group of products that are sold/used together is a bundle. Roman use the example of Microsoft Office as a product bundle. Not all products have to belong to a bundle.
A product may have multiple variants such as web, android, and iOS apps which all offer identical or similar functionality delivering the same value propositions to the same customer segments.
The next step is understanding where user experience and user journeys fit into the model.
A product is composed of features like the ability to log in, view an account balance, and make a purchase. A user experiences the product by carrying out user journeys interacting with one or more features across one or more products.
User journeys and experiences are what the user does and feels. They are outside of the software. An individual user journey is composed of one or more user tasks.
A product feature may display information such as a bank balance, or perform actions like adding funds to a bank balance. These pieces of information and actions are part of a business domain. Essentially, product features expose domain information and capabilities.
When a user uses a product feature that performs an action, business rules will be activated in the domain which are associated to business entities. For a Bank Account entity, a business rule could be that a balance must always be non-negative.
Domains are hierarchical. A domain may be composed of subdomains which themselves may be composed of subdomains. Domains are synonymous with business capabilities from the business architecture world.
Business processes are series of steps which cut through one or more domains. Processes contribute directly or indirectly to producing a value proposition, and they may contain manual steps performed initiated in a user journey or automated steps purely in the domain.
Processes are also a hierarchical concept. A high level process may be comprised of multiple lower-level processes.
Layers Overview
I find layering to be a useful concept for understanding how all of the elements of business architecture related to each other. There are also technical and organizational benefits to layering which Uber explain well.
Which Architecture Ownership Pattern To Use?
This model of business architecture gives us a lot to think about. Where are the possible team boundaries in such a model? User journeys, product features, product variants, domains, subdomains, processes?
The answer is all of them. In different scenarios, each of those architectural component types may be the correct responsibility for a team to own. The next part in this series will explore some patterns at the layers of individual teams and teams of teams.
Thanks to Matt in the comments who helped me find a better name for this article. It used to be called Team Responsibility Ownership Patterns. Thanks for all the other suggestions, too.
