data-platform-operating-model-and-service-ownership

Name: data-platform-operating-model-and-service-ownership
Author: vaquarkhan

19stars4forks

How to install data-platform-operating-model-and-service-ownership?

vaquarkhan/data-engineering-agent-skills/data-platform-operating-model-and-service-ownership

$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill data-platform-operating-model-and-service-ownership

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	# Data Platform Operating Model And Service Ownership
2
3	## Overview
4
5	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.
6
7	## When to Use
8
9	- defining central platform-team responsibilities
10	- clarifying handoffs between platform and domain teams
11	- designing golden paths for new datasets, pipelines, or consumer onboarding
12	- documenting support tiers, ownership, and escalation paths
13	- reducing operational sprawl and unclear platform accountability
14
15	Do not assume a good architecture will operate well if the ownership model is vague.
16
17	## Workflow
18
19	1. Define the service catalog.
20	List:
21	- supported platform capabilities
22	- approved golden paths
23	- self-service versus managed services
24	- support boundaries and exclusions
25
26	2. Assign ownership clearly.
27	Clarify:
28	- platform-team ownership
29	- domain-team ownership
30	- on-call or support expectations
31	- approval and escalation paths
32
33	3. Define onboarding and lifecycle flows.
34	Cover:
35	- new source intake
36	- dataset onboarding
37	- access requests
38	- incident routing
39	- deprecation and retirement
40
41	4. Define service levels and guardrails.
42	Include:
43	- support tiers
44	- change windows where relevant
45	- escalation expectations
46	- required contracts, validation, and operational evidence
47
48	5. Keep the model reviewable and executable.
49	The operating model should be visible in docs, runbooks, and actual platform workflows, not just organization charts.
50
51	## Common Rationalizations
52
53	\| Rationalization \| Reality \|
54	\| --- \| --- \|
55	\| "Everyone owns quality." \| Shared responsibility with no explicit owner usually means no one acts quickly enough. \|
56	\| "The platform team can handle anything." \| Undefined service boundaries create burnout, delays, and unsafe tribal processes. \|
57	\| "We can formalize the golden path later." \| Without an explicit adoption path, teams create inconsistent local patterns that are harder to govern. \|
58
59	## Red Flags
60
61	- support boundaries are vague or tribal
62	- domain teams and platform teams disagree on who owns incidents or changes
63	- onboarding depends on undocumented manual steps
64	- there is no explicit service catalog or golden path
65	- deprecation and retirement have no owner
66
67	## Verification
68
69	- [ ] Platform capabilities and support boundaries are documented
70	- [ ] Ownership and escalation paths are explicit for common workflows
71	- [ ] Golden paths exist for onboarding and routine delivery work
72	- [ ] Service levels and required guardrails are defined
73	- [ ] The operating model is reflected in real workflows, not only in abstract policy

People who liked this also viewed

6 picks

Type

data-platform-operating-model-and-service-ownership

19stars4forks

View on GitHub

How to install data-platform-operating-model-and-service-ownership?

vaquarkhan/data-engineering-agent-skills/data-platform-operating-model-and-service-ownership

$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill data-platform-operating-model-and-service-ownership

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Data Platform Operating Model And Service Ownership
2
3	## Overview
4
5	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.
6
7	## When to Use
8
9	- defining central platform-team responsibilities
10	- clarifying handoffs between platform and domain teams
11	- designing golden paths for new datasets, pipelines, or consumer onboarding
12	- documenting support tiers, ownership, and escalation paths
13	- reducing operational sprawl and unclear platform accountability
14
15	Do not assume a good architecture will operate well if the ownership model is vague.
16
17	## Workflow
18
19	1. Define the service catalog.
20	List:
21	- supported platform capabilities
22	- approved golden paths
23	- self-service versus managed services
24	- support boundaries and exclusions
25
26	2. Assign ownership clearly.
27	Clarify:
28	- platform-team ownership
29	- domain-team ownership
30	- on-call or support expectations
31	- approval and escalation paths
32
33	3. Define onboarding and lifecycle flows.
34	Cover:
35	- new source intake
36	- dataset onboarding
37	- access requests
38	- incident routing
39	- deprecation and retirement
40
41	4. Define service levels and guardrails.
42	Include:
43	- support tiers
44	- change windows where relevant
45	- escalation expectations
46	- required contracts, validation, and operational evidence
47
48	5. Keep the model reviewable and executable.
49	The operating model should be visible in docs, runbooks, and actual platform workflows, not just organization charts.
50
51	## Common Rationalizations
52
53	\| Rationalization \| Reality \|
54	\| --- \| --- \|
55	\| "Everyone owns quality." \| Shared responsibility with no explicit owner usually means no one acts quickly enough. \|
56	\| "The platform team can handle anything." \| Undefined service boundaries create burnout, delays, and unsafe tribal processes. \|
57	\| "We can formalize the golden path later." \| Without an explicit adoption path, teams create inconsistent local patterns that are harder to govern. \|
58
59	## Red Flags
60
61	- support boundaries are vague or tribal
62	- domain teams and platform teams disagree on who owns incidents or changes
63	- onboarding depends on undocumented manual steps
64	- there is no explicit service catalog or golden path
65	- deprecation and retirement have no owner
66
67	## Verification
68
69	- [ ] Platform capabilities and support boundaries are documented
70	- [ ] Ownership and escalation paths are explicit for common workflows
71	- [ ] Golden paths exist for onboarding and routine delivery work
72	- [ ] Service levels and required guardrails are defined
73	- [ ] The operating model is reflected in real workflows, not only in abstract policy

People who liked this also viewed

6 picks

Type