The Solution Architecture and Non-Functional Requirements Standard: Designing for Supportable Value

A solution must do the required job and remain dependable in real use. Agree the reliability, security, performance, data, integration and support conditions alongside its functions. Check ownership, evidence and trade-offs before committing to delivery.

1. The Market Connection Context

The recognisable failure is a solution approved because its feature list is complete while availability, recovery, security, privacy, accessibility, performance, data quality, integration behaviour and support ownership remain assumptions. The gap appears after launch as lost transactions, inaccessible journeys, fragile interfaces, manual reconciliation, uncontrolled access or incidents that no team is prepared to own.

Accepted product and value boundary
→ business criticality and affected populations
→ quality-attribute scenarios
→ threats, data and integration conditions
→ architecture options and explicit trade-offs
→ support and acceptance evidence
→ accept, validate, change, defer or stop

By [decision date], the CTO will assign ACCEPT, VALIDATE, CHANGE, DEFER or STOP to a bounded solution architecture and non-functional requirement set, naming business criticality, affected populations, quality attributes, data and integration boundaries, threat and failure conditions, support ownership, acceptance evidence and residual risk. Approval authorises a design boundary, not delivery, investment return or production release.

Use this after The Build, Buy, Configure, Integrate or Stop Decision: An Executive Technology Investment Playbook has selected an investment route and before The Product Delivery Governance Standard: From Discovery through Production Acceptance authorises delivery. The Software Investment Business Case: Scope, Total Cost, Risk and Operating Economics separately establishes the software investment business case. This guide does not price the solution, choose a supplier, create detailed implementation plans, waive qualified control authority or prove that the product will produce its intended market outcome.

Working files

• Architecture Charter and Business Criticality Register
• Quality Attribute Scenario and Acceptance Matrix
• Threat Data Integration and Trade-off Ledger
• Architecture Decision Support and Review Register

NIST SP 800-160 Volume 1 treats security as a systems-engineering concern across the lifecycle (Engineering Trustworthy Secure Systems, VERIFIED official standard). NIST's Secure Software Development Framework integrates security practices into software development (SSDF, VERIFIED official framework). CISA's Secure by Design guidance places responsibility for secure product outcomes with technology producers rather than relying only on users (Secure by Design, VERIFIED official guidance). W3C's Web Content Accessibility Guidelines 2.2 define testable accessibility success criteria (WCAG 2.2, VERIFIED normative standard). The UK Government Service Standard connects user needs, security, accessibility, performance and reliable operation (Service Standard, VERIFIED official standard). These sources support disciplines, not a universal architecture. The method below is PROPOSED; local thresholds are REQUIRES VALIDATION, and architecture conclusions remain INFERRED until supported by retained tests and qualified acceptance.

2. The Leadership vs. Delegation Boundary

The reader recognises that architecture requires business-criticality analysis, quality attributes, trade-offs, threat and risk review, operating ownership and evidence-based acceptance.

An internal team can lead when it has authority to inspect systems and operations, access affected users, and challenge feature, timing and vendor assumptions. Independent support is justified where supplier design, legacy coupling, specialist risk, disputed criticality or executive deadline pressure weakens challenge. Architects can recommend trade-offs but cannot accept business harm; security cannot define product value; product sponsors cannot waive legal, privacy or accessibility obligations. Stop for fabricated tests, concealed dependencies, unavailable support owners or a predetermined architecture.

Use a narrower specialist when the unresolved decision is limited to one qualified concern such as accessibility, privacy, security, resilience or data integration; preserve the executive sponsor's decision and the organisation's operating ownership. Escalate a failed mandatory condition or unresolved cross-domain trade-off to the named product/technology authority before delivery commitment. Ask providers how they expose assumptions, preserve organisation-controlled artefacts and accounts, evidence support and recovery, transfer knowledge and execute exit. The Solution Architecture and Non-Functional Requirements Standard: Designing for Supportable Value is the anchor for product solution architecture; The Automation Architecture Decision: Rules, Platforms, Agents, Custom Software or No Build remains the anchor for workflow automation architecture and The Management Intelligence Architecture Playbook: From Source Systems to Decision Interface for decision-intelligence architecture. Reuse evidence only with matching boundary and retain one shared decision ID for combined work.

