SSM Data Lake ArchitectureAn executive briefing
Prepared for SSM Health executive leadership · Business Intelligence & Analytics

All your data in one lake — and the architecture to trust it.

A data lake stores everything you collect — structured, semi-structured, and raw — in cheap, open cloud storage, so many tools can use one copy of the truth. The lakehouse adds the reliability and governance of a warehouse on top. This briefing lays out the philosophy, the architecture, who's building it, and how it maps to SSM's own enterprise data model.

The premise

Store all data in open formats on low-cost object storage; let any engine — BI, SQL, ML, streaming — read one governed copy instead of many siloed extracts.

Why now

Cloud object storage plus open table formats (Delta Lake, Apache Iceberg, Hudi) matured into the lakehouse — warehouse reliability on lake economics, without lock-in.

The SSM lens

One governed source behind Epic, Databricks, and Mission Intelligence — so Epic reporting and Databricks never tell different stories, and every team works from the same enterprise data model.

The centerpiece · Watch & learn

Hear it from the people who built it.

Pick a talk — it plays right here. Every video below was verified as real and embeddable. These are canonical talks and explainers from the people and platforms that defined the data lake and the lakehouse.

8 talks · embeds verified

Why it matters: A crisp, vendor-neutral primer that defines the data lake as a centralized repository for raw data in its native form — the right baseline vocabulary before the deeper architecture talks.

Source channel: IBM Technology · Open on YouTube ↗

Select a talk

What a "data lake" actually means

Plain-language definition

A data lake stores raw data as-is, and applies structure when you read it.

A warehouse uses schema-on-write: you model and clean data before it lands, which is reliable but rigid. A lake uses schema-on-read: you store anything cheaply now and impose structure when you query it — flexible, but it pushes the data-quality and governance problem downstream.

The term was coined in 2010 by James Dixon, then CTO of Pentaho, contrasting a tidy data mart with a body of water in its natural state. The danger he and others later named: without governance, a lake silts into a data swamp — full of data nobody trusts. The lakehouse is the answer: warehouse-grade management (transactions, schema, governance) directly on open lake storage.

"If you think of a datamart as a store of bottled water — cleansed and packaged and structured for easy consumption — the data lake is a large body of water in a more natural state." — James Dixon, CTO of Pentaho, the post that coined "data lake," Oct 2010

Schema-on-write

Data Warehouse

Structured, modeled, governed before load. Inmon/Kimball heritage.

  • Great BI & SQL performance
  • Rigid; ETL up front
  • Costly to store everything
Schema-on-read

Data Lake

Any data, raw, in open files on cheap object storage.

  • Flexible; ML-ready
  • Low storage cost
  • Risks becoming a swamp
Best of both

Lakehouse

Warehouse management on lake storage via open table formats.

  • ACID + governance
  • One copy, many engines
  • BI, ML & streaming together

Framed for SSM Health

The grocery analogy, in data terms

When every store solves supply on its own, you get sprawl and duplication. A shared, governed lake is the central distribution hub — stores still serve their communities, but the supply behind them is finally shared and interchangeable.

One front door, one story

The point of consolidating to a lake is that Epic reporting and Databricks tell the same story. Mission Intelligence is the front door; the governed lake is the shared shelf behind it.

Governance is the difference

Lake vs. swamp is a governance decision, not a technology one. A catalog, ownership, and quality rules are what keep the lake trustworthy at scale.

Schema-on-read, used deliberately

Land raw once; model it into dimension/fact and enterprise models as use cases demand. Flexibility up front, structure where it pays off.

Open formats protect optionality

Open storage and table formats mean one copy of data serves many tools — and the platform choice stays reversible instead of locked in.

"The data lake was a schema-on-read architecture that enabled the agility of storing any data at low cost, but … punted the problem of data quality and governance downstream." — Armbrust, Ghodsi, Xin & Zaharia, Lakehouse, CIDR 2021

The real arc

From a 2010 blog-post metaphor to the open lakehouse.

Every milestone below is dated to its first publication and links to a primary source. This is the genuine lineage of the data lake and the lakehouse — no revisionism.

How it's actually built

The medallion architecture: raw in, trusted out.

The dominant lakehouse pattern refines data in stages — bronze, silver, gold — so quality, structure, and business meaning increase at every hop. It maps almost one-to-one onto SSM's own raw → dimension/fact → enterprise-model path.

Br

Bronze

RAW · AS INGESTED

Raw data landed in its original form from source systems, message buses (Kafka/Kinesis), and object storage. Appended incrementally; minimal cleanup. The single source of truth for what arrived.

At SSM: the raw data already in the lake, before it's shaped for a model.
Ag

Silver

CLEANED · CONFORMED

Cleansed, deduplicated, validated, and joined into conformed dimension and fact tables. At least one trustworthy, non-aggregated representation of each record.

At SSM: the "silver construct" — raw transformed into Dim/Fact tables, joined to the model by surrogate key.
Au

Gold

BUSINESS-LEVEL

Highly refined, aggregated, dimensionally modeled data aligned to business logic — the measures and definitions that power dashboards, executive reporting, and ML.

