Conheça suas ferramentas: as nove perguntas

🌐 Também em 28 idiomas

English · Español · 日本語 · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · 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 por IA. Ainda não revisado pela comunidade. Ler em inglês

Módulo 6 de 7 do capítulo Pensar como um arquiteto de dados, o primeiro capítulo do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: Construa para hoje. Planeje para amanhã. Planeje para a falha. · Próximo: O arquiteto de dados na era da IA

A pergunta que este módulo responde: Como avaliar qualquer ferramenta, inclusive uma que você nunca viu antes?

Arquitetos precisam de discernimento. Mas discernimento sem conhecimento não serve para muita coisa. Você ainda precisa conhecer suas ferramentas.

Ensino arquitetos há anos, e um framework que uso é um conjunto de perguntas que você deveria conseguir responder sobre toda ferramenta ou capacidade importante da sua arquitetura. Originalmente eu ensinava oito perguntas. Acrescentei uma nona. As tecnologias mudam, a Salesforce muda, novos produtos aparecem e capacidades antigas evoluem, e a IA está acelerando tudo isso. Essas perguntas continuam funcionando.

As nove perguntas

Sempre que estiver aprendendo ou avaliando uma tecnologia, pergunte:

1. O que é?
2. Onde é usada?
3. Como eu a uso?
4. Quais são minhas alternativas?
5. Quais são seus pontos fortes?
6. Quais são seus pontos fracos?
7. Como explico isso para desenvolvedores, para o negócio e para executivos?
8. Como ela é mantida a longo prazo?
9. Quanto custa, que licenciamento exige e quais são seus limites?

Se você consegue responder às nove, está começando a entender a ferramenta como um arquiteto. Repare no que não está na lista: “Consigo configurá-la?” Isso importa, mas é só uma parte de conhecer a ferramenta.

Click to enlarge

1. O que é?

Comece pela pergunta óbvia, porque as pessoas a pulam com uma frequência surpreendente. Ouvimos o nome de um produto ou recurso e logo começamos a discutir se vamos usá-lo. Calma. O que ele realmente faz? Que problema foi projetado para resolver? Onde ele fica na arquitetura, e o que ele não é? Um arquiteto deveria conseguir descrever uma tecnologia sem repetir a descrição do marketing. Se não consigo explicar algo em poucas frases, provavelmente ainda não o entendo bem o bastante.

2. Onde é usada?

Saber o que algo faz não é o mesmo que saber quando ele pertence a uma arquitetura. Em que tipos de problemas ele é bom? Que condições o tornam apropriado, e que condições deveriam me deixar desconfiado? Esse é o passo de “conheço este recurso” para “reconheço o problema que este recurso resolve”, e é um passo grande. Você não quer andar por aí procurando lugares para usar sua tecnologia favorita. Você quer reconhecer problemas e saber quais ferramentas se encaixam neles.

3. Como eu a uso?

Sim, arquitetos devem entender a implementação. Você não precisa construir cada componente, mas deve entender o bastante para saber o que está pedindo para outras pessoas construírem. Saiba como ela é configurada, como um desenvolvedor trabalha com ela, como os dados entram e saem, como é implantada e protegida, e como fica em operação. Não quero um arquiteto projetando em torno de uma tecnologia que só viu num slide de produto. Ponha a mão na massa: construa algo, quebre algo, veja como ela realmente se comporta. A arquitetura melhora quando está ancorada na realidade.

4. Quais são minhas alternativas?

Talvez esta seja a pergunta mais importante da lista. Se você conhece só uma forma de resolver um problema, não tem uma decisão de arquitetura; tem um padrão. Sempre que alguém propõe uma tecnologia, quero saber o que mais poderíamos fazer. Outra capacidade da Salesforce? Algo declarativo, ou código? A capacidade poderia viver fora do Salesforce? Poderíamos deixar os dados onde estão em vez de copiá-los, usar um evento em vez de uma chamada de API, ou não construir nada? Alternativas criam trade-offs, e os trade-offs são o coração da arquitetura.

5. Quais são seus pontos fortes?

Toda ferramenta existe por um motivo. Entenda no que ela é realmente boa: o que ela facilita, onde escala bem, que complexidade remove, que problemas resolve com elegância. Use tecnologias onde seus pontos fortes se alinham com o problema. Parece óbvio, mas é muito fácil escolher uma ferramenta porque já a temos, porque a equipe a conhece, porque é nova ou porque alguém viu uma demo. Esses podem ser fatores. Não são a mesma coisa que adequação arquitetural.

