Archives For March 2003

Ho avuto modo di incontrare Ernesto Hofmann di IBM. Il suo ruolo ufficiale è "senior consultant". Questa formula dice molto proprio perché non dice gran ché: Hofmann ha infatti visto quasi tutto della storia IBM degli ultimi trent’anni – anzi, di più, essendo entrato in IBM nel 1968. Il che significa anche aver visto quasi tutto della storia dell’informatica, soprattutto italiana.

Il professor Hofmann però non ha esaurito la sua carriera tecnica rimanendo legato a una qualsiasi fase della storia dell’informatica. Al contrario, ricopre ormai da anni, per IBM e per l’Università Bocconi, il ruolo di ricercatore e "visionario" su quelli che saranno gli sviluppi futuri. E’ stato proprio questo l’argomento principale dell’incontro: gli scenari prossimi venturi dell’E-Business on demand. Ma non si è potuto evitare un piacevole excursus su come si è arrivati a ciò. E’ quel che vi presentiamo in queste righe. Potrete trovare la seconda parte dell’intervista nella nostra monografia sull’E-Business in uscita tra breve.

ZDNet Italia: Professor Hofmann, leggenda vuole che lei abbia installato il primo sistema operativo in Italia
Ernesto Hofmann: Non è così. Ho installato il primo MVS [il sistema operativo dei mainframe, n.d.r.] nella primavera del 1975. Lo confesso per la prima volta: mi avevano proposto di diventare capo, ma non apprezzavo la proposta. Non pensavo che quella carriera mi fosse confacente, preferivo tornare a essere un tecnico serio. Ma siccome in ufficio non mi permettevano di studiare, lo facevo nei weekend. Così, senza corsi e con il solo manuale, mi sono messo lì con la prima versione di MVS il sabato, e la sera del lunedì di Pasquetta girava. Male, ma girava.

ZD: Quali sono state le evoluzioni successive?
EH: Tra la fine del ’75 e l’inizio del ’76 il sistema, con le nuove versioni, ha iniziato a prendere piede. A ottobre del ’75 si è entrati in produzione con il transaction processing [gestione in tempo reale della trasmissione dei dati]. Allora nascevano le prime importanti applicazioni per il mondo bancario, e l’implementazione dei sistemi era relativamente semplice: non si faceva altro che aggiungere terminali. Nel ’77/’78 c’è stato l’attacco Digital, con i Vax: i primi sistemi dipartimentali. Macchine più piccole e di minor costo, che rappresentavano una concorrenza agguerrita per i costosi sistemi centrali di IBM. Poi vi furono le alternative ai mainframe IBM rese disponibili da Amdhal (Banca d’Italia prese un sistema di questo tipo, e altre banche la seguirono), e Hitachi. Ma intorno al 1980 IBM rispose con il primo sistema 3081D, molto avanzato e che ebbe notevole successo. Sarebbe diventato il 3090.

Intorno al 1982/’83 si profilò l’avvento del pc, ma ancora nell’84 erano sistemi periferici che sostituivano i terminali. Il vero attacco del pc è stato con l’arrivo di Santa Cruz Operation, la SCO, che è stata la prima a installare piccole reti locali gestite da un pc ben carrozzato e con il loro sistema operativo. Costavano poco, funzionavano, e anche se presentavano problemi di gestione presero piede, soprattutto presso la piccola impresa italiana. Presso questi clienti IBM aveva una buona presenza con i sistemi 36, ma la novità arrivò nell’88 con la presentazione della piattaforma AS/400, un evento storico. Alla presentazione vi erano 114 giornalisti, una cosa mai vista prima in questo settore. I dolori iniziarono a fine anni ’80, inizio anni ’90, con la diffusione vera dei pc e la battaglia dei sistemi operativi client [Windows 3.0 è stato introdotto nel 1990, n.d.r.]. In quel periodo il top management IBM non è stato in grado di interpretare correttamente l’evoluzione del mercato. Ci furono alcuni anni di sbandamento, che portarono alla crisi del 92/93.

ZD: Quali sono stati gli elementi fondamentali della trasformazione dall’informatica di quei tempi all’attuale?
EH: Il vero problema secondo me è stato il crollo del costo dei MIPS [million instruction per second, unità di misura fondamentale della capacità di calcolo]. In quegli anni un MIPS costava 150.000 dollari, non qualche centinaio. Il margine di profitto era altissimo, per cui i sistemi potevano essere tenuti in perfetta efficienza. I grandi sistemi avevano margini di guadagno spaventosi, come gli aerei Boeing, perché non erano delle commodity.

