Conosci i tuoi strumenti: le nove domande

🌐 Disponibile anche in 28 lingue

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · 한국어 · 简体中文 · 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)

Immagine generata con l'IA

Tradotto con l'IA. Non ancora rivisto dalla comunità. Leggi in inglese

Modulo 6 di 7 del capitolo Pensare da Data Architect, il primo capitolo del corso Data Architect. Ogni modulo si regge da solo. Precedente: Costruisci per oggi. Pianifica per domani. Pianifica per il guasto. · Successivo: L’architetto dei dati nell’era dell’IA

La domanda a cui risponde questo modulo: Come valuti qualsiasi strumento, anche uno che non hai mai visto prima?

Gli architetti hanno bisogno di giudizio. Ma il giudizio senza conoscenza non serve a molto. Devi comunque conoscere i tuoi strumenti.

Formo architetti da anni, e uno schema che uso è un insieme di domande a cui dovresti saper rispondere su ogni strumento o funzionalità importante della tua architettura. All’inizio insegnavo otto domande. Ne ho aggiunta una nona. Le tecnologie cambiano, Salesforce cambia, compaiono nuovi prodotti e le vecchie funzionalità si evolvono, e l’IA accelera tutto questo. Queste domande continuano a funzionare.

Le nove domande

Ogni volta che impari o valuti una tecnologia, chiediti:

1. Che cos’è?
2. Dove si usa?
3. Come lo uso?
4. Quali sono le mie alternative?
5. Quali sono i suoi punti di forza?
6. Quali sono i suoi punti deboli?
7. Come lo spiego agli sviluppatori, al business e ai dirigenti?
8. Come si mantiene nel lungo periodo?
9. Quanto costa, quali licenze richiede e quali sono i suoi limiti?

Se sai rispondere a tutte e nove, stai iniziando a capire lo strumento come un architetto. Nota cosa manca nell’elenco: “Posso configurarlo?”. Conta, ma è solo una parte del conoscere lo strumento.

Click to enlarge

1. Che cos’è?

Comincia dalla domanda ovvia, perché la si salta sorprendentemente spesso. Sentiamo il nome di un prodotto o di una funzionalità e iniziamo subito a discutere se usarlo. Rallenta. Cosa fa davvero? Quale problema è stato progettato per risolvere? Dove si colloca nell’architettura, e cosa non è? Un architetto dovrebbe saper descrivere una tecnologia senza ripetere la descrizione del marketing. Se non riesco a spiegare qualcosa in poche frasi, probabilmente non lo capisco ancora abbastanza bene.

2. Dove si usa?

Sapere cosa fa una cosa non equivale a sapere quando appartiene a un’architettura. In quali tipi di problemi è brava? Quali condizioni la rendono adatta, e quali dovrebbero rendermi sospettoso? È il passaggio da “conosco questa funzionalità” a “riconosco il problema che questa funzionalità risolve”, ed è un passaggio importante. Non vuoi andare in giro a cercare posti dove usare la tua tecnologia preferita. Vuoi riconoscere i problemi e sapere quali strumenti vi si adattano.

3. Come lo uso?

Sì, gli architetti dovrebbero capire l’implementazione. Non devi costruire ogni componente, ma dovresti capire abbastanza da sapere cosa stai chiedendo agli altri di costruire. Sappi come si configura, come ci lavora uno sviluppatore, come entrano ed escono i dati, come si distribuisce e si protegge, e come si presenta in esercizio. Non voglio un architetto che progetta intorno a una tecnologia vista solo in una slide di prodotto. Sporcati le mani: costruisci qualcosa, rompi qualcosa, guarda come si comporta davvero. L’architettura migliora quando è ancorata alla realtà.

4. Quali sono le mie alternative?

Potrebbe essere la domanda più importante dell’elenco. Se conosci un solo modo per risolvere un problema, non hai una decisione di architettura; hai un’impostazione predefinita. Ogni volta che qualcuno propone una tecnologia, voglio sapere cos’altro potremmo fare. Un’altra funzionalità Salesforce? Qualcosa di dichiarativo, o codice? La funzionalità potrebbe stare fuori da Salesforce? Potremmo lasciare i dati dove sono invece di copiarli, usare un evento invece di una chiamata API, o evitare del tutto di costruire qualcosa? Le alternative creano trade-off, e i trade-off sono il cuore dell’architettura.

5. Quali sono i suoi punti di forza?

Ogni strumento esiste per una ragione. Capisci in cosa è davvero bravo: cosa rende facile, dove scala bene, quale complessità elimina, quali problemi risolve con eleganza. Usa le tecnologie dove i loro punti di forza coincidono con il problema. Sembra ovvio, ma è facilissimo scegliere uno strumento perché lo abbiamo già, il team lo conosce, è nuovo, o qualcuno ha visto una demo. Possono essere fattori. Non sono la stessa cosa dell’adeguatezza architetturale.

