13. Enterprise Transformation and Architecture Leadership

Introduction and Context

Cloud and edge computing are often presented as technology adoption programmes. In practice, their consequences are organizational and strategic. Moving workloads to public, private, hybrid, or sovereign clouds changes sourcing arrangements, financial controls, security responsibilities, operational skills, data flows, and the authority of architecture teams. Extending computation to factories, vehicles, retail sites, hospitals, or remote facilities adds another layer of complexity: applications must operate across locations with different connectivity, latency, physical-security, and maintenance conditions.

Enterprise transformation therefore cannot be reduced to a migration schedule. It is a coordinated change in capabilities, decision rights, operating practices, technology platforms, and organizational behaviour. Architecture leadership provides the integrative function. It connects business strategy with technology choices, makes trade-offs visible, and establishes guardrails within which delivery teams can move quickly without creating unmanaged risk.

This chapter treats cloud–edge adoption as an enterprise transformation problem. It examines how organizations assess readiness, classify workloads, choose migration and modernization pathways, redesign operating models, develop skills, govern decisions, and demonstrate benefits. Particular attention is given to evidence-based decisions, scenario planning, and the leadership responsibilities required when transformation produces uncertainty, resistance, and competing interests.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Assess enterprise capability and readiness for cloud–edge transformation.

2. Construct and evaluate a workload portfolio using business, technical, financial, and risk dimensions.

3. Select suitable migration, modernization, repatriation, or edge-placement pathways.

4. Design an operating model that aligns people, processes, platforms, and accountability.

5. Establish governance, skills-development, and benefits-realization mechanisms.

6. Apply scenario planning and evidence-based decision frameworks to transformation choices.

7. Critically evaluate leadership, ethical, regulatory, and organizational risks in cloud–edge programmes.

Transformation as a Capability Problem

A cloud–edge programme succeeds when the enterprise can repeatedly deliver valuable, secure, and governable outcomes—not merely when servers have been moved. This distinction separates a technology project from a transformation capability. A migration may reduce data-centre occupancy while leaving the organization dependent on manual operations, opaque costs, inconsistent security controls, and skills that are no longer appropriate. Conversely, a carefully governed hybrid architecture may retain some legacy infrastructure while substantially improving resilience, speed, and business responsiveness.

A useful transformation perspective considers six interdependent capabilities:

• Strategic alignment: the ability to relate cloud–edge investments to measurable business outcomes.
• Architecture and engineering: the ability to design distributed, scalable, observable, and resilient systems.
• Platform and operations: the ability to provide reusable services, automation, reliability practices, and lifecycle management.
• Governance and risk: the ability to enforce security, privacy, regulatory, financial, and architectural controls without paralysing delivery.
• People and culture: the ability to develop multidisciplinary skills and encourage learning, accountability, and experimentation.
• Value management: the ability to measure benefits, costs, risk reduction, and opportunity creation over time.

These capabilities are mutually reinforcing. FinOps, for example, is ineffective if teams cannot observe resource consumption; observability is of limited value if nobody owns remediation; and ownership is ambiguous when the operating model has not defined shared-responsibility boundaries.

Capability Maturity and Its Limitations

Maturity models commonly describe progression from fragmented and reactive practices to standardized, measured, automated, and continuously improving capabilities. A simple five-level interpretation is:

1. Initial: practices depend on individuals and differ across projects.

2. Repeatable: selected teams use documented practices, but enterprise consistency is limited.

3. Defined: standards, platforms, roles, and policies are formally established.

4. Measured: performance, cost, risk, reliability, and delivery outcomes are monitored.

5. Adaptive: the organization learns from evidence and adjusts architecture and operating practices continuously.

Maturity should not be treated as a universal ladder. A highly regulated workload may appropriately retain stronger control and slower change than a low-risk digital service. A small edge site may need a deliberately simple operating model rather than the same platform used in a central cloud region. The purpose of assessment is not to assign a flattering score; it is to reveal constraints, dependencies, and the next capability investments that will produce value.

