Architecture Strategy and Emerging Directions

Introduction

Distributed computing has moved from a specialist infrastructure choice to a foundation of digital business. Cloud platforms, edge systems, data meshes, event-driven applications, artificial intelligence, and globally distributed services now shape how organisations create and deliver value. Consequently, architecture decisions cannot be reduced to selecting a technology or drawing a deployment diagram. They involve questions of economics, organisational capability, regulatory exposure, sustainability, operational risk, and long-term strategic flexibility.

This chapter examines how senior engineers, architects, and technology leaders can make build-versus-buy, platform, migration, and digital-transformation decisions. It also evaluates emerging directions including confidential computing, Web3, quantum networking, autonomous operations, and sustainable distributed systems. The central argument is that a successful distributed architecture is not necessarily the most technically sophisticated one. It is the architecture that produces durable business value while keeping risk, cost, environmental impact, and organisational complexity within acceptable limits.

Learning Objectives

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

1. Explain the strategic dimensions of distributed-architecture decisions.

2. Compare build, buy, partner, and managed-service options using structured criteria.

3. Evaluate platforms and migration strategies using cost, risk, capability, and sustainability measures.

4. Apply total-cost-of-ownership and weighted-decision models appropriately.

5. Design a governance approach for digital transformation and distributed systems.

6. Assess the practical maturity and limitations of confidential computing, Web3, quantum networking, autonomous operations, and sustainable computing.

7. Critically analyse a distributed-systems case and derive transferable lessons.

1. Architecture as a Strategic Decision

1.1 From technology architecture to enterprise capability

Technology architecture describes the organisation of software, data, infrastructure, interfaces, security controls, and operational processes. Architecture strategy goes further: it connects those technical structures to business objectives. A strategic architecture decision should answer four questions:

• What business capability is required?
• What outcomes and performance levels define success?
• Which risks and constraints must be accepted or controlled?
• Which organisational capabilities are needed to operate the solution?

For example, a retailer seeking same-day delivery may require real-time inventory visibility, location-aware processing, resilient mobile services, and integration with logistics partners. The relevant decision is not simply whether to deploy containers or serverless functions. It is whether the organisation should own the underlying platform, use a managed service, or establish a partnership that accelerates fulfilment while preserving control over customer and inventory data.

1.2 Architectural fitness

A system is architecturally fit when its properties support its intended context. Important properties include availability, latency, throughput, scalability, security, privacy, portability, maintainability, recoverability, and regulatory compliance. These properties can conflict. Strong isolation may increase cost; global replication may reduce latency but complicate consistency; portability may require the organisation to avoid provider-specific services and therefore sacrifice productivity.

Architecture strategy therefore involves explicit trade-offs rather than the pursuit of universally optimal designs. A useful practice is to identify a small number of measurable quality objectives, rank them by business importance, and define acceptable thresholds. For example:

• critical payment operations: 99.99% monthly availability;
• fraud decisions: response within 200 milliseconds at the 95th percentile;
• personally identifiable information: encryption in transit and at rest, controlled key ownership, and auditable access;
• recovery point objective: no more than five minutes of acceptable data loss;
• recovery time objective: restoration within one hour.

These requirements should be validated with business owners. A technical target without a business rationale often produces unnecessary expenditure.

1.3 The architecture decision record

An architecture decision record (ADR) is a concise, durable record of a significant architectural choice. It normally includes context, decision, alternatives considered, consequences, assumptions, and review conditions. ADRs prevent organisational memory from disappearing when personnel change. They also make later evaluation more disciplined: a decision can be judged against the assumptions that existed at the time rather than against hindsight alone.

At portfolio level, an architecture repository should link ADRs to business capabilities, risks, standards, data classifications, and investment plans. This creates traceability from strategy to implementation.

2. Build, Buy, Partner, or Compose

2.1 The strategic choice

Organisations typically choose among four approaches:

Build: develop and operate a capability internally.

Buy: acquire a packaged product, license, or commercial platform.

Partner: obtain the capability through an external strategic relationship, often with shared integration or delivery responsibility.

Compose: combine managed services, open-source components, internal services, and purchased products into a broader capability.

These options are not mutually exclusive. A bank may buy a core banking package, build its customer experience, partner for identity verification, and compose the surrounding platform from cloud and open-source technologies.

