Centralização vs. Descentralização

Visão Geral

O par se aplica a quase tudo: decisões, dados, serviços, times, ferramentas, plataforma.

E em todos os casos o eixo é o mesmo:

eixo real   quem arca com a consequência, e quanto custa convergir depois
            se cada um decidir por si

A primeira metade decide o caso comum. A segunda decide os empates, e é a que quase ninguém calcula: divergência acumulada é barata de criar e cara de desfazer, e essa assimetria deveria pesar mais do que pesa.

Problema

Os dois extremos falham de formas conhecidas e opostas.

Centralização. Um ponto decide, e o ponto vira fila. A qualidade da decisão cai com a distância do contexto; a velocidade cai com o número de solicitantes.

uma equipe de dados atendendo 20 times    fila de 6 semanas
um serviço de autenticação central        indisponibilidade derruba tudo
uma equipe de arquitetura decidindo por
  todos os sistemas                       decisões genéricas

Descentralização. Cada um decide, e a soma tem custo que ninguém decidiu:

9 linguagens, cada escolha razoável isoladamente
6 formas de autenticação entre serviços
15 formatos para o mesmo conceito de negócio
4 sistemas de fila no plantão compartilhado

Nenhuma dessas foi decidida. Todas foram acumuladas.

O ponto importante: o custo da descentralização não aparece dentro dos times. Ele aparece entre eles — na integração, no plantão compartilhado, na contratação, na migração.

Conceitos Centrais

Externalidade decide o caso comum

O critério é o da governança federada, canônico de externalidade de decisão: se der errado, quem paga? Consequência que fica no time se descentraliza; consequência que atravessa fronteira se coordena; consequência da organização se centraliza.

O que este documento acrescenta é a aplicação do critério fora de decisões — a dados, serviços, times e ferramentas — e o custo de desfazer, que a seção seguinte trata.

O custo de convergir decide os empates

divergir     barato, incremental, tomado por uma pessoa numa tarde
convergir    caro, coordenado, exige patrocínio e meses

Uma escolha de linguagem feita por um time em uma semana pode custar dois anos para reverter, quando a organização precisar de mobilidade entre times.

Isso significa que, em caso de empate, centralizar é a aposta mais segura — não por ser melhor, mas por ser reversível. Descentralizar depois é fácil; convergir depois não é.

A assimetria é oposta à de vários outros pares deste conjunto, e por isso vale explicitá-la.

Centralizar o quê, exatamente

A pergunta binária é mal formulada. Quase sempre a resposta é dividir:

centralizar a interface, descentralizar a implementação
centralizar o padrão, descentralizar a escolha dentro dele
centralizar a capacidade, descentralizar o uso
centralizar o mínimo compartilhado, descentralizar o resto

A terceira linha é o modelo de plataforma: uma equipe central constrói a capacidade, e os times a usam quando quiserem, sem pedir. Ver engenharia de plataforma.

Centralizar capacidade é diferente de centralizar decisão

decisão centralizada    o time pede, espera, recebe
capacidade centralizada o time usa quando quer, sem pedir

A diferença é enorme e frequentemente ignorada. Uma equipe de dados que atende pedidos vira fila; a mesma equipe construindo ferramental de autoatendimento não.

Isso permite obter coerência sem criar ponto de coordenação — o arranjo mais desejável e o mais caro de construir.

Escala muda a resposta

3 times      centralizar quase tudo é barato e funciona
15 times     centralização vira fila; coordenar interfaces
50 times     centralizar decisão vira fila mais rápido do que a organização
             absorve; a saída praticada é federação sobre plataforma

Uma decisão de centralização correta para 3 times é errada para 30, e organizações frequentemente mantêm o arranjo por inércia depois de crescer.

O sinal de que a hora passou: o tempo de espera no ponto central cresce mais rápido que o número de times.

Sinais de escolha errada

centralizou demais
  fila crescente no ponto central
  times construindo alternativas para contornar
  decisões genéricas que não servem a nenhum caso
  a equipe central sem contexto para decidir bem
  indisponibilidade do serviço central derrubando tudo

