Architecture Assessment, Leadership and Emerging Futures

Introduction

Enterprise architecture (EA) is valuable only when it improves organisational outcomes. A visually attractive architecture repository, a modern technology stack, or a large collection of standards does not by itself demonstrate architectural success. Architecture must be assessed against business strategy, stakeholder needs, operational performance, regulatory obligations, security expectations, financial constraints and the organisation’s capacity to change.

Architecture assessment is therefore a disciplined process of gathering evidence, judging an architecture against explicit criteria, identifying risks and trade-offs, and recommending actions. Architecture leadership extends this work by establishing direction, decision rights, communication practices and professional capability. At the same time, architects must evaluate emerging developments without confusing technological novelty with strategic value.

This chapter examines maturity models, metrics, scenario analysis, risk analysis and trade-off methods. It then considers executive communication, architecture practice leadership and four emerging themes: composable enterprises, digital twins, quantum computing and autonomous systems.

Learning Objectives

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

1. Assess enterprise architecture using maturity models and evidence-based criteria.
2. Design meaningful architecture metrics and interpret their limitations.
3. Apply scenario analysis, risk analysis and architecture trade-off methods.
4. Communicate architectural choices and uncertainty to executives.
5. Lead an architecture practice through governance, capability development and decision management.
6. Evaluate the strategic relevance, opportunities and limitations of composable enterprises, digital twins, quantum computing and autonomous systems.

1. The Nature of Architecture Assessment

An architecture assessment is a structured evaluation of an existing or proposed architecture. It answers questions such as:

• Does the architecture support business capabilities and strategic objectives?
• Can the system meet required levels of performance, availability, security and compliance?
• Is the architecture sufficiently adaptable to foreseeable change?
• Are technology, supplier and operational risks acceptable?
• Do the benefits justify the total cost and organisational disruption?

Assessment differs from an architecture review. A review commonly examines a design at a point in time, often before implementation. An assessment may examine an entire architecture practice, a platform, a portfolio or a live operating environment over a longer period. Both require explicit criteria and reliable evidence.

A useful assessment distinguishes four dimensions:

Assessment should not be reduced to a single score. A high average score can conceal a critical weakness, such as an unencrypted sensitive data store or dependence on one supplier. Scores support judgement; they do not replace it.

2. Maturity Models: Useful Ladders, Dangerous Labels

A maturity model describes progressive states of organisational or architectural capability. It provides a common vocabulary for discussing current capability and a plausible direction for improvement. Maturity is not the same as technological sophistication. A simple, well-governed architecture may be more mature than a complex architecture with fashionable technologies but weak accountability.

A generic five-level model is:

The model can be applied to domains such as security architecture, data governance, cloud management or architecture decision-making. For example, an organisation at Level 1 may approve applications independently, while a Level 3 organisation has reference architectures, review forums and documented exceptions.

Designing a credible maturity assessment

A credible assessment requires:

1. Defined dimensions. Examples include governance, skills, methods, technology standardisation, data management and measurement.
2. Observable indicators. “Good governance” is too vague; “critical decisions have named owners and recorded rationale” is testable.
3. Evidence collection. Interviews, document sampling, repositories, operational data and observation should be combined.
4. Calibration. Assessors should discuss examples so that one team’s “managed” does not become another team’s “defined.”
5. Improvement actions. The assessment must identify practical next steps, owners and target dates.

A simple weighted maturity score may be used when its assumptions are made explicit. If dimension i has maturity score m_i and weight w_i, where the weights sum to 1, then:

Here, M is the weighted average maturity, n is the number of dimensions, m_i is the score for dimension i, and w_i is its relative importance. The score is meaningful only when the scale is sufficiently consistent and the dimensions are comparable. It should never override a “red-line” control failure.

For example, suppose governance, skills and measurement have scores 3, 2 and 1, with weights 0.4, 0.3 and 0.3. Then M = (0.4×3)+(0.3×2)+(0.3×1)=2.1. This indicates a developing practice, but it does not prove that the architecture is safe or fit for purpose.

3. Architecture Metrics and Evidence

Metrics translate architectural intent into observable signals. They should be connected to decisions rather than collected merely because they are easy to count.

Types of metrics

Outcome metrics measure results experienced by stakeholders. Examples include reduction in customer abandonment, improved claims-processing time and increased availability of a critical service.

Quality metrics measure architectural characteristics such as response time, recovery time, security control effectiveness and data-quality rates.

