ZS Associates · 2022–2024 · Data Architecture & Delivery

Retiring a spreadsheet that 500 people depended on

Replaced a hand-maintained Excel reporting process with a layered data lake — 30% faster, for 500+ users.

30%

faster turnaround

500+

business users

Layered data lake on S3, stored as Parquet

Landing
raw data preserved as delivered
prior loads archived

Staging
quality rules and standardization

Mastering
conformed facts and dimensions

Aggregation
business metrics calculated once,
reused everywhere

IQVIA claims data
monthly delivery

Reporting tables

500+ business users
access limited by role

Parameterized PySpark jobs on AWS Glue
sequenced by Step Functions
behavior changed by config, not by editing code

Reusable data quality rule framework
built in-house at ZS

A layered, parameterized data lake replacing a hand-maintained Excel reporting process — monthly claims data refined through four stages into governed reporting tables for 500+ users.

Problem

Monthly reporting for a pharma client ran on an Excel-based pipeline that someone had to edit by hand. Changing a parameter meant opening a spreadsheet and editing it. The process was slow, hard to audit, and impossible to scale past the 500+ people who depended on its output.

Approach

Owned the migration to a layered data lake on AWS. Raw claims data lands as Parquet and is preserved exactly as delivered, with prior loads archived. Staging applies quality rules and standardization. Mastering builds conformed facts and dimensions. Aggregation calculates business metrics once, so they’re consistent everywhere downstream.

Every layer runs on parameterized PySpark jobs in AWS Glue, sequenced by Step Functions — changing behavior means changing config, not editing code.

We built and validated one layer at a time, spending a week testing and tweaking each before starting the next, with the legacy Excel process untouched until the new reporting tables reconciled against it.

no — fix the affected layer

yes

IQVIA claims data
feeds both

Legacy Excel process
keeps serving users
throughout the build

New pipeline built one layer at a time
each layer tested and tweaked for a week
before the next was started

Do the new reporting tables
reconcile with the Excel output?

Cutover
500+ users switch to the new tables

Legacy Excel process retired

30% faster monthly turnaround

De-risking the cutover — each layer validated for a week before the next was built, with the legacy Excel process untouched until the new reporting tables reconciled against it.

Outcome

500+ business users now pull from generated reporting tables with role-restricted access, and monthly turnaround dropped 30%. The same four-layer pattern was reused on a separate $50M commercial sales product — the architecture became a repeatable asset rather than a one-off.

Technical detail

Source & storage

Source data is IQVIA claims, delivered monthly. Storage is Parquet on S3, organized by layer. Loads are full monthly refreshes with prior loads archived, so any layer can be replayed from raw when transformation logic changes.

Quality & access control

Data quality rules run through a reusable framework built in-house at ZS. Access is restricted by role at the layer level.

Layer architecture

The four-layer scheme — Landing, Staging, Mastering, Aggregation — is a variant of the medallion pattern, with an explicit Mastering layer for dimensional conformance sitting between cleansing and aggregation. Landing preserves raw data exactly as delivered, which is what makes replay possible; without it, a logic change means going back to the source system.

  • Data Architecture
  • AWS