How to analyse the impact of an architecture change
Run impact analysis against the thing you intend to change and read the result with the right degree of trust.
When this is useful
- A component is being retired, replaced or restructured.
- A schema change is proposed and the consumers are not all known.
- A change request needs an assessment attached to it.
Before you start
- A model whose relationships have been recorded. Impact analysis reads connectors and modelled relationships — it does not scan anything.
Step 1: Select what is changing
Pick the component, entity or field that the change affects.
Step 2: Run Impact Analysis
Impact Analysis follows the recorded relationships outward and reports what depends on the selection.
Data ▸ Impact Analysis
Step 3: Read it as a floor, not a ceiling
The result is exactly as complete as the model. A dependency nobody recorded cannot appear in it.
Use it to find what you would have missed. Do not use it to argue that nothing else is affected — that is a claim the model cannot support.
Step 4: Follow the data as well as the components
Where the question is about data rather than services, Lineage traces how data moves through the model and answers "what feeds this?" alongside "what reads this?".
Data ▸ Lineage
What happens next
The assessment is repeatable: as the model improves, re-running gives a better answer, which is the argument for recording dependencies as you learn them.
Example
A proposed column drop returned four consumers. Three were expected; the fourth was a reporting view added eighteen months earlier by someone who had since left.
Tips
- Run it before the design review, not after. An assessment that arrives with the proposal changes the conversation.
- When it returns nothing, treat that as a prompt to check whether the relationships were ever modelled.
Limitations
- Only recorded relationships are followed. This is the single most important limitation of the whole feature.
- Impact analysis is separately enabled.