Ottimizzazione delle risorse e dei costi

L'ottimizzazione delle risorse e l'ottimizzazione dei costi lavorano insieme per l'azienda per ottenere il massimo valore per costo. Salesforce gestisce l'infrastruttura multi-tenant, applica i limiti del governor che mantengono la piattaforma equa per ogni tenant e applica i prezzi di accesso tramite licenze e crediti di consumo. Quello che si ottimizza è il valore che si ottiene: quanto risultato aziendale restituisce ogni dollaro di spesa e ogni unità di capacità della piattaforma. L'ottimizzazione delle risorse è il meccanismo: utilizza in modo efficiente ciò per cui si paga già. L'ottimizzazione dei costi è il risultato: indirizza deliberatamente la spesa verso ciò che favorisce il vantaggio competitivo. Questo pilastro li considera come un'unica decisione perché sono due punti di vista dello stesso obiettivo.

Questa visualizzazione del valore per costo definisce ogni decisione architettonica presa. Quando si comprende il costo totale di proprietà, si ottengono migliori compromessi tra capacità e investimento. Le soluzioni vengono dimensionate in modo da soddisfare i requisiti aziendali anziché eseguire un provisioning eccessivo di funzioni che non vengono utilizzate o investono poco in funzionalità che accelerano la consegna del valore. Una licenza, un credito consumo, una chiamata API e un ambiente Sandbox sono tutti input della stessa equazione. Ciò che conta è il valore restituito da ciascuno, non il libro mastro su cui si trova. La domanda non è mai "questo è un costo o una risorsa", ma "questo input ha un ritorno appropriato?"

Trascurare questo pilastro produce conseguenze prevedibili. Le aziende accumulano licenze non utilizzate che consumano budget, mentre altre funzionalità rimangono non finanziate. Architetture inefficienti sprecano capacità API, memoria e impegno nello sviluppo per problemi che una progettazione migliore evita. Inefficienza delle risorse in particolari composti nel tempo in modi prevedibili:

Le prestazioni peggiorano man mano che i volumi di dati aumentano.
I timeout delle query emergono a poche centinaia di migliaia di record quando le query non selettive analizzano intere tabelle.
Le eccezioni dei limiti heap vengono visualizzate quando le soluzioni recuperano campi non necessari.
I timeout della CPU si verificano quando i calcoli complessi vengono eseguiti in modo sincrono.
Le soluzioni si moltiplicano man mano che i team aggirano ogni nuovo limite.

Ciascuno di questi errori è sia un problema di affidabilità che un problema di costi, perché il calcolo sprecato consuma la capacità per cui si paga. L'aspetto più importante è che i team perdono opportunità di investire nell'innovazione perché il budget e la capacità ingegneristica vengono consumati dai rifiuti anziché dalle iniziative strategiche.

Soluzioni convenienti ottimizzano il valore:

Utilizzo delle funzionalità della piattaforma già acquistate
Allineare le licenze e il consumo su misura all'utilizzo reale
Modellazione del costo completo prima di impegnarsi in un approccio
Monitoraggio continuo della spesa rispetto ai risultati aziendali

Queste pratiche si complicano. I team che integrano la consapevolezza dei costi e l'efficienza delle risorse nella loro progettazione offrono una maggiore capacità per dollaro rispetto ai team che considerano l'ottimizzazione come un esercizio di pulitura dopo che la spesa è già cresciuta.

L'ottimizzazione delle risorse e dei costi si collega direttamente ad altri pilastri architettonici. L'eccellenza operativa riduce i costi correnti con un'automazione che riduce l'impegno manuale. Affidabilità e Trust giustificano gli investimenti premiali attraverso la garanzia della continuità operativa e il valore di conformità normativa. Insieme, questi pilastri aiutano le aziende a investire con fiducia perché la loro architettura offre il massimo ritorno.

Utilizzare questi principi per guidare le decisioni relative all'architettura per l'ottimizzazione delle risorse e dei costi sulla piattaforma.

Ottimizzare il costo totale di proprietà. Il costo totale di proprietà (TCO) si estende oltre le spese di abbonamento ai crediti di consumo, ai costi di implementazione, ai costi operativi, alle spese di integrazione e alla gestione del cambiamento. Valutare le decisioni utilizzando l'analisi del TCO per rivelare il quadro completo dell'investimento per tutta la durata di una soluzione. A volte un investimento iniziale più elevato riduce in modo significativo i costi operativi correnti e l'analisi del TCO evidenzia questo compromesso. Ottimizzare per il valore a lungo termine, non per ridurre al minimo i costi a breve termine.
Allineare la spesa al valore aziendale. Collegare ogni investimento Salesforce a un risultato aziendale misurabile. La spesa per le licenze consente di misurare la produttività degli utenti attraverso l'adozione e il completamento delle operazioni. L'investimento in Data 360 consente di prendere decisioni misurate attraverso la conversione e il valore di durata del cliente. Il Sandbox costa la velocità di sviluppo dei fondi misurata attraverso la frequenza e la qualità della distribuzione. Quando la spesa si allinea al valore, si investe con fiducia in ciò che favorisce il successo e si identifica la spesa che non ottiene più il suo ritorno.
Progettare entro i limiti della piattaforma. I limiti del governor definiscono gli elementi che una soluzione può elaborare per transazione. Considerarli fin dall'inizio come vincoli di progettazione, non come ostacoli da aggirare. Progettare transazioni che operino comodamente entro i limiti in presenza di picchi di carico e volumi di dati massimi e creare margini per funzioni future, altri pacchetti installati e schemi di dati imprevisti. Le soluzioni progettate entro i limiti fin dalla concezione hanno prestazioni prevedibili ed evitano il refactoring di emergenza in seguito.
Ottimizzare le risorse già a pagamento. Prima di acquistare ulteriore capacità, ottimizzare la produttività, l'efficienza e il valore degli asset piattaforma già forniti. Query efficienti, elaborazione dei record in blocco (bulkification), caching e ciclo di vita dei dati disciplinato riducono il consumo di calcolo, archiviazione e API necessario per una soluzione. Questa efficienza delle risorse è il meccanismo che guida l'ottimizzazione sostenibile dei costi: gli sprechi eliminati dalle risorse fornite migliorano sia le prestazioni che il TCO a lungo termine.
Licenze e consumo adeguati all'utilizzo effettivo. Abbinare ogni utente al tipo di licenza richiesto dal suo lavoro e progettare automazioni e agenti per invocare i servizi con contatore in modo efficiente. Le licenze eccessive e i crediti di consumo non monitorati sono tra le fonti di rifiuti più comuni e costose. Controlli periodici dei ruoli, dell'attività di accesso e dell'utilizzo delle funzioni consentono di raddrizzare le opportunità e una chiara visibilità sul credito bruciato consente di mantenere prevedibili i costi basati sul consumo.
Stabilire una governance finanziaria e una cultura consapevole dei costi. Gestire la spesa Salesforce come investimento strategico attraverso la supervisione attiva e la condivisione delle responsabilità. La governance finanziaria inserisce l'analisi costi-benefici nelle decisioni di progettazione anziché individuare i costi dopo la distribuzione. La consapevolezza dei costi è una responsabilità condivisa tra gli stakeholder aziendali, gli architetti e gli sviluppatori che ponderano le implicazioni dei costi insieme ai requisiti funzionali, quindi le decisioni di investimento intelligenti avvengono a tutti i livelli senza colli di bottiglia centralizzati.
Praticare l'ottimizzazione continua. L'ottimizzazione è una pratica continua, non un esercizio occasionale. Monitorare la spesa e il consumo di risorse tramite cruscotti digitali accessibili agli stakeholder tecnici e aziendali. Configurare avvisi che vengono attivati quando la spesa per consumi raggiunge le soglie prima che il consumo incontrollato passi inosservato. Esami periodici individuano gli sprechi che si accumulano gradualmente, confermano che gli investimenti di ottimizzazione precedenti hanno prodotto il ritorno previsto e fanno emergere nuove opportunità man mano che le priorità aziendali e i volumi di dati si evolvono.

