Arquitetura Salesforce Não É Sobre Desenhar a Solução Perfeita, É Sobre Desenhar para Decisões que Irão Mudar

Uma das premissas mais perigosas em arquitetura corporativa é acreditar que a arquitetura que aprovamos hoje continuará correta amanhã. Não continuará.

Modelos de negócio mudam. Regulamentações mudam. Ecossistemas de integração mudam. A liderança muda. As capacidades do Salesforce evoluem.

O Agentforce muda aquilo que podemos automatizar e o nível de autoridade que podemos delegar ao software.

E, algumas vezes, as premissas utilizadas para construir uma arquitetura simplesmente se mostram incorretas.

É por isso que acredito que uma das características mais importantes da arquitetura em nível CTA não seja a capacidade de tomar decisões perfeitas.

É a capacidade de tomar decisões que possam evoluir de forma responsável.

Essa diferença se torna extremamente importante quando Arquitetura Salesforce e Salesforce Center of Excellence operam em escala corporativa.

Arquitetura É um Sistema de Decisões, Não uma Coleção de Diagramas

Organizações frequentemente associam arquitetura a artefatos.

Diagramas de arquitetura. Diagramas de integração. Modelos de dados. Modelos de segurança. Roadmaps. Arquiteturas de referência.

Tudo isso é importante. Mas esses elementos são representações da arquitetura. Eles não são a arquitetura em si. Arquitetura é fundamentalmente um sistema de decisões.

Por que Salesforce é o System of Engagement?

Por que outra plataforma é o System of Record?

Por que escolhemos integração assíncrona?

Por que temos uma única org Salesforce em vez de múltiplas orgs?

Por que determinada capacidade foi centralizada?

Por que essa ação do Agentforce exige aprovação humana?

O diagrama mostra o que existe.

A arquitetura precisa preservar por que aquilo existe.

Essa diferença é fundamental.

O Pensamento em Nível CTA Torna o “Porquê” Defensável

Um arquiteto sênior deve conseguir explicar uma decisão sem se esconder atrás de afirmações como: “Essa é a best practice do Salesforce.”

Best practices são importantes.

Mas arquitetura corporativa depende de contexto.

Uma explicação mais forte seria: “Selecionamos integração assíncrona porque a transação de atendimento ao cliente não pode depender da disponibilidade em tempo real da plataforma core. Aceitamos consistência eventual e mitigamos esse trade-off através de idempotência, replay, reconciliação, monitoramento e procedimentos operacionais.”

Agora conseguimos compreender:

• O direcionador de negócio

• A decisão arquitetural

• O trade-off

• O risco

• A mitigação

Isso é significativamente mais valioso do que: “Estamos utilizando Platform Events porque integração assíncrona é uma best practice.”

O pensamento em nível CTA conecta: Requisito → Direcionador → Decisão → Consequência → Mitigação

Essa cadeia de raciocínio é o que torna uma arquitetura defensável.

Toda Decisão Arquitetural Possui uma Condição de Expiração

Acredito que esse seja um conceito que mais organizações Salesforce deveriam reconhecer explicitamente.

Decisões arquiteturais não precisam necessariamente possuir uma data de expiração.

Mas muitas deveriam possuir condições de expiração.

Imagine que decidimos manter uma capacidade de negócio dentro da org Salesforce existente porque:

• O volume transacional é relativamente baixo

• Uma única unidade de negócio controla o processo

• Não existe necessidade de separação regulatória

• O modelo operacional existente consegue suportá-la

Essa arquitetura pode estar completamente correta hoje.

Mas o que acontece quando:

• O volume aumenta 20 vezes?

• Cinco novos países passam a utilizar a capacidade?

• Uma regulamentação exige separação dos dados?

• Outra unidade de negócio precisa de releases independentes?

A decisão original pode deixar de ser válida.

Um arquiteto maduro, portanto, pergunta: “Sob quais condições deveríamos reconsiderar essa decisão?”

Essa pergunta transforma arquitetura de documentação estática em governança ativa.

É Aqui que Architecture Decision Records se Tornam Poderosos

Architecture Decision Records deveriam conter mais do que:

Decisão: Utilizar o Padrão A.

Um ADR realmente útil deveria explicar:

• Contexto

• Direcionadores arquiteturais

• Premissas

• Opções consideradas

• Decisão selecionada

• Trade-offs

• Riscos

• Mitigações

• Owner

• Gatilhos para revisão

O último ponto é particularmente importante.

