Architecture Requirements, Principles and Frameworks

Introduction

Cloud architecture is not primarily the selection of a provider, a virtual machine size, or a collection of managed services. It is the disciplined transformation of organisational goals into a system that can deliver useful outcomes under technical, financial, legal, operational, and ethical constraints. A sound architecture therefore begins with requirements and principles, and only then proceeds to technologies and implementation.

Cloud systems are especially sensitive to architectural decisions because they are distributed, elastic, service-oriented, and operated through programmable interfaces. Decisions about identity, data location, availability, observability, network boundaries, and deployment automation can affect the organisation for years. Architecture work must consequently be explicit, reviewable, and traceable.

This chapter explains how to elicit and classify requirements; distinguish functional requirements from quality attributes; apply architecture principles and patterns; record decisions through architecture decision records (ADRs); and use reference architectures and major cloud frameworks responsibly. The emphasis is on practical judgement: frameworks guide decisions, but they do not replace analysis.

Learning objectives

By the end of this chapter, you should be able to:

1. Convert business, user, technical, and regulatory needs into testable architecture requirements.
2. Distinguish functional requirements, non-functional requirements, constraints, assumptions, and acceptance criteria.
3. Analyse quality attributes such as availability, performance, security, reliability, scalability, maintainability, and cost efficiency.
4. Apply architecture principles, reference architectures, and design patterns to cloud solutions.
5. Construct and evaluate an architecture decision record.
6. Compare the purposes of cloud adoption frameworks and well-architected frameworks.
7. Identify trade-offs, governance obligations, and limitations in architecture recommendations.

1. From organisational need to architecture requirement

A requirement is a statement of a capability, condition, or constraint that a system must satisfy. Architecture requirements are not limited to software features. They include qualities and boundaries that shape the structure of the whole solution.

A useful requirements chain is:

Business outcome → stakeholder need → system capability → measurable requirement → verification method

For example:

• Business outcome: reduce insurance claim-processing time.
• Stakeholder need: claims staff require rapid access to policy and image data.
• System capability: retrieve and process claim information through a secure portal.
• Measurable requirement: 95% of standard claim searches shall return within two seconds during normal peak load.
• Verification method: automated performance testing using a defined production-like workload.

The final statement is more useful than the original aspiration because it is measurable and can influence design.

1.1 Stakeholders and viewpoints

Different stakeholders observe different risks. A business sponsor may focus on value and time to market; a customer may focus on usability and privacy; an operations team may focus on recoverability; a regulator may focus on evidence and lawful processing; and a security team may focus on identity, threat resistance, and accountability.

Common elicitation techniques include interviews, workshops, document analysis, observation, process modelling, threat modelling, service-level reviews, and analysis of existing incidents. Requirements should be validated with the people who own the relevant risk rather than inferred solely by the architect.

A stakeholder map can classify each party by influence, impact, and decision authority. A responsibility matrix can then identify who approves requirements, who supplies evidence, and who accepts residual risk.

1.2 Requirement categories

A requirement should be atomic, necessary, consistent, feasible, prioritised, traceable, and verifiable. The word “fast” is not a testable requirement until the workload, percentile, threshold, and operating conditions are specified.

1.3 Functional requirements

Functional requirements describe behaviour, services, data transformations, events, interfaces, and business rules. In cloud systems they may include:

• user registration and federation with an enterprise identity provider;
• ingestion of events through a queue or streaming service;
• validation and enrichment of uploaded documents;
• storage of immutable transaction records;
• publication of an API with authentication and rate limits; and
• scheduled generation of regulatory reports.

Functional decomposition should preserve business meaning. A requirement such as “use serverless functions” is not functional; it is a possible implementation constraint or design choice. Requirements should not prematurely prescribe technology unless a genuine constraint exists.

1.4 Non-functional requirements and quality attributes

Non-functional requirements specify qualities, operational conditions, or constraints. They are often more influential than features because they determine topology, data architecture, deployment methods, and operating procedures.

A strong quality requirement includes:

subject + measurable condition + threshold + workload or context + verification method

For example, “The order API shall support 500 requests per second at the 99th latency percentile below 400 ms for requests up to 20 KB, measured during a controlled load test.”