6. Quais são seus pontos fracos?

Isto é igualmente importante. Toda tecnologia tem pontos fracos, todas. Se alguém só sabe lhe contar os pontos fortes de uma tecnologia, vocês ainda não estão tendo uma discussão de arquitetura. O que ela não faz bem? Onde aparece a complexidade, e o que acontece em escala? Que carga operacional e que dependências ela traz? Que requisitos a empurram para fora do seu ponto ideal? Um ponto fraco nem sempre significa que não devemos usar a tecnologia. Significa que precisamos saber o que estamos aceitando. Um trade-off que você entende pode ser uma decisão de arquitetura. Um trade-off que você não entende pode virar uma surpresa.

7. Como explico isso para públicos diferentes?

Esta é uma das perguntas que separam conhecimento técnico de habilidade arquitetural. Você consegue explicar a mesma tecnologia para um desenvolvedor, para o negócio e para um executivo? Não deveriam ser a mesma explicação. O desenvolvedor precisa das APIs, do comportamento transacional, da segurança, do tratamento de falhas e dos padrões de implementação. O negócio se importa com o que ela possibilita e com como o processo dele muda. O executivo se importa com custo, risco, tempo, impacto organizacional e quais opções a decisão mantém abertas ou fecha. Você não está mudando a verdade; está mudando o nível de abstração. Se a única forma de explicar uma tecnologia é no vocabulário da documentação dela, continue trabalhando no seu entendimento.

8. Como ela é mantida a longo prazo?

Projetos terminam. Sistemas não, ou pelo menos esperamos que não. Alguém precisa ser dono do que construímos depois que a equipe do projeto sai. Isso significa saber como é monitorado, atualizado e diagnosticado, quem precisa das habilidades para dar suporte, como as mudanças são implantadas e testadas, e o que acontece quando a tecnologia evolui ou a Salesforce muda algo por baixo de nós. Imagine daqui a três anos. Já vi arquiteturas muito engenhosas no dia do lançamento e miseráveis de operar depois. Isso não é sucesso. A manutenibilidade faz parte da arquitetura.

9. Quanto custa, que licenciamento exige e quais são seus limites?

Esta é a pergunta que acrescentei às oito originais, e hoje acho impossível deixá-la de fora. Uma tecnologia pode ser a solução técnica perfeita e ainda assim a arquitetural errada, se a economia não fechar. Ela está incluída nas licenças que temos, ou é um complemento? É licenciada por usuário, uso, consumo, armazenamento ou transações? O que acontece com o custo à medida que escalamos?

Depois vêm os limites, e toda plataforma os tem: limites de API, armazenamento, consulta, transação, concorrência, vazão e licenciamento. Alguns são rígidos, outros flexíveis; alguns podem ser aumentados e outros não; alguns não importam na nossa escala até acrescentarmos mais um zero. Você não precisa decorar cada limite da Salesforce, e fazer isso seria um péssimo uso do seu tempo. Você precisa saber que os limites existem, quais importam para a sua arquitetura e quando ir verificar o número atual. Os números vão mudar. A pergunta arquitetural continua.

Um exemplo prático: compartilhamento Apex

Eis um dos meus exemplos mais comuns das perguntas em ação. Recebemos um requisito de compartilhamento complicado, um compartilhamento que não pode ser atendido por nenhuma das regras de compartilhamento baseadas em proprietário ou em critérios. Isso nos leva ao compartilhamento Apex (Apex sharing): código que grava ele mesmo os registros de compartilhamento. Agora precisamos saber o que é o compartilhamento Apex, onde é usado, como usá-lo e o resto. É uma escalada: o compartilhamento Apex é a alternativa (pergunta 4) para quando as regras de que precisamos vão além do que o compartilhamento baseado em proprietário e em critérios consegue expressar.

Agora seus pontos fracos (pergunta 6). Digamos que temos uma comunidade de clientes com 10 ou 20 milhões de membros, e usamos a licença Customer Community, não a Customer Community Plus. São usuários de alto volume. Eles não têm papéis, e não usam o modelo de compartilhamento: o acesso deles vem de conjuntos de compartilhamento e grupos de compartilhamento, correspondidos pela conta e pelo contato. Não existe registro de compartilhamento para o Apex gravar para eles, então o compartilhamento Apex não funciona para eles. E foi a pergunta de custo e licenciamento (pergunta 9) que nos colocou ali: a escolha da licença decidiu quais ferramentas de compartilhamento sequer existem.