Flow metrics measure how rapidly and safely change moves through the organisation. Examples include lead time from approved change to production, deployment frequency and change-failure rate.

Risk metrics indicate exposure, such as unsupported technology instances, critical vulnerabilities beyond their remediation target, concentration in a single supplier and the percentage of systems lacking tested recovery procedures.

Economic metrics include total cost of ownership, cloud unit cost, avoided cost and return on investment. Economic analysis must include migration, training, integration, licensing, operating and exit costs—not only purchase price.

A useful metric has a clear definition, owner, collection method, frequency, target and action threshold. For instance, “availability” should specify the service boundary, observation period and treatment of planned maintenance. If a service is available for 43,190 of 43,200 minutes in a 30-day month, availability is:

Thus, availability is approximately (43190÷43200)×100 = 99.98%. This calculation assumes that the recorded times are accurate and that the organisation has defined whether planned outages count.

Metrics can be combined into a scorecard, but aggregation introduces risk. A useful approach is to maintain a balanced set of measures:

A metric becomes harmful when it becomes a target detached from purpose. This is a form of Goodhart’s law: when a measure becomes the objective, it may cease to be a good measure. Architecture leaders should therefore use metric portfolios, qualitative review and exception analysis.

4. Scenario Analysis and Quality Attributes

Scenario analysis tests architecture against plausible situations rather than relying only on static documentation. A scenario specifies:

1. Stimulus: an event, such as a sudden demand spike, cyberattack or regulatory change.
2. Source: where the stimulus originates.
3. Environment: normal operation, degraded operation or emergency conditions.
4. Artifact: the system, service, data or process affected.
5. Response: what the architecture does.
6. Response measure: how success is judged.

For example: “During a promotional event, transaction demand rises fivefold for 20 minutes. The payment platform shall continue accepting valid transactions, with 95% completed within two seconds and no loss of committed orders.” This scenario is more useful than the vague requirement “the platform must be scalable.”

Scenarios can assess quality attributes including availability, performance, security, modifiability, interoperability, usability and deployability. They should include normal, peak, failure and adversarial conditions.

A scenario workshop may compare architectural options through prototypes, load tests, threat modelling and operational exercises. The output should identify which decisions are validated, which remain assumptions and which require further evidence.

5. Risk Analysis for Architecture Decisions

Architecture risk is the possibility that uncertainty will prevent the architecture from achieving objectives. Risk analysis should examine both the likelihood of an event and its consequence, while recognising that numerical precision can be misleading when evidence is weak.

A common qualitative method uses likelihood and impact scales. A numerical risk priority score can be calculated as:

where L is a likelihood rating and I is an impact rating on defined ordinal scales. Because these ratings are ordinal rather than precise measurements, the result is a prioritisation aid, not a probability of loss.

A quantitative expected-loss estimate is different. If event j has probability p_j and monetary impact C_j, then:

This is appropriate only when probabilities and impacts are sufficiently supported by evidence and when the events and assumptions are clearly defined. For a 5% annual probability of a failure costing £200,000, the expected annual loss is £10,000. This does not mean that the organisation will lose exactly £10,000; it is an average decision-support value across comparable periods or simulations.

Risk treatment options include:

• Avoid: do not undertake the activity or remove the risky dependency.
• Reduce: introduce controls, redundancy, testing or staged delivery.
• Transfer or share: use insurance, contractual provisions or managed services, while recognising that accountability may remain with the organisation.
• Accept: consciously retain the risk within approved tolerance.
• Exploit or enhance: for positive uncertainty, increase the likelihood or benefit of an opportunity.

Architecture risk registers should identify the risk statement, cause, event, consequence, owner, treatment, residual risk and review date. Residual risk is the exposure remaining after controls; it must be accepted by an appropriately authorised person.

6. Trade-Off Analysis and Architecture Decision Records

Architectural qualities conflict. Stronger isolation may reduce integration convenience; extensive redundancy increases cost; rapid delivery may reduce design certainty. A professional architect makes these tensions visible.

A trade-off method begins by identifying decision drivers and constraints. Options are then evaluated against scenarios and quality attributes. A weighted decision matrix can support comparison. If option j receives score s_ij on criterion i, and criterion i has weight w_i, the option’s score is:

Weights should sum to 1, and the scoring scale must be defined. The matrix is not an objective truth: changing weights or scores changes the result. Sensitivity analysis should test whether a small change reverses the recommendation.

