A Estratégia Multi-Org Salesforce é uma Decisão de Arquitetura Organizacional

Poucos temas de arquitetura Salesforce geram tanto debate quanto a decisão entre uma estratégia de org única e uma estratégia multi-org.

A discussão normalmente começa com perguntas técnicas:

· Uma única org consegue suportar o volume esperado de dados?

· Qual será a complexidade do modelo de compartilhamento?

· Como as integrações funcionarão entre diferentes orgs?

· As unidades de negócio poderão realizar releases de forma independente?

· Como os dados dos clientes serão sincronizados?

· Quais serão os impactos de licenciamento e suporte?

Essas perguntas são importantes. Entretanto, não revelam a natureza completa da decisão.

Uma org Salesforce não é apenas um contêiner técnico para metadados e registros. Ela estabelece limites para identidade, dados, segurança, automação, gestão de releases, administração, ownership operacional e controle organizacional.

A quantidade de orgs Salesforce operadas por uma empresa normalmente reflete como essa empresa distribui autoridade.

Uma estratégia de org única exige, em geral, grande alinhamento sobre processos compartilhados, definições de dados, padrões de governança, prioridades de release e políticas de segurança.

Uma estratégia multi-org pode oferecer maior autonomia, isolamento ou separação regulatória, mas introduz complexidade adicional em integração, identidade, consistência de dados, DevOps, analytics, governança e operações.

Por isso, a estratégia de orgs não deve ser tratada como uma decisão de configuração de plataforma.

Ela é uma decisão de arquitetura organizacional expressa por meio da tecnologia.

A Forma Errada de Iniciar a Discussão

Muitas conversas sobre estratégia de orgs começam com uma resposta preferida.

Um arquiteto pode afirmar: “Uma única org é sempre mais eficiente.”

Outro pode argumentar: “Múltiplas orgs são mais seguras e escaláveis.”

As duas afirmações são incompletas.

Nem uma arquitetura single-org nem uma arquitetura multi-org é inerentemente madura.

Uma única org mal governada pode se transformar em um monólito altamente acoplado, no qual toda alteração cria riscos para toda a empresa.

Um ambiente multi-org mal governado pode se tornar uma paisagem fragmentada de dados duplicados, processos inconsistentes, integrações sem controle e experiências conflitantes para os clientes.

A pergunta correta não é: “Qual modelo é melhor?”

A pergunta correta é: “Qual modelo representa melhor a estrutura de negócio, os limites regulatórios, o modelo operacional, a tolerância a riscos e a estratégia de longo prazo da empresa?”

O objetivo não é minimizar o número de orgs a qualquer custo. Também não é criar uma org separada sempre que surgir um desacordo organizacional. O objetivo é estabelecer os limites corretos.

O que um Limite de Org Realmente Representa

O limite de uma org influencia muito mais do que o armazenamento dos dados.

Ele estabelece uma fronteira para:

Configuração e customização Os metadados são implementados, testados, implantados e governados dentro da org.

Segurança Usuários, permissões, compartilhamento, configurações de criptografia, recursos de auditoria e políticas de segurança são administrados dentro desse limite.

Dados Registros, ownership, retenção, duplicação e modelos de acesso são fortemente influenciados pela separação entre orgs.

Automação Flows, Apex, processos de aprovação, eventos e ações de agentes operam dentro de um determinado contexto de execução.

Gestão de releases Equipes que compartilham uma org também compartilham dependências de deployment, riscos de regressão e coordenação de releases.

Operações Monitoramento, gestão de incidentes, suporte, capacidade e dívida técnica exigem ownership.

Governança Padrões, exceções, decisões arquiteturais e controle administrativo devem ser aplicados dentro e entre as orgs.

Inteligência artificial Agentes do Agentforce, fontes de grounding, ações, controles de acesso e políticas de autonomia também são afetados pelos limites das orgs.

