O Teste de Reversibilidade
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)
Módulo 3 de 7 do capítulo Pensar como um arquiteto de dados, o primeiro capítulo do curso Data Architect. Cada módulo sustenta-se sozinho. Anterior: O modelo de dados é o esqueleto · Próximo: Arquitetura é a arte dos trade-offs
A pergunta que este módulo responde: Como distinguir uma decisão de arquitetura de uma decisão comum?
Arquitetos tomam muitas decisões.
Mas nem toda decisão é uma decisão de arquitetura.
Esta é uma distinção importante. Se tratarmos todas as decisões como arquitetura, passaremos o tempo todo a debater coisas relativamente fáceis de mudar. Se não reconhecermos as decisões que realmente são de arquitetura, podemos tomar hoje uma decisão de cinco minutos que leva cinco anos a desfazer.
Então como percebemos a diferença?
Gosto de fazer uma pergunta simples:
Quão difícil será reverter esta decisão depois?
Chamo-lhe o Teste de Reversibilidade.
Quanto mais difícil for reverter algo, e quanto mais outras coisas dependerem dele, mais atenção de arquitetura ele merece.
Algumas decisões são baratas de mudar
Seção intitulada “Algumas decisões são baratas de mudar ”Vamos começar com algo simples.
Chamamos a um campo Categoria do cliente. Seis meses depois, o negócio decide que toda a gente, afinal, lhe chama Segmento do cliente. Mudamos o rótulo. Pode haver documentação para atualizar e um pouco de formação, mas não é um grande acontecimento de arquitetura. Teremos de conviver com o nome de API original, porém, porque mudá-lo tem consequências muito maiores. Por isso, pode significar apenas lidar com uma mudança de rótulo, e com a confusão que ela pode trazer.
Tomamos uma decisão. Mudamos de ideia. Seguimos em frente.
Agora compare isto com outra decisão.
Estamos a criar um identificador para clientes. Decidimos o que significa, que formato usa e que sistema o cria. Depois publicamo-lo.
O Salesforce usa-o. O data warehouse usa-o. A plataforma de integração usa-o. O portal do cliente usa-o. Cinco outras aplicações começam a armazená-lo. Relatórios e pipelines de dados usam-no. Talvez os clientes acabem por vê-lo.
Três anos depois, alguém diz:
Provavelmente não devíamos ter projetado o identificador desta forma.
Esta é uma conversa muito diferente.
A diferença não é uma decisão ser mais técnica do que a outra.
A diferença é a reversibilidade.
Veja como isto pode acontecer. Digamos que o negócio tem vindo a montar as suas chaves com parte do nome do cliente mais um número. Funciona durante anos, porque nunca ninguém precisou de mudar um nome. Então, um ano depois ou mais, um nome muda, e de repente as chaves não batem com o padrão que o resto dos dados espera. Esse é um dos motivos pelos quais as chaves não devem carregar nenhum significado intrínseco.
A arquitetura cria gravidade
Seção intitulada “A arquitetura cria gravidade ”Uma decisão de arquitetura tende a acumular coisas à sua volta. Penso nisso como gravidade.
Escolha um modelo de objetos, e a automação é construída à volta dele.
Escolha uma chave, e outros sistemas começam a armazená-la.
Escolha onde os dados mestres vivem, e as integrações começam a fluir na direção deles e a partir deles.
Escolha um modelo de partilha, e os processos de negócio começam a depender de quem pode ver o quê.
Escolha um padrão de integração, e os sistemas começam a depender do seu tempo e do seu comportamento.
Quanto mais tempo estas decisões existem, mais gravidade desenvolvem. A dada altura, mudar a decisão original significa mudar tudo o que se acumulou à volta dela.
A IA também sente essa gravidade. Uma ferramenta de IA trabalha a partir do que já está no sistema: quando um elemento-chave de design lá está, cada interação de IA a partir daí trata esse elemento como facto e continua a construir sobre ele, e a construir, e a construir. A decisão ecoa adiante por muitas outras decisões, e nenhum humano volta alguma vez a revisitar a original. Cada geração aumenta a gravidade.
É por isso que importa o modelo de dados ser «o esqueleto». Não somos cuidadosos porque mudar é mau. Somos cuidadosos porque as dependências tornam a mudança cara.
Faça duas perguntas
Seção intitulada “Faça duas perguntas ”Quando olho para uma decisão de design, faço duas perguntas:
Quão difícil é reverter isto?
Quanto vai depender disto?
Estão relacionadas, mas não são idênticas. Algo pode ser tecnicamente fácil de mudar e ter centenas de consumidores. As pessoas costumavam renomear objetos padrão para ficar mais claro, Conta como «Cliente», por exemplo. Fácil de fazer. Depois outro sistema quis usar Contas para Parceiros, e não conseguiu. Outra coisa pode ter poucos consumidores e precisar de uma migração enorme para mudar, como o nome de API de um objeto referenciado em muitos lugares internamente. Ninguém de fora o vê, mas um nome errado continua a confundir a equipa. Os dois casos merecem atenção.
Pense em algumas decisões de dados comuns:
- Que objeto do Salesforce representa este conceito de negócio?
- Qual é o identificador único?
- Que sistema é o sistema de registo?
- Estes dados são copiados para o Salesforce ou acedidos noutro lugar?
- Isto é um objeto ou vários objetos relacionados?
- Quem é dono dos dados, e por quanto tempo os guardamos?
- Quais são os nossos limites de acesso padrão?
- Como se movem estes dados entre sistemas?
Isto é muito diferente de decidir onde aparece um campo numa página Lightning. O design de página também importa. O custo de errar é diferente.
Pense no raio de impacto
Seção intitulada “Pense no raio de impacto ”Outra forma de pensar a reversibilidade é o raio de impacto: se eu mudar esta decisão, o que mais se move?
Suponha que algo que modelámos como campo precisa de passar a ser um objeto filho. Isso não é só uma mudança de esquema. O que acontece aos dados existentes? Aos relatórios, às integrações que esperam aquele campo, ao Apex e aos Flows que o referenciam, à segurança, às análises, a um agente de IA cujas ações dependem da estrutura original?
Quanto maior o raio, mais cuidado devemos ter ao tomar a decisão original.
É também por isso que os arquitetos precisam de olhar para além da sua própria parte do sistema. De dentro do Salesforce, uma mudança pode parecer fácil. Da perspetiva da empresa, pode afetar outros doze sistemas.
Decisões da empresa e decisões do Salesforce
Seção intitulada “Decisões da empresa e decisões do Salesforce ”Um arquiteto de dados pensa em dois níveis.
Dentro do Salesforce, decidimos objetos, relações, chaves, volume, acesso, automação e como os dados se comportam na plataforma.
Em toda a empresa, fazemos perguntas mais amplas. Onde vive realmente o Cliente? Quem é dono do Produto? Que sistema cria uma Encomenda? Qual é o nosso identificador oficial? Que informações são copiadas entre sistemas, e quais ficam onde estão?
Os dois níveis precisam de estar ligados. Já vi implementações Salesforce em que o modelo interno fazia todo o sentido por si só, mas não encaixava na empresa à sua volta. Isso não basta. As estruturas do Salesforce precisam de ser representadas ao nível da empresa, e as decisões da empresa precisam de voltar ao Salesforce.
Arquitetura é uma via de dois sentidos.
Abrande nas decisões caras
Seção intitulada “Abrande nas decisões caras ”Um perigo em tecnologia é que as decisões mais fáceis de implementar podem parecer as mais fáceis de tomar. Não são a mesma coisa.
Criar mais um objeto personalizado é fácil. Criar mais um campo é fácil. Ligar mais uma API está a ficar mais fácil, e a IA torna tudo isto ainda mais fácil.
Mas a facilidade de implementação não nos diz quase nada sobre o custo da decisão de arquitetura.
Antes de uma decisão difícil de reverter, abrande o suficiente para perguntar: Que problema estamos realmente a resolver? Que alternativas considerámos? O que estamos a assumir? O que acontece quando o volume cresce, e quando o negócio muda? O que mais vai depender disto? O que acontece se estivermos errados?
Não precisamos de seis meses de revisão sempre que criamos um objeto. Precisamos, sim, de reflexão proporcional ao custo de errar. Se é um objeto para um único departamento ou subsistema, pode avançar mais depressa. Se são dados de referência, um objeto central de cliente ou algo usado entre sistemas, reserve tempo para pensar bem.
Registe o porquê
Seção intitulada “Registe o porquê ”Há outro problema com as decisões importantes: as pessoas esquecem-se do motivo por que foram tomadas.
Alguém olha para uma arquitetura três anos depois e pergunta: «Porque é que alguém projetaria isto desta forma?» Às vezes a resposta é que era um mau design. Acontece. Mas às vezes havia um motivo muito bom: uma limitação da plataforma que já não existe, uma exigência regulatória, outro sistema que não suportava a abordagem preferida, um trade-off aceite conscientemente para cumprir um prazo.
Se registamos apenas o que decidimos e não porquê, o próximo arquiteto não tem como saber.
Para decisões significativas, registe-as. Não precisa de ser um documento de 50 páginas. Um registo de decisão útil pode ser bem pequeno:
Contexto: Que problema estamos a resolver?
Opções: Que alternativas realistas consideramos?
Decisão: O que escolhemos?
Consequências: O que ganhamos, e de que estamos a abdicar?
Responsável: Quem responde por esta decisão?
Revisão: Que motivo ou data nos deve levar a revisitá-la?
O valor não está no documento. O valor está em preservar o raciocínio.
E quando uma decisão muda, não apague a original. Substitua-a. A decisão que estava certa em 2027 pode não estar certa em 2030, porque os volumes, o negócio, o Salesforce e o nosso entendimento mudam. O que quero guardar é a história: este era o contexto, esta foi a decisão e o porquê, isto mudou, e isto é o que estamos a decidir agora. Isso vale muito mais do que fingir que sempre soubemos a resposta.
Além do exame: a IA encurta o tempo entre a decisão e a dependência. Uma ferramenta de IA pode propor um modelo de dados em segundos, e depois criar os objetos, a automação, o código de integração e a interface de utilizador sobre ele. Uma decisão questionável costumava levar meses de desenvolvimento até que muita coisa dependesse dela; agora as dependências chegam quase de imediato. Por isso, reveja as decisões por baixo do resultado, não só o resultado. A IA pode ajudar: pode listar opções, desafiar pressupostos e rascunhar o registo de decisão. Mas é o arquiteto quem continua a decidir, e quanto mais difícil for reverter a decisão, mais esse juízo humano importa.
Saiba quais decisões importam
Seção intitulada “Saiba quais decisões importam ”Uma das competências que quero que desenvolva é saber onde gastar a sua atenção.
Não transforme cada escolha de configuração numa cimeira de arquitetura.
Mas não tome casualmente uma decisão com a qual a organização vai conviver pela próxima década.
Pergunte:
Quão difícil será reverter isto?
Quanto vai depender disto?
Se as respostas forem muito difícil e muita coisa, provavelmente encontrou uma decisão de arquitetura.
Abrande. Entenda o requisito. Explore as alternativas. Torne os trade-offs visíveis. Tome a decisão. E registe o porquê.
O objetivo da arquitetura não é tomar decisões que nunca possam mudar.
O objetivo é reconhecer as decisões em que mudar de ideias vai sair caro.
O que um arquiteto decide aqui
Seção intitulada “O que um arquiteto decide aqui ”- Que decisões são de arquitetura: difíceis de reverter, com muita coisa a depender delas.
- Quanta atenção cada decisão recebe, na proporção do custo de errar.
- Que decisões são registadas, com contexto, opções, consequências, responsável e ponto de revisão.
- Como as decisões do Salesforce se alinham com as da empresa.
Para saber mais
Seção intitulada “Para saber mais ”- Object Relationships Overview (opens in a new tab), Ajuda do Salesforce (em inglês, consultado em 2026-10-09; reconsultado em 2026-10-12): numa relação mestre-detalhe, o acesso e a propriedade do detalhe seguem o mestre, e eliminar um mestre elimina os seus detalhes.
- Considerations for Object Relationships (opens in a new tab), Ajuda do Salesforce (em inglês, consultado em 2026-10-09; reconsultado em 2026-10-12): uma relação de pesquisa só pode ser convertida em mestre-detalhe quando todos os registos têm um valor nela; a conversão muda o modelo de partilha (para Controlado pelo pai), e o tipo de relação decide que tipos de relatório padrão ficam disponíveis.
- Roll-Up Summary Field (opens in a new tab), Ajuda do Salesforce (em inglês, consultado em 2026-10-09; reconsultado em 2026-10-12): os campos de resumo de totalização só existem em relações mestre-detalhe, e têm de ser eliminados antes de uma mestre-detalhe poder passar a relação de pesquisa.