Managerial Data Strategy and Digital Transformation

Introduction

Data has become a strategic organizational resource rather than merely an operational by-product. Organizations use data to understand customers, coordinate supply chains, detect fraud, optimize prices, evaluate performance, and develop new products. Yet possessing large volumes of data does not automatically create business value. Value depends on whether data is trustworthy, accessible, governed, economically managed, and connected to important decisions.

Managerial data strategy is the disciplined process of deciding how an organization will acquire, store, integrate, protect, analyze, and use data in support of its strategy. Digital transformation extends this concern beyond information systems. It involves redesigning products, processes, organizational structures, and relationships with customers and partners through digital technologies and data-driven operating models.

A data platform is the technological and organizational foundation through which data is collected, processed, stored, governed, and delivered to users or applications. Evaluating a data platform therefore requires more than comparing software features. Managers must assess architecture, economics, resilience, service levels, supplier dependence, governance, workforce capability, and the platform’s contribution to business decisions.

Learning Objectives

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

1. Explain the relationship between data strategy, digital transformation, and business strategy.
2. Evaluate major data-platform architectures and their trade-offs.
3. Analyze build-versus-buy decisions using strategic, economic, and operational criteria.
4. Apply basic cloud-cost, service-level, availability, and resilience concepts.
5. Assess vendor risk, governance requirements, and operating-model choices.
6. Design principles for self-service analytics without sacrificing control or trust.
7. Align data investments with measurable business decisions and outcomes.

1. From Data Management to Data Strategy

Traditional data management emphasized databases, data quality, backup, security, and reporting. These remain essential, but a strategic perspective asks additional questions:

• Which business decisions should data improve?
• Which data assets create competitive or public value?
• Who is accountable for data quality and appropriate use?
• What level of speed, reliability, and cost is justified?
• Which capabilities should be internal, purchased, or shared with partners?

A useful hierarchy is:

Data → information → insight → decision → outcome.

Data consists of recorded observations, such as transactions or sensor readings. Information is data organized in a meaningful context. Insight is an interpretation that reduces uncertainty or reveals an opportunity. A decision is a chosen course of action. An outcome is the measurable consequence, such as reduced inventory cost or improved customer retention.

This chain is not automatic. A technically sophisticated platform may generate dashboards that do not influence decisions. Conversely, a modest database can create considerable value when it supports a critical operational decision reliably.

Strategic alignment

A data strategy should be derived from organizational priorities. If the organization’s priority is operational efficiency, the platform may emphasize real-time monitoring, process integration, and reliable master data. If the priority is innovation, it may emphasize experimentation, machine-learning capability, and access to diverse data. If the priority is regulatory compliance, lineage, retention, access control, and auditability become dominant requirements.

A practical alignment test asks:

1. What decision is being improved?
2. Who makes the decision?
3. What information is required?
4. How frequently is it required?
5. What is the cost of being late or wrong?
6. How will improvement be measured?

2. Data-Platform Architecture

A modern platform commonly includes the following logical layers:

These layers are logical rather than necessarily separate products. One managed cloud service may provide several capabilities, while a large organization may use multiple products for one layer.

Common architectural patterns

Enterprise data warehouse. A warehouse stores structured, integrated data designed for reporting and analysis. It usually provides strong schema management, SQL performance, security, and consistent definitions. Its limitations may include expensive ingestion of highly varied data and less flexibility for exploratory work.

Data lake. A lake stores data in relatively raw form, often using scalable object storage. It can accommodate structured, semi-structured, and unstructured data. Its flexibility can become a weakness when metadata, quality, ownership, and lifecycle controls are inadequate. An unmanaged lake may become a “data swamp.”

Lakehouse. A lakehouse seeks to combine the low-cost and flexible storage of a lake with the governance, reliability, and analytical performance associated with a warehouse. The label describes an architectural objective, not a universal technical standard. Evaluation should focus on actual transaction management, metadata, workload support, security, and operating cost.

Data mesh. Data mesh is primarily an organizational and architectural approach. It proposes domain ownership of data products, data as a product, self-service platform capability, and federated computational governance. It is not simply a tool or storage technology. It may improve local accountability but can increase coordination complexity and produce inconsistent standards if governance is weak.

Workload fit

Architecture should be evaluated against workload characteristics:

• OLTP workloads: frequent, small, concurrent transactions requiring consistency and low latency.
• OLAP workloads: large scans, aggregation, historical analysis, and complex queries.
• Streaming workloads: continuous events requiring rapid processing and often time-sensitive action.
• Machine-learning workloads: repeated feature preparation, experimentation, model training, deployment, and monitoring.
• Master-data workloads: controlled management of shared entities such as customers, products, suppliers, or locations.

No single platform is automatically optimal for all workloads. A sound design may use multiple specialized services, but every additional component increases integration, skill, security, and operating burdens.

3. Evaluating Platforms: A Decision Framework

A platform evaluation should combine functional, technical, economic, and organizational criteria. A weighted scorecard can make assumptions visible. If criterion i has weight wᵢ and a vendor receives score sᵢ, a simple weighted score is:

where weights are non-negative and normally sum to 1, and scores use a defined scale such as 1 to 5. The score is useful for comparison, but it is not an objective truth. A platform that fails a mandatory security requirement should be rejected even if its total score is high.

Relevant criteria include:

A proof of concept should use representative data, queries, security controls, failure scenarios, and user tasks. Vendor demonstrations often show ideal conditions and should not substitute for controlled testing.

4. Build, Buy, or Partner?

The build-versus-buy decision concerns more than initial purchase price. Organizations may build a capability internally, purchase a packaged product, consume a managed cloud service, or partner with a specialist. The decision should consider strategic differentiation, required control, speed, lifecycle cost, and capability.

Build is attractive when:

• the capability is central to competitive advantage;
• requirements are unusual or rapidly changing;
• proprietary processes or data create differentiation;
• the organization has durable engineering and operating capability;
• integration with internal systems is unusually important.

Buy or consume is attractive when:

• the capability is common across industries;
• speed and predictable functionality matter;
• the supplier can achieve economies of scale;
• internal skills are scarce;
• the organization prefers to focus on its core business.

Hidden costs

Internal development can incur architecture, testing, security, documentation, support, recruitment, platform upgrades, and opportunity costs. Purchased services can incur licensing, implementation, integration, data transfer, training, customization, contract management, and switching costs.

A simplified total cost of ownership over a planning horizon is:

C₀ is initial implementation cost; Cₜ is recurring platform or licence cost in period t; Lₜ is labour and support cost; Oₜ is other operating cost such as network, storage, and monitoring; Rₜ is expected risk-related cost; V_T is residual value or avoided cost at the end of the horizon T. Costs must be measured in a common currency and time basis. This simplified expression does not automatically account for discounting, inflation, tax, or uncertain future usage.

For investment appraisal, discounted cash flow may be more appropriate:

I₀ is the initial investment, CFₜ is net cash flow in period t, r is the discount rate per period, and T is the number of periods. The method assumes cash flows and the discount rate are estimated consistently. Benefits that are difficult to monetize should be reported separately rather than silently omitted.

5. Cloud Economics and FinOps

Cloud computing changes the cost structure of data platforms. Instead of purchasing all capacity in advance, an organization can pay for consumption, reserve capacity, or use a mixture of models. Cloud does not necessarily mean lower cost. It can lower the cost of experimentation and reduce infrastructure-management work, while increasing costs through uncontrolled consumption, duplicated data, data transfer, premium services, or inefficient queries.

Important cost categories include:

• compute time and provisioned capacity;
• storage, backup, and archival retention;
• data ingestion and data transfer;
• managed-service and licence charges;
• observability, security, and governance tooling;
• personnel and supplier-management costs.

A useful unit-cost metric is:

The business unit must be defined carefully, such as cost per active customer, cost per completed report, or cost per thousand transactions. The metric is meaningful only when numerator and denominator cover the same period and scope.

FinOps is a management discipline that connects engineering, finance, and business teams. Practices include budgets, tagging, allocation, anomaly detection, rightsizing, workload scheduling, storage lifecycle policies, and review of unit economics. Cost optimization must not undermine availability, security, data quality, or legally required retention.

Worked example: comparing alternatives

Suppose a three-year planning estimate for an internal platform includes an initial cost of $180,000, annual operating cost of $120,000, and annual support labour of $90,000. A managed service requires $60,000 implementation cost, $210,000 annual service cost, and $45,000 annual internal support cost. Ignoring discounting and residual value:

Internal platform:

$180,000 + 3($120,000 + $90,000) = $810,000.

Managed service:

$60,000 + 3($210,000 + $45,000) = $825,000.

The internal option is $15,000 cheaper under these assumptions. However, the managed service may provide faster deployment, better resilience, or lower recruitment risk. The calculation informs the decision; it does not decide it. Sensitivity analysis should test usage growth, labour rates, migration cost, and service-price changes.

6. Service Levels, Reliability, and Resilience

A service-level agreement (SLA) is a contractual commitment, while a service-level objective (SLO) is a target used for operational management. A service-level indicator (SLI) is the measured quantity, such as successful query percentage or latency at the 95th percentile. These terms should not be treated as interchangeable.

Availability over a period can be expressed as:

Both time quantities must use the same unit and definition of downtime. Planned maintenance, exclusions, and measurement methods must be specified in the contract.

For example, in a 30-day month of 720 hours, 99.9% availability permits approximately:

720 × (1 − 0.999) = 0.72 hours, or 43.2 minutes, of unavailability.

High availability does not guarantee acceptable performance, data correctness, or successful recovery. A platform may be available but return stale or incorrect information.

Recovery time objective (RTO) is the maximum tolerable time to restore service after a disruption. Recovery point objective (RPO) is the maximum tolerable period of data loss measured backward from the disruption. A zero-minute RPO may require synchronous replication and may be costly or technically unsuitable.

Resilience includes prevention, absorption, recovery, and adaptation. Controls may include redundancy, backups, replication, graceful degradation, circuit breakers, tested restoration, incident procedures, and alternative processing arrangements. Backups are not a resilience strategy unless restoration is regularly tested.

7. Vendor Risk and Exit Strategy

Outsourcing does not outsource accountability. Management remains responsible for understanding how data is protected, processed, retained, and recovered.

Vendor due diligence should examine:

• financial stability and ownership;
• security certifications and independent assurance;
• subcontractors and supply-chain dependencies;
• geographic processing and legal jurisdiction;
• incident history and notification practices;
• data portability and deletion procedures;
• product roadmap and support quality;
• concentration and market power;
• contractual liability, audit rights, and termination assistance.

Vendor lock-in is not always bad. A deeply integrated service may produce substantial value. The issue is whether dependence is deliberate, proportionate, and manageable. Exit planning may include open formats, documented interfaces, tested exports, portable identity and metadata, contractual deletion evidence, and a realistic migration budget.

A multi-cloud strategy is not automatically safer. Using several providers can reduce concentration in some circumstances but may increase complexity, skills requirements, data-transfer cost, and security exposure. The right question is not “single cloud or multi-cloud?” but “which risks are reduced, and what new risks are introduced?”

8. Operating Models and Accountability

Technology alone does not create a responsible data capability. Operating models define decision rights, responsibilities, funding, standards, and ways of working.

A centralized model concentrates architecture, engineering, governance, and analytics in a central function. It can produce consistency and economies of scale but may respond slowly to domain needs. A decentralized model places capability in business units, increasing local responsiveness but potentially duplicating systems and definitions. A federated model combines domain accountability with shared standards and platforms.

Common roles include:

• Executive sponsor: connects data investment to strategic priorities.
• Data owner: accountable for a domain’s meaning, access, quality, and use.
• Data steward: manages definitions, metadata, quality issues, and controls.
• Platform engineering team: builds and operates shared technical services.
• Security and privacy professionals: establish protective and compliance controls.
• Analytics translator or product manager: connects business problems to data products.
• Data consumer: uses information according to approved purposes and controls.

A RACI matrix can clarify who is Responsible, Accountable, Consulted, and Informed. Accountability should be assigned to roles, not merely to a committee or abstract “data team.”

9. Self-Service Analytics: Empowerment with Guardrails

Self-service analytics allows business users to explore data, create reports, and answer questions without submitting every request to a central IT team. It can improve speed, learning, and decision ownership. However, uncontrolled self-service can create conflicting definitions, privacy violations, duplicated extracts, insecure spreadsheets, and misleading dashboards.

Effective self-service commonly requires:

1. certified datasets and reusable semantic models;
2. a business glossary defining key measures;
3. role-based access and row- or column-level controls;
4. catalogues showing ownership, lineage, freshness, and quality;
5. training in SQL, visualization, interpretation, and responsible use;
6. promotion processes for important reports;
7. monitoring of usage, quality incidents, and sensitive-data access.

