Oltre il BIM

Quanti, fra i lettori di questo articolo, sono titolari di uno SPID? Il “Sistema Pubblico di Identità Digitale” è solo uno dei tanti tentativi e iniziative di digitalizzazione oggi in corso a livello nazionale. Con uno SPID, molti siti istituzionali forniscono accesso ai propri servizi con una stessa combinazione nome utente/password. SPID mi ha permesso di entrare, dopo tanti anni, nel sito INPS e di smettere di chiedermi dove fosse “la seconda parte del PIN” o dove fosse necessario richiederlo.

Da poco l’Agenzia delle Entrate e diversi comuni si sono adeguati, e, di fatto, oggi entro a Roma (famigerata, ma non per il tema Open Data grazie al lavoro di Flavia Marzano) in Agenzia o in INPS con credenziali “generiche” di cittadino, anche se ottenerle non è semplicissimo né immediato. E lo stesso vale per altri servizi alla persona o alle imprese. Il 2019 è anche l’anno della fatturazione elettronica e confesso che il Sistema di Interscambio, pur nell’entusiasmo di poterlo sperimentare in passato, mi ha spesso messo di fronte a una compilazione eufemisticamente “farraginosa”, ora, del resto, già migliorata.

Lo stupore verso il successo di certi processi digitali è di sicuro patrimonio di pochi, si dice. L’”uomo della strada” vuole solo che le cose funzionino! La mia esperienza, tuttavia, dice il contrario, e la chiave sta proprio nella percezione personale: l’abolizione delle mediazioni tecniche, la disponibilità immediata di alcune funzioni, dati che siano i propri, accessibili, agibili. Del resto, dietro molta innovazione ci sono stati atti politici, cessioni di autorialità, aperture di software provenienti da settori come quello militare. Basti pensare, avvicinandoci al nostro, all’apertura per mano di Google di Kehyole, applicazione aerospaziale poi diventato Google Earth che proprio sul Giornale dell’Architettura documentammo all’epoca.

Per un “entusiasta digitale”, del resto, vedere per la prima volta i propri dati nella Dichiarazione Precompilata è stato emozionante. È ovvio che l’entusiasmo si consolida quando i dati si fanno seri, utili e, di conseguenza, sensibili. C’entra probabilmente un senso di possesso, di potere guadagnato. Simmetricamente, tuttavia, i medici lamentano di dover spendere parte della propria attività a “immettere dati”: in modo più colto, “digitalizzare”.

Ma sono immersi, ormai, in una digitalizzazione strumentale, a livello diagnostico e operativo, in cui anche la ricerca ha fortissime componenti “di calcolo”. Proprio a un convegno sul BIM, anni fa, il relatore che mi ha seguito era un compententissimo e attivissimo odontotecnico, intento a mostrare le sue attività di ricostruzione di arcate dentarie, che noi definiremmo “CAD-CAM”, basate su accurate “scansioni dell’esistente”.

L’esperienza del Team per la Trasformazione Digitale

Il “Team per la Trasformazione Digitale” è un gruppo istituito presso la Presidenza del Consiglio dei Ministri nel 2016 (confermato per ora anche dall’attuale governo), che ha lavorato in questo milieu non soltanto in termini prescrittivi, ma con un approccio che “mette le mani nel codice” e senza partire da zero, uno dei mali atavici del digitale “istituzionale”: ogni volta che un bando pubblico, regionale, nazionale o comunitario, propone un finanziamento, ad esso spesso corrisponde una “piattaforma” sviluppata ad hoc, magari con tecnologie Open Source, ma fatalmente e inderogabilmente autoreferenziale. Apribile certo, ma mai completamente a disposizione. Di nuovo, problemi politici, nel senso più ampio del termine.

In questo senso, il primo coordinatore del Team (tecnico, ma con impatto mediatico in quanto ex-Amazon) Diego Piacentini ha chiarito in un’intervista recente un approccio “light”, che combina strumenti sviluppati con l’attenzione massima al riuso e al dialogo con il lavoro delle istituzioni o delle Agenzie, dalla SOGEI all’AGid, per citarne solo due. Con il forte, annoso e sempre presente problema degli standard, e un approccio bottom-up: “dall’utente in su”. Tra i punti chiave ci sono quello della guida (i quattro progetti attivi all’epoca erano fermi “per assenza di guida chiara”: di nuovo quindi, un atto politico) e quella del recruitment dei talenti, a tempo, per due, massimo tre anni. In un ambiente in qualche modo strutturalmente lento.

