Stack Impact Analysis

Before any stack change I ask how many consumers it touches and whether we can undo it by Friday.

Those two answers put the change in one of four boxes, and each box gets its own treatment.

• Few consumers, easy to undo. Just do it. Swapping a linter or a small internal job doesn’t need a meeting.
• Many consumers, easy to undo. Pilot it with one team first, then widen. A new BI tool running next to the old one lives here.
• Few consumers, hard to undo. Write it down on one page: why you picked that storage format, and what you rejected.
• Many consumers, hard to undo. These are the ones that earn a proper architecture review. Warehouse moves, orchestrator swaps, changing the customer ID.

A lot of teams I see give every change the same process. Small fixes wait weeks for a review slot, and the warehouse migration gets decided in a Slack thread anyway.

Query logs and lineage get me the number in an afternoon, and it’s usually bigger than anyone guessed.

Which box is your next stack change in? The architecture principles I work from are here: https://thomasnys.com/data-architecture-principles/