Assessment evidence may include architecture reviews, incident records, deployment frequency, recovery tests, skills inventories, cost data, regulatory mappings, employee interviews, and user-experience measures. Self-assessment is useful for engagement but should be supplemented by operational evidence and independent challenge.

Building a Workload Portfolio

The workload portfolio is the principal bridge between enterprise strategy and technical action. A workload may be an application, data product, platform service, integration flow, analytics pipeline, or operational control system. Portfolio analysis prevents the common error of treating every workload as a candidate for the same migration pattern.

For each workload, the organization should establish a reliable baseline:

• business owner and technical owner;
• business criticality and service-level objectives;
• users, locations, and dependency relationships;
• data classification, residency, retention, and sovereignty requirements;
• current operating cost and major cost drivers;
• performance, latency, availability, and recovery requirements;
• technology condition, licensing constraints, and skills availability;
• security threats, regulatory obligations, and third-party dependencies;
• carbon, energy, and physical-infrastructure implications where material.

The portfolio can then be evaluated through a multi-criteria decision model. One illustrative score is:

Priority score = w₁V + w₂R + w₃T + w₄S − w₅C − w₆D

where V represents expected business value, R risk reduction, T time-to-value, S strategic alignment, C transformation complexity or cost, and D dependency risk. The weights should be agreed by the steering body and tested through sensitivity analysis. A numerical score is not an objective truth; it is a transparent way to expose assumptions and compare alternatives.

Portfolio decisions should also recognize interactions. A customer application may not be migratable until its identity service is modernized. A factory analytics workload may require edge processing because network outages and control-loop latency make centralized processing unsuitable. A data platform may generate value only after data ownership and quality problems are addressed. Thus, sequencing should consider value, feasibility, dependency, and learning—not simply the largest or oldest applications first.

The Placement Decision: Cloud, Edge, or Hybrid

Placement is an architectural decision rather than a slogan. Cloud is often advantageous when elastic capacity, managed services, centralized analytics, broad service availability, and rapid experimentation are important. Edge placement becomes more compelling when local autonomy, deterministic latency, data reduction, intermittent connectivity, physical-process integration, or data-sovereignty requirements dominate. Hybrid designs are appropriate when local execution must coexist with centralized coordination, model training, fleet management, or long-term analysis.

A rigorous placement decision examines:

1. Latency and determinism: Is a remote round trip acceptable, and is its timing predictable?

2. Connectivity: Can the workload continue safely during network degradation or disconnection?

3. Data economics: Is transmitting all data more expensive or risky than processing it locally?

4. Resilience: What happens when a cloud region, local node, identity provider, or management plane is unavailable?

5. Security and privacy: Which location provides appropriate control and evidential accountability?

6. Operational burden: Can the enterprise patch, monitor, replace, and secure distributed devices?

7. Lifecycle and sustainability: What are the energy, hardware, and disposal implications?

The most robust answer is often a federated design: policy and fleet management are centralized, while selected inference, filtering, control, or caching functions occur at the edge.

Migration and Modernization Pathways

Migration pathways should be selected by workload intent, not by terminology alone. Common pathways include:

• Retire: remove redundant, obsolete, or unused capability.
• Retain: keep a workload in place when its constraints or economics justify doing so.
• Relocate: move a workload with minimal architectural change, such as to a hosted environment.
• Rehost: move the workload largely unchanged to cloud infrastructure.
• Repurchase: replace a custom system with a software service or commercial product.
• Replatform: make limited changes to use managed databases, containers, or platform services.
• Refactor or rearchitect: redesign components to exploit elasticity, resilience, automation, and independent deployment.
• Rebuild: create a new solution when the existing one cannot meet strategic needs.
• Repatriate or redistribute: move selected functions back to controlled infrastructure or distribute them across cloud and edge when evidence shows that the original placement is unsuitable.

These pathways involve trade-offs. Rehosting can produce rapid exit from a data centre but may transfer technical debt and create disappointing cost or performance outcomes. Refactoring can improve long-term agility but requires stronger engineering capabilities and often changes testing, security, and operations. Repurchase may reduce maintenance but introduce vendor dependence, data-portability concerns, and process compromise.

