High Performance Computing

Chapter 14
HPC Strategy, Economics and Sustainable Management

Post Graduate Diploma in Data Science
High Performance Computing   •   Post Graduate

14. HPC Strategy, Economics and Sustainable Management

Introduction and Context

High-performance computing (HPC) is often introduced as a technical capability: a collection of processors, memory, storage, networks, schedulers, and software used to execute demanding workloads. At postgraduate level, however, HPC must also be understood as an organizational capability and an investment decision. A cluster that delivers excellent benchmark results may still be strategically unsuccessful if it is underutilized, too expensive to operate, difficult to govern, or poorly aligned with the institution’s research and business priorities.

HPC strategy therefore connects architecture with economics, service management, risk, sustainability, and organizational change. The central question is not simply, “Which processor or accelerator should be purchased?” It is, “What computational capability should the organization own, consume, or obtain through partnership in order to achieve measurable strategic outcomes at an acceptable cost and risk?”

This chapter examines total cost of ownership (TCO), capacity planning, sourcing alternatives, service-level objectives, risk management, energy efficiency, carbon accounting, and governance. It also considers how HPC supports digital transformation, including data-intensive science, artificial intelligence, simulation, and advanced analytics.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain why HPC decisions are strategic rather than exclusively technical.

2. Calculate and interpret major components of HPC total cost of ownership.

3. Compare on-premises, cloud, colocation, managed, and hybrid sourcing models.

4. Apply capacity-planning methods using demand, utilization, queueing, and growth assumptions.

5. Define appropriate service-level objectives and performance indicators.

6. Evaluate energy, carbon, resilience, security, and operational risks.

7. Recommend an HPC investment and governance approach for a realistic organization.

8. Relate HPC strategy to digital transformation and sustainable management.

From Computing Infrastructure to Strategic Capability

An HPC service creates value through a chain of activities. Users submit workloads; schedulers allocate resources; software environments make applications reproducible; storage and networks move data; support teams resolve failures; and governance ensures that access is fair, secure, and aligned with institutional priorities. The system’s value is therefore determined by more than peak floating-point performance.

Useful strategic measures include scientific or commercial outputs per unit of cost, time-to-solution, proportion of successful jobs, user productivity, energy consumed per completed workload, and the speed with which new software or hardware can be introduced. For example, reducing the runtime of a drug-design simulation from ten days to one day may have greater strategic value than increasing a benchmark score by 20 percent if the shorter runtime changes the organization’s research cycle.

A strategy should begin with demand and outcomes. Important questions include:

  • Which workloads are business-critical, research-critical, or exploratory?
  • Are workloads tightly coupled, embarrassingly parallel, data-intensive, interactive, or accelerator-dependent?
  • What growth is expected in users, data volume, model size, and experiment frequency?
  • Which data may leave the organization, and which must remain controlled?
  • What response time, availability, and recovery characteristics are required?
  • Which capabilities are differentiating and should be retained internally?

These questions prevent technology selection from becoming an isolated procurement exercise.

The Economics of HPC: Looking Beyond Purchase Price

Total Cost of Ownership

TCO is the total economic burden of acquiring, operating, renewing, and retiring an HPC capability over a defined period. A simple lifecycle model is:

TCO = capital expenditure + operating expenditure + transition costs − residual value

Capital expenditure may include compute nodes, accelerators, memory, interconnects, storage, racks, power-distribution equipment, and initial software licences. Operating expenditure includes electricity, cooling, floor space, networking, maintenance contracts, software subscriptions, personnel, training, security, monitoring, and support. Transition costs include migration, data transfer, application porting, testing, procurement effort, and user disruption. Residual value may be small for rapidly depreciating equipment but should not be ignored when assets can be reused.

A more realistic analysis discounts future cash flows. If a cost occurring in year t is represented by Cₜ and the discount rate is r, its present value is:

PV(Cₜ) = Cₜ /(1 + r)ᵗ

The choice of discount rate, lifecycle length, utilization assumption, and electricity price can materially change the result. Consequently, TCO should be presented as a range or scenario analysis rather than as a falsely precise number.

Direct, Indirect, and Opportunity Costs

Direct costs are relatively visible: equipment invoices, cloud consumption charges, electricity bills, and support contracts. Indirect costs include administrators’ time, procurement delays, downtime, application redesign, security assessments, and the cost of learning a new platform. Opportunity cost is the value of work not undertaken because capacity is unavailable or because staff are occupied with infrastructure problems.

