14. Architecture Strategy, Governance, and Emerging Directions

Introduction and Context

Computer architecture is no longer determined only by instruction-set design, datapath organization, cache hierarchy, or clock frequency. In contemporary systems, architectural decisions are inseparable from business strategy, regulation, supply-chain conditions, sustainability objectives, security requirements, and the expected evolution of workloads. An enterprise choosing a processor platform, accelerator, cloud service, edge device, or cyber-physical controller is making a long-term commitment to interfaces, tools, suppliers, skills, operating costs, and risk exposure.

Architecture strategy therefore concerns the deliberate selection and evolution of computing capabilities over time. It asks not merely whether a system can meet current performance requirements, but whether it can remain secure, interoperable, maintainable, economically viable, and adaptable. Governance provides the institutional mechanisms through which these choices are authorized, monitored, reviewed, and retired.

This chapter examines architecture roadmaps and build-versus-buy decisions across enterprise, cloud, edge, and cyber-physical environments. It also considers standards, interoperability, ethical and privacy obligations, export constraints, supply-chain risk, lifecycle governance, and emerging technologies including chiplets, three-dimensional integration, photonic computing, neuromorphic systems, and quantum-assisted computing.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain architecture strategy as a portfolio and lifecycle discipline.

2. Develop evidence-based platform roadmaps using workload, risk, cost, and capability analysis.

3. Compare build, buy, partner, and hybrid sourcing decisions.

4. Evaluate standards, interoperability, supply-chain, privacy, ethical, and export-control issues.

5. Design governance mechanisms for architecture decisions and technology lifecycles.

6. Assess the opportunities and limitations of chiplets, 3D integration, photonic, neuromorphic, and quantum-assisted computing.

7. Apply these ideas to enterprise, cloud, edge, and cyber-physical systems.

From Technical Architecture to Architecture Strategy

A technical architecture describes how components are arranged and how they interact. An architecture strategy adds time, alternatives, constraints, and organizational purpose. It identifies a desired future state, the sequence of transitions required to reach it, and the criteria used to select among competing paths.

A useful strategic distinction is between capabilities, platforms, and products. A capability is an enduring organizational ability, such as secure data processing, real-time control, or privacy-preserving analytics. A platform is a reusable technical foundation that provides the capability to several products or services. A product is a specific application or service delivered to users. Confusing these levels can result in short-term product optimization at the expense of a sustainable platform.

Architecture strategy is also a portfolio activity. A single organization may operate general-purpose servers, graphics or AI accelerators, mobile processors, industrial controllers, and cloud-managed services. These platforms have different performance measures, update cycles, safety requirements, and economic models. Strategy must determine where standardization creates value and where specialization is justified.

The central strategic question is not “Which technology is fastest?” It is “Which architectural choice produces the best sustainable outcome for the relevant workload and risk profile?” A technically superior processor may be unsuitable if it lacks a toolchain, has uncertain supply, cannot meet data-residency obligations, or imposes unacceptable migration costs.

Workload Evidence and Platform Roadmaps

A platform roadmap links present capabilities with future requirements. It should be based on evidence rather than technology fashion. Evidence may include production telemetry, benchmark results, application-profiling data, incident records, energy measurements, supplier information, regulatory analysis, and validated forecasts of workload growth.

The first step is workload characterization. Important dimensions include:

• computation intensity and instruction mix;
• memory capacity, bandwidth, and locality;
• communication latency and bandwidth;
• determinism and real-time deadlines;
• reliability, availability, and safety requirements;
• confidentiality and data-residency constraints;
• energy, thermal, size, and environmental limits; and
• expected changes in data volume or algorithmic behavior.

A benchmark is useful only when it represents the target workload. A high score on a synthetic numerical benchmark may say little about a transaction-processing system dominated by synchronization, storage access, and tail latency. Accordingly, evaluation should combine standard benchmarks with representative application traces, prototype implementations, and operational measurements.

A roadmap normally contains a baseline, transition states, decision gates, and a target state. Each transition should identify dependencies such as compiler maturity, operating-system support, firmware validation, staff capability, supplier qualification, and application migration. Roadmaps should include uncertainty explicitly. Instead of presenting one inevitable future, planners can define scenarios such as conservative, growth, disruption, and regulatory-change cases.

A practical decision score can combine several dimensions:

Strategic value = weighted capability benefit − transition cost − risk exposure.

The expression is not a substitute for judgment. It forces decision makers to make assumptions visible. Capability benefit may include performance, energy efficiency, resilience, or new functionality. Transition cost includes software porting, testing, training, tooling, and operational change. Risk exposure includes security, supplier concentration, obsolescence, compliance, and failure consequences.

Real-options reasoning is particularly valuable for uncertain technologies. A small pilot, standards-based interface, or modular design can preserve the option to expand later without committing the entire organization. This is often preferable to either immediate large-scale deployment or complete avoidance.

Build, Buy, Partner, or Combine?

The build-versus-buy decision is a strategic sourcing decision, not simply a comparison of purchase price with development cost. Organizations may build custom processors, boards, firmware, operating-system components, accelerators, or management software when differentiation, control, security, or long-term economics justify it. They may buy commercial products when scale, maturity, support, and rapid deployment are more important.

Four common alternatives are:

1. Build: develop and control the relevant component internally.

2. Buy: acquire a product or service from a supplier.

3. Partner: share development, validation, or ownership with another organization.

4. Hybrid: buy common infrastructure while building differentiating components.

The total cost of ownership includes acquisition, integration, licensing, energy, operations, upgrades, security response, compliance, decommissioning, and opportunity cost. A cloud service may have low initial capital expenditure but create variable operating costs and dependency on provider interfaces. An internally developed platform may provide control but require permanent investment in specialized engineers and validation infrastructure.

The decision should evaluate at least six questions. Does the component create competitive or mission-critical differentiation? Is the capability available at acceptable maturity? Can the organization maintain it over its expected life? What is the exit strategy? Does the supplier expose stable interfaces and credible security processes? What happens if volumes, regulations, or geopolitical conditions change?

Vendor lock-in is not automatically unacceptable. Lock-in can be rational when the provider delivers substantial economies of scale or distinctive capability. It becomes dangerous when switching costs are unknown, data and interfaces are non-portable, or contractual terms prevent meaningful exit. A sound architecture separates replaceable services from irreplaceable organizational knowledge and uses open interfaces where feasible.

Standards, Interoperability, and Architectural Boundaries

Interoperability is the ability of systems to exchange information and use it correctly. It has several layers: physical connectivity, communication protocols, data representation, semantic interpretation, identity and security, and operational management. A system can be technically connected yet semantically incompatible.

Standards reduce integration cost and support supplier diversity, but standards are not universally beneficial. A standard may be immature, overly complex, poorly implemented, or unable to express domain-specific requirements. Organizations should distinguish between mandatory standards imposed by regulation or safety practice, widely adopted de facto interfaces, and optional standards selected for strategic reasons.

Good architecture governance identifies stable boundaries. Hardware-software interfaces, device-management protocols, data schemas, telemetry formats, and security mechanisms should be documented and tested. Conformance testing, reference implementations, versioning rules, and compatibility policies are more reliable than assuming that two products using the same standard will behave identically.

In cloud and edge systems, interoperability also concerns workload placement. Containers, virtual machines, orchestration interfaces, identity systems, and observability formats can reduce migration barriers, although abstraction may hide performance or security differences. Portability should therefore be measured with an actual migration exercise, not claimed solely from marketing terminology.

Governance Across the System Lifecycle

Architecture governance is the set of decision rights, controls, evidence requirements, and review practices that keep technical choices aligned with organizational objectives. It should enable responsible innovation rather than function as a late-stage approval bureaucracy.

A governance model typically defines an architecture board or equivalent forum, accountable system owners, security and privacy reviewers, procurement specialists, operations representatives, and domain experts. Decision records should state the problem, alternatives considered, assumptions, evidence, risks, owner, review date, and conditions under which the decision must be revisited.

Lifecycle governance begins before procurement and continues through retirement. Relevant stages include requirements, architecture selection, design, implementation, verification, deployment, operation, upgrade, incident response, and decommissioning. Each stage needs appropriate evidence. For example, a safety-critical edge controller may require hazard analysis and fault-injection testing, while an internal analytics cluster may prioritize data-governance review and cost monitoring.

Configuration management and asset inventories are essential. An organization cannot patch, replace, or retire components it does not know it operates. Firmware, microcode, third-party libraries, model dependencies, and hardware revisions should be tracked. End-of-support dates should trigger migration planning rather than emergency replacement.