Então, assim como o compartilhamento Apex era a alternativa às regras baseadas em proprietário e em critérios, você pode cair num caso em que precisa de uma alternativa ao compartilhamento Apex. E, a essa altura, realmente não há opções baseadas em configuração para regras de compartilhamento complexas. Você acaba deixando o objeto somente leitura e controlando o acesso por Apex. É por isso que você faz as nove perguntas antes de escolher, não depois.

Não decore a plataforma

Isso importa mais quando você está aprendendo arquitetura Salesforce. Não tente decorar o Salesforce. Você não consegue: a plataforma é grande demais e muda rápido demais. Trabalho com Salesforce há muito tempo, e continuo aprendendo. Isso é normal.

O que quero que você desenvolva é um framework para aprender. Quando a Salesforce lançar uma nova capacidade amanhã, não preciso já tê-la visto. Sei o que perguntar: o que é, onde se encaixa, como uso, o que mais eu poderia usar, no que ela é boa, onde ela tem dificuldade, como explico, como opero, e quanto custa e onde estão os limites? Agora posso começar a avaliá-la. Isso vale muito mais do que decorar mais uma matriz de recursos.

Além do exame: a IA torna as nove perguntas mais rápidas de responder, e mais fáceis de errar. Encontre uma tecnologia que você não conhece, e você pode pedir à IA que a explique, compare três abordagens, liste seus limites e modos de falha comuns, ou argumente contra usá-la. É uma assistente de pesquisa notável. Mas ela pode estar errada, desatualizada, ou confundir com toda a confiança dois produtos ou edições de nomes parecidos. Para qualquer coisa que afete uma decisão, verifique: siga a fonte e confira a documentação, os limites e o licenciamento atuais. Confie, mas verifique (módulo 7).

Aprenda as perguntas, não só as respostas

Vamos encontrar muitas tecnologias neste curso. Não quero que você colecione respostas; quero que você pratique as perguntas. Quando falarmos de big objects, dados externos, Data 360, padrões de integração ou de uma capacidade de IA que a Salesforce lançar seis meses depois que este capítulo foi escrito, faça as mesmas nove perguntas.

As respostas vão mudar. As perguntas são duráveis. É isso que faz disto um framework de arquitetura, e não um guia de estudo.

Conheça suas ferramentas: no que são boas, no que são ruins, o que mais você poderia usar, quanto custam e onde quebram. E saiba o bastante para explicar a decisão às pessoas que vão ter de conviver com ela. É assim que um arquiteto aprende tecnologia.

O que um arquiteto decide aqui

• Se uma ferramenta se encaixa no problema, julgada pelas nove perguntas, não só por poder ser configurada.
• Quais são as alternativas, e o que o custo, o licenciamento e os limites da ferramenta significam na sua escala.
• Quem vai mantê-la, e como, daqui a três anos.
• Quais fatos sobre a ferramenta verificar antes de confiar neles.

Para saber mais

• About High-Volume Community or Site Users (opens in a new tab), Ajuda do Salesforce (em inglês, consultado em 2026-10-09; reconsultado em 2026-10-12): usuários de alto volume (as licenças External Apps, Customer Community, High Volume Customer Portal e Authenticated Website) não têm papéis; o acesso deles vem de conjuntos de compartilhamento e grupos de compartilhamento; não podem ser incluídos em regras de compartilhamento baseadas em proprietário, e os registros que possuem não podem ser compartilhados manualmente.
• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (em inglês, consultado em 2026-10-09; reconsultado em 2026-10-12): usuários de alto volume (Customer Community, High Volume Customer Portal, Authenticated Website) não usam o modelo de compartilhamento, porque suas licenças não suportam papéis; o acesso funciona pela correspondência do usuário com os relacionamentos de pesquisa de Conta e Contato, por meio de conjuntos ou grupos de compartilhamento. A mesma página lista quando o compartilhamento gerenciado por Apex é a ferramenta certa.
• Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab), pergunta na Trailblazer Community, novembro de 2024 (em inglês, consultado em 2026-10-09; reconsultado em 2026-10-12): um profissional relata que a inserção de registros de compartilhamento para usuários de alto volume falhou com um erro. Um relato de campo, não documentação oficial. (A Trailblazer Community online passa a ser somente leitura em 30 de outubro de 2026; o link pode mudar.)
• Create a Sharing Set for Experience Cloud Site Users (opens in a new tab), Salesforce Help (em inglês, consultado em 2026-10-09): um conjunto de compartilhamento concede acesso a registros relacionados à conta ou ao contato do usuário.