2.2 When building is justified

Building is defensible when the capability is a source of competitive differentiation, requires unusual domain knowledge, cannot be acquired at acceptable quality, or demands control that suppliers cannot provide. It may also be appropriate where the expected operational scale makes internal economics favourable.

However, building entails more than software development. The organisation must fund security engineering, testing, documentation, upgrades, incident response, compliance evidence, capacity planning, and the retention of specialist staff. A frequent strategic error is to compare the purchase price of a product with only the development cost of an internal prototype.

2.3 When buying or using a managed service is justified

Buying is attractive for commodity capabilities such as standard collaboration, observability, message delivery, identity federation, and routine data processing. A managed service can reduce undifferentiated operational work and provide elastic capacity. Nevertheless, the purchaser remains responsible for service configuration, identity, data classification, integration, resilience design, and many aspects of compliance. The cloud provider's responsibility does not eliminate the customer's responsibility.

2.4 Evaluation dimensions

A build-versus-buy assessment should consider at least the following dimensions:

• strategic differentiation and control;
• functional fit and extensibility;
• total cost over the planning horizon;
• time to value;
• security and privacy;
• regulatory and jurisdictional requirements;
• supplier viability and concentration risk;
• interoperability and exit feasibility;
• internal skills and operating maturity;
• reliability and service-level commitments;
• energy and environmental performance.

A decision matrix can make assumptions visible. Let option score \(s_{ij}\) represent the score of option \(j\) against criterion \(i\), on a consistent scale such as 1 to 5, and let \(w_i\) be the criterion weight, with the weights summing to 1. The weighted score is:

\[

S_j = \sum_{i=1}^{n} w_i s_{ij}

\]

This model is useful for structuring discussion, not for creating false precision. Scores should be supported by evidence, sensitivity-tested, and accompanied by a risk review. A high score does not override a mandatory legal or security constraint.

2.5 Total cost of ownership

A planning-level total-cost model can be expressed as:

\[

TCO = C_{acquisition} + C_{implementation} + C_{operation} + C_{integration} + C_{risk} + C_{exit} - V_{residual}

\]

where the terms represent costs over a stated time horizon and \(V_{residual}\) represents any recoverable residual value. Costs should include labour, licences, cloud consumption, connectivity, support, training, migration, testing, governance, security controls, downtime exposure, and decommissioning.

For multi-year comparisons, costs should be discounted if the analysis requires present-value accuracy. If a cash flow \(C_t\) occurs in period \(t\), the present value at discount rate \(r\) is:

\[

PV = \sum_{t=0}^{T} \frac{C_t}{(1+r)^t}

\]

The discount rate, horizon, tax treatment, inflation assumptions, and treatment of risk must be documented. TCO is not the same as business value: a low-cost option can still be strategically poor if it prevents revenue growth or creates unacceptable operational risk.

2.6 Real options and reversibility

Architecture choices create or destroy options. A proprietary platform may accelerate initial delivery but make future migration expensive. Open interfaces, portable data formats, modular services, and independently deployable components preserve optionality, though they can increase current complexity. Strategic evaluation should therefore ask not only, “What is the expected cost?” but also, “What choices remain available if assumptions change?”

3. Platform Strategy and Operating Models

3.1 Platforms as internal products

A platform is a set of capabilities that enables other teams to deliver services more safely and efficiently. It may include identity, networking, deployment automation, observability, data services, secrets management, policy controls, and developer tooling. A platform team should treat internal users as customers. Its success is measured by outcomes such as reduced lead time, lower failure rates, improved security posture, and increased developer autonomy—not by the number of tools installed.

The platform should provide a paved road rather than an inflexible road. Standard paths reduce cognitive load and operational variation, while documented escape mechanisms allow justified exceptions. Excessive centralisation creates queues; excessive autonomy creates duplicated systems and inconsistent controls.

3.2 Team and governance design

Platform strategy is inseparable from organisational design. A product-oriented model assigns teams ownership of services throughout their life cycle. A platform team supplies reusable capabilities and guardrails. A security or risk function defines policies and supports threat modelling. An architecture community maintains principles and resolves cross-domain issues.

Governance should be risk-based. Low-risk experiments can use lightweight review, while regulated workloads require evidence of data lineage, access control, resilience testing, and change approval. Automated policy checks are preferable to manual approval for repeatable controls because they provide faster feedback and more consistent enforcement.

