Conheça as suas ferramentas: as nove perguntas

🌐 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 6 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: Construa para hoje. Planeie para amanhã. Planeie para a falha. · Próximo: O arquiteto de dados na era da IA

A pergunta que este módulo responde: Como avaliar qualquer ferramenta, incluindo uma que nunca viu?

Os arquitetos precisam de discernimento. Mas discernimento sem conhecimento não serve para muito. Continua a precisar de conhecer as suas ferramentas.

Ensino arquitetos há anos, e um framework que uso é um conjunto de perguntas a que deveria conseguir responder sobre cada ferramenta ou capacidade importante da sua arquitetura. Originalmente ensinava oito perguntas. Acrescentei uma nona. As tecnologias mudam, a Salesforce muda, aparecem novos produtos e as capacidades antigas evoluem, e a IA está a acelerar tudo isto. Estas perguntas continuam a funcionar.

As nove perguntas

Sempre que estiver a aprender ou a avaliar uma tecnologia, pergunte:

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

Se consegue responder às nove, está a começar 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 saltam-na com uma frequência surpreendente. Ouvimos o nome de um produto ou funcionalidade e começamos logo a discutir se o vamos usar. Calma. O que é que ele realmente faz? Que problema foi projetado para resolver? Onde fica na arquitetura, e o que é que 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 suficientemente bem.

2. Onde é usada?

Saber o que algo faz não é o mesmo que saber quando pertence a uma arquitetura. Em que tipos de problemas é bom? Que condições o tornam apropriado, e que condições me deviam deixar desconfiado? É o passo de «conheço esta funcionalidade» para «reconheço o problema que esta funcionalidade resolve», e é um passo grande. Não quer andar por aí à procura de sítios para usar a sua tecnologia favorita. Quer reconhecer problemas e saber que ferramentas encaixam neles.

3. Como é que a uso?

Sim, os arquitetos devem entender a implementação. Não precisa de construir cada componente, mas deve entender o suficiente para saber o que está a pedir a outras pessoas que construam. Saiba como é configurada, como um programador trabalha com ela, como os dados entram e saem, como é implementada e protegida, e como se comporta em operação. Não quero um arquiteto a projetar à volta de uma tecnologia que só viu num diapositivo de produto. Meta as mãos na massa: construa algo, estrague algo, veja como se comporta realmente. A arquitetura melhora quando está ancorada na realidade.

4. Quais são as minhas alternativas?

Talvez esta seja a pergunta mais importante da lista. Se conhece só uma forma de resolver um problema, não tem uma decisão de arquitetura; tem um hábito. 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 os copiar, usar um evento em vez de uma chamada de API, ou não construir nada? As alternativas criam trade-offs, e os trade-offs são o coração da arquitetura.

5. Quais são os seus pontos fortes?

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

6. Quais são os seus pontos fracos?

Isto é igualmente importante. Todas as tecnologias têm pontos fracos, todas. Se alguém só lhe sabe contar os pontos fortes de uma tecnologia, ainda não estão a ter uma discussão de arquitetura. O que é que ela não faz bem? Onde aparece a complexidade, e o que acontece à escala? Que carga operacional e que dependências traz? Que requisitos a empurram para fora da sua zona ideal? Um ponto fraco nem sempre significa que não devemos usar a tecnologia. Significa que precisamos de saber o que estamos a aceitar. Um trade-off que se entende pode ser uma decisão de arquitetura. Um trade-off que não se entende pode tornar-se uma surpresa.

7. Como explico isto a públicos diferentes?

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

8. Como é mantida a longo prazo?

Os projetos terminam. Os sistemas não, ou pelo menos esperamos que não. Alguém precisa de ser dono do que construímos depois de a equipa do projeto sair. Isso significa saber como é monitorizado, atualizado e diagnosticado, quem precisa das competências para lhe dar suporte, como as mudanças são implementadas 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 facilidade de manutenção faz parte da arquitetura.

9. Quanto custa, que licenciamento exige e quais são os 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 mesmo assim a arquitetural errada, se as contas não baterem certo. Está incluída nas licenças que temos, ou é um extra? É licenciada por utilizador, utilização, consumo, armazenamento ou transações? O que acontece ao custo à medida que escalamos?

