Arquitetura Salesforce Não É Sobre Escolher a Melhor Tecnologia, É Sobre Tomar as Decisões Corporativas Certas

Uma das lições mais importantes que aprendi trabalhando com arquitetura Salesforce é esta:

As decisões arquiteturais mais difíceis raramente são apenas decisões sobre Salesforce.

Em escala corporativa, a pergunta não é simplesmente: “Qual capacidade do Salesforce devemos utilizar?”

As verdadeiras perguntas são: Quem é responsável por essa capacidade? Quem é o owner dos dados? Quem é responsável pela decisão? O que acontece quando algo falha? Quem aceita o risco? E quem continuará responsável por tudo isso daqui a três anos?

É exatamente nesse ponto que Arquitetura Salesforce, pensamento em nível CTA e governança de Center of Excellence se encontram.

Uma Boa Arquitetura Resolve o Problema de Hoje. Uma Excelente Arquitetura Protege as Opções de Amanhã.

Projetos naturalmente possuem foco em entrega.

Existe um prazo. Existe um backlog. Existe um orçamento. Existe uma data de go-live.

A arquitetura precisa operar em um horizonte diferente.

Quando avalio uma solução Salesforce corporativa, não pergunto apenas: “Isso vai funcionar?”

Também quero entender:

• O que acontece quando o volume transacional aumentar 10 vezes?

• O que acontece quando outra unidade de negócio adotar a plataforma?

• O que acontece quando a empresa adquirir outra organização?

• O que acontece quando os requisitos regulatórios mudarem?

• O que acontece quando o atual System of Record for substituído?

• O que acontece quando o Agentforce precisar acessar essa capacidade?

• O que acontece quando os arquitetos que desenharam essa solução não estiverem mais na empresa?

É nesse ponto que a arquitetura deixa de ser apenas Solution Design e passa a ser Enterprise Design. Uma solução tecnicamente correta ainda pode ser estrategicamente errada.

O Pensamento em Nível CTA Começa pelos Direcionadores Arquiteturais, não pelos Produtos

Um antipadrão comum de arquitetura é começar pela tecnologia.

“Devemos usar Platform Events.”

“Precisamos de Data Cloud.”

“Vamos usar MuleSoft.”

“Isso deveria utilizar Agentforce.”

Talvez.

Mas primeiro: Qual problema arquitetural estamos realmente tentando resolver?

Uma abordagem em nível CTA começa identificando os direcionadores:

• Disponibilidade

• Escalabilidade

• Segurança

• Ownership dos dados

• Latência

• Requisitos regulatórios

• Resiliência

• Experiência do usuário

• Complexidade operacional

• Custo

• Time to market

Somente depois disso devemos escolher a tecnologia.

Porque a mesma capacidade Salesforce pode representar uma excelente decisão em uma arquitetura e uma péssima decisão em outra. Arquitetura depende de contexto.

O Salesforce CoE Deve Proteger a Intenção Arquitetural

Essa é uma das responsabilidades mais importantes de um Salesforce Center of Excellence maduro.

Projetos começam e terminam. Equipes mudam. Parceiros de implementação mudam. Prioridades mudam. A arquitetura precisa sobreviver a essas transições.

Imagine que a arquitetura original estabeleça: Salesforce é o System of Engagement. O Customer Master permanece externo. Seis meses depois, outra equipe decide criar clientes diretamente no Salesforce. Outro projeto introduz sincronização bidirecional. Outra integração começa a atualizar os mesmos atributos do cliente.

Eventualmente surge uma pergunta: Quem realmente é o owner do cliente?

Ninguém sabe. A arquitetura original talvez ainda exista em algum diagrama.

Mas sua intenção desapareceu. Isso é architectural drift, desvio arquitetural.

Um CoE maduro protege a intenção arquitetural por meio de:

• Princípios de arquitetura

• Architecture Decision Records

• Arquiteturas de referência

• Padrões de integração

• Modelos de ownership de dados

• Baselines de segurança

• Design Reviews

• Governança de exceções

• Gestão de dívida técnica

• Controles arquiteturais automatizados

