Enterprise Data Architecture and Digital Transformation Strategy

Introduction and Context

Enterprise data architecture is the disciplined design of the data assets, platforms, integration mechanisms, governance arrangements, security controls, and operating practices through which an organization creates business value from data. It is broader than database design. A database schema describes how a particular application stores information; an enterprise data architecture explains how information is defined, shared, protected, moved, governed, and used across the organization.

Digital transformation makes this distinction strategically important. Organizations increasingly depend on real-time transactions, analytical intelligence, artificial intelligence, digital channels, ecosystems, and automated decision-making. These capabilities require data that is accessible, trustworthy, interoperable, secure, and appropriately governed. However, transformation is rarely achieved by simply replacing a legacy database with a cloud service. It requires alignment among business strategy, operating models, information management, technology platforms, risk appetite, and organizational capabilities.

A sound architecture therefore answers five questions:

1. What information is strategically important?

2. Where should data be stored and processed?

3. How should systems exchange and govern data?

4. Which capabilities should be built, bought, or consumed as services?

5. How can modernization create value while controlling operational, regulatory, and security risk?

This chapter develops frameworks for answering these questions and for converting an architectural target state into a feasible modernization roadmap.

Learning Objectives

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

• distinguish enterprise data architecture from application-level database design;
• evaluate centralized, lake, warehouse, lakehouse, mesh, fabric, and hybrid patterns;
• select relational, document, key-value, graph, time-series, or analytical technologies using workload characteristics;
• analyze build-versus-buy, migration, integration, and total-cost decisions;
• construct a phased modernization roadmap with governance, risk, and value measures;
• assess stakeholder, ethical, regulatory, and organizational implications of transformation; and
• critically evaluate how cloud, event-driven platforms, and AI influence enterprise data strategy.

1. Foundations of Enterprise Data Architecture

1.1 Architectural layers

Enterprise data architecture can be viewed as a set of connected layers:

• Business and information layer: business capabilities, processes, information domains, ownership, and information value.
• Data layer: conceptual, logical, and physical models; master data; metadata; quality rules; retention; lineage; and data products.
• Application and integration layer: operational systems, APIs, events, extract-transform-load (ETL) and extract-load-transform (ELT) pipelines, message brokers, and integration services.
• Platform layer: databases, warehouses, data lakes, lakehouses, object storage, streaming infrastructure, and compute services.
• Security and governance layer: identity, access control, encryption, privacy, audit, stewardship, policy enforcement, and resilience.

These layers should not be treated as isolated technical components. For example, a decision to expose customer data through an API affects the information model, consent policy, service-level objective, security design, integration cost, and ownership model.

1.2 Data as an organizational asset

Data has economic value when it improves decisions, enables services, reduces cost, controls risk, or supports compliance. Unlike physical inventory, data can often be reused without being consumed. Nevertheless, reuse is not costless: storage, processing, quality management, security, interpretation, and compliance create ongoing obligations.

The value of data is also contextual. A customer identifier that is reliable in a billing system may be incomplete for marketing. A dataset may be accurate but unsuitable for a decision because it is too old, insufficiently granular, or collected under constraints that prohibit its intended use. Consequently, data quality should be specified relative to purpose. Common dimensions include accuracy, completeness, consistency, timeliness, validity, uniqueness, and fitness for use.

1.3 Architecture principles

Useful enterprise principles include:

• Business ownership: business domains own definitions and usage accountability, while technology teams provide enabling platforms.
• Single definition, multiple uses: critical concepts such as customer, product, and account should have governed definitions, even when physically replicated.
• Fit-for-purpose persistence: a workload should determine its storage technology rather than fashion or vendor preference.
• Security and privacy by design: controls are designed into information flows rather than added after implementation.
• Automation and observability: pipelines should be testable, monitored, traceable, and recoverable.
• Reversibility where practical: architectures should avoid unnecessary dependency on proprietary features when switching costs would be strategically harmful.
• Evolution rather than perfection: a usable target state and incremental migration are generally preferable to an indefinitely delayed ideal architecture.

2. Enterprise Architecture Patterns

2.1 Centralized warehouse architecture

A data warehouse integrates structured, curated data for reporting and analytical workloads. It commonly uses dimensional models containing facts and dimensions. The architecture provides strong governance, consistent metrics, and predictable performance. Its limitations include ingestion bottlenecks, difficulty accommodating rapidly changing or unstructured data, and the possibility that a central team becomes a delivery constraint.

