"Your Data Warehouse Isn't Integrated Just Because the Tables Are in One Place" — @SeattleDataGuy

Why this is in the vault

Frames the centralization-vs-integration failure mode in a way directly useful for phData DSA discovery conversations with enterprise clients.

⚠️ Sponsorship

Codestrap (Ben Rogojan's own consulting firm) is promoted at the top of the issue as the solution to the exact problem the article describes — the pitch comes before the content and frames the argument toward Codestrap's value prop ("start with outcomes, combine data and software engineering"). No third-party paid sponsor; this is a self-consulting CTA.

The core argument

Centralizing data into Snowflake, Databricks, or BigQuery is not the same as integrating it. Most companies end up with a "sandbox of multiple data source-specific tables" that mirrors their org chart — marketing's user table, operations' user table, data science's user table — none of which connect.

Root causes SDG identifies:

• Mergers and acquisitions — systems never fully consolidated after the deal; ERP migrations fail routinely
• SaaS sprawl — every tool (Salesforce, Gainsight, NetSuite) brings its own version of "customer" and "account," and all of those teams have cross-system questions
• No entity ownership — when no one decides who owns the customer entity, every team defines it differently; those definitions harden into dashboards and dbt models; leadership then asks "how many customers do we have?" and gets five different answers
• Vertical vs. horizontal integration confusion — some organizations need to stack rows across sources (seven claims systems into one patient table) as well as join related entities across systems (horizontal join); these are different problems and get conflated
• Pressure to deliver quickly — early wins are easy when you're answering single-source questions; the cross-system joins never get built before the next urgent ask lands

Practical remediation framework:

1. Start with the business questions already failing, not with an abstract canonical entity modeling exercise — the questions reveal where the integration gap actually is
2. Pick the 6-8 core entities that matter most (customer, account, product, employee, order, transaction) and model only those first; trying to model the whole company in one sitting fails every time
3. Assign each core entity to a data team that owns it, with clear incentives and tooling
4. Decide which source system is authoritative when systems disagree, and propagate one ID across all production tables — ambiguous IDs become end-user footguns

AI warning: Text-to-SQL and conversational analytics tools generate syntactically correct queries that produce wrong answers when the underlying data is not integrated. The tool does not automatically know how a Salesforce account, a Stripe customer, and a product workspace relate unless those relationships have been explicitly modeled. "Data can look right, pipelines can technically work, and still give you bad results."

Curation section

Articles Worth Reading:

• "Most companies think they're building a software factory. They're actually just shipping bugs faster" — no source URL in plaintext; references Luca Rossi's "The Era of the Software Factory" as prior art but reads as Codestrap content given the software factory framing in the issue's sponsorship block. Label: self-cross-promo (likely Codestrap). Marginal RDCO relevance.
• "Building Trust and Credibility is the New Moat for Engineering Leaders" by Gregor Ojstersek — third-party (Engineering Leadership newsletter). Engineering career/leadership focus; no direct RDCO relevance.

Mapping against Ray Data Co

The phData CAF "Fabric" concept — a governed knowledge graph as the semantic integration center — is the enterprise-scale architectural answer to exactly the unowned-canonical-entity problem SDG documents here. In DSA discovery conversations, the failure-mode taxonomy (M&A sprawl, SaaS sprawl, no entity ownership, vertical vs. horizontal confusion) is a ready-made diagnostic frame for surfacing why a client's current data platform isn't delivering on its promise — and for positioning Fabric as the fix.

The AI warning maps directly to current phData client AI analytics work: when a client asks why their text-to-SQL tool is producing wrong numbers, the root cause is almost always the integration gap SDG describes, not the AI model's capability. That's a concrete phData wedge — and a discovery question worth adding to the DSA scoping toolkit.

SDG's Facebook anecdote (integration done in the application layer means the data team barely has to touch it) reinforces the data-contracts / upstream ownership argument Ray is positioned to make as a TAL-adjacent DSA: fix it at the source, not in the warehouse.

Related

• [[2026-07-14-practical-data-modeling-database-is-not-data-model]] — Joe Reis draws the same distinction SDG is making: having a database schema is not the same as having a data model; representation vs. implementation maps cleanly to centralization vs. integration
• [[2026-04-07-seattle-data-guy-noisy-data-quality-checks]] — data quality failures are downstream of the integration gaps SDG documents here; same author, adjacent diagnostic
• [[2026-03-25-seattle-data-guy-know-nothing-and-be-happy]]