Perché iniziare parlando di digitalizzazione?

Il “Giornale dell’Architettura” chiede di fare un punto, di capire qualcosa del BIM e dei processi che gli ruotano intorno, o lo sfiorano, delle persone che ci lavorano, ne parlano, tentano di capirlo. In Italia, innanzitutto, ma con un inevitabile sguardo internazionale.

Il Giornale è stato pioniere di questa curiosità, di questa ricerca, non tanto o non soltanto con la pagina di Informatica, ma con il suo atteggiamento complesso verso il progetto di architettura, le sue premesse e i suoi esiti, che volevano innanzitutto romperne (o prevenirne) l’isolamento. Sguardo che però non voleva in nessun modo togliergli prerogative, ma, anzi, riconfigurarne le responsabilità.

L’indagine del mondo digitale è sempre partita strettamente dalla capacità operativa, dallo sviluppo, per indagarne la strumentalità all’atto progettuale. Escludendo, per statuto e da sempre, ogni separazione tra “processo” e strumento che lo incarna, tra forma e contenuto. Un’abolizione alla radice di ogni rischio di approccio “utensile”.

I membri del Team per la Trasformazione Digitale sono stati definiti da alcuni “i missionari”.

Anche qui c’è un rischio da evitare, nella diffusione digitale: quello della ricerca del “superuomo”, quello che possa farsi carico di tutte le innovazioni digitali e diventare collettore (o collo di bottiglia) dei processi.

La “figura specialistica”, a maggior ragione in un mondo faticoso da capire, è un rischio le cui conseguenze analizzammo sulle pagine del Giornale, descrivendo e incontrando i “Computational Group” nati nelle grandi strutture di New York: CRAFT, quello di Buro Happold, che tra i propri membri vedeva quel Ian Keough, nato come sviluppatore libero di codice, confluito nel plug-in Dynamo e oggi, pur restando spirito libero, lavora con Autodesk, come, simmetricamente, con Robert McNeel and Associates lavora David Rutten, il giovane laureato di Delft che iniziò a sviluppare “Explicit History”, oggi “Grasshopper”.

La formazione di tali gruppi è stata in qualche modo sintomo di arretratezza di una situazione che tenta di confinare l’innovazione.

Se quindi i giovani “computational designer” (che la norma UNI oggi definirebbe probabilmente “BIM Specialist”) hanno sofferto nel tempo di marginalizzazione, specialmente in strutture come quelle di ingegneria sottoposte a un rigido controllo di gestione, non si può trascurare quanto il digitale sia una cultura operativa, di azione, che non può non fondarsi sul saper fare, sul software come linguaggio, come cultura diffusa.

“Le mani nel codice” significa l’assoluta centralità e necessità del lavorare “nel mezzo” e non “con il mezzo”. Di fare del digitale un medium, come più volte sottolineato Greg Lynn. Lo stesso Lynn che ha messo in guardia in tempi non sospetti da un altro grosso rischio dell’ambiente digitale, l’“attesa del futuro”. Ne parla nell’introduzione alla serie di mostre “Archaeology of the Digital” al CCA di Montreal, in cui mostra progetti compiuti che hanno reso espressivi, in architetture realizzate, i “limiti” tecnici del tempo. Senza aspettare che qualcosa arrivasse da una magica scatola nera che “ha da arrivare”.

Qualche esperienza italiana

L’Italia, in questo senso, è un territorio strano. Conflittuale, poco trasparente per definizione, storia e statuto, “familistico e amorale”, individualista, affetto da logiche consortili, da cui non è esente nemmeno l’ambiente BIM. Ed è stato, per molte società software soprattutto internazionali, terreno di vendita e non di sviluppo, in cui l’infausta separazione tra “tecnici” e “commerciali” è stata per molto tempo sbilanciata sul secondo fattore.