2.2 Data lake architecture

A data lake stores large volumes of raw or lightly transformed data, often in object storage. It supports exploratory analytics, machine learning, and diverse formats. A lake is not automatically a high-quality architecture. Without cataloguing, ownership, quality controls, access policies, and lifecycle management, it can become a “data swamp”: inexpensive storage containing poorly understood and untrustworthy assets.

2.3 Lakehouse architecture

A lakehouse seeks to combine the flexibility and economical storage of a lake with warehouse-like management, including schema enforcement, transactional consistency, versioning, and performance optimization. It is useful when organizations need common data for BI, data science, and operational analytics. Its effectiveness depends on platform maturity, workload isolation, governance, and skills; the label itself does not eliminate architectural trade-offs.

2.4 Data mesh

Data mesh is an organizational and architectural approach based on four ideas: domain-oriented ownership, data as a product, self-service data infrastructure, and federated computational governance. It addresses the problem of centralized teams lacking business context. It does not mean that every domain should independently select incompatible technologies. Federated standards for identity, quality, security, interoperability, and policy remain necessary.

Data mesh is most appropriate where the organization has multiple autonomous domains, strong product-management capability, and the maturity to assign accountable data owners. It is less suitable as an immediate solution for an organization with weak governance, unclear domain boundaries, or inadequate engineering capacity.

2.5 Data fabric

Data fabric generally refers to an architecture emphasizing integrated metadata, automation, semantic consistency, and access across distributed environments. It may use catalogs, lineage, knowledge graphs, policy engines, APIs, and machine-assisted discovery. The term is used inconsistently by vendors, so evaluation should focus on concrete capabilities rather than branding.

2.6 Hybrid and event-driven architectures

Most large enterprises require hybrid arrangements: legacy systems may remain authoritative for transactions while cloud services support analytics, digital channels, or machine learning. Event-driven architecture publishes business events such as OrderPlaced or PaymentSettled. Consumers can react asynchronously, improving decoupling and responsiveness. However, event systems introduce challenges involving ordering, duplication, replay, schema evolution, observability, and eventual consistency.

A practical architecture distinguishes:

• system of record: authoritative source for a defined transaction or entity;
• system of reference: trusted source used for a particular operational or analytical purpose; and
• data product: a governed, discoverable, documented, and usable data asset with an owner and quality expectations.

Replication does not necessarily create multiple sources of truth, provided authority and synchronization rules are explicit.

3. Polyglot Persistence and Workload-Based Design

Polyglot persistence means deliberately using different data technologies for different workloads. It is not the indiscriminate accumulation of databases.

3.1 Major persistence models

• Relational databases: strong schemas, transactions, joins, and mature integrity controls. Appropriate for financial records, orders, inventory, and other structured transactional workloads.
• Document databases: flexible aggregate-oriented records and convenient evolution for varying structures. Appropriate for selected content, profiles, and applications whose access patterns are primarily document-based.
• Key-value stores: extremely fast lookup by key and horizontal scalability. Useful for sessions, caches, preferences, and high-volume simple access patterns.
• Wide-column stores: scalable distributed storage for predictable, high-volume access patterns, especially where queries can be designed around partition keys.
• Graph databases: explicit representation of nodes and relationships. Useful for network analysis, recommendations, fraud relationships, and dependency analysis.
• Time-series databases: optimized for timestamped measurements, retention policies, and temporal aggregation.
• Analytical warehouses and lakehouses: columnar processing, large scans, aggregation, and analytical concurrency.

3.2 Decision criteria

Technology selection should evaluate data model, transaction boundaries, consistency requirements, query patterns, scale, latency, availability, durability, operational skill, portability, security, and total cost. A distributed platform may offer high availability but impose eventual consistency or complex partitioning. A relational platform may simplify integrity but require scaling or workload-isolation strategies.

The CAP theorem is relevant when a distributed data system experiences a network partition: a system cannot simultaneously guarantee both availability and strong consistency across the partition in the general case. This does not mean that systems permanently choose only two of three properties in all circumstances. It means that under partition, designers must understand which guarantees are prioritized. Additionally, “consistency” and “availability” have precise system-specific meanings and should not be reduced to marketing labels.

Polyglot persistence increases duplicated data, specialized skills, monitoring requirements, integration complexity, and failure modes. It should therefore be justified by measurable workload needs, not by technology enthusiasm.

4. Integration, Interoperability, and Data Movement