A low-cost cluster with long queues can be economically inferior to a more expensive platform that enables researchers or analysts to complete high-value work sooner. Similarly, cloud consumption may look expensive per compute-hour but be attractive when demand is uncertain and the alternative is purchasing hardware that remains idle.

Unit Economics and Cost Attribution

Managers need unit measures that connect spending to service consumption. Examples include cost per node-hour, cost per GPU-hour, cost per terabyte-month, cost per completed workflow, and energy cost per simulation. Internal chargeback or showback systems can make consumption visible. Chargeback recovers costs from users; showback reports costs without necessarily billing them. Both approaches should be designed carefully so that they encourage efficient use without discouraging strategically important experimentation.

Cost attribution is difficult in shared systems. A storage service may support many projects, while staff effort benefits the entire user community. A transparent allocation model can combine fixed institutional funding with variable usage charges. Strategic or early-stage work may receive subsidies, while commercial projects or exceptional consumption may pay marginal costs.

Sourcing and Architecture Choices

Owned Infrastructure

An owned facility provides control over hardware, data placement, network design, scheduling policy, and long-term optimization. It may be economical for stable, high utilization and predictable workloads. It also supports specialized configurations that are unavailable from general-purpose providers. Its weaknesses include large upfront investment, refresh risk, facility constraints, and responsibility for every operational layer.

Cloud HPC

Cloud services convert much infrastructure spending into variable expenditure and offer rapid access to capacity, specialized accelerators, and geographically distributed resources. They are attractive for burst workloads, temporary projects, and uncertain demand. However, costs can increase through data movement, persistent storage, premium instances, support plans, and poorly controlled provisioning. Performance variability, service dependency, compliance, and vendor lock-in also require analysis.

Cloud economics should not be assessed solely through list prices. A complete model includes compute, storage, input/output operations, data egress, licensing, orchestration, security controls, staff time, and idle resources. Reserved or committed-use pricing may reduce cost for predictable workloads but can recreate the commitment risk of owned hardware.

Colocation and Managed Services

Colocation places organizational equipment in a professional data centre. It can provide better power, cooling, connectivity, and physical security without requiring the organization to construct its own facility. Managed HPC goes further by outsourcing selected operational responsibilities. These approaches can be useful where the institution needs control over hardware but lacks facilities or operational expertise.

Hybrid and Federated Models

A hybrid model combines local resources with cloud or partner resources. Stable, sensitive, or latency-dependent workloads may remain on premises, while peaks, specialized accelerators, or experimentation move externally. A federated model links resources across departments or institutions through common identity, scheduling, data, and governance mechanisms. Hybrid strategies create flexibility but also introduce complexity in workload portability, monitoring, security, accounting, and data movement.

The appropriate sourcing decision depends on workload shape rather than organizational fashion. A useful decision matrix evaluates utilization, sensitivity, elasticity, latency, software portability, capital availability, staff capability, and strategic differentiation.

Capacity Planning as an Evidence-Based Process

Capacity planning estimates how much resource is needed, when it is needed, and with what service quality. It should combine historical utilization with a demand forecast. Relevant variables include number of users, job arrival rate, job duration, concurrency, memory requirements, storage growth, network traffic, accelerator demand, and expected changes in algorithms.

Average utilization can conceal service failure. A cluster operating at 70 percent average utilization may experience severe queues during peak periods. Conversely, designing for 100 percent utilization leaves no room for failures, maintenance, or growth. Capacity planning should examine peak demand, percentile demand, and queue behavior rather than averages alone.

Queueing concepts are particularly useful. If jobs arrive faster than the system can complete them, waiting time increases nonlinearly as utilization approaches saturation. Short jobs may be delayed behind large jobs, creating perceived unfairness. Schedulers can address this through fair-share policies, backfilling, reservations, priority classes, and quality-of-service partitions. These mechanisms involve trade-offs between utilization, fairness, and deadline performance.

A practical planning cycle includes:

1. Establish a workload inventory and classify applications.

2. Collect demand, runtime, failure, queue, energy, and storage data.

3. Forecast growth using conservative, expected, and high-demand scenarios.

4. Model alternative capacity additions, procurement dates, and sourcing options.

5. Validate assumptions through pilots or benchmark workloads.

