Workload profile
Classify the workloads by latency, volume, sensitivity and concurrency before naming any technology.
Done when: Every workload has a latency and sensitivity class on record.
Data Platform Architecture Framework (DPA)
Data Platform Architecture Framework
A decision path from source to serving layer, with the trade-off written down before the build starts.
The business problem
The platform grew by accident. Now it costs by design.
Warehouses, lakes and tools pile up, each project adds another copy, and nobody can say which architecture is the target.
What you hear inside the organisation
Should we move to Fabric, Databricks or stay?
Cloud costs doubled and we do not know why.
We have five copies of the same data.
Can sensitive data stay in Saudi Arabia?
Who it serves and what changes
Your teams, before and after the Data Platform Architecture Framework
Client teams and what they need
Enterprise architecture
A target architecture with principles
Data engineering
Standard patterns to build with
Finance and procurement
Predictable platform cost
Security
Residency and access by design
The outcome you get
- A target architecture and decision record
- Medallion layers from raw to business-ready
- A cost model and retirement plan for duplicates
- Residency and security patterns built in
A worked example
A logistics company with growing cloud bills
The problem we saw
Each project had built its own data copy. Costs rose and nobody could say which platform was the target.
How the framework solved it
We wrote the target architecture and the trade-offs behind it, set raw to business-ready layers, and planned retiring duplicates.
The business result
Teams build on one platform, duplicate copies are switched off, and platform cost is planned rather than discovered.
Illustrative example based on common client situations.
In short
What is the Data Platform Architecture Framework?
Data Platform Architecture Framework (DPA): A decision path from source to serving layer, with the trade-off written down before the build starts.
Most platform debt comes from decisions taken implicitly: batch or stream, lakehouse or warehouse, central or mesh, buy or build.
- How it moves
- Each step closes with a check before the next begins
- Owned by
- Run by data architecture and platform engineering; signed off by the architecture review body.
- You keep
- Target architecture, Layer and promotion standard, Unit cost model
How it works
How the Data Platform Architecture Framework works
A platform is judged by the second workload, not the first. If workload two does not reuse the layers, the design has not landed.
Reference decision
Choose the pattern, lakehouse, warehouse, mesh, or a hybrid, against written criteria.
Done when: The rejected options are documented with the reason for rejection.
Layer design
Define the raw, conformed and serving layers with the promotion rule between them.
Done when: Nothing is promoted between layers without a passing contract test.
Cost & controls
Attach the unit cost model, access controls, residency choice and retention rule to each layer.
Done when: A cost per governed workload can be produced on request.
Governed slice
Build one end-to-end slice through every layer before widening the platform.
Done when: The slice runs in production with monitoring, cost visibility and a rollback path.
Is it right for you?
Is the Data Platform Architecture Framework right for you?
A strong fit if
- You face a platform choice or migration
- Platform costs are rising without clear value
- Data is copied across many tools
Probably not yet if
- Your platform is recent and fit for purpose
- You only need a single dashboard
Free assessment
Discuss the Data Platform Architecture Framework with our team
A working session with our senior team. We review what fits your situation, what does not, and where to start.
A focused conversation
We listen to your situation and goals.
Fit review
Which parts of this framework apply to you, and which do not.
A written view
Clear next steps, whether or not you work with us.
Go deeper
Applying the Data Platform Architecture Framework in practice
Open only the part you need: how it starts, what your team keeps, maturity levels, sector rules and the evidence a reviewer will ask for.
Most platform debt comes from decisions taken implicitly: batch or stream, lakehouse or warehouse, central or mesh, buy or build. DPA forces each decision into the open with the criteria, the cost consequence and the exit condition attached.
Version
v1.0
Last reviewed
August 2026
Family
Data & Analytics Operating System
How this was developed: Built from delivery practice on Saudi and international engagements, then reconciled clause by clause against the published standards below. Revised when a standard is updated or a gate proves unworkable in the field.
Target architecture
Diagrams plus the decision records that justify each choice.
Layer and promotion standard
What each layer holds and what must pass to leave it.
Unit cost model
Cost per governed workload, visible before the platform scales.
Banking & finance
Segregation between production and analytical estates, and immutable audit trails per layer.
- Who reviews it
- SAMA, plus PDPL and NCA controls
- Systems in scope
- Core banking, cards, KYC and AML systems, credit bureau feeds, the general ledger
- Where it lands first
- KYC and AML review, credit decisioning support, complaint and dispute handling
1
Workload profile
- Workload matrix
- Data classification map
2
Reference decision
- Architecture decision records
- Trade-off table
3
Layer design
- Layer specification
- Promotion rules
- Naming standard
4
Cost & controls
- Unit cost model
- Access control matrix
5
Governed slice
- Running slice
- Runbook
- Cost dashboard
A platform is judged by the second workload, not the first. If workload two does not reuse the layers, the design has not landed.
Stage
Exit gate
Artefacts
1
Workload profile
Classify the workloads by latency, volume, sensitivity and concurrency before naming any technology.
Exit gate
Every workload has a latency and sensitivity class on record.
Artefacts
- Workload matrix
- Data classification map
2
Reference decision
Choose the pattern, lakehouse, warehouse, mesh, or a hybrid, against written criteria.
Exit gate
The rejected options are documented with the reason for rejection.
Artefacts
- Architecture decision records
- Trade-off table
3
Layer design
Define the raw, conformed and serving layers with the promotion rule between them.
Exit gate
Nothing is promoted between layers without a passing contract test.
Artefacts
- Layer specification
- Promotion rules
- Naming standard
4
Cost & controls
Attach the unit cost model, access controls, residency choice and retention rule to each layer.
Exit gate
A cost per governed workload can be produced on request.
Artefacts
- Unit cost model
- Access control matrix
5
Governed slice
Build one end-to-end slice through every layer before widening the platform.
Exit gate
The slice runs in production with monitoring, cost visibility and a rollback path.
Artefacts
- Running slice
- Runbook
- Cost dashboard
Standard
What this framework satisfies
DAMA / DCAM
Data architecture, integration and storage knowledge areas.
NCA
Segmentation, access control and logging controls applied per layer.
PDPL
Residency, minimisation and retention decided at design time, not after launch.
NDMO
Architecture and interoperability specifications evidenced in the decision records.
Tool first, workload later
The platform is bought, then workloads are bent to fit it. Profile the workloads before the shortlist.
Everything in real time
Streaming every feed multiplies cost for decisions taken weekly. Match latency to the decision.
A mesh with no contracts
Decentralising ownership without enforced contracts produces silos with a new name.
Built on
- 1
DAMA-DMBOK and EDM Council DCAM
Data management knowledge areas and capability assessment.
- 2
NCA Essential and Cloud Cybersecurity Controls
National Cybersecurity Authority control catalogues.
- 3
Personal Data Protection Law (PDPL) and its implementing regulations
Lawful basis, subject rights, transfer and retention.
- 4
NDMO data management and personal data protection standards
National Data Management Office specifications and domains.
Citations describe the parts of each standard the framework answers. Bilytica is not an accreditation or certification body.
In Saudi Arabia
The data layer, as NDMO reads it
Most AI programmes in Saudi Arabia stall underneath the model. These frameworks work on that layer, against the control set the national office actually assesses.
AuthorityWhat it requiresWhat we buildWhat you keep
NDMO data management controls
Owners, policies and measurable maturity across every data management domain.
Baseline assessment, then control-by-control remediation with dates and owners.
Maturity baseline and a re-assessment on the same control set.
SDAIA, PDPL
Classification and retention applied to personal data wherever it is copied.
Classification enforced in the platform, so a copy inherits the rules of its source.
Lineage view showing classification travelling with the data.
ZATCA, for invoicing and transactional data
Invoice and transaction records reconcile to the filed position.
Reconciliation checks run as data quality rules, with exceptions routed to an owner.
Reconciliation report and an exception log with resolution times.
Where it runs
Registers, lineage and quality evidence live in your environment inside Saudi Arabia and stay yours.
Arabic, as it is spoken here
Business glossaries are maintained in Arabic and English together, with Arabic as the governing definition.
FAQ
Frequently Asked Questions
Are you tied to a specific platform vendor?
No. The framework produces criteria and decision records; the same path can land on different platforms, including in-country hosting.
Where does the data foundation work fit?
DPA decides the layers; the Data Foundation Framework certifies the domains that run through them.
How long before something is usable?
The governed slice is the first usable output, and it is deliberately narrow, one domain, one serving path.
Where this connects
Rest of the library
DFFData Foundation FrameworkAIRMAI Readiness ModelVALUEAI Value FrameworkTRUSTAI Assurance FrameworkDELIVERAI Delivery FrameworkAGENTAgent Operations FrameworkSOVEREIGNSovereign AI FrameworkDMMData Management Maturity ModelDQFData Quality & Observability FrameworkDECIDEAnalytics & Decision FrameworkDGOVData Governance Operating ModelSDCFSaudi Data Compliance FrameworkAQSArabic Quality StandardKSA-READYIn-country Deployment Framework
Topic cluster
Explore the topic cluster
Curated links across our Saudi hubs, sector pages and long-form blog research.