6. Quali sono i suoi punti deboli?

Questa è altrettanto importante. Ogni tecnologia ha punti deboli, tutte quante. Se qualcuno sa dirti solo i punti di forza di una tecnologia, non state ancora facendo una discussione di architettura. Cosa non fa bene? Dove compare la complessità, e cosa succede su larga scala? Quale carico operativo e quali dipendenze porta con sé? Quali requisiti la spingono fuori dalla sua zona ideale? Un punto debole non significa sempre che non dovremmo usare la tecnologia. Significa che dobbiamo sapere cosa stiamo accettando. Un trade-off che capisci può essere una decisione architetturale. Un trade-off che non capisci può diventare una sorpresa.

7. Come lo spiego a pubblici diversi?

È una delle domande che separano la conoscenza tecnica dalla competenza architetturale. Sai spiegare la stessa tecnologia a uno sviluppatore, al business e a un dirigente? Non dovrebbero essere la stessa spiegazione. Allo sviluppatore servono le API, il comportamento delle transazioni, la sicurezza, la gestione degli errori e i pattern di implementazione. Al business interessa cosa rende possibile e come cambia il suo processo. Al dirigente interessano costi, rischi, tempi, impatto sull’organizzazione, e quali opzioni la decisione tiene aperte o chiude. Non stai cambiando la verità; stai cambiando il livello di astrazione. Se l’unico modo in cui sai spiegare una tecnologia è con il vocabolario della sua documentazione, continua a lavorare sulla tua comprensione.

8. Come si mantiene nel lungo periodo?

I progetti finiscono. I sistemi no, o almeno speriamo di no. Qualcuno deve occuparsi di ciò che costruiamo dopo che il team di progetto se ne va. Significa sapere come si monitora, si aggiorna e si diagnostica, chi deve avere le competenze per supportarlo, come vengono distribuite e testate le modifiche, e cosa succede quando la tecnologia si evolve o Salesforce cambia qualcosa sotto di noi. Immaginalo fra tre anni. Ho visto architetture molto ingegnose il giorno del lancio e un tormento da gestire dopo. Non è un successo. La manutenibilità fa parte dell’architettura.

9. Quanto costa, quali licenze richiede e quali sono i suoi limiti?

È la domanda che ho aggiunto alle otto originali, e oggi penso sia impossibile lasciarla fuori. Una tecnologia può essere la soluzione tecnica perfetta ed essere comunque quella architetturale sbagliata se i conti non tornano. È inclusa nelle licenze che abbiamo, o è un componente aggiuntivo? È concessa in licenza per utente, utilizzo, consumo, spazio di archiviazione o transazioni? Cosa succede al costo quando scaliamo?

Poi ci sono i limiti, e ogni piattaforma ne ha: limiti di API, di archiviazione, di query, di transazioni, di concorrenza, di throughput e di licenza. Alcuni sono rigidi, altri flessibili; alcuni si possono alzare e altri no; alcuni non contano alla nostra scala finché non aggiungiamo un altro zero. Non devi memorizzare ogni limite di Salesforce, e farlo sarebbe un pessimo uso del tuo tempo. Devi sapere che i limiti esistono, quali contano per la tua architettura e quando andare a verificare il numero attuale. I numeri cambieranno. La domanda architetturale resta.

Un esempio svolto: la condivisione Apex

Ecco uno dei miei esempi più frequenti delle domande all’opera. Riceviamo un requisito di condivisione complicato, una condivisione che non si può ottenere con nessuna delle regole di condivisione basate sul titolare o sui criteri. Questo ci porta alla condivisione Apex (Apex sharing): codice che scrive da sé i record di condivisione. Ora dobbiamo sapere cos’è la condivisione Apex, dove si usa, come si usa e il resto. È un’escalation: la condivisione Apex è l’alternativa (domanda 4) per quando le regole che ci servono vanno oltre ciò che la condivisione basata sul titolare o sui criteri sa esprimere.

Ora i suoi punti deboli (domanda 6). Diciamo che abbiamo una community di clienti con 10 o 20 milioni di membri, e usiamo la licenza Customer Community, non Customer Community Plus. Sono utenti ad alto volume. Non hanno ruoli, e non usano affatto il modello di condivisione: il loro accesso viene dai set di condivisione e dai gruppi di condivisione, abbinati tramite il loro account e il loro contatto. Non c’è alcun record di condivisione che Apex possa scrivere per loro, quindi la condivisione Apex per loro non funziona. Ed è la domanda su costi e licenze (domanda 9) ad averci portato lì: la scelta della licenza ha deciso quali strumenti di condivisione esistono.

