Your Data Warehouse Isn’t Integrated Just Because the Tables Are in One Place

SeattleDataGuy’s Newsletter

SubscribeSign in

Your Data Warehouse Isn’t Integrated Just Because the Tables Are in One Place<br>Centralization is not integration!<br>SeattleDataGuy<br>Jul 18, 2026

59

Share

Hi, fellow future and current Data Leaders; Ben here 👋<br>Today I wanted to talk about one of the major issues I still see companies face in 2026.<br>Data integration.<br>Before we jump into today’s article, I want to emphasize how important it is to connect technical solutions to real business outcomes.<br>That is the gap our team at Codestrap helps companies close. We start with the outcomes the business wants to improve, then combine data and software engineering services with our software factory to deliver solutions faster and more consistently.<br>Feel free to reach out if you’d like to check out what we are working on.<br>Now let’s jump into the article!

Many companies have successfully “centralized” their data without actually integrating it.<br>Centralization is not integration!

Integrating data across systems, teams, and business units remains a challenge. It’s also where a lot of the value of building a data warehouse comes from.<br>A warehouse is not integrated just because all the tables are in the same place, and that’s where many companies end up. They have a Salesforce set of customer tables and a product database customer table, but they don’t connect.<br>Now, many businesses want it all unified and integrated…but it’s just not where things end up.<br>For one reason or another, many businesses end up with a jumble of tables. So let’s talk about how many companies get there and how to avoid it.<br>The Original Promise of the Data Warehouse

One of the great things about working at Facebook was that its data was so well integrated across systems.<br>Prior engineers spent time developing systems that made it very easy to integrate from one table to another. There wasn’t even much you had to do as a data engineer in terms of getting disparate data sets to talk to each other. They’d done that in the application layer.<br>Which, in my mind, is the best layer. The less the data team has to do to fix application data and make it answer key questions, the better.<br>That way, when a business executive asks:<br>“Can we split up customers by, say, type of industry, or buying habits”

You can answer easily because you have a single customer table that you’ve taken and joined multiple source systems’ data into one, all thanks to there being a single customer ID that is across all systems.

This was actually the main focus of a recent project. There were several key entities that were spread across multiple systems.<br>But many data warehouses end up being a sandbox of multiple data source-specific tables. The marketing team has its user table, the operations teams have theirs, and of course, the data science team has its own.<br>The mistake many teams make when thinking of a data warehouse is that it’s supposed to just collect data and centralize it. It is also supposed to reconcile data across systems. It was supposed to create a shared enterprise view of the business.<br>That takes time. Data teams across the organization need to agree on everything from what ID will be used for the user to how to label specific entities. And most companies skip past that.<br>What Happens In Most Companies

In most companies, the data warehouse slowly becomes a reflection of the org chart or business units.<br>Enterprises in particular have multiple business units that might even all have their own C-suite with different marketing and sales departments that would benefit from integrating across business units. But whether due to politics or just simply because of a lack of communication, the systems don’t talk to each other.<br>There might be a dozen different data warehouses between the various units, all answering overlapping questions.<br>Here are a few other causes, and of course, most companies deal with more than one of these issues:<br>Mergers and Acquisitions

This comes up frequently in my work with private equity firms and growing organizations. Companies often merge, split, and acquire new businesses. Mergers and acquisitions, in particular, require integrating systems. Usually, the goal is to centralize operations onto one CRM, ERP, and other core business tools. But this takes time, and sometimes, it never happens. Just look up ERP migration failures.<br>SaaS Sprawl

Every team these days seems to have some SaaS product that has overlapping functionality. It makes sense how this happens. The sales teams have Salesforce, the customer success team might be able to use some parts of Salesforce, but maybe they prefer Gainsight, finance has to have NetSuite(no matter how much the data team complains about it), and so on. Every SaaS comes with its own version of customer, user, account, and other concepts that overlap. And all those teams have questions they want answered that involve a bit of data from...