Seven parts, one score

DATABRICKS PLATFORM REVIEW

How a Well-Architected review of a Databricks platform fits together — and why you should run it in pieces.

Th4mat Robotik GmbH · Data platform and platform security consulting

Most architecture reviews fail in one of two ways. Either they produce a sixty-page PDF nobody opens twice, or they produce a verdict — “it looks fine” — that survives exactly until the first incident. Both happen for the same reason: “is our platform well architected?” is too big a question to answer in one sitting, by one person, with one number.

The Databricks well-architected framework takes that question apart. Seven pillars, each covering one area of concern, each broken into principles and then into concrete best practices. Our review follows that structure exactly — seven parts, 30 principles, 185 best practices — so you can run one part this afternoon and the rest next month, and the numbers still add up.

This post covers what each part asks, where the parts deliberately overlap, and how seven separate scores become one platform score without flattering you.

Two pillars for the lakehouse, five from the cloud

Five of the seven pillars are familiar to anyone who has worked with the AWS, Azure or Google cloud frameworks: operational excellence, security, reliability, performance efficiency and cost optimization. The lakehouse inherits their intent unchanged. The specifics differ, because a platform whose unit of work is a table and a job is not a platform whose unit of work is a virtual machine.

Two pillars are specific to the lakehouse and have no cloud equivalent:

•   Data and AI governance — whether data brings value and supports the business strategy. In practice: is there one governance model covering every table, model, volume and dashboard, or seven models and a spreadsheet?

•   Interoperability and usability — whether the platform can be reached by the people and systems that need it, on open formats, without raising a ticket with the platform team.

These two are where lakehouse programmes quietly stall. The five common pillars are where they visibly break.

What each part asks

Part	Pillar	Practices	Who should be in the room	Time
1	Data and AI governance	13	Platform owner, data governance lead	15–30 min
2	Interoperability and usability	15	Platform owner, lead data engineer	20–35 min
3	Operational excellence	21	Platform / DevOps engineer	25–45 min
4	Security, compliance and privacy	75	Security lead, platform admin, cloud networking	2–3 sittings
5	Reliability	18	Lead data engineer, on-call owner	20–35 min
6	Performance efficiency	24	Data / analytics engineer	25–45 min
7	Cost optimization	19	Platform owner, FinOps or controlling	20–40 min

Times assume somebody who actually knows the platform is in the room; they are interview times, not investigation times. Part 4 is five times the size of Part 1 because security is where the framework goes deepest — 75 best practices across identity, data protection, network, compliance and monitoring. You rarely finish it in one sitting, and you should never run it without the security team.

The seven parts, the topics they share, and how the parts roll up into a single platform score.

Where the parts overlap — on purpose

The seven parts are not seven separate audits. They share topics, and the overlaps turn out to be the most informative thing in the exercise.

Three best practices appear verbatim in two pillars each:

•   Use infrastructure as code (IaC) for deployments and maintenance is an interoperability practice (IU-01-05) and an operational one (OE-02-01) — and it appears a third time as a security control (SP-07-06), because reviewed code is how a security setting stops being one person’s memory.

•   Use serverless compute is a usability practice (IU-03-02), a performance practice (PE-01-01) and a cost practice (CO-01-06).

•   Use Unity Catalog managed tables is an operational practice (OE-02-03) and a performance one (PE-02-06).

Then there are the thematic seams. Monitoring appears in five of the seven parts. Data quality is defined in governance (DG-03) and enforced in reliability (RL-02). Disaster recovery is a reliability pattern (RL-04) and a compliance obligation (SP-06-09). Cost attribution is a cost practice (CO-03) and a security signal (SP-07-13/14) — an unexplained spend spike is often the first evidence of misuse.

This is why a single weak score is rarely a single problem.

If Part 3 comes back weak on compute policies, expect Part 7 to be weak on cost control and Part 4 to be weak on identity — the same missing policy is doing damage in three places. Scoring the parts separately and reading them together is what makes that visible.

How seven scores become one

Every best practice is recorded as adopted, partially adopted, not adopted or not applicable, with a free-text note for the evidence. From there:

•   Adopted counts 1.0, partial 0.5, not adopted 0.

•   Not applicable leaves the denominator entirely. A platform with no ML workloads is not penalised for having no model registry.

•   Each best practice carries a weight — critical, high impact or standard. An absent disaster recovery plan and a missing table comment are not the same finding.

•   A part’s score is weighted credit over weighted applicable items, from 0 to 100.

•   The platform score is the plain mean of the parts you have scored. Not a weighted mean, deliberately: otherwise Part 4’s 75 items would drown the other six, and a platform with excellent security and no cost control would read as healthy.

Two consequences worth stating plainly. A part you have not started is not counted as zero — it is not counted at all, and the readout says how many parts the score rests on. And a part where everything is marked not applicable produces no score, rather than a perfect one.

The bands: 85 and above is on track, 70 to 84 means a few growth areas, below 70 needs attention. Those thresholds, and the weights, are our judgement — Databricks publishes the best practices, not a scoring scheme. We say so in the readout, so the number survives its first challenge in the room.

Running it in parts

Some sequences that work:

•   Whole platform, first time. Parts 1 and 3 first — governance and operational excellence set the vocabulary everything else uses. Then Part 4, then the rest.

•   Cost pressure. Part 7, then Part 3. Most cost findings turn out to be compute policies and runtime versions, which live in operational excellence.

•   Before an audit. Part 4 alone, then Parts 1 and 5 for the evidence and recovery questions the auditor reaches next.

•   After an incident. Part 5, then Part 3.

Because each part scores on its own, a partial review is still a real result — with the coverage stated on the scorecard rather than hidden.

What the score is not

It is not a certification and it is not a Databricks product. It is a structured reading of a platform against a published framework, with our weighting on top.

Databricks revises the framework. Since the December 2024 edition, the reliability pillar dropped “create regular backups” and split high availability from disaster recovery; cost optimization replaced its entire monitoring principle with budgets and usage policies; the security pillar went from seven principles to five. Our codes — DG-01-01 and so on — stay stable across those revisions so a re-run compares cleanly against the last one. The underlying documentation titles do not.

Start with one part

Pick the pillar that is currently costing you something — money, sleep, or an auditor’s attention — and run that part alone. An afternoon produces a score, a phased list of findings with the evidence attached, and a clear answer to whether the next part is worth the time.

Follow this link to the tool: Databricks Platform Review Tool | Th4mat We do not track or save your results in any way, but we appreciate your feedback!

Th4mat Robotik GmbH advises on Databricks data platforms and platform security. If you would like the review run with you, or want the tool for your own team, get in touch: info@th4mat.de.