Ma, proprio in Italia, simmetricamente e in analogia ad altri settori industriali, hanno anche agito in modalità asincrona e indipendente tante realtà di sviluppo software “artigianali”, legate spesso al mondo diffuso della professione e con una fortissima connotazione operativa. Sintomatica, in questo senso, è la storia della ACCA Software, forse una delle più radicate nel tessuto diffuso dei professionisti italiani, che nasce non a caso proprio da radici numeriche, dal software di computo, il primo costruito, per se stesso, artigianalmente dal fondatore Guido Cianciulli. Una commistione diretta tra professione e sviluppo software, che richiama gli anni eroici del Basic, del codice “nudo”, del software come “azione”, non come mediatore. E ovviamente tutta la tradizione degli anni novanta dei software di rete, di Linux, dai BBS alle reti civiche. Mondo di cui l’hacker è la punta, ma il tessuto diffuso è l’humus dei PC assemblati, delle macchine malleabili e aperte alla sperimentazione. Un digitale che abitua al lavoro sul corpo vivo, diretto e immediato, partito dall’epoca personale e di lì avanzato, dal PC al FAB di Neil Gershenfeld.

Fuori dalla comfort zone

Proprio il software “mediatore”, potente e sempre più disponibile, è dunque il rischio, già esperito e digerito dall’esperienza dei gruppi computazionali. Nell’epoca dell’abolizione dell’attesa, che ha fatto lanciare (e ora rimuovere) la “Instant Search” di Google, della scrittura diretta che non ha “brutta e bella” dei word processor ma che lavora sul testo vivo, ambienti confortevoli, autoreferenziali e chiusi (spesso per comprensibilissime ragioni commerciali) rischiano di mettere troppo a proprio agio gli attori, di chiudere i giovani, (ovviamente gioventù “mentale”, innanzitutto, come dimostrano personalità come lo storico Robert Aish) dentro a una nuova “comfort zone”, che gli esempi statunitensi e internazionali dimostrano avere vita breve. Basti pensare a nomi eroici della stagione del digitale (e già passati, come Lynn ha intelligentemente sottolineato) come lo studio newyorchese CASE, tra le più note e progressive “società di consulenza BIM” fatta da architetti, che è confluita in WeWork, il colosso del co-working, uscendo dal mondo, presto limitante, dello “strettamente software” ed entrando in un’attività più ampia, dove tra l’altro e non a caso la progettazione stessa degli spazi è legata a operazioni immobiliari e organizzative più ampie.

Lo sanno bene, questo, i ragazzi che nel tempo ho formato e che vedo sempre con piacere protagonisti della scena in Italia insieme ad altri in gruppi come il BUG (BIM User Group), e che ho sempre e costantemente spinto ad uscire dalle proprie comfort zone e guardare oltre. A maggior ragione quando ci sono forti talenti, emersi, anche ad Architettura, quando si fornisce il contesto giusto per svilupparsi. E che va alimentato di continuo per evitare che nello sviluppo autoreferenziale della tecnica, e nella europea separazione tra le due culture “cresca il deserto”, per richiamare una felice espressione di un altro dei nostri pionieri, Bernard Cache, in un testo che richiamava alle proprie responsabilità noi europei e la nostra atavica resistenza (o, per molti utile resilienza) alle competenze innovative che, quando lo sono, devono essere problematiche, non pacificano, non possono farlo.

Chiedono nuovi spazi operativi, che vanno capiti e definiti inizialmente nel mondo accademico, della ricerca e della formazione, per permettere ad architetti, ingegneri e sviluppatori software di sviluppare le proprie curiosità reciproche. E noi architetti, in questo senso, possiamo aprire molte strade e aiutare il processo con la forma mentis, non avendo però, noi per primi, timore di “perdere la nostra specificità” o di “allontanarci dall’incarico”. L’amalgama deve cambiare, e probabilmente non basta “un consulente” a farlo. Sembra strano a dirsi, ma proprio ai nostri talentuosi giovani va insegnato a perdere e cedere immediatamente il proprio acquisito potere, le strutture appena definite devono scardinarsi. Pena, un ingessamento imperdonabile.

Apertura contro l’autoreferenzialità