3.3 Avoiding platform failure

Common platform failures include building infrastructure without validated users, exposing excessive configuration, adopting tools without operating expertise, and measuring activity rather than outcomes. Another failure is platform fragmentation: each department creates its own cloud account structures, deployment methods, and monitoring conventions. Federated governance can preserve local autonomy while enforcing common identity, security, data, and reliability standards.

4. Migration and Digital Transformation

4.1 Migration is a change programme

Migration is often described using technical verbs such as rehost, replatform, refactor, rebuild, replace, and retire. These categories are useful but incomplete. A migration changes operating procedures, skills, supplier relationships, controls, data flows, and accountability. It should therefore be managed as a socio-technical transformation.

Typical migration patterns include:

• Rehost: move a workload with minimal modification. This is fast but may preserve inefficiency.
• Replatform: make limited changes to use managed services or improve operations.
• Refactor: redesign components to exploit distributed or cloud-native characteristics.
• Rebuild: implement the capability anew, often when the legacy design is unsuitable.
• Replace: adopt a packaged or external capability.
• Retire: remove functionality that no longer creates value.

No single pattern is best for an entire portfolio. Workloads should be segmented according to business criticality, technical debt, data sensitivity, dependency structure, and expected future value.

4.2 Migration waves and strangler transformation

A migration wave groups workloads according to dependencies and risk. Early waves should validate landing zones, identity, network connectivity, observability, security controls, and operational procedures. They should not be selected solely because they are easy; they must also generate useful organisational learning.

The strangler pattern gradually places new interfaces and capabilities around a legacy system, moving functions incrementally until the old core can be reduced or retired. It limits the risk of a single large cutover, but it can create a prolonged period of duplicated logic and data. Clear retirement criteria are essential.

4.3 Migration economics and success measures

A transformation business case should distinguish one-time transition costs from recurring operating costs. Benefits may include faster delivery, improved resilience, reduced data-centre expenditure, better customer conversion, and the retirement of obsolete systems. Benefits should be stated as measurable hypotheses rather than vague claims of “agility.”

Useful measures include deployment frequency, lead time for change, change failure rate, mean time to restore, service-level objective attainment, infrastructure utilisation, energy per transaction, security-control coverage, and user outcomes. Metrics must be interpreted together: increasing deployment frequency while increasing incidents is not necessarily improvement.

4.4 Data and integration risks

Migration commonly fails at data boundaries. Differences in schemas, identifiers, retention policies, time semantics, and data quality can invalidate an apparently successful application move. Distributed data also raises questions about consistency, ownership, lineage, and deletion. A migration plan should define authoritative sources, reconciliation mechanisms, rollback procedures, and evidence that regulatory deletion or export requirements continue to work.

5. Risk, Resilience, Sustainability, and Value

5.1 Risk analysis

Distributed systems introduce risks from dependency chains, shared infrastructure, network partitions, misconfiguration, supply-chain compromise, provider outages, data leakage, and skill shortages. Risk analysis should identify assets, threats, vulnerabilities, consequences, existing controls, and residual exposure. Scenario analysis is especially useful: ask what happens if a cloud region fails, a certificate expires, a supplier is compromised, a key becomes unavailable, or an automated decision behaves incorrectly.

Risk matrices are useful communication devices but should not be treated as objective measurements. Probability estimates may be uncertain, and low-probability systemic events can have very high consequences. Critical services need engineering controls such as redundancy, tested recovery, isolation, rate limiting, immutable backups, and dependency reduction.

5.2 Resilience engineering

Availability is only one dimension of resilience. A resilient service can anticipate, withstand, recover from, and learn from disruption. Important practices include failure-mode analysis, chaos experiments with controlled scope, graceful degradation, bulkheads, circuit breakers, backpressure, idempotent operations, and tested disaster recovery.

Reliability targets should be tied to error budgets. If a service has a monthly availability objective of 99.9%, the permissible unavailability in a 30-day month is approximately 43.2 minutes, because the month contains 43,200 minutes and 0.1% of that time is 43.2 minutes. The calculation assumes a 30-day month and treats all unavailability uniformly; contractual definitions may differ.

5.3 Sustainability