Important cloud quality attributes include:

• Availability: readiness to provide an intended service.
• Reliability: ability to perform consistently and correctly over time.
• Scalability: ability to handle changing demand by adding or removing resources.
• Elasticity: ability to provision and release resources in response to demand.
• Performance: response time, throughput, latency, and resource efficiency.
• Security: protection of confidentiality, integrity, availability, authenticity, and accountability.
• Resilience: ability to withstand and recover from faults or disruption.
• Maintainability: ease of correction, modification, testing, and operation.
• Portability: ease of moving workloads or data between environments.
• Cost efficiency: delivery of required value without avoidable expenditure.
• Sustainability: reduction of environmental impact while meeting service needs.

These qualities conflict. Stronger isolation can increase cost; extensive redundancy can increase complexity; multi-cloud portability can limit access to provider-specific capabilities. Architecture is therefore a process of making and governing trade-offs, not maximising every attribute independently.

1.5 Availability and recovery requirements

Availability is commonly expressed as the proportion of an agreed observation period during which a service is usable. If T is the total agreed observation time and D is unplanned unavailable time, then:

This formula assumes that the observation period and exclusions, such as approved maintenance, are explicitly defined. It does not by itself describe performance, data correctness, or user satisfaction.

For a 30-day month, using 24-hour days, T = 30 × 24 × 60 = 43,200 minutes. A 99.9% target permits approximately:

The result is an allowance, not a promise that downtime will be distributed evenly. Service-level objectives should also define measurement points, dependencies, support response, and consequences.

Recovery requirements use two important measures:

• Recovery time objective (RTO): the maximum acceptable time to restore service after a disruptive event.
• Recovery point objective (RPO): the maximum acceptable period of data loss measured in time.

A five-minute RPO does not mean that every transaction is recoverable; it means the designed recovery process should lose no more than the agreed five minutes of data under the stated scenario.

2. Architecture principles and trade-offs

Architecture principles are durable rules that guide decisions across systems. They are more stable than individual technologies and should be concise enough to influence design reviews. A useful principle has a title, rationale, implications, exceptions, and an owner.

Examples include:

1. Secure by design: security controls are built into identity, data, code, networks, and operations rather than added at the end.
2. Automate repeatable change: infrastructure, configuration, testing, and deployment are represented as versioned, reviewable code where practical.
3. Prefer managed services when they reduce undifferentiated operational work: adoption remains subject to portability, cost, performance, and compliance analysis.
4. Design for failure: components, dependencies, zones, and deployment processes are assumed to fail.
5. Least privilege by default: identities receive only the access required for an authorised task and period.
6. Make operational state observable: logs, metrics, traces, events, and audit evidence are designed as part of the system.
7. Use reversible decisions when uncertainty is high: experiments and modular boundaries reduce the cost of learning.
8. Classify data before selecting storage and location: sensitivity, retention, residency, recovery, and deletion requirements drive design.

Principles can conflict. “Use managed services” may conflict with a requirement for a specialised algorithm or strict portability. The correct response is not to abandon a principle but to document the exception and its consequences.

2.1 Separation of concerns and least privilege

Separation of concerns assigns distinct responsibilities to components, teams, accounts, or environments. It reduces accidental coupling and limits the effect of faults or compromised credentials. Typical boundaries include presentation, business logic, data access, security administration, and deployment control.

Least privilege applies to human users, workloads, pipelines, service accounts, and administrators. It requires explicit permissions, strong authentication, short-lived credentials where possible, protected secrets, and periodic access review. A cloud provider’s shared-responsibility model does not transfer application security to the provider: the provider may secure underlying facilities and managed-service infrastructure, while the customer remains responsible for configuration, identities, data, and workload code according to the service model.

2.2 Resilience and failure domains

A failure domain is a set of resources that may fail together, such as a host, availability zone, region, network segment, or administrative account. A resilient design identifies likely failure domains and places critical dependencies accordingly. Replication is not automatically resilience: synchronous replication may preserve consistency but increase latency; asynchronous replication may reduce latency but create an RPO greater than zero.

Resilience also includes graceful degradation, queue-based load levelling, retries with bounded backoff, idempotency, circuit breakers, health checks, tested backups, and rehearsed recovery. Retrying a non-idempotent payment request without an idempotency key can create duplicate charges, so reliability mechanisms must respect business semantics.