3. The Step-by-Step Execution Standard

Step 01: Charter the architecture acceptance decision

Purpose and decision served Bound the value, solution and authority under assessment.

Accountable owner CTO.

Delegated lead and contributors Solution architect, product sponsor, operations, security, data and finance owners.

Preconditions, inputs and access Accepted product opportunity, The Build, Buy, Configure, Integrate or Stop Decision: An Executive Technology Investment Playbook investment route and authoritative system access.

Actions

1. State the value outcome, users, business process and solution boundary.
2. Define allowed dispositions, excluded decisions and acceptance date.
3. Record evidence access, conflicts, qualified authority and stop rights.

Evidence to retain Signed charter, prior decision references, assumptions and conflict log.

Decision or scoring rule Proceed only when one executive owns the architecture acceptance decision.

Output and template Architecture charter and business criticality register.

Acceptance gate CHARTERED, CHANGE or STOP.

Leadership checkpoint CTO confirms architecture acceptance does not authorise delivery or release.

Human control point Product and technology owners accept the outcome and boundary.

Failure modes and safeguards A technology or vendor preference is not accepted as a charter.

Change, stop or escalation condition Stop if product value, accountable owner or system boundary is missing.

Handoff to the next step The charter controls criticality analysis.

Step 02: Classify business criticality

Purpose and decision served Determine the consequence of failure before selecting technical thresholds.

Accountable owner Product Sponsor.

Delegated lead and contributors Operations, finance, customer, risk, service and continuity owners.

Preconditions, inputs and access Charter, process maps, service records, obligations and affected populations.

Actions

1. Identify value, service, safety, legal, financial and operational consequences of loss or degradation.
2. Define affected populations, transaction or service boundaries and critical periods.
3. Record tolerance, recovery priority, manual fallback and evidence limitations.

Evidence to retain Criticality claims, authoritative sources, impact scenarios and owner acceptance.

Decision or scoring rule Criticality follows evidenced consequence, not system visibility or stakeholder seniority.

Output and template Business criticality rows.

Acceptance gate ACCEPT, VALIDATE, CHANGE or REJECT.

Leadership checkpoint CEO or delegate accepts material business and customer consequences.

Human control point Operating and risk owners confirm consequence within their mandates.

Failure modes and safeguards Generic high, medium and low labels are rejected without bounded scenarios.

Change, stop or escalation condition Validate when disputed consequence could change architecture or investment.

Handoff to the next step Criticality informs affected-person and failure analysis.

Step 03: Map affected populations and operating scenarios

Purpose and decision served Expose how different users, operators and partners experience normal and adverse conditions.

Accountable owner Product Sponsor.

Delegated lead and contributors Research, accessibility, operations, support, customer and partner owners.

Preconditions, inputs and access Accepted criticality, user evidence, workflows and service channels.

Actions

1. Map primary, secondary, assisted, excluded and vulnerable populations.
2. Define normal, peak, degraded, recovery, misuse and support scenarios.
3. Record access needs, context, harm, workarounds and dependency on human intervention.

Evidence to retain Population map, research evidence, operating observations and exclusions.

Decision or scoring rule No quality claim transfers beyond its tested population and scenario.

Output and template Population and scenario rows in the criticality register.

Acceptance gate REPRESENTED, VALIDATE or EXCLUDE WITH AUTHORITY.

Leadership checkpoint Product Sponsor accepts material exclusions and support burden.

Human control point Accessibility, customer and operating owners confirm representation.

Failure modes and safeguards The ideal user journey cannot stand in for degraded or assisted operation.

Change, stop or escalation condition Expand evidence when an excluded population faces material consequence.

Handoff to the next step Scenarios become testable quality attributes.

Step 04: Define quality-attribute scenarios

Purpose and decision served Translate criticality into measurable behaviour under stated conditions.

Accountable owner CTO.

Delegated lead and contributors Architect, product, security, accessibility, performance, data and reliability owners.