Integration connects applications and makes information useful across boundaries. Common styles include:

• batch ETL/ELT: efficient for periodic bulk movement and transformation;
• APIs: controlled, synchronous or asynchronous access to capabilities and data;
• message queues: buffering and reliable asynchronous delivery;
• event streaming: continuous publication and consumption of events;
• change data capture: extraction of inserts, updates, and deletes from source systems;
• federated queries: querying distributed data without centralizing all copies.

No style is universally superior. Batch may be appropriate for daily regulatory reporting; streaming may be essential for fraud detection. APIs are useful for governed access but can create tight runtime dependency. Data replication improves local performance but creates synchronization and privacy obligations.

Integration contracts should define schema, semantics, ownership, versioning, error handling, service-level expectations, and security. Schema registries and compatibility rules are valuable in event-driven systems. Idempotent processing is especially important: a consumer should produce the same business result when a message is accidentally delivered more than once. Exactly-once business outcomes are often achieved through idempotency keys, deduplication, transactional boundaries, or reconciliation rather than assumed from transport claims alone.

5. Modernization and Migration Strategy

5.1 Migration approaches

• Retain: keep a system unchanged when risk, cost, or business value does not justify change.
• Rehost: move the workload with minimal modification, often to infrastructure or a managed service.
• Replatform: make limited changes to gain operational or platform benefits.
• Refactor: redesign components to exploit new architecture.
• Replace: adopt a commercial product or new system.
• Retire: remove redundant or obsolete capability.
• Rebuild: develop a new solution, usually when legacy constraints are severe and the capability is strategically differentiating.

These approaches can coexist in one portfolio. A high-risk settlement engine may be retained initially, while customer-facing services are refactored around APIs and events.

5.2 Migration sequencing

A robust roadmap begins with discovery: application inventory, data classification, dependency mapping, quality assessment, regulatory constraints, business criticality, and cost baseline. It then identifies migration waves using criteria such as value, technical feasibility, dependency risk, change capacity, and reversibility.

A typical sequence is:

1. establish principles, governance, identity, security, and observability;

2. select a bounded pilot with meaningful but manageable value;

3. create coexistence and synchronization mechanisms;

4. migrate or modernize prioritized workloads;

5. validate data, performance, controls, and user outcomes;

6. cut over with rollback capability; and

7. decommission legacy components only after evidence confirms stability and retention obligations are met.

A “big bang” migration can be justified in limited circumstances, such as a small system with low dependency complexity. For large enterprises, phased migration usually reduces blast radius and enables learning.

5.3 Data migration controls

Migration must address profiling, mapping, transformation, deduplication, reconciliation, lineage, archival, and acceptance criteria. Reconciliation may compare record counts, control totals, balances, referential integrity, and sampled business outcomes. Testing should include functional, performance, security, resilience, data-quality, and operational-readiness testing.

A technically successful transfer can still be a business failure if users cannot interpret the data, reports change without explanation, or downstream controls are broken. Change management and communication are therefore part of migration engineering, not optional public relations.

6. Build, Buy, or Consume: Economic and Strategic Analysis

A build-versus-buy decision should consider more than initial licensing cost. Relevant dimensions include strategic differentiation, required customization, time to value, integration effort, vendor viability, data portability, regulatory requirements, internal capability, security, lifecycle cost, and exit options.

A simple total-cost model over a chosen planning horizon is:

TCO = C_initial + Σ(C_run,t + C_change,t + C_risk,t) − V_residual

where C_initial is initial acquisition and implementation cost, C_run,t is operating cost in period t, C_change,t is enhancement and migration cost, C_risk,t is the expected cost of material risks in period t, and V_residual is any defensible residual value. Costs should use a common currency, time horizon, and scope. If discounting is required, future cash flows should be discounted using an organizationally approved rate; otherwise, comparisons can be misleading.

Expected risk cost can be represented as:

Expected loss = probability of event × impact if event occurs

This is a decision aid, not a prediction. Probabilities and impacts may be uncertain, correlated, or difficult to monetize. Scenario analysis is preferable where estimates are weak.

An organization should generally buy commodity capability—such as standard workflow or infrastructure management—when a mature product meets requirements and switching risks are manageable. It should consider building when the capability is a source of competitive differentiation, requires unique processes, or cannot be safely adapted from available products. A hybrid approach is common: buy the platform, build domain-specific data products and integrations.

7. Governance, Security, Ethics, and Regulation

