Architecture Principles
Durable agreed rules that rule options out, stated with rationale and implications.
4 to work through
-
intermediate
A commerce platform adopts the principle "every service must survive the failure of any single dependency". A team building an internal analytics dashboard requests an exemption. What does holding the line cost, and what does granting the exemption cost?
2 min answer -
intermediate
An organisation's stated principle is "do not build what you can buy". In review it is used to reject an in-house rate limiter for the public API. The vendor option meets every functional need and adds a 40 ms round trip to a request path with a 120 ms p99 budget, and it cannot express the per-tenant burst rules the product sells. The principle is not withdrawn. What did the principle buy the organisation, and what is it now costing?
3 min answer -
intermediate
You are asked to produce a technology radar for a 200-engineer organisation with no current standards. How do you build the first one?
2 min answer -
advanced
Two teams write to the same set of database tables from two separately deployed services. List the problems this creates and describe how you would evolve out of it.
3 min answer
3 terms in this topic
Architecture Principle
A durable agreed rule that rules options out, stated with rationale and implications rather than as a slogan.
practicePrinciple Rationale
The stated reasoning and implications attached to an architecture principle, without which the principle cannot be applied to a case its authors did …
practicePrinciple Statement Format
The four-part shape - statement, rationale, implications, exceptions - that turns an architecture principle from a preference into something that act…
1 artifact you would hand over
Neighbouring topics
Architecture Fundamentals
General material on what solution architecture is and what an architect is accountable for.
Requirements to Constraints
Turning stated requirements into the constraints that actually bound a design.
Functional vs Non-Functional
Behaviour versus quality of behaviour, and why only the second constrains structure.
Architectural Drivers
The small subset of requirements whose change would force the structure to change.
Quality Attributes
Availability, latency, throughput, security, cost — expressed as testable scenarios.
Coupling
How much one component must know about, or change alongside, another.
Cohesion
Whether the things inside a boundary belong together and change for the same reason.
Modularity
Composing a system from parts that can be understood and replaced independently.
Separation of Concerns
Organising so that a change to one concern touches one place.
Abstraction & Encapsulation
Hiding mechanism behind contract, and protecting invariants by owning state.
Architecture Styles
System-level organising shapes, and how they differ from problem-level patterns.
Evolutionary Architecture
Designing for guided incremental change rather than for correctness on day one.
Fitness Functions
Automated checks that an architectural characteristic still holds.
Architecture Documentation
What to write down, at what altitude, and what nobody will ever read.
Conway's Law
Systems mirroring the communication structure of the organisation that builds them.
Trade-off Fundamentals
Why every architecture is a set of purchases, and how to state what you gave up.
Technical Constraints
Existing estate, skills, licences and platforms as inputs rather than obstacles.
Architecture Roles
Solution, enterprise, domain and platform architecture, and where each is accountable.
Reference Models
Shared conceptual frames — layering, tiers, viewpoints — and their limits.