3. Reference architectures and design patterns

A reference architecture is a generalised, documented arrangement of capabilities, components, interfaces, controls, and operating practices for a class of systems. It is not a deployment blueprint. It accelerates design by providing proven structures and vocabulary, but it must be adapted to requirements and provider realities.

A common cloud application reference architecture contains:

1. users and external systems;
2. DNS, content delivery, and an edge protection layer;
3. an identity and access boundary;
4. public-facing ingress and private application services;
5. asynchronous messaging for decoupling;
6. transactional and analytical data stores selected by access patterns;
7. central logging, metrics, tracing, security monitoring, and audit evidence; and
8. automated delivery and infrastructure management.

Figure: A layered reference architecture showing application flow and cross-cutting controls.

Patterns provide reusable solutions to recurring design problems. Examples include:

• Three-tier architecture: separates presentation, application, and data responsibilities. It is understandable and maintainable, but can become rigid for highly distributed workloads.
• Event-driven architecture: producers publish events and consumers react asynchronously. It supports decoupling and scale, but introduces eventual consistency, ordering, replay, and observability challenges.
• Microservices: divides a system around independently deployable business capabilities. It can improve team autonomy and scaling, but increases operational and testing complexity. It is not automatically superior to a modular monolith.
• Strangler pattern: gradually replaces parts of a legacy system behind a controlled interface. It reduces migration risk but requires careful routing, data ownership, and coexistence management.
• Bulkhead pattern: isolates resources so that failure in one workload does not exhaust shared capacity.
• Circuit breaker: stops calls to an unhealthy dependency for a period, allowing recovery and preventing cascading failure.
• Saga pattern: coordinates a distributed business transaction through local transactions and compensating actions. It requires explicit handling of partial completion and compensation failure.

Patterns should be selected because they address a demonstrated problem. Pattern adoption without appropriate scale, team capability, or operational maturity creates accidental complexity.

4. Architecture decision records

An ADR is a concise record of a significant architecture decision. It preserves context for future engineers and makes trade-offs auditable. A practical ADR structure is:

An ADR should not pretend that an uncertain decision is permanent. It should state triggers for review, such as a changed regulation, a capacity threshold, a new provider capability, or evidence that a quality objective is not being met. ADRs should link to requirements, threat models, cost estimates, diagrams, and implementation work.

Worked example: an ADR for asynchronous order processing

Context: An online retailer experiences variable demand and must not lose accepted orders during payment-provider latency. The order API must acknowledge a valid request quickly, while fulfilment can occur later. The organisation has a managed queue service and requires traceable order status.

Alternatives: (1) synchronous API-to-fulfilment calls; (2) a managed queue between order acceptance and fulfilment; (3) a distributed workflow service.

Decision: Use a durable managed queue between order acceptance and fulfilment, with an idempotency key, dead-letter handling, encryption, monitoring, and a status store. The API acknowledges only after the order and message are durably recorded according to the selected consistency guarantee.

Consequences: The design absorbs bursts and isolates payment or fulfilment delays. It introduces eventual consistency, duplicate-delivery handling, queue monitoring, and a customer-facing pending status. The team must define message retention, replay procedures, and reconciliation.

This ADR is stronger than “use queues” because it explains why the choice was made, what it costs, and how it will be operated.

5. Adoption and well-architected frameworks

Frameworks operate at different levels and should not be confused.

5.1 Cloud adoption frameworks

A cloud adoption framework helps an organisation change its people, governance, processes, platform capabilities, and operating model. It commonly addresses strategy, organisation, governance, people, security, platform, operations, and migration or modernisation. Its central question is: How can the organisation adopt and operate cloud capabilities successfully?

A typical adoption sequence includes defining outcomes, assessing readiness, establishing a landing zone, setting governance and identity controls, migrating or modernising workloads, and continuously improving operations. The sequence is iterative rather than strictly linear.

5.2 Well-architected frameworks

A well-architected framework evaluates an individual workload or solution against quality attributes. Major provider frameworks use different terminology, but recurring pillars include operational excellence, security, reliability, performance efficiency, cost optimisation, and sustainability. The central question is: How well is this workload designed and operated against recognised architectural concerns?