Data governance assigns decision rights and accountability. Important roles include data owner, data steward, custodian, privacy officer, security architect, platform owner, and product owner. Governance should define standards for classification, quality, access, retention, lineage, sharing, incident response, and policy exceptions.

Security controls include least privilege, separation of duties, strong authentication, encryption in transit and at rest, secrets management, network segmentation, logging, monitoring, vulnerability management, backup, and tested recovery. Access should be purpose-sensitive: a user authorized to process a transaction may not be authorized to explore an entire customer history.

Privacy requires lawful and transparent collection, purpose limitation, data minimization, accuracy, retention control, subject rights where applicable, and safeguards for international transfer. Sensitive attributes and inferred characteristics require particular care. De-identification reduces risk but does not guarantee anonymity; linkage attacks can re-identify records when supposedly anonymous data is combined with other sources.

AI creates additional governance issues. Training data may contain bias, confidential information, copyrighted material, or inaccurate records. Model inputs require provenance and quality controls, while outputs may require explainability, human oversight, drift monitoring, and appeal mechanisms. Generative AI systems can expose enterprise data through prompts or retrieval mechanisms unless access boundaries and logging are carefully designed.

Ethical architecture asks not only whether processing is legal, but whether it is fair, proportionate, understandable, and contestable. Automated decisions affecting employment, credit, healthcare, or public services demand stronger impact assessment and human accountability.

8. Measuring Architecture and Transformation Outcomes

Metrics should connect technology activity to business outcomes. Useful measures include:

• critical-data quality defect rate and remediation time;
• percentage of important assets with owners, lineage, and classification;
• data-product adoption and user satisfaction;
• report or API latency and availability;
• migration defect rate and reconciliation exceptions;
• recovery time objective and recovery point objective performance;
• infrastructure cost per workload or transaction;
• time required to onboard a new data source;
• number and severity of security or privacy incidents; and
• benefits realized, such as reduced manual effort or improved decision accuracy.

Metrics can create dysfunctional behavior if used without context. For example, maximizing migration volume may encourage movement of low-value data, while minimizing cost may reduce resilience. A balanced scorecard should include value, risk, quality, speed, cost, and sustainability.

9. Leadership and Stakeholder Alignment

Transformation is a socio-technical program. Executives define strategic outcomes and risk appetite; business leaders prioritize capabilities; architects establish coherent target states; engineers implement platforms; data stewards maintain meaning and quality; legal, privacy, and security teams control exposure; and users validate whether change improves work.

Effective leadership makes trade-offs explicit. Stakeholder workshops should identify value hypotheses, affected processes, non-negotiable controls, dependencies, and adoption barriers. Architecture review boards are useful when they make timely decisions based on principles and evidence. They become harmful when they centralize every decision and slow delivery.

A transformation narrative should explain why change is needed, what will change, what will remain stable, how success will be measured, and how people will be supported. Training, revised roles, incentives, and operating procedures are essential because new platforms fail when organizations continue to behave according to the old architecture.

10. Illustrative Case: Modernizing a Regional Bank

Background

The fictional Northbridge Bank operates branch, mortgage, card, and mobile-banking services. Its customer information is duplicated across five major systems. Daily reports are assembled through spreadsheets, fraud detection is delayed, and regulatory reporting requires extensive reconciliation.

Problem

The bank proposes a cloud data platform, but stakeholders disagree. The chief financial officer wants rapid reporting improvement; the chief risk officer requires strong lineage and residency controls; application teams fear disruption; and the chief information officer wants to reduce data-centre dependence without creating uncontrolled vendor lock-in.

Analysis

An inventory identifies three categories of workload. Core account posting requires strong transactional integrity and remains on a relational system initially. Regulatory and management reporting requires curated analytical data. Fraud detection requires low-latency events from card and payment systems. Customer identity is a shared domain with inconsistent identifiers and unclear ownership.

A purely centralized migration is rejected because it would delay fraud improvements and overload a central delivery team. A completely decentralized mesh is also rejected because governance maturity and domain engineering capacity are insufficient.

Approach and Solution

The bank adopts a hybrid target architecture. Existing transactional systems remain systems of record during early waves. Change data capture supplies a governed analytical platform. A customer master service establishes survivorship rules and a consistent enterprise identifier. An event stream carries payment and authentication events to fraud analytics. Curated data products are published for finance, risk, and customer analytics, with domain owners and common security standards.