Capire che cosa funziona Salesforce aiuta a concentrare le attività di ottimizzazione su ciò che si controlla. La piattaforma gestisce la gestione delle risorse a livello di infrastruttura che richiede team dedicati negli ambienti IT tradizionali:

Allocazione di risorse multi-tenant: Salesforce garantisce una condivisione equa delle connessioni CPU, memoria e database tra tutti i clienti nell'infrastruttura condivisa, monitora il consumo dei tenant e impone limiti che impediscono a un singolo tenant di peggiorare le prestazioni per gli altri.
Architettura del limite del governatore: I confini imposti dalla piattaforma (100 query SOQL per transazione sincrona, 10 secondi di CPU, 6 MB di dimensione heap) proteggono tutti i tenant dall'esaurimento delle risorse. Salesforce calibra questi limiti sulla capacità dell'infrastruttura multi-tenant. Questi limiti sono confini architettonici, non restrizioni arbitrarie.
Ottimizzazione delle query e motore di esecuzione: L'ottimizzazione delle query di Salesforce genera piani di esecuzione, gestisce le statistiche sulla distribuzione dei dati e seleziona i percorsi di query ottimali. Gli indici gestiti dalla piattaforma sui campi standard accelerano gli schemi di query comuni e l'ottimizzazione si adatta automaticamente alle variazioni del volume di dati.
Riscalamento dell'infrastruttura: Salesforce esegue il provisioning della capacità hardware, gestisce i cluster di database, distribuisce il carico e scala l'infrastruttura man mano che l'utilizzo aumenta. Non eseguire mai il provisioning dei server, gestire la replica del database o configurare i bilanciamenti del carico.
Ottimizzazione delle prestazioni della piattaforma: Salesforce ottimizza continuamente il codice core della piattaforma, l'esecuzione di query, i tempi di risposta API e le prestazioni del framework dell'interfaccia utente e migliora l'infrastruttura tramite i rilasci periodici senza richiedere l'intervento del cliente.

Salesforce gestisce anche il lato commerciale della piattaforma, motivo per cui licenze e consumo appartengono allo stesso pilastro di elaborazione e archiviazione. La piattaforma definisce le versioni, i tipi di licenza, i componenti aggiuntivi e i modelli di credito al consumo tramite cui viene acquistata la capacità e misura l'utilizzo che riduce tali crediti. Non si impostano questi prezzi più di quanto si forniscano i server, ma si decide quanto di ciascuno consuma: quale licenza detiene ogni utente, in che modo un'automazione invoca un servizio con contatore, quanti Sandbox rimangono attivi.

Queste operazioni della piattaforma sono la base su cui si crea. Poiché Salesforce gestisce sia l'infrastruttura che il modello di calcolo dei prezzi, l'impegno di ottimizzazione si concentra interamente sulle decisioni relative all'architettura: l'efficienza con cui si utilizzano le risorse messe a disposizione e la volontà di indirizzare la spesa per il provisioning.

Il modello di responsabilità condivisa indica che si è titolari dell'efficienza delle risorse per tutto ciò che si crea in Salesforce. La gestione delle risorse piattaforma supporta il lavoro, ma non sostituisce la necessità di ottimizzare. Una soluzione efficiente restituisce più valore aziendale dalla capacità di calcolo, archiviazione e API già pagata, ed è questo il meccanismo che mantiene sostenibile l'ottimizzazione dei costi anziché un taglio del budget una tantum. Lo spreco di calcolo, al contrario, consuma le risorse dell'infrastruttura senza offrire valore aziendale e i relativi costi composti. Le prestazioni peggiorano in modo prevedibile man mano che i volumi di dati aumentano e le soluzioni si moltiplicano man mano che i team aggirano i limiti che avrebbero potuto progettare.

Le responsabilità di ottimizzazione riguardano quattro aree interconnesse: prestazioni, organizzazione del codice, creazione di pacchetti e dati. Ciascuna è una decisione basata sul valore per costo prima che tecnica. Questa sezione spiega come prendere questa decisione e perché è importante. I procedimenti di implementazione esatti, i modelli a livello di codice, la navigazione in Imposta e le soglie di ottimizzazione specifiche a cui si fa riferimento in questa sezione si trovano nella libreria degli schemi di ottimizzazione delle risorse e dei costi.

L'ottimizzazione delle prestazioni inizia con un cambiamento nel modo in cui si considerano i limiti del governor. Non sono ostacoli da aggirare. Si tratta di vincoli architettonici che, abbracciati fin dalla progettazione iniziale, producono soluzioni con caratteristiche prestazionali prevedibili. Ogni transazione viene eseguita entro limiti prefissati e tali limiti esistono per imporre un'equa condivisione delle risorse in ogni tenant della piattaforma. Una transazione Apex che utilizza 95 delle 100 query SOQL consentite non lascia margini per funzioni future, trigger aggiunti da altri team o schemi di dati imprevisti. Gli architetti che mantengono le transazioni ben al di sotto della metà del limite creano soluzioni che possono crescere senza refactoring di emergenza quando un limite viene esaurito. La disciplina consiste nel progettare bene entro i limiti sotto carico di picco e ai volumi massimi di dati, in modo che l'aggiunta di una funzione o l'automazione di un altro pacchetto non spinga mai una transazione oltre il limite. Un errore comune e costoso: la soluzione funziona perfettamente contro 10 record in un Developer Sandbox, ma soddisfa i limiti del governor in produzione. I Developer Sandbox copiano solo la configurazione e non contengono dati. Il test con volumi realistici in un Full Copy Sandbox evidenzia i problemi di scalabilità prima dei clienti.

La selettività delle query è la leva più grande per determinare se una soluzione può essere scalata a milioni di record o se il timeout è centinaia di migliaia. Le query selettive utilizzano gli indici per individuare i record in modo efficiente, mentre le query non selettive analizzano intere tabelle, consumano risorse di database eccessive e alla fine si verificano dei timeout. La piattaforma mantiene indici standard su un insieme definito di campi e applica soglie di selettività che si riducono man mano che un oggetto supera il primo milione di record. Progettare per la selettività significa applicare un filtro ai campi indicizzati come criterio principale e convalidare con lo strumento Query Plan (Piano di esecuzione query) prima di distribuirlo a oggetti di grandi dimensioni, poiché una query che mostra una scansione della tabella su un oggetto a volume elevato è un incidente di produzione in attesa di verificarsi. La selettività è la capacità che non è necessario acquistare: una query efficiente restituisce in millisecondi e lascia disponibili le risorse di database per ogni altro tenant e ogni altra transazione nella propria organizzazione.

Bulkification è lo schema di scalabilità di base che distingue Apex che funziona su larga scala da Apex che supera i limiti. L'anti-schema (una query o un'istruzione DML inserita all'interno di un loop) funziona correttamente con insiemi di record piccoli ma viola i limiti del governor nel momento in cui viene eseguita un'operazione in blocco. Il rimedio consiste nell'eseguire query su tutti i dati necessari in singole istruzioni all'esterno dei loop, organizzare i risultati in mappe basate su ID per una ricerca rapida durante l'iterazione ed elaborare un'intera raccolta con DML in batch. Progettare ogni automazione per gestire il batch di trigger standard da 200 record senza avvicinarsi ai limiti e lo stesso codice viene scalato indipendentemente dal carico in produzione.

