Costruisci per oggi. Pianifica per domani. Pianifica per il guasto.

🌐 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 5 di 7 del capitolo Pensare da Data Architect, il primo capitolo del corso Data Architect. Ogni modulo si regge da solo. Precedente: L’architettura è l’arte dei trade-off · Successivo: Conosci i tuoi strumenti: le nove domande

La domanda a cui risponde questo modulo: Come progetti per i requisiti di oggi pianificando allo stesso tempo la crescita e il guasto?

Uno degli errori più facili in architettura è progettare solo per i requisiti che hai davanti. Abbiamo un progetto, un backlog e dei requisiti. Costruiamo qualcosa che li soddisfa. Funziona, e cantiamo vittoria. Sei mesi dopo il business cambia, o i dati crescono, o un’altra business unit vuole usarlo, o acquisiamo un’azienda, o un nuovo sistema deve integrarsi, o si guasta qualcosa che nessuno aveva previsto.

Niente di tutto questo dovrebbe sorprendere un architetto. Non possiamo prevedere tutto ciò che succederà, ma possiamo progettare sapendo che qualcosa succederà. Per questo guardo l’architettura attraverso tre lenti:

Costruisci per oggi. Pianifica per domani. Pianifica per il guasto.

Ti servono tutte e tre.

Click to enlarge

Costruisci per oggi

L’architettura parte dal problema che abbiamo davvero. Sembra ovvio, ma gli architetti possono commettere l’errore opposto al pensiero a breve termine: possiamo sovra-progettare. E se acquisissimo dodici aziende, avessimo un miliardo di clienti, ci espandessimo in 40 paesi e ogni sistema avesse bisogno di integrazione in tempo reale? Forse. Ma sono possibilità reali, o stiamo inventando problemi? L’architettura non consiste nel costruire il sistema più sofisticato che riusciamo a immaginare. Consiste nel costruire quello adeguato.

Quindi parti da oggi: di cosa ha bisogno il business, i volumi, gli utenti e le transazioni reali, quanto spesso cambiano i dati e quanto in fretta devono muoversi, chi ha bisogno di accedervi, e da dove vengono e dove vanno i dati. E soprattutto: perché? Queste risposte ci danno qualcosa di concreto da progettare.

Cerca i requisiti impliciti

I requisiti che ti vengono dati non sono necessariamente tutti i requisiti che hai. Ci sono quasi sempre requisiti impliciti.

Il business dice: “Ci servono i dati dei clienti in Salesforce”. Bene. Allora qualcuno deve possedere quei dati e decidere quanto devono essere aggiornati. Dobbiamo sapere cosa succede quando il sistema di origine è giù, come ci accorgeremo che la sincronizzazione fallisce, e chi vince quando Salesforce e l’origine non sono d’accordo. Ci servono un periodo di conservazione, un modello di accesso, una decisione sui campi sensibili e un modo per correggere i dati sbagliati.

Niente di tutto questo era nella user story. Eppure è tutta architettura. Gran parte del diventare architetto consiste nell’imparare a riconoscere le domande che nessuno ha ancora posto.

Conosci i tuoi numeri

Spingo continuamente gli architetti a quantificare. Non dirmi che ci sono tanti dati; dimmi quanti. Diecimila, dieci milioni, cento milioni, un miliardo? Sono architetture molto diverse. Non dirmi che l’integrazione gira spesso: ogni ora, ogni minuto, mille volte al secondo? Non dirmi che stiamo crescendo in fretta. Quanto in fretta?

Quando non ho un numero migliore, la mia base di partenza è una crescita del 30 per cento annuo. Non è una previsione; è uno strumento per forzare la discussione. Se qualcuno mi dice che oggi abbiamo 10 milioni di record, non voglio che la discussione si fermi a 10 milioni. Al 30 per cento l’anno arriviamo a circa 13 milioni l’anno prossimo, 17 milioni quello dopo, e intorno ai 22 milioni l’anno successivo. Ora parliamo del progetto. Se il business mi dice che il 30 per cento è ridicolo, benissimo: dammi il numero vero. Il punto è far entrare la crescita nella discussione sull’architettura.

