lunedì 29 settembre 2008

Architettura IT e Architettura Civile

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.

giovedì 11 settembre 2008

Il costo del prosciutto

In questi giorni mi sto occupando del processo di costing di un'iniziativa di upgrade tecnologico e SOA-enabling piuttosto complessa.

Ci pensavo ieri sera, mentre andavo dal mio salumiere per un etto di prosciutto. Pensavo che se il processo di costing che adottiamo nell'industria del software dovesse essere applicato al prosciutto, molto probabilmente questo genere alimentare - di cui sono particolarmente appassionato - sparirebbe.

Mi immaginavo già la scena mentre entravo nel piccolo salumierino del mio paese.
Entro e saluto il ragazzo al banco. “Vorrei del prosciutto...” dico.
“Ah, le chiamo subito il salumiere capo” - Project Management, costo 2 euro.
“Buonasera sig.Saltarin, cosa le va di mangiare stasera?” - Technical Proposal, costo 1 euro.
“Mah, pensavo a del prosciutto...”
“Ma, mi scusi, del prosciutto cotto o del prosciutto crudo?” - Feasibility, costo 2 euro.
“Del crudo” e sorrido terrorizzato sapendo cosa mi aspetta.
“Ah, guardi, ho del Parma dolcissimo, assaggi... assaggi!” - Proof Of Concept, costo 2 euro.
“Mmm, buono... va bene, lo prendo!”
“Benissimo, sig. Saltarin! E lo vuole al fiocco, o all'osso?” - Functional Specification, costo 3 euro.
“Mah, non saprei... al fiocco?”
“Chiamiamo il Mauro” - il Mauro è l'aiuto salumiere (Development Team)
“Ah, lo so io cosa vuole il Sig. Saltarin” dice il Mauro “un etto bello dolce vicino al fiocco” - Architectural Specification, 3 euro.
“Taglio?” Faccio di sì terrorizzato con la testa.
E il Mauro taglia - Development, 5 euro + 1 etto di prosciutto crudo di Parma, 2 euro.
Le fette cadono sottilissime sulla carta da salumeria - Deployment, 2 euro.
“E mi faccia sapere se era buono!” - Testing, 1 euro.
“In tutto” dice il mio salumiere “fanno 23 euro, con lo sconto facciamo 20! Contento?”
“Mah, tutto sommato forse, guardi, è meglio che vado in Pizzeria...”
“Ma cosa fa, sig. Saltarin, si dà all'outsourcing?”