A credible business case therefore includes transition costs, dual-running periods, data transfer, licensing changes, retraining, testing, resilience engineering, security remediation, and decommissioning. Benefits should be expressed in operational and business terms: reduced recovery time, faster product release, improved field autonomy, lower incident impact, improved customer experience, or increased analytical value. “Moving to the cloud” is not itself a benefit.

Migration should proceed through controlled waves. A wave contains a coherent set of workloads and enabling capabilities, such as identity, connectivity, landing-zone controls, observability, backup, and service management. Early waves should be chosen for learning and credible value, not merely convenience. A pilot that avoids the organization’s hardest constraints may produce false confidence.

Redesigning the Operating Model

The operating model defines how work is organized and how decisions are made. Traditional infrastructure models often separate development, operations, security, procurement, and architecture into sequential functions. Cloud–edge environments require more continuous collaboration because infrastructure is programmable, application and platform boundaries are fluid, and failures can propagate across organizational domains.

A target operating model commonly combines:

• Product-aligned delivery teams responsible for a business capability and its outcomes;
• Platform teams providing paved roads such as identity, networking, observability, deployment pipelines, policy automation, and approved data services;
• Enabling and assurance functions that coach teams and verify security, resilience, privacy, and regulatory conformance;
• Architecture leadership that establishes principles, resolves cross-domain issues, and manages technical evolution;
• Service and supplier management for contracts, support, continuity, and external dependencies.

The model should apply clear accountability. A RACI matrix may clarify who is responsible, accountable, consulted, and informed for identity, data, incident response, edge-device maintenance, cost allocation, and compliance evidence. However, matrices do not replace working relationships. Teams must also possess the authority, skills, telemetry, and budget necessary to discharge their responsibilities.

Architecture governance should shift from document approval toward evidence-based guardrails. Automated policy checks, reference architectures, reusable patterns, threat modelling, architecture decision records, and exception registers are more effective than reviews that occur only at project initiation. Exceptions should have an owner, rationale, expiry or review date, and compensating controls.

Financial and Benefits Governance

Cloud changes expenditure patterns from predominantly capital investment to a mixture of consumption, subscription, labour, and platform costs. Edge introduces additional hardware, logistics, connectivity, site-support, and replacement costs. FinOps practices connect engineering, finance, procurement, and business owners. They include tagging or attribution, budgets, forecasting, unit-cost measures, anomaly detection, rightsizing, commitment analysis, and accountability for idle resources.

Cost reduction should not be pursued in isolation. Excessive optimization may weaken resilience, security, or performance. A more meaningful measure is unit economics—for example, cost per transaction, cost per connected site, cost per analytical result, or cost per customer served—combined with service quality and risk indicators.

Benefits realization requires a baseline, named benefit owners, target measures, dates, and a method for distinguishing transformation effects from unrelated business changes. A benefits register can include financial benefits, cycle-time reduction, availability, safety, user experience, regulatory readiness, carbon reduction, and strategic options. Benefits should be reviewed after implementation because anticipated outcomes often change as adoption patterns and workloads evolve.

Leadership, Skills, and Organizational Change

Architecture leadership is partly technical and partly institutional. The architect must translate between executives seeking outcomes, engineers seeking viable designs, risk specialists seeking evidence, finance teams seeking control, and operational personnel accountable for continuity. Effective leadership makes disagreement productive by clarifying assumptions, decision criteria, reversibility, and evidence requirements.

Skills development should be based on role analysis rather than generic training. Relevant capabilities may include cloud and edge architecture, distributed systems, platform engineering, infrastructure as code, software supply-chain security, data engineering, site reliability engineering, observability, FinOps, privacy engineering, incident command, and vendor management. Leaders also need skills in facilitation, negotiation, systems thinking, and organizational change.