Preconditions, inputs and access Accepted criticality, populations, operating scenarios and baselines.

Actions

1. Define stimulus, source, environment, affected component, required response and measure.
2. Cover reliability, availability, recovery, performance, security, privacy, accessibility, data, integration, maintainability, scalability and supportability as relevant.
3. State threshold, guardrail, evidence source, owner, exclusion and expiry.

Evidence to retain Quality scenarios, baselines, test methods, limitations and approvals.

Decision or scoring rule Every material requirement must be observable and trace to a business or affected-person consequence.

Output and template Quality attribute scenario and acceptance matrix.

Acceptance gate TESTABLE, VALIDATE, CHANGE or REJECT.

Leadership checkpoint CTO and Product Sponsor accept threshold consequences and burden.

Human control point Qualified owners approve standards and mandatory thresholds.

Failure modes and safeguards Terms such as fast, secure and scalable are rejected without scenario and measure.

Change, stop or escalation condition Reframe requirements that cannot produce evidence relevant to the decision.

Handoff to the next step Quality scenarios constrain data and integration design.

Step 05: Govern data and integration boundaries

Purpose and decision served Make information meaning, ownership and interface failure explicit.

Accountable owner CIO.

Delegated lead and contributors Data architect, integration, privacy, security, operations and supplier owners.

Preconditions, inputs and access Quality scenarios, data inventory, interfaces and source-system authority.

Actions

1. Define authoritative sources, data meaning, purpose, lineage, quality and retention.
2. Map interface contracts, dependencies, authentication, failure, retry, reconciliation and ownership.
3. Record unavailable data, manual bridges, supplier conditions and exit alternatives.

Evidence to retain Data contracts, interface records, source approvals, failure tests and limitations.

Decision or scoring rule No interface is accepted without sending, receiving, failure and reconciliation ownership.

Output and template Threat data integration and trade-off ledger.

Acceptance gate ACCEPT, CONDITIONAL, VALIDATE or BLOCKED.

Leadership checkpoint CIO resolves authoritative-source and cross-system ownership disputes.

Human control point Data, privacy and interface owners accept boundaries.

Failure modes and safeguards Connectivity success is not data meaning, integrity or recoverability proof.

Change, stop or escalation condition Block when interface failure can create unowned material harm.

Handoff to the next step Data and integration boundaries inform threat analysis.

Step 06: Model threats, misuse and control obligations

Purpose and decision served Identify adverse conditions the architecture must prevent, detect, withstand or recover from.

Accountable owner Security and Risk Executive.

Delegated lead and contributors Security architect, privacy, fraud, safety, legal, support and product owners.

Preconditions, inputs and access System boundary, populations, data flows, interfaces and criticality.

Actions

1. Model threat actors, misuse, error, abuse, privilege, supply-chain and failure paths.
2. Map preventive, detective, responsive and recovery controls to consequences.
3. Record residual risk, control owner, evidence, exception and mandatory stop condition.

Evidence to retain Threat model, control mapping, test evidence, dissent and risk decisions.

Decision or scoring rule Failed mandatory control or unlawful processing cannot be offset by product value.

Output and template Threat and control rows.

Acceptance gate CONTROLLED, CONDITIONAL, REMEDIATE or STOP.

Leadership checkpoint Product and technology executives review material residual risk.

Human control point Qualified authorities retain risk acceptance and exception rights.

Failure modes and safeguards Compliance labels and tool scans are not substitutes for system threat reasoning.

Change, stop or escalation condition Stop on unacceptable uncontrolled harm or missing lawful authority.

Handoff to the next step Quality, data and threat conditions shape architecture options.

Step 07: Construct architecture options and trade-offs

Purpose and decision served Compare credible designs against value, quality, control and operating conditions.

Accountable owner CTO.

Delegated lead and contributors Architecture, product, engineering, data, operations, finance, security and suppliers.

Preconditions, inputs and access Quality matrix, boundaries, threats, constraints and resource assumptions.

Actions

1. Construct minimum viable, resilience-protected, managed-service, reuse and defer options where credible.
2. Compare quality attributes, coupling, reversibility, control, support burden, lifecycle implications and uncertainty.
3. Record rejected options and evidence that would reopen them.