The roadmap contains four waves:

1. establish identity, cataloguing, classification, lineage, monitoring, and a controlled cloud landing zone;

2. deliver a reporting data product for a high-value regulatory process;

3. introduce event-driven fraud scoring while retaining a safe fallback process; and

4. modernize selected customer-facing services after operational evidence supports further change.

The business case includes implementation cost, cloud consumption, training, decommissioning, vendor exit planning, and expected losses from operational or compliance failure. Success is measured through reporting cycle time, reconciliation exceptions, fraud-alert latency, data-quality defects, platform availability, and user adoption.

Outcome

In this illustrative scenario, the bank reduces reporting preparation effort and improves fraud-response speed without immediately replacing core posting systems. The program also exposes unresolved ownership and data-definition issues, which become explicit governance work rather than hidden defects.

Learning Points

The case demonstrates that modernization is a portfolio of differentiated decisions, not a single technology purchase. Coexistence architecture, authoritative ownership, measurable outcomes, staged risk, and stakeholder alignment are as important as platform selection.

11. Challenges and Limitations

Enterprise architecture models simplify reality. A data mesh may improve domain accountability but increase coordination cost. A lakehouse may reduce platform fragmentation but create dependence on one ecosystem. APIs may improve control but introduce latency and availability dependencies. Cloud adoption may accelerate delivery while complicating cost control, sovereignty, and exit planning.

Benefits are often difficult to attribute because transformation coincides with process, market, and regulatory changes. Cost forecasts are uncertain when usage is elastic or data growth is unpredictable. Legacy systems may contain undocumented business rules that are discovered only during migration. Finally, architecture cannot compensate for absent ownership, weak leadership, or incentives that reward local optimization over enterprise value.

12. Contemporary Developments and Best Practices

Current enterprise architectures increasingly combine real-time streaming, semantic layers, governed data products, managed cloud services, confidential computing, and AI-assisted engineering. Data contracts are becoming more important as teams publish reusable datasets and events. FinOps practices help organizations manage variable cloud consumption. Platform engineering seeks to provide self-service capabilities with secure defaults rather than forcing every team to build infrastructure independently.

Best practice is to:

• begin with business capabilities and measurable outcomes;
• document current state, dependencies, authority, and constraints;
• classify information before moving it;
• select technologies from workload evidence;
• make ownership and quality expectations explicit;
• design security, privacy, resilience, and observability from the start;
• use pilots and migration waves to reduce uncertainty;
• preserve rollback and exit options for critical services;
• involve users, risk specialists, and data owners continuously; and
• retire obsolete systems only after evidence-based acceptance and retention review.

Chapter Summary

Enterprise data architecture aligns information, platforms, integration, governance, security, and operating models with organizational strategy. Warehouse, lake, lakehouse, mesh, fabric, hybrid, and event-driven patterns address different organizational and workload conditions. Polyglot persistence can provide fit-for-purpose performance, but it increases operational and governance complexity.

Modernization requires discovery, workload-based sequencing, data-quality controls, coexistence planning, testing, adoption, and controlled decommissioning. Build-versus-buy analysis should include strategic differentiation, total lifecycle cost, risk, capability, portability, and exit options. Governance assigns accountability for meaning, quality, access, privacy, and security. AI and digital services increase the importance of provenance, human oversight, fairness, and continuous monitoring.

The central strategic lesson is that successful transformation is not defined by adopting a fashionable platform. It is defined by creating sustainable business value while preserving trust, resilience, compliance, and the ability to evolve.

Key Terms

Enterprise data architecture: The design of enterprise-wide data, platforms, integration, governance, and operating practices.

System of record: The authoritative source for a defined transaction or entity.

Data product: A governed, discoverable, documented, and usable data asset with an accountable owner.

Data warehouse: A curated analytical repository optimized for structured reporting and analysis.

Data lake: A repository that stores large volumes of raw or lightly transformed data in varied formats.

Lakehouse: An architecture combining lake-style storage flexibility with warehouse-like management and analytical capabilities.

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

Data fabric: An approach emphasizing metadata, automation, semantic integration, and governed access across distributed environments.

Polyglot persistence: Deliberate use of multiple data technologies for different workloads.

Change data capture: A method for identifying and transmitting source-system data changes.

Event-driven architecture: An architecture in which systems publish and consume business events, often asynchronously.

Data contract: An explicit agreement defining a data asset’s schema, semantics, ownership, quality, and compatibility expectations.