L'elaborazione asincrona esiste per il lavoro che non può o non deve essere completato entro i limiti sincroni di una transazione utente. Lo spostamento di quel lavoro in un contesto asincrono raddoppia grosso modo i limiti del governor disponibili e impedisce che operazioni di lunga durata blocchino gli utenti. Questo headroom è reale, ma non è gratuito, e raggiungere l'asincrono ogni volta che un limite si sente vicino è un errore. L'asincrono è un compromesso architetturale deliberato: introduce una coerenza finale, quindi il risultato del lavoro non è visibile nella transazione che lo ha richiesto, il che forza le decisioni sull'esperienza degli utenti che non dipendono dalla conferma immediata. Richiede la gestione e il monitoraggio espliciti degli errori, perché un errore viene visualizzato in un registro processi anziché nell'utente che lo ha attivato. E può complicare il modello mentale del sistema quando una singola operazione aziendale si estende a più transazioni. La decisione del valore per costo è quella di ponderare la complessità aggiuntiva con la capacità di cui il lavoro ha realmente bisogno e di mantenere il lavoro sincronizzato quando è comodo.

Quando l'asincrono è la chiamata giusta, la scelta tra i meccanismi segue la forma del lavoro anziché la dimensione del limite. Batch Apex è per il volume. Elabora milioni di record suddividendoli in blocchi, ciascuno con i propri limiti governor indipendenti, motivo per cui la migrazione dei dati, l'archiviazione dei dati e l'arricchimento in blocco appartengono a questa categoria. L'area di attesa è per la sequenza: gestisce flussi di lavoro a più fasi che superano i limiti sincroni ma non richiedono la scala Batch e supporta la concatenazione di un processo da un altro per le fasi che devono essere eseguite in ordine. Gli eventi piattaforma sono per il disaccoppiamento: un produttore emette un evento senza conoscere o attendere i propri consumatori. Utilizzare questo schema per la notifica tra sistemi e per separare il lavoro che non appartiene alla stessa transazione, tenendo presente che la consegna almeno una volta richiede abbonati idempotenti. I metodi futuri coprono il caso ristretto del lavoro asincrono semplice con input primitivi, più comunemente una chiamata da un trigger sincrono. La loro incapacità di concatenare o accettare oggetti complessi è proprio il motivo per cui non sono uno strumento per il lavoro asincrono multiuso. Abbinare il meccanismo asincrono alla forma del lavoro. In caso contrario, si scambia un problema di limite governor con costi di coerenza e monitoraggio superiori al guadagno.

Il caching converte il lavoro ripetuto in capacità mantenuta. La cache piattaforma memorizza i dati serializzabili oltre i confini delle transazioni, quindi un hit della cache evita di eseguire nuovamente la query o il ricalcolo che ha prodotto il valore, riducendo direttamente il consumo di SOQL e CPU. La decisione che decide di creare o interrompere una cache è ciò che si sceglie di inserire e per quanto tempo. Inserisci nella cache i dati letti molto più spesso di quanto non cambino, ad esempio i metadati personalizzati, la configurazione e i valori degli elenchi di selezione, e imposta il time-to-live in modo che corrisponda alla volatilità dei dati anziché a un singolo valore predefinito. I dati di riferimento che cambiano ogni mese possono essere memorizzati nella cache per ore, mentre la configurazione che cambia durante la giornata richiede un breve periodo di tempo in modo che la cache non serva mai un valore non aggiornato abbastanza a lungo da avere importanza. Una cache troppo aggressiva scambia un guadagno in termini di prestazioni con un rischio di correttezza e una cache con una percentuale di hit scarsa spende memoria senza restituire capacità, motivo per cui la percentuale di hit è una metrica da monitorare anziché un'impostazione da presumere. La scelta della partizione è una decisione di sicurezza: utilizzare la partizione dell'organizzazione per i dati condivisi tra gli utenti, utilizzare la partizione della sessione per i dati con ambito utente che devono rimanere isolati e non inserire mai informazioni personali nella partizione dell'organizzazione dove ogni utente può leggerle. Lightning Data Service estende la stessa idea al client: condivide i record memorizzati nella cache in ogni componente di una pagina ed elimina i round trip del server ridondanti. Ogni hit della cache è capacità di calcolo e API che non è necessario spendere, a condizione che il valore restituito sia ancora corretto.

Lo scostamento dei dati è un hotspot delle prestazioni creato da una distribuzione dei record non bilanciata. Quando un singolo record controllante accumula più di 10.000 elementi controllati, le prestazioni delle query peggiorano ed emerge una disputa per il blocco delle righe durante le operazioni simultanee. La soglia è un segnale di progettazione, non un limite rigido. Consente di distribuire il carico tra più controllanti, monitorare gli oggetti a volume elevato con processi pianificati che avvisano quando un controllante si avvicina al confine e ordinare i carichi in blocco in base all'ID controllante in modo che i batch simultanei non si scontrino per le stesse righe. La distorsione della proprietà, in cui un utente integrazione è titolare di centinaia di migliaia di record, produce la stessa contesa di blocco e merita la stessa distribuzione del carico.

Salesforce fornisce strumenti per mantenere sane le caratteristiche delle prestazioni man mano che una soluzione si evolve. Scale Center offre visibilità a livello di transazione sulle operazioni di lunga durata, sulle controversie di blocco delle righe e sulle transazioni che si avvicinano ai limiti, quindi assegna un nome al trigger specifico e all'oggetto interessato. ApexGuru applica l'analisi AI alla telemetria in fase di esecuzione della produzione per evidenziare gli schemi anti-scala prima che raggiungano la scala, e Salesforce Code Analyzer esegue analisi statiche nella pipeline CI/CD in modo che le build falliscano quando vengono rilevate query all'interno di loop o altri difetti di prestazioni. Event Monitoring rivela le tendenze di consumo nel tempo e Proactive Monitoring, una funzione del piano di successo della firma, valuta continuamente i rischi di prestazioni e scalabilità dell'organizzazione.

L'organizzazione del codice è una decisione sui costi espressa come manutenibilità. La manutenzione in genere consuma la maggior parte della capacità di sviluppo di una soluzione matura, quindi la struttura scelta determina la quantità di capacità futura destinata a cambiare anziché a essere rielaborata. Tre schemi contengono la maggior parte di quel valore. Lo schema dell'handler trigger centralizza la logica dei trigger nelle classi di handler e riduce il file trigger stesso a un punto di delega minimo, che mantiene la logica testabile indipendentemente dal contesto del trigger e offre un'unica pagina iniziale per il controllo della ricorsione. Lo schema del livello di servizio incapsula la logica aziendale in classi che espongono operazioni richiamabili da un trigger, un endpoint REST, un flusso invocabile o un processo batch, quindi una regola aziendale vive in un'unica implementazione anziché essere duplicata in ogni punto di ingresso e non sincronizzata. Lo schema di selezione centralizza SOQL per ogni oggetto nelle classi dedicate, rendendo la regolazione delle query una modifica a punto singolo e assegnando a ogni query un intento esplicito denominato.

Gli errori DML misti sono un rischio organizzativo distinto contro cui vale la pena progettare in modo esplicito. Si verificano quando una transazione esegue DML sia sugli oggetti di impostazione, ad esempio Utente e PermissionSet, che sugli oggetti non di impostazione, ad esempio Account e oggetti personalizzati, poiché le modifiche dell'impostazione che influiscono sull'accesso di un utente devono essere confermate in una transazione separata. L'errore si presenta su larga scala nei processi di integrazione, nell'impostazione dei test e nell'automazione del provisioning utente. I rimedi architetturali sono separare il DML di impostazione e non di impostazione oltre i confini delle transazioni utilizzando l'elaborazione asincrona o gli eventi piattaforma, progettare modelli di dati che evitino di combinare le due operazioni in un'unica fase aziendale e isolare il DML di impostazione nei test.

