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 | Who actually read the object, including unmanaged spreadsheets and applications | Consumers who did not query during the window examined |
| 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 cannot see a spreadsheet that queries the warehouse over a direct connection; query logs can. 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.
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.
Discover more from Insightful Data Lab
Subscribe to get the latest posts sent to your email.