Salesforce CTA Não É Apenas Sobre Arquitetura, É Sobre Governar a Arquitetura em Escala

Um dos maiores equívocos no ecossistema Salesforce é acreditar que ser um bom arquiteto significa principalmente desenhar a solução técnica correta.

Isso é apenas parte do trabalho.

Em escala corporativa, a arquitetura raramente falha porque alguém escolheu a funcionalidade errada.

Ela falha porque a organização não consegue tomar, aplicar e evoluir boas decisões arquiteturais de forma consistente.

É exatamente nesse ponto que o pensamento em nível CTA e um Salesforce Center of Excellence maduro se encontram.

Um Salesforce CTA precisa ser capaz de raciocinar sobre múltiplos domínios:

• Arquitetura de negócio

• Arquitetura de dados

• Segurança

• Integração

• Identidade

• Application Design

• DevOps

• Confiabilidade

• Governança

• Modelo operacional

Mas o verdadeiro desafio começa depois que a arquitetura foi desenhada.

Quem é responsável pela decisão?

Quem garante que o padrão seja seguido?

Quem aprova uma exceção?

Quem financia a remediação?

Quem monitora se aquela arquitetura continua válida seis meses depois?

Isso não é apenas Solution Architecture.

Isso é governança de arquitetura.

Um Salesforce CoE maduro não deveria ser simplesmente um grupo que se reúne uma vez por mês para revisar diagramas.

Ele deve funcionar como um mecanismo corporativo para manter a coerência arquitetural.

Isso significa definir:

• Princípios arquiteturais

• Padrões aprovados

• Direitos de decisão

• Critérios do Architecture Review Board

• Gestão de exceções

• Governança de dívida técnica

• Padrões não funcionais

• Baselines de segurança

• Padrões de integração

• Ownership de dados

• Controles de DevSecOps

• Governança do Agentforce

Sem esses mecanismos, até mesmo uma boa arquitetura começa a se deteriorar.

Um projeto pode começar com uma estratégia de integração muito bem definida.

Depois, uma equipe cria um atalho.

Outra equipe introduz um segundo padrão.

Uma terceira equipe ignora o middleware.

Seis meses depois, a organização já não possui uma arquitetura de integração.

Ela possui um histórico de integrações.

O mesmo acontece com os dados.

Um projeto define Salesforce como System of Engagement.

Outro começa a atualizar diretamente os dados master.

Outro implementa sincronização bidirecional sem restrições.

Em pouco tempo, ninguém consegue responder claramente:

Quem realmente é o responsável pelo registro do cliente?

Isso é architectural drift — desvio arquitetural.

E prevenir esse tipo de desvio é exatamente uma das responsabilidades de um CoE maduro.

O Pensamento CTA Vai Além de “O Que Devemos Construir?”

Um arquiteto em nível CTA não termina seu trabalho dizendo:

“Esta é a solução correta.”

As próximas perguntas são:

• Como esse desenho permanecerá consistente?

• Como outras equipes reutilizarão esse padrão?

• Como os desvios serão identificados?

• Quem pode aprovar uma exceção?

• Quais métricas demonstrarão que a arquitetura continua saudável?

• O que acontece quando o negócio mudar?

Essa é a diferença entre desenhar um projeto e desenhar uma capacidade corporativa.

Um projeto otimiza para entrega.

Arquitetura corporativa otimiza para mudança sustentável.

Arquitetura sem Direito de Decisão é Apenas uma Recomendação

Um dos problemas mais comuns que observo em Salesforce CoEs é existir responsabilidade sem autoridade.

O CoE recebe a responsabilidade de:

• Proteger a saúde da plataforma

• Reduzir dívida técnica

• Melhorar segurança

• Padronizar integrações

• Governar IA

• Controlar releases

Mas as equipes de delivery podem ignorar os padrões quando os prazos ficam apertados.

Isso não é governança.

Se um grupo de arquitetura não possui direitos de decisão claramente definidos, suas recomendações são opcionais.

Um modelo operacional maduro deve deixar claro:

• Quais decisões pertencem às equipes de delivery

• Quais exigem aprovação do Solution Architect

• Quais exigem revisão do Technical Architect

• Quais precisam passar pelo Architecture Review Board

• Quais exigem aceite de Security ou Risk

• Quais precisam ser escaladas para a liderança executiva

Governança funciona quando a autoridade de decisão é explícita.

Dívida Técnica Também é um Problema de Governança

Dívida técnica é frequentemente tratada como um problema dos desenvolvedores.

Não é.

Grande parte da dívida técnica significativa começa com uma decisão arquitetural.

Às vezes, essa decisão é intencional:

“Utilizaremos temporariamente uma integração ponto a ponto para cumprir o prazo regulatório.”