6. Review the plan periodically and revise it when workload behavior changes.

Capacity should include resilience margins. If a critical service requires 1,000 effective cores, purchasing exactly 1,000 physical cores may be inappropriate because maintenance, failures, and scheduling fragmentation reduce usable capacity.

Service Levels and Performance Governance

HPC service levels translate strategic expectations into measurable commitments. A service-level objective (SLO) might specify that 95 percent of standard jobs begin within a defined time, that the service is available during agreed operating hours, or that critical data is recoverable within a target period. A service-level agreement (SLA) is a more formal commitment between provider and consumer and may include remedies or reporting requirements.

Important indicators include:

  • availability and planned versus unplanned downtime;
  • job success rate and mean time to recovery;
  • queue waiting time by job class;
  • utilization of compute, memory, storage, and accelerators;
  • application performance and time-to-solution;
  • energy per node-hour or workload;
  • support response and resolution time; and
  • user satisfaction and reproducibility of environments.

Metrics must be interpreted together. High utilization is not automatically good if users experience unacceptable waiting times. Low queue time may indicate excess capacity or weak demand. A balanced scorecard is preferable to a single benchmark.

Risk, Resilience, and Governance

HPC risk is multidimensional. Hardware failure, software defects, cyberattack, data loss, skills shortages, supplier insolvency, energy price volatility, regulatory restrictions, and procurement delays can all affect outcomes. Risk registers should identify likelihood, impact, existing controls, owners, and treatment plans.

Resilience includes redundancy where justified, tested backups, alternative scheduling capacity, documented recovery procedures, monitoring, and spare components. High availability is not identical to disaster recovery. A system may remain operational during a component failure yet still lack a credible plan for site loss or major data corruption.

Cybersecurity must be integrated into architecture and operations. Controls include identity federation, least privilege, network segmentation, patch management, vulnerability scanning, secure images, logging, incident response, and protection of research data. HPC environments can be attractive targets because compromised nodes provide substantial computational power. Governance should also address acceptable use, export controls, intellectual property, data classification, software licensing, and responsible access to AI models or sensitive datasets.

A governance board should include technical staff, finance, security, research or business representatives, and users. Its responsibilities may include prioritizing investments, approving sourcing exceptions, reviewing utilization and sustainability, setting allocation policies, and overseeing lifecycle decisions.

Energy Efficiency, Carbon, and Sustainable Management

Energy is both a financial and environmental concern. The total energy footprint includes direct electricity used by compute, memory, storage, networking, and cooling, as well as embodied emissions associated with manufacturing, transport, construction, and disposal. Carbon accounting should distinguish operational emissions from embodied emissions and should state the boundary and assumptions used.

Power Usage Effectiveness (PUE) is commonly expressed as:

PUE = total data-centre energy / IT equipment energy

A lower PUE indicates less overhead from cooling and facility systems, but PUE alone does not measure computational efficiency. A system may have an excellent PUE while wasting energy through idle nodes or inefficient applications. More informative measures include energy-to-solution, performance per watt, carbon per completed workload, and useful work per unit of embodied carbon.

Sustainable management can involve efficient processors, dynamic power management, liquid cooling where appropriate, workload consolidation, turning off idle resources, thermal-aware scheduling, renewable electricity procurement, and application optimization. Algorithmic improvements are often especially valuable: reducing iterations, improving memory locality, compressing data movement, or using mixed precision can reduce both runtime and energy.

Carbon-aware scheduling can move flexible workloads to times or locations with lower grid carbon intensity, provided that data governance, deadlines, and cost remain acceptable. It should not be treated as a universal solution; transferring workloads between regions may increase network energy and complicate compliance.

Lifecycle decisions require balance. Replacing equipment early may improve operational efficiency but create additional embodied emissions. Extending hardware life may be sustainable if reliability and performance remain adequate. Reuse, refurbishment, responsible recycling, and supplier environmental disclosures should be part of procurement.

Aligning HPC with Digital Transformation

Digital transformation is not merely the purchase of advanced hardware. It involves redesigning processes, data flows, decision-making, and capabilities around digital technologies. HPC can support transformation by enabling digital twins, large-scale optimization, high-resolution forecasting, generative design, molecular simulation, and machine-learning model development.

