8.2 Data Flow Diagrams & Value Chains

System-to-System Lineage

Data lineage tracks the origin, movement, transformations, and destinations of data as it flows across the enterprise. It is a critical component of metadata management and data architecture. Lineage can be viewed at different levels of granularity:

1. System-to-System Lineage (Horizontal Lineage): Shows how data moves between different software applications, operational databases, file stores, and message queues. For example, data originating in an ERP system flows to an operational data store (ODS), then to an Enterprise Data Warehouse (EDW), and finally to a Power BI report.
2. Column-Level Lineage (Vertical/Detailed Lineage): Maps individual attributes or columns from source systems through transformations to target tables.

Lineage is essential for several key enterprise capabilities:

• Regulatory Compliance: Meeting guidelines like BCBS 239 (Basel Committee on Banking Supervision) or GDPR (General Data Protection Regulation) by proving the origin, transformations, and processing path of reporting data.
• Impact Analysis: Understanding which downstream reports, systems, or databases will break if a source database column or structure is modified.
• Root Cause Analysis: Troubleshooting data quality issues in a dashboard or report by tracing the calculations and data pathways back to the original entry point.

Data Flow Diagrams (DFDs)

A Data Flow Diagram (DFD) is a graphical representation of the path of data through an information system. It models how data is input, transformed, stored, and output. DFDs do not show control flow (loops, branches, or conditional decisions); they focus purely on the flow of data.

DFD Components

Every DFD consists of four basic symbols:

1. Processes: Tasks or transformations that manipulate data (e.g., validate card, calculate tax).
2. Data Stores: Repositories where data is held (e.g., customer database, log file).
3. External Entities (Sources/Sinks): Actors or systems outside the scope of the diagram that send or receive data (e.g., Customer, Payment Gateway).
4. Data Flows: Pipelines through which data travels (indicated by arrows).

Notational Standards: Gane-Sarson vs. Yourdon-DeMarco

The CDMP exam frequently tests the differences between Gane-Sarson and Yourdon-DeMarco notations. Below is a detailed comparison of their symbols:

Levels of DFDs

DFDs are designed hierarchically to represent different levels of abstraction:

• Level 0 (Context Diagram): The highest level. It models the entire system as a single process bubble, showing only external entities and the data flows entering or leaving the system boundary. Important: Data stores are typically not shown at Level 0, as they are considered internal to the system.
• Level 1: Decomposes the single Level 0 process into major sub-processes, revealing internal data stores and the data flows between them.
• Level 2 (and lower): Explodes Level 1 processes into more detailed sub-processes for software development and detailed architectural design.

Mapping Business Value Chains

A value chain, a concept popularized by Michael Porter, is a series of business activities that add value to a product or service. Data is the key enablement mechanism across the value chain. Data architects map data flows directly to business value chains to ensure that IT systems support core business strategies.

Value chain mapping involves:

1. Identifying Primary Activities: Mapping data flows that support inbound logistics, operations, outbound logistics, marketing, and customer service.
2. Identifying Support Activities: Mapping data flows for procurement, human resources, technology development, and infrastructure.
3. Data Product Maps: Visualizing data products as they move through value streams. A data product is a reusable, high-quality data asset designed for specific business applications (e.g., a "Customer 360" data product).
4. CRUD Matrix: Mapping which business processes Create, Read, Update, or Delete (CRUD) specific data entities. This helps align processes with data architecture.

Worked Example: Customer Order Lifecycle DFD

To illustrate how data flow diagrams function within a business value chain, consider the following order-to-cash lifecycle trace:

• Context Diagram (Level 0): A single process bubble "Order Management System". The external entities are the "Customer" (who sends Order Request, receives Invoice) and "Credit Bureau" (which receives Verification Request, sends Credit Score). No databases are shown at this stage because the focus is solely on the boundaries of the system and its external interactions.
• Level 1 DFD:
  • The "Customer" sends the Order Request flow to Process 1.1: "Verify Order Details" (rounded rectangle in Gane-Sarson).
  • Process 1.1 checks customer credit by sending data to the Credit Bureau, receives the score, and then passes valid order details to Process 1.2: "Authorize Payment".
  • Process 1.2 writes transaction details to the "Transactions DB" (open-ended rectangle data store) and forwards authorization status to Process 1.3: "Fulfill Order".
  • Process 1.3 reads inventory status from the "Inventory DB" and sends a shipping request to the Warehouse external entity.
• CRUD Matrix Integration: In this scenario, Process 1.1 performs a "Read" on Customer Data, Process 1.2 performs a "Create" on Transaction Data, and Process 1.3 performs an "Update" on Inventory Data. This maps directly to the enterprise's data governance policies regarding CRUD permissions.

Exam Trap: Context Diagrams and Data Stores

A recurring exam trap involves the Context Diagram (Level 0 DFD). Questions may ask if a database should be shown on a Context Diagram. The answer is no. Databases and data stores are internal components of the system boundary. The Context Diagram only models the system as a whole and its interactions with external entities. Showing internal data stores violates Level 0 design rules. Another common trap is confusing Gane-Sarson's rounded rectangle process symbol with Yourdon-DeMarco's circle.