L'architettura è l'arte dei trade-off

🌐 Disponibile anche in 28 lingue

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Immagine generata con l'IA

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

Modulo 4 di 7 del capitolo Pensare da Data Architect, il primo capitolo del corso Data Architect. Ogni modulo si regge da solo. Precedente: Il Test di Reversibilità · Successivo: Costruisci per oggi. Pianifica per domani. Pianifica per il guasto.

La domanda a cui risponde questo modulo: Quando diverse soluzioni potrebbero funzionare, come sceglie un architetto, e come spiega la scelta?

Se l’architettura consistesse semplicemente nell’individuare la risposta corretta, sarebbe molto più facile. Impari la piattaforma, impari i pattern, impari i limiti, scegli quello giusto, fatto.

Non è così che funziona l’architettura reale. Le decisioni difficili di solito non sono tra una soluzione ovviamente buona e una ovviamente cattiva. Sono tra diverse soluzioni che potrebbero funzionare, ognuna con vantaggi e svantaggi, ognuna che porta l’architettura in una direzione leggermente diversa. È lì che l’architetto si guadagna il suo posto al tavolo.

Molti modi per risolvere il problema

Ho usato una versione di questo esempio molte volte formando architetti.

In Salesforce ci possono essere molti modi per risolvere un problema. A volte ci metto un numero, diciamo dieci, ma è un’analogia, non un conteggio. Molte opzioni hanno problemi fin dall’inizio: si scontrano con un vincolo della piattaforma, mancano un requisito critico o creano un problema di sicurezza o di prestazioni che non possiamo accettare. Possiamo scartarle in fretta. Altre funzionano oggi ma avranno problemi quando i dati cresceranno. Tecnicamente funzionano, ma non reggeranno la crescita che sappiamo già che arriverà.

Ciò che resta è un piccolo numero di opzioni in grado di sostenere le tue esigenze nel tempo, e ora la cosa si fa interessante. Ognuna potrebbe funzionare, scalare e soddisfare i requisiti. Allora qual è quella corretta? Forse tutte. Il compito dell’architetto è capire le differenze.

Anche una cosa semplice come un elenco di selezione funziona oggi e può avere problemi quando i dati crescono. Un elenco di selezione è facile per gli utenti. Ma chiediti da dove vengono i valori, e quanti possono essere. Gli elenchi di selezione funzionano meglio con meno di una ventina di valori. A volte arriviamo a 50, come gli stati americani, e raramente oltre 100, come i paesi, e diventano scomodi. Quindi, per ogni elenco di selezione, conosci il limite massimo. E cambiare i valori di un elenco di selezione è una modifica ai metadati, non ai dati.

Usa invece una relazione di ricerca, e l’interfaccia utente diventa un po’ più complessa. Ma l’elenco può continuare a crescere senza limite, e i nuovi valori possono arrivare da un’integrazione. È un trade-off rispetto all’usabilità. È questo l’equilibrio.

Click to enlarge

Ottimale non significa perfetto

Uso la parola ottimale con attenzione. Un’architettura ottimale non è quella in cui ogni singola decisione è perfetta; quell’architettura probabilmente non esiste. È quella in cui la soluzione nel suo insieme è equilibrata.

Supponiamo che la Soluzione A dia le migliori prestazioni ma sia costosa e difficile da mantenere. La Soluzione B costa meno ed è più facile da gestire, ma rinuncia a un po’ di prestazioni. La Soluzione C è più flessibile per il futuro ma aggiunge complessità oggi. Qual è quella ottimale? Non posso rispondere solo da questi fatti. Devo conoscere il business, i requisiti e le priorità, e quali vincoli sono reali e quali sono preferenze. L’architettura dipende dal contesto. Ecco perché il pattern giusto per un cliente può essere completamente sbagliato per il successivo.

E il tuo compito come Data Architect è bilanciare queste decisioni. Ne prenderai decine da solo, o con il tuo team. Sappi quali sono, e riconosci quando una decisione ha un impatto maggiore, su costi, tempi o funzionalità, e deve salire fino a chi prende le decisioni chiave.

Una decisione subottimale può far parte di un’architettura ottimale

È una delle idee più importanti di questo capitolo. A volte prendo consapevolmente una decisione subottimale in una parte dell’architettura perché rende migliore l’intera soluzione.

Forse duplico una piccola quantità di dati, perché eliminare la duplicazione creerebbe una complessità di integrazione inutile. Forse scelgo un modello dati più semplice, perché quello teoricamente più pulito renderebbe molto più difficili la reportistica e l’uso quotidiano. Forse accetto un piccolo costo in prestazioni, perché l’alternativa aggiunge un’infrastruttura che l’organizzazione non è pronta a gestire.

