Some technical choices are harder to revisit than others. This lesson explains how to give those decisions the right attention while using delivery and reliability evidence to evaluate the architecture over time.
Carlos Sanabria focuses on three foundational areas: data models, authentication and the location of business logic. He then connects architecture discussions to four observable measures of how the team delivers software.
What you'll learn.
- Review foundational decisions with appropriate technical expertise.
- Distinguish expensive-to-change choices from more revisable ones.
- Use delivery speed and stability together when evaluating architecture.
Identify the decisions that are harder to change.
A data model shapes how the product represents the business. Authentication affects how people prove identity and receive access. The placement of business logic determines where important rules are implemented and maintained.
These choices can influence many later features and integrations. Bring informed engineering judgment into them early, and make sure the team can explain how each decision supports the product’s needs. Harder to change does not mean impossible to change; it means the consequences deserve attention.
Leave room to iterate elsewhere.
The recording contrasts those foundational choices with hosting, compute, caching and third-party tools, which may offer more room for revision as requirements become clearer.
The practical principle is to avoid giving every decision the same weight. Understand the dependencies and migration effort, then decide which choices need deeper investigation now and which can be reviewed when there is better evidence.
Measure delivery and stability.
Track how often the team deploys and how long a change takes to move from a code commit into production. These measures describe the ability to deliver improvements.
Also examine how often releases fail and how long recovery takes. Faster delivery is less useful if each release creates disruption. Looking at speed and stability together gives the architecture discussion a connection to operational outcomes.
Use evidence in the architecture review.
Ask developers where the current design slows delivery, creates repeated failures or makes recovery harder. Then connect a proposed change to the measure or product requirement it is meant to improve.
Repeat that review as the product develops. A decision that suited an early version may need adjustment, but the reason should be visible in customer needs, team experience or delivery data. This keeps architecture work connected to the business rather than a preference for novelty.
Give foundational choices careful thought and evaluate the system through the work it enables. The goal is an architecture the team can change safely at a pace the product requires.
