AI Technology Architecture, Deployment and MLOps

Introduction

Artificial intelligence creates business value only when models are connected reliably to data, applications, employees, customers, and operational controls. A highly accurate model that cannot be integrated into a business process, updated safely, monitored in production, or protected against misuse is not a successful business system. AI technology architecture is therefore concerned with the design of the complete environment in which AI is developed, deployed, operated, governed, and improved.

This chapter examines cloud AI, application programming interfaces (APIs), data platforms, model serving, vector databases, build-versus-buy decisions, MLOps, LLMOps, monitoring, scalability, cybersecurity, and legacy-system integration. The emphasis is practical and managerial: students should be able to connect technical design choices with cost, risk, performance, compliance, and business outcomes.

Learning Objectives

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

1. Explain the major layers of an enterprise AI architecture.
2. Distinguish cloud AI services, APIs, data platforms, model-serving systems, and vector databases.
3. Evaluate build-versus-buy choices using business and technical criteria.
4. Describe the lifecycle practices of MLOps and LLMOps.
5. Select meaningful performance, reliability, data-quality, and model-monitoring measures.
6. Explain how scalability, cybersecurity, governance, and legacy integration affect AI deployment.
7. Design a practical deployment approach for an AI-enabled business application.

1. From AI Model to Business System

A machine-learning model is a computational artifact that maps inputs to predictions, classifications, rankings, or generated outputs. A business AI system is much broader. It includes data collection, identity management, preprocessing, model execution, application logic, human interaction, monitoring, audit records, and responses to failure.

A useful conceptual architecture has the following layers:

The layers are connected rather than strictly independent. For example, a customer-service assistant may retrieve policies from a vector database, send the retrieved context to a language model through an API, apply access rules in the application layer, and record quality and security events in the operations layer.

Architecture should begin with a business capability, not with a fashionable technology. Relevant questions include:

• What decision or task is being improved?
• Who is authorized to use the system?
• What data is required, and who owns it?
• What response time and availability are expected?
• What happens when the model is uncertain or unavailable?
• Is a human required to approve the result?
• Which laws, contractual requirements, or industry standards apply?

2. Cloud AI and Data Platforms

2.1 Cloud service models

Cloud AI enables organizations to obtain computing, storage, managed databases, model-training environments, and foundation-model services on demand. The main service models are:

• Infrastructure as a Service (IaaS): The organization manages virtual machines, operating systems, applications, and data while the provider manages physical infrastructure.
• Platform as a Service (PaaS): The provider manages more of the runtime and infrastructure, allowing teams to focus on applications and models.
• Software as a Service (SaaS): A complete application is delivered by the provider, usually through a browser or API.
• AI as a Service: A provider exposes capabilities such as translation, document extraction, forecasting, computer vision, or generative AI through managed services.

Cloud services offer elasticity, global availability, managed security controls, and rapid experimentation. They also create dependence on provider pricing, regional availability, service limits, data-processing terms, and proprietary interfaces. A cloud decision should therefore consider portability and exit costs, not only initial speed.

2.2 Data platforms

AI depends on data platforms that support both analytical and operational requirements.

A data warehouse organizes structured data for reporting and analytical queries. A data lake stores large volumes of structured, semi-structured, and unstructured data, often in relatively raw form. A lakehouse combines inexpensive, flexible storage with warehouse-like management, governance, and query capabilities.

Operational databases support frequent transactions. They should not automatically be used for intensive model training because analytical workloads may interfere with business operations. A common architecture copies or streams approved data into an analytical environment.

Important data-platform capabilities include:

• ingestion from applications, files, sensors, and external sources;
• batch and real-time processing;
• data-quality validation;
• metadata, lineage, and cataloguing;
• encryption and access control;
• retention and deletion policies;
• reproducible snapshots for model training;
• separation of development, testing, and production data.

A feature store manages features used by machine-learning models. Its value is consistency: the feature used during training should be calculated in a way compatible with the feature used during prediction. A feature store can also reduce duplicated engineering work and support feature discovery, ownership, and lineage.

3. APIs and Model Serving

An application programming interface is a defined contract through which software components communicate. A model API commonly accepts an input payload and returns a prediction, score, recommendation, or generated response. The contract should specify the schema, authentication method, error behavior, version, latency expectation, and usage limits.

A typical online inference request follows this sequence:

1. A user or business application submits a request.
2. An API gateway authenticates the caller and applies rate limits.
3. The service validates and transforms the input.
4. A model server loads or accesses the appropriate model.
5. The model generates an output.
6. Business rules, confidence thresholds, and authorization checks are applied.
7. The result is returned and relevant telemetry is recorded.

Model serving is the infrastructure that makes a trained model available for inference. Common patterns include:

• Real-time serving: Returns a response during an interactive transaction.
• Batch scoring: Processes many records on a schedule.
• Streaming inference: Processes events as they arrive.
• Embedded inference: Runs within an application, device, browser, or edge environment.
• Asynchronous inference: Accepts a request and later provides a result, useful for long-running jobs.

Latency is the elapsed time between a request and a usable response. Throughput is the amount of work completed per unit of time, such as requests per second. Availability is the proportion of time a service is operational according to an agreed definition.

A simple capacity approximation is:

If peak traffic is 20 requests per second and average service time is 0.25 seconds, the approximation is 5 concurrent request-equivalents. This is not a complete sizing formula: queueing, variability, memory, batching, hardware utilization, and safety capacity must also be considered. Systems should be tested under realistic peak and failure conditions.

Model-serving strategies include:

• Single model endpoint: Simple and suitable for a small number of models.
• Multi-model serving: Several models share infrastructure, improving utilization but increasing isolation and loading complexity.
• Canary deployment: A small percentage of traffic is sent to a new model before full release.
• Blue-green deployment: Two environments exist; traffic moves from the old version to the new version after validation.
• Shadow deployment: The new model receives copied traffic but does not affect user decisions.
• A/B testing: Different versions serve different user groups under a controlled experiment.

The choice depends on risk. A credit decision may require extensive validation and controlled rollout, whereas a low-risk product recommendation may tolerate faster experimentation.

4. Vector Databases and Retrieval-Augmented Generation

A vector, or embedding, represents an item as a numerical coordinate in a high-dimensional space. Texts with similar meanings may have nearby vectors, although similarity is dependent on the embedding model and the comparison method. A vector database stores embeddings and supports similarity search, often with metadata filtering.

A common similarity measure is cosine similarity:

Here, a and b are non-zero embedding vectors, a · b is their dot product, and ||a|| and ||b|| are their Euclidean lengths. Cosine similarity compares direction rather than magnitude and is often used when vector orientation represents semantic similarity. The value is between −1 and 1 for ordinary real-valued vectors, although many embedding applications produce non-negative similarity values in practice.

A vector-search pipeline normally includes:

1. Collecting authoritative documents.
2. Removing or masking inappropriate sensitive content.
3. Splitting documents into meaningful passages.
4. Generating embeddings.
5. Storing vectors with document identifiers and metadata.
6. Retrieving candidate passages for a query.
7. Applying metadata filters or reranking.
8. Supplying selected passages to a model or application.

Retrieval-augmented generation (RAG) combines retrieval with generation. Instead of asking a language model to answer solely from its learned parameters, the system retrieves relevant organizational information and places it in the prompt or context. RAG can improve grounding, citation, and updateability, but it does not guarantee truth. Poor chunking, incomplete documents, incorrect access filters, or irrelevant retrieval can still produce wrong answers.

Access control must be applied during retrieval, not merely after generation. A user must not receive passages that the user was not authorized to view, even if the final answer does not quote them directly. Documents should carry ownership, classification, tenant, and retention metadata.

5. Build, Buy, or Partner?

Organizations can build an AI capability internally, buy a packaged product, consume a managed model service, or combine these options. This is a strategic decision rather than a purely technical one.

A sound evaluation includes total cost of ownership. A simple five-year estimate can be represented as:

Here, TCO is total cost of ownership; C_initial is initial implementation cost; the summation covers years or periods t; the C terms represent compute, data, licensing, staff, and compliance costs; and V_residual represents any residual value or avoided cost. The formula is a planning model, not a guarantee. Costs should be adjusted for inflation, usage growth, migration, downtime, and exit costs.

Build is attractive when the capability is strategically differentiating, data is highly specialized, requirements are unusual, or regulatory control is central. Buy is attractive when the capability is standard, time to value is important, and a reputable supplier can meet security and performance requirements. A hybrid approach is common: an organization may buy a foundation model, build its retrieval and business workflow, and operate its own data controls.