At SSM: the enterprise data model layer — Epic-based and custom SSM models carrying measure logic.

Source systems → Bronze (raw) → Silver (Dim/Fact) → Gold (enterprise models) → Mission Intelligence & BI

Separation of storage & compute

Cheap, near-infinite object storage (S3, ADLS, GCS) is decoupled from elastic compute. You pay for compute only when querying, and many engines read the same copy.

Open table formats

A transaction log over open Parquet files adds ACID transactions, time travel, and schema evolution — turning a pile of files into a reliable, governed table.

Catalog & governance

A catalog (Unity Catalog, AWS Glue/Lake Formation, Apache Polaris) provides discovery, lineage, and fine-grained access control — the guardrails that keep a lake from becoming a swamp.

Streaming + batch, unified

One copy of data serves both scheduled batch and near-real-time streams. Lambda splits the two; Kappa unifies them over a replayable log — fewer pipelines, fresher data.

Cost & scale

Commodity storage plus elastic compute is dramatically cheaper than duplicating everything into a proprietary warehouse — one open copy, sized to demand.

Time travel & reliability

Snapshots and an audit log let you query data as of a point in time, roll back bad writes, and reproduce a number — the reliability a regulated health system needs.

The three open table formats that made the lakehouse possible

Delta Lake

Databricks · Linux Foundation

ACID over Parquet via a transaction log; time travel, schema enforcement, MERGE/UPDATE/DELETE, unified batch + streaming. SSM's Databricks lakehouse is built on it.

Apache Iceberg

Originated at Netflix · ASF

Hidden partitioning, snapshots, and full schema/partition evolution. Now the cross-vendor interoperability standard; its creators' company, Tabular, was acquired by Databricks in 2024.

Apache Hudi

Originated at Uber · ASF

"Hadoop Upserts Deletes and Incrementals" — built for fast upserts, change-data-capture, and incremental processing at streaming scale.

Who is building this

The platforms and people shaping the field.

A map of where the technology, the open standards, and the ideas are coming from.

Platforms & organizations

People

Read the primary sources

The documents behind the claims.

Papers, founding blog posts, and authoritative vendor docs — each link checked to resolve. Where an official page blocked our automated checker, it is flagged so you can confirm it in a browser.

In their own words

What the field's architects actually said.

Real, attributed quotes — speaker, venue, and date — each linked to where it can be verified. Nothing here is paraphrased or invented.

Traceability

How this briefing was sourced.

This was researched before it was written, with the SSM BIA "Slide Library" executive deck as the narrative backbone. Every talk, paper, and quote was traced to a primary source and link-checked. The notes below state exactly what was verified — and what to double-check.

Verified

  • All 8 video embeds were confirmed real and embeddable via YouTube's oEmbed endpoint (titles and channels returned valid JSON) on 25 June 2026 — from official channels: Databricks, Thoughtworks, the Apache Software Foundation, IBM Technology, AI Council, and Guy in a Cube.
  • All papers/docs link to primary sources — the CIDR 2021 Lakehouse PDF, the VLDB 2020 Delta Lake PDF, James Dixon's 2010 post, Martin Fowler's data-mesh articles, Apache project sites, and Databricks / Microsoft / AWS docs — and were checked to resolve.
  • All quotes are verbatim and precisely attributed to a named speaker and a dated, linkable source.
  • Notable facts confirmed: "data lake" coined by James Dixon (2010); Iceberg originated at Netflix; Hudi at Uber; Databricks acquired Tabular (Iceberg's creators) in June 2024; Unity Catalog open-sourced June 2024; Kappa architecture proposed by Jay Kreps (2014).

⚑ Flagged — confirm before circulating widely

  • Content basis: The SSM-specific framing (grocery analogy, enterprise data model layer, "the lake," silver Dim/Fact path, Mission Intelligence) is drawn from Evan's BIA "Slide Library" deck (0611 LIB Full.pptx). It is an internal operating-model deck — verify any figures or names before external use.
  • Gartner "data swamp": Gartner's "Data Lake Fallacy" press release and report pages return automated-access blocks (HTTP 403). The URLs are real; the Nick Heudecker quote is verified via an accessible reprint (DatacenterDynamics). Open the Gartner page in a browser to confirm.
  • Academic PDFs: The Lakehouse (CIDR 2021) and Delta Lake (VLDB 2020) links are author/venue-hosted PDFs; the automated checker confirmed they resolve and match by embedded metadata rather than rendered text. They are the authoritative copies.
  • Inmon quote: Bill Inmon's data-warehouse definition originates in his 1992 book Building the Data Warehouse; it is cited here via an encyclopedic source rather than a page image.
  • Brand color: Theming reuses the green→teal gradient from SSM's Mission Intelligence apps and the agentic-engineering briefing in this workspace. Exact official hex values are not published.

Generated live, by the agent

The AI studio.

Anything the embedded agent creates appears here — images (Imagen 4) or short video (Veo). Open the agent (bottom-right) and ask: “generate an image of a governed healthcare data lakehouse,” or “make an AI video for the hero.”

Nothing generated yet — open the agent (bottom-right) and ask it to create something.
✦ The agent noticed