A estratégia de orgs é uma decisão de panorama

🌐 Também em 28 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Imagem gerada com IA

Traduzido com IA. Ainda não revisto pela comunidade. Ler em inglês

Módulo 5 de 6 do capítulo Entender os dados empresariais, capítulo 4 do curso Data Architect. Cada módulo sustenta-se sozinho. Anterior: Desenhe o panorama de sistemas · Próximo: O panorama da Steve Trucking

A pergunta que este módulo responde: Uma org ou várias, e onde corre?

Quando ensino candidatos a CTA, digo que a maior decisão de um cenário vem nos primeiros cinco ou dez minutos: com quantas orgs Salesforce estamos a lidar? Uma org grande? Orgs regionais para a América do Norte, EMEA e APAC? Orgs separadas para unidades de negócio separadas? Uma org especial para um país com regras próprias? E diretamente ligada a isso: onde correm essas orgs?

Estes não são pormenores de administração. Mudam onde vivem os dados, as integrações, os relatórios, a identidade, e como as pessoas pelo mundo fora chegam ao sistema. É por isso que trato a estratégia de orgs como uma decisão de panorama, e porque a tomo primeiro.

Comece com uma org

A minha posição de partida é simples: comece com uma org. Não porque uma org seja sempre o certo, mas porque preciso de um motivo para acrescentar outra. Uma org dá-me um lugar para os dados de cliente partilhados, um modelo de segurança, um lugar para fazer deploy, um conjunto de integrações, um lugar para os relatórios. E uma org continua a conseguir sustentar unidades de negócio, países, processos, tipos de registo, aplicações, modelos de partilha e experiências diferentes.

Por isso não acrescento uma org porque a Europa faz as coisas de forma um pouco diferente, ou uma divisão tem o seu próprio processo de vendas, ou as unidades de negócio não se dão bem. Isso são requisitos, não fronteiras de org. A pergunta é: que força é suficientemente forte para justificar outra org?

Várias orgs têm um custo

Divida uma org em três (América do Norte, Europa, Ásia-Pacífico) e não desenhou três caixas arrumadas; criou perguntas novas. Onde vive um cliente global? E se ele opera em duas regiões: duas cópias, e qual delas é a dona? Como faz alguém relatórios globais? O ERP integra-se com as três, o data warehouse recebe três feeds, o fornecedor de identidade liga-se às três? Fazemos deploy da mesma funcionalidade três vezes e mantemos três modelos de dados alinhados? Se um agente precisa de uma visão global de um cliente, a que org pergunta?

Volte ao panorama do módulo 4. Uma caixa Salesforce passa a ser três, e cada seta é redesenhada. Ter várias orgs não é errado. Nunca é de graça.

Procure fronteiras reais

O que pode justificar outra org? Fronteiras suficientemente reais para moldar a arquitetura: residência de dados, regulação, separação legal, modelos operacionais realmente diferentes, uma aquisição que ainda não convergiu, uma restrição regional de alojamento, uma governação muito diferente, às vezes escala ou isolamento. A lista não está completa. O ponto é distinguir «estes grupos são diferentes» de «estes grupos precisam de uma fronteira de arquitetura». A segunda fasquia é muito mais alta.

A geografia não é automaticamente uma estratégia de orgs

«Operamos em 30 países, por isso precisamos de 30 orgs.» Não. A geografia importa quando traz um requisito de arquitetura. Uma empresa pode ter utilizadores no mundo inteiro numa arquitetura comum. Por isso não conto países; pergunto o que vem com eles. Onde podem os dados ser armazenados? Onde podem ser processados? Há limites para mover dados pessoais através de fronteiras? Promessas contratuais sobre residência? Uma região precisa de outro serviço ou de outro alojamento Salesforce? «Há um escritório na Alemanha» não basta por si só.

O alojamento faz parte do desenho

Aqui a plataforma moderna torna o panorama mais interessante. O Hyperforce corre o Salesforce em infraestrutura de nuvem pública em regiões de todo o mundo, dando aos clientes mais escolha e controlo sobre onde residem os seus dados (Salesforce Hyperforce: General Information and FAQ (opens in a new tab), em inglês). Por isso, quando rotulo uma caixa como «Salesforce, Europa», essa localização pode importar.