L’attenzione quindi si è spostata sul software, molto più complesso dell’hardware e con un maggior valore aggiunto. Oggi è il software il vero problema. Negli Stati Uniti stimano che l’insufficiente disponibilità di competenze nello sviluppo software possa causare un danno potenziale nei prossimi anni pari a un 2/5% del PIL americano. Mancano un milione e mezzo, due milioni di persone, e per l’Europa è molto peggio. Per l’Italia mancano 2/300.000 programmatori l’anno.

ZD: Le architetture standard e modulari di sviluppo software, come per esempio i Web Service, non dovrebbero alleviare questo problema?
EH: Non sono sufficienti. Sono utili per gestire l’eterogeneità, ma non sufficienti per gestire software distribuito. Credo che in questi anni si sia commesso un grande errore di fondo, quello di credere alla riutilizzabilità del software. Non è reale. E’ quasi impossibile scrivere software riusabile, perché la documentazione è talmente difficile, sia da stendere sia da interpretare, che si vanifica lo sforzo. Certo, alcune routine possono essere standardizzate, ma i programmi principali, per esempio per gestire i conti correnti, non possono essere standard.

Si possono creare procedure standard per leggere, per esempio, gli andamenti di borsa delle maggiori banche. Un certo fornitore dei contenuti può esporre il proprio codice, con UDDI lo intercetti e con SOAP lo agganci. Ma la gestione dei processi interni di un’azienda richiede una modellistica su misura. Non può esserci un sistema di gestione dei conti correnti uguale per tutte le banche, altrimenti non si percepirebbe la differenza di valore tra un’azienda e l’altra. Si cambia modello di business perché si usa un algoritmo particolare, e si elabora un algoritmo particolare perché si deve cambiare modello di business.

ZD: Quindi qual è la posizione IBM negli scenari dell’informatica distribuita "modello Internet"?
EH: La posizione IBM è di scrivere "colla", "colla", "colla".

ZD: "Colla"?
EH: Middleware, ovvero strati di traduzione da un sistema all’altro, da una architettura all’altra, da un software all’altro. Nel tempo si sono sviluppati modi per comunicare tra sistemi diversi: pc, Unix, AS/400, eccetera. Con il problema di creare strati di interpretazione ("colla") tra i programmi sviluppati sulle diverse piattaforme. Tra pc e pc, pc e server, e anche tra server e server, cioè i cosiddetti ambienti distribuiti.

Poi è arrivato Internet che aveva un approccio completamente diverso. Usiamo un protocollo comune per i dati, HTTP, e uno per i documenti, HTML. Oggi un sistema, una applicazione, deve essere in grado di gestire l’interfaccia verso Internet, poi i messaggi e i dati vengono interpretati. Altra colla. Quindi il middleware che si sta sviluppando diventa sempre più complesso e flessibile. Si è passati dall’informatica centralizzata al peer-to-peer al client/server all’Internet prima fase all’Internet seconda fase.

ZD: Cosa intende con Internet seconda fase?
EH: Io credo che il [futuro] modello Internet sia a distribuzione applicativa. L’infrastruttura può diventare "trasparente" e può trasferire ogni tipo di informazione, ma può anche evitare di farlo. Quindi si possono far eseguire programmi a computer remoti, limitandosi a trasferire i dati di risultato. E’ l’approccio del Grid Computing.

IBM ha sposato questo approccio, e ha iniziato a scrivere colla in questo senso. Cioè a cercare di realizzare architetture per fornire capacità di calcolo a qualsiasi chiamata applicativa, dovunque siano codice da eseguire e computer a cui fornire la risposta. Il modello è: un computer chiede, per esempio, un’applicazione di data mining, su un suo insieme di dati. Quindi gli serve un software di data mining e un database temporaneo dove elaborare i risultati. Il sistema verifica e risponde: sì, posso fornire lo strumento software, che gira su una certa macchina, e il database per i risultati, che risiede su un’altra macchina. Per chi ha effettuato la richiesta tutto ciò è trasparente, ottiene solo i risultati. Facile a raccontarsi, ma ci vogliono anni per realizzarlo.