Sustainable distributed computing considers energy, carbon emissions, water consumption, hardware lifecycle, and electronic waste. Efficiency is not automatically sustainability: lower cost or lower energy per transaction can stimulate greater total usage, a phenomenon related to rebound effects.

Architectural levers include right-sizing, workload scheduling, efficient data movement, caching, compression where appropriate, storage lifecycle policies, workload consolidation, use of renewable-energy-aware regions, longer hardware life, and avoiding unnecessary replication. These choices must preserve security and resilience. For example, reducing replicas may lower energy use but increase recovery risk.

A useful operational indicator is energy per completed transaction, rather than energy per server, because it relates resource use to delivered value. Measurements must define system boundaries and account for shared infrastructure; otherwise comparisons may be misleading.

5.4 Business value

Business value can include revenue, cost avoidance, risk reduction, compliance enablement, customer experience, employee productivity, and strategic option value. A balanced investment case should combine financial measures with non-financial outcomes. Net present value, payback period, and return on investment can be informative, but they depend on uncertain forecasts and should be accompanied by scenario and sensitivity analysis.

6. Confidential Computing

Confidential computing protects data while it is being processed by using hardware-supported trusted execution environments (TEEs) or related mechanisms. Traditional encryption protects data at rest and in transit, but plaintext may be exposed in memory during computation. A confidential-computing design attempts to restrict access to that memory and provides attestation so that a party can verify which code is running before releasing sensitive data or keys.

Potential applications include privacy-preserving analytics across organisations, secure financial workloads, protection of encryption keys in shared infrastructure, and processing of regulated health data. The technology does not solve all security problems. Vulnerabilities in the trusted computing base, side-channel attacks, insecure application code, malicious administrators outside the protected boundary, compromised endpoints, and flawed attestation policies remain concerns.

Architectural evaluation should identify the trust boundary, supported workloads, performance overhead, attestation authority, update process, recovery behaviour, and regulatory interpretation. Confidential computing is best viewed as one control in a defence-in-depth strategy, not as a replacement for access control, secure coding, or governance.

7. Web3 and Decentralised Architectures

Web3 is an umbrella term associated with blockchains, smart contracts, decentralised applications, token-based incentives, and user-controlled digital assets. Its strongest architectural contribution is the ability to maintain a shared, tamper-evident state across parties that do not fully trust one another, subject to a consensus protocol and governance model.

Blockchains introduce costs: consensus consumes resources or imposes participation constraints; transaction throughput and latency may be limited; data permanence can conflict with privacy and deletion rights; smart contracts are difficult to modify once deployed; and bridges between chains have suffered serious security failures. Public ledgers are generally unsuitable for storing personal or confidential data directly. A common design stores proofs, references, or hashes on-chain while retaining sensitive content off-chain, but this does not automatically solve linkability or deletion concerns.

The strategic test is whether decentralisation solves a genuine coordination or trust problem. If one organisation can provide authoritative governance efficiently, a conventional database may be cheaper, faster, and easier to regulate. Web3 is most defensible where multiple parties need shared rules, verifiable provenance, programmable settlement, or reduced dependence on a single intermediary.

8. Quantum Networking

Quantum networking seeks to distribute quantum states or entanglement among nodes. Potential applications include quantum key distribution, distributed quantum computing, and high-precision sensing. It is not simply a faster version of the Internet. Quantum information cannot be copied arbitrarily, measurements disturb states, and long-distance communication requires specialised technologies such as quantum repeaters, memories, and error correction.

Quantum key distribution can provide security properties based on physical principles under stated implementation assumptions, but it does not eliminate endpoint compromise, denial of service, authentication requirements, or implementation vulnerabilities. Quantum networks remain at an early research and engineering stage, with substantial challenges in distance, fidelity, interoperability, synchronisation, and cost.

For current architecture strategy, the more immediate concern is post-quantum cryptography: organisations should inventory cryptographic dependencies, classify long-lived sensitive data, and develop migration plans toward algorithms expected to resist cryptanalytic attacks by quantum computers. This is an example of “harvest now, decrypt later” risk, in which encrypted data captured today may be exposed in the future.

9. Autonomous Operations and AI-Augmented Management

Autonomous operations uses automation and artificial intelligence to detect conditions, diagnose likely causes, recommend actions, and sometimes execute remediation. It builds on observability, event correlation, policy engines, configuration management, and machine-learning techniques. Its value is greatest when repetitive decisions are well understood and consequences are bounded.

