Analyst Days 16: Behold the Path of Data, Padawan

In April 2023, I presented “Behold the Path of Data, Padawan” at Analyst Days 16.

This article reconstructs the main ideas rather than transcribing the talk. Examples have been shortened and adapted, and I have left out internal measurements and details of corporate systems.

The central point was simple: analysts benefit from understanding the path behind a finished report. The required depth varies by role. A business analyst and a data analyst do not need identical tools, but both should be able to examine the origin and meaning of a number used in a decision.

Context that should remain separate

In 2021–2022, I worked with banking data platforms and saw how data quality and freshness mattered to downstream decisions. That experience preceded the early real-time product of 2023–2024 and was not the new Decision Engine project that began in autumn 2024.

The talk was broader than one project. It presented data as a chain of transformations, with an owner, meaning, and quality risk at every link.

From a record to a basis for action

I used a deliberately simple model with three levels.

Data is a recorded event or value: a log line, transaction, application status, or sensor reading. Without context, the record may be correct and still be useless.

Information connects data to an entity, time, source, and business event. It becomes possible to understand what happened and how much confidence to place in the record.

Decision knowledge interprets that information through rules, history, and purpose. This is where an action appears: investigate an anomaly, change a process, present an offer, or deliberately do nothing.

The model is not a universal theory. It is a prompt for two practical questions: which context was added at each transition, and who owns the interpretation?

One table, several professional views

The same transaction dataset looks different across the team.

Role	Primary question	Typical risk
Business or systems analyst	What does the record mean for the process and rule?	Correct structure, wrong business meaning
Data analyst	Which pattern does the evidence support?	Sampling or interpretation error
Developer	How can the set be stored and processed reliably?	Performance or faulty transformation
Tester	Which values and transitions break the scenario?	Unchecked boundaries and exceptions
Operations engineer	Does the complete flow arrive on time?	Loss, delay, or silent degradation

No perspective is primary in every situation. Problems appear when one role’s conclusion is used without checking the assumptions that belong to the others.

An illustrative example

Consider a transaction table with customer, amount, currency, timestamp, and status.

An analyst asks what counts as a successful operation and which business period owns it. A developer considers volume, indexes, and update behaviour. A tester asks about negative amounts, unknown currencies, and long-lived intermediate states. Operations checks replication delay and completeness.

If the team discusses field formats only, it can build a technically correct table and a misleading report. If it discusses meaning but not update behaviour, the report may be correct yesterday and stale today.

When convincing data is still wrong

The following is an anonymised composite of a common data-quality incident, not a description of a particular banking environment.

When parsing fails, an ingestion process substitutes a default value. The pipeline reports success, the dashboard updates, and the distribution of customer segments changes. Nothing has crashed, so infrastructure monitoring remains green.

Several complementary controls help detect and investigate the problem:

• the share of default values is a data-quality measure;
• distribution changes are compared with history;
• the segment has an owner and an agreed business definition;
• source and transformations can be followed through lineage;
• the result is checked after delivery as well as on test data.

Data has no intention to lie. The collection, transformation, or interpretation process is wrong. “Where did this number come from?” is therefore more useful than the confident appearance of the dashboard.

Four parts of the data path

Storage. Where do source and derived records live, how long are they retained, who can change them, and which system is authoritative?

Processing. Which rules apply, in which order, and can the calculation be repeated? Batch or stream should follow the required timeliness, not a fashionable technology choice.

Transfer. Which contracts connect systems, and what happens on replay, delay, schema change, or partial unavailability?

Provenance. Where are field meaning, ownership, source, transformations, and quality criteria recorded? Documentation only helps if it changes with the system.

A practical level of data literacy

The exact toolkit depends on the specialism, but I expect an analyst to be able to:

1. explain the business meaning of key entities and measures;
2. inspect a sample with a basic query or alongside a specialist;
3. distinguish missing, zero, and unknown states;
4. ask about freshness, completeness, and source;
5. notice where a join or filter changes the population;
6. connect acceptance criteria to data checks;
7. state a limitation when the evidence cannot support a precise conclusion.

This does not turn every analyst into a data engineer. It prevents the meaning of a number from being delegated entirely to a tool or another role.

The path of data ends not in a warehouse or dashboard but in a decision made by a person or system. The more important the decision, the clearer the provenance, limitations, and ownership of each transition must be.

---

A reconstruction of “Behold the Path of Data, Padawan,” presented at Analyst Days 16 in 2023.

Talk reference: the organiser’s page for Analyst Days 16. The edition number has been corrected against the programme.

Yours, DPUPP