Le scelte di packaging determinano i costi di sviluppo a lungo termine e il riutilizzo che è possibile ottenere in tutta l'azienda. I pacchetti gestiti di seconda generazione offrono uno sviluppo modulare basato sulla fonte con protezione dello spazio dei nomi e sono la scelta giusta per i prodotti ISV (Independent Software Vendor) distribuiti tramite AgentExchange. I pacchetti sbloccati offrono ai team interni la stessa modularità e la stessa gestione delle dipendenze senza sovraccarichi di spazio dei nomi, il che si adatta alle applicazioni aziendali che richiedono una distribuzione indipendente ma non un elenco di marketplace. I pacchetti gestiti di prima generazione rimangono in uso per i prodotti esistenti, ma mancano del flusso di lavoro basato sulla fonte che rende possibile la manutenzione del nuovo sviluppo modulare.

La modularità si estende ai componenti creati. Progettare i componenti Web Lightning attorno a un'unica responsabilità con interfacce delle proprietà chiare, privilegiare la composizione rispetto all'eredità in modo che le interfacce utente complesse vengano assemblate da piccoli componenti specifici e utilizzare gli eventi personalizzati per la comunicazione controllante anziché raggiungere direttamente una controllante. Esporre Apex riutilizzabili come azioni invocabili in modo che gli amministratori possano comporre l'automazione in Flow Builder a partire dalle funzionalità create dagli sviluppatori, riducendo la duplicazione e collegando il mondo dichiarativo e quello della programmazione. Una modularità ben progettata è ciò che consente di creare una funzionalità una volta e riutilizzarla, anziché reimplementarla e mantenerla separatamente in ogni posizione in cui è necessaria.

La crescita non gestita dei dati è la fonte più comune di deterioramento graduale delle prestazioni e determina il costo di archiviazione e il tempo di aggiornamento del Sandbox in parallelo. Due decisioni regolano l'efficienza dei dati. Il primo è la progettazione del modello di dati. Le relazioni record principale-record dettaglio offrono l'eliminazione a catena, i riepiloghi di roll-up e la condivisione dei dati a costo di un accoppiamento più stretto. Le ricerche offrono flessibilità a costo di una logica di roll-up personalizzata e una strategia di indice deliberata sui campi filtrati mantiene le query selettive man mano che gli oggetti crescono. Il secondo è il ciclo di vita dei dati. Definire un ciclo di vita completo dalla creazione all'archiviazione anziché consentire agli oggetti di accumulare record all'infinito, poiché un oggetto che cresce fino a milioni senza una strategia di archiviazione alla fine produce timeout di query, query non selettive e visualizzazioni elenco in timeout.

Scegliere il meccanismo di archiviazione solo dopo aver stabilito la conformità. Prima di scegliere un meccanismo, verificare se i requisiti di residenza dei dati, diritto alla cancellazione o conservazione limitano le opzioni. I Big Object non possono essere modificati dopo l'inserimento, il che rende l'eliminazione dei dati personali archiviati solo record un'operazione di eliminazione e ricreazione che può influire sugli itinerari di controllo. I Big Object archiviano serie di dati storiche di grandi dimensioni nello spazio di archiviazione, separate dai limiti standard e adatte alle transazioni completate e ai registri di controllo non più necessari per il lavoro quotidiano. La memoria esterna consente di mantenere i dati interrogabili tramite Salesforce Connect riducendo il volume dell'organizzazione e si adatta a schemi di query flessibili o all'integrazione con un data warehouse aziendale. Monitorare il consumo di memoria a livello di oggetto in modo che la crescita sia visibile prima che diventi un problema, utilizzare Salesforce Files anziché gli allegati legacy e configurare la conservazione dell'itinerario di controllo campi per campo in base alle esigenze di conformità, anziché applicare un limite massimo complessivo che spreca memoria.

L'ottimizzazione dei costi bilancia il valore aziendale con il costo della soluzione e dipende innanzitutto dalla determinazione di un costo preciso. A questo scopo, tenere conto di ogni componente di costo, poiché l'analisi di un singolo componente, ad esempio il costo della licenza, porta a un'errata comprensione del costo effettivo della soluzione. Un modesto canone di licenza può nascondere i costi di implementazione, operativi, di integrazione e di modifica che ne aumentano il volume. Una decisione presa solo sul numero visibile utilizza solo una parte dell'immagine. Il costo totale di proprietà è il modello che acquisisce il quadro completo. Include tutti i costi associati a una soluzione Salesforce nel corso del suo ciclo di vita e li suddivide in costi diretti, chiaramente associati alla soluzione, e costi indiretti, reali ma facili da ignorare. La modellazione di entrambi trasforma una stima dei costi in una decisione informata sull'architettura che pondera il valore a lungo termine anziché solo la spesa iniziale.

I costi diretti sono sostenuti per l'implementazione, il funzionamento e la manutenzione del sistema:

I costi di licenza e consumo sono costi di abbonamento continui che variano in base alla versione, al tipo di utente e al set di funzioni, più i crediti basati sul consumo. La scelta della versione Edition è una decisione di costo fondamentale perché le differenze per utente sono significative. Poiché i costi di consumo sono difficili da modellare in anticipo, rivedere le stime quando si prendono le decisioni di progettazione.
I costi di implementazione coprono la progettazione, lo sviluppo, il test, la migrazione dei dati e la formazione delle soluzioni. Sono prevalentemente una tantum ma creano obblighi di manutenzione continuativi proporzionali alla complessità. Le aziende sottovalutano sistematicamente lo sforzo di implementazione perché si concentrano sullo sviluppo e sottovalutano i test e la formazione.
I costi operativi coprono l'amministrazione, l'assistenza agli utenti, il monitoraggio, la risposta agli incidenti e gli strumenti operativi. Crescono con la complessità delle soluzioni e sono spesso invisibili nella pianificazione perché si manifestano come impegno interno anziché come fatture esterne.
I costi di manutenzione coprono il potenziamento, la riparazione tecnica del debito, l'adattamento del rilascio e le modifiche della configurazione. La manutenzione in genere consuma il 60-80% della capacità di sviluppo per le soluzioni mature, il che la rende la più grande categoria di costo in corso.
I costi di integrazione includono le licenze piattaforma di integrazione, il consumo API, lo sviluppo della sincronizzazione e la manutenzione continua. Crescono con la complessità dell'ecosistema perché la manutenzione dell'integrazione da punto a punto aumenta con l'aumento del conteggio dei sistemi.
I costi di modifica coprono la riprogettazione dei processi aziendali, la gestione del cambiamento, l'adozione e il coordinamento degli stakeholder. Aumentano man mano che la portata delle unità operative e delle aree geografiche, e spesso vengono omesse perché si manifestano come attività del team aziendale.

I costi indiretti non sono immediatamente visibili nella pianificazione iniziale ma si accumulano in modo significativo nel corso della vita di una soluzione e per le implementazioni mature spesso superano i costi diretti. Un'azienda che ottimizza solo i costi diretti ignorando le spese indirette perde la maggior parte dell'investimento totale. Diverse categorie meritano un'attenzione esplicita.