A mature operating model follows a progression:

1. Visibility: collect reliable logs, metrics, traces, events, and topology data.

2. Assistance: provide search, correlation, summaries, and recommendations.

3. Controlled automation: execute low-risk, reversible actions with approval or policy checks.

4. Adaptive autonomy: allow bounded systems to respond within explicit safety constraints.

AI-generated explanations can be useful but may be incomplete or incorrect. Models can amplify noisy telemetry, learn from biased incident data, or recommend actions that interact badly with distributed feedback loops. Autonomous systems therefore require human accountability, action limits, simulation or canary testing, rollback, audit trails, model monitoring, and emergency shutdown procedures.

Generative AI also raises issues of confidential data exposure, intellectual-property use, prompt manipulation, and unverifiable output. It should be integrated through controlled interfaces with least privilege, data classification, and evaluation against operational scenarios.

10. Sustainable Distributed Systems as a Design Discipline

Sustainability should be included during architecture design rather than measured only after deployment. A workload's environmental impact depends on computation, storage, network transfer, cooling, hardware manufacture, facility energy mix, and utilisation. Software design influences all of these.

Effective practices include:

• reducing unnecessary data movement and polling;
• selecting appropriate consistency rather than defaulting to the strongest model;
• using event-driven processing where it reduces idle work;
• expiring data according to business and legal requirements;
• choosing efficient encodings and query plans;
• scaling down non-production environments;
• designing for hardware reuse and supplier transparency;
• measuring carbon and energy with stated boundaries;
• balancing geographic redundancy against environmental and availability requirements.

Sustainability targets must be governed like reliability targets. A team should know who owns the target, how it is measured, what trade-offs are allowed, and what happens when the target is missed.

11. Illustrative Case: Migrating a Regional Health-Services Platform

Background

The fictional Northbridge Health Network operates appointment scheduling, laboratory-result exchange, clinician portals, and patient notifications across several hospitals. Its central application is twelve years old, difficult to change, and hosted in one facility. The organisation seeks improved availability, mobile access, and information exchange while remaining compliant with health-data regulation.

Problem

A proposal recommends moving the entire application to a public cloud in one large migration. The estimated infrastructure cost is attractive, but the proposal does not address data quality, recovery testing, supplier exit, clinical downtime, or the skills required to operate distributed services.

Analysis

An architecture review identifies four critical capabilities: identity and consent, appointment transactions, laboratory integration, and notification delivery. They have different availability, latency, retention, and integration requirements. A single migration pattern would therefore be inappropriate. The review also identifies a high consequence of incorrect patient matching, a dependency on an external laboratory network, and a need to retain some data within specified jurisdictions.

The team evaluates options using weighted criteria: patient safety and reliability, regulatory fit, time to value, five-year cost, portability, sustainability, and internal capability. Mandatory regulatory and safety requirements are treated as gates rather than merely weighted scores. The analysis shows that a fully managed proprietary platform has the shortest delivery time but creates significant exit and data-model risk. A fully bespoke rebuild provides control but exceeds available skills and delays benefits. A hybrid approach performs best under the stated constraints.

Approach and solution

The organisation establishes a governed landing zone with central identity, encryption-key management, audit collection, network segmentation, backup controls, and policy automation. It first migrates notification delivery and non-critical reporting to validate operations. Appointment search is then exposed through a strangler layer, while the legacy transaction engine remains authoritative until reconciliation is proven.

The platform team supplies deployment pipelines, observability, secrets management, and recovery automation. A domain team owns appointment services, and a data-governance group controls patient identity, consent, lineage, and retention. The laboratory interface is retained through a partner-managed integration because replacing it would create disproportionate risk.

The programme defines explicit exit tests: data must be exportable in documented formats, critical interfaces must have replacement procedures, and recovery must be demonstrated in an alternative environment. Sustainability measures include reducing idle development environments, selecting storage tiers according to access patterns, and reporting energy per completed appointment request.

Outcome

After the first year, notification reliability improves and release lead time decreases. The organisation does not claim that all legacy infrastructure has been eliminated; instead, it reports progress by capability, risk reduction, and clinical outcomes. A disaster-recovery exercise identifies an identity dependency that was not visible in the original design, leading to a revised architecture and runbook. The case demonstrates that migration success is not equivalent to cloud adoption. It depends on controlled learning, domain ownership, evidence-based sequencing, and preservation of safety and strategic options.