For example, an organisation compares a managed cloud service with a self-managed platform. The cloud option may score highly for speed and elasticity but lower for supplier concentration and long-term control. The decision record should explain the context, alternatives considered, assumptions, consequences, chosen option and review triggers.

An Architecture Decision Record (ADR) is particularly valuable because it preserves rationale, not merely the final diagram. A good ADR includes:

• decision title and status;
• context and problem;
• constraints and decision drivers;
• options considered;
• decision and rationale;
• positive and negative consequences;
• security, privacy and compliance implications;
• risks, assumptions and dependencies;
• revisit conditions.

This practice reduces “decision amnesia” and supports responsible challenge. It also prevents architects from presenting a preference as if it were an unavoidable technical fact.

7. Communicating Architecture to Executives

Executives generally need to understand business impact, risk, investment, timing and choices. They rarely need a detailed component diagram in the first discussion. Effective communication translates architecture into outcomes while preserving material technical truth.

A concise executive recommendation should answer:

1. What problem or opportunity is being addressed?
2. What decision is required now?
3. Which options were considered?
4. What benefits, costs and risks follow from each option?
5. What happens if the organisation delays or chooses nothing?
6. What assumptions and uncertainties remain?
7. How will success be measured?

A useful communication structure is “recommendation, evidence, consequences, decision required.” Use one clear message per visual, avoid unexplained acronyms and distinguish facts, estimates and judgements. Executives should be shown ranges and confidence levels when estimates are uncertain.

Architecture leaders must also communicate downward and outward. Delivery teams need actionable standards and patterns; security and legal teams need control implications; suppliers need interface and responsibility boundaries; users need understandable changes. The same decision may require different levels of abstraction for each audience.

8. Leading an Architecture Practice

Architecture leadership is a socio-technical responsibility. It includes strategy, people, governance and professional ethics.

Establishing the practice

A mature practice normally defines:

• architecture principles and scope;
• domains and role responsibilities;
• decision rights and escalation paths;
• review and exception processes;
• reference architectures and reusable patterns;
• skills, mentoring and communities of practice;
• repositories, standards and decision records;
• measures of value and improvement.

Governance should be proportionate. Excessive review creates delay and encourages avoidance; weak governance creates duplication and unmanaged risk. Lightweight guardrails, automated checks and delegated authority often work better than central approval of every technical detail.

Leadership behaviours

Effective architecture leaders create clarity without pretending to possess certainty. They invite dissent, make assumptions explicit, protect engineering integrity and connect decisions to organisational purpose. They also manage conflict among business units, because architecture often exposes competing incentives.

A practice should develop both specialist and boundary-spanning skills: systems thinking, financial reasoning, security, data management, facilitation, negotiation and written communication. Succession planning matters because a practice that depends on one “hero architect” is itself an architectural risk.

Ethical and regulatory responsibilities

Architecture decisions can distribute benefits and harms. Architects must consider privacy, accessibility, discrimination, surveillance, safety, environmental impact, labour effects and accountability. Regulatory obligations may include data protection, sector-specific controls, records retention, resilience requirements and auditability.

Important controls include data minimisation, purpose limitation, least privilege, segregation of duties, explainability where decisions affect people, human escalation and evidence preservation. Compliance is a baseline, not a substitute for ethical judgement.

9. Emerging Futures

9.1 Composable enterprises

A composable enterprise is organised so that business capabilities can be assembled, recombined and changed through modular components. These components may include packaged applications, APIs, data products, workflow services and platform capabilities. The concept addresses volatility: when customer expectations, regulations or markets change, the organisation should be able to reconfigure capabilities rather than rebuild the entire enterprise.

Composability has three important properties:

• Modularity: capabilities have clear boundaries and limited coupling.
• Discoverability: components, interfaces, ownership and service qualities are visible.
• Interoperability: components can interact through stable contracts and shared semantics.

For example, a retailer might combine identity, payments, inventory, fulfilment and customer-service capabilities into different journeys for online, store and partner channels. The benefits include reuse, faster experimentation and business-unit autonomy.

The risks are equally important. Excessive decomposition can produce integration complexity, inconsistent data, duplicated controls and a fragmented user experience. APIs do not automatically create composability; governance, domain ownership, versioning, observability and security are essential. Architects should assess the cost of coordination and the operational burden of many independently changing components.