Quindi, come la condivisione Apex era l’alternativa alle regole basate sul titolare e sui criteri, potresti trovarti in un caso in cui ti serve un’alternativa alla condivisione Apex. E a quel punto non esistono davvero opzioni basate sulla configurazione per regole di condivisione complesse. Finisci per rendere l’oggetto di sola lettura e controllare l’accesso tramite Apex. Ecco perché poni tutte e nove le domande prima di scegliere, non dopo.

Non memorizzare la piattaforma

Questo conta soprattutto mentre impari l’architettura Salesforce. Non cercare di memorizzare Salesforce. Non puoi: la piattaforma è troppo grande e cambia troppo in fretta. Lavoro con Salesforce da molto tempo, e sto ancora imparando. È normale.

Ciò che voglio che tu sviluppi è uno schema per imparare. Quando domani Salesforce rilascerà una nuova funzionalità, non devo averla già vista. So cosa chiedere: che cos’è, dove si colloca, come la uso, cos’altro potrei usare, in cosa è brava, dove fa fatica, come la spiego, come la gestisco, quanto costa e dove sono i limiti? Ora posso iniziare a valutarla. Vale molto più che memorizzare un’altra matrice di funzionalità.

Oltre l’esame: l’IA rende più veloce rispondere alle nove domande, e più facile sbagliare. Incontri una tecnologia che non conosci, e puoi chiedere all’IA di spiegartela, confrontare tre approcci, elencarne i limiti e i guasti tipici, o argomentare contro il suo uso. È un assistente di ricerca straordinario. Ma può sbagliare, essere non aggiornata, o confondere con sicurezza due prodotti o edizioni dal nome simile. Per tutto ciò che incide su una decisione, verifica: segui la fonte e controlla la documentazione, i limiti e le licenze attuali. Fidati, ma verifica (modulo 7).

Impara le domande, non solo le risposte

In questo corso incontreremo molte tecnologie. Non voglio che tu collezioni risposte; voglio che tu ti eserciti con le domande. Quando parleremo di big object, dati esterni, Data 360, pattern di integrazione, o di una funzionalità di IA che Salesforce rilascerà sei mesi dopo la stesura di questo capitolo, poni le stesse nove domande.

Le risposte cambieranno. Le domande durano. È questo che ne fa uno schema di architettura e non una guida allo studio.

Conosci i tuoi strumenti: in cosa sono bravi, in cosa sono scarsi, cos’altro potresti usare, quanto costano e dove si rompono. E sappi abbastanza da spiegare la decisione alle persone che dovranno conviverci. È così che un architetto impara la tecnologia.

Cosa decide qui un architetto

• Se uno strumento si adatta al problema, giudicato su tutte e nove le domande, non solo sul fatto che si possa configurare.
• Quali sono le alternative, e cosa significano costi, licenze e limiti dello strumento alla tua scala.
• Chi lo manterrà, e come, fra tre anni.
• Quali fatti sullo strumento verificare prima di farci affidamento.

Per approfondire

• About High-Volume Community or Site Users (opens in a new tab), Guida di Salesforce (in inglese, consultato il 2026-10-09; ricontrollato il 2026-10-12): gli utenti ad alto volume (le licenze External Apps, Customer Community, High Volume Customer Portal e Authenticated Website) non hanno ruoli; il loro accesso viene dai set di condivisione e dai gruppi di condivisione; non possono essere inclusi nelle regole di condivisione basate sul titolare, e i record di cui sono titolari non si possono condividere manualmente.
• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (in inglese, consultato il 2026-10-09; ricontrollato il 2026-10-12): gli utenti ad alto volume (Customer Community, High Volume Customer Portal, Authenticated Website) non usano il modello di condivisione, perché le loro licenze non supportano i ruoli; l’accesso funziona abbinando l’utente ai campi di ricerca Account e Contatto, tramite set di condivisione o gruppi di condivisione. La stessa pagina indica quando la condivisione gestita da Apex è lo strumento giusto.
• Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab), domanda nella Trailblazer Community, novembre 2024 (in inglese, consultato il 2026-10-09; ricontrollato il 2026-10-12): un professionista riferisce che l’inserimento di record di condivisione per utenti ad alto volume è fallito con un errore. Una testimonianza dal campo, non documentazione ufficiale. (La Trailblazer Community online diventa di sola lettura il 30 ottobre 2026; il link potrebbe cambiare.)
• Create a Sharing Set for Experience Cloud Site Users (opens in a new tab), Guida di Salesforce (in inglese, consultato il 2026-10-09): un set di condivisione concede l’accesso ai record collegati all’account o al contatto dell’utente.