A sustainable skills strategy combines formal learning, communities of practice, pairing, internal mobility, coaching, safe experimentation, and opportunities to operate real services. Certification may indicate exposure to a body of knowledge, but it does not demonstrate the ability to design or operate a reliable enterprise system. Knowledge transfer should be explicit when external partners or managed services are used.

Resistance is not necessarily irrational. Operations staff may fear loss of control, local personnel may understand site constraints that central architects overlook, and business owners may have experienced previous transformation failures. Leaders should distinguish legitimate risk from status-quo preference. Involving affected groups in discovery, publishing decision evidence, protecting safe dissent, and demonstrating early value are more effective than treating resistance as a communications problem.

Scenario Planning and Evidence-Based Decisions

Transformation decisions are made under uncertainty. Forecasts about demand, regulation, technology prices, connectivity, and supplier behaviour may be wrong. Scenario planning does not predict one future; it tests whether a strategy remains viable across plausible futures.

A practical process is to:

1. identify critical uncertainties, such as data-sovereignty rules or network availability;

2. define a small number of internally consistent scenarios;

3. assess the workload portfolio and operating model under each scenario;

4. identify robust choices, contingent choices, and early-warning indicators;

5. design trigger points for revisiting decisions.

For example, an industrial enterprise might test scenarios involving reliable connectivity, intermittent connectivity, strict local-data regulation, and rapid growth in machine-generated data. Centralized analytics may dominate in the first scenario, while local filtering and inference become essential in the latter two. The strategy may therefore define a common control plane and portable workload packaging, while delaying irreversible commitments about the final placement of all data.

Decision records should state the problem, alternatives considered, criteria, evidence, assumptions, risks, decision owner, and review conditions. Reversible decisions can be made with lighter governance and shorter evidence cycles. Irreversible decisions—such as proprietary data models, long contractual commitments, or major facility changes—deserve deeper analysis. This distinction prevents both reckless speed and unnecessary bureaucracy.

Illustrative Case: Northstar Manufacturing’s Federated Transformation

Background

Northstar Manufacturing, a fictional multinational producer, operates plants with robotic equipment, quality-inspection cameras, enterprise resource planning, and a centralized analytics function. Its estate contains ageing plant servers, inconsistent connectivity, duplicated data stores, and applications owned by separate business units. Executives approve a cloud programme expecting faster analytics and lower infrastructure cost.

Situation and Problem

An initial proposal recommends moving all plant data to a central cloud region. A pilot reveals that inspection images consume substantial bandwidth, some plant networks lose connectivity during maintenance, and production-control decisions cannot tolerate unpredictable remote latency. At the same time, central teams cannot reliably attribute cloud costs to plants, and no group owns the lifecycle of edge devices.

Analysis

The architecture office creates a portfolio catalogue and conducts interviews with plant engineers, security staff, finance, and product owners. It identifies three workload classes. Enterprise planning and long-term analytics have modest latency requirements and benefit from centralized managed services. Inspection workloads require local preprocessing and rapid inference, but aggregated results can be sent centrally. Safety-related control functions require strict local autonomy and cannot depend on a remote cloud service.

The assessment also reveals organizational constraints: plant teams possess essential process knowledge but lack modern software skills; central teams understand cloud platforms but not industrial operating conditions; and procurement contracts do not define patching or replacement responsibilities for edge equipment.

Approach and Strategy

Northstar adopts a federated target architecture. A central cloud platform provides identity, fleet policy, model management, observability, data governance, and enterprise analytics. Plant edge nodes perform image preprocessing, inference, local buffering, and selected autonomous functions. A store-and-forward mechanism synchronizes data when connectivity returns. Safety functions remain locally controlled and are separately validated.

The transformation is delivered in waves. The first wave establishes a secure landing zone, device identity, centralized logging, cost attribution, and a limited inspection pilot at two representative plants. The second wave introduces a reusable edge package and automated update process. The third wave addresses selected legacy applications through replatforming and retirement. Every wave includes rollback procedures, recovery tests, and benefit reviews.