Due diligence should cover data use by the supplier, service availability, model-change policy, audit rights, portability, incident notification, intellectual-property terms, geographical processing, subcontractors, and termination support.

6. MLOps: Operating the Machine-Learning Lifecycle

MLOps applies software engineering, data engineering, operations, and governance practices to machine-learning systems. The objective is not merely to deploy a model but to make model development and operation reproducible, observable, secure, and economically sustainable.

A practical MLOps lifecycle is:

1. Define the business objective and success criteria.
2. Acquire, document, and validate data.
3. Engineer features and create reproducible training sets.
4. Train and evaluate candidate models.
5. Register model artifacts, metadata, and evaluation results.
6. Validate the model against technical, business, fairness, and security requirements.
7. Deploy through an approved pipeline.
8. Monitor production behavior.
9. Retrain, roll back, replace, or retire the model when required.

Important practices include:

• Version control: Track code, configuration, prompts, schemas, data definitions, and infrastructure.
• Data and model lineage: Record which data, code, parameters, and environment produced an artifact.
• Automated testing: Test data schemas, transformations, features, APIs, security controls, and model behavior.
• Continuous integration and continuous delivery: Automatically build and validate changes before controlled release.
• Model registry: Store approved model versions and their status.
• Reproducibility: Make it possible to recreate a result or explain why exact reproduction is not possible.
• Approval gates: Require responsible review for high-impact systems.
• Rollback: Maintain a safe previous version and a tested procedure for returning to it.

Machine-learning pipelines differ from ordinary software pipelines because data changes can alter behavior even when code does not. A pipeline can therefore fail silently if an upstream column changes meaning, a population changes, labels become delayed, or a data source becomes incomplete.

Data and model drift

Data drift occurs when the distribution or structure of input data changes. Concept drift occurs when the relationship between inputs and the target changes. Performance drift occurs when outcomes such as accuracy, calibration, revenue, or error cost deteriorate.

A monitoring plan should define thresholds and actions. A warning may trigger investigation; a critical threshold may stop automated decisions, invoke human review, or initiate rollback. Retraining should not be automatic solely because a statistical measure changed: the organization should first determine whether the change is real, harmful, temporary, or caused by a data defect.

7. LLMOps and Generative-AI Operations

LLMOps extends MLOps to large language models and other generative systems. It must manage not only model versions but also prompts, system instructions, retrieval indexes, tools, safety filters, evaluation sets, and conversation context.

Key LLMOps practices include:

• prompt versioning and approval;
• evaluation using representative and adversarial test cases;
• tracking model, temperature, retrieval settings, and token usage;
• protection against prompt injection and unauthorized tool use;
• output validation and structured response schemas;
• detection of sensitive-information disclosure;
• grounding and citation checks for knowledge assistants;
• human review for high-impact or uncertain outputs;
• cost controls for long prompts and repeated calls.

Traditional accuracy may be insufficient for generative applications. Useful measures include groundedness, relevance, completeness, refusal quality, toxicity, privacy leakage, task success, user correction rate, and citation validity. Human evaluation remains important, but it should be supported by repeatable rubrics and sampled review rather than informal impressions alone.

A language model should be treated as an untrusted component when it can call tools or influence transactions. Tool permissions should be narrow, explicit, logged, and independently authorized. The model should not be allowed to decide its own access rights.

8. Monitoring and Observability

Observability allows an organization to understand what a system is doing from its outputs and internal signals. AI monitoring should cover four dimensions.

System monitoring

Measures include latency, throughput, error rate, availability, queue length, memory use, accelerator utilization, and cost per request. Percentiles are often more informative than averages. For example, the 95th percentile latency indicates a value below which 95% of observations fall; it reveals tail behavior that an average can conceal.

Data monitoring

Checks include schema validity, missingness, ranges, category changes, duplication, freshness, volume, and unusual distributions. Data-quality failures should be separated from legitimate population changes.

Model monitoring

Measures depend on the task. Classification may use precision, recall, F1 score, calibration, or business loss. Forecasting may use mean absolute error or another appropriate loss. Generative applications may use task success, groundedness, safety, and human review. Metrics must be interpreted with confidence, sample size, class imbalance, and decision costs in mind.

For binary classification:

Here, TP is true positives, FP is false positives, and FN is false negatives. Precision answers, “Among predicted positives, how many were positive?” Recall answers, “Among actual positives, how many were identified?” These measures apply to a defined classification threshold and labeled evaluation set; neither alone describes all business consequences.

Business monitoring

A model can have stable technical metrics while failing to create value. Monitor conversion, resolution time, fraud loss, customer retention, employee workload, appeal rates, and other outcome measures. Establish a comparison or baseline where feasible.

Monitoring data must be handled carefully because logs may contain personal, confidential, or commercially sensitive information. Redaction, minimization, retention limits, and restricted access are essential.

9. Scalability, Reliability, and Cost

Scalability concerns the ability to handle increasing workload while maintaining acceptable performance and cost. Vertical scaling adds resources to one machine; horizontal scaling adds instances. Horizontal scaling often improves resilience, but state management, synchronization, and data consistency become more complex.

Important design techniques include:

• caching repeated results;
• batching requests where latency permits;
• asynchronous queues for long-running tasks;
• autoscaling based on workload signals;
• model compression or distillation where quality remains acceptable;
• routing simple requests to less expensive models;
• separating interactive and batch workloads;
• regional redundancy for important services;
• graceful degradation when dependencies fail.

Reliability requires explicit service objectives. An SLO is a target such as a latency or availability objective; an SLA is a formal agreement that may include remedies; an SLI is the measured indicator used to assess performance. For example, a team may define an SLI for successful requests and set an SLO for a specified percentage over a stated period. The exact target should reflect business impact rather than an arbitrary technical aspiration.

AI systems also face dependency failures: a model provider may be unavailable, a vector index may be corrupted, credentials may expire, or a data pipeline may be delayed. Contingency designs may include a previous model, a rules-based fallback, a human queue, or a safe refusal.

10. Cybersecurity and Responsible Governance

AI security includes ordinary application security plus risks created by data, models, prompts, and autonomous behavior. Relevant threats include:

• unauthorized access to training or inference data;
• data poisoning;
• model theft or extraction;
• adversarial inputs;
• prompt injection;
• insecure tool use;
• sensitive-information disclosure;
• supply-chain vulnerabilities in packages and models;
• denial-of-service and excessive resource consumption;
• insufficient logging or non-repudiation.

Controls should include least-privilege identity, network segmentation, encryption in transit and at rest, secrets management, dependency scanning, code review, secure configuration, input validation, output filtering, rate limiting, backup, incident response, and periodic penetration testing.

Governance should assign accountability. A model owner may be responsible for business outcomes, a data owner for lawful and appropriate data use, a platform owner for operational reliability, and a security or risk function for independent oversight. High-impact uses may require impact assessments, explainability appropriate to the decision, human appeal, documentation, bias testing, and records of decisions.

Responsible AI principles—fairness, transparency, privacy, safety, accountability, and human oversight—must be translated into controls. A statement that a system should be “fair” is not sufficient unless the organization defines the relevant population, measures, trade-offs, and remediation process. Different fairness measures can conflict, particularly when base rates differ; therefore, selection of a measure is a governance decision connected to the application context.

11. Integrating AI with Legacy Systems

Legacy systems often contain essential records and business rules but expose limited interfaces. Replacing them may be expensive and risky. AI integration can occur through:

• APIs exposed by the legacy system;
• event streams or message queues;
• scheduled file exchange;
• read-only replicas or analytical extracts;
• robotic process automation where no interface exists;
• a strangler pattern, in which new services gradually replace selected functions.

A robust integration isolates the AI service from unstable legacy details through an adapter. The adapter translates schemas, handles authentication, validates responses, and prevents model-specific assumptions from spreading throughout the enterprise.

Legacy integration raises important issues: inconsistent identifiers, stale data, duplicate records, transaction rollback, batch timing, undocumented rules, and incompatible security models. AI should not silently override established controls. For example, an underwriting recommendation may be delivered to the existing workflow for authorized review rather than directly changing a core transaction.

12. Illustrative Case: Customer-Service Knowledge Assistant

Background

A regional telecommunications company receives a large volume of customer-service queries. Policies, device manuals, network procedures, and regulatory notices are distributed across a document repository. Agents spend substantial time searching for current information.

Problem

The company wants an assistant that proposes answers and cites authoritative documents. It must not reveal information across customer accounts, invent policy, or take irreversible actions without approval.