Architecture governance must also address exceptions. Exceptions should be time-bounded, risk-assessed, assigned to an owner, and reviewed periodically. Permanent exceptions are often undocumented architecture decisions that gradually become technical debt.

Supply-Chain Risk and Trust

Modern computing systems depend on extended global supply chains. Risks include counterfeit components, malicious or vulnerable firmware, compromised development tools, inadequate manufacturing controls, single-source dependencies, geopolitical disruption, and opaque subcontracting. Hardware assurance is difficult because verification cannot always inspect every transistor, mask, firmware image, or manufacturing step.

Risk reduction requires layered measures: supplier due diligence, provenance records, component authenticity checks, secure boot, signed firmware, reproducible or controlled builds where practical, vulnerability disclosure processes, segmentation, monitoring, and recovery plans. Critical systems should identify alternative suppliers or redesign options before disruption occurs.

The software bill of materials concept has a hardware analogue: organizations need an inventory of components, versions, suppliers, licenses, and dependencies. This information supports vulnerability response and regulatory reporting. However, inventories are useful only when maintained and connected to operational systems.

Resilience does not always require duplicate suppliers. It may instead require stock buffers, interchangeable interfaces, qualified second sources, local repair capability, or a design that can tolerate delayed component replacement. The appropriate response depends on failure probability, consequence, lead time, and substitution cost.

Ethics, Privacy, and Export Constraints

Architectural decisions distribute benefits and risks. Large-scale data-processing platforms can improve services while enabling surveillance or discriminatory inference. Edge processing may reduce data transmission and improve privacy, but it can also make behavior less visible to auditors. AI accelerators can increase productivity while intensifying energy use or enabling harmful applications.

Privacy should be addressed architecturally through data minimization, purpose limitation, access control, encryption, retention limits, isolation, and, where suitable, local or federated processing. Privacy is not achieved merely by adding a policy document after deployment. System boundaries determine what data is collected, where it travels, who can access it, and how long it persists.

Ethical review should consider affected stakeholders, unequal impacts, explainability needs, human oversight, accessibility, and the possibility of misuse. In cyber-physical systems, the analysis must include physical safety and the consequences of automation failure.

Export controls and technology-transfer restrictions can affect advanced processors, accelerators, design tools, cryptographic technology, and manufacturing equipment. Organizations must assess jurisdiction, end use, end user, licensing, technical thresholds, and re-export obligations. These constraints can alter platform roadmaps, supplier selection, support arrangements, and cloud-region choices. Compliance should involve legal and trade specialists; engineers should not assume that a technically available component is legally deployable in every location.

Architecture Choices Across Deployment Environments

Enterprise Systems

Enterprise architectures generally emphasize availability, integration, security, maintainability, and predictable total cost. Standard platforms are often preferred because they simplify staffing and operations. Specialization is justified when a workload has substantial scale or when latency, confidentiality, or regulatory constraints cannot be met by general-purpose infrastructure.

Cloud Computing

Cloud architecture converts many hardware decisions into service-selection decisions. Customers choose compute instances, accelerators, storage, networking, and managed services while providers control much of the underlying architecture. Strategic concerns include workload portability, data location, service-level agreements, cost variability, observability, provider concentration, and the distinction between provider responsibility and customer responsibility.

Edge Computing

Edge systems move computation closer to sensors, users, or machines. Benefits include lower latency, reduced bandwidth use, resilience during disconnection, and local data control. Constraints include limited power, physical exposure, intermittent management connectivity, heterogeneous hardware, and difficult field replacement. Edge roadmaps should prioritize secure remote update, identity management, fleet observability, graceful degradation, and long support lifetimes.

Cyber-Physical Systems

Cyber-physical systems combine computation with physical processes. Their architecture must integrate timing, sensing, actuation, control stability, safety, cybersecurity, and human interaction. Average performance is often less important than bounded worst-case response. A security update that is safe for an office server may be unsafe for a continuously operating industrial controller unless it has been validated under the relevant operating conditions.

Emerging Directions in Computer Architecture

Chiplets and Advanced Packaging

Chiplets divide a system into smaller dies that are integrated in a package. This approach can improve manufacturing yield, allow reuse of specialized dies, and combine technologies optimized for different functions. It may also reduce the cost and complexity of producing one very large monolithic die.

