The hidden costs of outsourced integrations: why owning your data layer matters
Outsourcing is a strategic move; a two-person IT department cannot, and should not, have all the necessary expertise in-house. You need partners for networking, ERP systems, and BI. There is nothing wrong with that.
However, there is a fundamental difference between outsourcing a service and outsourcing control of your data infrastructure. That difference is not always immediately visible, but it is always expensive.
The Unspoken Distinction
Most organizations outsource BI to an external partner. That partner builds dashboards, creates reports, and delivers insights. This is perfectly fine. However, in many of these engagements, the BI partner manages not just the presentation layer (the reports and dashboards) but also the underlying data layer. This includes the connections to source systems, the transformations that turn raw data into usable tables, and the core business logic: the definitions of “revenue,” “active customers,” and how returns are processed.
This logic then resides within a proprietary ETL tool managed by the partner, often in an environment you cannot access and a format you cannot export.
As long as the relationship remains productive, you might not notice any issues. The problem only surfaces when you want to switch.
What Switching Actually Costs
License costs are visible. They appear on an invoice; you can compare, negotiate, or cancel them. But the real switching costs are hidden elsewhere.
Suppose that after three years, you decide to transition to a new BI partner. Your current reports are clear and your dashboards look great. But the new partner doesn’t start with the reports: they start with the underlying data. And then, things often come to a standstill.
Where are the transformation definitions? Locked in the previous partner’s ETL tool. Who knows how “net revenue” is calculated? The consultant who left last year. Where is it documented which source data is filtered, merged, or rewritten before it appears in a report? Often, nowhere.
This is not an exceptional scenario; it is the default situation for many mid-sized companies that have entrusted their entire data infrastructure to a single partner.
The cost of reverse-engineering that knowledge, rebuilding transformations, and validating reports is significantly higher than the original implementation -often three to five times as much. You aren’t just rebuilding; you first have to figure out what was built in the first place.
The Strategy: Own the Data Layer, Outsource the Presentation
The solution isn’t to do everything yourself. The solution is knowing what you own and what you outsource.
The data layer (connections, transformations, models, and definitions) should belong to you. It should be built using open standards like SQL, dbt, Fabric Lakehouse, or Azure Data Factory. These are technologies that don’t depend on one specific partner to read, understand, or maintain.
The presentation layer (dashboards, reports, and visualizations) can be built by any competent BI partner. If the data layer is open and well-documented, the presentation layer becomes interchangeable. This isn’t because the presentation doesn’t matter, but because it is a layer you can rebuild without losing the entire foundation beneath it.
It’s like the difference between owning your home’s foundation and building on rented land. As long as you keep paying rent, you might not notice the difference -until you want to renovate.
Ownership as a Strategic Choice
We see this scenario frequently. An organization works with the same BI partner for years. The relationship is good, and the reports work. But when the first questions arise (“Can we adjust this ourselves?” or “What if we want a different partner for a new project?”) it turns out the data layer is so intertwined with the partner’s proprietary tooling that switching is practically impossible.
That is not a technical problem; it is a strategic one. You need a partner who builds on a foundation that belongs to you, one who makes their work transferable, not irreplaceable.
The best proof that a partner does quality work is that a successor can easily pick up where they left off. Complexity that no one else can understand is not a sign of expertise; it’s a sign of a dependency.
How We Approach This
At House of Data, we design the data layer as the property of the client. Every transformation lives in version control. Every definition is documented. Every pipeline is built on open tooling that the client can inspect, modify, and hand over.
Our BI partners (and we deliberately work with more than one) build on top of that layer. They don’t need to worry about how data is extracted from the source system. They focus on what the data means and how to use it, based on clear documentation in SQL and dbt models that are readable without our help.
This approach doesn’t make us indispensable; it makes us replaceable. And that is exactly the point. An architecture that only works as long as the same party is involved is not an architecture; it’s a dependency.
Ownership of your data layer is not a technical preference. It is a strategic decision that determines whether you still have a choice three years from now.