A few years ago I asked a vice president how the business intelligence team I was on actually proved its value. His answer was straightforward: we made it easier for directors and executives to see the current state of the business and judge what was possible next.
That discussion stuck with me because it was so different from how most foundational work gets discussed. Data architecture, data governance, and the unglamorous parts of IT hygiene rarely get described in terms of decision quality or growth optionality. They get described as cost centers. When something is only a cost, the rational move is to minimize it, defer it, and hope the problem stays quiet.
The past few days of widespread vulnerabilities—especially the critical PHP issues that affected a large share of the web—made the pattern obvious again. Plenty of people have pointed out that basic patching, asset management, and maintenance were underfunded for years. The harder observation is why. Work that leadership can’t clearly connect to top-line outcomes tends to lose the budget fight, even when everyone agrees it is important in the abstract.
The same logic shows up outside technology. In manufacturing, anything that could not be framed as a reason to upsell the product was treated as a liability to be reduced or offshored. Quality and durability became costs rather than features. The result was a lot of products that failed on a predictable schedule.
I got caught in the early wave of this offshoring and cost-only project filtering between the late 90s and the mid-00s. At the time I was a manufacturing engineer in the automotive industry, and I saw plants closed as automakers moved manufacturing offshore, first to Mexico and then to China. Plant management was under a lot of pressure from finance to get their costs down, and a lot of kaizen / continuous-improvement projects were either deprioritized or outright cancelled unless they could be justified as a cost-cutting expense. It was one of the reasons I decided to make the jump from manufacturing to data engineering.
The same dynamic appears in data work, just with different symptoms. A model that collapses grain or mixes two sources of truth does not merely create technical debt. It makes certain questions harder or riskier to answer. When membership and claims sit at different grains, or when eligibility and adjudicated status are treated as interchangeable, the reports that directors use for pricing or capacity decisions become noisy. Governance that can’t explain lineage or ownership makes a new partnership or product change slower and more expensive. Those costs are real, but they’re easy to treat as someone else’s problem until an initiative stalls or a risk materializes.
The pattern is consistent: work that only shows up as “keeping the lights on” or “reducing risk” loses to work that can be tied, even loosely, to revenue, margin, or speed of decision. Late-arriving facts, slowly changing dimensions that aren’t modeled as such, and domain reference data that drifts without notice all compound quietly. They do not produce an immediate incident the way an unpatched vulnerability can. They produce decisions that are slower, narrower, or less confident than they should be. Leadership experiences that as friction or missed opportunity rather than as a data-architecture failure, so the underlying work stays underfunded.
If we want this work treated as an investment rather than an expense to cut, we have to get better at showing the connection ourselves. The BI example was simple: better visibility into the current state and clearer sight of future options. The equivalent for architecture and governance is usually going to be some version of the same thing: faster, lower-risk answers to the questions that actually drive revenue or protect it.
That can look like a membership model that lets product and finance see the real impact of a pricing or network change without weeks of reconciliation. It can look like lineage that shortens the time from “we think this is happening” to “we can act,” so a partnership or acquisition moves without six months of data-mapping risk. It can look like governance that surfaces ownership early enough that a new data source does not create a second, conflicting source of truth for a metric the board already tracks. None of these are abstract. They are the difference between a leadership team that can evaluate an option and one that has to wait for a special analysis that may never finish.
The recent vulnerabilities are a reminder that “we’ll get to it” is not a strategy when the work is only visible as a cost. The more clearly we can show how the work changes what the business can decide or do, the harder it becomes to treat it as optional. That demonstration is not automatic. It requires translating grain, lineage, and ownership into the language of decision speed, risk to revenue, and the set of options leadership can actually consider. When that translation is missing, the work remains a cost center. When it is present, the same work starts to look like the thing that makes the next decision possible.