A review should produce evidence and actions, not a ceremonial score. Useful evidence includes recovery-test results, access reviews, deployment histories, monitoring dashboards, cost allocation reports, load-test results, and incident reviews. A workload can score well in one pillar and poorly in another; the result is a prioritised risk register, not a universal certificate.

Frameworks from standards bodies and cloud providers are valuable, but they reflect particular scopes and assumptions. They may omit local law, sector-specific controls, procurement constraints, accessibility, or organisational culture. Architects must map framework recommendations to the organisation’s own control objectives.

6. Governance, regulation, ethics, and AI

Architecture governance establishes decision rights, review points, standards, exception handling, and evidence requirements. It should be proportionate: high-risk systems require deeper review than low-risk internal tools. Governance mechanisms may include reference designs, policy-as-code, approved service catalogues, tagging standards, security gates, architecture forums, and post-implementation reviews.

Regulatory analysis should identify the applicable jurisdiction, data categories, lawful purpose, retention and deletion obligations, breach reporting, auditability, accessibility, and third-party responsibilities. Data residency is not identical to data sovereignty: location may be one factor among legal control, access rights, provider arrangements, and applicable foreign law. Compliance is a system property supported by people and evidence, not a checkbox attached to a provider logo.

Ethical issues include excessive surveillance, discriminatory automated decisions, inaccessible services, opaque consent, unsafe defaults, and use of data beyond the purpose understood by users. Architects should apply data minimisation, purpose limitation, explainability appropriate to the risk, human oversight, and secure deletion.

AI services can assist requirements analysis, threat-model drafting, log summarisation, code generation, and architecture exploration. They also introduce risks: confidential data may be disclosed to an unauthorised service; generated recommendations may contain insecure assumptions; and outputs may be difficult to explain or verify. AI-generated artefacts require human review, approved data handling, provenance, testing, and accountability. AI should support architectural judgement rather than replace responsible decision-makers.

7. Integrated case: modernising a public benefits platform

This is an illustrative case. A national benefits agency operates a legacy application that receives applications, verifies eligibility, and issues payment instructions. Peak demand occurs after policy announcements. Applicants report slow responses, and auditors require complete records of decisions and access. The agency must protect sensitive personal data, retain records according to law, and provide service continuity.

Background and problem

The existing system uses a single database and manual deployment. A failure during a previous demand spike caused a two-day backlog. The agency’s initial proposal is to move the application unchanged to cloud virtual machines. This may address hardware refresh but does not automatically address bottlenecks, recovery, auditability, or demand elasticity.

Analysis

Stakeholder workshops identify these initial requirements:

• applications must be submitted through an accessible web service;
• the service should support 2,000 concurrent sessions during forecast peaks;
• 95% of read requests should complete within three seconds under the agreed workload;
• accepted applications must not be silently lost;
• recovery time must be no more than four hours for the defined regional failure scenario;
• decision records must be tamper-evident and retained for the statutory period;
• privileged access must use strong authentication and be auditable; and
• personal data must be encrypted in transit and at rest and processed only in approved locations.

The team separates requirements from solutions. “Use containers” is not accepted as a requirement; it is evaluated as one implementation option. Threat modelling identifies account takeover, malicious document upload, insider misuse, denial of service, and unauthorised data export. A data classification exercise distinguishes identity data, supporting documents, decisions, and operational telemetry.

Approach and solution

The target architecture uses a protected edge, federated identity, stateless application services across multiple failure domains, a durable intake queue, a managed relational store for transactional decisions, object storage for documents, and a separate analytics environment with controlled data minimisation. Immutable audit records are sent to restricted storage. Infrastructure and deployment are automated, while policy checks prevent public exposure of sensitive storage.

The design applies the strangler pattern: low-risk application functions are moved first behind an API boundary, while the legacy system remains responsible for selected functions. A reconciliation process compares records during transition. An ADR documents the choice of asynchronous intake because it protects the system from bursts, while the user interface communicates that an application is received but processing may be pending.

Outcome and learning points