Uma org representa, portanto, tanto uma fronteira técnica quanto uma fronteira do modelo operacional. Criar uma nova org modifica quem controla o quê, quem depende de quem e como a empresa coordena mudanças.

Quando uma Estratégia Single-Org é Atraente

Uma estratégia de org única pode oferecer vantagens significativas quando a organização possui forte necessidade de padronização e compartilhamento.

Os benefícios típicos incluem:

· Informações compartilhadas de clientes e contas

· Processos de negócio padronizados

· Políticas de segurança consistentes

· Governança centralizada da plataforma

· Menor necessidade de integração entre ambientes Salesforce

· Analytics unificado

· Maior reutilização das capacidades da plataforma

· DevOps e operações consolidados

· Experiência mais consistente para os usuários

· Menor duplicação de metadados e dados

Uma única org normalmente é atraente quando:

· As unidades de negócio atendem os mesmos clientes

· Os processos são semelhantes ou podem ser padronizados

· Os limites regulatórios permitem dados compartilhados

· A organização possui governança centralizada

· Os releases podem ser coordenados

· As capacidades compartilhadas geram valor significativo

· Os modelos corporativos de identidade e clientes estão alinhados

Por exemplo, uma empresa global pode desejar uma única plataforma de atendimento para que todas as equipes visualizem o mesmo histórico de interações, independentemente da região.

Uma estratégia single-org pode permitir:

· Visibilidade global de Casos

· Knowledge compartilhado

· Regras consistentes de entitlement

· Identidade unificada do cliente

· Analytics corporativo de atendimento

· Capacidades reutilizáveis de Agentforce

Nesse cenário, o valor do contexto compartilhado pode superar a complexidade da coordenação regional.

O Custo Oculto de uma Única Org

Uma única org não elimina complexidade. Ela concentra essa complexidade.

À medida que mais unidades, países, produtos e equipes compartilham o mesmo ambiente, a org pode acumular:

· Modelos complexos de compartilhamento

· Grande quantidade de Permission Sets

· Proliferação de Record Types

· Automações excessivamente condicionais

· Integrações altamente acopladas

· Calendários de release conflitantes

· Prioridades de produto concorrentes

· Disputas sobre ownership de metadados

· Grande escopo de testes de regressão

· Regras difíceis de retenção de dados

Uma única org pode se tornar a expressão técnica de conflitos organizacionais não resolvidos.

Por exemplo, cinco regiões podem compartilhar, em princípio, o mesmo processo de atendimento, mas cada uma pode solicitar diferentes:

· Status de Caso

· Regras de atribuição

· Modelos de escalonamento

· Layouts

· Cálculos de nível de serviço

· Controles regulatórios

· Comportamentos de integração

Se toda variação regional for implementada por novas condições, exceções e customizações, a org ficará cada vez mais difícil de compreender e modificar. O objetivo original de consolidação pode produzir uma plataforma fortemente acoplada, em que a inovação local é lenta e os releases globais tornam-se arriscados. Uma estratégia single-org funciona melhor quando a organização está preparada para padronizar, e não apenas coexistir.

Quando Múltiplas Orgs Podem Ser Justificadas

Múltiplas orgs podem ser apropriadas quando a empresa exige separação mais forte.

Os principais direcionadores incluem:

· Isolamento regulatório

· Residência de dados

· Separação de entidades legais

· Modelos de negócio independentes

· Forte autonomia regional

· Populações distintas de clientes

· Empresas operacionais separadas

· Fusões e aquisições

· Ciclos independentes de release

· Contenção de riscos

· Limites distintos de segurança

· Preparação para desinvestimentos

Considere um grupo financeiro que opera negócios bancários, seguros e investimentos.

Mesmo que os três utilizem Salesforce, eles podem possuir diferentes:

· Obrigações regulatórias

· Restrições de acesso a dados

· Modelos de produto

· Controles de segurança

· Requisitos de retenção

· Processos de auditoria

· Equipes operacionais

