What is a "north-star" (target) architecture vision, and how does it differ from the current-state architecture?
answer
- as-is vs to-be, delta = roadmap
- destination, not itinerary
- quality attributes + explicit non-goals
- must change a real decision
- intermediate states, no big bang
basics
~20 sThe north-star is the agreed target architecture: a picture of the desired future state and why it is better. Current-state is what actually runs today. The gap between them drives a roadmap of incremental steps.
solid answer
~40 sA north-star (target) architecture describes where the system should be in roughly one to three years: major components, boundaries, data ownership, integration styles, and the quality attributes (time-to-market, scalability, cost, reliability) it optimises for. It is a decision-making aid, not a delivery plan. Its job is to make many small, distributed decisions add up to one coherent system. Current-state architecture documents what exists today, warts included. The delta between the two produces a transition roadmap of intermediate states, each shippable and valuable on its own, so you never need a big-bang rewrite. A good north-star is dated, owned, versioned, justified by business drivers, states explicit trade-offs and non-goals, and is revised when strategy or reality changes. If nobody can name a decision it changed, it is decoration, not strategy.
go deeper
Say it is the agreed future-state picture versus what exists today, and that the difference is worked through step by step rather than in one rewrite.
Add what it contains — boundaries, data ownership, integration styles, prioritised quality attributes — and that it guides day-to-day design decisions.
Emphasise explicit trade-offs and non-goals, the transition roadmap of independently valuable states, decision records for deviations, and fitness functions to prevent drift.
Frame it as the coherent-action layer of a strategy: diagnosis, guiding policy, actions; connect it to funding, team topology and Conway's law, adoption mechanics, and a review cadence that lets the vision be falsified.
### Definitions - **Architecture**: the structural decisions that are expensive to reverse later — how the system is decomposed, who owns which data, how parts communicate, and which quality attributes are prioritised over others. - **Quality attributes** (also "non-functional requirements"): properties like latency, availability, security, operating cost, and changeability. They are the real currency of architecture, because you trade them against each other. - **Current-state ("as-is") architecture**: an honest description of what runs today, including duplication, legacy systems and workarounds. - **North-star / target ("to-be") architecture**: a deliberately simplified description of the future state you are steering toward, plus the reasoning for it. ### Why a north-star exists In any organisation with more than a couple of teams, architecture is produced by hundreds of independent local decisions. Without a shared target, each decision is locally reasonable and globally incoherent: five queueing technologies, three auth mechanisms, overlapping services that each own a slice of "customer". The north-star is the shared reference that makes local decisions converge. Its practical test is simple: *does it let someone decide, without asking you?* ### What it should contain 1. **Business drivers** — the strategy it serves ("enter three new markets", "cut infra spend 30%", "ship a customer-visible change in a day"). 2. **Prioritised quality attributes**, ideally with numbers (p99 latency, RTO/RPO, cost per transaction). 3. **Boundaries and data ownership** — which capability owns which data, and the system of record for each concept. 4. **Integration styles** — synchronous request/response vs. asynchronous events, and where each applies. 5. **Explicit non-goals and trade-offs** — what you are deliberately *not* optimising for. A vision with no sacrifices is a wish list. 6. **Constraints** — budget, compliance, data residency, existing contracts, team skills and size (Conway's law: the architecture drifts toward your communication structure, so target architecture and team topology must be designed together). ### What it must not be - **A project plan.** It has no dates or task breakdown; it is the destination, not the itinerary. - **A big-bang rewrite mandate.** The roadmap from as-is to to-be must consist of intermediate states that are each independently valuable and safe to stop at. Strangler-fig style incremental replacement (route traffic feature-by-feature from old to new, retire the old when empty) is the default technique. - **Static.** Give it a version and a review cadence (commonly every 6–12 months, or on any major strategy change). A never-changing vision means nobody is checking it against reality. - **A tool list.** "Kubernetes, Kafka, GraphQL" is not a vision; it is an answer with the question missing. ### How it is used day to day - New designs and RFCs state whether they move toward or away from the north-star; deliberate deviations are recorded as decision records with an expiry or a payback plan. - It seeds the **technology radar** and the **golden paths** (the supported, paved defaults teams get for free). - It can be partly automated as **fitness functions** — tests or checks that continuously verify a targeted property (dependency direction, latency budget, no cross-service database access), so drift fails a build rather than being discovered a year later. ### Common failure modes - Drawn once by an ivory-tower group, never socialised, so teams ignore it. - Too detailed: it constrains implementation choices that should stay local, and becomes stale within a quarter. - Too vague ("cloud-native, event-driven, API-first") so it forbids nothing and resolves no argument. - No migration path, so the gap is never closed and the vision becomes a source of guilt rather than direction.
- How do you keep a north-star architecture from becoming a document nobody reads?Tie it to decisions: require RFCs/design reviews to reference it, derive golden paths and the technology radar from it, encode the parts you can as automated fitness functions, publish deviations as dated decision records, and re-version it on a fixed cadence with named owners.
- What is the difference between a target architecture and an architecture roadmap?The target describes the destination state and its rationale; the roadmap sequences intermediate, independently valuable states with owners and rough timing that move you from current-state to target.
It is the pin you drop on a map, not the turn-by-turn route. The pin makes every driver's small choice — which exit to take — consistent, even though each of them picks their own roads and traffic changes daily.
saying these in an interview costs you the question
- Presenting a list of technologies as the vision, with no business drivers or quality-attribute goals
- Treating the north-star as a rewrite mandate rather than a direction reachable incrementally
- A vision with no non-goals or trade-offs — everything is a priority
- Writing it once and never versioning or reviewing it
- So detailed it dictates implementation choices teams should own
- Ignoring team structure and Conway's law when picking boundaries