Product, Domain, and Team Architecture Overview Template
A difficult aspect of my job is understanding enough about a client’s purpose and landscape to offer useful advice and propose how I might be able to help. I speak with multiple new companies per month about the possibility of working together so this is an important skill I need to work on.
I’m looking at this challenge from multiple angles, and one of them is figuring out the key information I need. If I can capture key information earlier, that gives me a good understanding of key elements of the business’s architecture, we can get to valuable conversations sooner.
I’ve been reflecting on my work over the past 12 months and I’ve created a template which feels like a good starting point. At the moment it’s an experimental idea that I’m evaluating. I’m always happy to chat if you have feedback or suggestions (I’d love to hear if you already solved this problem with something much better).
The template can be viewed as a Miro board and is shared under a Creative Commons license.
Product Taxonomy
Products and Platforms are the components of a business’s architecture that I find the most interesting and revealing, so my template starts with a Product Taxonomy section.
The product taxonomy definitions by Ross Clanton et al. are a useful starting point. In their definition, a product portfolio contains one or more product groups with contain one or more products.
It’s not mandatory to use these definitions. Most companies have their own language for talking about products, platforms, systems, value streams and so on. If something already exists, I’d recommend using that.
Not all parts of a system are considered to be part of a product. I call these platforms. Examples include identity platforms, API platforms, and digital platforms that may be leveraged by multiple products.
It’s worth highlighting that platforms should still be developed in product mode.
Innovation Portfolio
An innovation portfolio is invaluable because it expresses where products and platforms are in their lifecycle, revealing where each fits into the strategy. Essentially, this helps to see what’s important now and what the big bets for the future are.
I’ve been using the Lean Innovation Portfolio for years. I think it’s simple and effective: for each product and platform, decide if it is in the Explore, Exploit, Sustain, or Retire phase.
You may ask why I don’t recommend Wardley Mapping here, since I’ve been a proponent for a number of years? The answer is that I want this template to be a quick overview that is fairly easy to create with no learning curve. The Lean Innovation Portfolio meets that criteria but Wardley Mapping takes a while to grasp and a map takes longer to create.
Domain Roles and Personas
To gain an understanding of how a business operates, I find it useful to start by thinking about all of the people involved in the business domains. What are they trying to achieve, and what do they do? This can include people outside the company like customers and suppliers, and also people within the company like employees and even chatbots.
To find a balance between gaining useful information and not spending too much time, I’ve settled on a list of roles/personas along with ~3 key jobs/tasks they do and ~5 key domain events that are most relevant to them.
Teams
Possibly the most useful indicator of organization health is how well teams are working, and equally, how happy they are. To truly assess this requires spending time with teams to see how they work, the challenges they face, and how they are able to continuously adapt and improve.
To get a quick overview, I think scale, deployment frequency, and ownership patterns are three pieces of information that are easy to attain yet still provide useful insights and clues about where to dig deeper.
On the template I use a table with four columns: Team / Group, Size, Deployment Frequency, Responsibilities.
The first column is the name of the team or group. If an organization has more than 20 teams, listing them all out will take too long, so it’s ok to work at the the teams-of-teams level (aka groups). The Size column indicates the approximate number of engineers working in the team or group.
Deployment Frequency is the rate at which a team deploys to production. Once a day, once a week, once a month etc. This is one of the 4 DORA metrics and also reflects my personal experience: in general, teams that deploy to production more frequently are working to a higher standard. There are lots of caveats and concerns, but in general, I’ve found it’s the best single indicator.
The final column, Responsibilities, captures the parts of the system that each team owns. For example Payments Platform, Website, Admin UI, etc. This gives away a lot of clues about how the organization draws boundaries and slices up responsibilities.
The Template is the Starting Point
I would like to finish by emphasising that a completed template alone isn’t that useful. It doesn’t tell the whole story, it just helps to get the conversation started.
The value is in talking through the template, discussing each part, and identifying unknowns, conflicts, or other interesting factors that may benefit from additional discussions or potentially workshops.
Feel free to leave a comment or message me directly if you’re interested in this topic and want to discuss anything.