Uma estratégia multi-org pode oferecer isolamento mais claro do que tentar representar todos os limites regulatórios e organizacionais dentro de um único modelo altamente complexo de compartilhamento. Da mesma forma, uma empresa adquirida pode manter sua org temporariamente porque a consolidação imediata criaria riscos excessivos de transformação. Nos dois casos, múltiplas orgs podem representar uma decisão arquitetural deliberada, e não uma falha de padronização.

O Custo Oculto de Múltiplas Orgs

Uma arquitetura multi-org cria fronteiras, mas essas fronteiras precisam estar conectadas.

A empresa deve tratar:

· Identidade de clientes entre orgs

· Sincronização de dados

· Duplicação de integrações

· Orquestração de processos compartilhados

· Analytics consolidado

· Padrões comuns de segurança

· Provisionamento de usuários

· Consistência de DevOps

· Reutilização de metadados

· Monitoramento

· Coordenação de incidentes

· Alinhamento de releases

· Custos de licenciamento e suporte

Sem governança corporativa, cada org pode evoluir de forma independente.

Com o tempo, a organização pode criar:

· Definições diferentes de cliente

· Integrações duplicadas

· Semânticas conflitantes de campos

· Configurações inconsistentes de segurança

· Backlogs separados de dívida técnica

· Padrões diferentes de desenvolvimento

· Ações duplicadas do Agentforce

· Jornadas fragmentadas para os clientes

Uma arquitetura multi-org pode reduzir a complexidade local e aumentar a complexidade corporativa. O custo não desaparece. Ele se move da estrutura interna de uma org para os relacionamentos entre várias orgs.

A Estratégia de Orgs Está Conectada à Arquitetura de Negócio

Uma boa avaliação começa pelo modelo de negócio da organização.

Os arquitetos devem compreender:

· Capacidades de negócio

· Cadeias de valor

· Segmentos de clientes

· Entidades legais

· Portfólios de produtos

· Estruturas regionais

· Empresas operacionais

· Serviços compartilhados

· Autoridade de decisão

· Modelos de financiamento

Se duas unidades compartilham clientes, processos, ownership de dados e governança, separá-las pode gerar fragmentação desnecessária. Se possuem clientes, regulações, financiamento, operações e ciclos de produto independentes, forçá-las em uma única org pode criar acoplamento desnecessário. A paisagem de orgs deve refletir fronteiras corporativas significativas.

Ela não deve simplesmente reproduzir cada departamento do organograma. Estruturas organizacionais mudam frequentemente. Uma arquitetura baseada apenas nas linhas atuais de reporte pode se tornar obsoleta depois da próxima reorganização.

Direcionadores mais estáveis incluem:

· Limites regulatórios

· Ownership de dados

· Capacidades de negócio

· Autonomia operacional

· Domínios de risco

· Relacionamentos com clientes

· Independência de ciclo de vida

O Isolamento Regulatório Deve Ser Avaliado Cuidadosamente

A regulamentação é frequentemente citada como justificativa para novas orgs. Às vezes, essa justificativa é válida. Em outras situações, “requisito regulatório” é utilizado como uma forma resumida de descrever uma preferência que não foi totalmente analisada.

Os arquitetos devem perguntar:

· A regulamentação exige explicitamente separação física ou lógica?

· O requisito pode ser atendido por controles de segurança Salesforce?

· Existe exigência de residência regional de dados?

· Administradores podem acessar informações entre jurisdições?

· Chaves de criptografia ou registros de auditoria precisam ser separados?

· Políticas distintas de retenção são exigidas?

· A entidade legal precisa de controle operacional independente?

· O ambiente deve suportar auditorias regulatórias independentes?

Uma nova org não deve ser criada apenas porque o desenho de segurança é difícil. Entretanto, uma única org não deve ser imposta quando o isolamento necessário depender de controles frágeis, excessivamente complexos ou operacionalmente irrealistas. A decisão apropriada deve se basear em evidências, risco e capacidade de aplicação dos controles.