9.2 Digital twins

A digital twin is a continuously updated digital representation of a physical or organisational object, process or system, connected to the real-world entity through data. It is more than a static three-dimensional model. A useful twin has an explicit identity, relevant state data, a relationship to the physical or operational object, and defined purposes such as monitoring, simulation, prediction or optimisation.

A manufacturing twin may combine equipment telemetry, maintenance history, engineering models and production schedules. It can detect abnormal behaviour, simulate process changes and support predictive maintenance. A city-scale twin may represent transport flows, energy use and infrastructure conditions.

Digital twins require trustworthy data, time synchronisation, model validation, identity management and lifecycle governance. The twin may be wrong because sensors are incomplete, models are biased or data arrives late. Organisations must distinguish observed facts from inferred states and predicted outcomes. Security is critical because compromising a twin can reveal or manipulate real-world operations.

9.3 Quantum computing

Quantum computing uses quantum-mechanical phenomena such as superposition and entanglement to represent and manipulate information. A quantum bit, or qubit, can be measured as 0 or 1, but its state before measurement is described by amplitudes. Quantum algorithms do not simply try every answer simultaneously and read all answers; measurement and algorithm design determine which information can be extracted.

Potentially relevant areas include certain optimisation, simulation, search and cryptographic problems. However, practical advantage is problem-dependent. Current systems face noise, limited scale, error-correction challenges and specialised programming requirements. Quantum computing is not a general replacement for classical cloud computing.

Enterprise architecture implications include:

• inventorying cryptographic dependencies and preparing for post-quantum cryptography;
• monitoring standards and vendor claims;
• isolating experiments from production commitments;
• evaluating hybrid classical–quantum workflows;
• protecting long-lived confidential data against “harvest now, decrypt later” threats.

A responsible business case should compare a quantum approach with mature classical alternatives and include data preparation, specialist skills, access costs and uncertainty. Quantum readiness is often more immediately relevant to cryptographic migration than to deploying a quantum application.

9.4 Autonomous systems

Autonomous systems sense their environment, interpret information, choose or recommend actions and execute actions with limited direct human control. Examples include warehouse robots, autonomous vehicles, adaptive industrial control and software agents that perform business tasks.

Architectural concerns include sensor reliability, perception uncertainty, decision latency, safety boundaries, human override, fail-safe behaviour, audit logs, model updates and interaction with other autonomous systems. Autonomy should be specified by operational design domain: the conditions under which the system is authorised to operate.

A high-risk autonomous system needs defence in depth: independent monitoring, constrained action spaces, safe degradation, authenticated updates, incident response and meaningful human accountability. Machine-learning performance in a test environment is insufficient evidence of safety in changing real-world conditions. Governance should cover data provenance, bias, explainability appropriate to the risk, cybersecurity and responsibility when the system acts incorrectly.

10. Illustrative Case: Modernising a National Insurance Platform

Background

An insurance organisation operates a fifteen-year-old policy and claims platform. It has duplicated customer records, batch-based integration, expensive specialist skills and a long release cycle. Its strategy requires digital self-service, faster product introduction and improved fraud detection.

Problem

The executive committee considers replacing the platform with a single packaged suite, decomposing it into microservices, or adopting a composable approach using packaged policy capabilities, shared identity, event-driven integration and data products. The organisation must improve agility without compromising regulatory reporting, resilience and customer privacy.

Analysis

The architecture team conducts stakeholder interviews, dependency mapping, scenario workshops and a risk assessment. Three scenarios are selected:

1. A new insurance product must reach market within twelve weeks.
2. Claims volume triples after a severe weather event.
3. A customer requests access to and correction of personal data.

Metrics show an average release lead time of 20 weeks, 99.5% monthly availability for the claims portal and 18% duplicate customer records. A maturity assessment places architecture decision management at Level 2: some reviews exist, but rationales and exceptions are inconsistently recorded.

The single-suite option offers integration simplicity but creates supplier concentration and limits differentiation. A fully bespoke microservice solution offers flexibility but has high delivery and operational complexity. The composable option provides modularity but requires stronger API governance, data ownership and platform engineering.

Approach and solution

The organisation selects a staged composable architecture. It first establishes a canonical identity service, a customer data stewardship process, secure API standards, event observability and a claims integration boundary. The policy engine is replaced only after a pilot product demonstrates measurable benefit. Legacy systems remain behind controlled interfaces during transition.

