Leggi qui le nostre pianificazioni degli aggiornamenti.

Le soluzioni intenzionali offrono valore aziendale immediatamente e nel tempo. Le architetture intenzionali sono pianificate e fornite in modo strategico, possono essere mantenute in modo efficace e sono facili da leggere e comprendere per gli esseri umani.

Le funzioni e le correzioni sono definite in base alla priorità e fornite in modo trasparente sia per le aziende che per gli stakeholder tecnologici. Le scelte ingegneristiche creano implementazioni facili da utilizzare per i team di consegna e manutenzione, senza funzioni aggiuntive o complicazioni. Le architetture intenzionali sono più facili da possedere, gestire ed evolvere con l'azienda perché seguono schemi di implementazione chiari e coerenti. I generatori possono interpretare e implementare progetti per nuove funzioni e i team di manutenzione possono comprendere la documentazione di ciò che è stato implementato.

È possibile creare sistemi più intenzionali concentrandosi su tre aree chiave: strategia, manutenibilità e leggibilità.

Strategia in architettura significa che i sistemi vengono pianificati e consegnati in modo ponderato. Ciò significa che i team di consegna e manutenzione hanno una visione chiara del lavoro da svolgere oggi e in futuro e tutti sono allineati sul "perché" del lavoro da svolgere. Ciò significa che le richieste urgenti possono essere gestite in modo efficace ed efficiente e che gli stakeholder possono comprendere chiaramente l'impatto e i compromessi delle richieste.

È possibile definire una strategia più chiara nell'architettura concentrandosi sulla definizione delle priorità, sulla mappatura stradale e sulla governance.

Assegnare priorità significa pianificare l'ordine e l'ambito del lavoro che verrà consegnato. L'assegnazione delle priorità implica la comprensione del reale impatto dei risultati sul business, la valutazione di tali impatti rispetto ad altre richieste di lavoro e la roadmap complessiva per il prodotto o il programma.

Un modo per valutare l'impatto di una determinata voce su cui lavorare è esaminare il costo o il vantaggio effettivo per l'azienda. Dopo aver identificato i KPI per l'automazione, è possibile utilizzare un foglio di lavoro per valutare il costo o il vantaggio complessivo dell'implementazione. Questi calcoli possono aiutare a ottenere l'allineamento e il consenso degli stakeholder sulle automazioni da creare e in quale ordine. Possono anche aiutare a identificare le automazioni da posticipare o evitare. Per ulteriori informazioni sull'identificazione del lavoro efficace, vedere Progettazione dei processi.

Stabilire un framework di definizione delle priorità per la consegna aiuterà anche l'utente e i suoi team di manutenzione a gestire le aspettative degli utenti e a rimanere in linea con la roadmap.

Alcune considerazioni che è possibile utilizzare per definire le priorità sono:

• Impatto aziendale (costo/beneficio) del deliverable
• Quantità di nuovo lavoro richiesto per il deliverable
• Quantità di lavoro necessaria per mantenere il deliverable

L'elenco degli schemi e antischemi riportato di seguito mostra l'aspetto della corretta (e scarsa) definizione delle priorità quando si tratta di lavorare in Salesforce. È possibile utilizzarli per convalidare i piani di implementazione o identificare i punti in cui è necessario identificare meglio le priorità prima di procedere alla creazione.

Per ulteriori informazioni sugli strumenti disponibili in Salesforce per informazioni sull'assegnazione delle priorità, vedere Strumenti pertinenti all'intenzionale.

Una roadmap è una visualizzazione prioritaria, convalidata e ben definita delle operazioni da eseguire. Tabelle di marcia efficaci offrono un quadro chiaro dell'impatto sul business e dell'impatto tecnologico del lavoro futuro. Coinvolgere gli stakeholder aziendali e tecnici è una parte fondamentale della roadmapping. Le tabelle di marcia consentono di ricevere commenti e contributi sull'approccio e sui risultati prima dell'inizio del lavoro. In definitiva, le roadmap allineano ogni stakeholder sul "perché" del lavoro futuro.