A Arquitetura de Dados Frequentemente Determina a Decisão

Estratégia de orgs e estratégia de dados não podem ser separadas.

O arquiteto deve determinar:

· Quais domínios de dados são compartilhados?

· Quais sistemas são autoritativos?

· Quais registros precisam ser visíveis entre unidades?

· Quais informações podem atravessar as fronteiras?

· Como a identidade será resolvida?

· Como duplicações serão evitadas?

· Como a qualidade será medida?

· Como exclusão e retenção serão coordenadas?

Em uma única org, o compartilhamento pode melhorar a visão do cliente, mas criar requisitos complexos de ownership e acesso.

Em múltiplas orgs, o ownership local pode ser mais claro, mas a empresa precisa determinar como formar uma visão corporativa do cliente.

Os padrões possíveis incluem:

· Master Data Management

· Resolução de identidade pelo Data Cloud

· Serviços externos de customer master

· Sincronização orientada a eventos

· Replicação seletiva

· Acesso virtualizado ou federado

· Plataformas corporativas de dados

· Relatórios cross-org

A resposta correta raramente é “sincronizar tudo”. Os dados devem atravessar os limites das orgs somente quando existir uma finalidade clara de negócio, operação, análise ou regulação.

A Identidade se Torna Mais Complexa em uma Paisagem Multi-Org

Múltiplas orgs podem criar desafios importantes de identidade.

A empresa deve decidir:

· Os usuários terão identidades separadas em cada org?

· Será utilizado Single Sign-On?

· Como usuários serão provisionados e desprovisionados?

· Como roles e permissões permanecerão consistentes?

· Como identidades de integração serão administradas?

· Um usuário pode atuar em várias entidades legais?

· Como acessos privilegiados serão monitorados?

· Como clientes circularão entre experiências digitais?

Um provedor de identidade compartilhado pode simplificar autenticação, mas não resolve autorização. Um usuário pode autenticar centralmente e precisar de acessos muito diferentes em cada org.

A empresa também precisa de estratégia para identidades externas:

· Clientes

· Parceiros

· Corretores

· Agentes

· Fornecedores

· Contratados

Uma arquitetura inadequada de identidade aumenta risco de segurança e overhead operacional. Por isso, o modelo de identidade deve ser um input de primeira classe na estratégia de orgs, e não um detalhe tratado depois da criação dos ambientes.

A Arquitetura de Integração Deve Evitar uma Malha de Orgs

Um antipadrão comum em multi-org é conectar cada org diretamente a todas as outras. À medida que o número de orgs cresce, a quantidade de relacionamentos potenciais aumenta rapidamente.

Isso cria uma malha com:

· APIs ponto a ponto

· Lógicas duplicadas de negócio

· Transformações distintas de dados

· Comportamentos inconsistentes de retry

· Observabilidade limitada

· Cadeias complexas de dependência

Uma arquitetura multi-org madura utiliza princípios corporativos de integração.

Eles podem incluir:

· APIs canônicas

· Serviços de domínio

· Brokers de eventos

· Orquestração por middleware

· Serviços compartilhados de identidade

· Serviços de master data

· Monitoramento central

· Contratos versionados

O objetivo não é necessariamente enviar todas as interações por uma única plataforma central. É evitar dependências bilaterais sem controle. Cada org deve integrar-se às capacidades corporativas, e não se transformar em um novo hub de integração.

DevOps e Independência de Releases São Direcionadores Relevantes

A autonomia de release é frequentemente um dos argumentos mais fortes para múltiplas orgs.

Equipes em ambientes separados podem:

· Manter calendários independentes

· Reduzir o escopo de regressão entre times

· Priorizar necessidades locais

· Isolar falhas de deployment

· Utilizar cadências distintas de ciclo de vida

Entretanto, essa independência cria um desafio de governança.

A empresa ainda precisa manter consistência em:

· Controle de versão

· Padrões de deployment

· Security scanning

· Gates de qualidade

· Gestão de ambientes

· Versionamento de metadados

· Evidências de release

· Monitoramento de produção

Em uma única org, as equipes precisam coordenar-se mais. Isso pode reduzir velocidade, mas também incentivar padronização e reutilização. A escolha depende parcialmente de a organização obter mais valor de mudanças compartilhadas ou independentes. O arquiteto não deve avaliar independência de release apenas como conveniência técnica. Ela reflete ownership de produto e autonomia organizacional.

Multi-Org Não Significa Múltiplos Padrões

Uma estratégia multi-org não deve permitir que cada org estabeleça práticas completamente diferentes de arquitetura e engenharia.

Um Salesforce CoE maduro deve definir padrões corporativos para:

· Segurança

· Integração

· Classificação de dados

· DevOps

· Monitoramento

· Nomenclatura

· Documentação

· Gestão de APIs

· Identidade

· Governança do Agentforce

· Dívida técnica

· Continuidade de negócio

Cada org pode implementar variações locais, mas elas devem existir dentro de guardrails definidos.

Por exemplo, orgs regionais podem possuir processos diferentes de atendimento e ainda compartilhar:

· Identificadores corporativos de clientes

· Baselines de segurança

· Contratos de eventos

· Controles de CI/CD

· Requisitos de auditoria

· Padrões de observabilidade

A federação deve permitir autonomia sem abandonar a coerência.

O Agentforce Adiciona uma Nova Dimensão à Estratégia de Orgs

O Agentforce introduz novas perguntas na decisão entre single-org e multi-org.

Os arquitetos precisam considerar:

· Onde os agentes serão criados e administrados

· Qual org será responsável por tópicos e ações compartilhados

· Quais fontes de dados poderão ser acessadas

· Se agentes poderão executar ações entre orgs

· Como a identidade do agente será propagada

· Como prompts e instruções serão padronizados

· Como ações autônomas serão auditadas

· Como conversas de clientes serão transferidas entre orgs

· Como evitar capacidades duplicadas de agentes

Em uma única org, o Agentforce pode acessar com maior facilidade um contexto compartilhado e ações reutilizáveis. Entretanto, a governança torna-se crítica, pois um agente pode operar em múltiplas unidades e domínios de dados. Em uma arquitetura multi-org, os agentes podem se alinhar mais claramente a limites regulatórios e operacionais locais. Porém, a organização pode criar agentes duplicados, comportamentos inconsistentes, experiências fragmentadas e orquestração cross-org complexa.

A empresa pode precisar de um modelo de portfólio que diferencie:

· Agentes corporativos

· Agentes de domínio

· Agentes regionais

· Agentes para colaboradores

· Agentes para clientes

Os limites dos agentes devem estar alinhados à autoridade, acesso aos dados, risco e accountability. Eles não devem apenas replicar o número de orgs Salesforce.

Fusões, Aquisições e Desinvestimentos Alteram a Decisão

Atividades de M&A são grandes direcionadores da estratégia.

Ao adquirir uma empresa, a organização precisa decidir se irá:

· Manter a org adquirida

· Migrá-la para uma org existente

· Criar uma nova org compartilhada

· Integrar temporariamente e consolidar depois

· Manter separação permanente

A consolidação imediata pode parecer eficiente, mas criar riscos relevantes.

A empresa adquirida pode ter:

· Produtos diferentes

· Qualidade distinta de dados

· Obrigações diferentes de segurança

· Integrações próprias

· Processos operacionais diferentes

· Maturidade distinta de releases

Um modelo multi-org transitório pode ser apropriado. Entretanto, estados temporários precisam de critérios explícitos de saída. Sem uma decisão de target state, orgs transitórias podem se tornar permanentes por inércia. Desinvestimentos criam a preocupação inversa. Uma única org altamente consolidada pode tornar a separação extremamente difícil.