Evidence to retain Option views, decision records, trade-offs, assumptions and dissent.

Decision or scoring rule No option wins by aggregate score when a mandatory attribute or control fails.

Output and template Architecture trade-off rows.

Acceptance gate DECISION-READY, VALIDATE, CHANGE or REJECT.

Leadership checkpoint CTO and Product Sponsor accept value, risk and support trade-offs.

Human control point Attribute and control owners accept impacts within their mandates.

Failure modes and safeguards Technology novelty and vendor preference carry no automatic value.

Change, stop or escalation condition Validate when option preference depends on an unsupported material assumption.

Handoff to the next step Options require an operating support model.

Step 08: Define support, recovery and lifecycle ownership

Purpose and decision served Ensure the solution can be operated, observed, changed and retired safely.

Accountable owner CIO.

Delegated lead and contributors Service owner, engineering, support, reliability, security, data, vendor and finance owners.

Preconditions, inputs and access Decision-ready architecture options and operating criticality.

Actions

1. Define service ownership, support boundary, monitoring, incident, recovery and escalation.
2. Define change, patch, dependency, capacity, knowledge, supplier and continuity obligations.
3. Define data export, migration, decommission, evidence retention and exit responsibilities.

Evidence to retain Operating model, runbook outline, owner acceptance, supplier conditions and gaps.

Decision or scoring rule Architecture is not supportable without accepted operating authority, capability and evidence access.

Output and template Support and lifecycle rows in the architecture decision register.

Acceptance gate SUPPORTABLE, CONDITIONAL, HOLD or REJECT.

Leadership checkpoint CIO confirms support obligations are resourced, not assumed.

Human control point Operating, support and control owners accept explicitly.

Failure modes and safeguards Delivery team availability is not a permanent support model.

Change, stop or escalation condition Hold when critical recovery or support ownership is missing.

Handoff to the next step The selected option receives an acceptance evidence plan.

Step 09: Design acceptance evidence

Purpose and decision served Specify how architecture claims will be tested before relevant commitments and release gates.

Accountable owner CTO.

Delegated lead and contributors Quality engineering, security, accessibility, reliability, data, operations and independent assurance.

Preconditions, inputs and access Selected option, quality scenarios, controls and support conditions.

Actions

1. Map each material claim to test method, environment, data, owner and independent evidence need.
2. Define pass, conditional, validate and stop conditions before execution.
3. Define production-proving limits, exception, retest, expiry and residual-risk records.

Evidence to retain Acceptance plan, test definitions, environment limits, owner approvals and dissent.

Decision or scoring rule Document review cannot substitute for behavioural test where the claim concerns behaviour.

Output and template Acceptance matrix and evidence plan.

Acceptance gate TESTABLE, CONDITIONAL, VALIDATE or STOP.

Leadership checkpoint Product Sponsor accepts what pre-production evidence cannot establish.

Human control point Qualified attribute owners approve methods and thresholds.

Failure modes and safeguards Passing one environment is not universal performance or reliability proof.

Change, stop or escalation condition Redesign claims that cannot be tested within accepted risk and resources.

Handoff to the next step Evidence-ready architecture reaches human disposition.

Step 10: Make the architecture disposition

Purpose and decision served Accept, condition, change, defer or stop the bounded architecture.

Accountable owner CTO.

Delegated lead and contributors Product Sponsor, CIO, CFO, risk, security, data, accessibility and operating owners.

Preconditions, inputs and access Challenged options, trade-offs, acceptance plan, residual risk and dissent.

Actions

1. Assign ACCEPT, VALIDATE, CHANGE, DEFER or STOP.
2. State chosen option, criticality, quality thresholds, residual risk and support conditions.
3. Record separate resource authority, conditions, evidence expiry and reopening rule.

Evidence to retain Signed decision, architecture record, conditions, dissent and resource boundary.

Decision or scoring rule Only named human authority decides; aggregate scores and vendor recommendation do not.

Output and template Architecture decision support and review register.

