EDP Capability Architecture¶

An enterprise data platform is not just a storage and transformation stack. It is a governed capability system with explicit operational, control, and service responsibilities.

Executive Summary¶

• An EDP must deliver 7 distinct capability groups spanning acquisition, management, processing, storage, access, governance, and observability
• Capabilities are durable design concerns. Components (tools, products, services) are replaceable implementations of those capabilities.
• Most platform failures are not technology failures. They are capability gaps -- missing lineage, absent quality controls, no reprocessing path, no cost visibility.
• This model works as a gap assessment, vendor evaluation framework, team structure blueprint, and maturity scorecard.
• If you cannot name the component that delivers a capability, you have a gap. If you have a component but no one owns it, you have a risk.

graph TB
    subgraph "Data Acquisition"
        A1[Batch] --- A2[CDC] --- A3[Events] --- A4[Files] --- A5[3rd Party]
    end
    subgraph "Data Management"
        M1[Schema] --- M2[Metadata] --- M3[Lineage] --- M4[Quality] --- M5[Historization]
    end
    subgraph "Core Processing"
        P1[Transform] --- P2[Orchestrate] --- P3[Execute] --- P4[Isolate] --- P5[Reprocess]
    end
    subgraph "Storage and Modeling"
        S1[Raw Zone] --- S2[Curated Zone] --- S3[Semantic Layer] --- S4[History] --- S5[Serving]
    end
    subgraph "Access and Consumption"
        C1[BI] --- C2[Self-Service] --- C3[APIs] --- C4[ML Features] --- C5[Export]
    end
    subgraph "Governance and Control"
        G1[Access] --- G2[Masking] --- G3[Audit] --- G4[Contracts] --- G5[Policy]
    end
    subgraph "Observability"
        O1[Freshness] --- O2[Pipelines] --- O3[Cost] --- O4[SLAs] --- O5[Incidents]
    end

    A1 -.-> M1
    M1 -.-> P1
    P1 -.-> S1
    S1 -.-> C1
    C1 -.-> G1
    G1 -.-> O1

The Capability Model¶

Seven capability groups. Each group contains sub-capabilities with a single responsibility. Every sub-capability must have an owner, an implementation, and a measurable outcome.

1. Data Acquisition¶

2. Data Management¶

3. Core Platform Processing¶

4. Storage and Modeling¶

5. Access and Consumption¶

6. Governance and Control¶

7. Observability and Platform Operations¶

Capabilities vs Components¶

A capability is what the platform must do. A component is one way to do it. Confusing the two is how platforms end up locked to a vendor with no understanding of what they actually need.

Capabilities are durable. Components change. Design for the capability, select the component.

How to Use This Model¶

Gap assessment. Walk through all 7 groups and 35+ sub-capabilities. For each one, name the component that delivers it. If you cannot, you have a gap. Gaps do not fix themselves.

Vendor evaluation. When evaluating a platform vendor or tool, map their feature set to these capabilities. Most vendors cover 3-4 groups well and leave the rest to you. Know what you are buying and what you still need to build or integrate.

Team structure. Each capability group suggests a team ownership boundary. Data acquisition is not the same team as governance. Observability is not the same team as transformation. Align teams to capability groups, not to tools.

Maturity assessment. For each sub-capability, score your current state: (0) absent, (1) manual/ad-hoc, (2) partially automated, (3) fully automated with monitoring. The distribution tells you where to invest. A platform that scores 3 on transformation but 0 on lineage is not mature -- it is blind.