Integration Architecture
Data Mesh Working Skill
Turn centralized data bottlenecks into domain-owned data products with clear contracts, discoverable interfaces, and federated governance that works in SAP and mixed landscapes.
What this skill is for
This skill helps you identify domains in an enterprise landscape, define data products with clear output ports and ownership, assign data product owners, establish lightweight federated governance, and choose integration patterns that connect domains without recentralizing everything into a single warehouse team.
When to use this skill
- Central data warehouse or IT team is a bottleneck for domain analytics needs.
- Domain teams cannot access their own data without a three-week ticket to a central team.
- New analytics requirements cross multiple SAP modules and no one owns the cross-module view.
- Master data centralization is causing delays and quality disputes.
- You need to expose SAP domain data to external consumers with clear contracts and SLAs.
- A data lake project is becoming a data swamp because ownership and schema are undefined.
Real work situations
Situation 1: Finance team waits three weeks for a new warehouse field
The central data warehouse team owns all ETL and schema changes. When Finance needs a new field from SAP for a regulatory report, the request sits in a backlog. Finance starts building shadow spreadsheets. The data becomes inconsistent.
Situation 2: Cross-module analytics with no owner
Analytics needs order data from SD, inventory from MM, and production status from PP. Each module team owns its application but no one owns the integrated data product. Reports are built ad hoc and break when any module upgrades.
Situation 3: Domain team wants to expose data but lacks contract skills
The procurement team knows their data and wants to expose a supplier performance data product. They do not know how to define an output port, schema, or SLA. IT offers a generic extract, which lacks quality guarantees and consumer support.
Inputs required
- Domain map: business domains and their boundaries.
- Existing data landscape: warehouses, lakes, marts, SAP modules, external systems.
- Data product candidates: reports, APIs, events, files that domains already produce or need.
- Current ownership model: who owns data quality today.
- Integration capabilities: middleware, API management, event brokers, CDC tools.
- Governance framework: existing standards for security, privacy, quality.
- Consumer list: who uses data from each domain today.
Questions to ask
- Which domain is the authoritative source for this data?
- What is the data product's output port: API, event stream, file, or analytical model?
- Who owns the quality, schema, and SLA of this data product?
- How do consumers discover that this data product exists?
- What is the SLA for data freshness, and how is it measured?
- How is access controlled: role-based, attribute-based, or consumer-specific?
- What happens when the source schema changes?
- Is this data product reusable, or is it a one-off extract?
Working method
- Identify domains. Map business domains based on organizational boundaries, data ownership, and process autonomy. Avoid purely technical boundaries.
- Map data products per domain. For each domain, list data it produces that other domains or systems consume. Name each data product clearly.
- Define output ports. For each data product, specify the interface: synchronous API, event stream, batch file, or analytical export. Match the port to consumer needs.
- Assign ownership. Name a business owner (quality, semantics) and a technical owner (schema, infrastructure, SLA) for each data product.
- Create a data product catalog. Register each product with name, owner, description, output ports, schema location, SLA, and consumer onboarding path.
- Define consumer onboarding. Document how a new consumer requests access, what compatibility checks are required, and how schema changes are communicated.
- Establish federated governance. Define lightweight standards: naming conventions, schema versioning, access control patterns, quality minimums. Do not create a central committee for every decision.
- Validate with a pilot consumer. Have one domain publish a data product and one consumer subscribe. Measure freshness, quality, and onboarding friction. Fix before scaling.
Decision rules
- If data is used only within one domain, keep it internal; do not publish as a data product.
- If data is consumed by two or more domains, publish it as a data product with a defined output port.
- If freshness requirement is under one hour, use an event or API; if batch is acceptable, use a scheduled extract.
- If no domain owner exists, assign one before publishing; unowned data products become swamps.
- If governance is missing, start with lightweight standards and a small governance group, not a large committee.
- If SAP is the source, respect SAP licensing and data model constraints; do not expose raw tables directly.
- If a data product has no consumers after six months, deprecate it.
- If a consumer needs a cross-domain view, create a consumer-specific analytical model that references domain data products, not a new central warehouse.
Deliverables
- Domain Map — Domains, boundaries, and data product candidates.
- Data Product Definitions — One per product: owner, output ports, schema, SLA. See template below.
- Data Product Catalog — Discoverable registry of all products.
- Ownership Matrix — Business and technical owners per product. Link to Interface Ownership Matrix template.
- Integration Pattern Decisions — ADR for how each product connects to consumers.
Templates
Data Product Definition
---
artifact: Data Product Definition
id: DP-001
status: draft | published | deprecated
---
## Data product name
## Domain
## Description
## Owner
## Output ports
| Port | Type | Interface | SLA | Consumers |
|------|------|-----------|-----|-----------|
| API | Synchronous | REST / OData | p99 < 500ms | CRM, Portal |
| Event stream | Asynchronous | Kafka topic | < 5 min lag | Analytics |
| Batch export | Scheduled | Parquet to S3 | Daily 06:00 | Data science |
## Schema
## Quality SLAs
| Metric | Target | Measurement |
|--------|--------|-------------|
| Completeness | > 99.5% | Daily audit |
| Freshness | < 1 hour | Last update timestamp |
| Accuracy | Zero known defects | Monthly review |
## Access control
## Consumer onboarding
## Change process
## Deprecation policy
Quality checklist
- Every data product has a named business owner and technical owner.
- Output port is defined with interface type and SLA.
- Schema is documented and versioned.
- Consumer onboarding path is documented and tested.
- Quality SLAs are stated and measurable.
- Access control is defined.
- Change process is documented.
- Data product is registered in the catalog.
Common mistakes
- Mistake: Treating data mesh as a technology project. Consequence: The organization buys a data catalog and Kafka but keeps central IT ownership; nothing changes.
- Mistake: Centralizing governance instead of federating it. Consequence: Domain teams still wait for committee approval, recreating the bottleneck.
- Mistake: Publishing data without ownership. Consequence: Schema changes break consumers and no one is accountable.
- Mistake: Ignoring SAP-specific constraints. Consequence: Licensing violations, exposed internal data models, or unsupported direct table access.
- Mistake: Creating a data product for every table. Consequence: Catalog noise, low-quality products, and consumer confusion.
Agent instructions
- Gather context first: Collect the domain map, existing data landscape, and current ownership model before proposing data products.
- Focus on ownership and contracts, not tools: Do not recommend technology before ownership is clear.
- Produce artifacts: Generate a Domain Map and at least one Data Product Definition. Do not stop at conceptual recommendations.
- Avoid generic language: Do not write "data mesh decentralizes data ownership." Write "Assign the Procurement domain owner for the SupplierPerformance data product."
- Handle missing information: If domain boundaries are unclear, propose boundaries based on existing org structure and process ownership, flagging them as assumptions.
- Link to Atlas: Reference Data Mesh for SAP Landscapes for SAP-specific constraints and Data Contracts for contract design.
Related skills
- Interface Ownership — Assign owners to data product output ports.
- API Integration — Design synchronous output ports.
- Data Lineage — Trace data product origins.
- Data Integration and Interoperability — Cross-domain data flow patterns.
Related Atlas pages
- Data Mesh for SAP Landscapes — SAP-specific application.
- Data Contracts — Contract design for data products.
- CDC (Change Data Capture) — Event-based data product emission.
- Integration Ownership Model — Ownership patterns.
Verification status and limitations
This skill is a public working interpretation of data mesh practice. It is not official DAMA, Zhamak Dehghani, or SAP documentation. It simplifies federated governance for operational applicability. SAP-specific guidance respects common licensing and data model constraints but does not replace legal or contractual review. Use this skill as a structured starting point, not as an authoritative framework substitute.