Mia moglie fa l'architetto - quello vero! - e spesso mi fa vedere libri illustrati sulle opere architettoniche dei nostri tempi. Io solitamente non ci capisco molto, né riesco ad emozionarmi come fa lei. Una cosa però intuisco: che le architetture edilizie, rispetto alle architetture IT sono sostanzialmente più evolute.
Si capisce molto bene, vedendo un'opera di Renzo Piano o di Fuksas, che il requisito di un'architettura civile non è (non è soltanto, diciamo) la funzionalità, ma vi sono anche requisiti di bellezza, originalità, integrazione col contesto.
La differenza sostanziale tra l'architettura civile e quella informatica è che la prima di solito "funziona" (nel senso che assolve la sua funzione primaria, quella cioè di costituire una o più unità abitative) e di fatto "dura nel tempo".
Le architetture informatiche, anche quelle più complesse e con costi paragonabili a quelli dell'architettura civile, solitamente invece "non funzionano" (nel senso che non riescono a tradurre al 100% i requisiti funzionali in software) e, soprattutto, "non durano" - difficilmente un sistema informatico dura più di cinque anni, quasi mai dura più di dieci.
Come mai quindi l'industria spende milioni di dollari in sistemi informatici che non durano e che non funzionano? La risposta è piuttosto semplice: in questo campo umano, molto semplicemente, non esistono alternative. Noi architetti IT progettiamo "al meglio" quanto la tecnologia e l'ingegneria informatica oggi consentono di fare. In altre parole, come dicevo prima, l'architettura dei sistemi informativi è una scienza relativamente giovane, e come tale, largamente immatura.
Dobbiamo accontentarci di fare, dunque, spallucce, e realizzare quei sistemi qualitativamente pessimi a cui l'industria dei sistemi IT enterprise ci ha abituati?
Io credo di no. E suggerisco, umilmente s'intende, due linee guida (noi architetti IT siamo, questo sì, veramente bravi nel produrre Guidelines!) per migliorare la qualità complessiva dei progetti.
La prima è ovvia, ma sempre trascurata. Premiare la semplicità. Se andate da qualche responsabile IT di una media o grande impresa, vi accorgerete che non riuscirete facilmente a vendere cose semplici. Esistono pochi requisiti informativi enterprise che non siano in realtà soddisfacibili con uno script shell o al massimo con un programma in Python (o in Ruby, guardate per esempio alla lezione di Ruby On Rails), affiancato a un buon database e ad un buona tecnologia di front-end. Ma molto difficilmente riuscirete a vendere qualcosa che non si appoggi a J2EE (una delle tecnologie peggiori e più inutilmente complesse che siano mai state prodotte dall'Uomo) e che non richieda hardware secondo solo a quello della NASA. Credo che questa necessità di complessità sia in qualche modo correlata all'idea che si ha dei computer e del software come qualcosa di oscuro e di magico, campi esoterici in cui il Segreto e il Mistero sono connaturati alla soluzione che si va proponendo.
Della seconda ho parlato nel mio blog precedente a proposito del mio macellaio. Avremo, io credo, un balzo nella qualità dei sistemi informativi quando abbandoneremo del tutto l'idea (presuntuosa e sempre disattesa) di poter stimare il loro valore economico a preventivo. So di dare un dispiacere ai venditori di (complessissime!) metodologie che vorrebbero calcolare a priori il costo o il valore di un progetto informatico: ogni anno vengono pubblicati studi che confermano che questo è un campo del sapere in cui semplicemente non siamo in grado di fare previsioni! Non siamo in grado e non abbiamo una metodologia in grado di stimare il costo di un progetto informatico a partire dai suoi requisiti e dall'analisi funzionale. Come nella meteorologia, in un progetto informatico di medie o grosse dimensioni, le variabili sono talmente tante, che non è possibile tenerle tutte in conto. Perciò ogni previsione è destinata in genere a naufragare.
Per rispondere seriamente e onestamente alla domanda: "quanto costa" occorrerebbe applicare analisi statistiche da confermare con successivi ricicli ad ogni milestone del progetto, convincendo la controparte che - agli stadi iniziali - non si possono avere idee precise sui costi, e che darne una "spannometrica" equivale più o meno a mentire.
Quando ero ancora un ragazzino, il mio datore di lavoro, che fu tra i primi in Italia a proporre soluzioni di Workflow, aveva un metodo infallibile per stimare il prezzo a cui vendere una soluzione software: "Vedi" mi diceva sorridendo "io cerco di capire quanti soldi il mio cliente ha nel portafoglio, e poi cerco di prenderglieli tutti".
Benché tecnicamente ingiustificabile, e moralmente discutibile, questo approccio aveva se non altro il merito dell'onestà intellettuale.
