Arquitetura Sociotécnica¶

Definição: arquitetura sociotécnica

Visão de que o software e a organização que o constrói formam um único sistema: a arquitetura técnica (módulos, serviços, dados) e a arquitetura organizacional (times, comunicação, responsabilidades) se influenciam o tempo todo. Projetar só um dos lados gera atrito; alinhá-los é o que permite escalar o software e manter a organização adaptável.

A ideia central: pessoas não escalam como CPU e memória. Dá para subir capacidade de uma aplicação com mais instâncias, mas times só crescem bem quando têm limites claros, propósito e baixa dependência. Esta página junta os conceitos que conectam estrutura de times, arquitetura e carga mental, muito cobrados em vagas de arquitetura, liderança técnica e engenharia de plataforma.

Modelos organizacionais¶

Modelo	Ideia	Pontos de atenção
Org-chart (hierárquico)	Estrutura por funções e cargos, comunicação por canais formais, vertical e horizontal	Ignora o fluxo real de trabalho; cria silos e filas de aprovação
Ágil (Manifesto, 2001)	Valoriza pessoas, software funcionando, colaboração e resposta a mudanças; Scrum, Kanban, XP	É um conjunto de valores/métodos, não uma estrutura organizacional completa (Gestão de projetos)
Modelo Spotify	Squads (times autônomos), tribes, chapters e guilds	O próprio Spotify afirmou que nunca o seguiu rigidamente e que não é um framework prescritivo; cópia literal gera confusão de papéis e governança
Two-Pizza Teams (Amazon)	Times pequenos (5 a 10 pessoas, "alimentados com duas pizzas") com ponta a ponta de um serviço	Só funciona se a arquitetura permitir independência técnica: dois times no mesmo bloco de código ou no mesmo banco perdem a autonomia
SAFe	Framework completo para escalar agilidade: papéis, cadências, artefatos	Extremo "pesado": estrutura prescritiva
Team Topologies	Princípios e padrões de times e interações (veja abaixo)	Leve e ajustável, mas exige maturidade

Processo x modelo x princípios x framework: processo é uma sequência formal e prescritiva (Waterfall, RUP); modelo é uma representação simplificada que inspira; princípios são diretrizes abertas; framework é uma estrutura de apoio com regras. A tendência é preferir abordagens leves e adaptáveis, começando por princípios e necessidades reais, e evitar adotar um modelo "da moda" sem avaliar o contexto*. Toda escolha organizacional é uma análise de trade-offs*** (prós e contras abertos, não uma resposta certa).

Lei de Conway e a Manobra Inversa¶

Definição: Lei de Conway

Formulada por Melvin Conway (1968): organizações projetam sistemas cuja estrutura copia a estrutura de comunicação da própria organização. Corolário popular: se a arquitetura de software e a organização entram em conflito, a organização vence.

Exemplos: três times separados (front, back, banco) tendem a produzir uma aplicação em três camadas fortemente acopladas por contratos negociados entre os times; um monolito mantido por vários times vira uma fila de dependências para cada mudança. Sinais típicos de desalinhamento: releases coordenados entre muitos times, reuniões de alinhamento sem fim, propriedade difusa de código, baixa visibilidade de retorno sobre o investimento, métricas que premiam atividade em vez de resultado.

Definição: Manobra Inversa de Conway (Inverse Conway Maneuver)

Em vez de aceitar a Lei de Conway como destino, desenhar a organização (times e comunicação) para produzir a arquitetura desejada. Se queremos serviços independentes, formamos times independentes, com propriedade clara e ponta a ponta.

Cuidados: reorganizar só o organograma "de cima para baixo" (re-org) sem mudar a arquitetura e a forma de colaborar não resolve; é preciso agir nos dois lados, e de forma gradual. Para medir se o fluxo melhora, usam-se as métricas DORA: frequência de deploy, lead time de mudanças, taxa de falha de mudanças e tempo de recuperação (SRE, CI/CD).

Carga cognitiva¶

Definição: carga cognitiva

Quantidade de esforço mental que uma pessoa (ou um time) precisa para entender e executar seu trabalho. A memória de trabalho é limitada: como um celular com aplicativos demais, o desempenho cai quando ela estoura.

Tipo	O que é	Exemplo em software
Intrínseca	Dificuldade inerente ao assunto	Entender como uma classe Java é definida; uma regra fiscal complexa
Extrínseca	Esforço causado pela forma como o trabalho é feito	Fazer deploy manual; ferramentas confusas; documentação ruim
Pertinente (germane)	Esforço útil para construir conhecimento e modelos mentais	Estudar o domínio, praticar um padrão

