Pensare come un architetto
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)
Modulo 1 di 7 del capitolo Pensare da Data Architect, il primo capitolo del corso Data Architect. Ogni modulo si regge da solo. Precedente: la panoramica del capitolo · Successivo: Il modello dati è lo scheletro
La domanda a cui risponde questo modulo: Qual è la differenza tra costruire e progettare un’architettura, e cosa fa davvero un architetto?
Per gran parte della mia carriera sono stato uno che costruisce.
Ho cominciato come sviluppatore. Ho lavorato in Java e .NET prima di passare a Salesforce, e ho passato anni a progettare sistemi, scrivere codice, integrare piattaforme, formare architetti e rivedere architetture.
Ma una delle lezioni più importanti che ho imparato lungo la strada è che essere un ottimo costruttore ed essere un ottimo architetto non sempre coincidono.
Chi costruisce si chiede:
Come lo costruisco?
Un architetto deve porsi domande diverse:
Dovremmo costruirlo?
Perché lo stiamo costruendo in questo modo?
Quali sono le alternative?
Cosa succede quando diventa più grande?
Cosa succede quando si guasta?
E quale decisione stiamo prendendo oggi su cui, fra tre anni, vorremmo aver riflettuto di più?
Ricordo un progetto per un’azienda retail che gestiva appuntamenti. Ho chiesto: quanti appuntamenti al giorno per negozio? Poi: quanti negozi avete? E quanti giorni alla settimana siete aperti? In fretta ho capito che avremmo avuto milioni di appuntamenti solo nel primo anno. Sono queste le domande che un architetto pone all’inizio di un progetto.
Questo cambio di mentalità è ciò di cui parla davvero questo corso.
La persona che tiene il progetto
Sezione intitolata “La persona che tiene il progetto ”Ho usato questa analogia molte volte formando architetti.
Immagina un cantiere. C’è chi getta il calcestruzzo, chi stende l’impianto elettrico, chi installa l’idraulica, chi alza le pareti, e decine di altri lavori specializzati. Queste persone devono essere molto brave in ciò che fanno.
Ma qualcuno deve anche tenere in mano il progetto.
Quella persona deve capire come tutti quei pezzi si incastrano. Deve accorgersi quando qualcosa che succede in una parte del progetto crea un problema da un’altra parte.
Questa è l’architettura.
Nella tecnologia a volte commettiamo l’errore di pensare che l’architetto sia semplicemente chi ne sa di più. Non è proprio così. Conoscere la piattaforma conta. Serve profondità tecnica. Ma l’architettura non è un quiz.
Il compito dell’architetto è prendere buone decisioni, a volte con informazioni incomplete e requisiti in conflitto, e capire le conseguenze di quelle decisioni.
È un’abilità molto diversa.
Non limitarti a prendere il requisito
Sezione intitolata “Non limitarti a prendere il requisito ”Una delle prime abitudini che voglio che un architetto sviluppi è semplice:
Chiedi perché.
Qualcuno ti dice:
Ci serve un altro oggetto.
Perché?
Ci serve questo campo copiato sull’Account.
Perché?
Ci serve che tutti questi dati siano memorizzati in Salesforce.
Perché?
Non significa fare il difficile. Significa capire il vero requisito di business invece di implementare subito la soluzione proposta.
Spesso un requisito arriva travestito da soluzione.
“Ci serve un nuovo oggetto personalizzato” non è necessariamente un requisito. Il requisito potrebbe essere in realtà “dobbiamo tracciare questa informazione separatamente”. Non sono la stessa cosa.
Una volta capito il vero requisito, puoi iniziare a esplorare le alternative. Forse un nuovo oggetto è esattamente la risposta giusta. Forse l’informazione appartiene a qualcosa che esiste già. Forse Salesforce non dovrebbe possedere affatto quei dati.
L’architetto deve separare ciò di cui il business ha bisogno da un modo proposto per ottenerlo.
Stavamo lavorando a un’applicazione di vendita, e il cliente aveva più approvazioni, ognuna con un approvatore e una data. La prima richiesta era aggiungere Approvatore 2 e Approvatore 3, ognuno con la sua data, come campi sull’Opportunità. Scavando, abbiamo capito che potevano essercene più di due o tre. Così abbiamo spostato le approvazioni in un oggetto figlio. La richiesta era di avere più campi; il requisito era tracciare ogni approvazione, per quante fossero.
Pensare oltre il requisito
Sezione intitolata “Pensare oltre il requisito ”Da “chiedi perché” discendono due abitudini, e ognuna ha un suo modulo più avanti in questo capitolo.
Di solito c’è più di una risposta. Salesforce ci offre molti modi per risolvere un problema, e alcuni sono sbagliati quasi subito. Scegliere tra quelli che funzionano è l’arte dei trade-off (modulo 4).
E i requisiti che ti vengono dati non sono tutti i requisiti che hai. Nessuno dice “assicurati che funzioni quando il caricamento notturno riesce solo a metà”, ma è comunque un requisito. Guardo ogni progetto attraverso tre lenti: costruisci per oggi, pianifica per domani, pianifica per il guasto (modulo 5).
Pensa a chi incarica un architetto di progettare un edificio. Non chiede un allarme antincendio o un impianto sprinkler, né che l’edificio resti in piedi durante un terremoto. Lo dà per scontato come parte del lavoro, senza chiederlo. Il nostro mondo funziona allo stesso modo. Nessuno chiede una gestione degli errori elegante, i log o un modo per ripartire quando qualcosa si guasta. Sta all’architetto sapere quali di questi sistemi appartengono al progetto, e inserirli.
Rendi visibile il tuo ragionamento
Sezione intitolata “Rendi visibile il tuo ragionamento ”Un architetto non dovrebbe semplicemente entrare in una stanza e annunciare: “Facciamo così”.
Il tuo compito è anche spiegare perché. Voglio che gli stakeholder capiscano le alternative che abbiamo considerato e i trade-off in gioco. Non significa consegnare a un dirigente un documento di progetto di 40 pagine. Significa saper spiegare la stessa architettura a uno sviluppatore, al business e a un dirigente: conversazioni diverse sulla stessa decisione.
E il modo per farlo è con progetti e istruzioni chiari, come la persona che tiene il progetto in cantiere. Per un Data Architect, uno dei progetti più importanti è il modello dati.
Se nessuno capisce perché è stata presa una decisione, è molto probabile che prima o poi qualcuno la annulli. E potrebbe avere ottime ragioni per farlo, perché nessuno ha mai spiegato la decisione originale.
L’architetto non deve costruire tutto
Sezione intitolata “L’architetto non deve costruire tutto ”C’è un’altra transizione che può essere difficile, soprattutto per chi arriva all’architettura dallo sviluppo.
Non devi costruire tutto in prima persona.
Mi piace ancora capire come funzionano le cose a un livello molto tecnico, e quelle basi contano. Ma da architetto la tua responsabilità diventa più grande della tua implementazione. Non devi costruire tutto; devi sapere come dare a chi costruisce la direzione giusta e i parametri giusti. Questo significa capire abbastanza da guidare il loro lavoro, da riconoscere quando un’implementazione proposta crea un problema architetturale, e da muoverti tra i dettagli e il quadro generale.
A volte significa scendere a fondo in una query, un’API o un modello dati.
A volte significa fare un passo indietro e chiedersi se dovremmo fare tutto questo, in primo luogo.
E sempre più spesso, a costruire non sono solo le persone. Con l’IA, l’architetto può lavorare direttamente con lo strumento che genera gli oggetti, il codice e le schermate. Allora la direzione, i parametri e le linee guida vanno all’IA, e darli bene diventa sempre più responsabilità dell’architetto. Ci torneremo nel modulo 7.
Fa parte del percorso da costruttore ad architetto.
Il tuo compito è prendere decisioni
Sezione intitolata “Il tuo compito è prendere decisioni ”In fondo, l’architettura riguarda le decisioni.
Alcune decisioni sono facili da cambiare. Altre no.
Un layout di pagina si può cambiare. Un’etichetta si può rinominare.
Ma scegli il modello dati fondamentale sbagliato, pubblica identificatori da cui decine di sistemi iniziano a dipendere, o metti la copia master di dati critici nel posto sbagliato, e cambiare idea diventa molto più costoso.
Queste sono decisioni architetturali. Ed è proprio su questo tipo di decisioni che si concentra questo corso.
Come Data Architect prenderai decisioni su come sono strutturate le informazioni, dove risiedono, come crescono, come si muovono, chi può accedervi e come il resto dell’azienda le comprende.
La tecnologia conta.
Ma conoscere ogni funzionalità di Salesforce non è l’obiettivo.
L’obiettivo è sviluppare il giudizio per sapere quale strumento usare, quando usarlo, a cosa stai rinunciando e cosa succede dopo.
Questo è pensare come un architetto.
E ora possiamo iniziare a pensare da Data Architect.
Cosa decide qui un architetto
Sezione intitolata “Cosa decide qui un architetto ”- Se una richiesta è un vero requisito, o una soluzione proposta per soddisfarlo.
- Quali domande porre prima di costruire qualsiasi cosa: dovremmo farlo, perché in questo modo, cos’altro potremmo fare, cosa succede quando cresce o si guasta.
- Quali decisioni spettano all’architetto e quali a chi costruisce; e quale direzione e quali parametri dare a chi costruisce, persone o IA.
- Come spiegare una decisione in modo che uno sviluppatore, il business e un dirigente la capiscano ciascuno.