Del resto, proprio i leader sviluppatori che si inseguono su tutte le piattaforme condividono, sviluppano, aprono, soprattutto, ma non solo, nella “produttivista” cultura statunitense. Un’apertura di cui tutti gioviamo, ma che spesso è difficile da trovare in molti altri. La cultura software avanzata fa ancora fatica a diffondersi nel mondo AEC (Architecture Engineering Construction), spesso troppo eterodiretto. Ma proprio loro, da Ian a Nathan Miller, a tanti altri, ci fanno intravedere un metodo. Rischioso, ma unica àncora in un mondo che cambia troppo velocemente. Chi ricorda la vicenda di “Generative Components”, che dominava la scena prima di Grasshopper? E di cui io per primo, con i ragazzi anni fa, subimmo il fascino e ci lanciammo?

Un altro rischio, infatti, è che dietro a molte, faticose e costose implementazioni, si arrivi a un’operazione gattopardesca, in cui “tutto cambia perché nulla cambi”, nel senso che i ruoli nel processo non vengono nella sostanza mutati. Quanti studi, dopo l’adozione del BIM, hanno cambiato la propria “forma professionale”, anche senza arrivare agli estremi di CASE? E quanti altri invece, sono caduti nel tema del “gruppo computazionale”? O del “giovane talentuoso”? Le figure, oggi codificate, del BIM Manager, Coordinator o Specialist a che strutture appartengono? Il bilancio tra sviluppo software, cultura che sappiamo necessaria, e rischio di una sua chiusura, di codici avanzati che in pochi possono usare e ri-usare, è difficile e ha bisogno di un’apertura per non diventare autoreferenziale. E un aiuto viene di nuovo dall’evoluzione software, dal fiume globale che aiuta a rompere ogni ingessatura.

Un punto chiave: la questione del digital ecosystem

C’è in corso un’inversione di rotta, uno specchio che trasforma l’autore in produttore, per dirla con Walter Benjamin, ma che sostanzialmente rende i produttori di BIM “produttori di materia prima”. Oggi artigianale, frutto di faticose ore di lavoro, ma in futuro, anche in vista del dialogo con le scansioni 3D, sempre più convertita con sistemi di intelligenza artificiale e modificata. Di nuovo, il settore impiantistico e industriale sta guardando avanti, grazie alla maggiore “linearità” di strutture e geometria. E può fare da motore, come la forma complessa ha fatto per tutta la ricerca di geometria computazionale applicata alla produzione. Anche in questo tema esiste una lunga archeologia di esperienze di BIM “mittente e destinatario”: dall’infrastruttura Excel-based della torre Swiss Re, fino ai lavori di modellazione comparata per la torre alla Défense di Morphosis.

Materia prima per cosa? Per sistemi di gestione, web based e condivisi, che riportino a sintesi il modello. Sempre per riferirsi alle recenti cristallizzazioni normative, al “Common Data Environment”, tradotto in “Ambiente di Condivisione Dati”, ACDat, che troppo spesso è soprattutto uno “spazio di scambio file” più o meno evoluto. Questione però giustamente definita centrale da molti esperti anche italiani di recente, nel presentare il faticoso e comunque prezioso lavoro di istituzionalizzazione dei molti concetti del mondo BIM, che, entrati in normativa, senz’altro hanno ora una corsia preferenziale preziosissima per allocare budget, costruire competenze necessarie nelle gare e offrire una sponda a tutta l’innovazione che vuole e deve farsi spazio nel mondo della pratica professionale.

La questione del “digital ecosystem” fu identificata come cruciale già da John Frazer, altro nome chiave dell’innovazione digitale, quando GehryTechnologies lo coinvolse e fu lui a scegliere tale definizione per il suo ruolo, descrittoci quando lo incontrammo a Torino per il Giornale. E uscì fuori il tema delle datastructures.

Quale sia però la forma che tali sistemi debbano avere, quali professionalità debbano alimentarle, mette in campo i problemi della forma professionale (e di molta innovazione lì dentro confinata), dell’impossibilità di formare in tempo generazioni di super-uomini, pronti per il futuro che “ha da venire”. Ma che allo stesso tempo necessita di sviluppo, e quindi di una formazione che non può essere “sul processo”, se non è computazionale. A meno che non vogliamo, noi italiani, restare a guardare il fiume dalle rive. O non tentare di intervenire veramente. Per questo ho guardato con interesse all’esperienza “di minimo impatto” del Team Digitale, con tutti i vincoli di un’operazione altamente istituzionale e in parte di comunicazione che cerca di lavorare “la materia prima” senza ipotizzare di cambiarla tutta, nell’infausta tradizione dello “start from scratch”.