O objetivo é reduzir a intrínseca (com formação) e a extrínseca (com plataforma e automação) para sobrar capacidade para a pertinente. Sobrecarga coletiva: quando as demandas combinadas excedem a capacidade do time (vários domínios, muitos sistemas, muitas dependências), a entrega desacelera. A carga cognitiva é reflexo direto das estruturas organizacionais e da arquitetura, não só um problema individual.

Como avaliar: por observação e pesquisa de percepção (por exemplo, dificuldade percebida e fatores de distração numa escala de 1 a 5) e por heurísticas. Uma delas usa o framework Cynefin (Dave Snowden): classifica problemas em simples, complicados, complexos, caóticos e confusos; quanto mais complexo o domínio, maior a carga, e diferentes categorias pedem respostas diferentes (boa prática, análise de especialistas, experimentação).

Team Topologies¶

Definição: Team Topologies

Modelo (Matthew Skelton e Manuel Pais) com quatro tipos de time e três modos de interação, desenhado para reduzir carga cognitiva e acelerar o fluxo de valor.

Quatro tipos de time:

Tipo	Papel	Observação
Stream-aligned (alinhado ao fluxo)	Entrega valor continuamente e de ponta a ponta em um fluxo (produto, serviço, jornada), com alta autonomia	O tipo principal; pequeno e coeso (regra das duas pizzas)
Platform (plataforma)	Oferece APIs, ferramentas e serviços *self-service* como produto interno	Lema: "o caminho de menor resistência para fazer a coisa certa"; *Thinnest Viable Platform*: a menor plataforma que ajuda de fato
Enabling (habilitador)	Capacita outros times: mentoria, treinamentos, boas práticas, transferência de conhecimento	Atua por tempo limitado; reduz carga intrínseca e extrínseca
Complicated-subsystem	Cuida de partes que exigem conhecimento profundo (algoritmos, biometria, IA, leitura de IoT)	Opcional; só quando a especialização justifica

Três modos de interação:

Modo	Quando usar
Colaboração	Dois times trabalham juntos por um período, com objetivo comum (descoberta, inovação): relação intensa
X-as-a-Service	Um time consome o que outro oferece (API, plataforma) com mínima interação: baixa fricção
Facilitação	Um time (enabling) ajuda outro a superar um obstáculo ou aprender algo

Barreiras comuns: cultura, falhas de comunicação e uso errado dos modos de interação (que gera mais atrito). Uma boa prática de adoção é começar por times habilitadores (removem bloqueios e geram aprendizado) e evoluir de forma gradual.

DDD como base do alinhamento¶

O DDD fornece o vocabulário para decidir quais fronteiras os times assumem:

Domínio, subdomínio e contexto delimitado (bounded context): o domínio é a área de negócio; os subdomínios são suas partes; o contexto delimitado é a fronteira em que um modelo e uma linguagem ubíqua valem. Idealmente, um contexto por time e (no software) por serviço ou módulo.
Classificação dos subdomínios: Core (diferencial competitivo; invista mais, mantenha internamente), de suporte (apoia o core, sem diferencial) e genérico (comum a qualquer empresa, como autenticação; compre ou use SaaS). A classificação não é estática: um genérico pode virar core.
Capacidades de negócio: o que a empresa faz (cobrar, entregar, antifraude), independente de como; ajudam a dividir times e sistemas por valor, e não por tecnologia.
EventStorming: oficina colaborativa que descobre eventos de domínio, subdomínios, a linguagem ubíqua e as interações entre times (EDA).
Portfólio de domínios e métricas: com subdomínios mapeados, pode-se medir complexidade, criticidade e sobrecarga para decidir onde investir ou separar equipes.

Arquitetura e custo de oportunidade¶

Definição: custo de oportunidade e trade-off

Custo de oportunidade é o valor do que se deixa de ganhar ao escolher uma alternativa em vez de outra. Trade-off é o conjunto de ganhos e perdas de cada opção. Toda decisão arquitetural (monolito, microsserviços, EDA, comprar ou construir) deve explicitar ROI, time-to-market, risco e carga cognitiva.

