Architectural perspectives¶
What are perspectives?¶
Perspectives are evaluation lenses. You apply them to a proposed solution, an existing system, a set of options, or an ADR to test whether the design holds up from different angles.
Where principles tell you how to build, perspectives help you assess what you've built — or what you're about to build. They are the structured equivalent of a good reviewer asking "but have you thought about...?"
They are not NFRs, though they are related. An NFR is a measurable requirement — "latency p99 ≤ 10ms". A perspective is a qualitative lens — "is this design performant and scalable?" NFRs often inform a perspective assessment, but a perspective is broader than any single metric.
They are not always pictures. A perspective assessment is typically a structured evaluation — ticks, crosses, ratings, commentary. Simple and honest is better than elaborate and incomplete.
Not every perspective applies to every solution. The author decides which ones are relevant. Applying all of them to a minor change wastes time and dilutes the value of the exercise. Applying the right ones to a major decision is where the value lives.
When to use perspectives¶
- Evaluating an ADR — particularly when a decision involves trade-offs between options
- Assessing a proposed solution architecture before commitment
- Reviewing an existing system for weaknesses or gaps
- Comparing options in an RFP or vendor assessment
- Validating a new module design against the broader system
Not every scenario needs a formal perspective review. A small, well-understood change with clear requirements does not. A significant architectural decision, a new system domain, or a cross-cutting concern usually does.
How to apply them¶
Pick the perspectives relevant to your scenario. For each one you apply:
- State your assessment — positive, negative, or mixed
- Give the reason in one or two sentences
- Note any mitigations or open questions
A tick-and-cross format works well. So does a simple traffic light. The format matters less than the honesty of the assessment.
Perspectives can be combined where it makes sense — Resilience & Availability are often assessed together. They can also be split if the scenario demands it. Use judgment.
Core perspectives¶
These thirteen perspectives cover the majority of significant architectural decisions. Most assessments will draw from this set.
Performance & Scalability¶
Does the solution perform adequately at current load, and does it scale to future load without requiring a redesign?
Performance covers response times, throughput, and resource utilisation under normal and peak conditions. Scalability covers whether the architecture can handle growth — in transaction volume, in customer numbers, in data volume — without hitting a structural ceiling.
These two are assessed together because a design that performs well today but requires a rewrite at 10x volume is not a good design. The question is not just "is it fast enough?" but "is it fast enough at the scale we need to reach?"
Relevant NFRs: NFR-002 (onboarding ≤5min), NFR-007 (credit decision ≤10s), NFR-012 (Postgres write p99 ≤10ms), NFR-015 (Kafka latency ≤1s), NFR-021 (fraud scoring ≤200ms)
Typical questions: - What happens to response time at 10x current load? - Where are the bottlenecks and what is the plan when they are hit? - Does the design require horizontal scaling, and has that been tested? - Is there a cost cliff at higher volumes?
Evolution¶
Can this solution change when the business needs it to? How hard is it to extend, refactor, or replace?
Evolution is about the long-term cost of the decision. A solution that is cheap to build but expensive to change accumulates architectural debt. In a regulated environment where legislation changes, products change, and technology changes, evolution is not a nice-to-have — it is a survival requirement.
This perspective is directly linked to AP-007 (Evolution by design) and the regeneration test: could Claude Code rebuild this module from its wiki spec? If the answer is no, the evolution score is low.
Typical questions: - How easy is it to change the internal implementation without affecting consumers? - Are interfaces versioned and stable? - Is the module spec in the wiki current and complete enough to regenerate from? - What is the blast radius of a change to this component?
Strategy¶
Does this solution align with the long-term direction of the platform, the business, and the regulatory environment?
A solution can be technically correct and still be strategically wrong — it might solve today's problem in a way that creates tomorrow's constraint. Strategy perspective asks whether this decision moves the architecture toward or away from where it needs to go.
This perspective is particularly important for technology choices, vendor selections, and integration decisions. A vendor that is strategically aligned today might not be in three years. A technology choice that fits the current team might not fit a larger one.
Typical questions: - Does this align with the stated architectural principles and ADRs? - Does this create a dependency that constrains future options? - Is this consistent with the platform direction or does it introduce a divergence? - Would a regulator view this as a forward-looking or backward-looking choice?
Resilience & Availability¶
Does this solution fail gracefully? What is the impact of a failure, and how quickly does the system recover?
Resilience covers the system's ability to absorb failure — a component going down, a dependency becoming unavailable, an unexpected spike in load. Availability covers the percentage of time the system is operational and serving requests correctly.
These are often assessed together but can be split when one is significantly more important than the other. A batch processing job has different availability requirements than a payment gateway.
Relevant NFRs: NFR-019 (RTO ≤4h, RPO ≤1h), NFR-020 (availability ≥99.95%)
Typical questions: - What happens when this component fails? Does it degrade gracefully or cascade? - What is the RTO and RPO, and are they acceptable for this use case? - Are there single points of failure? - Has failure mode been tested, not just designed?
Usability¶
Is this solution usable by the people who need to use it — customers, staff, or engineers?
Usability applies to customer-facing interfaces (is the experience clear and efficient?), back office tools (can agents do their jobs without frustration?), and developer interfaces (is the API intuitive, well-documented, and consistent?). A solution that technically works but that nobody can use effectively has failed.
This perspective is directly linked to AP-005 (Customer driven). Customer experience metrics are first-class engineering metrics.
Typical questions: - Has this been tested with real users, or only designed in isolation? - Does it meet the customer experience NFRs (NFR-002, NFR-017)? - Is the back office interface efficient for the tasks agents actually perform? - Is the developer API consistent with the rest of the platform?
Risk¶
What are the risks introduced by this solution, and are they acceptable?
Risk perspective covers the full range — technical risk (this might not work), delivery risk (this might not ship on time), operational risk (this might fail in production in ways we have not anticipated), regulatory risk (this might not satisfy our obligations), and financial risk (this might cost more than expected).
This perspective deliberately overlaps with security, regulatory, and resilience perspectives. That is fine — risk is the aggregating lens that pulls them together into a single view of whether the overall exposure is acceptable.
Typical questions: - What is the probability and impact of the key failure modes? - Are there regulatory risks that require sign-off before proceeding? - What is the delivery risk — complexity, team capability, timeline? - What is the residual risk after mitigations are applied?
Integration¶
How does this solution integrate with the rest of the platform? What are the dependencies, and are they well-managed?
Integration perspective covers both technical integration (APIs, events, data flows) and organisational integration (team ownership, support boundaries, change coordination). A solution that integrates cleanly into the platform is easier to build, test, operate, and evolve. One that requires tight coupling, shared databases, or informal coordination creates fragility.
Typical questions: - What does this solution consume from and publish to the platform? - Are all interfaces versioned and documented in the wiki? - What happens to this solution if a dependency changes or becomes unavailable? - Who owns each integration point, and is that clear?
Support & Maintenance¶
What does it cost to keep this solution running after it is built? Who does that work, and is it sustainable for a small team?
Support and maintenance perspective covers operational complexity, monitoring requirements, upgrade cadence, dependency management, and the ongoing engineering effort required to keep the solution healthy. A solution that is expensive to maintain drains capacity from new work — permanently.
This perspective is directly linked to AP-009 (Robust and serviceable) and the 2am test.
Typical questions: - How much ongoing operational effort does this require? - Is the observability sufficient to diagnose problems quickly? - What is the upgrade and patching burden for dependencies? - Is the runbook written and tested, not just planned?
Security¶
Is this solution secure? Does it introduce vulnerabilities, or does it strengthen the security posture?
Security perspective covers authentication and authorisation, data protection, secrets management, network exposure, vulnerability surface, and audit trail. It is applied to every solution that handles customer data, processes payments, or provides access to production systems — which is most of them.
This perspective overlaps with AP-004 (Security by design). Where the principle sets the standard, the perspective is how you assess whether a specific solution meets it.
See also: Security architecture for platform security controls.
Typical questions: - Does this solution introduce any new attack surface? - Are secrets managed correctly — in vault, with rotation, not in code? - Is access scoped to least privilege? - Is the audit trail complete for all sensitive operations?
Resource¶
Does the organisation have the people, skills, and time to build and operate this solution?
Resource perspective is about delivery reality. A solution can be architecturally sound but undeliverable by the team that exists today. That is still a problem. Resource perspective forces an honest assessment of whether the required skills are available, whether the timeline is realistic, and whether the ongoing operational burden is sustainable.
Typical questions: - Does the team have the skills to build this correctly? - Is the delivery timeline realistic given current capacity? - Does this require specialist knowledge that is not currently available? - What is the ongoing resourcing requirement once built?
Cost¶
What does this solution cost to build and to run? Is that cost justified by the value it delivers?
Cost perspective covers both build cost (engineering time, licensing, infrastructure setup) and run cost (ongoing infrastructure, support, maintenance). It is directly linked to AP-006 (Cost effective) but goes beyond the infrastructure question to include the total cost of ownership.
Typical questions: - What is the total cost of ownership over three years? - Is the run cost predictable, or does it have variable components that could spike? - Is there a cheaper alternative that meets the requirements? - What is the cost at 10x current scale?
Regulatory¶
Does this solution satisfy the applicable regulatory obligations? Does it create new obligations, or does it help satisfy existing ones?
Regulatory perspective is specific to this bank's dual-jurisdiction environment. A solution touches regulatory obligations through data residency, audit trail requirements, reporting obligations, customer protection rules, or AML/CFT requirements. This perspective assesses the regulatory exposure of the solution and whether the compliance-by-design obligations (AP-003) have been met.
Typical questions: - Which regulatory obligations does this solution touch? - Does every applicable obligation have a documented satisfaction mode? - Does this solution create any new reporting or disclosure requirements? - Has compliance review been sought where required?
Capability¶
Does this solution deliver the capability the business needs? Does it satisfy the functional requirements completely?
Capability perspective is the functional counterpart to the non-functional perspectives. It asks whether the solution actually does what it is supposed to do — not just whether it is fast, secure, and available, but whether it delivers the feature, function, or outcome that justified building it in the first place.
This perspective can be applied at the system level (does this system domain cover all the required modules?) or at the module level (does this module satisfy all the policies it is responsible for?).
Typical questions: - Does this solution satisfy all the functional requirements it was designed to meet? - Are there gaps — capabilities that are required but not yet covered? - Does it satisfy the business goals it was built to deliver? - Are the acceptance criteria clear and testable?
Extended perspectives¶
These perspectives apply in specific scenarios. They are not needed for most assessments but are important when they are relevant.
| Perspective | When to apply |
|---|---|
| Flexibility | When the solution must adapt to a range of configurations or use cases not fully defined at design time |
| Traceability | When audit, compliance, or debugging requires end-to-end visibility of data lineage or transaction flow |
| Interoperability | When the solution must work with external systems, third-party APIs, or standards that are not fully controlled |
| Portability | When the solution may need to move between environments, cloud providers, or deployment models |
| Accessibility | When the customer-facing interface must meet accessibility standards (WCAG) for users with disabilities |
| Internationalisation | When the solution must support multiple languages, locales, time zones, or currency formats |
| Reliability | When distinguishing reliability (correctness over time) from availability (uptime) is important for the use case |
| Recoverability | When the solution manages critical data and the recovery process in a failure scenario needs specific assessment |
| Location | When data residency, latency from specific geographies, or regulatory location requirements are a primary concern |
Relationship to NFRs, principles, and viewpoints¶
NFRs are measurable thresholds — a perspective assessment uses NFRs as evidence but is broader than any single metric. See NFR register for the full list with thresholds.
Principles tell you how to build. Perspectives tell you whether what you built is good. A solution can comply with all principles and still score poorly on a perspective — that is a signal to revisit the design. See architectural-principles.md.
Viewpoints describe the architecture from a specific stakeholder's angle. Perspectives overlap with viewpoints — the security perspective and the security viewpoint cover similar ground — but a perspective is an evaluation tool, where a viewpoint is a descriptive one. The overlap is acceptable. Use whichever serves the audience. See viewpoints.md.
Perspective assessment format¶
No prescribed format — use what works for the audience and the decision. Two formats that work well:
Tick/cross summary (for ADR or option comparison):
| Perspective | Option A | Option B | Notes |
|---|---|---|---|
| Performance & Scalability | ✓ | ✓ | Both meet NFR targets at current load; Option A has better headroom |
| Evolution | ✓ | ✗ | Option B is tightly coupled — hard to change provider |
| Cost | ✗ | ✓ | Option A is 40% more expensive at scale |
| Regulatory | ✓ | ✓ | Both satisfy data residency requirements |
Narrative assessment (for a single solution review):
For each relevant perspective, one paragraph: the assessment, the reason, and any mitigations or open questions. Honest about weaknesses — a perspective assessment that has only positives is not useful.
Selecting perspectives for a given scenario¶
The author selects the relevant perspectives. As a starting point:
| Scenario | Likely relevant perspectives |
|---|---|
| New system domain | All 13 core perspectives |
| New module in existing domain | Capability, Performance, Security, Regulatory, Integration, Support |
| Technology or vendor choice | Strategy, Cost, Evolution, Resource, Integration, Support |
| ADR comparing two options | The perspectives where the options differ most |
| RFP or vendor assessment | All 13 core, plus any extended perspectives relevant to the domain |
| Minor change to existing module | Only the perspectives affected by the change |
When in doubt, apply fewer perspectives well rather than all perspectives superficially.