Analysis

A general language model alone is unsuitable because policies change and unsupported answers could create financial and regulatory risk. The proposed architecture uses a managed language model, a controlled document pipeline, a vector database, an API gateway, and an agent-facing application. Customer-specific information remains in the authorized customer system and is not copied broadly into the knowledge index.

Approach and solution

Documents are classified by owner, effective date, region, and access level. Approved documents are chunked, embedded, and indexed. At query time, the assistant applies the agent’s authorization context before retrieval. Retrieved passages are supplied to the model with instructions to cite sources and state when evidence is insufficient.

The application validates the response format, displays citations, records the model and prompt versions, and requires agent confirmation before any account change. A rules-based fallback presents search results if the model service is unavailable. A pilot uses shadow evaluation and human review before wider release.

Monitoring covers latency, retrieval success, citation validity, unsupported-answer rate, sensitive-data leakage, agent correction rate, and customer-resolution time. The company establishes rollback procedures for the prompt, index, and model independently.

Outcome

In this illustrative case, the expected benefit is reduced search time and more consistent responses, not complete replacement of agents. The design preserves human accountability and allows the organization to update knowledge by publishing approved documents rather than retraining the language model after every policy change.

Learning points

1. Retrieval quality and access control are as important as model selection.
2. Human approval is appropriate where errors have customer or regulatory consequences.
3. Versioning must include prompts, indexes, documents, and model providers.
4. A fallback path is part of production architecture, not an optional enhancement.
5. Business outcomes should be measured alongside technical metrics.

13. Best-Practice Design Checklist

Before production release, an organization should be able to answer “yes” to most of the following questions:

• Is the business purpose and decision authority clearly defined?
• Are data ownership, lawful use, retention, and access documented?
• Can the model, data, prompt, index, and code versions be identified?
• Are API contracts, limits, authentication, and error behavior specified?
• Has the system been tested under normal, peak, and dependency-failure conditions?
• Are quality, fairness, security, and business metrics monitored?
• Is there a human-review or safe-fallback path?
• Can the system be rolled back or disabled quickly?
• Have vendor portability, pricing changes, and exit risks been assessed?
• Are users trained to interpret and challenge AI outputs?

Chapter Summary

AI architecture connects models to data, applications, users, infrastructure, and governance. Cloud services provide elasticity and managed capabilities, but require attention to cost, portability, security, and provider dependence. APIs and model-serving systems turn models into usable services, while data platforms and feature stores support reliable and reproducible inputs. Vector databases and retrieval-augmented generation can ground language-model responses in controlled organizational knowledge, provided retrieval respects authorization.

Build-versus-buy decisions should consider strategic differentiation, speed, expertise, total cost, control, vendor risk, and exit options. MLOps establishes disciplined lifecycle management through versioning, testing, registries, deployment controls, monitoring, and rollback. LLMOps extends these practices to prompts, retrieval indexes, tools, safety, and generative evaluation.

Production systems require monitoring of infrastructure, data, models, and business outcomes. Scalability depends on capacity, latency, queues, caching, batching, and graceful degradation. Cybersecurity requires least privilege, encryption, secure dependencies, prompt and tool controls, and incident response. Finally, legacy integration should use controlled interfaces and adapters while preserving business rules and human accountability. The central principle is that trustworthy AI is an engineered operational system, not merely a trained model.

Key Terms

Cloud AI: AI capability delivered through cloud infrastructure or managed services.

API: A software contract that enables systems to communicate.

Model serving: Infrastructure and software used to provide model predictions in production.

Inference: The process of using a trained model to produce an output.

Data warehouse: A structured analytical data store optimized for reporting and queries.

Data lake: A storage environment for large volumes of varied data, often in raw form.

Lakehouse: A platform combining flexible lake storage with warehouse-style management.

Feature store: A system for managing machine-learning features consistently across training and inference.

Embedding: A numerical representation of an item in a vector space.

Vector database: A database optimized for similarity search over embeddings.

Retrieval-augmented generation: A method that retrieves external information before generating an answer.

MLOps: Practices for developing, deploying, monitoring, and governing machine-learning systems.

LLMOps: Operational practices for large language models and generative-AI applications.

Data drift: Change in the distribution or structure of input data.

Concept drift: Change in the relationship between inputs and the target outcome.