Gatilhos para revisão.

Por exemplo:

Revisar esse padrão de integração se:

• O volume ultrapassar 5 milhões de transações por dia

• A latência necessária ficar abaixo de dois segundos

• Um segundo domínio de negócio consumidor for introduzido

• A classificação regulatória mudar

Agora a organização sabe quando a arquitetura deverá ser novamente questionada.

Isso é governança arquitetural com memória.

Um Salesforce CoE Deve Ser Responsável pela Memória Arquitetural

Plataformas corporativas possuem um problema de memória. Pessoas deixam a empresa. Parceiros de consultoria mudam. Programas terminam. Documentações ficam desatualizadas.

Três anos depois, uma nova equipe olha para a arquitetura e pergunta: “Por que estamos fazendo dessa maneira?”

Quando ninguém conhece a resposta, a equipe frequentemente assume que a arquitetura está errada. Às vezes está. Em outros casos, a decisão original era excelente, mas seu contexto desapareceu. Um Salesforce CoE maduro deve preservar a memória arquitetural.

Isso inclui:

• Architecture Decision Records

• Arquiteturas de referência

• Princípios arquiteturais

• Padrões aprovados

• Registros de exceções

• Decisões sobre dívida técnica

• Padrões de segurança

• Contratos de integração

• Ownership dos dados

• Decisões de governança do Agentforce

O CoE não deveria simplesmente documentar o estado atual.

Ele deve preservar o raciocínio que criou o estado atual.

Dívida Técnica e Exceções Arquiteturais Precisam de uma Estratégia de Saída

Uma das maiores fontes de complexidade arquitetural é a palavra: “Temporário.”

Integração temporária. Customização Apex temporária. Exceção temporária de segurança. Modelo de dados duplicado temporariamente. Processo manual temporário.

Cinco anos depois, continua existindo.

Um CoE maduro deveria exigir que toda exceção arquitetural significativa respondesse: Qual é a estratégia de saída?

Uma exceção deveria possuir:

• Justificativa de negócio

• Avaliação de risco

• Owner

• Controles compensatórios

• Target architecture

• Critérios de remediação

• Data ou gatilho de revisão

Caso contrário, a exceção não está sendo governada.

Ela simplesmente está se tornando arquitetura.

O CoE Também Precisa Saber Quando Aposentar Padrões

Governança não significa apenas criar padrões.

Também significa removê-los. Isso se torna cada vez mais importante em Salesforce porque a plataforma evolui rapidamente. Um padrão que fazia sentido quatro anos atrás pode não representar mais a melhor abordagem. Um framework customizado pode ter se tornado desnecessário porque Salesforce agora fornece uma capacidade nativa. Um padrão de integração pode ter sido superado. Um controle de segurança pode precisar ser fortalecido.

Uma política de governança de IA pode precisar ser ajustada à medida que as capacidades do Agentforce evoluem.

Um CoE maduro deveria, portanto, administrar padrões através de um ciclo de vida: Proposto → Aprovado → Recomendado → Descontinuado → Aposentado

Sem gerenciamento do ciclo de vida, CoEs acumulam padrões da mesma maneira que orgs mal governadas acumulam dívida técnica.

Eventualmente, ninguém sabe qual padrão é realmente autoritativo.

Agentforce Torna a Governança do Ciclo de Vida das Decisões Crítica

Agentforce introduz um desafio adicional.

Com automações determinísticas tradicionais, governamos principalmente:

• Código

• Configuração

• Permissões

• Integração

• Deployment

Com sistemas agentic, também precisamos governar:

• Instruções

• Grounding

• Limites de raciocínio

• Ações disponíveis

• Autonomia

• Critérios de avaliação

• Escalonamento

• Supervisão humana

Considere um agente Agentforce originalmente autorizado a: Recomendar a próxima ação para um representante de atendimento.

Posteriormente, o negócio solicita: “Podemos permitir que o agente execute essa ação automaticamente?”

Tecnicamente, isso pode parecer uma pequena evolução. Arquiteturalmente, não é.

Mudamos o agente de: Recomendação

para: Execução delegada.

Isso altera o modelo de risco.

A arquitetura precisa reconsiderar:

• Autorização

• Least privilege

• Limites transacionais

• Reversibilidade

• Aprovação humana

• Auditabilidade

• Monitoramento

• Accountability

A capacidade mudou.

Portanto, a decisão arquitetural precisa ser reavaliada.

Governança Arquitetural Precisa de Indicadores Antecipados