In a controlled pilot, load testing identifies a slow document-validation dependency. Rather than increasing every server, the team introduces bounded concurrency and queue-based processing. Recovery exercises reveal that backups exist but restoration procedures are incomplete; the runbook is corrected and retested. Cost allocation shows that document retention is the largest variable expense, leading to a legally reviewed lifecycle policy.

The case demonstrates several principles: requirements must be measurable; migration is an architectural change, not merely infrastructure relocation; resilience requires tested recovery; auditability must be designed; and frameworks are useful when they produce evidence and prioritised action.

8. Challenges and limitations

Architecture requirements are often incomplete, contradictory, or politically negotiated. Stakeholders may request unrealistic availability at an unjustified cost, or demand portability while also requiring deep use of proprietary services. Estimates may be distorted by uncertain demand, weak baseline data, or optimistic assumptions.

Cloud abstractions can conceal dependencies. A managed service reduces operational work but does not eliminate quota limits, regional dependencies, provider outages, licensing obligations, or data-exit costs. Distributed systems make consistency, time, retries, and failure harder to reason about. Multi-cloud designs may improve bargaining position or resilience in selected cases, but they can multiply skills, tooling, security controls, and operational complexity.

Frameworks can encourage box-ticking. Patterns can be misapplied. ADRs can become stale. Diagrams can omit human procedures and external dependencies. These limitations are controlled through explicit assumptions, measurable objectives, testing, ownership, review dates, and feedback from real incidents and operations.

Best-practice checklist

• Start with outcomes and stakeholder risks, not provider services.
• Write quality requirements with thresholds, context, and verification methods.
• Identify failure domains, recovery objectives, data classifications, and dependencies early.
• Prefer simple, modular designs unless complexity solves a demonstrated problem.
• Automate infrastructure, testing, security checks, and evidence collection where appropriate.
• Use ADRs for consequential decisions and record rejected alternatives.
• Treat identity, observability, cost management, and governance as cross-cutting architecture concerns.
• Test resilience, restoration, performance, security controls, and operational procedures.
• Review frameworks critically and adapt them to law, sector, organisation, and workload.
• Revisit architecture when evidence, risk, regulation, or business strategy changes.

Chapter Summary

Cloud architecture converts business and stakeholder intent into capabilities and measurable constraints. Functional requirements describe behaviour, while non-functional requirements define quality, operating conditions, and boundaries. Good requirements are specific, prioritised, traceable, and verifiable. Availability, RTO, and RPO must be defined with clear measurement assumptions.

Architecture principles provide durable guidance for security, automation, resilience, least privilege, observability, data management, and reversibility. Reference architectures and patterns accelerate design but must be adapted rather than copied. ADRs preserve context, alternatives, consequences, and review conditions. Cloud adoption frameworks address organisational readiness and transformation; well-architected frameworks assess workload quality attributes. Neither replaces professional judgement, evidence, governance, regulatory analysis, or ethical responsibility.

Key Terms

Requirement: A capability, condition, or constraint that a system or organisation must satisfy.

Functional requirement: A statement of behaviour or service the system must provide.

Non-functional requirement: A quality, operating condition, or constraint governing the system.

Quality attribute: A measurable characteristic such as security, availability, or maintainability.

Constraint: An imposed boundary that limits solution choices.

Assumption: A condition accepted as true for planning or design purposes.

Acceptance criterion: A condition used to judge whether a requirement has been met.

Availability: The proportion of an agreed period during which a service is usable.

RTO: Maximum acceptable time to restore service after disruption.

RPO: Maximum acceptable period of data loss measured in time.

Failure domain: A group of resources likely to fail together.

Architecture principle: A durable rule guiding architecture decisions.

Reference architecture: A reusable model for a class of systems.

Design pattern: A recurring solution to a recurring design problem.

ADR: Architecture decision record documenting context, choice, alternatives, and consequences.

Cloud adoption framework: Guidance for organisational transformation and cloud adoption.

Well-architected framework: Guidance for evaluating workload quality attributes.

Shared responsibility: Allocation of security and operational responsibilities between provider and customer.

Policy as code: Machine-readable policies that can be automatically evaluated or enforced.

Review Questions

Short Answer Questions

