What is a target state architecture?
Your "target state architecture" is exactly what your project needs in order to adequately describe current state, its problems, and desired solutions.
During the last large scale project I led we had a team of about 40 that needed onboarding. One of the first activities was a target state architecture review. I remember giving a top-down journey, going from business events, capabilities and use cases down to a high-level drawing of the event streaming architecture.
After about 30 minutes I started to wind things up so we could take a break. Before giving everyone a breather, I asked if there were any questions.
I remember one tentative hand going up. I said, “every question’s a good one — what is it?”
He asked, “what’s a target state architecture?”
Target state architecture, noun:
A framework that enables the necessary planning and subsequent actions required to attain a desired target state.
Sometimes we’ve been doing things for so long, we forget it’s not second nature to others. I throw jargon around that people don’t understand all the time. Target state architecture. Event streaming. Context boundary. Anti-corruption layer. External interface. Ubiquitous language. Stereotype. Immutable state.
Pausing to take time and make sure whomever you’re talking to understands your words is a good first step.
Recently I’ve had a few others ask me what a target state architecture is. This is, to the best of my recollection, what I said to that young engineer.
Target state architecture, noun:
A target state architecture helps us reason about current state, its problems, and desired solutions while providing a plan for the future. It’s not any one single thing, not just a pretty drawing or technical model.
To create a path free of obstacles, you need a clear, shared understanding of technical and business challenges. That comes from a systematic approach to problem diagnosis, impact assessment, and solution development — it goes beyond describing features, listing stereotypes, and making technical drawings.
Organizations often struggle with varying opinions on technical challenges. While some problems might be universally recognized, different teams and business units typically focus on issues that most directly affect their work. That siloed view can make it difficult to develop a holistic solution that fits the entire business problem.
A target state architecture serves as a crucial tool for bridging these gaps. It helps teams analyze current state problems, envision solutions, and plan a path forward. It offers a detailed examination of specific challenges, proposed solutions, key features, priorities, and designs that align with delivering value. In essence, it represents an expert opinion on implementation — a solution architecture for the desired future state.
It's important to recognize that any target state architecture is inherently opinionated. As an imagined solution at a specific point in time, it should embody the principle of “strong opinions, loosely held.”
Plans are worthless, but planning is everything. – Dwight D. Eisenhower, Nov. 1957
The details of any plan designed in advance may be incorrect or may become incorrect. But the planning itself has value. It demands thorough investigation of potential solutions, contingencies and different options. That knowledge, gained while probing various ideas, prepares us to select better actions as events unfold.
This is why a target state architecture cannot be a fixed goal. It must evolve with changing conditions. The best way to achieve such a flexible, evolving architecture is to adopt an iterative style: constantly reevaluate, replan, and rearchitect. Your target state architecture is a moving target that needs to stay up to date with every new development.
As plans change, so do intended outcomes. An effective strategy needs to communicate its evolving state. I wrote about that in a short article, Why we shouldn’t hide complexity.
What goes into target state architecture
The most important thing to remember is that a target state architecture is not static. It’s not one thing. It’s not a drawing. It’s not a specific tech stack, or a list of use cases. Nor is it limited to a high level architecture. It’s all these things, and more.
It is exactly what your project needs in order to adequately describe current state, its problems, and desired solutions.
For an exploration of a comprehensive target state architecture, refer to the Delivery Playbook and, in particular, these topics:
Plagued with problems getting to delivery? Solve them with a “steel thread."
Ephemeral environments are the best way to fight “‘waste gremlins”
Do you understand your customer? Subtle word choices lead us into a lot of trouble
Join for free, no obligation! As a free subscriber you can read about half of every article, plus all of my free articles.
As a paid subscriber you get open access to the Delivery Playbook. Check out this free chapter to see what it’s all about. Plus, there are weekly articles on career development and technology.