DEV Community

Murray Evans
Murray Evans

Posted on

Lakehouse Architecture for Regulated Industries: Notes from Banking and Energy

I've spent years building data systems in two of the most regulated industries on earth: banking and oil & gas. If a data architecture survives both a bank auditor and an energy regulator, it can survive anything. Here's what the lakehouse pattern looks like when compliance isn't optional.

Why the lakehouse fits regulated industries

The classic split — data lake for raw storage, warehouse for analytics — creates a governance seam. Data gets copied, transformed, and copied again, and every copy is a place where lineage breaks and access controls drift. In a regulated environment, that's not a technical inconvenience; it's an audit finding.

The lakehouse (open table formats like Delta Lake, Iceberg, or Hudi over cheap object storage, with a proper governance layer) collapses that seam: one copy of the data, one set of access controls, one lineage story. When the auditor asks "who touched this field and when," there's exactly one place to look.

Four non-negotiables

1. Governance before scale. Unity Catalog, Apache Ranger, or equivalent — not as phase two, as day one. Table-level and column-level access controls, audit logging of every read. In banking, "we'll add governance later" is how you end up explaining yourself to a regulator.

2. The medallion pattern, enforced. Bronze (raw, immutable) → Silver (cleaned, validated) → Gold (business-ready). The key word is enforced: pipelines that write directly to Gold get rejected in code review. I've seen too many "temporary" shortcuts become permanent data quality incidents.

3. Time travel isn't a luxury. Open table formats give you snapshot isolation and time travel for free. When finance asks "what did this report show last Tuesday," you check out the table version — you don't restore a backup. For reconciliation-heavy industries, this alone justifies the architecture.

4. Data contracts at ingestion. Every upstream system declares its schema, SLAs, and semantics in a contract; breaking changes fail the pipeline instead of silently corrupting downstream. In energy, where SCADA feeds and trading systems converge, this is the difference between a reliable platform and a rumor mill.

The mistake I see most

Teams buy the lakehouse technology (Databricks, Snowflake with Iceberg, open-source Trino stacks) and skip the lakehouse discipline. The tech without governance, medallion enforcement, and contracts is just an expensive data lake with a new name. Architecture is 30% tooling, 70% the rules everyone agrees to follow.


Aziz is a data architect working across banking and energy. He runs AI Data Center in Calgary — data engineering, analytics, and AI systems designed as one intelligent ecosystem.

Top comments (0)