I costi dell'organizzazione sono gli investimenti che determinano il successo di Salesforce ma non compaiono mai in una fattura Salesforce. Comprendono gli stipendi interni dei team per amministratori, sviluppatori e architetti, l'infrastruttura di sviluppo come il controllo delle versioni e gli strumenti CI/CD, la formazione e la manutenzione delle certificazioni e lo sviluppo delle competenze e il costo opportunità della capacità di sviluppo allocata alla manutenzione anziché all'innovazione. Quest'ultimo elemento è difficile da rilevare, perché non viene visualizzato come speso affatto. Si presenta come l'innovazione che non ha mai spedito.

L'interesse debito tecnico è il costo composto delle scelte rapide architettoniche. Le scelte rapide adottate per rispettare una scadenza di lancio creano un onere di manutenzione che può richiedere più volte l'impegno originale per essere risolto in seguito e ogni sprint speso per rimediare al debito è uno sprint che non fornisce nuovo valore aziendale. I team che rinviano i miglioramenti dell'architettura abbastanza a lungo alla fine scoprono che la maggior parte della loro capacità va alla manutenzione anziché a nuove funzionalità.

Il sovraccarico di governance richiede tempo nei processi di approvazione, nelle riunioni di coordinamento e nelle revisioni manuali. La governance offre un valore reale attraverso la riduzione del rischio e la coerenza, ma un eccesso di governance crea costi nascosti attraverso decisioni ritardate e sforzi duplicati, motivo per cui l'obiettivo è progettare sistemi che promuovono un'autonomia sicura anziché richiedere un collo di bottiglia di approvazione centralizzata per ogni modifica.

Le funzionalità inutilizzate si accumulano quando le funzioni vengono implementate ma non vengono mai adottate completamente. Una soluzione distribuita parzialmente consuma manutenzione continua senza fornire valore proporzionale e il monitoraggio dell'utilizzo delle licenze e dell'adozione delle funzioni rivela le capacità per investire ulteriormente o ritirarsi per reindirizzare la capacità.

Una visibilità completa dei costi richiede l'attribuzione sia delle voci dirette che di quelle indirette, poiché solo un quadro completo supporta una decisione di investimento corretta.

Creare modelli TCO per la base di riferimento e per alternative architettoniche ottimizzate prima di impegnarsi in un approccio. I modelli che proiettano i costi da 3 a 5 anni con presupposti documentati consentono di confrontare le opzioni in modo sistematico. Eseguire un'analisi della sensibilità sui presupposti più importanti per determinare le varianze e i confini delle stime dei costi. Pianificare di rivedere le decisioni man mano che le condizioni cambiano. La disciplina di scrittura delle ipotesi fa parte del valore, perché rende una rivalutazione successiva un confronto basato su prove anziché un argomento nuovo.

Valutare le soluzioni disponibili in commercio rispetto allo sviluppo personalizzato utilizzando un confronto completo del TCO anziché il solo costo iniziale. Le decisioni Build-VS-Buy modellano l'investimento a lungo termine attraverso le spese di abbonamento o gli obblighi di manutenzione continua e le due strade presentano profili di investimento fondamentalmente diversi.

AgentExchange (precedentemente noto come AppExchange) è la principale fonte di soluzioni pronte all'uso della comunità ISV Salesforce. Il suo profilo di investimento favorisce la velocità e la manutenzione condivisa. La distribuzione viene misurata in settimane anziché nei mesi richiesti da una build personalizzata comparabile. Il fornitore mantiene le funzionalità, inclusa la compatibilità con i rilasci piattaforma, senza impegno da parte del cliente. La funzionalità è dimostrata da una base di clienti esistente, che riduce il rischio di implementazione. Le capacità specializzate traggono vantaggio dall'esperienza nel settore dei fornitori e dagli investimenti nella ricerca che superano quelli che una singola azienda finanzierebbe da sola. La disponibilità del supporto varia a seconda del provider di servizi, in genere con un percorso di inoltro al livello superiore definito per i problemi, e comporta un costo di abbonamento continuo al modello.

Lo sviluppo personalizzato favorisce l'adattamento e il controllo. Si allinea esattamente ai requisiti organizzativi specifici senza compromettere gli schemi di soluzione generica, offre il controllo completo sulle funzionalità e sulle priorità della roadmap, non porta con sé alcun abbonamento in corso oltre le licenze piattaforma di base e può creare un vantaggio competitivo attraverso funzionalità non disponibili per i concorrenti che utilizzano le stesse soluzioni pronte all'uso. Il compromesso è che l'azienda si assume la piena responsabilità della manutenzione e della compatibilità della soluzione con ogni rilascio di Salesforce.

Un confronto TCO a lungo termine trasforma questi profili in una decisione. Le soluzioni pronte all'uso comportano costi di abbonamento annuali aggiuntivi ma includono aggiornamenti di manutenzione, miglioramento e compatibilità forniti dal fornitore. Le soluzioni personalizzate richiedono un investimento di sviluppo una tantum, ma comportano costi di manutenzione continua e la piena responsabilità della compatibilità dei rilasci. Proiettare i totali da 3 a 5 anni per entrambi in modo che il confronto rifletta l'investimento completo anziché la spesa iniziale, che di solito privilegia l'opzione che sembrava più economica il primo giorno.

Oltre al costo grezzo, quattro fattori determinano la decisione tra build e buy.

La differenziazione strategica determina se una capacità è un vantaggio competitivo che vale la pena costruire o una merce acquistata meglio.
Time to value favorisce l'acquisto quando una funzionalità è necessaria immediatamente per cogliere un'opportunità o rispondere alla pressione della concorrenza, perché una funzionalità personalizzata sostanziale richiede mesi.
La capacità organizzativa favorisce la creazione solo se esiste un team interno capace di gestire ed evolvere la soluzione nel tempo e favorisce l'acquisto quando tale capacità è assente.
Il costo di uscita privilegia le opzioni che preservano la flessibilità, perché una soluzione che crea un deep lock-in attraverso formati proprietari o un'estesa personalizzazione è un rischio se i requisiti cambiano.

Sistematizzare la decisione in modo che si basi su una valutazione coerente anziché su un giudizio specifico.

Licenze e consumo sono input nell'equazione del valore per costo esattamente come calcolo e stoccaggio e sono tra le fonti più comuni di rifiuti. Ottimizzarli non significa ridurre i costi. Si tratta di abbinare ogni utente alla licenza giusta per il proprio lavoro e invocare ogni servizio con contatore in modo efficiente.

L'ottimizzazione delle licenze abbina ogni utente al tipo di licenza corretto. In sostanza, si tratta di abbinare ogni utente dell'azienda alla licenza richiesta dal suo lavoro. L'eccesso di licenze, ad esempio l'assegnazione di licenze piattaforma complete agli utenti che necessitano solo di funzionalità limitate (accesso di sola lettura o approvazioni di flussi di lavoro semplici), è uno degli errori più comuni e costosi che le aziende commettono ed è invisibile finché qualcuno non lo cerca. Un controllo regolare dei ruoli utente, dell'attività di accesso e dell'utilizzo delle funzioni consente di ottenere risparmi significativi rendendo più corrette le assegnazioni in tutta la base di utenti. Eseguirlo con cadenza, non solo al momento del rinnovo: i disallineamenti crescono in silenzio man mano che cambiano i ruoli e le persone cambiano posizione nell'azienda.