descentralizou demais
  N formas de fazer a mesma coisa, sem que ninguém tenha decidido
  integração entre times custando mais que a construção
  plantão compartilhado com carga cognitiva insustentável
  mobilidade entre times impossível
  custo agregado de licenças e operação crescendo sem uso proporcional

Custo de mudar de ideia

centralizado → descentralizado   relativamente barato: distribuir o que já é uniforme
descentralizado → centralizado   caro: convergir N variantes, com resistência

Esta assimetria é a razão de "centralize por padrão, descentralize com evidência" ser um conselho melhor que o inverso — em organizações que já passaram do tamanho em que a conversa resolve.

Modelo Mental

Se der errado, quem paga? E, no empate: divergir é barato, convergir não é.

Quando Usar

Centralize quando:

• A consequência é da organização — segurança, dado regulado, identidade.
• O custo de convergir depois é alto.
• A capacidade exige especialização que não cabe em cada time.
• O componente entra no plantão compartilhado.
• A escala ainda é pequena.

Descentralize quando:

• A consequência fica no time.
• O contexto local varia de verdade.
• A capacidade já está disponível como autoatendimento — e não só a fila do ponto central incomoda: fila sem plataforma que a substitua devolve duplicação, não autonomia.
• A reversão é barata.

Quando Não Usar

O enquadramento não ajuda em três situações, e insistir nele nelas custa tempo de decisão.

Abaixo de cerca de cinco times. Nessa faixa quase tudo é central e o arranjo cabe na cabeça de todos; a discussão de eixo é antecipação de um problema que ainda não existe.

Quando o custo de convergir é desprezível. Escolha de biblioteca interna, formato de log, convenção de nome: se desfazer é uma tarde, deixe divergir e revise depois. O eixo só paga a discussão quando desfazer custa meses — é o que a seção sobre o custo de convergir mede.

Quando o problema medido é de capacidade, não de arranjo. Fila de seis semanas na equipe de dados pode ser subdimensionamento, e nesse caso mudar o arranjo não resolve nada e ainda troca um problema conhecido por um desconhecido. Meça a utilização antes.

E, em qualquer caso, não trate como escolha binária: a resposta quase sempre divide interface e implementação.

Alternativas

• Plataforma — capacidade central, uso descentralizado: obtém coerência sem criar ponto de coordenação, ao custo de construir e manter o autoatendimento.
• Federação — decisão local com contrato central. Ver governança federada.
• Centralização temporária — construir central e distribuir quando maduro.
• Lista curta — em vez de uma escolha central ou liberdade total, três opções aprovadas.

A última resolve boa parte dos casos de tecnologia: nem uma linguagem só, nem nove — três, com o custo de plantão e contratação declarado.

Trade-offs

Centralizado	Descentralizado
Coerência	Contexto local
Especialização concentrada	Especialização difusa
Vira fila	Divergência acumulada
Ponto único de falha	Sem coordenação

Centralizar decisão	Centralizar capacidade
Controle	Coerência sem fila
Barato de instituir	Caro de construir
Cria dependência	Cria alavanca

Modos de Falha

Os sintomas estão na lista de sinais de escolha errada. O que segue é o que se observa quando o arranjo falha sem que nenhum sinal daquela lista tenha disparado — os casos difíceis de atribuir.

Fila que não aparece na métrica. O tempo de atendimento do ponto central está bom porque os times pararam de pedir e passaram a contornar. A fila virou trabalho invisível.

Coerência de fachada. O padrão central existe, é obedecido na forma e contornado no conteúdo — o mesmo evento publicado com o campo genérico que aceita qualquer coisa.

Plataforma adotada e não usada. A adoção é alta porque é obrigatória; o caminho pavimentado não é o mais curto, e o time usa o mínimo para passar na verificação.

Reversão bloqueada por conhecimento. O arranjo antigo poderia voltar, mas quem sabia operá-lo saiu. O custo de convergir cresceu por rotatividade, não por tecnologia.

Erros Comuns

Tratar como binário.

Não calcular o custo de convergir antes de permitir divergir.

Confundir centralizar decisão com centralizar capacidade.

Não revisar o arranjo quando a escala muda.

Descentralizar como resposta a uma fila, sem construir a plataforma que a substitui.

Exemplo Real