Verso la logica degli Open Data

Dove e come quindi costruire un mondo che nel nostro settore vada verso la logica “operativa” degli Open Data? È strano e singolare come anche un’innovazione importantissima come l’avvento di standard come il WebGL nel mondo HTML5 stia generando poche applicazioni “generaliste”. Ce ne sono tante, di commerciali, ma poco aperte. È probabilmente questione di tempo. Ho spinto da sempre su questo tema, in tempi non sospetti, e di recente ho fatto in modo che si tenesse a Roma il primo evento in Italia degli Accelerator della tecnologia FORGE. E dovremmo andare su questa strada mettendoci ancora di più in sinergia, innanzitutto in Italia. È indubbio infatti che senza incrociare la costruzione normativa con le “mani nel codice” non si va lontano. Non si ragiona su una cultura operativa che fa del versioning il suo modus operandi, che non può accettare, per dirla con il linguaggio di noi progettisti, che il progetto “venga tutto prima”, ma che accetti che esso, nato morto, prende vita nel processo, e sia vivo a costruzione ultimata.

Nel frattempo, solo per citare esperienze recenti, di “costruire infrastruttura” si occupa un gruppo come HYPAR, o, recentissimamente, uno come Morphocode con MapsGL, che a New York lavora sul rapporto tra mappatura, GIS e dati sul costruito, sul tema delle reti, oggi cruciale. Di nuovo, mondi paralleli oggi, che si guardano ma hanno dietro strutture consolidate, professionali, di vendita, di impegno nel tempo. Di nuovo, traduzione, o meglio MashUp, come si sarebbe detto qualche anno fa. È un lavoro da fare; all’Università Roma Tre e in collaborazione con tanti privati abbiamo iniziative in corso su questo tema, ma soprattutto, come in passato, il contributo importante è aprirsi, cambiare innanzitutto le proprie strutture: è difficile quando si ha intorno il mercato, la concorrenza, i tempi, ma può anche essere salvifico.

Per questo cito sempre uno studio che non ha nulla di digitale ma che di esso, forse, condivide la cultura profonda dell’azione, la voglia di agire, magari non selvaggiamente come detto da Kas Oosterhuis, che insieme ai nostri pionieri ci ha trasferito la rottura, il cambiare senza chiedere permesso. Studio Mumbai ha deciso di costruire opere insieme ai propri artigiani, nel proprio cortile a Mumbai, in India, prototipandole “in corso d’opera”. Operazione sicuramente d’élite, ma simbolica, soprattutto per la voglia di costruire una forma professionale, a suo modo inedita e liberatoria. Non è una negazione della complessità che siamo felici di affrontare. È il contatto con i materiali, di qualsiasi tipo essi siano, l’aria, la luce per chiudere e non dimenticare mai quale sia il vero obiettivo della nostra attività. Buon lavoro a tutti noi.

Stefano Converso

Nato nel1975, è ricercatore in Progettazione architettonica presso il Dipartimento di Architettura dell’Università Roma Tre. Ha svolto ricerca e attività professionale nel campo delle tecnologie digitali avanzate per il progetto di architettura, conseguendo il Dottorato di ricerca nell’ambito del programma europeo “Villard D’Honnecourt” e poi una specifica attività di ricerca tra Italia e Stati Uniti collaborando in misura preferenziale con il Laboratorio “Product Architecture Lab” diretto da John Nastasi presso lo Stevens Institute of Technology a Hoboken, New York. Presso il Dipartimento è poi stato docente, dal 2007, di un corso di “Tecniche Parametriche di Progettazione”, conducendo un’attività di sperimentazione confluita nella prima partecipazione italiana al Solar Decathlon Europe, vinto nel 2014, e poi nel lavoro di ricerca sulla realizzazione delle superfici a controllo numerico dell’auditorium del Conference Center “La Nuvola” di Roma. Dal 2003 è stato redattore de “Il Giornale dell’Architettura”, referente per il settore Informatica. E’ impegnato in una crescente attività professionale, tra cui spicca la selezione come progettista del Campus TIM di Acilia Macchia Palocco, nell’ambito del progetto nazionale “10 Città”, ora in cantiere.