Se il team utilizza un backlog, è importante capire che la roadmap non è un riepilogo o un elenco degli elementi in backlog. La relazione è opposta: Le voci sono destinate a entrare nell'arretrato solo se possono essere collegate in modo chiaro e credibile a un risultato nella roadmap. Roadmap di alta qualità, create con il coinvolgimento degli stakeholder, offrono ai team di consegna e manutenzione una visione chiara di ciò su cui concentrarsi e di come assegnare la priorità alle richieste, semplificando la risoluzione delle richieste in conflitto e la gestione delle aspettative degli stakeholder.

Una mappatura stradale scarsa o inesistente porta a:

• Mancanza di chiarezza su quando saranno disponibili nuove funzioni e funzionalità
• Priorità in conflitto tra gli stakeholder
• Una disconnessione tra le soluzioni fornite e la visione organizzativa complessiva
• Difficoltà a capire quali lavori sono in corso
• Carichi di lavoro irregolari tra i team
• Mancanza di visibilità sulle relazioni e le dipendenze tra le voci su cui lavorare
• Implementazioni in stallo a causa di dipendenze mal gestite

Spesso gli stakeholder necessitano di informazioni in linea con i loro ruoli per prendere decisioni. La creazione di roadmap efficaci richiede una chiara comprensione del pubblico e del tipo di informazioni di cui ha bisogno. Le roadmap sono classificate in due stili per supportare i pubblici aziendali e tecnici. Ogni stile contiene due livelli di dettaglio per supportare diversi tipi di informazioni.

Le roadmap aziendali aiutano gli stakeholder a pianificare il cambiamento organizzativo, a sfruttare le opportunità di crescita e a rimanere allineati agli obiettivi aziendali. Le roadmap aziendali offrono anche un modo per garantire che la spesa IT sia allineata alla visione aziendale generale.

• Creare una roadmap delle funzionalità aziendali per mostrare agli stakeholder dirigenti le funzionalità che verranno abilitate. Questo tipo di roadmap contiene dettagli generali sulle funzionalità stesse e sul modo in cui si allineano agli obiettivi aziendali, ad esempio l'aumento dell'efficienza operativa o il lancio di una nuova linea di prodotti.
• Creare una roadmap delle funzioni aziendali per visualizzare in dettaglio una funzionalità specifica e le relative caratteristiche e funzionalità quando è necessario aiutare gli stakeholder aziendali nella pianificazione delle risorse, nel budget e nella gestione del cambiamento.

Le roadmap tecnologiche aiutano gli stakeholder tecnici nella pianificazione del budget e dell'allocazione delle risorse. Aiutano anche i team di implementazione a capire dove si inseriscono i loro progetti come parte di un quadro generale più ampio e a identificare eventuali dipendenze tra team.

• Creare una roadmap del sistema tecnologico per mostrare i sistemi specifici che verranno implementati, insieme alle eventuali dipendenze a livello di sistema. Questo tipo di roadmap mostra le informazioni generali sul sistema e l'allineamento tra i sistemi e le funzionalità aziendali.
• Creare una roadmap dei componenti tecnologici per visualizzare i dettagli dei componenti specifici di un sistema che verranno distribuiti per facilitare la pianificazione delle risorse e i requisiti di abilitazione. Questo tipo di roadmap mostra le informazioni a livello di componente e i requisiti di implementazione (ad esempio, sviluppo dichiarativo, pro-code e così via).

Assicurarsi che le roadmap contengano tempistiche realistiche. Un errore comune è includere solo la quantità di tempo necessaria per implementare un sistema senza considerare anche la quantità di tempo necessaria per completare le attività correlate. Ciò può causare un'allocazione eccessiva dei membri del team di implementazione e ritardi più lunghi del previsto. Quando si crea una roadmap, tenere presente il tempo necessario per completare quanto segue:

• Documentazione di tutte le funzionalità nuove e aggiornate
• Manutenzione delle funzionalità esistenti necessarie per supportare le nuove funzionalità
• Aggiornamenti ai sistemi correlati necessari per supportare le integrazioni
• Supporto elevato da parte dei team di progetto subito dopo l'implementazione
• Test, formazione e gestione del cambiamento

Roadmap aziendali e tecnologiche ben allineate comunicano una visione olistica di quando le funzionalità saranno rese disponibili e di quale tecnologia è alla loro base. L'elenco degli schemi e antischemi riportato di seguito mostra le roadmap corrette (e scadenti) per un'organizzazione Salesforce. È possibile utilizzarli per convalidare o migliorare la strategia di mappatura stradale.

Per ulteriori informazioni sugli strumenti Salesforce che possono essere utili per la mappatura stradale, vedere Strumenti pertinenti all'intenzionale.

La governance è la struttura utilizzata per gestire le priorità, il processo decisionale e la gestione del cambiamento con gli stakeholder. La governance chiarisce come vengono prese e comunicate le decisioni. Fornisce modalità coerenti per i feedback e le richieste di partecipazione al processo decisionale e consente a tutte le parti interessate di comprendere lo stato del lavoro di manutenzione e sviluppo. La governance consente di rilasciare i processi di gestione in modo chiaro e coerente e aiuta tutti i membri del team a comprendere i propri ruoli e responsabilità.

Senza una governance adeguata, i team sperimenteranno una varietà di problemi, tra cui:

• Le richieste di sovrapposizione di caratteristiche e funzionalità arrivano ad hoc
• I team di implementazione danno priorità agli sforzi o alle richieste più "semplici" da parte di stakeholder più influenti, senza tenere in debita considerazione il valore aziendale, i compromessi o gli obiettivi organizzativi complessivi
• Mancanza di processi di approvazione e revisione coerenti
• Cadenza e qualità dei rilasci incoerenti
• Alte percentuali di difetti, sovrascritture, conflitti e lavoro ridondante negli sforzi di sviluppo

Forse il segnale più chiaro che un sistema non ha una governance efficace sono i rilasci lenti e complessi. È importante riconoscere che le dimensioni di un sistema di governance non sono una misura della sua efficacia. Infatti, sistemi elaborati per la governance (come quelli presenti in molte grandi aziende) possono limitare la velocità e la frequenza dei rilasci.

Una buona governance consiste nel rendere difficile per le personalizzazioni non corrette superare le prime fasi di sviluppo e ottenere personalizzazioni valide in produzione in modo prevedibile e coerente.

Troppo spesso gli sforzi di governance sono reazionari. Vengono avviati o raddoppiati quando un problema, ad esempio un debito tecnico eccessivo, inizia a diventare un problema aziendale. In molti casi, la sfortunata risposta è che l'azienda "blocca" gli sforzi di sviluppo e i rilasci, invece di creare standard di progettazione efficaci e di automazione degli edifici per applicare tali standard nelle catene di strumenti per sviluppatori e nei sistemi di controllo sorgente.

Quando si crea il framework per il sistema di governance Salesforce, includere i seguenti elementi e considerare le seguenti domande chiave a cui rispondere:

• Richieste di lavoro. Come possono gli utenti richiedere funzionalità o caratteristiche? Come vengono segnalati i bug?
• Priorità e pianificazione del lavoro. Chi decide quali richieste di lavoro contano? In che modo il lavoro viene circoscritto, assegnato alle priorità e accettato o approvato?
• Ambienti e pianificazione dei rilasci. Qual è la pipeline ambientale per sviluppo, test e rilascio? Chi fa cosa per eseguire il provisioning, aggiornare e concedere l'accesso? Chi gestisce le distribuzioni e la convalida? Come e quando vengono rilasciate le modifiche? Come si gestiscono le distribuzioni o gli ambienti durante un ciclo di rilascio di Salesforce? (Per ulteriori informazioni, vedere Gestione del ciclo di vita delle applicazioni).
• Titolarità del servizio e supporto alla produzione. Chi sostiene cosa? Chi gestisce i problemi di produzione "hot-fix"? Come vengono testati e rilasciati questi elementi? Chi è responsabile degli standard di sicurezza complessivi dell'organizzazione?