The strategic challenge is integration. Chiplet interfaces, packaging reliability, thermal behavior, testing, security boundaries, and supply-chain qualification become central concerns. A chiplet ecosystem can reduce dependence on one supplier only if interfaces are sufficiently open and compatible. Otherwise, it may create a new form of packaging-level lock-in.

Three-Dimensional Integration

3D integration stacks active layers or memory above one another, shortening interconnects and increasing density. Potential advantages include high bandwidth and compact form factors. Thermal removal, manufacturing yield, test access, mechanical reliability, and fault containment are significant constraints. The architecture must be evaluated as a system: a denser design is not beneficial if thermal throttling eliminates its expected performance.

Photonic Computing and Interconnects

Photonic technologies use light for communication and, in some approaches, computation. Optical interconnects can offer high bandwidth and potentially lower communication energy over suitable distances. Photonic computing may be attractive for specialized linear-algebra operations, but programming models, precision, conversion overhead, manufacturing variability, and integration with electronic control remain important limitations. Near-term value is often more plausible in communication and accelerator subsystems than in wholesale replacement of electronic general-purpose processors.

Neuromorphic Computing

Neuromorphic systems imitate selected principles of biological neural processing, often using event-driven communication, distributed memory, and spiking computation. They may provide high efficiency for sparse, temporal, or sensory workloads. Their adoption is constrained by unfamiliar programming models, limited software ecosystems, training complexity, and difficulty mapping conventional applications. A credible evaluation requires comparing complete application pipelines, including data conversion and model development, rather than accelerator throughput alone.

Quantum-Assisted Computing

Quantum-assisted computing uses quantum processors or quantum-inspired methods alongside classical systems. Quantum devices are expected to remain specialized because of noise, error correction costs, control requirements, and limited algorithmic applicability. A realistic architecture may include classical preprocessing, quantum execution, error mitigation, and classical post-processing. The strategic question is whether a problem has a suitable algorithm and whether the complete workflow improves a meaningful business or scientific objective.

Illustrative Case Study: A Resilient Edge Analytics Platform

Background

Consider a fictional logistics company operating refrigerated vehicles and warehouses. Sensors report temperature, location, door status, and equipment condition. The company wants predictive maintenance and rapid detection of unsafe temperature excursions.

Situation and Problem

The existing design sends all sensor data to a central cloud. It provides useful historical analytics but depends on network availability, incurs growing transmission costs, and can respond too slowly to protect temperature-sensitive goods. The company is considering custom edge hardware, an off-the-shelf industrial computer, or a managed cloud-edge platform.

Analysis

Workload analysis shows that local threshold detection requires deterministic response and modest computation. Predictive models require more memory and periodic updates but need not run at millisecond scale. Devices operate in harsh environments and may be offline for several hours. Privacy risk is moderate, but supply interruption and field-maintenance cost are high.

A custom processor could reduce energy consumption, but the company lacks hardware-design and long-term firmware expertise. A fully managed platform would accelerate deployment but create dependence on one provider and might not support all field conditions. An industrial computer with a standard processor, secure boot, replaceable storage, and a containerized runtime provides a balanced initial option.

Approach and Strategy

The company adopts a hybrid architecture. Safety-related threshold detection and local buffering run at the edge. Predictive-model training and fleet-wide analysis run in the cloud. Data is summarized locally, while selected raw data is retained for diagnostic sampling. The platform uses signed updates, device identity certificates, encrypted communication, remote health monitoring, and a documented migration path to a second hardware supplier.

A pilot is conducted on a representative route and warehouse environment. Decision gates measure response time, energy consumption, offline durability, false alarms, update reliability, and total operating cost. The company also records component provenance and establishes a five-year support and retirement plan.

Outcome

The hybrid design reduces dependence on continuous connectivity and allows urgent actions to occur locally. It avoids the cost and organizational risk of developing custom silicon while preserving the option to introduce a specialized accelerator if model workloads grow. Governance reviews are scheduled after the pilot, before production expansion, and at each major firmware or model change.

Learning Points

The case demonstrates that architecture strategy begins with workload and failure analysis. It also shows why build-versus-buy decisions should consider skills, lifecycle obligations, interoperability, and exit options. The best architecture is often not the most specialized one, but the one that preserves operational resilience and future choices.