An ADR records the decision and explicitly accepts temporary duplication during migration. A risk register identifies data inconsistency, supplier lock-in, operational skill gaps and regulatory reporting failure. Scenario tests require recovery exercises, privacy-request completion and peak claims performance before each transition.

Outcome

After two releases, product configuration time falls from 20 weeks to 10 weeks, and duplicate customer records decline to 8%. The organisation does not yet claim full transformation: operational complexity has increased, and it must continue investing in platform reliability and data governance. The staged approach allows evidence-based learning rather than an irreversible “big bang.”

Learning points

• Composability depends on governance and semantics, not only on APIs.
• Metrics must be linked to scenarios and business outcomes.
• Transitional architectures should be treated as deliberate designs with explicit risks.
• Architecture decisions become more trustworthy when assumptions, trade-offs and revisit conditions are recorded.

Challenges and Limitations

Architecture assessment can be weakened by incomplete data, political pressure, inconsistent scoring and optimism bias. Maturity models may encourage organisations to pursue a higher level ceremonially rather than improve outcomes. Metrics can be gamed, and scenario results may not generalise to untested conditions. Risk models can create false confidence when probabilities are invented.

Emerging technologies introduce additional uncertainty. Vendor road maps may be unreliable, standards may change and organisational capabilities may lag behind technical possibilities. Architects should use staged investment, proof-of-value experiments, explicit exit criteria and periodic reassessment. They should also avoid both technological hype and premature rejection: the relevant question is not whether a technology is fashionable, but whether it creates defensible value under the organisation’s constraints.

Best-Practice Checklist

• Begin with outcomes, capabilities and stakeholder concerns.
• Use observable maturity indicators and triangulated evidence.
• Combine outcome, quality, flow, risk and economic metrics.
• Test architecture with concrete normal, peak, failure and attack scenarios.
• Record assumptions, alternatives, consequences and decision ownership.
• Treat risk scores as aids to judgement, not scientific certainty.
• Perform sensitivity analysis on weighted trade-off matrices.
• Communicate recommendations in business terms without hiding technical risks.
• Use proportionate governance and automate repeatable controls.
• Design emerging-technology experiments with security, ethics, exit criteria and measurable success conditions.

Chapter Summary

Architecture assessment is an evidence-based judgement of fitness, resilience, adaptability and governance. Maturity models provide a vocabulary for capability development, but scores must be supported by observable evidence and must not conceal critical control failures. Metrics are valuable when they connect architectural qualities and risks to decisions; balanced portfolios are safer than isolated targets.

Scenario analysis expresses quality requirements as stimuli, responses and measurable outcomes. Risk analysis identifies uncertainty, consequences and treatments, while distinguishing qualitative prioritisation from quantitative expected-loss analysis. Trade-off methods and Architecture Decision Records make competing objectives, assumptions and consequences visible.

Architecture leadership requires clear decision rights, proportionate governance, professional capability, executive communication and ethical responsibility. Composable enterprises seek modular, discoverable and interoperable capabilities; digital twins connect digital representations to physical or operational entities; quantum computing creates specialised possibilities but also cryptographic preparation requirements; and autonomous systems demand strong safety, security, accountability and human-control mechanisms. Across all these areas, responsible architecture combines strategic ambition with evidence, staged learning and explicit management of uncertainty.

Key Terms

Architecture assessment: Systematic evaluation of an architecture against objectives, quality attributes, risks and constraints.

Architecture maturity: The degree to which architecture capabilities are defined, repeatable, measured and continuously improved.

Architecture Decision Record: A durable record of an architectural decision, its context, alternatives, rationale and consequences.

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

Composable enterprise: An organisation designed to assemble and reassemble modular business capabilities rapidly.

Digital twin: A data-connected digital representation of a physical or operational entity.

Expected loss: Probability-weighted consequence used for quantitative risk analysis.

Flow metric: A measure of how work or change moves through a delivery system.

Maturity model: A framework describing progressive capability states.

Operational design domain: The conditions under which an autonomous system is authorised to operate.

Quality attribute: A non-functional property such as security, performance, reliability or modifiability.

Residual risk: Risk remaining after controls or treatments are applied.

Risk appetite: The type and level of risk an organisation is willing to pursue or retain.

Scenario analysis: Evaluation of architecture against specified stimuli, responses and measures.

Trade-off analysis: Structured comparison of options with competing benefits, costs and constraints.