A metric such as “customer churn” should have a documented population, time window, exclusion rules, and calculation method. Different departments may legitimately use different measures, but the distinction must be explicit.

Self-service is therefore best understood as managed autonomy. Governance should make safe and correct behavior easier, not merely prohibit user activity.

10. Governance, Ethics, Privacy, and AI

Data governance establishes authority and controls over data throughout its lifecycle. Important governance areas include ownership, classification, quality, metadata, lineage, retention, access, privacy, and ethical use.

Data quality is multidimensional. Typical dimensions include accuracy, completeness, consistency, timeliness, validity, and uniqueness. Quality should be assessed against business use. A minor formatting error may be irrelevant in exploratory analysis but unacceptable in regulatory reporting or payment processing.

Privacy principles commonly require purpose limitation, data minimization, transparency, lawful processing, appropriate security, retention control, and rights management. Exact legal obligations vary by jurisdiction and sector, so organizations must obtain appropriate legal advice. Sensitive data should not be copied into development or analytics environments without an approved purpose and suitable controls.

Ethical risks include discriminatory outcomes, invasive profiling, unfair exclusion, manipulation, and inability to explain important decisions. AI systems intensify these concerns because they may process large datasets, infer sensitive attributes, and make recommendations at scale. AI governance should address data provenance, model documentation, validation, bias testing, human oversight, monitoring, and appeal mechanisms.

11. Aligning Platforms with Business Decisions

The strongest data strategies begin with decisions rather than technologies. A decision inventory can classify decisions by frequency, value, reversibility, risk, and required speed.

A benefits map can connect platform outputs to outcomes:

Capability → decision improvement → behavior change → business result.

For example, near-real-time inventory visibility may improve replenishment decisions, reduce emergency purchasing, and lower stockout costs. The platform should be evaluated through the entire chain rather than by counting dashboards or terabytes stored.

Useful measures may include decision cycle time, forecast error, stockout rate, fraud loss, customer retention, report adoption, data-quality incidents, platform availability, and cost per transaction. Metrics should have owners and baselines. A rise in dashboard usage is not necessarily a benefit if decisions and outcomes do not improve.

12. Illustrative Case: Northstar Retail Group

Background

Northstar Retail Group operates 140 stores and an online channel. Its sales, inventory, customer, and supplier data reside in separate systems. Regional managers receive weekly reports, while the online team uses a cloud analytics service. Product and customer definitions differ between departments.

Problem

Northstar experiences stockouts for popular products while holding excess inventory elsewhere. Managers cannot reliably compare online and store sales. A proposed platform would consolidate data, but executives disagree about whether to build a custom lakehouse or buy a managed analytical platform.

Analysis

The executive team begins with decisions rather than products. The priority decisions are replenishment, promotion evaluation, and customer-service monitoring. Replenishment requires daily integrated data, while selected online events require near-real-time visibility. Regulatory and privacy requirements apply to customer information.

A cross-functional team identifies mandatory requirements: documented product and location master data, role-based access, recovery testing, data lineage for financial measures, and a three-year cost forecast. It also identifies non-functional requirements: 99.9% monthly availability for the management reporting service, an RTO of four hours, and an RPO of one hour.

The team compares three options: extending the existing warehouse, building a new platform, and purchasing a managed service. The build option offers flexibility but requires scarce engineering skills. The managed option offers faster implementation and integrated security controls but creates supplier dependence and variable usage cost.

Approach and solution

Northstar selects a managed analytical platform with open export formats and contractual exit assistance. It retains ownership of business definitions and implements a federated operating model. A central platform team provides ingestion, security, monitoring, and common semantic models. Domain stewards from merchandising, supply chain, finance, and customer operations own definitions and quality rules.

The first data product is a certified inventory model. It includes product, store, warehouse, stock-on-hand, inbound quantity, and timestamp definitions. A data-quality dashboard reports missing product identifiers, stale feeds, and duplicate records. Customer data is separated from general inventory analysis and access is restricted according to purpose.

Outcome

After implementation, replenishment reports move from weekly to daily, and selected event feeds become near-real-time. Managers use a common stock definition. Northstar reports fewer emergency transfers and improved visibility into promotional performance. The organization does not claim that every improvement is caused by the platform; it establishes baseline measures and reviews results with business owners.