Challenges, Limitations, and Common Mistakes

Strategic architecture is affected by uncertain forecasts. Workloads change, suppliers fail, regulations evolve, and emerging technologies mature unevenly. Excessive confidence in long-range predictions can produce stranded investments. Scenario planning and staged commitments reduce this risk.

A common mistake is optimizing acquisition price while ignoring integration and lifecycle cost. Another is treating benchmarks as universal evidence. Organizations also underestimate migration effort, especially for software tied to undocumented hardware behavior, proprietary libraries, or provider-specific services.

Governance can fail in two opposite ways. Weak governance permits uncontrolled diversity, hidden dependencies, and unmanaged risk. Excessive governance delays innovation and encourages teams to bypass formal processes. Effective governance is proportionate to impact and uses evidence appropriate to the system.

Emerging technologies create a further danger: pilot success may be confused with production readiness. A prototype may not include thermal management, failure recovery, toolchain maintenance, security updates, certification, or supply continuity. Production decisions require complete-system evaluation.

Best Practices for Strategic Architecture

A mature organization should:

• define measurable workload and mission requirements before selecting technology;
• compare total lifecycle cost rather than acquisition price alone;
• document assumptions, alternatives, decision rights, and review dates;
• use open and stable interfaces where they reduce migration risk;
• maintain inventories of hardware, firmware, software, suppliers, and dependencies;
• design security, privacy, safety, and compliance into the architecture;
• conduct pilots with explicit success and failure criteria;
• preserve exit options through portability testing and qualified alternatives;
• align support periods with the physical and economic life of the system; and
• evaluate emerging technologies through complete application workflows.

Chapter Summary

Architecture strategy extends computer design from component selection to long-term organizational decision-making. It uses workload evidence, scenario planning, lifecycle economics, and risk analysis to create platform roadmaps. Build, buy, partner, and hybrid choices must account for differentiation, maturity, skills, lock-in, supply continuity, and total cost of ownership.

Standards and interoperability create valuable boundaries, but they require conformance testing and semantic agreement. Governance coordinates architecture decisions across design, operation, upgrade, and retirement. Supply-chain assurance, privacy, ethics, export controls, and safety are architectural concerns rather than administrative afterthoughts. Enterprise, cloud, edge, and cyber-physical systems require different balances of performance, determinism, resilience, and manageability.

Chiplets, 3D integration, photonic systems, neuromorphic processors, and quantum-assisted computing offer important possibilities but also introduce integration, thermal, software, maturity, and governance challenges. Sound strategy uses staged investment, representative evaluation, and explicit decision gates to capture benefits without treating emerging technology as an inevitable solution.

Key Terms

Architecture strategy: A coordinated plan for selecting, evolving, and governing technical platforms in support of organizational objectives.

Platform roadmap: A time-oriented plan describing current capabilities, transition states, target capabilities, dependencies, and decision gates.

Workload characterization: Measurement and analysis of the computational, memory, communication, timing, energy, and reliability properties of an application.

Total cost of ownership: The complete lifecycle cost of acquiring, integrating, operating, securing, upgrading, and retiring a system.

Vendor lock-in: Dependence on a supplier that makes migration or substitution difficult or costly.

Interoperability: The ability of independent systems to exchange and correctly use information.

Architecture governance: Decision rights, controls, review practices, and evidence requirements used to manage architecture.

Technical debt: Future cost and risk created by expedient or poorly maintained technical decisions.

Supply-chain risk: Exposure to disruption, compromise, counterfeit components, dependency, or weakness across suppliers and production stages.

Hardware root of trust: A protected hardware foundation used to establish device identity, secure boot, or cryptographic trust.

Privacy by design: Incorporating privacy protections into system architecture from the beginning.

Export control: Legal restriction on transferring specified technologies, products, services, or technical knowledge.

Chiplet: A separately fabricated die integrated with other dies in a common package.

3D integration: Stacking or vertically connecting active semiconductor layers or dies.

Photonic computing: Computing or communication that uses optical signals or components.

Neuromorphic computing: Computing designed around selected principles of neural or event-driven information processing.

Quantum-assisted computing: Use of quantum processors or methods as specialized components within a broader classical workflow.

Real-options reasoning: An approach that values staged investment and preservation of future choices under uncertainty.

