Frontend Architecture Operating Model
Why this chapter matters
Architecture fails when it is only a set of opinions held by one senior person. A frontend architect needs an operating model: how decisions are proposed, reviewed, adopted, measured, and retired.
This chapter defines the minimum operating system for architecture work before the advanced governance chapters.
The operating loop
Intake
Architecture work enters through signals:
| Signal | Architect response |
|---|---|
| repeated implementation debate | turn the debate into a decision record |
| production incident | identify the missing constraint or fitness function |
| product strategy shift | update boundaries, ownership, and quality targets |
| slow delivery | distinguish code debt from ownership or platform debt |
| quality regression | add review gates or automated checks |
| migration pressure | define strangler path and compatibility contract |
Classification
Not every issue deserves the same weight.
| Class | Examples | Artifact |
|---|---|---|
| local design | component API, local module split | short note or PR comment |
| cross-feature decision | shared state, API contract, package boundary | ADR |
| platform decision | build system, design system, observability, auth | RFC and rollout plan |
| high-risk launch | checkout, billing, identity, AI tool action | review packet and readiness gate |
Review cadence
Use lightweight ceremonies:
| Cadence | Purpose |
|---|---|
| weekly architecture triage | classify new decisions and risks |
| biweekly design review | review ADRs/RFCs before irreversible work |
| monthly quality review | inspect budgets, incidents, accessibility, security, dependency risk |
| quarterly architecture health review | retire old standards, update roadmap, rebalance ownership |
Ownership model
Architecture ownership should be explicit.
| Area | Owner question |
|---|---|
| product surface | Who owns user outcome and operational quality? |
| platform capability | Who owns contracts, upgrades, documentation, and support? |
| shared component | Who owns API stability, accessibility, and deprecation? |
| dependency | Who owns version policy and incident response? |
| metric | Who owns interpretation and action when it regresses? |
Fitness functions
Operating models need signals, not vibes.
| Constraint | Example fitness function |
|---|---|
| route cost | bundle budget and Web Vitals threshold |
| accessibility | keyboard/focus smoke test plus component a11y contract |
| ownership | module boundary lint and dependency ownership map |
| design system | no new raw color usage outside token package |
| security | CSP violation budget and Trusted Types adoption |
| reliability | critical route error budget and rollback drill |
Review checklist
- Is architecture intake visible to teams?
- Are decisions classified by risk and reversibility?
- Are review cadences light enough to survive delivery pressure?
- Does every shared capability have an owner?
- Are architecture constraints measured through fitness functions?
- Is retirement/deprecation part of the process?
Exercises
- Draw your team's current architecture operating loop.
- Classify the last five frontend architecture debates by decision class.
- Define three fitness functions that would have prevented a recent regression.
Source lens
This chapter is the Part 0 baseline for Part IX governance, Part XII review programs, and the capstone solution packs.