L'ottimizzazione del credito al consumo è sempre più importante man mano che le aziende adottano Agentforce, Data 360 e altre funzionalità basate sull'intelligenza artificiale che determinano il prezzo in base all'utilizzo anziché alla sede. I pool di crediti possono esaurirsi in modo sorprendentemente rapido quando i team progettano i processi in modo inefficiente o non monitorano i modelli di utilizzo. A differenza di un conteggio licenze fisso, il consumo può aumentare senza che venga presa alcuna decisione di provisioning. Stabilire una chiara visibilità sui tassi di combustione del credito, impostare soglie di consumo che attivano la revisione e progettare automazioni e agenti per essere efficienti nel modo in cui invocano i servizi con contatore. Lo stesso lavoro di efficienza che mantiene una transazione entro i limiti del governor mantiene un servizio con contatore entro il budget di credito. Questa è la stessa idea di valore per costo, espressa in termini di consumo.

La strategia per l'ambiente e i Sandbox è una decisione della risorsa con conseguenze dirette sui costi e un modello di consegna Salesforce maturo richiede una strategia ambientale ben strutturata. Gli ambienti di sviluppo, test, gestione temporanea e produzione hanno ciascuno uno scopo specifico e il giusto mix di tipi Sandbox consente ai team di creare e convalidare le modifiche in modo sicuro prima che raggiungano la produzione. La sfida è che senza una governance deliberata, il numero di Sandbox attivi prolifera rapidamente, soprattutto nei programmi di grandi o lunghe durata, e aumenta i costi in modo da cogliere le aziende alla sprovvista. Il rimedio consiste nel trattare il provisioning Sandbox con la stessa intenzionalità di qualsiasi altra risorsa. Aggiornare o annullare il provisioning dei Sandbox che non sono più utilizzati attivamente anziché lasciarli inattivi, lasciare che la scelta del tipo di Sandbox sia determinata dall'effettiva necessità di fedeltà dei dati anziché dalla convenienza e impostare policy chiare per la proprietà, la cadenza di aggiornamento e la disattivazione in modo che l'azienda rimanga all'altezza del lavoro.

L'architettura multi-organizzazioni moltiplica i costi. Un'architettura a organizzazione singola beneficia di licenze consolidate, infrastruttura piattaforma condivisa e di un sovraccarico amministrativo ridotto, perché è semplicemente meno necessario gestire, configurare e gestire. Quando tutte le unità operative operano all'interno di una stessa organizzazione, le integrazioni sono interne anziché tra organizzazioni, la condivisione dei dati è nativa e l'impronta totale dei Sandbox, dell'assistenza e degli strumenti di governance rimane proporzionalmente più piccola. Le architetture multi-organizzazioni, sebbene talvolta necessarie per motivi geografici, di conformità normativa o di separazione organizzativa, introducono un effetto moltiplicatore su alcune categorie di costo. Ogni organizzazione aggiuntiva apporta i propri requisiti di licenza, il proprio patrimonio Sandbox, il proprio sovraccarico di integrazione e il proprio impegno amministrativo e richiede strumenti più sofisticati per gestire la distribuzione tra organizzazioni, la federazione delle identità e la sincronizzazione dei dati. Comprendere il vero costo totale di proprietà di ogni organizzazione aggiuntiva prima di prendere una decisione architettonica difficile e costosa da annullare.

I costi API e di integrazione sono tra i fattori di costo più sottovalutati in un ecosistema Salesforce. La connessione di Salesforce a un sistema esterno può sembrare semplice, ma i requisiti di integrazione complessi accumulano rapidamente costi per le licenze middleware, le attività di sviluppo, la manutenzione in corso e il consumo API che fluisce da ogni scambio di dati. Le aziende con molti sistemi integrati, volumi di dati elevati o requisiti di sincronizzazione quasi in tempo reale sono particolarmente esposte. L'approccio architettonico è importante qui. Le integrazioni chiacchierose e a grana fine che effettuano frequenti chiamate API di piccole dimensioni sono più costose e più fragili rispetto a schemi in blocco o basati sugli eventi ben progettati che riducono al minimo i viaggi di andata e ritorno e la differenza si compone man mano che le applicazioni connesse si moltiplicano. Gestire gli standard di progettazione dell'integrazione, consolidare le piattaforme di integrazione ove possibile ed esaminare regolarmente se le integrazioni esistenti funzionano ancora con la stessa efficienza con cui sono state progettate in origine.

Un'architettura sostenibile richiede più delle ottimizzazioni iniziali della progettazione. Richiede una supervisione continua e una responsabilità strutturata. Il monitoraggio e la governance dei costi sono il framework che trasforma l'ottimizzazione da esercizio singolo a pratica operativa continua. Un tracciamento coerente e una chiara proprietà riducono il rischio di sovraccarichi di costi imprevisti in modo che ogni dollaro speso sia allineato al valore aziendale.

Creare visibilità sugli schemi di spesa tramite cruscotti digitali accessibili sia ai team tecnici che agli stakeholder aziendali, in modo che le conversazioni sugli investimenti si basino sui dati anziché sulle fatture. La visibilità dei costi avvia una conversazione basata sui dati sulle priorità di investimento e sulle opportunità di ottimizzazione e funziona meglio quando sono disponibili tre visualizzazioni distinte. I cruscotti digitali di utilizzo delle licenze rilevano gli utenti inattivi, gli utenti con licenze eccessive e le mancate corrispondenze dei tipi di licenza, ovvero le opportunità di ottimizzazione che si nascondono all'interno di un organico uniforme. I cruscotti digitali della capacità mostrano il consumo di memoria, API ed elaborazione con le tendenze di crescita, in modo che i team ottimizzino prima che un limite causi un guasto anziché dopo. I cruscotti digitali di investimento mostrano la spesa per unità operativa, i costi ambientali del team titolare, i costi aggiuntivi rispetto al loro utilizzo e la spesa prevista in base alla crescita corrente, che trasforma una conversazione sul budget in una conversazione sull'allocazione.

Questi cruscotti digitali possono provenire da una varietà di strumenti, tra cui Digital Wallet e rapporti personalizzati che eseguono query sui metadati. Lo strumento è meno importante della disciplina di rendere visibili i dati in cui vengono prese le decisioni. Condividere i cruscotti digitali con gli stakeholder aziendali e la dirigenza per creare la trasparenza di una discussione informata sugli investimenti anziché un dibattito reattivo sul budget. Un team finanziario che vede gli schemi di utilizzo può ottimizzare la spesa. Un team che visualizza solo una fattura totale può solo tagliarla.

Implementare la consapevolezza della spesa in tutta l'azienda, inclusi avvisi proattivi che segnalano l'ottimizzazione prima di superare i limiti:

I budget delle licenze impostano gli obiettivi di allocazione per reparto con avvisi man mano che si avvicinano alla capacità, in modo che il provisioning incontrollato non venga rilevato solo al rinnovo.
I budget di archiviazione monitorano il tasso di crescita con avvisi quando le tendenze prevedono il superamento dei limiti prima del ciclo di rinnovo successivo. Questi avvisi forniscono un avviso in anticipo in modo che l'archiviazione possa essere implementata prima che si verifichino eccedenze.
I budget API tengono traccia del consumo rispetto ai limiti con avvisi in corrispondenza di soglie di utilizzo di esempio come 70% e 85%, quindi l'ottimizzazione è proattiva anziché una risposta di emergenza dopo che i limiti causano errori.
I budget Sandbox controllano la proliferazione dell'ambiente attraverso i limiti di allocazione e i processi di approvazione.

I controlli del budget creano consapevolezza dei costi senza bloccare gli investimenti necessari. Le soglie di avviso forniscono avvisi tempestivi che consentono un'ottimizzazione ponderata anziché la crittografia reattiva.

