Three People. One Building. Three Different Blueprints.
The CFO walks into the room.
She wants to know who owns the customer data, how it flows into revenue reporting, and what the regulatory boundary is.
The data architect walks into the same room.
He wants to know which entities relate to which, how the schemas connect, and where the domain boundaries are drawn.
The platform engineer walks into the same room.
She wants to know which database, which partitioning strategy, which index design, and which cloud region.
Three legitimate questions.
Three completely different answers.
All describing the same data estate.
Now consider this.
Most enterprises hand the same document to all three.
Or worse — each person has built their own document.
And none of the three documents point to each other.
The CFO's data ownership register does not connect to the architect's logical model.
The architect's entity diagram does not trace to the engineer's physical schema.
The engineer's infrastructure spec does not map back to the business rule it was built to enforce.
Three layers.
Three islands.
Zero coherence.
That disconnection is not a communication problem.
It is a structural failure.
And it is the reason data estates drift the moment delivery begins.
The Structural Gap Nobody Has Named
Organisations know the three layers exist.
They have seen the diagrams.
Business layer. Logical layer. Physical layer.
Every architecture textbook covers them.
What the textbook does not cover is the gap between them.
Not the conceptual gap.
The operational gap.
In practice, the business layer is owned by data stewards.
The logical layer is owned by data architects.
The physical layer is owned by platform engineers.
Three teams. Three tools. Three review cycles. Three governance rhythms.
And when a business rule changes, nobody knows which logical entity it affects.
When a logical schema changes, nobody knows which physical tables it will break.
When a physical migration happens, nobody checks whether the business intent it was serving still holds.
The layers were named.
The connections were never built.
What Most Enterprises Have Built
This is the architecture most enterprises are actually running.
%% caption: The three data layers as most enterprises run them, each kept as a separate artifact
flowchart TD
A["Business Layer\n(Data Ownership Register)"]
B["Logical Layer\n(Entity Relationship Model)"]
C["Physical Layer\n(Database Schema)"]
A -. "no formal link" .-> B
B -. "no formal link" .-> C
Three layers.
Three separate artefacts.
No traceability between them.
When a regulation changes, the business layer is updated.
The logical model is not.
The physical schema is definitely not.
And the estate quietly drifts away from the intent that was supposed to govern it.
Layered Data Authority (LDA)
Layered Data Authority (LDA) is a structural model that connects the three layers of enterprise data architecture into a single traceable framework.
Its purpose is not to add governance overhead.
Its purpose is to make three things permanently true:
- Every physical implementation traces to a logical design decision
- Every logical design decision traces to a business intent
- Every business intent is visible at the layer where it is enforced
LDA does not collapse the layers into one.
It builds the bridges between them.
%% caption: Layered Data Authority: mappings bind each layer to the one above it and back to business intent
flowchart TD
A["Business Layer\nIntent + Ownership + Rules"]
B["Logical Layer\nEntities + Relationships + Contracts"]
C["Physical Layer\nStorage + Schema + Infrastructure"]
A -- "Logical Binding\n(entity-to-domain mapping)" --> B
B -- "Physical Binding\n(schema-to-entity mapping)" --> C
C -- "Traceability\n(back to business intent)" --> A
Each layer has a defined owner.
Each layer has a defined output.
Each layer connects to the next through a named binding contract.
When anything changes, the binding contract surfaces the downstream impact.
That is the structural shift.
Layer 1 — The Business Layer
What It Is
The business layer is the intent layer.
It answers one question:
What does the enterprise need from its data — and who is accountable for it?
It does not describe how data is structured.
It does not describe where data is stored.
It describes what data means to the business, who owns it, and what rules govern it.
This is the layer that regulators care about.
This is the layer that CDOs live in.
This is the layer that most data architects skip when time is short.
That is the most expensive shortcut in data architecture.
What It Contains
%% caption: What the business layer contains
mindmap
root((Business Layer))
Data Domains
Customer
Product
Finance
Operations
Risk
Data Ownership
Domain Steward
Executive Sponsor
Regulatory Owner
Business Rules
Retention Policies
Classification Tiers
Consent Requirements
Regulatory Boundaries
GDPR
DPDP
SOX
HIPAA
The Business Layer Template
| Element | Description | Owner | Review Cadence |
|---|---|---|---|
| Data Domain | Named grouping of related business data | Domain Steward | Quarterly |
| Domain Definition | What this domain contains, what it excludes | Data Architect | At creation |
| Executive Sponsor | Senior owner of business intent for this domain | CXO / Director | Annual |
| Data Classification | Public / Internal / Confidential / Restricted | Data Steward | Quarterly |
| Retention Policy | How long data in this domain may be held | Legal / Compliance | Annual or on regulation change |
| Consent Model | What consent governs collection and use | Privacy Officer | At creation + on regulation change |
| Regulatory Boundary | Which regulations apply to this domain | Compliance | Annual |
| Downstream Consumers | Which business processes consume this domain | Domain Steward | Quarterly |
| Logical Model Reference | Link to the logical entity or entities that implement this domain | Data Architect | On every logical change |
The last column is the binding.
Without it, the business layer is a register.
With it, the business layer is the governing root of the entire architecture.
What the Business Layer Decides
- Which data domains exist and what they contain
- Who is accountable for each domain's accuracy and compliance
- What classification tier governs each domain
- What regulatory rules apply and where the boundary sits
- Which domains may join and under what governance conditions
The business layer does not decide how the data is structured.
That is the logical layer's authority.
Layer 2 — The Logical Layer
What It Is
The logical layer is the design layer.
It answers one question:
How is the business intent expressed as a structured data model — independent of any specific technology?
It does not describe storage.
It does not describe partitioning.
It describes entities, relationships, attributes, and the domain contracts that connect them.
This is the layer where architectural decisions about data shape are made.
This is the layer where future flexibility is either protected or destroyed.
Most enterprises build it once and never revisit it.
That is how structural debt accumulates silently.
What It Contains
%% caption: One business domain, Customer, mapped to its logical entities
flowchart LR
A["Business Domain:\nCustomer"]
B["Logical Entity:\nParty"]
C["Logical Entity:\nCustomer Account"]
D["Logical Entity:\nConsent Record"]
E["Logical Entity:\nCommunication Preference"]
A --> B
B --> C
B --> D
B --> E
C -. "has many" .-> D
C -. "has one" .-> E
The business domain maps to multiple logical entities.
Each entity has defined attributes, a uniqueness key, and relationship contracts to adjacent entities.
None of this references a database technology.
It is not a PostgreSQL schema.
It is not a BigQuery table definition.
It is the intention — expressed precisely enough that any physical implementation can trace back to it.
The Logical Layer Template
Entity Definition Card
| Element | Description |
|---|---|
| Entity Name | Party |
| Business Domain | Customer |
| Definition | Any individual or organisation that has or may have a relationship with the enterprise |
| Uniqueness Key | Party ID (system-generated surrogate) + Party Reference (business-assigned) |
| Core Attributes | Party Type (Individual / Organisation), Legal Name, Registration Date, Status |
| Derived Attributes | Age (from date of birth), Tenure (from registration date) |
| Relationships | Has many: Customer Accounts, Consent Records; Has one: Communication Preference |
| Domain Contracts | Customer Account must reference a valid Party before creation; Consent Record cannot exist without an active Party |
| Classification Tier | Confidential (inherited from Customer domain) |
| Physical Model Reference | Links to: core.party, crm.customer_master |
| Business Layer Reference | Customer Domain — Data Steward: [Name] |
| Last Reviewed | [Date] |
| Owner | [Data Architect name] |
The last two rows are the bindings.
Upward to the business layer.
Downward to the physical layer.
What the Logical Layer Decides
- How business domains translate into entities and attributes
- What uniqueness keys govern each entity
- What relationships and contracts exist between entities
- What derivation rules apply to computed attributes
- What the domain contract is — the rules that every physical implementation must enforce
The logical layer does not decide where the data is stored.
That is the physical layer's authority.
Layer 3 — The Physical Layer
What It Is
The physical layer is the implementation layer.
It answers one question:
How is the logical design expressed in specific technology — at the scale, latency, and cost the business requires?
It describes schemas.
It describes storage technology.
It describes partitioning, indexing, encryption, and access control.
This is the layer most engineers live in.
This is the layer most architects delegate entirely.
That delegation is the reason data estates become ungovernable.
Because physical implementations made without logical traceability quietly become the new architectural truth — whether the architecture team meant them to or not.
What It Contains
%% caption: One logical entity, Party, traced to its physical stores in PostgreSQL, Snowflake and S3
flowchart TD
A["Logical Entity:\nParty"]
B["Physical Table:\ncore.party\n(PostgreSQL — Operational)"]
C["Physical Table:\ncrm.customer_master\n(Snowflake — Analytical)"]
D["Physical Object:\nparty_profile\n(S3 — Archived)"]
A --> B
A --> C
A --> D
B -. "replicated via CDC" .-> C
C -. "archived nightly" .-> D
One logical entity.
Three physical representations.
Each serving a different purpose.
Each governed by the same logical contract — even though they are implemented differently.
The Physical Layer Template
Physical Implementation Card
| Element | Description |
|---|---|
| Physical Object Name | core.party |
| Logical Entity Reference | Party (Logical Layer — [link to entity card]) |
| Technology | PostgreSQL 16 — Operational Store |
| Schema Owner | Platform Engineering — Data Services Team |
| Primary Key | party_id (UUID, system-generated) |
| Partition Strategy | None (operational; row-level access pattern) |
| Index Strategy | Index on party_reference, status, created_at |
| Encryption | AES-256 at rest; TLS 1.3 in transit |
| Access Control | Row-level security by tenancy scope; column masking on legal_name for non-privileged roles |
| Retention Enforcement | Soft delete via deleted_at; hard purge job scheduled at retention boundary |
| Replication Target | crm.customer_master (Snowflake) via Change Data Capture — 5-minute SLA |
| SLA | 99.95% availability; p99 write latency < 50ms |
| Business Layer Reference | Customer Domain — Classification: Confidential |
| Logical Layer Reference | Party — Entity Definition Card v2.1 |
| Last Schema Review | [Date] |
| Breaking Change Protocol | Any column removal or type change requires logical layer review and business layer impact assessment |
The last three rows are the bindings.
They are what make the physical layer governable.
Without them, a schema is an implementation detail.
With them, it is a physical expression of a governed design.
What the Physical Layer Decides
- Which storage technology implements each logical entity
- What partitioning and indexing strategy applies at the current data volume
- What encryption, access control, and masking is applied at the storage level
- What replication or synchronisation exists between physical representations
- What the SLA is and how it is measured
The physical layer does not decide what the data means.
That was settled in the business layer.
The physical layer does not decide how the data is structured.
That was settled in the logical layer.
The physical layer decides how to build what was already designed.
The Full LDA Model
%% caption: The full LDA model: the artifacts that make up the business, logical and physical layers
flowchart TD
subgraph Business["Business Layer — Intent"]
B1["Data Domain Register"]
B2["Ownership + Stewardship Map"]
B3["Classification Tiers"]
B4["Regulatory Boundary Register"]
B5["Business Rules Catalogue"]
end
subgraph Logical["Logical Layer — Design"]
L1["Entity Definition Cards"]
L2["Relationship + Contract Model"]
L3["Attribute + Derivation Register"]
L4["Domain Contract Specification"]
L5["Cross-Domain Integration Map"]
end
subgraph Physical["Physical Layer — Implementation"]
P1["Physical Implementation Cards"]
P2["Schema + DDL Register"]
P3["Access Control Matrix"]
P4["Replication + CDC Topology"]
P5["SLA + Observability Specs"]
end
Business -- "Logical Binding\n(domain-to-entity)" --> Logical
Logical -- "Physical Binding\n(entity-to-schema)" --> Physical
Physical -- "Traceability\n(schema-to-business-intent)" --> Business
Every artefact in the business layer connects to one or more artefacts in the logical layer.
Every artefact in the logical layer connects to one or more artefacts in the physical layer.
Every physical artefact can trace its lineage back to the business intent it was built to serve.
That is not documentation.
That is architecture.
The Binding Contracts
LDA works because of three explicit binding contracts.
Not because of good intentions.
Not because of documentation standards.
Because of named, enforced contracts between the layers.
Binding 1: Domain-to-Entity (Business → Logical)
Every data domain in the business layer must reference the logical entities that implement it.
Every logical entity must reference the business domain it belongs to.
When the domain changes — a new regulation, a reclassification, a new ownership model — the entity cards surface immediately.
The contract rule:
No logical entity may exist without a business domain reference. No business domain may change without triggering a logical layer impact review.
Binding 2: Entity-to-Schema (Logical → Physical)
Every logical entity must reference the physical objects that implement it.
Every physical object must reference the logical entity it was built from.
When an entity contract changes — a new uniqueness rule, a new relationship, a removed attribute — the physical implementations surface immediately.
The contract rule:
No physical schema may be created without a logical entity reference. No logical entity may change without triggering a physical layer impact review. Breaking changes require a governance gate.
Binding 3: Schema-to-Intent (Physical → Business)
Every physical implementation must be able to trace — in a single lookup — to the business intent that governs it.
When a platform engineer asks "why does this column exist and why is it encrypted," the answer should be visible from the physical layer.
The contract rule:
No physical implementation may be deployed without classification tier and business domain visible in the implementation card. Traceability is a deployment gate, not a documentation afterthought.
How Disconnection Accumulates Without LDA
Without binding contracts between layers, the same pattern emerges in every enterprise.
%% caption: Without LDA, a business rule change never reaches the physical estate; with LDA, the bindings carry it through
flowchart LR
subgraph Without_LDA["Without LDA"]
direction TB
A1[Business rule changes] --> B1[No logical entity linked]
B1 --> C1[No physical schemas notified]
C1 --> D1[Physical estate drifts from intent]
D1 --> E1[Regulatory audit finds misalignment]
E1 --> F1[Emergency remediation costs 10x the governance cost]
end
subgraph With_LDA["With LDA"]
direction TB
A2[Business rule changes] --> B2[Domain-to-entity binding surfaces impact]
B2 --> C2[Logical entity review triggered]
C2 --> D2[Entity-to-schema binding surfaces physical impact]
D2 --> E2[Physical schema updated with governance gate]
E2 --> F2[Physical estate stays aligned to intent]
end
The failure mode is always the same.
Not a sudden collapse.
A slow, quiet drift.
Until a regulator, an incident, or a migration reveals that the physical estate describes something nobody designed.
When LDA Is Absent: What Breaks
When layers are disconnected:
- A GDPR deletion request arrives. Nobody knows which physical tables hold the affected data because there is no entity-to-schema binding.
- A logical schema is refactored. Three physical pipelines break silently because there is no entity-to-schema traceability.
- A new regulation changes a retention rule. Nobody knows which domains it applies to because there is no business rule linked to physical enforcement.
- A cloud migration is proposed. The impact assessment takes months because nobody can trace physical objects back to logical intent.
- An audit asks for data lineage. The exercise takes quarters because the layers have never been connected.
When LDA is respected:
- A deletion request produces an immediate list of physical tables via the entity-to-schema binding.
- A logical schema change triggers an automated impact review of all physical implementations.
- A regulation change surfaces the affected domains, entities, and schemas in a single query.
- A cloud migration scope is assessable in days, not months.
- Lineage exists because it was built into the architecture, not assembled as a remediation exercise.
The difference is not discipline.
It is structure.
Implementation Guide (30–60 Days)
Introducing LDA does not require replacing existing artefacts.
It requires connecting them.
The goal in the first 60 days is not a complete data architecture.
It is one domain, traced through all three layers, with binding contracts in place.
Phase 1: Layer Inventory (Weeks 1–2)
Objective: Find what already exists in each layer and identify what is missing.
Activities:
- Inventory existing business-layer artefacts: data dictionaries, ownership registers, classification schemes
- Inventory existing logical artefacts: entity models, schema documents, domain diagrams
- Inventory existing physical artefacts: database schemas, DDL scripts, platform specs
- For each artefact, ask: what layer does this belong to, and what does it connect to?
Deliverable: Three-layer artefact inventory with connection gaps identified
Success Metric: At least one complete domain identified where all three layers have existing artefacts — even if unconnected
Phase 2: Binding Contract Definition (Weeks 3–4)
Objective: Build the connections for the pilot domain.
Activities:
- Select the highest-risk or most-regulated data domain as the pilot
- Complete the Business Layer Template for that domain
- Produce Entity Definition Cards for every logical entity in that domain
- Produce Physical Implementation Cards for every physical object implementing those entities
- Establish the three binding contracts explicitly: domain-to-entity, entity-to-schema, schema-to-intent
Deliverable: Fully connected LDA model for the pilot domain — all three layers, all three binding contracts
Success Metric: Any physical object in the pilot domain can be traced to its business intent in under five minutes
Phase 3: Governance Integration (Weeks 5–8)
Objective: Embed LDA into the architecture lifecycle.
Activities:
- Add binding contract completeness to architecture review checklists
- Require entity-to-schema binding as a deployment gate for new physical schemas
- Require domain-to-entity binding as a condition for business layer changes
- Extend the LDA model to two additional domains
- Train data architects and platform engineers on binding contract discipline
Deliverable: LDA model active for three domains; binding contracts embedded in architecture and deployment review
Success Metric: No new physical schema enters production without a logical entity reference and classification tier
Evidence from Practice
A telecommunications company I worked with had three separate data teams — business intelligence, data engineering, and analytics — each maintaining their own copy of customer data. The business layer (what data means), logical layer (how data is structured), and physical layer (where data lives) had never been mapped to each other. A regulatory audit revealed that nobody could trace a single customer data element from the source system to the executive dashboard.
We introduced the Layered Data Authority (LDA) model with binding contracts between layers. Each layer defined its outputs and dependencies — the business layer specified what "customer" means, the logical layer defined how customer data is structured, and the physical layer mapped where customer data resides. The traceability gap was closed in six weeks. The audit passed on the first review.
Action Plan
This Week
Ask three questions across your current data estate:
- If a regulation required deletion of all data belonging to a specific customer, how long would it take to identify every physical object that holds it — and could you answer that question today?
- If the definition of a core entity in your logical model changed — a new uniqueness rule, a removed attribute — which physical schemas would break, and does your architecture tell you?
- If a regulator asked you to trace a specific column in your production database back to the business rule that justified its existence, could you do it in under an hour?
If the answers are uncertain, the three layers are operating as three islands.
Next 30 Days
Apply the LDA model to one domain:
- Complete the Business Layer Template
- Produce Entity Definition Cards for all logical entities in that domain
- Produce Physical Implementation Cards for all physical objects in that domain
- Establish the three binding contracts explicitly
Start with the domain that carries the highest regulatory, compliance, or operational risk.
3–6 Months
Extend LDA across the data estate:
- Include LDA layer completeness and binding contract review in every new data architecture review
- Require physical implementation cards as a deployment artefact, not a documentation afterthought
- Build binding contract traceability into your data catalogue tooling
- Audit binding contracts quarterly as domains evolve
Final Thought
The CFO asked: who owns this data and what governs it?
The architect asked: how is it structured and how does it relate?
The engineer asked: where does it live and how is it built?
Three correct questions.
All of them deserve an answer.
And the answers should point to each other.
That is not documentation.
That is not governance overhead.
That is what it means to have an architecture rather than three separate descriptions of the same thing.
Without the bindings, you have three islands that produce three post-incident discoveries.
With the bindings, you have one estate that can be governed, traced, and changed without surprise.
The framework was always three layers.
The part nobody finished was the connections.
Build an Architecture Your Three Teams Can All Trust
If your business layer is a register nobody reviews…
if your logical entities have never been traced to physical schemas…
or if your physical estate is the only document that accurately describes what you have built —
the gap is not a tooling problem.
It is a structural disconnection between intent, design, and implementation.
In a focused 30-minute Enterprise Data Architecture Diagnostic, we will:
- Identify which layers of your data architecture exist, which are missing, and which are connected
- Apply the LDA binding contract model to your highest-risk data domain
- Define the minimum artefact set needed to make your estate traceable end-to-end
- Build a 30-day plan to connect your existing layers without starting from scratch
No three-year data strategy.
No enterprise data catalogue procurement.
No architecture theatre that produces diagrams nobody maintains.
Just the structural connections that make three layers into one governable estate.
→ Book a Data Architecture Diagnostic
or
The layers were never the problem.
The missing bridges were.