Northstar forms product teams combining plant specialists, software engineers, security professionals, and data scientists. A platform team owns reusable capabilities, while plant teams retain responsibility for operational outcomes. The architecture board approves principles and exceptions but does not manually review every deployment. Policy checks in the delivery pipeline verify encryption, approved images, identity configuration, and logging.

Outcome

The programme demonstrates improved inspection responsiveness and reduced transmission of raw images, while central analysts receive standardized results for cross-plant comparison. More importantly, Northstar discovers that cost transparency and device lifecycle ownership are prerequisites for expansion. It delays migration of two applications whose licensing and safety constraints remain unresolved rather than declaring them failures.

Learning Points

The case illustrates five principles. First, workload placement must follow physical and business constraints rather than enterprise fashion. Second, edge computing expands operational responsibility; it does not eliminate it. Third, representative pilots should expose difficult constraints. Fourth, platform capabilities and organizational ownership must develop together. Finally, benefits realization should include resilience, autonomy, data quality, and decision speed—not only infrastructure expenditure.

Risks, Limitations, and Common Mistakes

Several failure patterns recur in enterprise transformation. “Cloud first” may become “cloud only,” causing inappropriate placement and expensive rework. Migration factories may optimize the number of servers moved rather than business outcomes. Central platform teams may build technically impressive services that delivery teams find difficult to use. Architecture boards may become bottlenecks when they rely on manual approval instead of automated guardrails.

Other risks include uncontrolled consumption, vendor lock-in, concentration risk, inadequate identity design, weak software supply-chain security, inconsistent edge patching, data duplication, and incomplete decommissioning. Distributed systems also create observability gaps: a transaction may cross devices, networks, cloud services, and third-party platforms, making ownership and diagnosis difficult.

Maturity scores can mislead when they reward documentation instead of operational performance. Business cases can fail when they omit change effort, dual running, exit costs, or the value of resilience. Benchmarking can be unreliable when organizations compare unlike workloads or use vendor-produced assumptions without validation. Finally, transformation fatigue can reduce adoption even when the architecture is sound.

Mitigation requires incremental delivery, independent assurance, threat modelling, resilience testing, cost controls, supplier exit planning, explicit service ownership, and mechanisms for learning from incidents. Leaders should treat near misses and failed experiments as evidence for improving the system, not as reasons to conceal uncertainty.

Ethical, Regulatory, and Professional Responsibilities

Cloud–edge architecture determines where data is collected, inferred, retained, and accessed. Architects must address privacy, lawful processing, purpose limitation, data minimization, residency, cross-border transfer, surveillance risks, and the explainability of automated decisions. Edge analytics may reduce transmission of identifiable data, but local devices can also create new risks through physical access, opaque inference, or inadequate deletion.

Professional responsibility includes designing for accessibility, safety, security, and continuity, especially where technology affects healthcare, employment, industrial control, or public services. Governance should establish evidence of compliance rather than treating compliance as a final document review. Controls must be proportionate, auditable, and understandable to those accountable for operating them.

AI-enabled operations introduce further concerns. Automated remediation can reduce response time but may amplify an incorrect diagnosis. Machine-learning models deployed at the edge require version control, drift monitoring, provenance, performance evaluation across relevant populations, and a safe fallback. Human oversight should be meaningful rather than nominal, with clear authority to suspend automated actions.

Emerging Directions

Enterprise transformation is moving toward platform products, policy as code, confidential computing, distributed data products, event-driven architectures, and increasingly automated compliance evidence. Edge environments are likely to use more specialized accelerators and local AI inference, while centralized environments remain important for training, coordination, and governance.

The strategic issue is not whether every organization should adopt the newest pattern. It is whether architecture leaders can preserve portability, observability, security, and operational control while using new capabilities selectively. Sovereign and regulated cloud arrangements, carbon-aware workload scheduling, digital twins, and autonomous operations will increase the importance of evidence, clear accountability, and scenario-based planning.

Best Practices for Architecture Leaders

A disciplined transformation programme should:

