Documenting Constraints
Constraints define the boundaries you work within. Learn how to capture technical, organisational, regulatory, and commercial constraints that shape your architecture decisions.
Every architecture exists within boundaries. Budget limits what you can build. Compliance requirements dictate how you handle data. Legacy systems constrain integration options. Technology mandates narrow your choices.
The Constraint Block
A dedicated block type for constraints includes structured fields that capture the information reviewers and auditors need.
This example uses the NeoArc Constraint content block.
Constraint Types
NeoArc supports six constraint categories:
Hard vs Soft Constraints
Not all constraints are absolute. The rigidity field captures this distinction:
This example uses the NeoArc Constraint content block.
This example uses the NeoArc Constraint content block.
Source and Authority
Every constraint comes from somewhere. The source field records where the constraint is defined: a policy document, a regulation, a contract, a technical specification. The authority field records who can modify or waive it.
Impact on Design
The most valuable part of a constraint is explaining how it affects your architecture. A constraint without impact analysis is just a rule. A constraint with impact analysis shows how that rule shaped specific decisions.
Workarounds
Some constraints have escape hatches. An exception process. A waiver request. A technical workaround that satisfies the spirit if not the letter. Document these so teams know their options.
Workarounds are not violations. They are legitimate paths that acknowledge the constraint while providing flexibility where it exists.
Constraint Lifecycle
Constraints change over time. A budget constraint expires at fiscal year end. A legacy system constraint disappears when the system is decommissioned. A regulatory constraint may be superseded by new legislation.
The reviewDate field helps schedule periodic reviews to confirm constraints remain valid.
Constraints vs Assumptions
Constraints and assumptions both shape architecture, but they differ in an important way:
"We must use PostgreSQL" is a constraint if mandated by policy, but an assumption if based on expected query patterns. The distinction matters because constraints require acceptance while assumptions require validation.
Adding a Constraint Block
This documentation site was built entirely using NeoArc Studio, so the constraint blocks you see here are the same ones you will use in your own documentation.