Mas seja preciso. Escolher onde vive uma org não é uma promessa de que cada byte de cada serviço lá fica. A Salesforce orienta os clientes a rever a documentação de confiança e conformidade do Hyperforce, incluindo os subcontratantes adicionais dos serviços que compram (mesma fonte). Por isso não diga «estamos no Hyperforce no país X, logo tudo fica no país X». Saiba que serviços está realmente a usar, e que requisito está a cumprir. E repare no que escolhe: a região, não a nuvem por baixo dela. O Hyperforce corre na AWS, com o Google Cloud a partir do fim de 2026, e é a Salesforce que decide em que fornecedor fica uma org; um cliente com um motivo regulatório documentado para evitar um deles fala com a sua equipa de conta (mesma fonte).

Não se faça de advogado

É aqui também que os arquitetos precisam de conhecer o seu papel. Se alguém diz «a lei de privacidade europeia exige uma org separada», não vou aceitar às cegas. Também não me vou nomear advogado da empresa e declarar que não exige. Vou perguntar: que requisito específico estamos a cumprir? Onde os dados são armazenados, onde são processados, transferência internacional, quem lhes pode aceder para suporte, um contrato, uma política interna? Depois trabalho com privacidade, segurança, conformidade e jurídico para transformar esse requisito em arquitetura. Não invente requisitos legais, e não os ignore. Traduza-os.

Quando a Europa tem a sua própria org

Eis uma fronteira que vejo em cenários reais. Uma empresa tem uma presença forte nos EUA e uma presença forte na Europa: duas grandes bases de clientes, duas operações de vendas e atendimento, e um programa europeu de privacidade construído à volta do RGPD (GDPR). O RGPD não diz «precisa de uma org Salesforce separada». Estabelece regras para os dados pessoais, incluindo quando podem ser transferidos para fora da UE (RGPD, capítulo V (opens in a new tab)). Mas esta empresa, a trabalhar com as suas equipas de privacidade e jurídica, decide que os dados pessoais dos seus clientes europeus devem viver numa org alojada na Europa, gerida pela sua equipa europeia, sob a sua governação europeia. Esse é um requisito real, e é deles, não meu.

Agora «uma grande org global» já não é uma preferência. Há uma fronteira no panorama, Salesforce AMER e Salesforce EMEA, e tenho de a desenhar. E a segunda org nunca é só mais uma caixa.

Click to enlarge

Duas orgs, AMER e EMEA. O âmbar é o que a segunda org acrescenta: não mais uma caixa, mas todas as setas de novo.

Percorra outra vez as setas

Com mais do que uma org, percorra outra vez o panorama. O ERP envia produtos para cada org? Cada uma devolve encomendas? Onde são mestres os clientes, e podem os seus dados atravessar regiões? A camada de integração é global ou regional? Que fornecedor de identidade autentica que utilizadores? Para onde vão os dados analíticos?

Três lugares mostram o custo mais depressa:

Relatórios. O CEO quer um pipeline global. Numa org, é um relatório do Salesforce. Em três, é um problema de relatórios empresariais: replicar, enviar para o data warehouse, federar? Quão atual tem de estar, e as orgs definem sequer «pipeline» da mesma forma? Onde vive a análise segue onde vivem os dados, e se divide os dados operacionais de propósito, tem de projetar como os insights se voltam a juntar.

Dados mestres. Um cliente global compra nos EUA, na Alemanha e no Japão. Três orgs, por isso provavelmente três Contas. Como sabe que são a mesma empresa? Qual é o identificador global, e quem é o dono? Se uma região muda a morada, a mudança deve espalhar-se? Que atributos são globais e quais são regionais? A estratégia de orgs não resolve a identidade; muda o problema de identidade. Isso é o capítulo 6.