1. What is the difference between a functional requirement and a non-functional requirement?
2. Define RTO and RPO.
3. Why should an architecture principle include implications and exceptions?
4. What is the purpose of an ADR?
5. Distinguish a cloud adoption framework from a well-architected framework.

Long Answer Questions

1. Explain how a business outcome can be transformed into a measurable architecture requirement. Include an example and verification method.
2. Discuss the trade-offs involved in using managed cloud services.
3. Explain how separation of concerns and least privilege contribute to cloud security and resilience.
4. Compare microservices, a modular monolith, and event-driven architecture as architectural choices.
5. Describe how governance, regulation, and ethics should influence the design of a cloud system handling personal data.

Analytical / Application Questions

1. A service operates for 30 days and has a 99.95% availability objective. Calculate the approximate maximum unavailable time in minutes, state your assumptions, and explain why the result is not a complete reliability specification.
2. An organisation wants multi-cloud deployment solely to avoid vendor lock-in, but its team has limited experience and its data is strongly coupled to one provider’s managed database. Analyse the decision using portability, resilience, cost, skills, and operational complexity.
3. Design the outline of an ADR for a burst-sensitive public service that must accept requests quickly but may process them asynchronously. Identify the context, alternatives, decision, and at least three consequences.

Multiple Choice Questions with Answers

Question 1

Which statement is the best example of a measurable non-functional requirement?

A. The system shall be modern.

B. The system shall use containers.

C. 95% of standard searches shall return within two seconds under the agreed peak workload.

D. The system shall be user-friendly.

Correct Answer: C. 95% of standard searches shall return within two seconds under the agreed peak workload.

Question 2

For a 30-day month, approximately how many minutes of unavailability correspond to a 99.9% availability objective?

A. 4.32 minutes

B. 43.2 minutes

C. 432 minutes

D. 4,320 minutes

Correct Answer: B. 43.2 minutes

Question 3

What does an RPO primarily specify?

A. The maximum acceptable time to restore service

B. The maximum acceptable data-loss period measured in time

C. The number of users supported per second

D. The percentage of successful deployments

Correct Answer: B. The maximum acceptable data-loss period measured in time

Question 4

What is the principal purpose of an architecture decision record?

A. To replace all technical documentation

B. To record context, alternatives, decision, and consequences

C. To guarantee that a design never changes

D. To provide a provider-specific service catalogue

Correct Answer: B. To record context, alternatives, decision, and consequences

Question 5

Which pattern is most directly associated with gradually replacing parts of a legacy system?

A. Bulkhead

B. Circuit breaker

C. Strangler

D. Saga

Correct Answer: C. Strangler

Question 6

Which statement best describes a well-architected framework?

A. It is a workload-focused guide for evaluating architectural quality attributes.

B. It is a programming language specification.

C. It is a legal contract that guarantees availability.

D. It is a replacement for requirements elicitation.

Correct Answer: A. It is a workload-focused guide for evaluating architectural quality attributes.

Question 7

Why is idempotency important when implementing retries?

A. It guarantees zero network latency.

B. It prevents a repeated request from causing unintended duplicate effects when the operation supports it.

C. It removes the need for authentication.

D. It makes every database transaction synchronous.

Correct Answer: B. It prevents a repeated request from causing unintended duplicate effects when the operation supports it.

Question 8

Which is a likely consequence of event-driven architecture?

A. It always eliminates operational complexity.

B. It removes the need for monitoring.

C. It can introduce eventual consistency and message-ordering concerns.

D. It guarantees that messages are processed exactly once.

Correct Answer: C. It can introduce eventual consistency and message-ordering concerns.

Question 9

Which practice best supports least privilege?

A. Giving every developer permanent administrator access

B. Using shared credentials for convenience

C. Granting only required permissions and reviewing them periodically

D. Disabling audit logs to reduce storage cost

Correct Answer: C. Granting only required permissions and reviewing them periodically

Question 10

What is a key limitation of copying a reference architecture without analysis?

A. Reference architectures cannot contain security controls.

B. The copied design may not satisfy the workload’s specific requirements, constraints, or regulations.

C. Reference architectures are only useful for on-premises systems.

D. A copied design automatically becomes provider-independent.

Correct Answer: B. The copied design may not satisfy the workload’s specific requirements, constraints, or regulations.