Toda organização que automatiza decisões enfrenta, em algum momento, a mesma crise: o sistema que começou simples — umas regras if/then, um score, uma tabela de decisão — se transformou em um monólito frágil, impossível de mudar sem quebrar algo. O problema não é a tecnologia. É a arquitetura. Ou, mais precisamente, a falta dela.
Decision Architecture é a disciplina de projetar sistemas que capturam, executam, monitoram e evoluem decisões de negócio de forma estruturada. Ela trata a decisão como um artefato de primeira classe — com seu próprio ciclo de vida, versionamento, governança e observabilidade.
Neste artigo, vamos explorar os princípios fundamentais de Decision Architecture, os padrões de design que funcionam em escala, os anti-patterns que destroem operações, e como projetar um sistema que evolua com o negócio.
O que é Decision Architecture?
Decision Architecture é o design intencional de como decisões são estruturadas, executadas e gerenciadas dentro de um sistema. Não é sobre qual linguagem de programação usar ou qual banco de dados escolher. É sobre responder perguntas fundamentais:
- Separação — a lógica de decisão está desacoplada do código da aplicação?
- Composição — decisões complexas são compostas de decisões menores e reutilizáveis?
- Versionamento — políticas podem ser versionadas, comparadas e revertidas?
- Orquestração — como o fluxo de dados e decisões é coordenado?
- Observabilidade — cada decisão é rastreável, mensurável e explicável?
A arquitetura de decisão não é sobre como decidir. É sobre como projetar sistemas que decidem bem — e continuam decidindo bem quando tudo muda.
Por que arquitetura importa em decisões
Decisões de crédito, fraude e compliance têm características que tornam a arquitetura crítica:
- Mudança frequente — políticas mudam semanalmente em operações ativas; a arquitetura deve suportar isso sem deploy
- Múltiplas fontes de dados — bureaus, Open Finance, bases internas, APIs — cada decisão pode consultar 5-15 fontes
- Latência crítica — decisões de crédito digital precisam acontecer em < 2 segundos
- Regulação — cada decisão precisa ser auditável e explicável
- Escala variável — de 100 a 100.000 decisões/dia, dependendo do canal e campanha
Princípio 1: Separação de concerns
O princípio mais importante: lógica de decisão não pertence ao código da aplicação. Quando regras de crédito estão hardcoded em Java, Python ou SQL, qualquer mudança exige um ciclo de desenvolvimento completo: coding → code review → QA → staging → deploy.
A separação correta cria três camadas independentes:
Application Layer — interface, APIs, integrações. Não contém lógica de decisão.
Decision Layer — políticas, regras, modelos, orquestração. Gerenciada por negócio, não por TI.
Data Layer — ingestão, enriquecimento, cache. Alimenta a camada de decisão com dados normalizados.
Essa separação permite que analistas de crédito mudem políticas sem depender de desenvolvedores, e que desenvolvedores mudem infraestrutura sem afetar políticas.
Princípio 2: Composição hierárquica
Decisões complexas devem ser compostas de decisões menores. Uma decisão de crédito não é um bloco monolítico — é uma cadeia:
- Elegibilidade — o solicitante atende critérios mínimos?
- Fraude — há indicadores de fraude?
- Score — qual o risco calculado?
- Política — as regras de negócio aprovam?
- Pricing — qual taxa e limite?
- Compliance — as verificações regulatórias passam?
Cada sub-decisão é um componente reutilizável. A verificação de fraude pode ser compartilhada entre crédito pessoal e crédito consignado. O módulo de compliance serve qualquer produto.
Princípio 3: Orquestração declarativa
O fluxo de decisão deve ser declarativo, não imperativo. Em vez de codificar "se isso, então chame aquilo" em lógica procedural, o fluxo é definido como um grafo de decisão — um pipeline visual onde cada nó tem entrada, processamento e saída definidos.
Benefícios da orquestração declarativa:
- Visibilidade — qualquer pessoa entende o fluxo olhando o grafo
- Paralelismo — nós independentes executam em paralelo automaticamente
- Testabilidade — cada nó pode ser testado isoladamente
- Evolução — adicionar um nó novo não requer reescrever o fluxo
Princípio 4: Observabilidade nativa
Cada decisão deve gerar automaticamente: trace (caminho percorrido no grafo), métricas (latência, resultado, dados utilizados), e explanation (motivos da decisão em linguagem estruturada). Observabilidade não é um add-on — é parte da arquitetura.
Padrões de design (Design Patterns)
Decision Pipeline
O padrão mais comum: decisões são organizadas como um pipeline linear onde cada estágio processa e passa adiante. Input → Enriquecimento → Política → Score → Output. Simples, previsível, fácil de debugar.
Decision Graph (DAG)
Para fluxos complexos com dependências parciais, usa-se um DAG (Directed Acyclic Graph). Nós independentes executam em paralelo; nós dependentes esperam seus predecessores. Ideal para decisões que consultam múltiplas fontes simultaneamente.
Decision Cascade
Uma sequência de políticas onde a primeira que "casa" produz a decisão. Útil para fast-reject (rejeitar cedo) ou fast-approve (aprovar sem consultas caras quando possível). Reduz custo por decisão.
Champion/Challenger Router
Um router que distribui tráfego entre múltiplas versões de política. Integra Champion/Challenger como padrão arquitetural nativo, não como feature ad hoc.
Anti-patterns de arquitetura
- Monolith Decision — toda lógica em um único bloco; impossível de testar, versionar ou evoluir parcialmente
- Spaghetti Rules — regras que referenciam outras regras sem hierarquia clara; mover uma quebra dez
- Hardcoded Logic — regras de negócio no código da aplicação; qualquer mudança exige deploy
- God Service — um microserviço que faz tudo: consulta bureaus, aplica regras, calcula score, verifica compliance
- Shadow Decision — lógica de decisão duplicada em planilhas, emails ou "na cabeça do João"
Decision Architecture no Decision Stack™
O Decision Stack™ é uma implementação de referência de Decision Architecture com cinco camadas:
Integration Layer — Conecta fontes de dados (bureaus, APIs, Open Finance) com normalização e cache.
Policy Layer — Regras, scorecards, tabelas de decisão, modelos ML — versionados e governados.
Orchestration Layer — Pipeline/DAG que coordena o fluxo de dados e decisões entre componentes.
Observability Layer — Métricas, traces, explanations, alertas, backtesting.
Governance Layer — Audit trail, RBAC, versionamento, compliance.
Como a Sinky implementa Decision Architecture
Na Sinky, a arquitetura de decisão é materializada em três produtos: Sinky Studio (design e execução de pipelines de decisão), Sinky Consulta (integration layer com 100+ conectores), e Sinky Analytics (observability layer com métricas em tempo real). Cada decisão é um pipeline declarativo — sem código, versionado, auditável e testável.
Perguntas frequentes
O que é Decision Architecture?
É a disciplina de projetar sistemas que capturam, executam, monitoram e evoluem decisões de negócio de forma estruturada — tratando a decisão como artefato de primeira classe com ciclo de vida próprio.
Qual a diferença entre Decision Architecture e um motor de regras?
Um motor de regras é um componente de execução. Decision Architecture é o design completo: fluxo de dados, orquestração, observabilidade, governança. O motor é uma peça; a arquitetura é o sistema.
Quando investir em Decision Architecture?
Quando mudanças em políticas levam semanas em vez de horas, quando múltiplos produtos compartilham lógica, ou quando regulação exige auditabilidade que a abordagem ad hoc não suporta.