L'allocazione dei costi crea responsabilità e decisioni informate nelle varie unità operative e le aziende la implementano attraverso uno dei due modelli che si differenziano per la quantità di responsabilità imposta. Mostra mostra i costi per unità operativa senza applicare un addebito finanziario effettivo. Crea trasparenza e promuove discussioni e priorità di ottimizzazione consapevoli dei costi senza contestare la fatturazione interna, il che si adatta a un'azienda che preferisce la gestione collaborativa dei costi alla responsabilità finanziaria. Il chargeback alloca i costi effettivi alle unità operative e crea una responsabilità finanziaria diretta per le decisioni di consumo. Incoraggia un comportamento di ottimizzazione più forte perché i costi influiscono direttamente sui budget dipartimentali, ma richiede una metodologia di allocazione accurata per evitare controversie su chi paga per cosa. In entrambi i casi, le regole di allocazione seguono la stessa logica: costi di licenza per reparto utenti, costi ambientali per la proprietà del team di sviluppo, costi di integrazione per il processo aziendale che consuma l'integrazione e costi di sviluppo per l'iniziativa che finanzia il lavoro. Quando queste regole sono assenti, ogni costo viene trasferito in un budget IT centrale e gli stakeholder aziendali considerano la piattaforma gratuita, ovvero la condizione che genera le richieste effettuate senza consapevolezza dei costi.

Adattare le procedure FinOps cloud all'economia della piattaforma Salesforce per creare una funzionalità di ottimizzazione continua anziché una pulitura periodica. Cinque studi ne hanno il peso.

La collaborazione interfunzionale tra finanza, architettura e stakeholder aziendali garantisce che le decisioni sui costi soppesino il valore aziendale insieme alla spesa. Porta la competenza finanziaria nelle discussioni sull'architettura e la comprensione tecnica nella pianificazione del budget.
Una cadenza di ottimizzazione continua evita la fluttuazione dei costi attraverso cicli di revisione regolari: un riesame mensile dell'anomalia che rileva i picchi di spesa, un controllo trimestrale dell'utilizzo che convalida le assegnazioni delle licenze e l'utilizzo della capacità e una valutazione annuale completa del TCO che riallinea la spesa alle priorità strategiche.
Le decisioni di investimento basate sui dati utilizzano i dati di utilizzo e i modelli TCO anziché ipotesi o abitudini storiche. Queste decisioni sostituiscono "abbiamo sempre fatto così" con l'analisi se la spesa corrente offre un valore ottimale.
L'automazione del monitoraggio dei costi riduce l'impegno manuale nel tracciamento dell'utilizzo, nell'identificazione delle opportunità di ottimizzazione e nella generazione di rapporti, in modo che lo studio si adatti alla complessità organizzativa senza una crescita lineare del personale.
La formazione sulla consapevolezza dei costi aiuta i team a capire in che modo le decisioni architettoniche influiscono sul costo totale di proprietà, perché un architetto che comprende i costi progetta compromessi migliori e uno sviluppatore che comprende l'economia della piattaforma scrive un'automazione più efficiente.

Integrare la consapevolezza dei costi nel processo di revisione dell'architettura in modo che le implicazioni degli investimenti siano visibili insieme alle considerazioni funzionali e tecniche anziché essere scoperte dopo la distribuzione. Includere una valutazione dell'impatto dei costi nei record decisione architettura che documentano le principali scelte di progettazione. Richiedere una proiezione del TCO per le soluzioni che superano una soglia di investimento definita. Valutare le implicazioni delle licenze durante la progettazione, determinando se un approccio richiede licenze premium o componenti aggiuntivi prima di essere confermato. Valutare il costo dell'integrazione prima di adottare uno schema che influisce sul consumo dell'API o sulle licenze middleware. Una commissione di revisione dell'architettura che include una prospettiva dei costi insieme a requisiti funzionali e non funzionali produce decisioni di investimento meglio allineate. Considerare il costo come un input a una decisione architettonica anziché come il suo unico fattore trainante, in modo che le aziende investano in modo appropriato in ciò che è importante evitando gli sprechi su ciò che non lo è.

La sostenibilità del cloud computing si concentra sulla minimizzazione dell'impatto ambientale dell'infrastruttura digitale attraverso un utilizzo efficiente delle risorse e si allinea naturalmente al valore per costo: la stessa efficienza che riduce il consumo delle risorse riduce anche i costi. Salesforce e gli architetti condividono la responsabilità dei risultati di sostenibilità. Salesforce gestisce l'infrastruttura del data center, incluse l'ottimizzazione dell'efficacia dell'utilizzo dell'energia, l'efficienza di raffreddamento e la gestione del ciclo di vita dell'hardware, oltre al pooling di risorse multi-tenant e ai miglioramenti dell'efficienza a livello di piattaforma. Si influenzano gli schemi di consumo delle risorse delle soluzioni all'interno di quell'ambiente multi-tenant.

La relazione tra una singola soluzione e le emissioni del data center è indiretta ed è importante essere precisi. Le ottimizzazioni di un singolo tenant non riducono direttamente le emissioni dei data center. Contribuiscono a un effetto aggregato: i guadagni di efficienza in tutti i tenant consentono a Salesforce di gestire l'infrastruttura a un utilizzo più elevato e di rinviare l'espansione della capacità. Le metriche di efficienza delle risorse, tra cui query SOQL, tempo CPU, consumo di heap e memoria, fungono quindi da indicatori proxy per la sostenibilità. L'eliminazione degli sprechi computazionali migliora le prestazioni e i costi e contribuisce al raggiungimento degli obiettivi di efficienza a livello di piattaforma. I principi di progettazione di questo pilastro, tra cui la creazione in blocco, le query selettive, il caching, l'elaborazione asincrona e il ciclo di vita dei dati disciplinato, creano soluzioni che consumano meno risorse. La sostenibilità non è un'iniziativa separata agganciata all'architettura. È l'aspetto dell'efficienza delle risorse quando la si misura in base all'impatto ambientale anziché solo in base ai costi finanziari.

Diversi studi di architettura portano la maggior parte del valore di sostenibilità, e ciascuno migliora anche le prestazioni o il costo, motivo per cui appartengono allo stesso pilastro.

L'automazione inattiva consuma le risorse dell'infrastruttura senza offrire alcun valore aziendale. Trigger che elaborano record non pertinenti, flussi di lavoro che vengono eseguiti inutilmente e processi pianificati eseguiti quando non esiste lavoro, tutti i processi di calcolo, stoccaggio ed energia dei rifiuti. Il rimedio è un controllo trimestrale dell'automazione con criteri espliciti per ciò che conta come inutilizzato: nessuna esecuzione negli ultimi 90 giorni, processi batch che elaborano costantemente zero record e automazione sostituita da implementazioni più recenti ma mai disattivata. Documentare ogni disattivazione in modo che possa essere ritirata se riemerge un requisito aziendale. Un'azienda che trasporta decine di Process Builder rimanenti da implementazioni precedenti, la maggior parte senza esecuzioni nell'ultimo anno, paga per valutarli tutti su ogni salvataggio di record pertinente.

La pianificazione di operazioni che richiedono molte risorse durante gli orari di attività ridotta distribuisce il carico tra le finestre temporali. In un ambiente multi-tenant, questa disciplina migliora la reattività della piattaforma durante l'orario di ufficio e, nel complesso, consente a Salesforce di gestire l'infrastruttura con un utilizzo medio più elevato. Pianificare l'archiviazione batch, l'arricchimento e la pulitura per le finestre a basso utilizzo, scaglionare i processi anziché avviarne 20 a mezzanotte e causare un picco di elaborazione e preferire schemi basati sugli eventi al polling pianificato in modo che non vengano spesi cicli per controllare il lavoro che non è disponibile.

