Ingegnerizzare il software, una chimera?

Molti, quasi tutti direi, si ispirano ai processi ed a i metodi dell'ingegneria civile per strutturare e gestire il ciclo di vita di un progetto software: i metodi detti "ingegneristici" sono visti come un faro a cui tendere ed inquadrare finalmente in un'ottica di metodo e qualità lo sviluppo del software. Secondo me è una chimera e pure un rischio perché non si è capito che le due cose come fondamentalmente diverse ed incompatibili; non si può progettare e realizzare un software con i metodi con cui si progetta e realizza un punte. Perché? Seguiamo un ragionamento.
Nell'ingegnerie civile il costo di spostare un pilastro é un'ordine di magnitudine superiore al costo di costruirlo. Da millenni l'uomo prima di costruire una struttura o un edificio lo ha prima accuratemente progettato, dalle piramidi, ai ponti romani a San Pietro a Roma. L'istinto che abbiamo con questo tipo di costruzioni è: prima progetto e poi costruisco. Se dobbiamo costruire un'artefatto anche piccolo come un tavolo o una cassapanca prima di tutto facciamo un piano, un disegno, uno schema se non pure un prototipo, prima della sua costruzione. Perchè sappiamo ed abbiamo l'istinto che modificare in corso d'opera è estremamente costoso, buttiamo via materiale e tempo, c'è poca probabilità di riusare quello che è già stato fatto. In informatica abbiamo una anomalia particolarissima: il costo di modificare un artefatto software è una frazione del costo di realizzalo. Tutti noi all'inizio delle nostre esperienze informatiche abbiamo vissuto l'esperienza di realizzare subito e modificare dopo, perché "si fa prima", perché "tanto modifico dopo". L'istinto è di tutt'altra natura. Ho visto aziende mature e di successo con la stessa mentalità, partire a sviluppare senza piano o progetto o disegno perché tanto, si pensa, a modificare ci penso sopo. Questa è una anomalia in cui molti ci cascano, e debbo dire che pure li capisco. Una variabile si valorizza al volo, un software si duplica, si reinstalla, il valore di una tabella si cambia in un attimo. L'istinto di modellare, progettare, disegnare prima ed un anticipo non c'è ed il motivo è quello: modificare costa meno che fare. Poi aggiungiamo la fretta e l'agitazione di fare presto che permea l'informatico, allora abbiamo un bel quadro completo: ho visto "analisti" in piedi dietro un programmatore a dirgli cosa fare!

I processi di ingegneria hanno milleni di esperienza e si sono adattati al fatto che i requisiti di un ponte o di un edificio sono statici come la struttura che deve essere relalizzata, c'è molto poco spazio per gestire i cambiamenti. Spesso se i requisiti cambiamo, un ponte non basta più. si butta giù e si rifà. Ad un ingegnere civile non si chiede di allungare un ponte, o di spostarlo o tanto meno di costruire un altro piano mentre sotto il traffico scorre ancora. In informatica non ci meravigliamo di queste richieste, sono una conseguenza della natura effimera (soft) appunto di questa strana scienza (oddio..scienza, ho esagerato, l'informarica pare più essere un'opinione).

Consideriamo per un attimo anche gli strumenti di sviluppo. Per fare una casa servono degli strumenti costosi e complessi come delle gru, scavatrici e betoniere solo per dirne alcuni. Nessuno di noi pensa che per farsi una casa in un terreno che abbiamo basta fare un corso di "gru" o di "scavatrice". Sappiamo che lo strumento non basta, non serve neppure essere un bravo operatore. Ci sono processi, altri strumenti, tecnologia, scienza, progetti. Questi strumenti sono innanzi tutto costosi da ottenere, voluminosi ed una volta ottenuti non siamo in grado di usarli. Il nostro istinto è di andare dai professionisti! Il nostro istinti è quello di andare da un geometra o da un architetto che poi invocano un ingegnere per la fattibilità che poi chiama un'impresa edile: ogni uno
sa cosa fare ed ha un ruolo ben specifico.