Lo chiamo il Numero di Zeri di Steve (Steve’s Number of Zeros). Uno zero in più può cambiare completamente la tua architettura. Diecimila, centomila, un milione, dieci milioni, cento milioni: la funzionalità non è cambiata, e il requisito forse nemmeno, ma l’architettura potrebbe.

Ricordi gli appuntamenti del modulo 1? Mettiamoci i numeri reali. Oltre 1.200 sedi, 100 appuntamenti al giorno per sede, sei giorni alla settimana, circa 305 giorni l’anno. Sono oltre 36 milioni di appuntamenti nel primo anno. Ogni visita crea due record, quindi oltre 73 milioni di record. Ora conserva cinque anni di storico, con una crescita del 30 per cento l’anno, e si superano i 650 milioni di record. Stessa funzionalità, stesso requisito. Un paio di zeri in più, e un’architettura molto diversa.

Pianifica per domani

Una volta capito l’oggi, guardo avanti: cosa è ragionevolmente probabile che cambi? Il volume ne fa parte, ma domani non significa solo di più. Può anche significare diverso: più prodotti, business unit e paesi; requisiti di privacy diversi; nuovi canali e integrazioni; una fusione o un’acquisizione; una nuova strategia di dati master o una nuova piattaforma di analisi; un agente IA che consuma informazioni pensate solo per le persone.

Ecco perché mi importa tanto che l’architettura possa crescere per aggiunta anziché per continue modifiche. Se il business aggiunge un prodotto, il modello lo regge? Se un altro sistema ha bisogno dei dati, possiamo esporli in modo pulito? Se il volume fa un salto, abbiamo dove andare? Se la struttura del business cambia, dovremo smontare il modello dati? Non stiamo cercando di prevedere il futuro alla perfezione. Stiamo cercando di non chiuderci in un angolo.

Non costruire oggi il domani

Qui c’è un equilibrio. Pianificare per domani non significa costruire oggi il sistema di domani. Se abbiamo 100.000 record e fra cinque anni potremmo averne 100 milioni, non significa che costruiamo ora l’architettura da 100 milioni di record. Potrebbe portare costi e complessità di cui non abbiamo ancora bisogno.

La domanda a cui voglio una risposta è: l’architettura di oggi può evolvere in quella di domani? Se possiamo partire in modo semplice con una strada chiara davanti, spesso è meglio che pagare il costo della complessità con anni di anticipo. Il pericolo non è partire in piccolo. Il pericolo è partire da un punto da cui non si può andare da nessuna parte.

Pianifica per il guasto

Ora la parte di cui nessuno ama parlare: le cose si guastano. Non ho mai progettato un sistema in cui ogni componente restasse disponibile per sempre, ogni integrazione riuscisse, ogni utente inserisse dati perfetti e ogni sistema esterno si comportasse esattamente come documentato. Quindi non progettare quel sistema.

Chiediti cosa può guastarsi, poi chiediti cosa succede quando si guasta. Un’integrazione va in timeout. Un’API rifiuta una richiesta. Un caricamento notturno elabora 800.000 record e fallisce su 200.000. Un sistema di origine va giù. Un utente inserisce dati non validi. Un identificatore esterno compare due volte. Un sistema a monte cambia il formato di un valore senza cambiare il nome del campo. Un processo riesce in un sistema e fallisce in un altro. Non sono casi limite insoliti. È così che appare la produzione.

Anche un successo parziale è un guasto che devi capire

I guasti parziali sono particolarmente pericolosi nell’architettura dei dati. Immagina di spostare un milione di record, e il processo segnala di aver terminato. Ottimo. Ma ne è arrivato un milione, o 999.997, e quali tre mancano? Forse 200.000 sono falliti, alcuni sono stati creati due volte, oppure è arrivato tutto ma alcuni campi non hanno superato la trasformazione.