Strategic alignment requires a portfolio view. Some workloads create immediate operational value; others build long-term capability or scientific knowledge. Investment cases should define outcomes such as reduced design-cycle time, improved forecast accuracy, increased research competitiveness, new services, or compliance with analytical requirements. Benefits should be tracked after deployment rather than assumed at procurement.

Automation is central to sustainable HPC operations. Infrastructure-as-code can make environments reproducible. Observability platforms can correlate queue behavior, application performance, and energy use. Policy-based schedulers can enforce quotas, reservations, and carbon preferences. Machine learning may predict failures, classify workloads, recommend resource configurations, or identify anomalous consumption. Such automation requires reliable data and human oversight; an opaque optimization model should not override safety, fairness, or governance controls without review.

Illustrative Case: A University Research and Analytics Platform

Background

A fictional university operates a five-year-old CPU cluster supporting climate modelling, computational chemistry, engineering simulation, and postgraduate data-science projects. Demand has grown, and researchers increasingly request GPUs. The institution is considering a major replacement, cloud bursting, or a managed partnership.

Situation and Problem

The cluster has high average utilization, but users report long waits at the beginning of each semester. Some nodes are idle because jobs request large contiguous allocations. Storage is approaching capacity, electricity costs are rising, and only two engineers understand the scheduler and interconnect. Finance prefers predictable expenditure, while researchers want rapid access to GPUs. Several projects contain restricted data that cannot be transferred without assessment.

Analysis

The university first collects six months of scheduler, storage, energy, and support data. It separates jobs into four classes: tightly coupled simulations, ordinary CPU batch jobs, GPU experiments, and interactive teaching workloads. It finds that CPU demand is relatively stable, GPU demand is uncertain but rapidly increasing, and teaching peaks are predictable. It also estimates the cost of new hardware, facility upgrades, staffing, software migration, cloud consumption, data transfer, and retirement.

Rather than compare only purchase price, the team models three scenarios: full local replacement, cloud-first provision, and a hybrid platform. Each scenario is evaluated against five-year TCO, queue-time targets, data restrictions, carbon per workload, skills requirements, and resilience.

Strategy and Solution

The university selects a hybrid strategy. It purchases a moderate local CPU and GPU system sized for baseline demand and sensitive workloads. It negotiates cloud capacity for seasonal teaching peaks, experimental GPU demand, and overflow. A common container and workflow standard is adopted to improve portability. The scheduler is configured with separate quality-of-service classes, fair-share allocation, backfilling, and reservations for teaching periods.

A financial showback dashboard reports compute, storage, and energy consumption by project. Strategic research receives institutional subsidy, but unusually large discretionary workloads receive an internal cost signal. The university funds cross-training so that operational knowledge is not concentrated in two individuals. It also establishes quarterly reviews of demand, carbon, queue times, and cloud spending.

Outcome

The strategy reduces dependence on a single capacity source, improves predictability for sensitive workloads, and provides a controlled route to specialized cloud resources. The university does not assume that all workloads should move to the cloud or that all capacity should be owned. Instead, sourcing follows workload characteristics and strategic priorities.

Learning Points

The case illustrates five principles: TCO must include people and transition costs; capacity must be planned around peaks and service levels; hybrid models require portability and governance; sustainability needs workload-level measures; and investment decisions should be reviewed as demand changes.

Common Mistakes and Limitations

Several errors recur in HPC strategy. Organizations may select systems by peak performance while ignoring application performance, memory capacity, or data movement. They may underestimate staffing and software-porting costs, assume cloud elasticity is free, or purchase capacity without a retirement plan. Another mistake is to measure utilization without measuring user outcomes and queue fairness.

Forecasts are inherently uncertain. New algorithms, changes in funding, AI adoption, energy prices, or regulatory requirements may invalidate assumptions. TCO models also depend on accounting boundaries and uncertain residual values. For this reason, decision makers should use sensitivity analysis and real options thinking: phased investments, pilot agreements, and expandable architectures can preserve flexibility when uncertainty is high.

Sustainability metrics also have limitations. PUE does not capture embodied carbon, and carbon intensity varies by region and time. Performance-per-watt comparisons may favour benchmarks that do not represent production workloads. Metrics should therefore be transparent, workload-relevant, and accompanied by boundaries and measurement methods.

Best-Practice Decision Framework

A defensible HPC strategy can be organized into six questions:

1. Purpose: Which organizational outcomes require HPC?

2. Workload: What computational, data, latency, and software characteristics exist?