Learning points

1. Different capabilities require different migration patterns.

2. Safety and regulatory constraints should act as decision gates.

3. Platform engineering must include operational and governance capabilities.

4. Exit planning is easier before supplier dependence becomes deep.

5. Outcomes and tested resilience matter more than infrastructure location.

12. Professional Best Practices

A disciplined architecture strategy should:

• begin with business capabilities and measurable outcomes;
• document assumptions and review them as evidence changes;
• separate mandatory constraints from preference-based scoring;
• model full life-cycle cost and operational responsibility;
• treat data, identity, and integration as first-class architecture concerns;
• use incremental migration with explicit rollback and retirement criteria;
• design for observability, recovery, and controlled failure;
• maintain supplier, concentration, and exit-risk registers;
• integrate security, privacy, accessibility, and sustainability early;
• govern autonomous systems with bounded authority and human accountability;
• use standards and open interfaces where they preserve meaningful options;
• measure business and user outcomes, not only technical activity.

Challenges and Limitations

Strategic analysis is constrained by uncertainty. Future demand, technology prices, supplier behaviour, regulation, and threat levels cannot be predicted precisely. Quantitative models may therefore create an illusion of confidence. Scenario analysis, sensitivity testing, staged investment, and review points are appropriate responses.

Distributed architectures also create organisational complexity. More services, teams, providers, and data flows can increase cognitive load and failure modes. The answer is not always further abstraction. Simplification, retirement, standardisation, and clear ownership may create more value than adding another platform layer.

Emerging technologies require particular caution. Demonstrations often show technical possibility without proving economic viability, operational maturity, governance feasibility, or societal benefit. Strategic leaders should distinguish a research option from a production commitment and define evidence required to progress between them.

Chapter Summary

Architecture strategy connects distributed-technology choices to business value, risk, cost, sustainability, and organisational capability. Build-versus-buy decisions should compare full life-cycle consequences, including integration, operations, security, skills, supplier concentration, and exit. Weighted matrices and total-cost models provide structure but do not replace judgement, evidence, or mandatory constraints.

Platforms should be designed as internal products with paved roads, measurable outcomes, and risk-based governance. Migration is a socio-technical transformation requiring workload segmentation, incremental waves, data discipline, tested recovery, and explicit retirement criteria. Resilience extends beyond availability to anticipation, recovery, and learning. Sustainability requires measurement of resource use in relation to delivered value and careful balancing of efficiency, reliability, and environmental impact.

Confidential computing can reduce exposure during processing but does not remove application or governance risks. Web3 is valuable only where decentralised coordination solves a genuine problem. Quantum networking remains emerging, while post-quantum preparation is an immediate strategic concern. Autonomous operations can improve response and reduce toil when supported by high-quality observability, bounded authority, auditability, and human accountability. Across all these directions, architecture leadership depends on disciplined experimentation, transparent assumptions, and preservation of future choices.

Key Terms

Architecture decision record: A documented record of an important architectural choice, its context, alternatives, and consequences.

Build-versus-buy: The strategic comparison between developing a capability internally and acquiring it externally.

Confidential computing: Protection of data during processing through trusted execution environments or related mechanisms.

Digital transformation: Organisational change that uses digital capabilities to alter operations, services, and value creation.

Error budget: The permissible unreliability implied by a service-level objective.

Exit strategy: A plan for reducing or ending dependence on a supplier, platform, or technology.

Managed service: A capability operated partly or wholly by an external provider under defined service terms.

Migration wave: A coordinated group of workloads moved or transformed together according to dependencies and risk.

Net present value: The present value of expected benefits minus the present value of expected costs.

Platform engineering: The design and operation of reusable capabilities that enable delivery teams.

Post-quantum cryptography: Cryptographic methods intended to resist attacks from sufficiently capable quantum computers.

Resilience: The ability of a system or organisation to anticipate, withstand, recover from, and learn from disruption.

Strangler pattern: An incremental transformation approach that places new capabilities around and gradually replaces a legacy system.

Sustainability: The management of environmental, social, and economic impacts over the system life cycle.

