Impact Analysis
Impact analysis is the work of determining, before a change is made, which systems, reports, models, and people it will affect. In data platforms the change is usually to a table, column, definition, or pipeline, and the goal is to replace “I think nobody uses that” with an evidence-based list of dependents who can be told, consulted, or migrated.
The questions it answers
- What depends on this? Downstream tables, models, dashboards, exports, and applications.
- How does it depend on it? Copying a value, aggregating it, filtering on it, or joining on it — each breaks differently.
- Who owns those dependents? The people to notify and to agree a migration with.
- How complete is the list? Stated honestly, because no single source finds everything.
Where the evidence comes from
| Source | Finds | Misses |
|---|---|---|
| Declared dependencies in transformation code | Managed models downstream of the change | Anything outside the project |
| Column-level lineage | Which outputs use the specific column, and how | Tools and paths that do not report lineage |
| Query logs | Which principals actually read the object, including unmanaged spreadsheets and applications — evidence that a consumer exists, and a candidate for who | Consumers who did not query during the window examined; and, behind a shared BI service account or an application connection pool, which report, spreadsheet, or person was behind the query |
| Catalog ownership records | Named owners and stated consumers | Whatever was never recorded |
Some transformation tools expose the first source directly. In dbt, for example, the graph operator my_model+ selects a model together with all of its descendants, and my_model+1 limits that to first-degree descendants — a quick way to list what a change to one model can reach inside the project.
Combining sources matters because their gaps differ. Lineage collected from pipelines does not see a spreadsheet that queries the warehouse over a direct connection unless the engine’s query or access history is fed into it; query logs do. Query logs cannot see a quarterly report that has not run in the last month; ownership records might. A log window shorter than the longest reporting cycle will miss periodic consumers. And a log identifies the executing user, session, and query rather than the business consumer: behind a shared BI account or a connection pool, the report and the person still have to be resolved — through a query tag carrying the report or job identifier, the BI tool’s own metadata, application logs, or asking the owner — so treat a log entry as evidence and a candidate, not as the notification list.
Meaning changes need a different question
For a structural change, “who reads this column?” is the right question. For a change in what a value means — revenue excluding cancellations, a customer counted differently — the question is “who relies on this definition?” A consumer can read a column without relying on its old meaning, and a consumer who relies on it will not see any error when it changes. The answer usually needs the owners of the downstream metrics, not just a list of queries.
The output of impact analysis should be a list someone acts on: who is notified, who must migrate, by when, and who confirms they have. How that list feeds versioning and deprecation when a data model changes is worked through in Changing a Data Model Without Breaking the People Using It.
References
- dbt Documentation, Graph operators
- OpenLineage, Column Level Lineage Dataset Facet
- Snowflake Documentation, QUERY_HISTORY view
Discover more from Insightful Data Lab
Subscribe to get the latest posts sent to your email.