Canary deployment: A release strategy that sends limited traffic to a new version first.

Observability: The ability to understand system behavior through measured outputs and internal signals.

Service-level objective: A defined target for a service indicator such as availability or latency.

Prompt injection: An attempt to manipulate a language model through malicious or unauthorized instructions.

Legacy integration: Connecting new systems to older applications, databases, or workflows.

Review Questions

Short Answer Questions

1. What are the main layers of an enterprise AI architecture?
2. How does a vector database differ from a conventional relational database?
3. What is the purpose of a model registry in MLOps?
4. Distinguish data drift from concept drift.
5. Why is a fallback mechanism important in AI production systems?

Long Answer Questions

1. Explain how cloud AI can accelerate deployment while increasing concerns about vendor dependence and data governance.
2. Compare real-time, batch, streaming, and asynchronous model-serving patterns and give an appropriate business use for each.
3. Discuss the criteria an organization should use when deciding whether to build, buy, or combine AI capabilities.
4. Explain how MLOps and LLMOps differ from ordinary software delivery practices.
5. Describe a comprehensive monitoring and governance framework for a high-impact AI application.

Analytical / Application Questions

1. A retailer receives 12 prediction requests per second during peak periods, and each request takes an average of 0.5 seconds. Use the capacity approximation in this chapter to estimate concurrent request-equivalents, then explain why the estimate is insufficient for final infrastructure sizing.
2. Design a RAG-based internal policy assistant for a bank. Specify the data controls, retrieval permissions, model-serving approach, monitoring measures, human-review points, and fallback behavior.
3. An AI fraud model’s precision remains stable, but fraud losses increase after a major change in payment behavior. Analyze possible causes, identify the evidence you would collect, and recommend whether to retrain, roll back, or investigate further.

Multiple Choice Questions with Answers

Question 1

Which component primarily manages similarity search over embeddings?

A. Vector database

B. API gateway

C. Message queue

D. Data warehouse

Correct Answer: A. Vector database

Question 2

Which deployment strategy sends a small percentage of production traffic to a new model first?

A. Blue-green deployment

B. Canary deployment

C. Batch scoring

D. Embedded inference

Correct Answer: B. Canary deployment

Question 3

In the formula Precision = TP / (TP + FP), what does FP represent?

A. False positives

B. False negatives

C. Feature predictions

D. Forecast parameters

Correct Answer: A. False positives

Question 4

What is the principal purpose of retrieval-augmented generation?

A. To eliminate the need for data governance

B. To ground generated responses in retrieved information

C. To replace all application programming interfaces

D. To guarantee that every generated answer is correct

Correct Answer: B. To ground generated responses in retrieved information

Question 5

Which practice is most directly associated with reproducible MLOps?

A. Changing models manually in production

B. Tracking code, data, configuration, and model versions

C. Removing evaluation data after training

D. Allowing each user to select a different unrecorded prompt

Correct Answer: B. Tracking code, data, configuration, and model versions

Question 6

Which statement best distinguishes concept drift from data drift?

A. Concept drift concerns changes in the input-target relationship

B. Concept drift concerns only server memory usage

C. Data drift always means that model accuracy has improved

D. Data drift occurs only in language models

Correct Answer: A. Concept drift concerns changes in the input-target relationship

Question 7

Why should authorization be applied during vector retrieval?

A. To increase embedding dimensionality

B. To prevent users from retrieving documents they are not allowed to see

C. To make all documents publicly searchable

D. To remove the need for document metadata

Correct Answer: B. To prevent users from retrieving documents they are not allowed to see

Question 8

Which is a characteristic of horizontal scaling?

A. Adding more service instances

B. Increasing the memory of one machine only

C. Deleting redundant services

D. Replacing monitoring with manual inspection

Correct Answer: A. Adding more service instances

Question 9

Which is an appropriate LLMOps control when a language model can call business tools?

A. Allowing the model to grant itself permissions

B. Using narrow, explicit, logged tool permissions

C. Removing authentication from tool calls

D. Disabling all audit records

Correct Answer: B. Using narrow, explicit, logged tool permissions

Question 10

If peak traffic is 20 requests per second and average service time is 0.25 seconds, what is the approximate concurrent request-equivalent capacity using the chapter’s approximation?

A. 0.05

B. 5

C. 20.25

D. 80

Correct Answer: B. 5