L'elenco degli schemi e antischemi riportato sotto mostra l'aspetto di una governance corretta (e scarsa) per un'organizzazione Salesforce. È possibile utilizzarli per convalidare o migliorare la strategia di governance.

Per ulteriori informazioni sugli strumenti Salesforce disponibili per la governance, vedere Strumenti pertinenti all'intenzionale.

La tabella seguente mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui destinare la riparazione.

✨ Scopri altri schemi per la strategia in Pattern & Anti-Pattern Explorer.

La manutenibilità significa che un sistema può essere mantenuto in uno stato sano, con l'introduzione di nuove funzioni e l'indebitamento tecnico che esce dal sistema su base regolare e prevedibile. I sistemi di manutenzione consentono ai team di offrire valore all'azienda con velocità e qualità prevedibili. La manutenibilità di un sistema dipende da diversi fattori, tra cui la leggibilità, l'accoppiamento e l'accuratezza della strategia di test.

Soprattutto, la manutenibilità di un sistema dipende dalla semplicità del suo design. Questa sezione descrive come creare soluzioni più semplici e aumentare la manutenibilità.

È possibile creare soluzioni più facili da gestire concentrandosi su due elementi chiave: l'utilizzo delle funzionalità standard rispetto a quelle personalizzate e la gestione del debito tecnico.

Salesforce offre una gamma di soluzioni predefinite (Sales Cloud, Service Cloud e molte soluzioni Salesforce per il settore) e la flessibilità di creare soluzioni personalizzate. I servizi di base che supportano le soluzioni cloud di Salesforce sono disponibili anche per tutte le soluzioni personalizzate create in Salesforce Customer 360 Platform. Utilizzare i servizi e le soluzioni predefinite di Salesforce come base affidabile per il maggior numero possibile di soluzioni.

L'utilizzo dei servizi piattaforma predefiniti presenta due vantaggi distinti. Innanzitutto, le app beneficiano naturalmente delle ultime innovazioni di Salesforce con ogni rilascio. In secondo luogo, i team di sviluppo possono concentrarsi sull'espansione e l'approfondimento delle funzionalità aziendali offerte dalle soluzioni Salesforce anziché gestire operazioni di sollevamento gravose di base dell'architettura.

Scegliere correttamente quando utilizzare le funzionalità standard e quando creare funzionalità personalizzate non è difficile da un punto di vista architettonico. Le chiavi sono:

• Personalizzare la piattaforma significa modificare ed estendere, non copiare. Durante la progettazione o la valutazione dell'architettura, è necessario chiedere: Esiste già in qualche punto della piattaforma Salesforce? Se la risposta è "Sì, ma... [inserire le modifiche desiderate da un stakeholder aziendale...]", utilizzare la funzione predefinita nella piattaforma. Il lavoro di architettura da eseguire consiste nell'identificare i modi più utili per configurare la funzione Salesforce predefinita in modo da soddisfare le aspettative aziendali.
• Nessuna personalizzazione è banale. Nel tempo, ogni modifica ha delle conseguenze. Se è necessario implementare una soluzione personalizzata, è possibile ridurre l'inevitabile debito tecnico che il sistema accumulerà scegliendo di utilizzare una tecnologia low-code ogni volta che sia possibile e creando unità componibili nelle implementazioni.
• Si consideri lo spettro build-buy. Salesforce AppExchange è un marketplace di app e soluzioni per estendere Salesforce. Le app AppExchange possono offrire funzionalità senza il sovraccarico necessario per creare e gestire una soluzione personalizzata. Durante la valutazione delle soluzioni AppExchange, tenere presente quanto segue:
  • Identificare le caratteristiche e le lacune della soluzione. L'ideale è trovare un'app che soddisfi tutti i requisiti aziendali. In realtà, potresti non trovare una misura perfetta. Durante la valutazione delle soluzioni, mappare le funzionalità della soluzione potenziale a un elenco prioritario di requisiti aziendali. Questo vi aiuterà a trovare la soluzione più adatta alle vostre esigenze più critiche.
  • Utilizzare i Sandbox e le versioni di prova gratuite. Utilizzare periodi di prova gratuiti per valutare le app negli ambienti Sandbox e identificare la soluzione migliore. Determinare se le app richiederanno modifiche alla configurazione in conflitto con la configurazione esistente.
  • Considerare i costi a breve e a lungo termine. Valutare i risparmi di manutenzione a lungo termine rispetto ai costi ricorrenti delle app basate su abbonamento. Evitare gli scenari in cui è necessario pagare costi ricorrenti per molte funzionalità che gli stakeholder aziendali non utilizzeranno mai.
• Utilizzare i modelli di dati predefiniti di Salesforce. Salesforce fornisce modelli di dati predefiniti per Sales, Service e una varietà di verticali di settore. L'utilizzo dei modelli di dati forniti da Salesforce garantisce che le funzionalità del sistema vengano definite una sola volta (eliminando ridondanza e silos), stabilisce un'unica fonte di dati in tutto il sistema, semplifica la comprensione dei dati delle applicazioni con gli analytics, semplifica l'utilizzo dei servizi di intelligenza artificiale predefiniti di Salesforce, riduce i costi di manutenzione (riducendo le personalizzazioni che è necessario supportare) e riduce l'indebitamento tecnico.

E' cosi' semplice. Come si può vedere negli schemi e antischemi riportati di seguito, gli antischemi si riducono a replicare le funzioni standard in una soluzione personalizzata o a utilizzare tecnologie più complesse per fornire personalizzazioni.

In pratica, si può verificare uno scenario in cui un anti-schema di funzionalità personalizzata viene considerato dagli stakeholder aziendali come la migliore o l'unica strada percorribile. In questi casi, è essenziale spiegare agli stakeholder i compromessi coinvolti nella scelta di questo percorso e quindi documentare in modo approfondito la decisione, la sua logica e la sua attuazione. Questo è anche un settore in cui fornire tempestivamente il valore chiave e adattarsi nel tempo può aiutare gli stakeholder a capire meglio come procedere.

Per ulteriori informazioni sugli strumenti Salesforce che possono aiutare a migliorare la manutenibilità, vedere Strumenti pertinenti all'intenzionale.

Il debito tecnico è una parte naturale di qualsiasi sistema. I sound design di ieri possono diventare anti-schemi quando la tecnologia o le esigenze aziendali cambiano. È possibile che qualcosa creato per colmare una lacuna nelle funzionalità di Salesforce Platform diventi improvvisamente ridondante con un nuovo rilascio di Salesforce o il lancio di un prodotto. Forse una tecnologia più performante o flessibile sostituisce una tecnologia già implementata. Il debito tecnico può essere creato in molti modi.

Un vantaggio chiave della creazione di applicazioni con Salesforce Customer 360 Platform è la compatibilità retroattiva integrata nella piattaforma. Ciò significa che le nuove innovazioni della piattaforma possono modificare lo schema da utilizzare per le soluzioni in futuro, ma la funzione quotidiana delle soluzioni create sulle tecnologie Salesforce precedenti continuerà a funzionare. Con il tempo, qualsiasi soluzione basata su tecnologie più datate inizierà a comportare rischi o colli di bottiglia per l'aggiunta di nuove funzioni alle app e ridurrà lo stato generale della soluzione.