3. Economics: What is the lifecycle cost under realistic utilization and growth scenarios?

4. Service: What availability, queue, recovery, and support levels are required?

5. Risk: Which security, regulatory, supplier, skills, and resilience risks must be controlled?

6. Sustainability: What energy, carbon, lifecycle, and social impacts follow from each option?

The resulting recommendation should state assumptions, alternatives rejected, decision criteria, sensitivity to uncertainty, implementation phases, owners, and review points. A strategy is credible when it can explain not only what will be purchased, but why it will create value and how that value will be measured.

Current Developments and Emerging Directions

HPC management is increasingly shaped by heterogeneous computing, AI accelerators, composable infrastructure, confidential computing, and disaggregated storage. Demand for large language models and scientific machine learning is changing capacity profiles, particularly for GPUs, high-bandwidth memory, and high-speed interconnects. Cloud marketplaces and federated research infrastructures are expanding access, while sovereign and regulated computing requirements are encouraging regional or nationally controlled resources.

The strategic challenge is to avoid treating every emerging technology as an automatic investment. Pilots, representative benchmarks, portability testing, and benefits realization reviews should precede large commitments. Sustainable HPC will increasingly evaluate not only speed but also energy, carbon, hardware lifetime, supply-chain responsibility, and the social value of the workloads enabled.

Chapter Summary

HPC strategy combines technical architecture with financial, organizational, service, risk, and sustainability decisions. Total cost of ownership must include capital, operations, personnel, transition, energy, data movement, and lifecycle costs. On-premises, cloud, colocation, managed, and hybrid models each suit different workload and governance conditions. Capacity planning should use demand forecasts, peak behavior, queueing, resilience margins, and service-level objectives rather than average utilization alone.

Effective management measures time-to-solution, queue performance, reliability, cost per useful workload, energy, and carbon. Governance addresses security, data protection, allocation fairness, licensing, skills, and supplier risk. Digital transformation benefits arise when HPC is connected to measurable organizational outcomes and supported by portable software, automation, observability, and benefits review. Sustainable choices consider operational and embodied carbon across the equipment lifecycle. The strongest strategy is evidence-based, scenario-driven, and flexible enough to adapt as workloads and organizational priorities change.

Key Terms

Total Cost of Ownership (TCO): The complete lifecycle cost of acquiring, operating, renewing, and retiring a system.

Capital Expenditure (CapEx): Upfront spending on assets such as servers, storage, and facilities.

Operating Expenditure (OpEx): Recurring costs such as power, support, staffing, and subscriptions.

Showback: Reporting resource consumption and associated costs to users without necessarily charging them.

Chargeback: Recovering service costs from the consuming department or project.

Capacity Planning: Forecasting and providing resources to meet present and future demand.

Utilization: The proportion of available resource capacity that is actively used.

Queueing: The waiting process that occurs when workload demand exceeds immediately available capacity.

Service-Level Objective (SLO): A measurable target for service performance or reliability.

Service-Level Agreement (SLA): A formal commitment defining service expectations and responsibilities.

Hybrid HPC: An arrangement combining local infrastructure with external or cloud resources.

Federated Computing: Coordinated use of resources belonging to multiple organizations or domains.

Power Usage Effectiveness (PUE): Total facility energy divided by IT equipment energy.

Embodied Carbon: Emissions associated with manufacturing, transporting, and disposing of equipment.

Operational Carbon: Emissions caused by energy consumed during system operation.

Energy-to-Solution: Energy required to complete a defined workload or computational result.

Carbon-Aware Scheduling: Scheduling flexible work according to variations in electricity carbon intensity.

Showback: Transparent reporting of resource use and its estimated cost to consumers.

Benefits Realization: The process of verifying that an investment produces its intended organizational outcomes.

Risk Register: A structured record of risks, likelihood, impact, controls, owners, and treatments.

Review Questions

Short Answer Questions

1. What cost categories should be included in an HPC TCO model?

2. Distinguish between showback and chargeback.

3. Why can average cluster utilization be misleading?

4. Define PUE and explain one limitation of using it alone.

5. What is the difference between an SLO and an SLA?

Long Answer Questions

1. Compare owned, cloud, colocation, managed, and hybrid HPC sourcing models.

2. Explain how capacity planning can combine workload classification, demand forecasting, queueing, and resilience margins.

