Data mesh readiness assessment and strategy using Zhamak Dehghani's 4 principles. Use when the user asks to "assess data mesh readiness", "design data mesh strategy", "domain data ownership", "data as a product", "self-serve data platform", "federated data governance", "data mesh migration", or mentions "data decentralization", "data domain ownership", "data product thinking".
Generates data mesh readiness assessment and adoption strategy based on Zhamak Dehghani's 4 foundational principles: domain ownership, data as a product, self-serve data platform, and federated computational governance. Produces readiness scorecard, domain decomposition map, data product catalog design, platform requirements, and phased adoption roadmap.
Data mesh is not a technical architecture — it is an organizational model for data. If the organization cannot decentralize decisions, it cannot decentralize data.
$1 — Path to data architecture analysis (AS-IS, data flows, data governance assessment)$2 — Assessment scope: full (default), readiness (assessment only), pilot (single domain design)Parse from $ARGUMENTS.
Parameters:
{MODO}: piloto-auto (default) | desatendido | supervisado | paso-a-paso{FORMATO}: markdown (default) | html | dual{MODO_OPERACIONAL}: readiness (default, assessment against 4 principles) | estrategia (full mesh strategy with roadmap) | dominio (single domain pilot design){VARIANTE}: ejecutiva (~40% — readiness scores + recommendation) | técnica (full, default)Mandatory:
Recommended:
Assumptions:
Cannot do:
| Decision | Enables | Constrains | When to Use |
|---|---|---|---|
| Readiness assessment | Clear go/no-go signal | No implementation plan | Early discovery, Phase 1 |
| Full strategy | Complete roadmap, platform spec | 5-7 days, requires deep domain knowledge | Committed to data mesh |
| Single domain pilot | Low risk, fast learning | Limited scope, may not generalize | Testing mesh viability |
Per principle, score 1-5 with evidence:
| Principle | Assessment Questions | Score |
|---|---|---|
| Domain Ownership | Are business domains clearly defined? Do teams own their data? Is there domain expertise for data quality? | |
| Data as a Product | Can teams treat data outputs as products? Are there SLAs for data? Is there a product mindset for data? | |
| Self-Serve Platform | Is there infrastructure for teams to publish/consume independently? Can domains deploy data products without central team? | |
| Federated Governance | Can governance be distributed without losing compliance? Are there global standards that domains can implement locally? |
Composite readiness score. Go/No-Go recommendation with conditions.
Business domain identification based on DDD bounded contexts. Per domain: name, description, key data entities, current data ownership, data consumers, data quality responsibility. Domain interaction map.
Data product specification template: name, domain, owner, SLA (freshness, quality, availability), schema, access patterns, consumers, documentation requirements. Data product catalog design.
Quality dimensions per product: accuracy, completeness, timeliness, consistency, uniqueness.
Platform capabilities needed: data product authoring tools, schema registry, data catalog, quality monitoring, access management, lineage tracking, cost allocation. Build vs. buy analysis. Reference architectures per cloud provider.
Global policies (data classification, retention, PII handling, naming conventions). Domain-level implementation (quality gates, access controls, documentation standards). Governance automation (policy-as-code, automated quality checks). Interoperability standards (schema compatibility, API contracts).
Phased approach:
Per phase: domains included, platform capabilities, governance evolution, success metrics, risks.
Team structure changes needed. New roles (data product owner, domain data engineer, platform team). Training requirements. Cultural shift from "data as byproduct" to "data as product." Integration with metodologia-change-readiness-assessment and metodologia-adoption-strategy skills.
| Caso | Estrategia de Manejo |
|---|---|
| Modelo hibrido necesario (no todos los dominios estan listos) | Recomendar mesh para dominios maduros, centralizado para los demas; documentar condiciones de frontera y criterios de transicion |
| Datos regulados (PII, PCI, HIPAA) cruzan dominios | Gobernanza federada debe incluir automatizacion de compliance; equipo central de compliance retiene poder de veto sobre data products sensibles |
| No existe catalogo de datos como prerequisito | Establecer catalogo como paso previo obligatorio; no es posible implementar mesh sin visibilidad de lo que existe |
| Monolito legacy como fuente principal de datos | Aplicar strangler pattern para extraccion de datos; CDC (Change Data Capture) como solucion interim mientras se desacopla |
| Decision | Alternativa Descartada | Justificacion |
|---|---|---|
| Evaluar readiness con los 4 principios de Dehghani antes de proponer estrategia | Asumir que data mesh es la solucion correcta y disenar directamente | Data mesh no es adecuado para todas las organizaciones; la evaluacion de readiness previene inversiones en transformaciones que la organizacion no puede sostener |
| Recomendar piloto de 1-2 dominios antes de adopcion completa | Big-bang migration de todos los dominios simultaneamente | El piloto reduce riesgo, genera aprendizaje, y construye evidencia interna; la migracion completa tiene tasa de fracaso alta |
| Incluir cambio organizacional como seccion mandatoria (S7) | Tratar data mesh como decision puramente tecnica | Data mesh es un modelo organizacional, no una arquitectura tecnica; sin cambio organizacional, la implementacion falla independientemente de la tecnologia |
| Recomendar against data mesh cuando readiness score <2 en >2 principios | Siempre recomendar data mesh cuando el cliente lo solicita | Recomendar una transformacion que la organizacion no puede absorber dania la credibilidad y desperdicia inversion del cliente |
graph TD
subgraph Core["Data Mesh Core"]
A[metodologia-data-mesh-strategy]
A1[S1: Readiness Assessment]
A2[S2: Domain Decomposition]
A3[S3: Data Product Design]
A4[S4: Self-Serve Platform]
A5[S5: Federated Governance]
A6[S6: Adoption Roadmap]
A7[S7: Org Change]
end
subgraph Inputs["Inputs"]
I1[Data Architecture AS-IS]
I2[Organizational Structure]
I3[Data Governance Current State]
end
subgraph Outputs["Outputs"]
O1[Data Mesh Strategy Report]
O2[Readiness Scorecard]
O3[Domain Map + Data Products]
end
subgraph Related["Related Skills"]
R1[metodologia-technical-feasibility]
R2[metodologia-sector-intelligence]
R3[metodologia-software-viability]
R4[metodologia-stakeholder-mapping]
end
I1 --> A
I2 --> A
I3 --> A
A --> A1 --> A2 --> A3 --> A4 --> A5 --> A6 --> A7
A --> O1
A --> O2
A --> O3
R1 --- A
R2 --> A
A --- R3
R4 --- A
Formato MD (default):
# Data Mesh Strategy — {proyecto}
## Resumen Ejecutivo
> Readiness score: X/5. Recomendacion: [Go/No-Go/Conditional]. Dominios piloto: N.
## S1: Readiness Assessment
| Principio | Score (1-5) | Evidencia | Gap |
## S2: Domain Decomposition
```mermaid
mindmap
root((Dominios))
...
gantt
title Data Mesh Adoption
...
**Formato HTML (bajo demanda — Design System MetodologIA v5):**
DataMesh_Strategy_{project}_{WIP}.html
HTML self-contained branded (Design System MetodologIA v5). Dark-First Executive. Incluye readiness radar chart interactivo (4 principios), domain decomposition mindmap, y adoption Gantt faseado. WCAG AA, responsive.
**Formato HTML (para presentacion ejecutiva — legacy):**
Header: Logo + proyecto + readiness score visual Section 1: Readiness Scorecard (radar chart 4 principios) Section 2: Domain Map (mindmap interactivo) Section 3: Data Product Catalog Preview (cards por dominio) Section 4: Platform Requirements (tabla comparativa build vs buy) Section 5: Governance Model (diagrama de flujo) Section 6: Adoption Roadmap (Gantt visual con fases) Section 7: Org Change Requirements (tabla de roles nuevos) Footer: Attribution MetodologIA + fecha
**Formato DOCX (bajo demanda):**
{fase}DataMesh_Strategy{project}_{WIP}.docx
Via python-docx con Design System MetodologIA v5. Cover page, TOC auto, headers/footers branded, tablas zebra. Poppins headings (navy), Montserrat body, gold accents.
**Formato XLSX (bajo demanda):**
- Filename: `{fase}_DataMesh_Strategy_{cliente}_{WIP}.xlsx`
- Via openpyxl con MetodologIA Design System v5. Headers con fondo navy y tipografía Poppins en blanco, conditional formatting por readiness score y principio, auto-filters en todas las columnas, valores directos sin fórmulas.
**Formato PPTX (bajo demanda):**
- Filename: `{fase}_DataMesh_Strategy_{cliente}_{WIP}.pptx`
- Via python-pptx con MetodologIA Design System v5. Navy gradient slide master, Poppins titles, Montserrat body, gold accents. Máx 20 slides ejecutivo / 30 técnico. Speaker notes con referencias de evidencia.
## Evaluacion
| Dimension | Peso | Criterio | Umbral Minimo |
|-----------|------|----------|---------------|
| Trigger Accuracy | 10% | El skill se activa ante prompts de data mesh, domain ownership, data as a product, federated governance | 7/10 |
| Completeness | 25% | Las 7 secciones pobladas; readiness con score por principio; data products con SLAs y dimensiones de calidad | 7/10 |
| Clarity | 20% | Recomendacion go/no-go es binaria y justificada; dominios mapeados a estructura real del negocio | 7/10 |
| Robustness | 20% | Edge cases cubiertos (hibrido, regulado, sin catalogo, legacy); cross-section traceability completa | 7/10 |
| Efficiency | 10% | Modo operacional correcto (readiness/estrategia/dominio) seleccionado; no se genera estrategia completa cuando solo se necesita assessment | 7/10 |
| Value Density | 15% | Cada fase del roadmap tiene criterios de entrada/salida; platform requirements incluyen build-vs-buy; org change es accionable | 7/10 |
**Umbral minimo global: 7/10.** Si alguna dimension cae por debajo, el entregable requiere revision antes de entrega.
## Escalation to Human
- Readiness score <2 on >2 principles (not ready for data mesh)
- No executive sponsor for organizational change
- Regulatory constraints that prevent domain ownership of sensitive data
- Central data team politically opposed to decentralization
- Platform investment >$500K (requires business case beyond this assessment)
## Execution Workflow
1. **Context Ingestion (1-2 hours):** Review AS-IS, data architecture, org structure
2. **Readiness Assessment (3-4 hours):** Score 4 principles, interview-based or artifact-based
3. **Domain & Product Design (4-6 hours):** Decompose domains, define product specs, platform requirements
4. **Strategy & Roadmap (3-4 hours):** Governance model, phased adoption, org change plan
**Typical engagement:** 4-6 days for organizations with 5-15 business domains.
## Output Artifact
**Primary:** `DataMesh_Strategy_{project}.md` (o `.html` si `{FORMATO}=html|dual`) — Full 7-section data mesh strategy with readiness scorecard, domain map, and adoption roadmap.
**Secondary:** `DataMesh_Readiness_{project}.md` — Executive readiness scorecard (S1 + go/no-go recommendation).
**Included diagrams:**
- Mindmap: domain decomposition with data products
- Quadrant chart: domain readiness (maturity × data volume)
- Flowchart: data product lifecycle
- Gantt chart: phased adoption roadmap
## Validation Gate
- [ ] All 7 sections populated with evidence-based content
- [ ] Readiness scored with observable evidence per principle
- [ ] Domain decomposition maps to actual business structure
- [ ] Data product specs include SLAs and quality dimensions
- [ ] Platform requirements include build-vs-buy analysis
- [ ] Governance model balances autonomy with compliance
- [ ] Roadmap is phased with clear entry/exit criteria per phase
- [ ] Cross-section traceability complete
## Output Format Protocol
| Format | Default | Description |
|--------|---------|-------------|
| `markdown` | ✅ | Rich Markdown + Mermaid diagrams. Token-efficient. |
| `html` | On demand | Branded HTML (Design System). Visual impact. |
| `dual` | On demand | Both formats. |
## Operational Modes
| Mode | Focus | Best For |
|---|---|---|
| `readiness` (default) | S1 + go/no-go + conditions | Early discovery, Phase 1 assessment |
| `estrategia` | Full 7-section strategy | Committed to data mesh adoption |
| `dominio` | S2 + S3 deep for 1 domain | Pilot design, proof of concept |
## Additional Resources
### References (Progressive Disclosure — Level 3)
- `Read ${CLAUDE_SKILL_DIR}/references/knowledge-graph.mmd` — Domain knowledge graph
- `Read ${CLAUDE_SKILL_DIR}/references/body-of-knowledge.md` — Academic and industry sources (Dehghani, Fowler, DAMA)
- `Read ${CLAUDE_SKILL_DIR}/references/state-of-the-art.md` — Trends 2024-2026
### Examples
- `Read ${CLAUDE_SKILL_DIR}/examples/sample-output.md` — Golden reference output
- `Read ${CLAUDE_SKILL_DIR}/examples/sample-output.html` — Branded HTML
### Prompts
- `Read ${CLAUDE_SKILL_DIR}/prompts/use-case-prompts.md` — Ready-to-use prompts
- `Read ${CLAUDE_SKILL_DIR}/prompts/metaprompts.md` — Meta-strategies
## Output Configuration
- **Language**: Spanish (Latin American, business register — simple, clear, concise, direct)
- **Attribution**: Expert committee of the MetodologIA Discovery Framework
- **Tagline**: *"Construido por profesionales, potenciado por la red agéntica de MetodologIA."*