• begin with business outcomes and measurable baselines;
• maintain a living workload and dependency portfolio;
• assess cloud, edge, and hybrid placement explicitly;
• fund enabling capabilities such as identity, observability, security, and platform engineering;
• use waves that maximize learning as well as value;
• define ownership for applications, data, platforms, devices, and benefits;
• automate guardrails and compliance evidence where practical;
• use unit economics rather than infrastructure cost alone;
• develop skills through real operational experience;
• record assumptions, alternatives, exceptions, and review triggers;
• test resilience, recovery, supplier exit, and offline operation;
• involve affected personnel and protect constructive challenge;
• review outcomes after deployment and retire capabilities that no longer create value.

Chapter Summary

Enterprise cloud–edge adoption is an organizational transformation involving architecture, operating models, skills, governance, finance, and culture. Capability assessment should reveal practical constraints rather than produce superficial maturity scores. Workload portfolio analysis connects business outcomes to placement and migration choices, while multi-criteria evaluation makes assumptions and trade-offs visible. Migration may involve retiring, retaining, relocating, rehosting, repurchasing, replatforming, refactoring, rebuilding, or redistributing workloads.

Successful transformation redesigns accountability through product teams, platform teams, assurance functions, and architecture leadership. FinOps, benefits registers, observability, and automated governance connect technical activity with measurable value. Scenario planning helps organizations prepare for uncertainty concerning connectivity, regulation, demand, and supplier conditions. Leadership must integrate technical judgement with organizational change, skills development, ethical responsibility, and evidence-based decision-making. The central lesson is that cloud and edge are not destinations; they are components of an evolving enterprise capability.

Key Terms

Capability maturity: The assessed development of an organizational capability from ad hoc practice toward measured and adaptive performance.

Workload portfolio: A structured inventory of applications, services, data products, and dependencies considered for transformation.

Cloud–edge placement: The architectural decision about where processing, storage, control, and data management should occur.

Rehost: Moving a workload with minimal modification to a new infrastructure environment.

Replatform: Making limited changes to use managed or more suitable platform services.

Refactor: Redesigning application structure to exploit improved scalability, resilience, automation, or operability.

Retain: Keeping a workload in its existing environment because constraints or evidence justify that choice.

Repurchase: Replacing a custom workload with a commercial product or software service.

Federated architecture: An architecture combining distributed autonomy with shared policies, management, and governance.

Operating model: The arrangement of roles, processes, decision rights, platforms, and accountability through which work is performed.

Platform team: A team that provides reusable technical capabilities and a supported path for delivery teams.

FinOps: A collaborative practice for managing and optimizing technology consumption through financial and operational accountability.

Benefits realization: The disciplined process of defining, measuring, owning, and reviewing expected transformation outcomes.

Scenario planning: Exploring plausible alternative futures to identify robust strategies and decision triggers.

Architecture decision record: A documented statement of a significant architectural decision, its rationale, alternatives, and consequences.

Policy as code: Expressing governance or compliance rules in machine-readable form so they can be checked automatically.

Technical debt: The future cost created by expedient technical choices, obsolete design, or deferred remediation.

Edge autonomy: The ability of an edge system to perform required functions during limited or absent connectivity.

Unit economics: Measurement of cost in relation to a meaningful unit of business or service output.

Shared responsibility: The allocation of security, operational, and compliance duties among the enterprise, providers, and other parties.

Review Questions

Short Answer Questions

1. Why is cloud–edge adoption considered an enterprise transformation rather than only a migration project?

2. What evidence can be used to supplement a capability-maturity self-assessment?

3. Distinguish between rehosting, replatforming, and refactoring.

4. What is the purpose of a benefits register?

5. Why does edge computing require explicit device-lifecycle ownership?

Long Answer Questions

1. Explain how workload portfolio analysis supports migration sequencing and cloud–edge placement decisions.

2. Discuss the operating-model changes required for product teams, platform teams, assurance functions, and architecture leadership to work effectively together.

3. Evaluate the advantages and limitations of using a multi-criteria decision model for transformation priorities.