Review Questions

Short Answer Questions

1. Why is architecture strategy broader than processor or system design?

2. What dimensions should be included in workload characterization?

3. Distinguish between interoperability and mere connectivity.

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

5. Why can a custom accelerator create lifecycle risk?

Long Answer Questions

1. Explain how an organization can construct an evidence-based platform roadmap.

2. Compare build, buy, partner, and hybrid sourcing strategies using total cost and risk.

3. Discuss the role of governance across the complete technology lifecycle.

4. Analyze supply-chain, privacy, ethical, and export-control concerns in platform strategy.

5. Compare the opportunities and limitations of chiplets, 3D integration, photonic, neuromorphic, and quantum-assisted computing.

Analytical / Application Questions

1. A bank wants to move fraud detection from a central cloud to branch-edge systems. Develop a decision framework addressing latency, privacy, security, manageability, and supplier dependence.

2. An industrial firm is offered a highly efficient proprietary accelerator with no second supplier. Determine what evidence and safeguards should be required before adoption.

3. A university plans to deploy a quantum-assisted optimization service. Design a staged roadmap that distinguishes experimentation from production value and identifies suitable decision gates.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes architecture strategy?

A. Selecting the processor with the highest benchmark score

B. Planning and governing technical capabilities over time in relation to organizational objectives

C. Replacing all specialized systems with cloud services

D. Documenting only the physical arrangement of hardware

Correct Answer: B. Planning and governing technical capabilities over time in relation to organizational objectives

Question 2

Which factor is least suitable as a sole basis for selecting a platform?

A. Representative production workload measurements

B. Lifecycle support and migration cost

C. A synthetic benchmark unrelated to the target application

D. Security and supply-chain evidence

Correct Answer: C. A synthetic benchmark unrelated to the target application

Question 3

A hybrid sourcing strategy most commonly means that an organization:

A. Avoids all external suppliers

B. Buys every component from one vendor

C. Builds differentiating elements while acquiring common infrastructure

D. Uses only experimental technologies

Correct Answer: C. Builds differentiating elements while acquiring common infrastructure

Question 4

Which practice most directly reduces the risk of undocumented architecture exceptions?

A. Making exceptions permanent

B. Assigning an owner, time limit, and review condition to each exception

C. Removing architecture governance

D. Evaluating exceptions only after system retirement

Correct Answer: B. Assigning an owner, time limit, and review condition to each exception

Question 5

Why might open interfaces be strategically valuable?

A. They guarantee identical performance from all suppliers

B. They can reduce migration barriers and support supplier diversity

C. They eliminate the need for conformance testing

D. They prevent all forms of vendor lock-in

Correct Answer: B. They can reduce migration barriers and support supplier diversity

Question 6

Which architecture is most likely to require bounded worst-case response rather than average throughput as its primary concern?

A. A cyber-physical control system

B. An offline document archive

C. A batch reporting warehouse

D. A media streaming catalogue

Correct Answer: A. A cyber-physical control system

Question 7

What is a major strategic concern specific to chiplet-based systems?

A. The impossibility of combining different manufacturing technologies

B. Packaging, interface, thermal, testing, and supply-chain integration

C. The elimination of all software dependencies

D. The requirement that every die use the same process technology

Correct Answer: B. Packaging, interface, thermal, testing, and supply-chain integration

Question 8

Which statement about quantum-assisted computing is most appropriate?

A. It automatically improves every computational workload

B. It should be evaluated as part of a complete classical-quantum workflow

C. It removes the need for classical preprocessing

D. It is already a general replacement for conventional processors

Correct Answer: B. It should be evaluated as part of a complete classical-quantum workflow

Question 9

A field edge device must operate during network outages. Which design choice most directly supports this requirement?

A. Sending all sensor data to the cloud before taking action

B. Local processing, buffering, and graceful degradation

C. Removing remote update capability

D. Using only a centralized database

Correct Answer: B. Local processing, buffering, and graceful degradation

Question 10

Why should emerging architectures be evaluated through complete application pipelines?

A. Accelerator peak throughput always predicts business value

B. Conversion, programming, thermal, and integration costs may change the practical result

C. Prototypes never require security analysis

D. Complete workflows are less representative than isolated components

Correct Answer: B. Conversion, programming, thermal, and integration costs may change the practical result