Acceptance gate ACCEPT, VALIDATE, CHANGE, DEFER or STOP.

Leadership checkpoint Product and technology executives accept business and operating consequences.

Human control point Qualified owners retain mandate-specific conditions and objections.

Failure modes and safeguards Conditional acceptance is invalid without owner, evidence and consequence.

Change, stop or escalation condition Stop when mandatory control, support ownership or acceptance evidence is absent.

Handoff to the next step Accepted boundaries transfer to delivery planning.

Step 11: Transfer requirements and decision authority

Purpose and decision served Ensure architecture intent survives implementation without freezing all design choices.

Accountable owner CTO.

Delegated lead and contributors Architect, product, engineering, delivery, operations, quality and control owners.

Preconditions, inputs and access Signed disposition, quality matrix, trade-off and support records.

Actions

1. Transfer mandatory requirements, evidence gates, owners, assumptions and exceptions.
2. Define which decisions are reserved, delegated or require re-approval.
3. Obtain delivery and operating acceptance and record unresolved gaps.

Evidence to retain Handover record, decision log, acceptance, open conditions and escalation routes.

Decision or scoring rule Delivery may refine design within the accepted quality, control and authority boundary.

Output and template Delivery and operating handover rows.

Acceptance gate ACCEPTED, CONDITIONAL or HOLD.

Leadership checkpoint CTO confirms The Product Delivery Governance Standard: From Discovery through Production Acceptance retains delivery authority within explicit gates.

Human control point Delivery and operating owners accept; silence is not acceptance.

Failure modes and safeguards Architecture documentation alone is not knowledge or ownership transfer.

Change, stop or escalation condition Hold work lacking mandatory evidence or accountable owners.

Handoff to the next step The Product Delivery Governance Standard: From Discovery through Production Acceptance may authorise delivery within the accepted boundary.

Step 12: Review architecture drift and operating evidence

Purpose and decision served Keep criticality, quality attributes and support decisions current as evidence changes.

Accountable owner CTO.

Delegated lead and contributors CIO, Product Sponsor, architecture, engineering, service, security, data and assurance.

Preconditions, inputs and access Delivery decisions, test evidence, incidents, performance, support and dependency changes.

Actions

1. Compare observed evidence with accepted scenarios, thresholds and residual risk.
2. Review drift in design, data, integrations, threats, capacity, suppliers and support.
3. Renew, validate, change, constrain, retire or stop affected architecture decisions.

Evidence to retain Review pack, drift register, test evidence, incidents, dissent and disposition.

Decision or scoring rule Absence of incidents is not proof that a quality attribute or control is effective.

Output and template Architecture decision support and review register.

Acceptance gate RENEW, VALIDATE, CHANGE, CONSTRAIN, RETIRE or STOP.

Leadership checkpoint CTO decides material re-architecture and escalates investment impact to The Software Investment Business Case: Scope, Total Cost, Risk and Operating Economics where required.

Human control point Attribute, operating and control owners confirm evidence within their mandates.

Failure modes and safeguards Documentation is versioned rather than silently changed around failures.

Change, stop or escalation condition Re-charter on material change in value boundary, criticality, population or solution scope.

Handoff to the next step The architecture remains accepted within evidence limits or returns to a controlled decision.

4. The Evidence & Measurement Checklist

Preflight and authority

• Product value, population and solution boundary are named. Evidence: architecture charter. Owner: CTO.
• The Build, Buy, Configure, Integrate or Stop Decision: An Executive Technology Investment Playbook investment route is referenced. Evidence: prior decision record. Owner: Product Sponsor.
• Architecture acceptance is separate from delivery and release. Evidence: boundary statement. Owner: CTO.
• Qualified authority and stop rights are explicit. Evidence: authority register. Owner: Risk Executive.
• Conflicts and supplier influence are disclosed. Evidence: conflict log. Owner: CTO.

Evidence access and quality

• Criticality claims include consequence, population and source. Evidence: criticality register. Owner: Product Sponsor.
• Quality attributes use bounded scenarios and measures. Evidence: quality matrix. Owner: CTO.
• Proof states, contradictions and exclusions remain visible. Evidence: evidence register. Owner: Architect.
• Test environment and production-transfer limits are explicit. Evidence: acceptance plan. Owner: Quality Owner.
• Evidence expiry can reopen architecture decisions. Evidence: review register. Owner: CTO.