Calcolando lo stesso valore si sprecano ripetutamente i cicli della CPU e la capacità dell'infrastruttura. Calcolare una volta, memorizzare il risultato nella cache e riutilizzarlo in transazioni e utenti. La cache piattaforma serve i dati di riferimento sottoposti a query ripetute, i valori di roll-up memorizzati nella cache evitano le query aggregate in tempo reale dove la precisione quasi in tempo reale è sufficiente, i campi formula vengono ricalcolati dinamicamente all'accesso ai record anziché memorizzare un valore e richiedere l'automazione per mantenerlo e Lightning Data Service elimina le richieste server ridondanti sul client. Ogni calcolo evitato è la capacità restituita alla piattaforma.

La memoria dati consuma le risorse dell'infrastruttura e peggiora le prestazioni delle query man mano che cresce. Le policy di conservazione che archiviano o eliminano i dati non più necessari per le operazioni attive consentono di mantenere piccole le tabelle attive e veloci le query. Archiviare i record datati in Big Object o memoria esterna in un processo pianificato, eliminare definitivamente quando è conforme anziché affidarsi all'eliminazione non definitiva che continua a consumare memoria e configurare la conservazione dell'itinerario di controllo campi per campo anziché applicare un limite massimo che memorizza molta più cronologia di quanto richiesto dalla conformità. Come per l'elaborazione pianificata, le singole decisioni di archiviazione non riducono direttamente l'utilizzo di energia del data center, ma la disciplina del ciclo di vita dei dati aggregati in tutti i tenant migliora l'efficienza della piattaforma e ritarda l'espansione dell'infrastruttura di storage.

Le integrazioni esterne consumano risorse sia in Salesforce che nei sistemi a cui si connettono. Acquisizione dati di modifica e altri schemi basati sugli eventi eliminano le chiamate di polling che controllano ripetutamente le modifiche e non ne trovano, riducendo il consumo dell'API, i limiti del governor e rimuovendo gli sprechi di calcolo. Gli schemi API compositi aggregano più operazioni in un'unica chiamata, l'API in blocco v2 elabora volumi elevati in modo molto più efficiente rispetto a migliaia di chiamate REST singole e la logica di tentativo con backoff esponenziale evita di martellare un sistema esterno in difficoltà. Una singola integrazione che esegue un polling ogni cinque minuti e non trova nulla da fare il più delle volte è puro spreco, mentre la stessa integrazione guidata da eventi di cambiamento elabora solo cambiamenti reali.

Le architetture degli agenti consumano risorse di calcolo tramite l'inferenza del modello di linguaggio di grandi dimensioni e si applica la stessa mentalità di efficienza. Ridurre al minimo la lunghezza del prompt, riepilogare la cronologia delle conversazioni anziché portare con sé trascrizioni integrali che crescono senza limiti, utilizzare il modello più piccolo sufficiente per un'operazione anziché utilizzare per impostazione predefinita il più adatto e memorizzare nella cache i dati di riferimento e le risposte deterministiche. Il recupero di 50 risultati di ricerca vettoriale quando ne vengono valutati solo 5 spende risorse di inferenza e recupero senza valore aggiunto, quindi configurare i limiti di recupero in modo che corrispondano all'utilizzo effettivo.

La sostenibilità, come il resto di questo pilastro, richiede un monitoraggio continuo anziché un passaggio occasionale, poiché i modelli di consumo delle risorse cambiano man mano che le soluzioni si evolvono, i volumi di dati crescono e le popolazioni di utenti si espandono. Il monitoraggio è importante solo quando attiva un'azione. Definire soglie fruibili per ogni metrica (conteggio delle query SOQL che supera un obiettivo per transazione, crescita dello spazio di archiviazione oltre una percentuale mensile o percentuale di hit nella cache inferiore a un obiettivo) e documentare le ottimizzazioni da eseguire per prime. Concentrare le attività sulle transazioni a volume elevato e sull'automazione eseguita di frequente, dove i miglioramenti dell'efficienza hanno il maggiore impatto aggregato. Process Builder ha terminato il supporto il 31 dicembre 2025 Eseguire la migrazione dei Process Builder rimanenti al flusso; non limitarsi a disattivarli.

Utilizzare questo elenco di controllo per valutare se una soluzione restituisce il valore massimo per costo. Riunisce le pratiche di efficienza delle risorse e disciplina dei costi di questo pilastro in un unico riesame, poiché i due elementi costituiscono un'unica decisione.

Modello di valore e costo

Collegare ogni investimento Salesforce significativo a un risultato aziendale misurabile.
Modellare il costo totale di proprietà in categorie dirette, indirette, singole e in corso prima di impegnarsi in un approccio.
Confrontare il TCO per la base di riferimento e per le alternative architettoniche ottimizzate su un orizzonte di 3–5 anni.
Applicare una valutazione build-vs-buy coerente che soppesi la differenziazione strategica, il time-to-value e il costo di uscita anziché basarsi su giudizi specifici.

Efficienza delle risorse

Progettare le transazioni in modo da operare comodamente entro i limiti del governor in presenza di picchi di carico e volumi massimi di dati.
Rendere selettive le query rispetto ai campi indicizzati ed eseguire la convalida con lo strumento Query Plan (Piano di esecuzione query) prima di distribuirle su oggetti di grandi dimensioni.
Bloccare tutte le operazioni sui dati e scegliere deliberatamente l'elaborazione asincrona dove i limiti sincroni lo richiedono.
Inserire nella cache i dati di riferimento tramite Cache piattaforma e Lightning Data Service per evitare query e ricalcoli ripetuti.
Evitare la distorsione dei dati distribuendo il carico e monitorando gli oggetti a volume elevato.
Centralizzare la logica dei trigger, dei servizi e dei selettori in modo che la logica aziendale rimanga testabile ed economica da modificare.
Definire un ciclo di vita completo dei dati dalla creazione all'archiviazione e monitorare il consumo di memoria a livello di oggetto.

Licenze e consumo

Abbinare ogni utente al tipo di licenza richiesto dal lavoro e controllare regolarmente i ruoli, l'attività di accesso e l'utilizzo delle funzioni.
Stabilire la visibilità sui tassi di combustione dei crediti a consumo e progettare automazioni e agenti per invocare i servizi misurati in modo efficiente.
Gestire il provisioning Sandbox con una chiara policy di proprietà, cadenza di aggiornamento e disattivazione.
Prima di aggiungere un'organizzazione, comprendere il moltiplicatore di costi multi-organizzazione completo e privilegiare l'integrazione in blocco o basata sugli eventi rispetto agli schemi chiacchieroni.

Monitoraggio e governance

Fornire cruscotti digitali di costi e capacità accessibili sia ai team tecnici che agli stakeholder aziendali.
Impostare avvisi budget per licenze, memoria, consumo API e Sandbox in modo che l'ottimizzazione sia proattiva anziché reattiva.
Stabilire uno showback o un chargeback in modo che l'allocazione dei costi crei responsabilità tra le unità operative.
Adottare una cadenza FinOps: revisione mensile dell'anomalia, controllo trimestrale dell'utilizzo e valutazione annuale completa del TCO.
Integrare la valutazione dell'impatto dei costi nelle revisioni dell'architettura e nei record decisione architettura.

Ottimizzazione e sostenibilità continue

Considerare l'ottimizzazione come una pratica continua e verificare che gli investimenti di ottimizzazione precedenti abbiano prodotto il ritorno previsto.
Eliminare l'automazione inutilizzata e i calcoli ridondanti tramite controlli regolari.
Monitorare il consumo delle risorse nel tempo e definire soglie fruibili che attivano l'ottimizzazione quando una metrica le attraversa.

Condividere i propri commenti sul framework ben progettato.