Learning points

1. The platform decision followed business decisions and service requirements.
2. Managed services can be strategically appropriate without eliminating vendor risk.
3. Data ownership and semantic consistency are operating-model issues, not only technical issues.
4. Exit planning should be designed before dependence becomes unavoidable.
5. Benefits must be measured through business outcomes rather than infrastructure volume.

13. Implementation Roadmap and Best Practices

A practical transformation can proceed through the following stages:

1. Diagnose: inventory decisions, data assets, risks, costs, pain points, and current capabilities.
2. Prioritize: select high-value use cases with feasible data and accountable owners.
3. Design principles: define architecture, security, governance, service levels, and economic guardrails.
4. Pilot: test one or two representative data products using realistic workloads.
5. Industrialize: automate deployment, testing, monitoring, lineage, access approval, and recovery.
6. Scale selectively: expand only when adoption, quality, economics, and outcomes justify it.
7. Review continuously: reassess vendors, costs, risks, technology, legal requirements, and strategic fit.

Best practices include keeping critical definitions explicit, measuring unit economics, testing restoration, separating development and production data, documenting assumptions, using least-privilege access, and treating data products as maintained services rather than one-time projects.

Challenges and Limitations

Data strategy is difficult because benefits are distributed while costs are often concentrated in technology budgets. Data quality problems may originate in operational processes outside the platform team’s authority. Architecture standards can become bureaucratic and slow experimentation. Self-service can produce uncontrolled variation, while excessive centralization can suppress innovation.

Economic estimates are uncertain because usage, supplier pricing, labour availability, and regulatory requirements change. Weighted scorecards may create false precision. Availability targets can distract from correctness and recovery. New technologies may solve technical bottlenecks while introducing skills shortages or governance gaps.

Successful transformation therefore requires judgment. Managers should make assumptions visible, test them, use pilots, involve users, and revise decisions when evidence changes.

Chapter Summary

Managerial data strategy connects data capabilities to organizational decisions and outcomes. A data platform should be evaluated across architecture, workload fit, security, governance, resilience, service levels, economics, skills, interoperability, and vendor risk. Warehouses, lakes, lakehouses, and data mesh approaches address different combinations of technical and organizational needs.

Build-versus-buy decisions should consider strategic differentiation, total cost of ownership, speed, control, skills, integration, and exit risk. Cloud economics requires attention to consumption, unit cost, data movement, governance, and FinOps. Service levels should distinguish indicators, objectives, and contractual commitments, while resilience requires tested recovery, not merely high availability.

Operating models assign accountability among executives, owners, stewards, engineers, security specialists, and users. Self-service analytics creates value when supported by certified data, semantic definitions, access controls, catalogues, training, and managed autonomy. Governance must address quality, privacy, ethics, lineage, retention, and responsible AI use.

Finally, the strongest platform strategies begin with important business decisions. Technology investment should be assessed by whether it improves decisions, changes behavior, and produces measurable outcomes.

Key Terms

Data strategy: A coordinated plan for using data capabilities to support organizational objectives.

Digital transformation: Redesign of products, processes, structures, and relationships through digital technologies.

Data platform: Technological and organizational foundation for collecting, storing, processing, governing, and delivering data.

Data warehouse: Structured analytical repository designed for integrated reporting and analysis.

Data lake: Scalable repository that stores data in relatively raw and varied forms.

Lakehouse: An architectural approach combining flexible lake storage with warehouse-like management and analytical capabilities.

Data mesh: A domain-oriented approach emphasizing data products, domain ownership, self-service infrastructure, and federated governance.

Total cost of ownership: The complete cost of acquiring, operating, supporting, and retiring a capability.

FinOps: Collaborative financial-management practice for governing and optimizing cloud consumption.

Service-level indicator: A measured attribute of service performance.

Service-level objective: A target level of service performance.

Service-level agreement: A contractual commitment concerning service performance and responsibilities.

RTO: Maximum acceptable time to restore service after disruption.

RPO: Maximum acceptable period of data loss measured backward from disruption.

Resilience: Ability to withstand, recover from, and adapt to disruption.

Vendor lock-in: Difficulty or cost of moving away from a supplier or technology.