Outro erro é medir arquitetura somente depois que alguma coisa dá errado. Quantidade de incidentes é importante. Falhas em produção são importantes. Eventos de segurança são importantes.

Mas esses são principalmente lagging indicators — indicadores tardios.

Um CoE maduro deveria também monitorar leading indicators — indicadores antecipados.

Por exemplo:

• Crescimento de exceções arquiteturais

• Aumento de integrações ponto a ponto

• Percentual de customizações sem suporte

• Aging da dívida técnica

• Crescimento das dependências de APIs

• Aumento de acessos privilegiados

• Redução na adoção de componentes reutilizáveis

• Crescimento de deployments manuais

• Quantidade de ações Agentforce sem avaliações concluídas

Esses indicadores podem revelar deterioração arquitetural antes que ela se transforme em um incidente de produção.

Isso é muito mais valioso do que descobrir o problema somente depois da falha.

Boa Governança Arquitetural Questiona Suas Próprias Decisões

Esse é um ponto cultural importante. Um Architecture Review Board não deveria existir para provar que os arquitetos estavam certos. Deveria existir para garantir que a arquitetura continue correta para o contexto atual.

Às vezes, a decisão correta é: Manter a arquitetura atual.

Às vezes: Refatorá-la.

Às vezes: Substituí-la.

E, em alguns casos: A premissa original não é mais verdadeira, portanto precisamos de uma abordagem completamente diferente.

Alterar uma decisão arquitetural porque o contexto mudou não representa uma falha de arquitetura.Recusar-se a alterar uma decisão mesmo quando existem evidências de que o contexto mudou, sim.

Arquitetos em Nível CTA Precisam se Sentir Confortáveis em Dizer “Depende”

A expressão “depende” algumas vezes recebe uma interpretação negativa.

Mas arquitetura realmente depende do contexto.

A parte importante é o que vem depois.

Um arquiteto fraco diz: “Depende.”

Um arquiteto forte diz: “Depende destes quatro direcionadores arquiteturais. Se A e B forem verdadeiros, recomendo a Opção 1. Se C se tornar a principal restrição, migraria para a Opção 2.”

Isso não é indecisão. Isso é tomada de decisão estruturada. Arquitetura em nível CTA não elimina a incerteza.

Ela cria um framework para tomar decisões responsáveis dentro da incerteza.

O Verdadeiro Produto de um Salesforce CoE São Decisões Melhores

Um CoE pode produzir muitas coisas:

Padrões. Templates. Arquiteturas de referência. Review Boards. Aceleradores. Treinamentos. Dashboards. Processos de governança.

Mas tudo isso são outputs.

O verdadeiro resultado deveria ser: A organização toma melhores decisões sobre Salesforce porque o CoE existe.

Melhores decisões sobre:

• Arquitetura

• Segurança

• Dados

• Integração

• DevOps

• Dívida técnica

• Investimentos na plataforma

• Agentforce

• Reutilização

• Risco

Se essa melhoria não puder ser demonstrada, o CoE corre o risco de se transformar apenas em mais uma camada de governança, em vez de uma verdadeira capacidade corporativa.

Reflexão Final

A Arquitetura Salesforce nunca deveria se transformar em um museu de decisões que estavam corretas cinco anos atrás. Arquitetura precisa estar viva. Precisa preservar seu raciocínio. Precisa expor suas premissas. Precisa deixar seus trade-offs claros. Precisa reconhecer quando as circunstâncias mudaram. E precisa possuir uma governança capaz de questionar suas próprias decisões. É nesse ponto que vejo uma das conexões mais fortes entre pensamento CTA e maturidade de CoE.Um arquiteto em nível CTA não tenta provar que uma decisão é perfeita. Ele demonstra por que aquela é a decisão mais defensável considerando as restrições atuais. Um CoE maduro garante que a organização saiba quando essas restrições mudaram o suficiente para que a decisão precise ser novamente questionada.

Uma excelente arquitetura não é aquela que nunca muda. É aquela que sabe por que existe, compreende as condições nas quais suas decisões continuam válidas e consegue evoluir sem perder o controle do ambiente corporativo.O pensamento em nível CTA cria decisões defensáveis.A Arquitetura Salesforce conecta essas decisões em um sistema coerente. O CoE preserva, governa, mede e questiona essas decisões ao longo do tempo. Maturidade arquitetural não significa estar certo para sempre. Significa construir uma organização capaz de reconhecer quando aquilo que era “certo” mudou.