Os arquitetos devem considerar a opcionalidade organizacional:

· Uma unidade pode ser separada?

· Os dados podem ser extraídos de forma limpa?

· As integrações estão organizadas por domínio?

· Os limites de segurança e metadados são compreensíveis?

· As capacidades compartilhadas estão documentadas?

A estratégia deve apoiar mudanças estruturais prováveis, e não apenas o estado atual.

O Custo Total Deve Ser Avaliado em Nível Corporativo

A comparação de custos entre single-org e multi-org costuma ser simplificada em excesso.

Uma única org pode reduzir:

· Duplicação de ambientes

· Integração entre orgs

· Administração da plataforma

· Reconciliação de dados

· Capacidades duplicadas

Mas pode aumentar:

· Coordenação de releases

· Testes de regressão

· Complexidade de compartilhamento

· Overhead de governança

· Raio de impacto das mudanças

· Tempo para entregar requisitos locais

Múltiplas orgs podem aumentar autonomia e isolamento, mas também ampliar:

· Licenciamento

· Ferramentas DevOps

· Equipes de suporte

· Monitoramento

· Integração

· Gestão de identidade

· Sincronização de dados

· Consolidação analítica

· Desenvolvimento duplicado

A comparação correta não se limita ao custo de licenças.

Ela deve considerar o custo total de propriedade em:

· Entrega

· Operações

· Governança

· Segurança

· Integração

· Dados

· Gestão da mudança

· Dívida técnica

· Transformações futuras

Uma estratégia aparentemente mais barata pode gerar custos operacionais de longo prazo muito maiores.

Um Framework Prático de Decisão

Uma avaliação estruturada pode considerar diversas dimensões.

Alinhamento com o negócio

· Os processos são compartilhados?

· Os clientes são compartilhados?

· Produtos e cadeias de valor estão conectados?

· É necessária autonomia operacional?

Regulatório e segurança

· O isolamento legal ou regulatório é obrigatório?

· Existem limites de residência de dados?

· Um único modelo de segurança permanecerá administrável?

· Qual é o raio de impacto aceitável?

Dados

· É necessária uma visão compartilhada do cliente?

· Quais sistemas são autoritativos?

· Os dados podem atravessar os limites?

· Como identidade e consentimento serão administrados?

Entrega e operações

· Os calendários de release são compatíveis?

· As equipes podem compartilhar um backlog?

· É necessário isolamento independente de falhas?

· Quem dará suporte a cada org?

Arquitetura

· Quanto da configuração pode ser reutilizado?

· Qual modelo de integração conectará as orgs?

· Requisitos não funcionais serão atendidos?

· Como a dívida técnica será governada?

Financeiro

· Qual é o custo total de propriedade?

· Quem financia capacidades compartilhadas?

· Como serviços duplicados serão controlados?

Mudança estratégica

· Aquisições ou desinvestimentos são prováveis?

· As regiões crescerão de forma independente?

· O modelo operacional está se tornando mais centralizado ou federado?

IA e Agentforce

· Quais agentes exigem contexto corporativo?

· Onde a autoridade dos agentes deve ser limitada?

· Como a governança permanecerá consistente?

· Como o comportamento será monitorado entre orgs?

Nenhuma dimensão isolada deve decidir o resultado.

A resposta surge do padrão combinado.

Documente a Decisão em um ADR

Como a estratégia possui consequências de longo prazo, ela deve ser registrada em um Architecture Decision Record.

O ADR deve incluir:

· Contexto de negócio

· Direcionadores arquiteturais

· Restrições regulatórias

· Premissas

· Opções consideradas

· Decisão

· Trade-offs

· Riscos

· Mitigações

· Implicações financeiras

· Abordagem de migração

· Gatilhos de revisão

Os gatilhos podem incluir:

· Aquisição

· Desinvestimento

· Grande mudança regulatória

· Crescimento relevante do volume de dados