Uma empresa de tecnologia financeira com 24 times passou por três arranjos em cinco anos.

Fase 1 — centralizada (2021). Uma equipe de arquitetura decidia tecnologia, uma equipe de dados atendia todos os pedidos de dados, uma equipe de infraestrutura provisionava recursos.

tempo médio para provisionar ambiente novo       19 dias
tempo médio de atendimento de pedido de dados    6 semanas
times que construíram alternativas próprias
  para contornar a fila                          11 de 24
linguagens em produção                           4 (2 aprovadas)
tecnologias em uso não aprovadas                 estimadas em 8

Os contornos eram o dado relevante: a centralização não impediu divergência, ela apenas a tornou invisível.

Fase 2 — descentralizada (2022). A resposta foi remover a centralização: cada time decide sua tecnologia, provisiona seus recursos e gere seus dados.

Dezoito meses depois:

linguagens em produção                           7
mecanismos de fila                               4
formas de autenticação entre serviços            5
tempo médio de integração entre dois times       de 4 para 12 dias
custo de infraestrutura                          +52% (uso +18%)
mobilidade entre times                           praticamente nula
incidentes no plantão compartilhado com causa
  em tecnologia desconhecida pelo plantonista    23 em 12 meses

Nenhuma decisão isolada tinha sido errada. A soma foi.

Fase 3 — capacidade central, uso local (2024). O terceiro arranjo separou decisão de capacidade:

Plataforma de autoatendimento para provisionamento, esteira, observabilidade e identidade. O time usa sem pedir; a coerência vem do caminho pavimentado, não de aprovação.

Lista curta de tecnologias, com três linguagens e um mecanismo de fila, com o custo de plantão e contratação declarado explicitamente como a razão. Fora da lista exige exceção com prazo.

Interfaces centralizadas, implementações locais: formato de evento, protocolo síncrono, identidade e requisitos de observabilidade são centrais; tudo o mais é do time.

Equipe de dados como construtora de ferramental, não como atendente de pedidos.

Resultados após 20 meses:

tempo para provisionar ambiente novo             minutos (autoatendimento)
tempo de integração entre times                  3 dias
linguagens em produção                           4 (uma em desativação)
mecanismos de fila                               1
custo de infraestrutura                          -21%, com uso +30%
incidentes por tecnologia desconhecida            2 em 12 meses
adoção da plataforma em serviços novos           93%

A divergência foi de 4 linguagens para 7 em dezoito meses. A convergência de volta a 4 levou vinte, e ainda não terminou: a lista curta tem três, e a quarta está em desativação.

O tempo, portanto, é quase o mesmo nas duas direções — e não é aí que está a assimetria. Ela está no que cada direção exigiu. Divergir não exigiu projeto: aconteceu como soma de decisões locais, nenhuma delas errada, sem que ninguém aprovasse o resultado. Convergir exigiu construir uma plataforma de autoatendimento, negociar uma lista curta com o custo de plantão declarado, instituir processo de exceção e reposicionar uma equipe inteira — e o custo disso não aparece em nenhum dos dois números.

É esse o argumento que a organização passou a usar para avaliar qualquer proposta de descentralização. A pergunta não é se o time consegue decidir bem; é quanto custa construir o que vai desfazer a soma de decisões boas.

Conceitos Relacionados

• Governança Federada.
• Engenharia de Plataforma.
• Monólito vs. Microsserviços — o mesmo eixo, aplicado à estrutura.
• Build vs. Buy.

Exercício Prático

Escolha uma decisão que os times da sua organização tomam de forma independente e estime o custo de convergir todas as variantes existentes hoje.

Compare com o tempo que levou para elas divergirem. A razão entre os dois números costuma surpreender.

Perguntas de Entrevista

• Por que centralizar capacidade é diferente de centralizar decisão?
• Por que o empate favorece centralizar, ao contrário de outros trade-offs?
• Por que uma fila no ponto central não é resolvida simplesmente descentralizando?

Para Aprofundar

• Skelton, Matthew; Pais, Manuel. Team Topologies. IT Revolution, 2019.
• Hohpe, Gregor. The Software Architect Elevator. O'Reilly, 2020.
• Conway, Melvin. How Do Committees Invent?. Datamation, 1968.