Data platform operating model and service ownership
Skill vaquarkhan/data-engineering-agent-skills/skills/data-platform-operating-model-and-service-ownership
Production-grade Agent Skills for data engineering AI agents: 73 workflows, platform presets, safe backfill/replay, Kafka & Spark reliability, MCP observability, and VS Code/JetBrains installers.
npx -y skills add vaquarkhan/data-engineering-agent-skills --skill data-platform-operating-model-and-service-ownershipAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 21 stars21 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Guides agents through data platform operating model and ownership design. Use when defining platform team responsibilities, service tiers, golden paths, escalation boundaries, onboarding flows, or handoffs between central platform teams and domain or product teams.
SKILL.md
3.1 KB, as published. Nobody here has run it
Data Platform Operating Model And Service Ownership
Overview
Use this skill when the hard problem is organizational and operational, not just technical. It helps agents define who owns platform capabilities, how teams onboard safely, what the golden paths are, and how support, escalation, and service boundaries work across a shared data platform.
When to Use
- defining central platform-team responsibilities
- clarifying handoffs between platform and domain teams
- designing golden paths for new datasets, pipelines, or consumer onboarding
- documenting support tiers, ownership, and escalation paths
- reducing operational sprawl and unclear platform accountability
Do not assume a good architecture will operate well if the ownership model is vague.
Workflow
-
Define the service catalog. List:
- supported platform capabilities
- approved golden paths
- self-service versus managed services
- support boundaries and exclusions
-
Assign ownership clearly. Clarify:
- platform-team ownership
- domain-team ownership
- on-call or support expectations
- approval and escalation paths
-
Define onboarding and lifecycle flows. Cover:
- new source intake
- dataset onboarding
- access requests
- incident routing
- deprecation and retirement
-
Define service levels and guardrails. Include:
- support tiers
- change windows where relevant
- escalation expectations
- required contracts, validation, and operational evidence
-
Keep the model reviewable and executable. The operating model should be visible in docs, runbooks, and actual platform workflows, not just organization charts.
Common Rationalizations
| Rationalization | Reality |
|---|---|
| "Everyone owns quality." | Shared responsibility with no explicit owner usually means no one acts quickly enough. |
| "The platform team can handle anything." | Undefined service boundaries create burnout, delays, and unsafe tribal processes. |
| "We can formalize the golden path later." | Without an explicit adoption path, teams create inconsistent local patterns that are harder to govern. |
Red Flags
- support boundaries are vague or tribal
- domain teams and platform teams disagree on who owns incidents or changes
- onboarding depends on undocumented manual steps
- there is no explicit service catalog or golden path
- deprecation and retirement have no owner
Verification
- Platform capabilities and support boundaries are documented
- Ownership and escalation paths are explicit for common workflows
- Golden paths exist for onboarding and routine delivery work
- Service levels and required guardrails are defined
- The operating model is reflected in real workflows, not only in abstract policy