A data platform team builds and maintains centralized, self-serve infrastructure and tooling, whereas domain data teams use that infrastructure to build and own specific data products for their business units. By providing shared frameworks for ingestion, orchestration, CI/CD, and governance, the platform team enables domain teams to operate autonomously without turning the central data team into an engineering bottleneck. This clear division of responsibilities establishes clean operational boundaries and scales data delivery across expanding organizations.
Self-serve capabilities versus data products
The distinction between the two groups reflects a product-and-platform relationship:
- Data platform team responsibilities: They treat internal domain engineers as their customers. They provide self-serve ingestion templates, maintain managed Airflow or Dagster clusters, provision compute workspaces in Snowflake or Databricks, establish automated CI/CD validation pipelines, manage catalog metadata, and configure FinOps cost tracking dashboards.
- Domain team responsibilities: Embedded within business domains like Marketing, Finance, or Logistics, domain engineers possess deep context on source application logic. They use platform tooling to write dbt models, define business metrics, clean customer attributes, publish clean gold tables, and meet operational SLAs for domain stakeholders.
Platform Team (Horizontal Foundation):
- Orchestration infra (Airflow/Dagster)
- Storage & compute provisioning (Terraform)
- CI/CD templates & automated test frameworks
- Data catalogs & access control policies
|
v (Enables self-serve operations)
Domain Teams (Vertical Business Products):
- Marketing Data Products (Attribution, Ad Spend)
- Finance Data Products (Revenue Recognition, Invoicing)
- Supply Chain Data Products (Inventory Velocity, Fulfillment)Clean interfaces prevent organizational gridlock as the company expands:
Guardrails and platform contracts
In legacy organizations, central data teams attempted to build every pipeline, report, and transform for the entire company. This centralized pattern inevitably collapsed into an operational bottleneck where simple schema change requests took months to review.
The platform-versus-domain model eliminates this friction by establishing explicit contracts:
- Platform guardrails: The platform team defines automated security policies, role-based access controls, and resource quota limits, preventing any single domain from crashing shared clusters or leaking sensitive data.
- Domain autonomy: Domain teams own their schemas, release cycles, and data quality tests, shipping updates independently within established governance guardrails.