Method execution

• Normal, peak, degraded, recovery and misuse scenarios are considered. Evidence: scenario register. Owner: Architect.
• Data meaning, lineage, retention and ownership are explicit. Evidence: data contract. Owner: Data Owner.
• Interfaces include failure, retry and reconciliation ownership. Evidence: integration ledger. Owner: CIO.
• Architecture options retain trade-offs and rejected alternatives. Evidence: option record. Owner: CTO.
• Support, recovery and exit ownership are accepted. Evidence: operating model. Owner: CIO.

Governance, privacy, security and risk

• Threats include misuse, error, privilege and supply chain. Evidence: threat model. Owner: Security Owner.
• Mandatory legal, privacy, security and accessibility conditions remain gates. Evidence: control register. Owner: Risk Executive.
• Residual risks have qualified human owners. Evidence: risk acceptance. Owner: Risk Executive.
• Sensitive evidence uses approved access and retention. Evidence: handling plan. Owner: Data Owner.
• Failed mandatory conditions cannot be averaged away. Evidence: trade-off record. Owner: CTO.

Deliverables and acceptance

• Charter, criticality, scenarios, threats and options reconcile. Evidence: cross-reference review. Owner: Architect.
• Every material requirement traces to consequence and test. Evidence: traceability matrix. Owner: Quality Owner.
• Conditional acceptance has owner, evidence and consequence. Evidence: condition register. Owner: CTO.
• Delivery and operating owners accept handover. Evidence: acceptance records. Owner: CIO.
• The Software Investment Business Case: Scope, Total Cost, Risk and Operating Economics business case and The Product Delivery Governance Standard: From Discovery through Production Acceptance delivery remain separate. Evidence: boundary decision. Owner: Product Sponsor.

Measurement

• Measures include stimulus, response, population and exclusion. Evidence: measurement contract. Owner: Quality Owner.
• Reliability, performance, accessibility and security remain distinct. Evidence: quality matrix. Owner: CTO.
• Guardrails remain separate from product outcome. Evidence: measure register. Owner: Product Sponsor.
• Support and recovery measures have operating owners. Evidence: support register. Owner: CIO.
• Thresholds and review triggers are human-approved. Evidence: review record. Owner: CTO.

Decision and handover

• CTO records accept, validate, change, defer or stop. Evidence: signed decision. Owner: CTO.
• Resource authority is separate from architecture acceptance. Evidence: investment record. Owner: CFO.
• Reserved and delegated delivery decisions are explicit. Evidence: decision matrix. Owner: CTO.
• Open conditions and dissent reach delivery unchanged. Evidence: handover pack. Owner: Architect.
• Operating owner accepts support and lifecycle duties. Evidence: acceptance record. Owner: CIO.

Review, change and stop controls

• Drift in design, data, integrations and suppliers is reviewed. Evidence: drift register. Owner: Architect.
• Incident absence is not represented as control effectiveness. Evidence: proof note. Owner: Risk Executive.
• New threats or populations can reopen requirements. Evidence: change rule. Owner: CTO.
• Architecture decisions can renew, constrain, retire or stop. Evidence: disposition register. Owner: CTO.
• Material value or criticality change triggers re-charter. Evidence: review decision. Owner: Product Sponsor.

Topic-specific measurement contracts

Measure A: Criticality evidence coverage

Measure B: Testable quality-attribute coverage

Measure C: Mandatory control acceptance

Measure D: Interface recovery fitness

Measure E: Support ownership readiness

Measure F: Accepted product and service outcome

Evidence classifications used in this guide

• VERIFIED: authoritative evidence supports the fact within its boundary.
• INFERRED: architecture interpretation remains distinguishable from retained facts.
• PROPOSED: a quality threshold, option or trade-off awaits acceptance.
• REQUIRES VALIDATION: a material claim, control or support assumption is not decision-fit.

Controlled source record