Il Bit del Mercoledì
Non tutti i contenitori sanno contenere le stesse cose
Ci sono domande che sembrano tecniche e invece sono semplicissime, se le guardiamo dalla parte giusta. Una di queste è: “Perché non riesco a scrivere l’elenco delle manutenzioni dentro il modello digitale dell’edificio?”
Per rispondere, non serve sapere niente di informatica. Basta un’idea che conosciamo tutti benissimo dalla vita di tutti i giorni: non tutti i contenitori sono fatti per contenere le stesse cose.
Un cassetto va bene per le posate. Non va bene per un liquido: ci vuole una bottiglia. Una bacheca va bene per attaccare un foglio. Non va bene per tenere insieme cento fogli in ordine: ci vuole un raccoglitore. Ogni contenitore ha una forma, e quella forma decide cosa può stare dentro e cosa no.
I dati funzionano allo stesso modo. Non tutti i dati hanno la stessa forma, e non tutti i “contenitori digitali” sanno accogliere ogni forma di dato.
Proviamo a distinguere tre forme di dato, dalla più semplice alla più complessa.
- La prima forma: il dato singolo. È un’informazione che ha una sola risposta possibile in un dato momento. “Di che materiale è fatta questa parete?” Cemento armato. “Quanto è spessa questa porta?” Quattro centimetri. Una domanda, una risposta. Questo è il tipo di dato più facile da gestire, ed è anche quello che praticamente tutti i modelli digitali di edifici sanno trattare senza problemi.
- La seconda forma: l’elenco. È un’informazione che, per sua natura, non ha una sola risposta ma tante, e quelle tante crescono nel tempo. “Quali manutenzioni sono state fatte su questo impianto?” Non è una risposta, è una lista che si allunga ogni volta che qualcuno interviene: una riga il 12 marzo, una il 30 giugno, una il 15 settembre, e continuerà ad allungarsi negli anni a venire. Qui il contenitore “una domanda, una risposta” comincia a scricchiolare: non è progettato per tenere insieme più righe collegate fra loro, con le loro date, i loro responsabili, i loro dettagli.
- La terza forma: il collegamento a qualcosa che vive altrove. È il caso in cui l’informazione non sta nemmeno tutta nello stesso posto. Pensiamo all’anagrafica dei fornitori che fanno manutenzione: quei dati vivono nel gestionale dell’azienda, non nel modello dell’edificio. Il modello dovrebbe solo “sapere” a quale fornitore rivolgersi, senza doverne copiare dentro tutte le informazioni. È come quando, invece di riscrivere tutta la rubrica del telefono su un foglietto, ci basta un numero di richiamo: “per i dettagli, chiedi a quell’altro elenco”. Questa è la forma più difficile da far stare in un contenitore semplice, perché richiede che due sistemi diversi si parlino.
Il file che oggi usiamo per scambiarci i modelli digitali degli edifici si chiama IFC ed è stato pensato benissimo per la prima forma di dato, quella del “una domanda, una risposta”. Ed è per questo che funziona così bene quando descrive materiali, misure, caratteristiche tecniche. Ma quando gli chiediamo di reggere la seconda forma, l’elenco che cresce, o la terza, il collegamento con altri sistemi, gli stiamo chiedendo qualcosa che non rientra nella sua forma naturale. Non perché sia fatto male: semplicemente, come il cassetto con il liquido, non è quello lo scopo per cui è nato.
Ecco perché, quando un edificio deve essere seguito nel tempo (manutenzioni che si accumulano, fornitori che cambiano, interventi che si susseguono) non basta un unico file, per quanto ben fatto. Serve qualcosa che sappia gestire anche la seconda e la terza forma di dato: un sistema capace di tenere elenchi che crescono e di dialogare con altri archivi. Il file resta prezioso come punto di partenza e di riferimento, ma da solo non può portare tutto il peso della vita di un edificio.
E qui si apre una domanda che vale la pena tenersi in tasca: se un solo contenitore non basta a tenere insieme tutta l’informazione di un edificio, chi decide quale pezzo di informazione sta in quale contenitore e chi si ricorda, con il passare degli anni, dove sono finiti tutti i pezzi?