Data lineage: The record of data origins, transformations, movement, and use.

Data steward: A person accountable for data meaning, quality, and appropriate use within a domain.

Rehost: Moving a workload with minimal modification.

Refactor: Redesigning a workload to exploit capabilities of a new architecture.

Total cost of ownership: The lifecycle cost of acquiring, operating, changing, securing, and eventually retiring a capability.

Expected loss: The product of the probability of a risk event and its impact, used as a risk-analysis aid.

Purpose limitation: The principle that personal data should be collected and used for specified, legitimate purposes.

Data sovereignty: The requirement or expectation that data is subject to particular jurisdictional laws and controls.

Review Questions

Short Answer Questions

1. How does enterprise data architecture differ from database schema design?

2. What are the four principal ideas associated with data mesh?

3. Why can a data lake become a data swamp?

4. Define change data capture and identify one use for it.

5. What responsibilities commonly belong to a data steward?

Long Answer Questions

1. Compare warehouse, lake, lakehouse, data mesh, and hybrid architectures. Identify conditions under which each may be appropriate.

2. Explain how workload characteristics influence the selection of relational, document, key-value, graph, and analytical technologies.

3. Develop a phased modernization strategy for an organization with critical legacy systems and strict regulatory obligations.

4. Discuss the economic, strategic, and risk factors in a build-versus-buy decision.

5. Explain how privacy, security, governance, and ethical requirements should be integrated into enterprise data architecture.

Analytical / Application Questions

1. An insurer wants real-time fraud detection, monthly regulatory reporting, and flexible data-science experimentation. Propose an architecture and justify the integration and persistence choices.

2. A proposed cloud migration has lower infrastructure cost but high vendor lock-in and uncertain data-transfer charges. Construct a decision analysis using total cost, risk, portability, and strategic value.

3. During migration, record counts match but customer balances do not. Diagnose possible causes and design a validation, reconciliation, and rollback plan.

Multiple Choice Questions with Answers

Question 1

Which statement best describes enterprise data architecture?

A. The physical schema of one application database

B. The design of enterprise data, platforms, integration, governance, and operating practices

C. A list of approved database vendors

D. A procedure for writing SQL queries

Correct Answer: B. The design of enterprise data, platforms, integration, governance, and operating practices

Question 2

Which architecture emphasizes domain-oriented ownership and data as a product?

A. Data mesh

B. Traditional batch ETL

C. Single-system monolith

D. Network segmentation

Correct Answer: A. Data mesh

Question 3

Which technology is generally most appropriate for maintaining financial transactions requiring strong integrity and joins?

A. Key-value cache

B. Graph database

C. Relational database

D. Object-storage archive only

Correct Answer: C. Relational database

Question 4

What is a principal risk of polyglot persistence?

A. It eliminates the need for data governance

B. It always prevents horizontal scaling

C. It removes the need for integration

D. It increases specialized skills, duplication, and operational complexity

Correct Answer: D. It increases specialized skills, duplication, and operational complexity

Question 5

What does change data capture primarily identify?

A. Changes made to source-system data

B. Changes in employee responsibilities

C. Changes in hardware temperature

D. Changes in legal ownership of a company

Correct Answer: A. Changes made to source-system data

Question 6

Which migration approach involves moving a workload with minimal modification?

A. Refactor

B. Rehost

C. Retire

D. Rebuild

Correct Answer: B. Rehost

Question 7

In the chapter’s total-cost model, which item represents operating and enhancement costs over time?

A. C_initial only

B. V_residual only

C. C_run,t and C_change,t

D. Data lineage

Correct Answer: C. C_run,t and C_change,t

Question 8

Under the expected-loss model, if a risk has probability 0.2 and impact of $50,000, what is the expected loss?

A. $2,500

B. $10,000

C. $50,200

D. $250,000

Correct Answer: B. $10,000

Question 9

Which practice is especially important when event messages may be delivered more than once?

A. Removing all message identifiers

B. Ignoring duplicate events

C. Idempotent processing

D. Disabling monitoring

Correct Answer: C. Idempotent processing

Question 10

Why should a migration not be considered successful solely because data was transferred?

A. Transferred data never requires testing

B. Business outcomes, controls, quality, usability, and downstream processes must also work

C. Migration success depends only on storage capacity

D. Data transfer is unrelated to business processes

Correct Answer: B. Business outcomes, controls, quality, usability, and downstream processes must also work