Proof · Practitioner experience
Telecom: Databricks Lakehouse Modernization
A national telecom provider's move from a legacy warehouse and siloed marts to a governed lakehouse — medallion discipline, streaming where SLAs demand it, cost observability from day one.
How to read this: an anonymized account of practitioner experience from 21+ years of enterprise technology work, structured the way we would run it. It is not a client logo and not a claimed AnovaCloud engagement — no client names, no measured figures presented as outcomes. Where a specific number belongs to the engagement and isn't ours to publish, we omit it; the narrative reads complete without invented numbers.
01 · BUSINESS PROBLEM
The warehouse bill, the stale dashboards, and the mart sprawl
The provider's analytics ran on a legacy data warehouse supplemented by departmental marts — each team's extract of the truth, refreshed on its own schedule, disagreeing at the edges. Three pains compounded: the warehouse bill grew faster than the business, operational dashboards (network health, customer care) lagged the events they described, and every new question meant another mart, another pipeline, another reconciliation argument.
Leadership didn't need a bigger warehouse. They needed one governed copy of the data that served both batch analytics and near-real-time operations — with costs that could be attributed, understood, and controlled.
02 · INDUSTRY
Anonymized
- Industry
- A national telecommunications provider — consumer and enterprise services, network operations.
- Anonymization
- Client name and identifying details withheld. Presented as experience informing AnovaCloud's methodology, not as an AnovaCloud delivery claim.
03 · SCALE
Orders of magnitude that shaped the design
- Data shape
- High-volume network telemetry and operational events alongside billing, order, and customer data — streaming and batch workloads on one platform.
- Consumers
- Network operations, customer care, marketing, and finance — each with different freshness needs, from minutes to daily.
- Freshness bar
- Operational use cases couldn't wait for nightly batches; the platform had to serve streaming where SLAs demanded it and batch where they didn't.
04 · CONSTRAINTS
The non-negotiables
- Freshness SLAs by use case: network operations needed near-real-time; finance needed correct, not fast. One platform, tiered SLAs.
- Cost discipline: the new platform couldn't just move the bill — spend had to be attributable per workload and per team.
- Subscriber data governance: personal data under regulatory and contractual obligations; access control and lineage non-negotiable.
- BI compatibility: existing dashboards and analyst workflows couldn't break during the migration — adoption dies on broken reports.
- Team skills: warehouse SQL skills were deep; streaming and lakehouse operations were new and had to be built during the program.
05 · BASELINE
What the platform looked like before
A legacy MPP data warehouse as the system of record for analytics, surrounded by departmental marts — each with its own extracts, definitions, and refresh schedules. Batch windows defined what "current" meant. Network telemetry lived largely outside the warehouse, analyzed in operational silos. Costs were a single growing line item nobody could decompose, and "which number is right?" was a standing meeting topic.
06 · TARGET ARCHITECTURE
One lakehouse, tiered by SLA
All sources — BSS/OSS feeds, network telemetry, reference data — land through ingestion governed by data contracts (schema, quality, and freshness expectations enforced at the boundary). The medallion layers do the discipline work: bronze holds raw immutable data, silver holds conformed and cleaned entities, gold holds domain marts purpose-built for consumers. A unified catalog provides lineage and access control; cost observability attributes spend per workload from day one. The serving layer exposes the same governed data to BI, ML feature pipelines, and data APIs — so the operational dashboards and the finance reports finally read from the same source.
07 · KEY DECISIONS
The tradeoffs that mattered
| Decision | Chosen | Why |
|---|---|---|
| Platform direction | Lakehouse on Databricks, not a bigger warehouse | The workload mix — streaming telemetry plus batch analytics plus ML — doesn't fit a warehouse economically. Open table formats kept the data portable and the exit credible. |
| Table format | Open format (Delta Lake) with medallion layout | Portability and time travel beat proprietary lock-in; medallion gives every team the same mental model of data maturity. |
| Streaming vs batch | Streaming only where SLAs demand it | Streaming everything is the most expensive way to learn that most dashboards don't need it. Freshness tiers matched to use-case SLAs. |
| Migration approach | Coexistence with strangler migration per domain | Big-bang warehouse replacements fail loudly. Domains migrated one at a time, with the old and new platforms reconciled during overlap. |
| Cost control | Per-workload cost attribution from day one | A lakehouse without cost observability just moves the surprise. Attribution made optimization a team sport instead of a finance complaint. |
08 · IMPLEMENTATION
Phased by risk reduction
09 · GOVERNANCE
Who decided what
- Data contracts between source teams and the platform: schema, quality rules, and freshness SLAs, versioned and enforced — a broken contract fails loudly at ingestion, not silently in a dashboard.
- Catalog as the front door: every dataset registered with lineage, owner, and access policy; unregistered data didn't exist for consumers.
- Domain data owners accountable for their gold-layer marts — the platform team owned the machinery, domains owned the meaning.
- Cost reviews alongside data quality reviews: per-workload spend discussed in the same forum as pipeline health.
10 · SECURITY
Controls for a regulated estate
- Subscriber and personal data classified and handled under applicable obligations; masking and tokenization where analytics didn't need identifiers.
- Fine-grained access control through the catalog — row and column level where the use case required it — with every access logged.
- Encryption in transit and at rest; network isolation consistent with the provider's existing zones; service identities scoped per pipeline.
- Lineage as a security control: the ability to trace any served number back to its sources, on demand, for audit or incident response.
11 · CHALLENGES
What was actually hard
- Reconciliation arguments: the legacy platform and the lakehouse disagreed during overlap — usually because of undocumented transformations in old marts. Each disagreement was a data-quality find, but winning the argument took evidence, not assertions.
- Freshness expectations: once one dashboard went near-real-time, every team wanted it. The tiered-SLA model held the line — streaming where it paid, batch where it didn't.
- Contract enforcement: source teams initially treated data contracts as paperwork. The first few loud ingestion failures — caught by contracts before bad data spread — converted the skeptics.
- Skill transition: warehouse SQL experts becoming streaming and lakehouse engineers required deliberate investment — pairing, training, and patience during the waves.
12 · RESULTS
Outcomes, described without invented metrics
- Analytics and operations began reading from one governed copy — the standing "which number is right?" argument lost its fuel as domains migrated and reconciled.
- Operational dashboards moved to near-real-time where SLAs demanded it, while batch workloads kept their economics — freshness became a tiered decision, not a platform limitation.
- Cost attribution per workload made spend visible and optimizable; the platform bill became a set of team-level conversations instead of a single growing line item.
- Departmental marts retired on schedule as gold-layer equivalents proved out — the sprawl shrank alongside the warehouse.
13 · LESSONS LEARNED
What generalizes
- Governance before data. Catalog, access model, and cost attribution wired before the first pipeline — retrofitting governance onto a running lakehouse is where programs stall.
- Reconciliation is the migration. The technical move is straightforward; the organizational move is proving the new numbers. Budget for the arguments and win them with evidence.
- Stream by SLA, not by enthusiasm. Freshness tiers keep the platform economical and honest — streaming everything is a cost decision disguised as an architecture decision.
- Contracts make data quality a boundary, not a hope. Enforced ingestion contracts catch upstream breakage where it's cheapest to fix: at the boundary.
- Retire visibly. Mart retirement on a public schedule is what turns a migration into a simplification. Otherwise you get two platforms forever.
14 · RELATED
Pattern, toolkit, service
Lakehouse pattern
The reference architecture: medallion discipline, open formats, and the honest cost model.
Read pattern →Lakehouse architecture guide
When a lakehouse beats a warehouse — migration waves and the honest cost model.
Read the guide →Databricks vs. Snowflake
The mid-market decision guide: TCO, workload fit, and team skills.
Read the guide →Data lakehouse pack
Free working documents: medallion design checklist, table-maintenance runbook, format decision guide.
Get the pack →Data platform health check
Score your platform's cost, reliability, and architecture — free, ungated.
Start the assessment →Engineering practice
AnovaCloud's engineering services: data and cloud platforms, built.
Explore practice →Start here
Talk to an Architect
Bring your hardest AI, data, or modernization problem. We'll tell you plainly whether we can help — and what it takes.