Depois vêm os limites, e todas as plataformas os têm: limites de API, armazenamento, consulta, transação, concorrência, débito e licenciamento. Alguns são rígidos, outros flexíveis; alguns podem ser aumentados e outros não; alguns não importam à nossa escala até acrescentarmos mais um zero. Não precisa de decorar cada limite da Salesforce, e fazê-lo seria um péssimo uso do seu tempo. Precisa de 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 mantém-se.

Um exemplo prático: partilha Apex

Eis um dos meus exemplos mais comuns das perguntas em ação. Recebemos um requisito de partilha complicado, uma partilha que não pode ser resolvida por nenhuma das regras de partilha baseadas em proprietário ou em critérios. Isso leva-nos à partilha Apex (Apex sharing): código que grava ele próprio os registos de partilha. Agora precisamos de saber o que é a partilha Apex, onde é usada, como usá-la e o resto. É uma escalada: a partilha Apex é a alternativa (pergunta 4) para quando as regras de que precisamos vão além do que a partilha baseada em proprietário e em critérios consegue exprimir.

Agora os 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 utilizadores de grande volume. Não têm funções, e não usam o modelo de partilha: o seu acesso vem de conjuntos de partilha e grupos de partilha, correspondidos pela conta e pelo contacto. Não existe registo de partilha para o Apex gravar para eles, por isso a partilha Apex não funciona para eles. E foi a pergunta de custo e licenciamento (pergunta 9) que nos pôs ali: a escolha da licença decidiu que ferramentas de partilha chegam sequer a existir.

Assim, tal como a partilha Apex era a alternativa às regras baseadas em proprietário e em critérios, pode cair num caso em que precisa de uma alternativa à partilha Apex. E, a essa altura, realmente não há opções baseadas em configuração para regras de partilha complexas. Acaba por deixar o objeto só de leitura e controlar o acesso por Apex. É por isso que se fazem as nove perguntas antes de escolher, não depois.

Não decore a plataforma

Isto importa mais quando está a aprender arquitetura Salesforce. Não tente decorar o Salesforce. Não consegue: a plataforma é grande demais e muda depressa demais. Trabalho com Salesforce há muito tempo, e continuo a aprender. Isso é normal.

O que quero que desenvolva é um framework para aprender. Quando a Salesforce lançar uma nova capacidade amanhã, não preciso de já a ter visto. Sei o que perguntar: o que é, onde encaixa, como a uso, que mais poderia usar, em que é boa, onde tem dificuldades, como a explico, como a 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 funcionalidades.

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 não conhece, e pode pedir à IA que a explique, compare três abordagens, liste os seus limites e modos de falha comuns, ou argumente contra usá-la. É uma assistente de pesquisa notável. Mas 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 colecione respostas; quero que 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 de este capítulo ter sido 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 as suas ferramentas: em que são boas, em que são más, que mais poderia usar, quanto custam e onde se partem. E saiba o suficiente 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 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 à sua escala.
• Quem vai mantê-la, e como, daqui a três anos.
• Que factos 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): os utilizadores de grande volume (as licenças External Apps, Customer Community, High Volume Customer Portal e Authenticated Website) não têm funções; o seu acesso vem de conjuntos de partilha e grupos de partilha; não podem ser incluídos em regras de partilha baseadas em proprietário, e os registos que possuem não podem ser partilhados manualmente.
• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (em inglês, consultado em 2026-10-09; reconsultado em 2026-10-12): os utilizadores de grande volume (Customer Community, High Volume Customer Portal, Authenticated Website) não usam o modelo de partilha, porque as suas licenças não suportam funções; o acesso funciona pela correspondência do utilizador com as relações de pesquisa de Conta e Contacto, através de conjuntos ou grupos de partilha. A mesma página indica quando a partilha gerida 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 registos de partilha para utilizadores de grande volume falhou com um erro. Um relato de campo, não documentação oficial. (A Trailblazer Community online passa a ser só de leitura a 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 partilha concede acesso a registos relacionados com a conta ou o contacto do utilizador.