Framework ben progettato

Il framework Salesforce Well-Architected offre agli architetti una base di principi condivisa per prendere le decisioni che contribuiscono al successo di una soluzione nel tempo. È organizzato attorno a cinque pilastri (Trust, Affidabilità, Eccellenza operativa, Ottimizzazione delle risorse e dei costi ed Equità), ognuno dei quali cattura una dimensione di qualità importante in ogni fase della vita di una soluzione, dalla progettazione iniziale fino all'operatività e alla crescita a lungo termine.

Il framework affronta le realtà che gli architetti affrontano oggi: persone, agenti e piattaforme che lavorano insieme all'interno di sistemi aziendali governati. Una soluzione sicura ma fragile sotto carico, o efficiente ma opaca nelle sue decisioni, non è ben progettata. Questi cinque pilastri lavorano insieme per garantire che la qualità sia trattata nel suo insieme anziché come elenco di controllo di imprese indipendenti.

Gli architetti utilizzano il framework come lente coerente durante le revisioni della progettazione, le conversazioni di compromesso e la governance in corso. Non prescrive una sola risposta corretta. Fornisce le domande giuste da porre, gli schemi giusti da considerare e un vocabolario comune da utilizzare nei team.

Salesforce Well-Architected Framework è una guida alla qualità dell'architettura per le soluzioni create in Salesforce Platform. Codifica i principi, gli schemi e i compromessi che distinguono le soluzioni scalabili e adattabili da quelle che accumulano debito tecnico o falliscono sotto pressione.

Il quadro è organizzato attorno a cinque pilastri. Ogni pilastro definisce una dimensione di qualità, articola i principi di progettazione di base, identifica schemi comuni e fornisce indicazioni esplicite sia per le funzionalità della piattaforma tradizionale che per i carichi di lavoro di intelligenza artificiale degli agenti. Insieme, i pilastri coprono in modo completo cosa significa creare qualcosa di buono in Salesforce.

Questo framework non è un manuale del prodotto o una guida all'implementazione. Si tratta di un framework decisionale architettonico, un modo di pensare alla qualità che si applica indipendentemente dai cloud, dalle funzioni o dagli strumenti utilizzati da una soluzione.

I framework di settore dei provider di cloud iperscala offrono preziose indicazioni generali, ma sono creati principalmente per le infrastrutture cloud e le problematiche operative, ad esempio macchine virtuali, networking, storage ed elaborazione. Gli architetti Salesforce devono affrontare diversi vincoli e funzionalità: piattaforma multi-tenant con limiti governor, decenni di logica aziendale in Customer 360, soluzioni di integrazione sofisticate, automazione dichiarativa, configurazione basata sui metadati e modelli di condivisione gestiti. Queste determinano ogni decisione architettonica in modi che la guida cloud generica non può gestire.

Il passaggio ad agenti autonomi introduce ulteriori considerazioni. Gli agenti che ragionano e agiscono introducono schemi di non determinismo, ragionamento probabilistico e supervisione Human-in-the-Loop che i framework precedenti non affrontavano in origine, anche se i framework generici hanno iniziato a estendersi in questo spazio tramite lenti AI dedicate. Il framework Salesforce Well-Architected si rivolge sia all'architettura tradizionale della piattaforma che ai sistemi agenti tramite una lente unificata.

Questo framework è utile a chiunque sia responsabile della qualità dell'architettura nella piattaforma Salesforce:

• Salesforce Architects progetta nuove soluzioni o amplia quelle esistenti
• Amministratori Salesforce che configurano e proteggono le organizzazioni in cui vengono eseguite queste soluzioni
• Lead di sviluppo che stabiliscono standard e schemi per i loro team
• Consulenti e partner che consigliano i clienti sulle procedure consigliate della piattaforma
• AI e Agentic Specialists creano e governano sistemi di agenti autonomi

Non è richiesta alcuna esperienza precedente nell'intelligenza artificiale agente. Il framework è accessibile a tutti gli architetti fornendo profondità a coloro che lavorano alla frontiera dei sistemi autonomi.

Non esiste un unico ordine di lettura corretto. Scegliere in base al proprio ruolo e alle esigenze immediate:

• Se non si conosce il framework: Leggere questo documento di panoramica dall'inizio alla fine ed esplorare il pilastro più pertinente al progetto corrente.
• Se si sta progettando una nuova soluzione: Iniziare con Trust e Affidabilità (fondazioni non negoziabili) e quindi affrontare l'Eccellenza operativa (come la si gestirà), l'Ottimizzazione delle risorse e dei costi (come la si sosterrà) e l'Equità (come ci si assicurerà che serva equamente tutti gli utenti).
• Se si stanno creando soluzioni agentiche: Leggere prima la Panoramica Enterprise per una guida completa sull'architettura degli agenti. Quindi, leggere i documenti del pilastro centrale (linkati sopra) per gli schemi di base (modello di responsabilità condivisa, limiti del governor, strumenti di monitoraggio, modellazione del TCO, standard di accessibilità) su cui si basano le soluzioni agentiche. Infine, fare riferimento alle varianti del pilastro Agentic Enterprise (collegate da ogni pilastro) per le sovrapposizioni specifiche degli agenti in ogni dimensione della qualità.
• Se si esegue una revisione della progettazione: Utilizzare i documenti del pilastro come elenco di controllo di revisione strutturato. Una soluzione ben progettata ha risposte chiare alle domande chiave in ogni pilastro pertinente.

Le decisioni architettoniche più importanti includono compromessi tra i pilastri. Il framework consente di rendere espliciti questi elementi:

• Trust e ottimizzazione delle risorse e dei costi: La crittografia e la registrazione di controllo consumano risorse. Il framework consente di identificare i casi in cui il requisito Trust non è negoziabile rispetto ai casi in cui si dispone di flessibilità.
• Affidabilità e ottimizzazione delle risorse e dei costi: Una maggiore disponibilità costa di più. Le definizioni SLO consentono di abbinare l'investimento ai requisiti aziendali effettivi anziché utilizzare per impostazione predefinita la massima ridondanza.
• Eccellenza operativa e velocità: L'implementazione dell'osservabilità e dei test completi richiede tempo. Il framework consente di identificare la minima osservabilità praticabile per il proprio profilo di rischio.
• Equità e autonomia: Una maggiore autonomia degli agenti consente l'efficienza ma crea un rischio di equità. Gli schemi Human in the Loop consentono di trovare il giusto equilibrio per ogni tipo di decisione.

Non esiste una risposta universale a questi compromessi. Il framework consente di porre le domande giuste e di trovare i compromessi in modo consapevole anziché scoprirli in produzione.

Il framework Well-Architected è progettato tenendo presenti i seguenti principi:

• Specifico della piattaforma ma non tecnologico: La guida affronta i vincoli specifici di Salesforce (limiti del governor, architettura multi-tenant, configurazione basata sui metadati) senza prescrivere prodotti o funzioni specifiche. Gli architetti scelgono le funzionalità giuste per il loro contesto.
• Opinionated senza essere prescrittivo: Il quadro assume posizioni chiare su ciò che costituisce qualità, ma non impone un unico percorso di attuazione. Fornisce principi, schemi e domande, non requisiti.
• Lungimirante nel rispetto del presente: Il framework affronta gli schemi emergenti (intelligenza artificiale, sistemi autonomi) pur rimanendo pertinente alle soluzioni piattaforma tradizionali. Entrambi i casi d'uso traggono vantaggio dagli stessi principi fondamentali.
• Vivo, non statico: Il framework si evolve man mano che cambiano la piattaforma, le procedure di settore e le esigenze dei clienti. Il Registro modifiche tiene traccia degli aggiornamenti in modo che gli architetti possano rimanere aggiornati con le nuove indicazioni.
• Funzionabile in ogni fase: Sia che si progetti una nuova soluzione, si esegua una revisione o si migliori un'implementazione esistente, il framework fornisce indicazioni pertinenti. Non è solo un elenco di controllo di certificazione, è uno strumento di lavoro.

Questi principi assicurano che il framework rimanga utile in contesti architettonici diversi, mantenendo al contempo indicazioni chiare e coerenti su ciò che la qualità dell'architettura significa per le soluzioni Salesforce.

Ogni pilastro affronta una dimensione fondamentale della qualità architettonica. Insieme, i pilastri offrono una copertura completa: nessun pilastro è sufficiente da solo e i compromessi tra i pilastri sono la sede in cui vivono le decisioni architettoniche più importanti.

I cinque pilastri che seguono forniscono indicazioni architettoniche di base per tutte le soluzioni Salesforce, sia per le applicazioni piattaforma tradizionali, le integrazioni e i sistemi agenti. L'Agentic Enterprise Overview e le sue varianti del pilastro companion offrono la sovrapposizione specifica dell'agente: come gli agenti utilizzano queste funzionalità, cosa cambia quando i sistemi agiscono in autonomia e gli schemi architetturali richiesti per l'intelligenza artificiale governata.

Usare entrambi insieme:

• Iniziare con le linee guida del pilastro per gli schemi architettonici principali (ad esempio, il modello di responsabilità condivisa, i limiti del governor, gli strumenti di monitoraggio, la modellazione del TCO, gli standard di accessibilità).
• Quindi, fare riferimento al pilastro Agentic Enterprise corrispondente per le considerazioni specifiche degli agenti (ad esempio, autorizzazioni degli agenti e catene di controllo, gestione degli errori di orchestrazione, Ciclo di vita dello sviluppo degli agenti, ottimizzazione dei token, Unità di lavoro agenti, spiegabilità e contestabilità).

