Un assessment architetturale non serve a decidere cosa fare. Serve a stabilire da dove si parte, con abbastanza precisione da poter discutere un preventivo.
È la parte che viene saltata più spesso, perché costa qualche giornata e non produce niente di visibile. Poi il progetto parte, e a metà si scopre che l'integrazione che tutti davano per esistente è un export notturno in CSV, che il campo su cui si fondano tre report è compilato a mano nel 40% dei casi, e che il modello di permessi non regge il caso d'uso che era la ragione del progetto. A quel punto il preventivo si riapre, e la posizione negoziale è la peggiore possibile: avete già firmato.
Le cinque cose che deve contenere
Se una di queste manca, il documento non è finito. Non è una questione di stile: sono le cinque aree da cui esce la stima dei giorni.
1. Il modello dati, com'è, non come dovrebbe essere
Quali oggetti esistono, quali campi sono effettivamente popolati e con che percentuale, dove ci sono duplicati e quali relazioni sono state costruite per aggirare un limite invece che per descrivere il business. Un modello dati disegnato tre anni fa e mai più toccato non è un problema; un modello dati che nessuno sa più spiegare, sì.
2. Le integrazioni reali
Non l'elenco dei sistemi collegati: l'elenco di come sono collegati. Chiamata sincrona, coda, batch notturno, file su un server, persona che copia e incolla. La differenza fra un'API e un CSV schedulato non è tecnica, è una differenza di mesi sul piano di progetto, e in una slide di architettura sono entrambi una freccia.
3. Chi vede cosa
Il modello di accessi è la parte che fa saltare i progetti AI più di qualunque altra, perché un agente eredita i permessi di chi lo interroga e li rende improvvisamente visibili. Un assessment serio dice quali profili esistono, quali condivisioni sono state aperte per necessità e mai richiuse, e cosa succede quando un modello linguistico legge quei dati. Se questa sezione non c'è, chiedetela prima della firma, non dopo.
4. Il debito tecnico, quantificato
Automazioni sovrapposte che fanno la stessa cosa in tre modi diversi, codice senza test, personalizzazioni che bloccano gli aggiornamenti della piattaforma. Il debito non va eliminato: va misurato, perché è quello che trasforma una stima da dieci giorni in una da venticinque. Un documento che dice "presente debito tecnico" senza dire quanto e dove non vi ha detto niente.
5. I vincoli che non si spostano
Finestre di rilascio, dipendenze da altri programmi in corso, persone che esistono in un solo esemplare, requisiti di conservazione dei dati. Sono i vincoli a determinare l'ordine delle cose, e l'ordine determina il costo più di quanto lo determini la tecnologia scelta.
Come si riconosce un assessment vero
La distinzione più utile è questa: un assessment descrive lo stato attuale, una proposta descrive una soluzione. Se aprite il documento e trovate subito un'architettura target, un diagramma con il nome di un prodotto al centro e una stima, state leggendo una proposta.
Tre controlli rapidi, tutti verificabili senza competenze tecniche:
- Cerca le ipotesi. Un assessment onesto elenca cosa ha assunto senza poterlo verificare. Se non ci sono ipotesi dichiarate, o hanno verificato tutto — improbabile in quattro giornate — oppure le ipotesi ci sono ma non ve le hanno scritte.
- Cerca le esclusioni. Cosa non è stato guardato, e perché. L'assenza di una sezione di esclusioni è il segnale più affidabile che il documento serve a vendere la fase successiva.
- Cerca i numeri sgradevoli. La percentuale di compilazione di un campo critico, il numero di automazioni duplicate, quante persone hanno accesso a un oggetto che non dovrebbero vedere. Un assessment che non contiene nessun dato imbarazzante non ha guardato abbastanza a fondo.
Quando non serve
Non tutto merita un assessment, e dirlo prima fa risparmiare più di quanto faccia risparmiare l'assessment stesso.
- Il perimetro è un solo processo, su un solo sistema, che una persona in azienda conosce a fondo. Parlate con quella persona.
- L'org è nuova, con pochi mesi di vita e nessuna personalizzazione. Non c'è ancora niente da valutare.
- La decisione non è ancora presa. Prima serve capire se ha senso muoversi: quella è la domanda di un readiness assessment, e viene prima.
- Il budget totale è tale che quattro giornate di analisi ne mangiano una quota sproporzionata. In quel caso il rischio si accetta e si contiene con un perimetro piccolo.
Cosa ci fate, dopo
Il valore di un assessment non è il documento: è che d'ora in poi tutti discutono sugli stessi fatti. Serve a chiedere a due partner diversi un preventivo sulla stessa base e poterli confrontare davvero, a riconoscere la voce gonfiata quando la vedete, e ad avere una risposta quando in comitato qualcuno chiede perché costa così.
Se il documento non vi mette in condizione di fare quelle tre cose, non avete comprato un assessment. Avete comprato quattro giornate.
Domande frequenti
Quanto dovrebbe durare un assessment architetturale?
Tre o quattro giornate di lavoro per un perimetro definito: una org, i sistemi che ci parlano, il modello dati e gli accessi. Se ve ne propongono venti, o il perimetro è molto più largo di quello che vi serve, o l'assessment sta finanziando la fase di apprendimento del fornitore sul vostro budget. Se ve ne propongono mezza, state comprando una checklist compilata in call.
Serve se abbiamo già scelto la tecnologia?
Serve soprattutto allora. La scelta della piattaforma decide il "cosa"; l'assessment decide se il "come" regge: quali dati vanno migrati e in che stato sono, quali integrazioni vanno rifatte, quali autorizzazioni vanno ridisegnate e quanto tempo interno serve. È la differenza fra un preventivo stimato e un preventivo difendibile.
Può farlo il partner che poi implementa?
Può, e spesso lo fa bene sul piano tecnico. Il punto non è la competenza, è l'incentivo: chi scrive l'assessment decide anche l'ampiezza del progetto che seguirà. Se lo fa lo stesso soggetto, chiedete almeno che il documento elenchi le ipotesi e le esclusioni in modo esplicito, così restano verificabili da qualcun altro.
Che differenza c'è con un readiness assessment?
Il readiness assessment guarda l'organizzazione: processi, responsabilità, competenze, qualità dei dati, e se esiste un caso d'uso che regge. L'assessment architetturale guarda i sistemi: modello dati, integrazioni, accessi, debito tecnico. Il primo risponde a "siamo pronti", il secondo a "su cosa poggiamo". Se dovete sceglierne uno solo, di solito viene prima il readiness.
Approfondimenti
- Architecture & Data Assessment - la versione che faccio io, con perimetro e prezzo.
- Cosa chiedere a un partner prima di firmare
- Perché falliscono i progetti Salesforce AI
A volte il consiglio migliore che posso darvi è che l'assessment non vi serve. Anche quello è un risultato.