Ah, ma in informatica i tool si possono scaricare da Internet, e sono spesso free a partire dai data base, agli IDE, UML editor, application server, GUI framework, linguaggi, VM, middleware ... tutto freee, tutto scaricabile. E tutti ci sentiamo in grado di metterci ad usarli, tutti credono e hanno il diabolico istinto di poter creare di poter realizzare un software solo perché hanno gli strumenti a portata di un click! Vedo nelle librerie libri contitoli come "XML in 24 ore", "Impare EJB in 2 giorni","Diventa un webmaster", e li vediamo e magari ci facciamo pure il pensierino di prenderli che qualcosa magari insegnano pure. Fate un salto nella sezione "Medicina" e cercate "Diventa un chirurgo del cervello in 24 ore", "Fai fa te: il trapianto di fegato in 24 ore", "Chirurgia vascolare in 48 ore". Se vi fa ridere allora dovete trovare il modo ri ridere anche per quei titoli informatici. Assurdamente ritengo che se i tool pesassero 10kg a Megabyte, se occupassero 1m^3 a Mbyte avremmo meno problemi: dove li mettiamo? Questa manna di tool free e potenti a disposizione non hanno bene all'informatica secondo me, avremmo contrastato questa mania di onnipotenza, poter realizzare qualunque cosa solo perché abbiamo accesso agli strumenti. Pensate a quanti disastri avremmo fatto se possedere una ruspa o una scavartrice fosse facile e economico come comprare una levigatrice.

Mettiamo assieme le due cose:

costa meno modificare che fare
gli strumenti sono accessibili a tutti
e vediamo che viene rivoluzionata una buona fetta di quegli elementi propri dell'ingegnerie civile, quello che resta è il knowhow ed i processi che finiscono sottostimati e sono la causa principale del fallimento dei progetti IT.

Comunque, non mi si fraintenda: in informatica quando si realizza del software c'è ovviamente bisogno di progettare e molto! Serve "pensare" a priori prima di scrivere un "main", ma non per gestire la complessità della realizzazione del prodotto software, non per la sua realizzazione ma per ottenerne la scalabilità e la manutenibilità, per poterlo gestire nel suo ciclo di vita. Il software è quasi un essere biologico, non è immutabile. Sono aspetti che nell'ingegneria civile non sono gestiti. E' un aspetto non intuitivo che il cliente innanzi tutto non chiede per primo (lo vuole dopo, assume "dopo" che avrebbe potuto scalare sulla tecnologia 'x' a costi '0'), ma lo vede solamente l'informatico, l'architetto che può dire "ne ho viste di cose che voi umani non potete nemmeno immaginari", ho visto progetti perfetti fallire per non aver gestito un requisito, per non aver saputo scalare il numero di utenti, per non essere stati in grado di supportate l'estensione delle funzionalità, per essere stato in grado di supportare una diversa piattaforma...pare che siamo anche incapaci di imparare.

Del famoso Tacoma bridge, non metto neppure un URL qui, trovatevelo è un caso famosissimo, è stato studiato a fondo per evitare che si ripetano tali errori: in informatica pare non si faccia lo stesso, un'analisi post mortem di un progetto è sempre da assegnare ad un “capro espiatorio”, spesso erroneamente alla tecnologia “X”, pare che in informatica non si possa imparare dagli errori.

Alla via così.

Architetture IT e di Enterprise stanno per congiungersi

Le architetture di enterprise hanno un ruolo importante nelle aziende di grandi dimensioni in cui ci sia la necessitò di definire sia I processi IT che quelli di business con lo scopo principale di allineare il business all'IT. In questo contesto sono state definiti diversi metemodelli come TOGAF, MoDAF, DODAF, ITIC, COBIT, BMM per non citare il classico Zachman.

Diverse imprese in Italia ne hanno adottato anche più di uno e il trend è di allungare questi approcci alle architetture IT per ottenere un vantaggio di scala attraverso la generazione di codice o di infrastrutture; si tratta in questi casi di tecniche orientate ai modelli come Model Driven Architeture (MDA), Model Driven Engineering (MDE), Model Driven Development (MDD). Ad ogni modo, indipendentemente dall'acronimo o del consorzio che è stato sposato si assiste ad un corto-circuito tra un cammino bottom-up, guidato dalle esigenze della software factory che intende armonizzare I suoi processi, raccogliere e gestire I requisiti e generare parte del codice di piattaforma con uno top-down voluto dal gruppi di Enterprise Architecture per la governance dell'impresa.

L'obiettivo è che le due piramidi si tocchino al vertice in modo armonico: il fine che permetterebbe di vedere finalmente l'IT come sistema nervoso del Business e non come “il centro meccanografico”.