· Nova capacidade global de negócio

· Incapacidade de cumprir metas de release

· Integração cross-org excessiva

· Mudança na estratégia de identidade do cliente

· Adoção corporativa do Agentforce

A estratégia não deve ser reconsiderada a cada trimestre.

Mas também não deve se tornar uma doutrina permanente.

Antipadrões Comuns na Estratégia de Orgs

Uma única org a qualquer custo A empresa força todas as diferenças para um único ambiente, gerando acoplamento excessivo e complexidade de governança.

Uma org por unidade de negócio A paisagem replica o organograma atual sem avaliar capacidades compartilhadas ou futuras reorganizações.

Uma org para resolver cada desacordo Novas orgs são criadas em vez de resolver conflitos de governança, ownership ou processo.

Orgs transitórias permanentes Estruturas temporárias de aquisição ou migração permanecem indefinidamente sem revisão.

Sincronização cross-org sem controle Dados são replicados amplamente sem ownership, propósito ou regras de resolução de conflitos.

Integração ponto a ponto entre orgs Cada org conecta-se diretamente às demais, criando uma malha impossível de administrar.

Padrões independentes Cada org estabelece suas próprias práticas de segurança, DevOps, integração e Agentforce.

Ignorar o modelo operacional A arquitetura pressupõe governança centralizada quando o negócio opera autonomamente, ou o inverso.

Tratar consolidação como simples migração técnica O programa move metadados e dados sem tratar processos, ownership, governança e mudança organizacional.

O Papel do Arquiteto Salesforce

A responsabilidade do arquiteto não é defender automaticamente consolidação ou separação.

Ele deve criar clareza sobre:

· Limites corporativos

· Capacidades compartilhadas

· Obrigações regulatórias

· Autoridade dos dados

· Autonomia operacional

· Dependências de release

· Complexidade de integração

· Custo total

· Flexibilidade futura

O arquiteto também precisa expor os trade-offs com honestidade. Ao recomendar uma única org, deve explicar como a organização governará mudanças, segurança, dados e releases compartilhados. Ao recomendar múltiplas orgs, deve explicar como identidade, integração, analytics, DevOps e padrões permanecerão coerentes.

O pensamento em nível CTA é fundamental porque a estratégia atravessa todos os grandes domínios:

· Negócio

· Dados

· Segurança

· Identidade

· Integração

· Desenvolvimento

· Operações

· Governança

· Custos

· Desenho organizacional

Uma resposta tecnicamente possível não é suficiente. A estratégia precisa ser operacionalmente sustentável e organizacionalmente realista.

Reflexão Final

A quantidade de orgs Salesforce que uma empresa opera não é uma medida de maturidade arquitetural. Uma única org pode ser elegante ou caótica. Múltiplas orgs podem ser disciplinadas ou fragmentadas. A maturidade surge do estabelecimento de limites intencionais e da governança dos relacionamentos entre eles.

Uma boa estratégia alinha:

· Estrutura de negócio

· Requisitos regulatórios

· Ownership de dados

· Segurança

· Autonomia de entrega

· Accountability operacional

· Sustentabilidade financeira

· Mudança corporativa

A arquitetura não deve forçar a empresa a adotar um modelo operacional que ela não consegue sustentar. Também não deve transformar cada desacordo organizacional em um limite tecnológico permanente. O objetivo é equilíbrio.

A arquitetura single-org centraliza a complexidade. A arquitetura multi-org distribui a complexidade. O papel do arquiteto é determinar onde essa complexidade pode ser governada de forma mais eficaz.

A estratégia de orgs Salesforce não é uma decisão sobre quantos ambientes técnicos uma organização deve possuir. É uma decisão sobre onde colocar os limites de autoridade, dados, risco, mudança e accountability. A estratégia correta é aquela que alinha esses limites à realidade do negócio, preservando ao mesmo tempo coerência corporativa, sustentabilidade operacional e capacidade de evolução.