4. Explain how FinOps and benefits realization should be integrated into enterprise governance.

5. Discuss the role of architecture leadership in managing organizational resistance, skills development, and ethical responsibility.

Analytical / Application Questions

1. An organization proposes moving all factory workloads to a central cloud region. Using the placement criteria in this chapter, analyze the proposal and recommend a decision framework.

2. Design a scenario-planning exercise for an enterprise facing uncertain data-sovereignty regulation, intermittent connectivity, and rapid growth in edge-generated data.

3. A cloud programme reports that 80 percent of servers have been migrated, but costs and incident rates have increased. Diagnose likely causes and propose an evidence-based recovery plan.

22. Multiple Choice Questions with Answers

Question 1

Which statement best captures the central purpose of enterprise cloud–edge transformation?

A. To move every workload to a public cloud as quickly as possible

B. To build a repeatable capability for delivering secure, valuable, and governable outcomes

C. To eliminate all legacy infrastructure regardless of business constraints

D. To replace architecture governance with autonomous delivery teams

Correct Answer: B. To build a repeatable capability for delivering secure, valuable, and governable outcomes

Question 2

Which workload characteristic most strongly supports processing at the edge?

A. A need for centralized long-term trend analysis only

B. A requirement for local autonomy during intermittent connectivity

C. A preference for using the largest available cloud region

D. A workload with no physical or operational dependencies

Correct Answer: B. A requirement for local autonomy during intermittent connectivity

Question 3

What is a principal weakness of treating maturity models as universal ladders?

A. They cannot include any operational evidence

B. They always prevent organizations from automating governance

C. They may imply that every workload and organization should follow the same progression

D. They focus exclusively on financial performance

Correct Answer: C. They may imply that every workload and organization should follow the same progression

Question 4

A company moves an application to cloud infrastructure with almost no code changes. Which pathway has it primarily selected?

A. Rehost

B. Rebuild

C. Repurchase

D. Refactor

Correct Answer: A. Rehost

Question 5

Which practice most directly connects technology consumption with financial and operational accountability?

A. FinOps

B. Threat modelling

C. Data minimization

D. Architecture decision recording

Correct Answer: A. FinOps

Question 6

Why should a migration wave include identity, observability, and recovery capabilities?

A. They are optional features used only after all applications are migrated

B. They are enabling capabilities needed to operate migrated workloads securely and reliably

C. They eliminate the need for workload owners

D. They guarantee that rehosting will reduce costs

Correct Answer: B. They are enabling capabilities needed to operate migrated workloads securely and reliably

Question 7

Which feature best distinguishes evidence-based architecture governance from a traditional approval board?

A. It requires every deployment to receive manual executive approval

B. It relies on undocumented expert judgement

C. It uses guardrails, automated checks, decision records, and managed exceptions

D. It prohibits teams from choosing different technical patterns

Correct Answer: C. It uses guardrails, automated checks, decision records, and managed exceptions

Question 8

In scenario planning, what should an organization do after identifying critical uncertainties?

A. Select the most optimistic forecast and ignore alternatives

B. Construct plausible internally consistent scenarios and test strategies against them

C. Delay all transformation decisions indefinitely

D. Treat scenarios as predictions with fixed probabilities

Correct Answer: B. Construct plausible internally consistent scenarios and test strategies against them

Question 9

Northstar keeps safety-related control functions locally autonomous while sending selected results to the cloud. What principle does this illustrate?

A. All workloads should be centralized for consistency

B. Placement should follow latency, resilience, and operational constraints

C. Edge systems should never communicate with cloud systems

D. Data reduction is incompatible with centralized analytics

Correct Answer: B. Placement should follow latency, resilience, and operational constraints

Question 10

Which measure is most useful for evaluating transformation value beyond raw infrastructure expenditure?

A. Number of cloud accounts created

B. Number of servers migrated without regard to outcomes

C. Cost per meaningful service unit combined with quality and risk indicators

D. Total volume of architecture documentation

Correct Answer: C. Cost per meaningful service unit combined with quality and risk indicators