Revisit Architecture Bets on a Fixed Cadence

The Strategic Architectural Planning Template

Companion to The Code Takes Care of Itself · Updated 2026-09-30

This is the full playbook from “Match Architecture to the Business’s Next Three Years.” The book prints a shorter version at the end of that chapter, and this page keeps every step and every example.

Run the Strategic Architectural Planning Template as a standing exercise, not a one-time audit: quarterly for a fast-growing company, semi-annually for a stable one.

  1. State the business trajectory in specific, falsifiable terms. Not “we plan to grow.” Write four things: expected customer count and revenue at twelve, twenty-four, and thirty-six months; the markets or segments the company is pursuing now; the compliance regimes those markets require, such as data residency, HIPAA, SOC 2, or an industry-specific rule; and whether an acquisition, a round of funding, or a major partnership is realistic, along with the technical due diligence it would trigger. Get these in writing from the CEO and the board deck. Don’t infer them from hallway conversation.
  2. Compare the current architecture with that trajectory and name specific constraints. For each major system, state what it handles today and where its ceiling is, as a number or a named event. “This database architecture holds until roughly 2 million rows in the primary events table” is useful. “This should scale fine for a while” is not. Then sort the inventory. Urgent: constraints that bind you before the Step 1 trajectory is reached. To monitor: constraints that bind you after it. Overbuilt: capacity that already exceeds the expected constraint. For that last group, ask whether the extra complexity earns its cost.
  3. Classify each pending architectural decision as early-binding or late-bindable. Include everything on the horizon: a new data store, a move into a new cloud region, a change in service boundaries, a new core dependency. For each, ask what a reversal costs in eighteen months if the business changes. An element that will be expensive to reverse, like the core data model, the multi-tenancy approach, or the regulatory architecture, earns full upfront diligence, business-leader involvement, and a deliberate design review. An element that will be cheap to reverse gets a lighter process: ship something reasonable now instead of spending weeks on a choice you can change later. A rough split is enough. Its purpose is to stop you from over-investing in the wrong half of the list.
  4. Assign an owner and a review trigger to every urgent and monitor item. Name one person accountable for tracking each. Give each a specific trigger that reopens the conversation: a metric threshold, a customer commitment, or a date. Use this form: “Revisit the sharding strategy when active accounts cross 500,000. Owner: the platform lead.” A list without owners and triggers is a list of good intentions, and nobody acts on it until an emergency forces the issue.
  5. Bring a business voice into the room before the decision hardens. For every early-binding item from Step 3, name the person outside engineering who must attend the decision meeting: usually the CEO, the head of sales for anything touching customer configurability, or the compliance lead for anything regulatory. Write down the business assumption the decision optimizes for. If that assumption turns out wrong, the postmortem can trace the failure to the assumption rather than to the engineering team’s technical judgment, which was probably sound for what it was told to optimize.

Try this with AI.

“I’ll describe an architecture decision and the business assumption behind it. Interview me one question at a time until you find the assumption I’m treating as a fact, then name the person outside engineering who should be in the room when we decide.”

Start from the trajectory the business is actually betting on, not the trajectory engineering has inferred in its absence. The CTO in the opening story of “Match Architecture to the Business’s Next Three Years” had good engineers and a defensible technical decision. What he didn’t have was a process that forced the business’s real assumptions about growth, customers, and demand into the room before the architecture hardened around an engineering guess.

All of the playbooks are listed on the playbooks page.