O objetivo não é impedir mudanças.

O objetivo é garantir que as mudanças continuem sendo intencionais.

Governança de Arquitetura Não Pode se Transformar em Burocracia

Existe outro risco. A governança pode se tornar pesada demais. Se todo Flow precisar passar por uma reunião do Architecture Review Board, o modelo de governança falhou. Se os arquitetos se transformarem em gargalos de aprovação, eventualmente as equipes começarão a contorná-los. Um CoE maduro deve aplicar governança baseada em risco.

Por exemplo:

Baixo impacto arquitetural

Um novo relatório ou pequeno ajuste de interface.

A equipe de delivery deve possuir autonomia.

Impacto arquitetural moderado

Uma nova automação, extensão de integração ou alteração no modelo de dados.

Uma revisão arquitetural pode ser necessária.

Alto impacto arquitetural

Nova org, novo System of Record, grande mudança no padrão de integração, alteração da identidade do cliente, utilização de IA externa ou ação autônoma do Agentforce.

Nesse caso, uma governança arquitetural formal deve ser aplicada.

A governança deve aumentar de acordo com o blast radius (raio de impacto) da decisão.

Isso permite ao CoE proteger a empresa sem reduzir desnecessariamente a velocidade das equipes.

Dívida Técnica é Arquitetura com um Custo Futuro

Uma das responsabilidades que acredito que arquitetos deveriam levar mais a sério é a dívida técnica.

Dívida técnica nem sempre significa arquitetura ruim.

Às vezes, representa uma decisão de negócio deliberada.

Imagine que um prazo regulatório exija uma integração em oito semanas.

O padrão corporativo estratégico levaria doze semanas para ser implementado.

A organização pode decidir conscientemente utilizar uma solução tática.

Isso pode representar uma decisão arquitetural responsável.

Mas somente se documentarmos:

• Por que a decisão tática foi tomada

• Qual risco foi aceito

• Quem é responsável pela dívida

• Qual é a arquitetura target

• Quando a remediação deverá acontecer

• O que acontece se ela não acontecer

Caso contrário, arquitetura temporária se transforma em arquitetura permanente.

E três anos depois alguém pergunta: “Por que fizeram dessa forma?”

Ninguém lembra. É por isso que Architecture Decision Records são tão importantes.

Eles preservam não apenas a decisão. Eles preservam o raciocínio.

Um CoE Deve Criar Reutilização, não Apenas Padrões

Outro importante nível de maturidade acontece quando o CoE deixa de apenas dizer às equipes o que devem fazer e passa a tornar mais fácil fazer a coisa certa.

Em vez de simplesmente publicar: “Todas as integrações devem seguir nosso padrão corporativo.”

Forneça:

• Padrões reutilizáveis de APIs

• Frameworks para Platform Events

• Componentes de logging

• Padrões de tratamento de erros

• Templates de CI/CD

• Configurações de segurança

• Padrões de observabilidade

• Implementações de referência

Em vez de dizer: “Agentforce deve seguir nossa governança de IA responsável.”

Forneça:

• Classificação de risco dos agentes

• Templates de avaliação

• Padrões aprovados de grounding

• Padrões de human-in-the-loop

• Regras de autorização para ações

• Requisitos de auditoria

• Dashboards de monitoramento

Isso transforma o CoE de uma organização de controle em uma organização de enablement.

A melhor governança reduz fricção.

Agentforce Torna a Governança Arquitetural Ainda Mais Importante

A arquitetura tradicional controla o que o software pode fazer. A arquitetura agentic também precisa controlar o que o software possui autorização para decidir e executar. Essa diferença é significativa.

Considere três capacidades do Agentforce:

1. Resumir um Case.

2. Recomendar um reembolso para um cliente.

3. Executar automaticamente um reembolso de US$ 10.000.

Tecnicamente, as três podem ser possíveis.

Arquiteturalmente, são completamente diferentes.

O arquiteto e o CoE precisam perguntar:

• Quais dados o agente pode acessar?

• Qual fonte de grounding é autoritativa?

• Quais ações ele pode executar?

• O que exige confirmação humana?

