La domanda a cui risponde questo modulo: Come disegno un panorama che mostri dove vanno i dati?
Dammi un nuovo scenario e una lavagna bianca, e una delle prime cose che disegnerò è il panorama dei sistemi. Non bello, non ogni API, non ancora il modello dati. Voglio vedere l’azienda: chi sono gli utenti, quali sistemi sono coinvolti, dove si colloca Salesforce, cosa la circonda, da dove vengono i dati e dove vanno. E poi voglio percorrere le frecce. Un buon panorama non è un’immagine di riquadri. È un modo per far emergere le decisioni architetturali.
Faccio esercitare su questo i candidati CTA. Leggi lo scenario, poi inizia a disegnare. Non aspettare di aver risolto tutto in testa; il disegno ti aiuta a risolverlo. Per questo il compito dopo il primo giorno è iniziare il panorama prima di provare a buttare giù il modello dati. Disegna prima il modello dati e hai già dato per scontato cosa appartiene a Salesforce. Disegna prima il panorama e vedi i sistemi che dovrebbero dare forma a quella decisione.
Parti dall’alto, poi scendi nel dettaglio: prima l’intera azienda, poi il dettaglio dove conta.
Ci sono molti modi di disegnare un panorama dei sistemi. Questo è solo il mio, uno che ho affinato in molti anni, e lo condivido perché tu veda come metterne insieme uno in fretta. Lo uso per ogni panorama Salesforce, e si legge come una frase: le persone a sinistra raggiungono Salesforce al centro, con la fiducia garantita dai sistemi sopra, servite dai canali sotto, e collegate al back office a destra.
Le persone a sinistra, dall’alto in basso: utenti interni, partner, clienti. Non ancora ogni persona tipo; abbastanza per rispondere a chi sta cercando di raggiungere questa architettura? Ogni gruppo punta al proprio punto di ingresso: gli utenti interni a Salesforce, i partner alla community dei partner, i clienti alla community dei clienti. I sistemi non esistono da soli. Qualcuno, o qualcosa, sta cercando di usarli.
Passo 2 di 6: chi sta cercando di raggiungere questa architettura?
Salesforce al centro. Un semplice riquadro. Non perché Salesforce sia il centro dell’azienda (abbiamo appena passato tre moduli a dire che non lo è) ma perché è il sistema intorno a cui sto progettando. È l’ancora.
Le community subito sotto, a contatto. Una community dei partner e una community dei clienti sono endpoint separati, quindi hanno i loro riquadri. Ma stanno attaccate a Salesforce, perché non serve alcuna integrazione per raggiungerle: girano nella stessa org.
Passo 3 di 6: Salesforce al centro, le community subito sotto.
L’identità sopra. I provider di identità vanno in cima, quelli che gli sviluppatori dimenticano: uno per gli utenti interni, magari un altro per i partner. Lassù vanno anche i pacchetti AppExchange, spostati verso destra, perché sono funzionalità portate dentro la org e non sistemi di back office che scambiano dati con essa. I siti web pubblici stanno in alto a sinistra.
Passo 4 di 6: l’identità sopra, il riquadro che gli sviluppatori dimenticano.
L’integrazione, poi il back office, a destra. Il livello di integrazione, un ESB o un iPaaS (o MuleSoft, quando viene nominato), è una barra alta subito a destra di Salesforce. I sistemi interni stanno dietro di essa: gli ERP, la finanza, la gestione degli ordini, i sistemi legacy, il data warehouse. Ora la pagina si legge da sinistra a destra: persone, Salesforce, integrazione, back office.
I canali sotto. Tutto ciò che ha una linea diretta con i clienti: email-to-case, web-to-lead, telefono, messaggistica.
I dati in entrata e in uscita, in basso a destra. Fonti di dati esterne, archivi, caricamenti di dati.
Data 360 a destra, sotto il livello di integrazione. Gli utenti non vi si collegano mai, e il suo tenant si collega a molti sistemi di back-end, quindi sta con le tubature, dove quelle linee restano corte: accanto ai sistemi interni, al data warehouse e ai dati in basso a destra. I team dei dati aprono sì le sue schermate, ma quelle schermate sono nella org: Data 360 è vicino al core (near-core), gestito sul core e ospitato fuori dal core (modulo 1). Una sola linea che torna a Salesforce mostra chi lo gestisce. Il posto in cui metti il riquadro dovrebbe raccontare cosa fa.
Niente di questa geometria è sacro. Il valore di una convenzione è che non reinvento ogni volta il linguaggio visivo, e chiunque abbia visto uno dei miei diagrammi legge il successivo più in fretta.
Mantieni semplice la notazione. Ogni sistema è una scheda: il suo nome, il suo ruolo e una piccola icona che dice che tipo di cosa è: un ERP, un database, un provider di identità, un gruppo di persone. Le regioni che ho appena descritto sono disegnate come zone tenui con un’etichetta, così il layout stesso è visibile. Una legenda in basso dice cosa significa ogni icona e ogni linea.
Non mettere troppo dentro un riquadro. Solo in un panorama molto complicato apro Salesforce nelle sue parti (Sales Cloud e Service Cloud dentro la org, con frecce tra loro). E non inventare quindici forme, a meno che ognuna dica qualcosa a chi legge. Voglio che qualcuno guardi il panorama per trenta secondi e cominci a capire l’architettura. L’effetto speciale non aiuta. La chiarezza sì.
Non aspettare la progettazione di dettaglio per pensare al volume. Una freccia che porta 500 prodotti a notte e una che porta 200.000 letture GPS al giorno possono sembrare identiche nel panorama. Non sono lo stesso problema. Quindi, prima di disegnare una sola freccia, conta ciò che si muove. Avvia l’inventario dietro l’immagine con i conteggi: una riga per ogni insieme di dati importante, con il suo volume. Gli zeri potrebbero non comparire mai sulle frecce, ma devi sapere quando entri nei numeri alti: migliaia o milioni in un’ora, centinaia di migliaia di transazioni, persino da decine a centinaia di transazioni al secondo.
Quei numeri guidano il meccanismo. Qualche centinaio di record a notte è un batch. Una chiamata su cui qualcuno aspetta può essere sincrona, se il volume lo permette. Da decine a centinaia al secondo possono richiedere eventi, come i platform event, invece di una chiamata per record. La freccia avrà lo stesso aspetto; è il volume a decidere cosa la trasporta, quindi registralo nell’inventario, dove si sceglie il meccanismo.
Il meccanismo può persino cambiare la direzione della freccia. Invia un paio di record al minuto, e Salesforce può semplicemente fare una chiamata in uscita: la freccia parte da Salesforce. Inviane molti di più, e Salesforce potrebbe invece pubblicare eventi sull’event bus; il sistema esterno si iscrive e chiama per riceverli, quindi ora la freccia parte dall’altra estremità. Ancora più grande, per esempio una sincronizzazione notturna di milioni di record, ed è un processo batch. Quindi conosci presto i tuoi conteggi, quando cominci a progettare i meccanismi, perché i conteggi possono ridisegnare le frecce.
Il volume conta in due posti, per due ragioni. In un modello dati, mi serve per tenere d’occhio i grandi volumi di dati e pianificare l’archiviazione; la Parte 2 lo approfondisce. In un panorama dei sistemi, i numeri grandi dell’inventario guidano la scelta del pattern e del meccanismo di integrazione. Il modulo 6 mette zeri reali sul panorama di Steve Trucking e sul suo inventario. Con i conteggi in mano, disegna le frecce.
Con i sistemi al loro posto, collegali, e il panorama diventa architettura. Un riquadro è un sistema; la freccia mostra chi avvia la connessione. Parte dal sistema che apre la connessione e punta a quello che chiama: dal client al server. L’etichetta dice cosa si muove, e in che direzione.
Questa regola vale per i panorami dei sistemi, dove sono i sistemi a parlare con altri sistemi. In un diagramma di flusso dei dati la freccia segue i dati, come ti aspetteresti. Non portare la regola del panorama in altri diagrammi; aggiunge solo confusione.
Le frecce aggiunte. Ogni riquadro è dov’era; ogni freccia parte dal sistema che apre la connessione, e la sua etichetta dice cosa si muove e in che direzione.
Quindi, se il livello di integrazione spinge i prodotti in Salesforce, la freccia va dal livello di integrazione a Salesforce, con l’etichetta prodotti in entrata (products in). Se è Salesforce a chiamare per recuperarli, la freccia parte da Salesforce, sempre con l’etichetta prodotti in entrata. Stessi dati, conversazione diversa, e quella differenza mi dice chi ha bisogno delle credenziali e chi deve gestire il fallimento. Salesforce invia l’ordine attraverso il livello di integrazione: ordini in uscita (orders out). L’evasione dell’ERP torna indietro: stato dell’ordine in entrata (order status in). Ora vedo chi avvia ogni conversazione, dove i dati entrano in Salesforce e dove escono, quali flussi attraversano confini, dove probabilmente sta la titolarità, e dove devo chiedere di più.
E ricorda il modulo 1: ogni volta che vedo un solo flusso, mi preoccupo. Ad alto livello, una freccia ordini in uscita dipende da flussi di ritorno: clienti in entrata, prodotti in entrata, prezzi. Guarda ancora più a fondo e c’è il viaggio di ritorno: accettazione, rifiuto, stato, un numero di fattura, un annullamento. Le frecce mi danno qualcosa di concreto da mettere in discussione.
È qui che il panorama smette di essere arte da PowerPoint. Davanti alla commissione d’esame, qualsiasi freccia può attirare tre domande, e voglio che tu abbia le risposte:
Come si autentica? OAuth, un certificato, una named credential, qualcos’altro?
È sincrona o asincrona? Salesforce aspetta l’ERP, o pubblica e va avanti? Quanto in fretta ha bisogno del risultato il business?
Qual è il meccanismo? Una chiamata REST, un evento, un file, una coda di messaggi, tramite MuleSoft o diretto?
E poi: cosa succede quando l’altra parte è giù? Ogni freccia ha bisogno di un meccanismo. Se non sai spiegarlo, la linea è decorazione.
E “fire and forget” non è una risposta. Di solito significa “non ho progettato cosa succede dopo lo sparo”. È arrivato? È stato accettato? È fallito? Riproverà? Chi sa che è bloccato? E se lo stesso messaggio arriva due volte? Niente di questo va nel panorama, che diventerebbe illeggibile. Ma la freccia dovrebbe farti sapere che quelle domande esistono.
Ingrandisci una qualsiasi freccia e trovi un client e un server, e ognuno possiede la sua metà. Il client apre la connessione: ha bisogno dell’endpoint e della porta, ottiene prima un token dal server di autenticazione, chiama secondo il protocollo e il contratto definiti dal server, e sceglie se aspettare. Solo il client vede l’intero viaggio di andata e ritorno, quindi solo il client può riprovare. Il server ascolta, definisce il protocollo, il contratto e il payload, convalida ciò che arriva, e vede solo la propria parte. Quando disegno una freccia, so già quale estremità è quale, e questo mi dice chi possiede ciascuna di queste domande.
Una freccia, ingrandita: il client gestisce, il server definisce. Niente di questo va nel panorama, ma ogni freccia lo ha.
Ora gira la freccia. Quando l’ERP chiama Salesforce, Salesforce è il server: definisce le API, gestisce il proprio server di autorizzazione, e decide tramite un’App client esterna e un utente di integrazione cosa può fare chi chiama. Stesse domande, dall’altra parte.
Ecco dove gli architetti rovinano un buon diagramma: gli fanno rispondere a tutto. Nel panorama finiscono nomi delle API, payload, nuovi tentativi, code di errore, trasformazioni, ogni callback, e presto nessuno riesce più a leggerlo. Non farlo. Il panorama è il quadro generale: i sistemi e i flussi importanti tra loro.
Quando devo spiegare un’interazione, disegno un secondo diagramma, ma non per ogni integrazione. Se il sistema A invia qualcosa a B, o anche chiede e riceve una risposta, la freccia con l’etichetta basta. Voglio una corsia (swim lane) quando il processo diventa una conversazione: A chiama B, B verifica con C, C risponde, B crea qualcosa e richiama A, una persona approva, un altro sistema prosegue. La mia regola pratica: più di uno o due scambi avanti e indietro, e la sequenza ha una sua corsia. Frecce nel panorama; la conversazione nella corsia.
E nota che lì una freccia significa qualcosa di diverso. Nel panorama, una freccia è una connessione: chi la apre, e cosa si muove. In una corsia, ogni freccia è un messaggio in una conversazione, letto in ordine: una richiesta va in un senso, una risposta torna nell’altro, e il passo successivo segue.
Quando il panorama sembra quasi finito, percorrilo, freccia per freccia. Da ERP a Salesforce: cosa si muove, chi lo possiede, come si autentica, qual è il meccanismo, sincrono o asincrono, quanto deve essere aggiornato? Poi la freccia successiva, e quella dopo. È qui che compaiono le lacune. “Ah, non abbiamo mai capito come il partner lo invia davvero.” “Mandiamo gli ordini all’ERP, ma non abbiamo progettato come tornano quelli rifiutati.” Bene. L’hai trovato sulla lavagna invece che in produzione.
L’immagine deve restare leggibile, quindi i dettagli vanno nell’inventario dietro di essa. L’hai avviato con i conteggi; ora completalo, una riga per ogni insieme di dati o flusso importante:
Colonna
Cosa voglio sapere
Insieme di dati
Cliente, prodotto, ordine, consegna, fattura
Tipo
Master, di riferimento, transazionale, analitico, non strutturato
Responsabile
Chi governa il suo significato e il suo ciclo di vita?
Ecco perché mi piace questo artefatto: mi aiuta a pensare. “Come faremo report tra Salesforce e l’ERP?” È la domanda del modulo 3: quale dei miei diagrammi risolve questo in modo splendido? Il panorama. Se è tutto sul core, report standard. Se i dati sono nell’ERP e nel data warehouse, lo vedi subito. “Dove dovrebbe essere gestito come dato master questo attributo del cliente?” Guarda quali sistemi lo usano e quale possiede già il cliente. “Salesforce ha bisogno di ogni lettura GPS?” Chi la produce, chi la consuma, qual è il carico di lavoro? Forse a Salesforce serve la posizione attuale e un’altra piattaforma conserva lo storico. Il panorama non ti consegna la risposta. Ti dà la vista giusta del problema.
Un’ultima disciplina. In un’azienda esistente, disegna ciò che esiste, non ciò che vorresti esistesse. Il foglio di calcolo mandato per email ogni venerdì: disegnalo. Il CSV del partner su un server SFTP: disegnalo. L’integrazione che salta l’ESB per ragioni storiche: disegnala. Persone che ridigitano dati tra due sistemi: mostralo. Non ripulire la realtà mentre la documenti. Ti serve il panorama attuale prima di progettare quello futuro, ed è ciò che facciamo per Steve Trucking nel modulo 6.
Oltre l’esame: cosa cambia l’IA. Il panorama sta diventando una mappa per gli agenti. Se un agente risponde a “dov’è la mia consegna?”, il panorama deve dire se la risposta viene da Salesforce, dal sistema di un partner, dalla telematica, dall’ERP o da un misto. Gli agenti non eliminano i confini tra i sistemi; rendono ancora più importante sapere quale sistema è autorevole, e come raggiungerlo in sicurezza.
Quali sistemi e quali popolazioni di utenti appartengono al panorama, e come la loro posizione mostra il loro ruolo.
Quali flussi attraversano i confini tra sistemi, in quale direzione, e cosa torna indietro.
Come si autentica ogni collegamento, quale meccanismo lo trasporta, e se è sincrono, asincrono, batch o federato.
Quando basta una freccia con l’etichetta e quando un’interazione ha bisogno di una sua corsia.
Cosa registra l’inventario dietro l’immagine: responsabile, carico di lavoro, volume, org, tempi, autenticazione, e copiare, referenziare o federare.
Il panorama non è qualcosa che disegno dopo che l’architettura è finita. È il modo in cui trovo l’architettura. E quando pensi che sia finito, non ammirarlo. Percorrilo. Ogni freccia che non sai ancora spiegare ti mostra dov’è il lavoro.