Data steward: Person responsible for managing data definitions, metadata, quality, and controls.

Self-service analytics: User-led analysis supported by governed data and tools.

Data lineage: Record of data origins, transformations, and destinations.

Unit economics: Analysis of cost and value per defined business unit.

Review Questions

Short Answer Questions

1. Why should data-platform evaluation begin with business decisions rather than technology features?
2. Distinguish a data lake from a data warehouse.
3. What is the difference between an SLA, SLO, and SLI?
4. Define RTO and RPO.
5. Why does self-service analytics require governance?

Long Answer Questions

1. Compare warehouse, lake, lakehouse, and data mesh approaches, including their technical and organizational trade-offs.
2. Explain the major factors that should influence a build-versus-buy decision for a data platform.
3. Discuss how cloud economics can reduce some costs while creating new financial risks.
4. Explain how a federated operating model can balance local responsiveness and enterprise consistency.
5. Discuss the governance, privacy, ethical, and accountability issues associated with data platforms and AI-enabled analytics.

Analytical / Application Questions

1. An organization estimates that a 30-day month contains 720 agreed service hours. Calculate the maximum downtime permitted by a 99.95% availability objective and explain whether this alone proves that the platform is reliable.
2. Design a weighted platform-evaluation scorecard for a hospital, government agency, or retailer. Justify the criteria, weights, mandatory requirements, and evidence you would request from suppliers.
3. Using the Northstar Retail Group case, propose two additional measures that could demonstrate business value and explain how you would establish a credible baseline for each.

Multiple Choice Questions with Answers

Question 1

Which sequence best represents the data-to-value chain described in the chapter?

A. Data → insight → information → outcome → decision

B. Data → information → insight → decision → outcome

C. Information → data → decision → insight → outcome

D. Decision → data → information → outcome → insight

Correct Answer: B. Data → information → insight → decision → outcome

Question 2

Which architecture is primarily an organizational and architectural approach based on domain ownership and data products?

A. Data warehouse

B. Data lake

C. Data mesh

D. Object storage

Correct Answer: C. Data mesh

Question 3

If initial implementation costs $60,000, annual service costs are $210,000, and annual internal support costs are $45,000, what is the three-year undiscounted total cost?

A. $675,000

B. $735,000

C. $810,000

D. $825,000

Correct Answer: D. $825,000

Question 4

A 30-day month has 720 agreed service hours. Approximately how much downtime is permitted by 99.9% availability?

A. 4.32 minutes

B. 43.2 minutes

C. 72 minutes

D. 7.2 hours

Correct Answer: B. 43.2 minutes

Question 5

What does the recovery point objective measure?

A. The maximum time required to restore service

B. The percentage of queries that must succeed

C. The maximum tolerable period of data loss

D. The maximum number of users supported

Correct Answer: C. The maximum tolerable period of data loss

Question 6

Which practice most directly supports controlled self-service analytics?

A. Allowing every user to create independent metric definitions

B. Removing access controls to accelerate exploration

C. Providing certified datasets and a documented business glossary

D. Prohibiting business users from accessing analytical tools

Correct Answer: C. Providing certified datasets and a documented business glossary

Question 7

Which statement about vendor risk is most accurate?

A. Using a cloud provider eliminates accountability for data protection

B. Multi-cloud always reduces total technology risk

C. Vendor dependence should be deliberate, proportionate, and supported by an exit strategy

D. Open export formats guarantee that migration will be costless

Correct Answer: C. Vendor dependence should be deliberate, proportionate, and supported by an exit strategy

Question 8

In the formula NPV = −I₀ + ∑ CF_t ÷ (1 + r)^t, what does r represent?

A. The recovery point objective

B. The discount rate per period

C. The number of reporting users

D. The residual value of the platform

Correct Answer: B. The discount rate per period

Question 9

Which role is primarily accountable for a data domain’s meaning, access, quality, and appropriate use?

A. Data owner

B. Network administrator

C. External auditor

D. Dashboard consumer

Correct Answer: A. Data owner

Question 10

Why is a platform’s high availability insufficient by itself as a measure of data-service quality?

A. Availability measures only storage capacity

B. A service can be available while producing stale or incorrect data

C. Availability is relevant only to batch systems

D. Availability automatically includes privacy compliance

Correct Answer: B. A service can be available while producing stale or incorrect data