Be Wise Apps
Leer en español · Lire en français · Auf Deutsch lesen
Section 2.7 of 2.8 · Intermediate · 22 min read
Security, usability, interoperability, cost and sustainability as qualities
Video lesson
5 min · narrated, with captionsListen only (audio)
Read the transcript
This lesson covers the remaining qualities: security, usability, interoperability, cost, sustainability and a few more that are easy to overlook until an audit.
When you choose a bank, you care that it keeps your money safe, that its app is easy to use, that it works with other banks, that its fees are fair and, perhaps, that it doesn't waste energy. None of these is a feature you can point to on a screen. Each is a quality of the whole service, and architects must make each one specific enough to design for and check.
Security is the ability to protect data and functions from unauthorised use, while still serving those who are authorised. The international standard lists six sub-characteristics. Confidentiality means only authorised parties can read data. Integrity means data and code aren't altered without authorisation. These come from the classic CIA triad. Non-repudiation means actions can't be denied later. Accountability means they can be traced to whoever did them. Authenticity means an identity can be proved. And resistance, new in twenty twenty three, means the system keeps working while under attack. The A of the triad, availability, sits under reliability in this model.
The system must be secure can't be tested. A security scenario names the attacker, the attack, the target and a measure. For example, an attacker tries leaked passwords at fifty attempts a second. The system detects the pattern within two minutes, and challenges or blocks the sources. Security tactics act at different times. Before an attack, resist it: authenticate, authorise, limit exposure, encrypt and validate input. During an attack, detect it, then react: revoke access, lock accounts, block traffic and alert people. Afterwards, recover from clean backups, and use the audit trail to learn what happened. Security is a property of the whole structure, not a component you add at the end.
Usability, now called interaction capability, is mostly interaction design, but parts reach deep into the structure. Responsiveness is one. About a tenth of a second feels instant, about one second keeps your flow of thought, and about ten seconds is the limit of attention. Undo, cancel and working offline are architectural too. They're much cheaper to design in than to retrofit. Accessibility is increasingly a legal constraint. The Web Content Accessibility Guidelines, version two point two, define testable criteria, and level double A is the usual benchmark. In the European Union, the European Accessibility Act has applied since the twenty eighth of June twenty twenty five to many services, including banking and online shops. So capture it early.
Interoperability means systems can exchange information and use it. Agreeing on format isn't enough; they must agree on meaning. Is an amount of one thousand and fifty in pence or pounds? Most integration failures are about meaning. Safety is different from security. Security protects the system from people with harmful intent. Safety protects people from the system, even when nobody is malicious. Observability is how well you can understand what's wrong from the data a system emits. Recovery time, and so availability, depends on it. And laws create qualities too: where data is stored, proving who did what and when, and how long data is kept. Treat them as constraints with clear acceptance criteria.
Cost and carbon are best measured per unit of work. An order service costs twenty four thousand pounds a month and handles three million orders. That's nought point eight pence per order. For carbon, the Software Carbon Intensity formula multiplies energy by the carbon intensity of the electricity. Twelve hundred kilowatt hours at two hundred and fifty grams each is three hundred kilograms. Add sixty kilograms for the emissions of making the hardware: three hundred and sixty kilograms. Divide by three million orders, and you get nought point one two grams of carbon dioxide equivalent per order. Caching menus to cut energy by twenty five per cent brings that down to nought point nought nine five grams per order. Only real reductions count. Buying offsets doesn't lower the score. And because both measures are per order, they reward efficiency rather than penalising growth.
The full section has more security scenarios, the standards for interoperability and safety, and a summary table of example measures. Next, in Section two point eight, the last in this chapter, we look at how to find, rank and trade off qualities. See you there.
What you need to know
- Security starts from confidentiality, integrity and availability; ISO/IEC 25010:2023 lists confidentiality, integrity, non-repudiation, accountability, authenticity and resistance, with availability under reliability.
- Security scenarios name the attacker, the attack, the target and a measurable response such as detection time or data exposed; tactics resist, detect, react to and recover from attacks.
- Interaction capability (formerly usability) affects architecture through responsiveness, undo, cancel and offline working; accessibility to WCAG 2.2 level AA is increasingly a legal constraint.
- Interoperability needs agreement on meaning as well as format; industry standards and adapters reduce the cost.
- Cost and carbon are best expressed per unit of work; the SCI specification (ISO/IEC 21031:2024) computes ((E x I) + M) per R and counts only real reductions.
- Safety, observability, data residency, auditability and retention are qualities too, and should be captured early as testable constraints.
Security as a quality attribute
Security is the system's ability to protect data and functions from unauthorised access and use while still serving those who are authorised. Architects often start from the CIA triad: confidentiality (only authorised parties can read data), integrity (data and code are not altered without authorisation, and alterations are detectable) and availability (authorised users can use the service when they need it). Attacks map onto the three: stealing customer records breaks confidentiality, changing a payee's bank details breaks integrity, and a denial-of-service attack breaks availability.
ISO/IEC 25010:2023 refines the picture. Its security characteristic has six sub-characteristics: confidentiality, integrity, non-repudiation (actions or events can be proved to have taken place, so that a party cannot later deny them), accountability (actions can be traced uniquely to the entity that performed them), authenticity (the identity of a subject or resource can be proved to be the one claimed) and, new in the 2023 edition, resistance (the product keeps operating as intended while under attack by a malicious actor). Availability appears under reliability in that model, which is why it was covered in Section 2.5.
The security sub-characteristics
Writing security scenarios
"The system must be secure" cannot be designed for or tested. A security scenario names a source (who attacks, with what access), a stimulus (what they try), an artifact (what is targeted), an environment (online, during an incident, with the attacker already inside the network), a response and a measure. Measures for security are often about detection time, the amount of damage, or the time to restore, because "no attack ever succeeds" cannot be verified.
Three examples for an online bank. Credential stuffing: an external attacker tries leaked username and password pairs against the login API at 50 attempts per second from many addresses; the system detects the pattern within 2 minutes, challenges or blocks the source addresses, and accounts protected by multi-factor authentication are not taken over. Insider tampering: a support employee with legitimate access changes a customer's payee details; the change requires a second person's approval, and the audit log records who, what and when in a form that the employee cannot alter. Stolen backup: an attacker obtains a copy of last week's database backup; all personal data in it is encrypted with keys stored separately, so no customer data is readable.
Notice that each scenario implies different architecture: rate limiting and anomaly detection at the edge, a four-eyes approval workflow and tamper-evident logs, and encryption with separate key management. Finding these scenarios systematically is the job of threat modelling, covered in Chapter 8.
Security tactics: an overview
Bass, Clements and Kazman group security tactics by when they act. Resist attacks: identify, authenticate and authorise actors, limit access and exposure (fewer open ports, fewer public endpoints, least privilege), encrypt data in transit and at rest, separate entities (sensitive data in its own store or network segment), change default settings and validate input. Detect attacks: intrusion detection, detecting denial of service, verifying message integrity and spotting unusual delays or patterns. React to attacks: revoke access, lock accounts after failed log-ins, inform operators and users. Recover from attacks: restore a known good state (the availability tactics again) and keep an audit trail to understand what happened and support non-repudiation.
This section only introduces the families. Principles such as defence in depth and least privilege, identity protocols, encryption, zero trust and supply-chain security are the subject of Chapter 8. The architectural point here is that security is a property of the whole structure, not a component you add at the end: where trust boundaries fall, which component holds which data, and how services authenticate one another are early, expensive-to-change decisions.
Tactics before, during and after an attack
Usability, interaction capability and accessibility
ISO/IEC 25010:2023 renamed usability interaction capability: the degree to which a product can be interacted with by specified users to exchange information through the user interface to complete specific tasks. Its sub-characteristics are appropriateness recognisability, learnability, operability, user error protection, user engagement (which replaced user interface aesthetics), inclusivity, user assistance and self-descriptiveness. Much of this is interaction design rather than architecture, but several usability concerns reach deep into the structure.
Responsiveness is the obvious one. Long-standing human-factors guidance, popularised by Jakob Nielsen, gives three limits: about 0.1 seconds feels instantaneous, about 1 second keeps the user's flow of thought, and about 10 seconds is the limit of attention. Meeting them may require caching, asynchronous processing with progress feedback, or optimistic updates. Undo and cancel are architectural: supporting undo the last five actions
needs commands that can be reversed, and cancelling a long upload needs an operation that can be interrupted cleanly. Working offline in a mobile app requires local storage and synchronisation with conflict handling. These are much cheaper to design in than to retrofit.
Accessibility, the ability of people with disabilities to use the product, is increasingly a legal constraint rather than a preference. The Web Content Accessibility Guidelines version 2.2 (WCAG 2.2), a W3C Recommendation since October 2023, define testable success criteria at levels A, AA and AAA; level AA is the usual legal and procurement benchmark. WCAG 2.2 added nine criteria, including minimum target sizes for pointer input and accessible authentication (no step of logging in may depend on a cognitive function test, such as remembering a password or transcribing a code, unless the user is offered an alternative method or help such as pasting from a password manager; a few other narrow exceptions apply). In the European Union, the European Accessibility Act (Directive (EU) 2019/882) has applied since 28 June 2025 to many consumer products and services, including e-commerce, banking services, e-books and passenger transport services. For an architect, accessibility is therefore a constraint to capture early: it affects the choice of front-end framework, the design system, the authentication flow and the testing pipeline (automated accessibility checks in continuous integration, plus manual testing with assistive technologies).
Interoperability
Interoperability is the degree to which two or more systems can exchange information and use the information they exchange. ISO/IEC 25010 places it under compatibility, alongside co-existence. It has two levels. Syntactic interoperability means the systems agree on format and protocol: both speak HTTP and JSON. Semantic interoperability means they agree on meaning: "amount": 1050 is pence, not pounds; status: "closed" means paid, not cancelled. Most integration failures are semantic.
Industries reduce the cost of semantic agreement with shared standards: HL7 FHIR for exchanging healthcare records, ISO 20022 for financial messages, GTFS for public transport timetables. Architectural tactics include discovering services through a registry, tailoring interfaces with adapters and translators, and managing versions explicitly so that older partners keep working. An interoperability scenario might read: A new hospital joins the network and exchanges patient summaries using FHIR R4 resources within 4 weeks, without changes to the core record service.
Cost as a quality
Cost is rarely listed in quality models, yet it constrains every architectural decision. Separate build cost (the effort to create the system), run cost (infrastructure, licences, third-party services, support) and change cost (the effort for each future change, which modifiability is about). In the cloud, run cost is variable and directly shaped by architecture: chatty services pay for network transfer, over-provisioned clusters pay for idle capacity, and a careless query pattern can multiply a database bill.
A useful way to make cost a quality attribute is unit cost: cost per transaction, per active user or per order. Unlike a total monthly bill, it shows whether the architecture becomes more or less efficient as the business grows, and it can be written as a scenario: At 3 million orders a month, infrastructure cost stays below 1 pence per order.
FinOps practices for managing this are covered in Chapter 10.
Worked example
Worked example: unit cost and carbon per request for a food-delivery API
An order API runs on a cluster costing £24,000 a month and handles 3,000,000 orders a month. An analysis estimates its energy use at 1,200 kWh a month, on a grid averaging 250 g CO2e per kWh, with 60 kg CO2e of embodied hardware emissions allocated to it each month. The Software Carbon Intensity formula is SCI = ((E x I) + M) per R.
| Cost per order | £24,000 / 3,000,000 = £0.008, so 0.8 pence per order |
|---|---|
| Operational emissions (E x I) | 1,200 kWh x 250 g = 300,000 g = 300 kg CO2e |
| Add embodied emissions (M) | 300 + 60 = 360 kg CO2e |
| Divide by the functional unit (R = one order) | 360,000 g / 3,000,000 = 0.12 g CO2e per order |
| Change: cache menus, cut energy by 25% | E = 900 kWh: (900 x 250 + 60,000) / 3,000,000 = 0.095 g per order |
| Change: run batch jobs in a region at 50 g per kWh | Lowers I for that share of the load; carbon-aware scheduling reduces the score without changing the code |
| Growth to 6,000,000 orders on the same cluster | Cost per order halves to 0.4 pence; carbon per order falls too, as long as energy grows less than in proportion (idle servers still draw power, so higher utilisation is more efficient) |
Both metrics are rates per unit of useful work, so they reward efficiency rather than penalising growth.
The SCI specification counts only real reductions: buying offsets or renewable energy certificates does not lower the score.
Energy and grid figures are estimates; what matters is measuring them the same way over time so that changes can be compared.
Energy efficiency and sustainability
Software does not emit carbon itself, but the hardware it runs on consumes electricity and embodies the emissions of its manufacture. The Green Software Foundation's Software Carbon Intensity (SCI) specification, published by ISO as ISO/IEC 21031:2024, defines a rate: operational emissions (energy E times the carbon intensity I of the electricity) plus embodied emissions M, divided by a functional unit R such as a user, an API call or an order. It identifies three levers: energy efficiency (use less electricity for the same work), hardware efficiency (use fewer devices, and use them more fully and for longer) and carbon awareness (run flexible work when and where electricity is cleaner).
Architecture affects all three. Right-sizing and higher utilisation improve hardware efficiency; caching, efficient data formats and avoiding needless work improve energy efficiency; queues and batch processing make it possible to shift work in time or place. Sustainability often aligns with cost, but not always: keeping a warm standby in a second region improves availability and doubles the embodied emissions. Large AI models make the question more pressing, as Chapter 12 discusses.
Safety
Safety is freedom from unacceptable risk of harm to people, property or the environment. It differs from security: security protects the system from people with harmful intent; safety protects people from the system, including when nobody is malicious. ISO/IEC 25010:2023 added safety as a ninth characteristic, with sub-characteristics operational constraint, risk identification, fail safe, hazard warning and safe integration.
Safety-critical domains have their own standards, which impose architecture and process: IEC 61508 for functional safety in general, ISO 26262 for road vehicles, IEC 62304 for medical device software and DO-178C for airborne software. Typical tactics are a fail-safe default (a train stops when signals are lost), independent monitoring channels that can override the main controller, redundancy with voting, and strict separation of safety-critical components from everything else so that a fault in the infotainment system cannot reach the brakes. Note that fail-safe and highly available can conflict: a fail-safe system often stops, which is safe but unavailable.
Observability, an emerging quality
Observability is the degree to which you can understand a system's internal state from the outside, using the data it emits, well enough to answer questions you did not anticipate when it was built. It is not listed in ISO/IEC 25010, though analysability and accountability touch on it. In distributed systems it has become a quality in its own right, because recovery time, and therefore availability, depends on how quickly people can find out what is wrong. Architecturally it requires structured logs, metrics and distributed traces with correlation identifiers that follow a request across services, designed in from the start. A scenario might be: For any failed checkout, an on-call engineer can identify the failing service and the request's path within 5 minutes.
See observability in Chapter 9.
Legal and regulatory qualities
Laws and regulations create qualities that are easy to overlook until an audit. Data residency requires certain data to be stored or processed in a particular country or region; it may come from sector rules, public-sector contracts or customer demands. The EU GDPR itself does not require data to stay in the EU, but transfers outside it need a legal basis and safeguards, which in practice shapes where services and backups run. Auditability means being able to show, later, who did what and when: tamper-evident logs, retained for a defined period, with clocks synchronised. Retention and deletion rules require data to be kept for a minimum time (financial records) and deleted after a maximum time or on request (personal data), which is hard in systems with many copies, caches and backups. Explainability and human oversight are required for some automated decisions, as the EU AI Act chapter explains.
Treat these as constraints with acceptance criteria: "customer data for German public-sector clients is stored and processed only in EU regions, including backups and logs" is testable, and it rules out some managed services immediately. Privacy requirements are covered in privacy by design and the GDPR.
Summary: the qualities in this section and example measures
| Quality | Example response measure | Typical architectural lever |
|---|---|---|
| Security (confidentiality) | No personal data readable from a stolen backup | Encryption at rest with separately managed keys |
| Security (accountability) | Every change to payee details attributable to one person, logs tamper-evident | Central audit log, write-once storage |
| Interaction capability | 95% of first-time users complete checkout without help in under 3 minutes | Simple flows, fast responses, undo |
| Accessibility | All customer journeys meet WCAG 2.2 level AA | Accessible design system, automated checks in CI |
| Interoperability | New partner integrated using the published API standard within 4 weeks | Standard formats, adapters, versioned APIs |
| Cost | Infrastructure under 1 pence per order at 3 million orders a month | Right-sizing, caching, autoscaling |
| Sustainability | SCI below 0.1 g CO2e per order | Efficiency, utilisation, carbon-aware scheduling |
| Observability | Failing service identified within 5 minutes for any failed request | Structured logs, metrics, distributed tracing |
| Data residency | All data for EU clients, including backups, stays in EU regions | Region-pinned storage and processing |
Check your understanding
What is the difference between accountability and non-repudiation?
Accountability means actions can be traced to the entity that performed them; non-repudiation means there is proof strong enough that the entity cannot later deny the action.
Why does "undo the last five actions" count as an architectural requirement, not only a user-interface one?
Because it requires operations to be modelled as reversible commands with stored history, which affects how state changes are structured throughout the system.
An API uses 800 kWh a month on a grid at 200 g CO2e per kWh, has 40 kg of embodied emissions allocated, and serves 2,000,000 requests. What is its SCI per request?
(800 x 200 g + 40,000 g) / 2,000,000 = 200,000 / 2,000,000 = 0.1 g CO2e per request.
How does safety differ from security?
Security protects the system and its data from people with harmful intent; safety protects people and the environment from harm the system could cause, even with no malicious actor.
Sources and further reading
Have a question about this section? ArchitectBot, the course’s AI study assistant, answers from the course first.
Ask: “How do I write a security requirement for our customer portal that the testers can actually verify?”