Estilo	Quando faz sentido	Observação
Monolito	Domínio pequeno, um time, ciclo de vida simples	Cresce até vários times disputarem o mesmo código (gargalo de Conway)
Microsserviços	Vários times, contextos bem delimitados, necessidade de implantar de forma independente	Complexidade operacional; só vale com times e domínios alinhados (Microsserviços)
EDA	Desacoplamento temporal, resiliência e escala com eventos	Eventos são fundamentais em sistemas distribuídos, não "moda" (EDA)

Escalabilidade x elasticidade: escalar é crescer (vertical = máquina mais forte; horizontal = mais instâncias); elasticidade é ajustar dinamicamente conforme a demanda (System Design).

Modernização: greenfield x brownfield e o Strangler Fig¶

Greenfield: projeto novo, sem legado; brownfield: evoluir um sistema existente (comum, e com decisões cujo "porquê" se perdeu).
Strangler Fig (figueira-estranguladora, Martin Fowler): em vez de reescrever o monolito de uma vez, crescer novas capacidades ao redor, desviando gradualmente o tráfego, até o legado poder ser desligado. Times de plataforma e habilitadores são os "polinizadores" que levam novas práticas. Exemplo: substituir o módulo de antifraude do monolito por um serviço novo, roteando primeiro uma parcela das transações (Código legado).

Engenharia de plataforma e ADR¶

Engenharia de plataforma: disciplina de desenvolver e operar plataformas internas como produto, com abstrações self-service e "caminhos pavimentados" (golden paths) que reduzem a carga cognitiva dos times de produto (SRE: platform engineering).
ADR (Architecture Decision Record): documento curto com contexto, alternativas, decisão e consequências. Mantém a memória das decisões, conecta níveis de maturidade e evita o "por que fizeram assim?" em projetos brownfield.

IA como sistema sociotécnico¶

A adoção de IA também é uma questão de organização e carga cognitiva, não só de modelos:

Sistema sociotécnico: agentes e modelos são moldados pela sociedade, pelos dados, pelos hábitos e pelas regras das organizações. Um modelo bem treinado mal posicionado vira problema.
Três formas de adotar IA e o esforço de cada uma:

Forma	Como	Carga e controle
Plugada (partner service)	Consome modelos e APIs de provedores	Menor complexidade inicial; dependência do fornecedor; é preciso acompanhar versões e descontinuações
Customizada	Adapta modelos de fundação (RAG, fine-tuning)	Controle intermediário; exige MLOps e dados
Construída	Treina e mantém o próprio modelo	Máximo controle e máxima carga (LLM)

Efeito "AI Factor" (antipadrão): IA introduzida sem preparo aumenta a carga cognitiva (novas ferramentas, fluxos e fontes de erro) e alimenta a dívida técnica: improvisos hoje, cobrados quando a escala chegar.
Como escalar IA: em vez de um "time central de IA" isolado, aplicar Team Topologies: times de plataforma de IA (MLOps, pipelines, modelos como serviço interno), times habilitadores (formação e práticas) e times alinhados ao fluxo usando a plataforma; começar por habilitadores.
Governança e ética: transparência, privacidade, viés e explicabilidade, com cocriação entre áreas (Engenharia de IA).

Modelo próprio do autor

O livro propõe ainda o 3SM Tri-Space Metamodel, um modelo de referência que combina três "espaços" (domínio, organização e tecnologia) com atratores e detratores, e o apresenta em casos de abastecimento digital, consumo e segurança. É uma síntese autoral; os conceitos acima são o conteúdo reutilizável.

Para responder em entrevista¶

Pergunta	Ideias para a resposta
"O que é a Lei de Conway?"	A estrutura do sistema espelha a estrutura de comunicação da organização; usar a Manobra Inversa para desenhar times que produzam a arquitetura desejada
"Quando migrar para microsserviços?"	Quando há vários times, contextos delimitados claros e necessidade de deploy independente; senão, um monolito modular é melhor. Falar de carga cognitiva e trade-offs
"O que é Team Topologies?"	Quatro tipos de time (stream-aligned, platform, enabling, complicated-subsystem) e três interações (colaboração, X-as-a-Service, facilitação)
"Como reduzir a carga cognitiva de um time?"	Escopo e domínio claros, plataforma self-service, automação, documentação (ADR), time habilitador
"Como modernizar um legado?"	Strangler Fig por capacidades de negócio, com métricas DORA para validar o fluxo
"Como escalar a adoção de IA?"	Plataforma de IA + times habilitadores + governança; evitar o time central isolado e o AI Factor