3. Discuss the financial and strategic importance of personnel, transition, and opportunity costs in HPC procurement.

4. Explain how governance and cybersecurity should influence HPC architecture and operations.

5. Discuss how operational carbon, embodied carbon, and energy-to-solution contribute to sustainable HPC management.

Analytical / Application Questions

1. An organization has stable CPU demand, unpredictable GPU demand, sensitive data, and limited infrastructure staff. Recommend a sourcing strategy and justify it using TCO, risk, service, and sustainability criteria.

2. A cluster reports 85 percent utilization, but users experience long waits and many large jobs fail. Diagnose possible causes and propose capacity, scheduling, and measurement improvements.

3. Construct a five-year decision framework for replacing an HPC system. Identify assumptions, scenarios, metrics, governance controls, and review points that would make the recommendation defensible.

22. Multiple Choice Questions with Answers

Question 1

Which item is most likely to be omitted from a narrow purchase-price analysis but should be included in HPC TCO?

A. The colour of server racks

B. Application migration and staff training

C. The number of user passwords

D. The name of the scheduler

Correct Answer: B. Application migration and staff training

Question 2

A hybrid HPC strategy is most defensible when an organization has which combination of conditions?

A. Only completely stable demand and no data restrictions

B. No need for portability or external capacity

C. Stable baseline demand, occasional peaks, and varying workload sensitivity

D. A requirement that every workload run on identical hardware

Correct Answer: C. Stable baseline demand, occasional peaks, and varying workload sensitivity

Question 3

Why can a cluster with high average utilization still provide poor service?

A. Utilization always measures user satisfaction incorrectly

B. Peak demand and queueing may create long waits despite a reasonable average

C. High utilization proves that all jobs are completing successfully

D. Average utilization measures only electricity consumption

Correct Answer: B. Peak demand and queueing may create long waits despite a reasonable average

Question 4

Which metric most directly measures the energy efficiency of completing useful computational work?

A. Total number of installed nodes

B. Power Usage Effectiveness alone

C. Energy-to-solution

D. Number of software licences

Correct Answer: C. Energy-to-solution

Question 5

What is the principal purpose of a service-level objective in HPC management?

A. To specify measurable expected service performance

B. To guarantee that all users receive identical hardware

C. To eliminate the need for monitoring

D. To calculate embodied carbon automatically

Correct Answer: A. To specify measurable expected service performance

Question 6

An organization has low and uncertain workload demand but needs temporary access to specialized accelerators. Which economic characteristic most supports cloud use?

A. The ability to avoid all data-transfer costs

B. Conversion of some fixed infrastructure commitment into variable consumption

C. Guaranteed lower cost for every workload

D. Complete elimination of vendor and compliance risks

Correct Answer: B. Conversion of some fixed infrastructure commitment into variable consumption

Question 7

Which statement best distinguishes PUE from workload-level sustainability metrics?

A. PUE measures facility overhead, whereas energy-to-solution relates energy to completed work

B. PUE measures embodied carbon, whereas energy-to-solution measures staffing cost

C. PUE applies only to cloud systems, whereas energy-to-solution applies only to clusters

D. PUE measures queue time, whereas energy-to-solution measures availability

Correct Answer: A. PUE measures facility overhead, whereas energy-to-solution relates energy to completed work

Question 8

In the illustrative university case, why was a moderate local platform combined with cloud capacity?

A. To ensure that all workloads were permanently outsourced

B. To support baseline and sensitive workloads locally while handling peaks externally

C. To avoid adopting portable software standards

D. To maximize dependence on a single provider

Correct Answer: B. To support baseline and sensitive workloads locally while handling peaks externally

Question 9

Which governance practice best reduces the risk of knowledge concentration in a small HPC operations team?

A. Restricting documentation to senior administrators

B. Cross-training staff and documenting operational procedures

C. Removing monitoring systems

D. Allowing only one person to approve changes

Correct Answer: B. Cross-training staff and documenting operational procedures

Question 10

Why should an HPC investment proposal use sensitivity analysis?

A. Because workload growth, energy prices, utilization, and technology performance are uncertain

B. Because sensitivity analysis replaces the need for any cost model

C. Because it guarantees that the cheapest option is selected

D. Because all future costs can be known precisely

Correct Answer: A. Because workload growth, energy prices, utilization, and technology performance are uncertain

High Performance Computing
Chapter 14 of 15