Integração. Uma org: o Salesforce, a camada de integração, o ERP. Três orgs: três ligações à camada de integração, talvez uma com alojamento e conectividade próprios, alguns fluxos partilhados, alguns regionais, alguns dados que podem atravessar e outros não. Até a rede pode mudar: se a empresa precisa de conectividade privada dedicada ao Hyperforce (na AWS, a Salesforce recomenda o AWS Direct Connect; mesmo FAQ do Hyperforce), cada org e cada alojamento no desenho é mais uma ligação a planear. Onde corre uma org pode mudar a forma como o resto da empresa chega até ela.

Uma org ou várias é uma decisão que toma agora, no início, no panorama. Como as orgs depois partilham dados (Salesforce Connect entre orgs, integração entre elas, Data 360) é a mecânica, e o capítulo 14, Uma org ou várias? (coming soon), trata disso.

Se projeta todo o modelo de dados e a arquitetura de integração e só então ouve «a propósito, isto tem de ser três orgs», não fez um pequeno ajuste. Mudou a arquitetura. É por isso que a decisão vem primeiro.

Não divida só para deixar as caixas menores

Uma org grande parece complicada: muitas unidades, objetos, utilizadores, integrações. Alguém diz: «Não seria mais limpo se cada um tivesse a sua própria org?» O desenho pode ficar mais limpo. A empresa talvez não. Trocou complexidade interna por complexidade distribuída: sincronização, dados duplicados, identidade entre orgs, relatórios globais, vários pipelines de release, integrações e automação duplicadas, e governação sobre tudo isso. Às vezes essa continua a ser a troca certa. Mas separado não é o mesmo que simples.

E uma org também não é de graça. A governação partilhada importa mais, as equipas podem afetar-se umas às outras, as fronteiras de segurança precisam de design cuidadoso, o modelo de dados tem de servir muitos grupos, os releases precisam de coordenação, e as regras regionais podem restringir toda a gente. Por isso não é «o Steve diz que é sempre uma org». A minha inclinação de partida é uma org; depois procuro o requisito suficientemente forte para me tirar dela.

Torne a decisão visível

Se a estratégia de orgs importa, não desenhe uma nuvem Salesforce genérica. Desenhe as orgs e rotule-as (AMER, EMEA, o que for real), anote o requisito de alojamento ou residência por trás de cada uma, e percorra as ligações. Outro arquiteto deve conseguir ver porque existe cada fronteira. Se não consigo explicar porque há três caixas Salesforce, não terminei a decisão.

A Steve Trucking corre uma org, nos EUA, e nada no seu briefing pede outra. Mas guarde este módulo para o projeto final: uma aquisição que chega com a sua própria org é exatamente o tipo de fronteira que põe estas perguntas à prova.

Além do exame: o que a IA muda. Um agente pode tornar uma fronteira de org invisível para o utilizador. Por baixo, a arquitetura continua a ter de decidir a que org ou sistema o agente pode perguntar, que dados podem atravessar regiões, e que resposta tem autoridade. A IA pode esconder a complexidade na experiência; não remove a governação nem a fronteira.

O que um arquiteto decide aqui

• Se há um motivo real de arquitetura para mais de uma org, em vez de resolver as diferenças dentro de uma.
• Onde corre cada org, e que requisito de residência, regulatório, contratual ou de negócio a põe ali.
• Que dados podem atravessar fronteiras de org e de região, onde têm autoridade os dados mestres, e como funciona a identidade global.
• Como a integração, a identidade, a análise e os relatórios mudam quando uma caixa Salesforce passa a ser várias.
• Se o benefício da separação compensa a arquitetura distribuída que ela cria.

Quando leio um cenário, procuro primeiro esta decisão: uma org ou várias, alojadas onde, e impostas porquê? Responda a isso, e o resto do panorama começa a ganhar forma.

Para saber mais

• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (em inglês), consultado em 2026-10-14.
• EUR-Lex, Regulamento (UE) 2016/679, o Regulamento Geral sobre a Proteção de Dados (opens in a new tab), capítulo V (transferências de dados pessoais para países terceiros), consultado em 2026-10-14.