The data spine for a
multi-brand portfolio.
A consumer holding company with 6+ subsidiary brands had no way to see across its portfolio without manual, spreadsheet-stitched exports. We designed and built a Snowflake data warehouse that unified reporting, analytics, and third-party integrations across every brand — without asking any subsidiary to change how they operate. Two years in, we still own and extend the pipelines as the portfolio grows.
One warehouse. Every brand. No disruption.
A multi-brand consumer holding company operates a portfolio of 6+ subsidiary businesses, each with its own operational systems, e-commerce storefronts, and back-office tooling. Finance couldn't roll up numbers across the portfolio without hours of manual export work. Every new third-party integration — accounting, marketing, analytics — had to be built and maintained per-subsidiary, multiplying engineering cost with every brand added.
The mandate was simple to state and hard to execute: give the organization one place to see and act on data from every brand, without disturbing any of them.
A portfolio with no shared spine.
Every subsidiary ran on its own stack. Different databases, different e-commerce platforms, different back-office processes, different teams and cadences. That was fine at the subsidiary level — each brand ran itself well — but at the parent level, it was a wall.
Any question that crossed brand boundaries meant a manual, multi-step data-gathering project. And every new third-party integration compounded the problem: one connection point per brand, per tool, forever.
Zero cross-brand visibility
Cross-subsidiary questions — total portfolio revenue, category performance, customer overlap — required manual exports from disparate systems, stitched together in spreadsheets. Answers took days and went stale immediately.
Non-disruptive by mandate
Each subsidiary had its own stack, workflows, and pace. Central IT couldn't dictate migrations. Whatever we built had to work around every brand's existing systems, not through them.
Integration sprawl was compounding
Every new tool the parent adopted meant N per-subsidiary integrations to build and maintain. Each acquired brand made the problem worse. Without a shared data layer, scale was a liability.
A warehouse the whole portfolio can rely on.
We designed Snowflake as the central spine. Azure Data Factory pipelines pull from each subsidiary on its own cadence — operational databases, e-commerce storefronts, ERP, marketing tooling — and land the data in a normalized layer with a semantic model that unifies concepts like customer, order, and product across brands.
Power BI sits on top for finance and operations. Third-party integrations that used to be built per-brand increasingly consume from a single source instead. And because the ingestion layer is the parent's responsibility, subsidiaries never had to change vendors, workflows, or people.
Snowflake as the spine
A single warehouse, cheap to scale, decoupled from any subsidiary's operational stack. All portfolio data lands here in a common semantic model that reconciles brand-specific data shapes into shared concepts.
Non-disruptive ingestion
Azure Data Factory pulls from each brand on its own schedule. No subsidiary had to migrate, change tools, or add process. Ingestion became the parent's problem, not theirs.
Integrations point at the warehouse
Instead of a new sync per brand per tool, third-party integrations increasingly read from Snowflake — collapsing sprawl into a single, testable integration surface.
Built for the query pattern, not just the data volume.
A warehouse that ingests everything but answers slowly is a liability. From day one we designed for how reports would actually be run — layering the warehouse, modeling dimensionally, and refreshing incrementally so cost and latency stayed flat as the portfolio grew.
A layered warehouse: raw → staging → core → marts
Raw is a 1:1 mirror of each source, untouched. Staging standardizes types, deduplicates, and applies basic quality checks. The core layer applies business logic and produces conformed dimensions shared across brands. Marts denormalize into subject-area, BI-ready shapes tuned for the queries analysts actually run.
Star schemas with conformed dimensions
Marts follow Kimball dimensional modeling. Fact tables (orders, transactions, enrollments) are held at the lowest usable grain, surrounded by conformed dimension tables (customer, brand, product, date) defined once at the core layer. Every brand's data speaks the same language, so cross-brand joins and rollups are trivial for BI to write and fast for Snowflake to execute.
Incremental loading with Streams, Tasks, and MERGE
Snowflake Streams capture row-level change from source landing tables; Tasks orchestrate the pipeline on a schedule tuned per source; MERGE upserts into targets. Large fact tables never full-refresh — only new and changed rows move each cycle, keeping compute cost predictable as data volume grows.
Workload separation across virtual warehouses
Dedicated Snowflake compute per workload: one for ELT transformation, one for Power BI, one for ad-hoc analytics. Heavy nightly transforms never contend with an analyst refreshing a dashboard, and cost is attributable per workload instead of pooled.
From zero cross-brand insight to load-bearing infrastructure.
The data spine of the business
Before this project, no one in the organization could answer a cross-brand question without hours of manual work. Today, the warehouse is the shared source of truth for finance, operations, and analytics — a system the business now depends on.
The warehouse has grown steadily since it shipped in 2023. We continue to own the pipelines, extend the semantic model as new reporting needs emerge, and onboard new subsidiaries as the portfolio grows. What began as a Phase 1 MVP is now the analytical backbone of the business.
Used daily by finance, operations, and analytics teams — the reporting infrastructure the parent now runs on.