Teams and Ownership

Architecture is also an org chart

Microservices succeed when each service has one owning team responsible for building, running and fixing it ("you build it, you run it"). The book Team Topologies (Skelton and Pais) describes four team types that map well onto architecture: stream-aligned teams own a slice of business value end to end; platform teams provide self-service infrastructure (pipelines, clusters, observability) as an internal product; enabling teams coach others in new skills; and complicated-subsystem teams own parts needing deep specialist knowledge. Keep cognitive load manageable: a team should be able to understand everything it owns. Interaction modes matter too: collaboration for discovery, X-as-a-service for stable platforms. Without a strong platform, every stream-aligned team reinvents pipelines and monitoring, and microservices become expensive.

Stream-aligned teams on a platform

Product teams each own a slice of the system and build on a shared self-service platform.

An ownership entry in a service catalogue

Every service declares its owner, on-call, docs and dependencies.

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: checkout
  description: Cart, pricing, coupons and order placement
  annotations:
    pagerduty.com/service-id: PCHK123
  links:
    - url: https://grafana.example.com/d/checkout
      title: Dashboard
    - url: https://runbooks.example.com/checkout
      title: Runbook
spec:
  type: service
  lifecycle: production
  owner: team-checkout
  system: storefront
  dependsOn:
    - component:pricing-rules
    - resource:checkout-db

No orphan services

A service without a clear owner will be the one nobody patches. Make ownership part of the definition of done for any new service, and reassign it explicitly when teams change.

Quick check: In Team Topologies, what is the role of a platform team?

• Owning a customer-facing feature end to end
• Approving every deployment manually
• Providing self-service internal capabilities such as pipelines and infrastructure for other teams
• Writing all the business logic