• Qual valor monetário exige aprovação?

• Como avaliamos o agente antes de produção?

• Como monitoramos decisões incorretas?

• Como reconstruímos o que aconteceu durante um incidente?

• Quem é responsável pela ação autônoma?

É por isso que a arquitetura de Agentforce não pode ser separada da governança corporativa.

A IA introduz uma nova dimensão arquitetural: autoridade delegada.

Arquitetos em Nível CTA Pensam em Modos de Falha

Uma das características que diferencia arquitetura de simples configuração de solução é pensar sobre a falha antes que ela aconteça. Para cada decisão arquitetural importante, pergunte: “Como isso pode falhar?”

Para uma integração:

• O que acontece se o sistema de destino estiver indisponível?

• O que acontece se uma mensagem for duplicada?

• O que acontece se o processamento ocorrer fora de ordem?

• O que acontece se Salesforce concluir a operação, mas a transação downstream falhar?

Para dados:

• O que acontece se dois sistemas atualizarem o mesmo cliente?

• Como reconciliamos inconsistências?

• Qual sistema prevalece?

Para Agentforce:

• O que acontece se as informações utilizadas para grounding estiverem incompletas?

• O que acontece se uma ação falhar no meio da execução?

• Como o agente realiza o escalonamento?

• A transação pode ser revertida?

Isso não é pessimismo. Isso é Reliability Engineering. A arquitetura está incompleta enquanto seu modelo de falhas não for compreendido.

Os Melhores CoEs Eventualmente se Tornam Menos Visíveis

Existe um ponto interessante na maturidade de um Salesforce CoE. Inicialmente, o CoE pode precisar exercer forte controle centralizado. Mas, ao longo do tempo, boas práticas arquiteturais devem se tornar parte natural do delivery.

As equipes deveriam automaticamente:

• Seguir padrões de segurança

• Reutilizar padrões de integração

• Documentar decisões arquiteturais

• Medir dívida técnica

• Aplicar controles de DevSecOps

• Avaliar soluções Agentforce

• Monitorar a saúde da plataforma

A governança arquitetural torna-se progressivamente mais automatizada e distribuída.

O CoE evolui de: “Aprovar tudo.”

para: “Definir guardrails, automatizar controles, habilitar as equipes e intervir onde o risco é maior.”

Isso é maturidade arquitetural.

A Conexão entre CTA, Arquitetura e CoE

Para mim, esses três conceitos representam diferentes níveis da mesma disciplina.

Salesforce Architecture pergunta: Como devemos desenhar esta solução de forma responsável?

Pensamento em nível CTA pergunta: Consigo explicar e defender por que este é o melhor compromisso considerando estas restrições?

Salesforce CoE pergunta: Como tornamos essa qualidade de decisão arquitetural repetível em toda a organização?

Essa progressão é importante. Um bom Solution Architect pode melhorar um projeto. Um bom Technical Architect pode melhorar uma plataforma. Um CoE maduro pode melhorar o sistema de tomada de decisões de toda a organização. É nesse momento que a arquitetura realmente se torna estratégica.

Reflexão Final

O valor de um Salesforce Architect não é medido pela quantidade de tecnologias que consegue colocar em um diagrama. É medido pela qualidade das decisões que existem por trás daquele diagrama. O valor de um CTA não está simplesmente em conhecer mais Salesforce. Está em demonstrar capacidade de raciocinar sobre negócio, dados, segurança, integração, identidade, operações, risco e restrições organizacionais. E o valor de um Salesforce CoE não está na quantidade de padrões publicados. Está em saber se a organização toma decisões arquiteturais melhores porque o CoE existe.

Uma excelente arquitetura Salesforce não é criada escolhendo mais tecnologia. Ela é criada tomando decisões melhores. O pensamento em nível CTA desenvolve o julgamento necessário para tomar essas decisões, enquanto um Salesforce CoE maduro transforma esse julgamento em uma capacidade corporativa repetível. O objetivo final não é criar governança de arquitetura simplesmente pela governança. É construir uma organização capaz de avançar mais rápido sem perder a disciplina arquitetural à medida que cresce.