TymeX is onboarding three pods to its tech and processes backbone for Data Mesh in the next six weeks:
- Authentication and Authorisation – Identity, access control, security data products
- MoreTyme – Lending and credit data products
- MCA Asia – Multi-country merchant cash advance analytics
None of these teams have Data Mesh experience. They lack clarity on what data products are, how to build them, and how to work with the platform team.
The CEO expects visible progress within 12 weeks. The CDO wants federated ownership and AI-ready data. Pods are capacity-constrained and overwhelmed.
This plan addresses enablement, experience design, POC execution, and adoption mechanics required to make Data Mesh work at TymeX scale.
Current vs Future State
| Dimension | Current state (my assumption) | Future state |
|---|---|---|
| View of data | Data as by-product | Data as product |
| Ownership | Central teams | Domain teams |
| Meaning | Implicit, inconsistent | Explicit, shared |
| Measures | Embedded in reports | Defined, versioned |
| Contracts | Assumed | Declared and enforced |
| Quality | Detected late | Built-in and monitored |
| Lineage | Fragmented | End-to-end, visible |
| Access | Tool-specific | Standard, self-service |
| Enablement | Playbooks and intent | Repeatable engine |
| Adoption | Hoped for | Measured and managed |
| AI readiness | Bespoke pipelines | Native, reusable |
Relationships Map
The interactive map works best on a PC browser. Mobile browsers display a static image.
TymeX Data Product Anatomy
Definition (multi-modal)
At TymeX, a data product is multi-modal. It is the bundle below, shipped and operated together.
- Bronze / Silver / Gold tables (medallion)
- Metrics and semantic definitions (product KPIs)
- BI assets (dashboards, standard views)
- Event schemas (domain / real-time events)
- AI surfaces (for example MCP server, agents, vector stores / knowledge graphs where relevant)
- Documentation and operations: contract, lineage, quality SLAs, user guide, ownership, support path
Golden Path (Definition of Done)
- 1. Design Owner: DPO
- [x] Consumers and outcomes defined
- [x] Scope and success metrics agreed
- [x] Contract draft outlined
- 2. Ingest Owner: Engineers
- [x] Source access approved
- [x] Bronze tables landed
- [x] Freshness checks added
- 3. Model Owner: Engineers
- [x] Silver and Gold models defined
- [x] Tests and quality checks added
- [x] Performance reviewed
- 4. Metrics Owner: DPO
- [x] KPI definitions agreed
- [x] Semantic layer documented
- [x] Owners assigned
- 5. Publish Owner: Platform
- [x] Contract approved and versioned
- [x] Lineage captured end-to-end
- [x] Catalog entry published
- 6. Discover Owner: Steward
- [x] Search tags and trust signals set
- [x] Access path documented
- [x] Usage guidance added
- 7. Consume Owner: Engineers
- [x] Reuse pattern shared
- [x] BI or API access verified
- [x] Consumer feedback captured
- 8. Operate Owner: Platform
- [x] SLA monitoring live
- [x] Support path published
- [x] Incident runbook ready
Worked Example (Auth & Authorisation pod, first release)
- Purpose and consumers: Secure identity posture for Security, Fraud, and Compliance teams.
- Data assets: Bronze auth logs; Silver sessions and devices; Gold daily access risk summary. Key entities: user, session, device, role, permission.
- Metrics: MFA success rate, auth failure rate, privileged access count, time-to-revoke, dormant admin accounts.
- BI outputs: Identity posture dashboard; weekly access anomalies report.
- Events: user_logged_in, access_granted, privilege_changed.
- AI-ready surfaces: Now: curated features table for anomaly detection. Later wave: graph of users-roles-permissions and agent-ready policy index.
- Docs and ops: Contract v1, lineage captured in catalog, SLA freshness daily, support path in #mesh-auth-support.