Pianificare ed eseguire lavori regolari per risolvere il debito tecnico è essenziale per mantenere progetti sani e semplici in una soluzione Salesforce. Non pianificare, controllare e correggere il debito tecnico è un modo sicuro per creare un sistema mal progettato.

Un modo per ridurre al minimo l'indebitamento tecnico è evitare di introdurlo il più possibile, evitando le scelte rapide e preferendo le funzionalità standard alle funzionalità personalizzate. Le scelte rapide, come i valori codificati, possono essere tentate di risparmiare tempo, ma nel lungo termine creano un debito che deve essere ripagato.

Le chiavi per affrontare il debito tecnico da una prospettiva architettonica includono:

• Identificare il costo o i vantaggi effettivi dell'azione rispetto all'inazione
• Roadmapping corretto
• Costruire soluzioni componibili

La difficoltà può essere quella di allineare gli stakeholder all'azione. Alcuni stakeholder possono percepire la manutenzione in corso come una soluzione agli “errori di ieri” o come un’eliminazione delle funzionalità che vogliono supportare con il budget.

Mostrare l'impatto reale dell'azione e dell'inazione sul business, insieme a risultati e tempistiche chiaramente definiti, può aiutare gli stakeholder a capire il valore e la priorità relativa della gestione del debito tecnico. Fare costantemente il lavoro per collegare il debito tecnico agli impatti sul business non solo aiuterà gli stakeholder a capire meglio il lavoro da fare. Ti aiuterà anche a essere sicuro di identificare e risolvere il debito tecnico in modi che vadano davvero a vantaggio degli utenti.

L'elenco degli schemi e antischemi riportato di seguito mostra l'aspetto corretto (e inadeguato) della gestione del debito tecnico per un'organizzazione Salesforce.

Per ulteriori informazioni sugli strumenti Salesforce che possono aiutare l'utente in caso di indebitamento tecnico, vedere Strumenti pertinenti all'intenzionale.

La tabella seguente mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui destinare la riparazione.

✨ Scopri altri schemi per la manutenibilità in Pattern & Anti-Pattern Explorer.

Alla base, il concetto di leggibilità consiste nel creare coerenza che consenta alle persone di capire facilmente come funzionano le cose. La creazione di sistemi leggibili allinea i team di consegna e manutenzione e aiuta le persone che non hanno familiarità con il sistema a capire rapidamente come si inseriscono i pezzi. Ciò significa che il team può essere meno dipendente da singole persone con Knowledge istituzionali o storiche per integrare efficacemente i fornitori o i nuovi membri del team. Ciò significa che le persone esperte di un team possono concentrarsi sulla qualità e sui compromessi delle scelte che vengono effettuate, poiché la configurazione e il codice del sistema sono facili da leggere e comprendere. La leggibilità può velocizzare i processi di governance e di controllo della qualità e aiutare i team a identificare meglio quando potrebbero creare personalizzazioni ridondanti. Può anche aumentare le possibilità di avere un sistema che si comporta in modo riutilizzabile e testabile.

È possibile migliorare la leggibilità tramite standard di progettazione e documentazione efficaci.

Gli standard di progettazione forniscono indicazioni per mantenere coerenti tutte le personalizzazioni, anche nelle prime fasi di sviluppo. Gli standard di progettazione funzionano come guardrail, mantenendo allineati tutti i team di consegna e i team di manutenzione che lavorano sul sistema su come approcciare e implementare le personalizzazioni. La definizione di standard di progettazione consente di aumentare la produttività dei team di consegna e manutenzione, semplifica le revisioni del codice e dell'architettura e fornisce una base per una migliore documentazione.

Senza standard di progettazione, i team hanno maggiori probabilità di lavorare in silos. Senza la coerenza offerta dagli standard di progettazione, le aziende si troveranno alle prese con:

• Venditori e team di sviluppo che utilizzano schemi e approcci ad hoc nelle soluzioni, potenzialmente introducendo schemi anti-schema e riducendo la riutilizzabilità (vedere Separazione delle preoccupazioni).
• Maggiore tempo per risolvere i problemi di produzione e team di assistenza necessari per inserire nuovi membri del team e aiutarli a comprendere una serie di schemi e approcci diversi.
• Scarsa collaborazione tra i team, ridondanze nel lavoro tra i team, tempo perso per risolvere i conflitti e bug rilevati durante i test di integrazione.
• Aumento della frustrazione e tassi di turnover più elevati.

Un vantaggio chiave degli standard di progettazione deriva dalle conversazioni e dalle decisioni che gli stakeholder devono prendere per crearli. Nello specifico, il processo offre ai lead aziendali e tecnologici l'opportunità di allinearsi su come si presenta la progettazione ottimale per la propria azienda.

Includere i seguenti elementi negli standard di progettazione

• Convenzioni di denominazione per i metadati Salesforce. Definire un insieme di convenzioni per il nome di ogni personalizzazione di un sistema. Le convenzioni di denominazione corrette non si limitano a imporre la coerenza tra i nomi di oggetti, campi, codice, flussi e altri elementi del sistema. Convenzioni di denominazione valide aiutano anche i team di sviluppo a utilizzare nomi che trasmettono informazioni sullo scopo e la funzionalità di ciò che stanno creando. Di conseguenza, gli altri stakeholder possono comprendere meglio una determinata personalizzazione, semplicemente visualizzandone il nome.
• Modelli di progettazione approvati e relativi casi d'uso. Creare una libreria di Pattern & Anti-Pattern Explorer, insieme alle informazioni chiave su quando (e quando non) utilizzare ogni schema. La libreria può includere schemi di trigger Apex richiesti o schemi di orchestrazione dei flussi basati sulla componibilità desiderata nel sistema.
• Ambiente di sviluppo e guida. Mantenere un elenco chiaro degli strumenti che i team di sviluppo devono utilizzare per il proprio lavoro. Ciò potrebbe includere catene di strumenti e lingue approvate per chiunque scriva codice o funzioni dichiarative approvate (o non approvate) per lo sviluppo di codice basso. Gli standard possono includere un elenco di sistemi di controllo sorgente per la personalizzazione e la documentazione e le fasi di check-in/check-out obbligatori. Possono anche includere un elenco di ambienti da utilizzare per diversi tipi di lavoro di sviluppo.

Oltre a definire questi standard, sarà necessario decidere come e dove mantenerli e archiviarli. Se i team di tutta l'azienda non riescono a trovare gli standard di progettazione (o non ne sono nemmeno consapevoli), non saranno efficaci. L'ideale è che gli standard di progettazione siano integrati nello stesso sistema della documentazione (per ulteriori informazioni, vedere la sezione successiva).

L'elenco di schemi e antischemi riportato di seguito mostra l'aspetto degli standard di progettazione corretti (e scadenti) per un'organizzazione Salesforce. È possibile utilizzarli per convalidare o migliorare gli standard di progettazione.

Per ulteriori informazioni sugli strumenti Salesforce che possono aiutare a definire gli standard di progettazione, vedere Strumenti pertinenti all'intenzionale.

La documentazione spiega cosa, come e perché del sistema. Senza una documentazione significativa e coerente, i team perdono molto tempo a cercare di capire il sistema così com'è (e potenzialmente fraintendere le funzioni e le personalizzazioni).