“Job completato” non è la stessa cosa di i dati sono corretti. Un architetto dei dati pensa alla riconciliazione: come sappiamo cosa sarebbe dovuto succedere, cosa è successo davvero, e la differenza? E cosa facciamo al riguardo?

Ecco cosa faccio quando i sistemi diventano complessi. I record vanno da A a B, da sinistra a destra. Poi B rimanda indietro qualcosa: una conferma per ogni record che ha ricevuto e salvato. Ora A può confrontare ciò che ha inviato con ciò che è stato confermato. Se ogni record ha la sua conferma, l’esecuzione è riuscita. Se mancano delle conferme, non è riuscita, qualunque cosa dica lo stato del job, e sappiamo esattamente quali record recuperare: riprovarli, passarli a una persona o lanciare un avviso.

Click to enlarge

Fallisci con eleganza

Quando un guasto si verifica, voglio sapere cosa fa dopo il sistema: se riprova, e se lo fa in automatico o no; cosa succede se la stessa transazione viene elaborata due volte; dove finiscono i record falliti, e se i record buoni continuano a scorrere oltre quello cattivo; chi riceve l’avviso, con quali informazioni, e come rielabora il guasto; e come fa un utente a scoprire che qualcosa è andato storto.

E soprattutto: possiamo ripartire senza peggiorare il problema? Una strategia di nuovi tentativi che crea dati duplicati non è granché come strategia di ripristino. Una buona architettura dà per scontato il guasto e ci offre una via del ritorno.

Monitora ciò che conta

Pianificare per il guasto senza monitoraggio non è davvero pianificare. Se un’integrazione fallisce alle 2 di notte e nessuno se ne accorge finché un cliente non chiama tre giorni dopo, non avevamo un’architettura operativa. Avevamo una speranza.

Decidi cosa deve essere osservabile: il processo è partito, quanto è durato, quanti record sono stati elaborati, quanti sono riusciti e quanti falliti? I volumi sono improvvisamente diversi dal normale? Il backlog sta crescendo, gli errori stanno aumentando? L’architettura non finisce quando il deployment riesce. Domani qualcuno dovrà gestire questo sistema, e anche questo fa parte del progetto.

Pensa in tutte e tre le direzioni

Continua ad applicare le tre lenti per il resto del corso. Quando progettiamo un modello dati: funziona oggi, può crescere domani, e cosa succede quando i dati sono sbagliati o incompleti? Un’integrazione: sposta i dati di oggi, regge i volumi e i sistemi di domani, e cosa succede quando una delle due parti è giù? Grandi volumi di dati: cosa abbiamo oggi, dove stanno andando i numeri, e come ripartiamo quando un’operazione grande riesce solo in parte?

La tecnologia cambia da un capitolo all’altro. Le domande no.

L’architettura esiste nel tempo

Uno sviluppatore a volte può guardare un requisito e chiedersi: “Funziona?”. L’architetto deve chiedersi di più: funziona oggi, funzionerà ancora domani, e cosa succede quando non funziona affatto? Queste tre domande ci portano oltre l’implementazione, dentro la vita del sistema.

Non prevederai ogni requisito futuro né eviterai ogni guasto. Non è questo l’obiettivo. L’obiettivo è costruire qualcosa di adeguato a ciò che sappiamo oggi, lasciarci un posto dove andare domani, e avere un piano per quando la realtà non collabora.

Costruisci per oggi. Pianifica per domani. Pianifica per il guasto. Useremo queste tre lenti ancora e ancora.

Cosa decide qui un architetto

• Quali sono i volumi e la crescita reali, e quali numeri cambierebbero il progetto.
• Quali requisiti impliciti il business non ha ancora espresso.
• Come il progetto di oggi può evolvere in quello di domani, senza costruire oggi il sistema di domani.
• Cosa succede quando qualcosa si guasta: ripristino, riconciliazione e monitoraggio.