Weighted decision matrix: A comparison method using criterion weights and option scores.

Quantum computing: Computing based on quantum information and quantum-mechanical operations.

Autonomous system: A system that senses, decides or recommends, and acts with limited direct human control.

Review Questions

Short Answer Questions

1. What is the difference between an architecture review and an architecture assessment?
2. Why should maturity scores not be treated as proof of architectural fitness?
3. Identify the six elements of a useful architecture scenario.
4. What information should an Architecture Decision Record preserve?
5. State two governance challenges associated with autonomous systems.

Long Answer Questions

1. Explain how a balanced architecture metric portfolio can reduce the weaknesses of single-target measurement.
2. Compare qualitative risk scoring with quantitative expected-loss analysis, including their assumptions and limitations.
3. Describe how an architecture leader should communicate a major platform decision to an executive committee.
4. Explain the benefits and risks of a composable enterprise architecture.
5. Discuss the architecture implications of digital twins and quantum computing for a regulated organisation.

Analytical / Application Questions

1. An organisation gives security weight 0.4, cost weight 0.2, agility weight 0.25 and resilience weight 0.15. Two options score respectively (5, 3, 4, 2) and (4, 5, 3, 5) on a five-point scale. Calculate both weighted scores and explain whether the higher score alone should determine the decision.
2. A proposed autonomous warehouse system has a low-probability but severe failure mode. Design a scenario, identify at least four architectural controls and specify evidence that should be collected before deployment.
3. Using the insurance-platform case, recommend two additional metrics and one revisit condition for the composable architecture decision. Justify how each would support responsible governance.

Multiple Choice Questions with Answers

Question 1

Which statement best describes an architecture maturity model?

A. A guaranteed sequence for replacing all legacy systems

B. A framework describing progressive levels of organisational capability

C. A calculation of annual technology expenditure

D. A catalogue of approved software products

Correct Answer: B. A framework describing progressive levels of organisational capability

Question 2

What is the main purpose of a concrete architecture scenario?

A. To replace all technical documentation

B. To express a quality concern through a stimulus, response and measurable outcome

C. To guarantee that an architecture will never fail

D. To identify the cheapest technology vendor

Correct Answer: B. To express a quality concern through a stimulus, response and measurable outcome

Question 3

A service is available for 43,190 of 43,200 observed minutes. What is its approximate availability?

A. 95.00%

B. 99.50%

C. 99.98%

D. 100.20%

Correct Answer: C. 99.98%

Question 4

Which risk treatment removes the activity or dependency creating the risk?

A. Accept

B. Transfer

C. Reduce

D. Avoid

Correct Answer: D. Avoid

Question 5

What is the primary value of an Architecture Decision Record?

A. It preserves the rationale and consequences of a decision

B. It automatically tests system performance

C. It replaces the need for security controls

D. It guarantees executive approval

Correct Answer: A. It preserves the rationale and consequences of a decision

Question 6

If a criterion has weight 0.6 and score 4, while a second criterion has weight 0.4 and score 2, what is the weighted score?

A. 2.0

B. 2.8

C. 3.2

D. 4.6

Correct Answer: C. 3.2

Question 7

Which property is central to a composable enterprise?

A. Permanent coupling of all applications

B. Modular capabilities that can be assembled and recombined

C. Elimination of all governance

D. Exclusive use of quantum processors

Correct Answer: B. Modular capabilities that can be assembled and recombined

Question 8

What distinguishes a digital twin from a static digital model?

A. A digital twin is always a three-dimensional image

B. A digital twin is connected to a real-world entity through relevant data

C. A digital twin cannot support prediction

D. A digital twin removes the need for sensors

Correct Answer: B. A digital twin is connected to a real-world entity through relevant data

Question 9

Which is an important near-term enterprise implication of quantum computing?

A. All classical systems must immediately be discarded

B. Every business process will become autonomous

C. Organisations should assess cryptographic migration and post-quantum readiness

D. Quantum computers eliminate all cybersecurity risks

Correct Answer: C. Organisations should assess cryptographic migration and post-quantum readiness

Question 10

Why is operational design domain important for autonomous systems?

A. It defines the conditions in which the system is authorised to operate

B. It specifies the organisation’s annual budget

C. It removes the need for human accountability

D. It guarantees perfect machine-learning accuracy

Correct Answer: A. It defines the conditions in which the system is authorised to operate