La creazione di una buona documentazione richiede tempo. Benché la maggior parte dei team sia d'accordo sul fatto che la documentazione sia importante per i progetti di grandi dimensioni, può essere un passo allettante da saltare quando si apportano modifiche rapide come aggiornamenti di configurazione o piccole modifiche a un'automazione. Non documentare le modifiche apportate al sistema è sempre un anti-schema. Ignorare la documentazione può far risparmiare un po' di tempo in anticipo, ma la quantità di tempo necessaria per risolvere i problemi di un'organizzazione non adeguatamente documentata annulla ampiamente tali risparmi di tempo. Includere sempre tempo sufficiente per creare la documentazione in tutte le stime, indipendentemente dal livello di impegno richiesto per gli aggiornamenti che si prevede di eseguire.

La mancanza di una documentazione chiara può causare una serie di problemi, tra cui:

• Cicli di sviluppo spesi per rielaborare implementazioni esistenti
• Discussioni ripetitive che rivedono o sconcertano le decisioni precedenti
• Onboarding più lungo per i nuovi membri del team o fornitori
• Eccessiva dipendenza da individui con Knowledge istituzionali o storiche
• Architetture ridondanti per supportare le stesse funzionalità o funzionalità simili in tutta l'azienda
• Difficoltà a comunicare lo scopo e il valore della soluzione ai principali stakeholder

Per le soluzioni Salesforce, conservare la documentazione per:

• Panoramica delle soluzioni. I diagrammi consentono all'utente e ai suoi stakeholder di visualizzare le soluzioni a vari livelli di dettaglio. Il framework del diagramma di Salesforce consente di creare diagrammi che mostrano le funzionalità aziendali delle soluzioni e i dettagli tecnici dell'implementazione.
• Record decisioni. Tenere un registro delle opzioni considerate, dei compromessi, della decisione finale e del ragionamento in una posizione centrale a cui tutti i membri del team possono accedere per riferimento futuro.
• Codice. Il formato stesso del codice è un elemento chiave della documentazione e questo può (e deve) allinearsi agli standard di progettazione. Si desidera anche avere un registro delle informazioni chiave e aggiornarlo con ogni modifica di un frammento di codice. Per tutte le classi, i trigger e i componenti, documentare quanto segue:
  • Chi ha creato il codice
  • Quando è stato scritto il codice
  • Cosa dovrebbe fare il codice
  • Dipendenze chiave
  • Tutte le modifiche
• Personalizzazione dichiarativa. Per ogni tipo di personalizzazione che può essere apportata ai metadati nell'organizzazione, Salesforce fornisce attributi incorporati che consentono ai team di fornire informazioni utili sullo scopo e l'intento dei metadati. Nell'ambito degli standard di progettazione, includere le modalità di utilizzo di queste funzioni incorporate da parte dei team e la denominazione delle personalizzazioni dichiarative. Mantenere anche un registro delle informazioni chiave identico a quello utilizzato per il codice.

Sviluppare una serie di standard di documentazione per garantire che tutti i membri attuali e futuri del team siano in grado di interpretare i documenti allo stesso modo (gli standard di progettazione possono essere utili in questo caso). È anche importante considerare in che modo gli utenti potranno cercare nella documentazione per trovare sezioni o termini pertinenti. Man mano che il sistema invecchia e diventa più complesso, crescerà anche la documentazione. L'utilità delle informazioni nella documentazione sarà direttamente correlata alla frequenza, alla rapidità e alla facilità con cui gli utenti possono cercare e trovare gli elementi pertinenti.

L'elenco di schemi e antischemi riportato di seguito mostra l'aspetto della documentazione corretta (e scarsa) per un'organizzazione Salesforce. È possibile utilizzarli per convalidare o migliorare la strategia di documentazione.

Per ulteriori informazioni sugli strumenti Salesforce per la documentazione, vedere Strumenti pertinenti all'intenzionale.

La tabella seguente mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui destinare la riparazione.

✨ Scopri altri modelli per la leggibilità in Pattern & Anti-Pattern Explorer.

Aiutaci a mantenere Salesforce Well-Architected pertinente per te; partecipa al nostro sondaggio per fornire un feedback su questo contenuto e dirci cosa vorresti vedere dopo.