I pilastri non sono "tradizionali" e "agentici", ma sono un'architettura di base su cui si basano le soluzioni agentiche. I sistemi agentici devono soddisfare gli stessi requisiti di Trust, affidabilità, eccellenza operativa, ottimizzazione delle risorse e dei costi e correttezza di qualsiasi altra soluzione aziendale, con ulteriori considerazioni per il funzionamento autonomo.

Questa tabella fornisce un rapido riferimento. Seguono indicazioni dettagliate per ogni pilastro.

Proteggere la soluzione, i suoi dati e i suoi utenti attraverso una sicurezza moderna, l'accesso con privilegi minimi, controlli della privacy e una governance chiara. Trust on Salesforce opera tramite il modello di responsabilità: condivisa Salesforce protegge l'infrastruttura e la piattaforma, quindi si creano soluzioni sicure su queste basi. La responsabilità si estende a:

• Gestione delle identità e degli accessi (ruoli, profili, insiemi di autorizzazioni, MFA, SSO, OAuth)
• Governance dei dati (Shield Platform Encryption, protezione a livello di oggetto/campo/record)
• Sicurezza dell'integrazione (autenticazione API, credenziali denominate)
• Procedure di sviluppo sicure (OWASP Top 10 adattato per Salesforce, analisi statica, gate di sicurezza CI/CD)

Per le soluzioni agentiche: Quando gli agenti agiscono in autonomia, i requisiti Trust si estendono a stabilire ciò che gli agenti sono autorizzati a fare, a controllare ciò che hanno fatto e a proteggere i confini tra agenti e piattaforme (Agent Fabric, Einstein Trust Layer). Vedere Agentic Enterprise Trust.

Per ulteriori informazioni, vedere Trust pillar e Agentic Enterprise Trust.

Progettare per garantire una disponibilità continua, un ripristino rapido dopo le interruzioni e la capacità di scalare in caso di domanda imprevista. L'affidabilità richiede la comprensione delle garanzie della piattaforma (infrastruttura multiregione, SLA piattaforma) mentre si progettano soluzioni che rimangano affidabili entro tali vincoli. Il pilastro copre:

• Limiti del governor con massimale operativo del 70%
• Schemi di elaborazione asincroni (Batch Apex, Apex inseribile in area di attesa, Eventi piattaforma)
• Interruttori automatici per integrazioni esterne
• Pianificazione della capacità
• Test di carico
• Schemi multi-organizzazione
• Ripristino di emergenza
• Modellazione della salute

Per le soluzioni agentiche: I sistemi basati sugli agenti introducono un comportamento probabilistico che richiede nuovi schemi per gli errori di orchestrazione, interruttori automatici per gli errori degli agenti a catena e grafici deterministici degli agenti in cui i risultati aziendali richiedono prevedibilità. Vedere Affidabilità aziendale.

Per ulteriori informazioni, vedere Pilastro Affidabilità e Affidabilità aziendale Agentic.

Creare una soluzione osservabile completa e gestirla attraverso procedure e automazioni ben definite. L'Eccellenza operativa si estende a:

• Osservabilità (Monitoraggio evento, Proactive Monitoring, Scale Center)
• Procedure DevOps (sviluppo basato sulla fonte, opportunità in corso di realizzazione per CD/IC, strategia di test)
• Automazione (prima dichiarativa con Flow Builder, schemi di programmazione con Apex)
• Gestione degli incidenti (livelli di gravità, rotazione su chiamata, automa irreprensibile)
• Miglioramento continuo (metriche DORA, revisioni operative)