Isso pode ser aceitável.

A falha acontece quando ninguém registra:

• Por que a exceção existe

• Quem é responsável pela remediação

• Quando ela deverá ser removida

• Qual risco ela cria

• O que acontece se permanecer

Um CoE maduro deve tratar dívida técnica como um portfólio de riscos aceitos.

Não como um backlog misterioso que cresce indefinidamente.

Arquitetos em nível CTA devem tornar a dívida visível no momento em que ela é criada.

Agentforce Eleva Novamente o Nível de Governança

O Agentforce torna tudo isso ainda mais importante.

A governança tradicional de Salesforce já precisa controlar:

• Dados

• Automação

• Segurança

• Integração

• Releases

Agora precisamos adicionar:

• Autonomia dos agentes

• Grounding

• Governança de prompts e instruções

• Autorização de ações

• Human-in-the-loop

• Testes de IA

• Observabilidade

• Escalonamento

• Auditabilidade

Uma implementação de Agentforce não pode ser governada exatamente como uma funcionalidade tradicional.

Um agente autônomo introduz autoridade delegada.

Portanto, a pergunta arquitetural deixa de ser apenas:

“O agente consegue executar essa ação?”

E passa a ser:

“O agente deveria ter autoridade para executar essa ação sem aprovação humana?”

Essa é uma decisão de governança.

Por exemplo:

Um agente resumindo um Case representa um risco relativamente baixo.

Um agente alterando uma preferência de contato pode representar risco moderado.

Um agente aprovando um ajuste financeiro pode representar risco elevado.

Esses três cenários não deveriam seguir exatamente o mesmo processo de governança.

Um CoE maduro deve estabelecer uma governança de Agentforce baseada em risco.

A Maturidade do CoE Precisa Ser Mensurável

Um CoE não deveria medir seu sucesso pela quantidade de reuniões realizadas.

Ele deve medir resultados.

Alguns exemplos:

• Adoção dos padrões arquiteturais

• Quantidade de exceções não controladas

• Aging da dívida técnica

• Taxa de sucesso dos releases

• Redução de incidentes de segurança

• Taxa de falhas de integração

• Estabilidade da plataforma

• Reutilização de capacidades compartilhadas

• Tempo necessário para decisões arquiteturais

• Percentual de controles de governança automatizados

• Taxa de sucesso das avaliações do Agentforce

• Incidentes de IA ou intervenções humanas

Se a governança não pode ser medida, ela se torna subjetiva.

E governança subjetiva eventualmente se transforma em governança política.

A Conexão entre CTA e CoE

O pensamento em nível CTA desenvolve a capacidade de tomar decisões arquiteturais de alta qualidade em ambientes de ambiguidade.

Um CoE maduro institucionaliza essa mesma disciplina para que a organização não dependa de um único arquiteto.

Essa diferença é importante.

Um excelente arquiteto pode melhorar um programa.

Um excelente CoE pode melhorar a maneira como centenas de equipes tomam decisões.

O arquiteto se torna escalável por meio da governança.

Para mim, essa é uma das conexões mais importantes entre CTA e maturidade de CoE.

O pensamento CTA pergunta:

Qual é a arquitetura mais defensável dentro deste contexto?

O pensamento de CoE pergunta:

Como garantimos que a organização continue tomando decisões arquiteturais defensáveis depois que este projeto terminar?

Essas duas disciplinas precisam trabalhar juntas.

Reflexão Final

Arquitetura não é apenas o desenho que aprovamos hoje.

Arquitetura é o acúmulo das decisões que uma organização toma ao longo do tempo.

Se essas decisões forem inconsistentes, não documentadas, politicamente direcionadas ou impossíveis de aplicar, a plataforma eventualmente perderá sua coerência.

As organizações Salesforce mais maduras fazem mais do que contratar excelentes arquitetos.

Elas constroem um modelo operacional no qual boa arquitetura se torna repetível.

Isso exige:

• Arquitetos qualificados

• Direitos claros de decisão

• Forte governança arquitetural

• Architecture Decision Records

• Revisões baseadas em risco

• Controles automatizados

• Ownership da dívida técnica

• Resultados mensuráveis

• Um CoE capaz de evoluir junto com a plataforma

E, cada vez mais, exige uma governança preparada para um mundo em que Salesforce não apenas executa workflows, mas no qual o Agentforce também começa a participar das decisões.

O Salesforce CTA demonstra a capacidade de tomar decisões arquiteturais responsáveis em ambientes complexos. Um Salesforce CoE maduro transforma essa capacidade em um modelo operacional corporativo. O verdadeiro objetivo não é produzir uma excelente arquitetura uma única vez. É construir uma organização capaz de criar, governar, sustentar e evoluir excelentes arquiteturas de forma consistente e em escala.