Total cost of ownership: The complete cost of acquiring, implementing, operating, integrating, securing, and retiring a capability.

Trusted execution environment: A protected processing area intended to isolate code and data from unauthorised access.

Web3: An umbrella term for decentralised applications, blockchains, smart contracts, and related token-based systems.

Weighted decision matrix: A structured evaluation that combines criterion weights with option scores.

Review Questions

Short Answer Questions

1. What is the difference between technology architecture and architecture strategy?

2. Identify four costs that should be included in a build-versus-buy comparison.

3. What is the purpose of an architecture decision record?

4. Define the strangler migration pattern.

5. Why does confidential computing not eliminate the need for conventional security controls?

Long Answer Questions

1. Explain how an organisation should evaluate build, buy, partner, and compose options for a strategic capability.

2. Discuss the relationship between platform engineering, team autonomy, and governance.

3. Analyse the major technical and organisational risks of a distributed-systems migration.

4. Compare the strategic potential and limitations of Web3 and conventional centralised architectures.

5. Explain how sustainability, resilience, and business value can conflict in distributed-system design and how those conflicts should be managed.

Analytical / Application Questions

1. An organisation must choose between a proprietary managed platform, an open-source internal platform, and a hybrid model. Design a weighted decision framework, identify mandatory gates, and explain how you would test sensitivity to cost and supplier-exit assumptions.

2. A critical service has a monthly availability objective of 99.95%. Assuming a 30-day month, calculate the approximate monthly unavailability budget and propose an operational policy for using it.

3. Using the Northbridge Health Network case, propose a migration wave sequence and identify the evidence required before moving the patient-appointment transaction engine.

Multiple Choice Questions with Answers

Question 1

Which statement best describes architecture strategy?

A. Selecting the newest available infrastructure technology

B. Connecting technical choices with business outcomes, risks, constraints, and organisational capability

C. Replacing all legacy systems with microservices

D. Reducing infrastructure expenditure regardless of service quality

Correct Answer: B. Connecting technical choices with business outcomes, risks, constraints, and organisational capability

Question 2

In a weighted decision matrix, what must the criterion weights normally sum to when expressed as proportions?

A. 0

B. 0.5

C. 1

D. 1000

Correct Answer: C. 1

Question 3

Which cost is most likely to be omitted in an overly narrow build-versus-buy comparison?

A. The colour of the user interface

B. Operational support and exit costs

C. The number of project meetings only

D. The age of the organisation’s logo

Correct Answer: B. Operational support and exit costs

Question 4

What is the principal purpose of a platform team?

A. To approve every line of application code

B. To provide reusable capabilities that help delivery teams work safely and efficiently

C. To prevent all teams from choosing any implementation detail

D. To replace business ownership of services

Correct Answer: B. To provide reusable capabilities that help delivery teams work safely and efficiently

Question 5

Which migration pattern incrementally places new functionality around a legacy system?

A. Rehost

B. Retire

C. Strangler pattern

D. Cold standby

Correct Answer: C. Strangler pattern

Question 6

For a 30-day month, approximately how much unavailability corresponds 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 7

What does confidential computing primarily seek to protect?

A. Data only while stored on backup media

B. Data while it is being processed in memory

C. Only the physical location of a data centre

D. The user interface from poor design

Correct Answer: B. Data while it is being processed in memory

Question 8

Which is a strong strategic test for adopting Web3?

A. Whether the technology is fashionable

B. Whether decentralised coordination solves a genuine trust or governance problem

C. Whether all data can be placed publicly on-chain

D. Whether a blockchain removes the need for security controls

Correct Answer: B. Whether decentralised coordination solves a genuine trust or governance problem

Question 9

Which is an immediate strategic response to the possibility of future quantum attacks on current cryptography?

A. Ignoring cryptographic dependencies until quantum computers are widespread

B. Inventorying cryptographic use and planning post-quantum migration

C. Replacing all networks with blockchains

D. Removing authentication from internal systems

Correct Answer: B. Inventorying cryptographic use and planning post-quantum migration

Question 10

What is a necessary control for autonomous operations?

A. Unlimited automated authority

B. No logging, to reduce storage cost

C. Bounded actions, auditability, and rollback or shutdown mechanisms

D. Permanent prohibition of all automation

Correct Answer: C. Bounded actions, auditability, and rollback or shutdown mechanisms