Per le soluzioni agentiche: L'osservabilità diventa più difficile quando il comportamento del sistema è probabilistico. L'ADLC (Agent Development Lifecycle) offre una struttura articolata in cinque fasi: ideazione e progettazione, sviluppo, test e convalida (incluse le valutazioni del Testing Center degli agenti per la precisione, la coerenza e l'osservanza delle istruzioni), distribuzione e rilascio, monitoraggio e messa a punto (incluso il tracciamento delle sessioni Agentforce per la visibilità delle interazioni end-to-end). Vedere Eccellenza operativa Enterprise.

Per ulteriori informazioni, vedere il pilastro Eccellenza operativa e Eccellenza operativa aziendale.

Restituire il valore aziendale massimo per ogni dollaro e ogni unità di risorsa della piattaforma, attraverso un uso efficiente di ciò che si ha e un investimento deliberato in ciò che si acquista. Dal punto di vista delle risorse, ciò significa comprendere i limiti del governor (query SOQL, istruzioni DML, dimensioni heap, tempo CPU) e progettare al loro interno tramite l'ottimizzazione SOQL, l'elaborazione asincrona e la prevenzione delle distorsioni dei dati. Dal punto di vista dei costi, significa modellazione completa del TCO sia per i costi diretti (implementazione, operativi, manutenzione) che indiretti (debito tecnico, spese generali di governance) che spesso superano i costi diretti delle licenze. Il pilastro copre:

• Schemi di organizzazione del codice (handler trigger, livelli di servizio, selettori)
• Pacchetti e modularità (pacchetti gestiti 2GP vs. pacchetti sbloccati, che sono entrambi tipi di imballaggio di seconda generazione, composizione LWC)
• Gestione del ciclo di vita dei dati (strategie di archiviazione, ottimizzazione dei flussi)
• Strumenti di monitoraggio delle prestazioni (Scale Center, Query Plan Tool, ApexGuru, Salesforce Code Analyzer)
• Analisi build vs buy (valutazione AgentExchange)
• Ottimizzazione di licenze e Sandbox
• Monitoraggio e governance dei costi (cruscotti digitali, controlli del budget, modelli di showback e chargeback)

Per le soluzioni agentiche: I flussi di lavoro degli agenti aumentano il consumo delle risorse nelle fasi di ragionamento, nelle chiamate agli strumenti e nei recuperi di dati, quindi l'utilizzo dei token, la latenza di inferenza e gli schemi di memoria richiedono un'ottimizzazione. I sistemi agentici introducono anche costi basati sul consumo (crediti Flex, token di inferenza) più difficili da prevedere rispetto alle licenze per utente. Le unità di lavoro agenti (ULA) misurano gli agenti di lavoro effettivamente completati (operazioni discrete eseguite) anziché il consumo di token non elaborati. Vedere Ottimizzazione delle risorse aziendali.

Per ulteriori informazioni, vedere il pilastro Ottimizzazione delle risorse e dei costi e Ottimizzazione delle risorse.

Assicurarsi che la soluzione sia accessibile, non discriminatoria, inclusiva e trasparente, con una supervisione umana appropriata delle decisioni automatiche. L'equità è costruita sulle fondamenta della piattaforma. Salesforce Lightning Design System (SLDS) offre l'accessibilità incorporata per i componenti standard, mentre i componenti personalizzati richiedono un'implementazione esplicita delle WCAG 2.1 AA (con le WCAG 2.2 AA, l'attuale raccomandazione W3C del dicembre 2024, consigliata per i nuovi lavori). Il pilastro copre:

• Test di accessibilità (axe-core, scanner sfdx)
• Modelli di non discriminazione (OWD, regole di condivisione, FLS con Monitoraggio evento Shield)
• Architettura della privacy (gestione del consenso di Data 360, Itinerario di controllo campi)
• governance etica AI (commissioni di revisione, porte di equità, conformità normativa).

Per le soluzioni agentiche: Quando gli agenti prendono decisioni autonome che riguardano le persone, i rischi di equità aumentano. La spiegabilità (capire perché un agente ha agito), la contestabilità (decisioni impegnative) e Human-in-the-Loop (supervisione proporzionale) diventano fondamentali. Vedere Agentic Enterprise Fairness.

Per ulteriori informazioni, vedere Pilastro Equità e Equità aziendale.

Nessun pilastro esiste isolato. Le decisioni architettoniche di un pilastro influiscono inevitabilmente sugli altri:

• Controlli Trust più efficaci (crittografia, registrazione di controllo) consumano più risorse e aumentano i costi (ottimizzazione delle risorse e dei costi) e aumentano la latenza che influisce sull'affidabilità
• Maggiore affidabilità (ridondanza, multiregione) aumenta i costi (ottimizzazione delle risorse e dei costi) e la complessità operativa (eccellenza operativa)
• Un'applicazione più completa dell'equità (supervisione umana, monitoraggio della distorsione) rallenta la produttività degli agenti (ottimizzazione delle risorse e dei costi)
• Una maggiore maturità dell'eccellenza operativa (strumentazione completa) consente una migliore applicazione del Trust e un rilevamento precoce dei problemi di equità

Queste interazioni fanno sì che la qualità architettonica sia sempre in equilibrio. Il framework aiuta gli architetti a capire che cosa stanno scambiando e a fare quelle operazioni intenzionalmente. L'obiettivo non è massimizzare ogni pilastro contemporaneamente, ma ottenere il profilo di qualità giusto per i requisiti, la tolleranza al rischio e il contesto aziendale di una determinata soluzione.

Condividere i propri commenti sul framework ben progettato.