Guarda una qualsiasi di queste decisioni da sola e diresti che non è ottimale. Esatto. Ma l’architettura non consiste nell’ottimizzare ogni componente per conto suo; consiste nell’ottimizzare il sistema. Una decisione subottimale a livello locale può far parte di un’architettura ottimale a livello globale, purché capiamo il trade-off che stiamo facendo. Il pericolo è fare il trade-off senza sapere di farlo.

Sappi a cosa stai rinunciando

Ogni volta che qualcuno mi dice “questa è la soluzione migliore”, la mia domanda successiva è “migliore in cosa?”. La più veloce? La più economica? La più semplice? La più scalabile, la più sicura, la più flessibile? La più facile da gestire, la più rapida da consegnare, la meno dipendente da competenze specialistiche? C’è quasi sempre un’altra dimensione in cui la risposta non è “la migliore”. Quello è il trade-off. Voglio sapere cosa otteniamo, e voglio anche sapere a cosa rinunciamo.

Prendi due opzioni per un grande insieme di dati aziendali. Una copia i dati in Salesforce, il che rende più facile usare le funzionalità native di Salesforce, ma ora siamo responsabili di spostarli, memorizzarli, sincronizzarli, proteggere un’altra copia e gestire la latenza. L’altra lascia i dati dove sono e vi accede quando servono. Abbiamo eliminato un po’ di duplicazione, ma ora contano di più la disponibilità, le prestazioni delle query, le dipendenze di rete e le capacità del sistema remoto. Nessuna delle due descrizioni ci dice quale scegliere. Ci dice quali domande porre.

I requisiti non sono tutti uguali

I trade-off ci costringono anche a vedere che non tutti i requisiti hanno lo stesso peso.

Qualcuno dice: “I dati devono essere disponibili istantaneamente”. Bene, cosa significa istantaneamente? Un secondo, dieci secondi, un minuto? E perché? Forse si tratta di rilevamento delle frodi, dove i secondi contano. Forse a qualcuno semplicemente non piace aspettare il caricamento notturno. Sono requisiti molto diversi, e l’architetto continua a chiedere finché non sappiamo quale abbiamo.

Mi piacciono i requisiti che reggono alle domande: quanto, quanti, quanto veloce, quanto spesso, per chi, e cosa succede se non lo facciamo? “Veloce” non è un requisito di architettura. “Il 95 per cento degli aggiornamenti dei clienti deve essere disponibile all’agente del servizio entro 30 secondi” ci si avvicina molto di più. Ora possiamo valutare i trade-off.

I vincoli cambiano la risposta

A volte l’architettura non è vincolata affatto dalla tecnologia. È vincolata da denaro, persone, tempo, licenze o maturità organizzativa.

Un’architettura tecnicamente eccellente ma che richiede un team operativo che l’azienda non ha non è una buona architettura. Una funzionalità che risolve il problema con eleganza ma richiede licenze che il cliente non comprerà non è nemmeno lei la soluzione. E la trasformazione perfetta in tre anni non aiuta un’azienda che deve partire tra otto settimane.

Niente di tutto questo significa abbandonare la buona architettura per una scadenza. Significa capire su cosa scendiamo a compromessi, perché e quali conseguenze accettiamo, e idealmente come passeremo dal compromesso di oggi all’architettura di domani.

L’architetto ha bisogno di un’immagine dell’“ottimale”

Ecco una tensione interessante. Ti dico che spesso non esiste un’unica risposta perfetta, e voglio anche che tu porti in testa un’immagine di come appare una soluzione ottimale. Non è una contraddizione. Ti serve un punto di riferimento.

Quando guardo un modello dati, voglio sapere cosa costruirei se potessi ottimizzare per i requisiti senza vincoli inutili. Poi, quando i vincoli reali ci allontanano da quel progetto (appiattiamo parte del modello, duplichiamo alcuni dati, rimandiamo un’integrazione, accettiamo un processo manuale temporaneo), non sto facendo compromessi a caso. So in quale direzione mi sto allontanando dall’ottimale, e perché. È l’arte dell’architettura, e l’istinto richiede pratica.

Disegnalo

Uno dei modi migliori per capire un trade-off è disegnarlo. I diagrammi di architettura non sono decorazioni per una presentazione; sono strumenti per pensare. Se stiamo scegliendo tra due approcci, disegnali entrambi. Dove risiedono i dati, e dove si muovono? Chi li possiede? Dove sono i confini, e dove viene applicata la sicurezza? Cosa succede quando qualcosa si guasta, e cosa cambia quando il volume cresce?

