Design and test your technical architecture

Why architecture comes before building

Early technical choices shape every feature that follows. Changing them later can mean rewriting code, migrating data, or renegotiating access.

Architecture work makes hidden constraints visible before the product depends on them. It connects the chosen direction to existing systems, operational capacity, privacy, security, and procurement realities.

Addressing technical risks using a spike

Some feasibility questions cannot be settled through discussion or diagrams. An integration can look straightforward until real data, permissions, or volumes expose a hidden constraint.

A spike is a small, temporary build aimed at one technical risk. It creates evidence before the delivery plan depends on an assumption.

A failed spike is still valuable. It reveals a limit while changing direction remains cheap.

What you leave with

Architecture decision records capture the consequential choices, their context, and their reasons. They preserve the trade-offs that future teams cannot see in the code.

The technical test record captures repeatable tests, evidence, results, and next actions. Overall findings connect those results to architecture decisions.

Further Reading

• Choosing technology: an introduction - Map constraints, prototype integrations, and preserve the ability to change technology choices.
• Architectural Decision Record Framework - Record significant decisions, context, consequences, stakeholders, and supporting evidence.
• Application programming interfaces - Design government APIs and plan for failures in third-party dependencies.
• Working with open standards - Use open specifications to support integration, change, reuse, and lower switching costs.
• How the alpha phase works - Test risky integrations, constraints, and technical assumptions before beta delivery.
• Build the product - Use time-boxed spikes to investigate uncertainty before committing delivery work.
• Take an ecosystem approach - Evaluate architecture within existing systems, shared components, standards, and long-term operating capacity.
• Government of Canada Enterprise Architecture Framework - Design modular, interoperable, secure, adaptable systems that support service continuity.
• Government of Canada Standards on APIs - Build interoperable APIs and validate their design through a real internal consumer.
• Loosely coupled teams - Assess whether architecture supports independent testing, deployment, and change.
• Simplicity - Reduces accidental complexity while balancing system stability, delivery agility, modularity, and release safety.