Plataforma é produto. Tem clientes (stream-aligned teams), roadmap, NPS, SLA. Plataforma sem demanda real vira "framework abandonado em produção". Plataforma feita certo dá 2-3x menos toil e libera o foco dos times pro domínio.

O problema que platform resolve

Quando você tem N times stream-aligned construindo microservices, cada um vai resolver os mesmos cross-cutting concerns:

  • CI/CD pipeline
  • Observability (logs, metrics, traces)
  • Secrets management
  • Auth/Auth N
  • Service mesh / discovery
  • Database provisioning
  • Feature flags, A/B testing

Sem plataforma, cada time gasta 30-50% do tempo nessas peças — não no domínio do produto. Plataforma centraliza essas capabilities como self-service e libera os times.

Plataforma ≠ Ops centralizada

Ops centralizada (anti-pattern)Platform engineering
Ticket: "preciso de um banco"idp deploy db --type postgres --size m em 30s
Aprovação humana em cada deploySelf-service com guardrails automatizados
"Vai entrar na fila"API + portal sempre disponível
Bottleneck → frustração → shadow ITAdoção orgânica porque é mais fácil que fazer fora
Se exige humano no caminho crítico, não é plataforma. É bottleneck rebrand.

Quando vale criar uma plataforma

  • ≥3 times stream-aligned resolvendo as mesmas peças técnicas
  • A duplicação está visivelmente custando tempo (mensurável em DORA)
  • Há pelo menos 1-2 engenheiros que querem ser donos da plataforma
  • Liderança aceita platform team como produto (com tempo de retorno em 2-3 trimestres)
Por que platform team é uma evolução de "DevOps engineer"?
DevOps engineer original era pessoa híbrida que ajudava cada time individualmente. Não escala — pra 10 times você precisa de 10 DevOps. Platform team produtiza o trabalho: em vez de fazer pra cada time, constrói self-service que qualquer time usa sem ajuda humana. O DevOps engineer continua importante no stream-aligned team (devops culture); o platform team é quem provê as ferramentas pra essa cultura escalar. Veja Team Topologies para o desenho organizacional.