Un diagramma costringe l’ambiguità a venire allo scoperto, e dà a tutti la stessa immagine da indicare.

Ho imparato quanto conti in un progetto con un’azienda di servizi pubblici. Revisione dopo revisione, mi ritrovavo a spiegare di nuovo gli stessi concetti e a riportare la conversazione al progetto originale. Così ho cambiato il modo di condurre quelle riunioni: ogni revisione iniziava con il modello dati sullo schermo. Non quello dettagliato con ogni campo. Un modello di sintesi: un account ha dei contatti, questo record ha dei figli, ecco dove è agganciato il lavoro. Nella stanza c’erano soprattutto dirigenti, e bastavano un paio di minuti.

Siccome erano le stesse persone riunione dopo riunione, il diagramma è diventato il nostro linguaggio comune. Le persone hanno iniziato a usarne i nomi. Le domande ripetute sono sparite e le riunioni sono diventate molto più facili. Lo chiamo ancorare la riunione: un diagramma semplice, mostrato ogni volta, valeva molto più di quanto costasse realizzarlo.

L’obiettivo non è la perfezione artistica. A volte è un diagramma dettagliato per gli ingegneri, a volte cinque riquadri e sei frecce per un dirigente. L’obiettivo è la chiarezza.

Spiega il trade-off

Un buon architetto lo espone in ordine: ecco le opzioni che abbiamo considerato, ecco cosa ci dà ciascuna, ecco quanto ci costa ciascuna, ecco l’opzione che raccomando, ed ecco perché.

Nota che la raccomandazione arriva dopo i trade-off. Non voglio che l’architettura diventi “l’ho già fatto, fidati”. L’esperienza conta moltissimo; ti aiuta a riconoscere i pattern più in fretta e a vedere i problemi prima. Ma la tua esperienza dovrebbe migliorare il tuo ragionamento, non sostituirlo. Il nostro compito non è solo capire l’architettura. È aiutare l’organizzazione a capire la decisione, soprattutto quando chi decide alla fine non è un architetto.

Think Correct. Think Fast.

Non avrai sempre tre settimane per analizzare ogni opzione. A volte avrai tre minuti. Un requisito cambia durante una riunione, qualcuno nomina un vincolo che non conoscevi, o un dirigente chiede: “E se l’anno prossimo ci servisse in Europa?”.

Ho usato l’espressione Think Correct. Think Fast. (Pensa giusto. Pensa veloce.) La velocità non viene dal saltare il ragionamento. Viene dall’aver ragionato abbastanza prima che arrivi il momento: hai imparato i pattern, conosci la piattaforma, hai visto i fallimenti, sai quali domande porre e quali decisioni sono difficili da invertire. Ecco perché in questo corso lavoriamo su scenari dall’inizio alla fine. Più decisioni analizzi, più in fretta riconosci la forma della prossima.

Avevo un cliente che aveva bisogno di inserire moduli. Ma i moduli erano tanti, e le domande potevano cambiare nel tempo. Ho riconosciuto subito la necessità di un modello dati per sondaggi, un pattern su cui torneremo più avanti nel corso. Avendo riconosciuto il pattern e la soluzione, ho potuto proporre un modello dati più completo, che gestiva i requisiti ancora da venire, non solo quelli che avevamo davanti.

L’architettura è equilibrio

Man mano che andremo più a fondo nell’architettura dei dati, incontrerai scelte per cui mi rifiuto di darti una regola semplice. Normalizzare o appiattire? Copiare i dati o federarli? Sincrono o asincrono? Oggetto standard o personalizzato? Archiviarli o tenerli online?

Ci sono principi, pattern e limiti, e a volte risposte chiaramente sbagliate. Ma spesso il compito dell’architetto è trovare il giusto equilibrio per questo sistema, questo business e questo momento.

Sappi com’è l’ottimale. Capisci i vincoli. Individua le opzioni praticabili. Rendi visibili i trade-off. Poi prendi la decisione.

Non è indecisione. È architettura.

Cosa decide qui un architetto

• Quali opzioni sono praticabili, e quali sono sbagliate ora o lo diventeranno fra un anno.
• Cosa guadagna e a cosa rinuncia ogni opzione praticabile, misurato su requisiti che reggono alle domande.
• Quali vincoli sono reali e quali solo preferenze.
• Quale opzione raccomandare, dopo aver esposto i trade-off, e come spiegarla.