Buongiorno dottor Tagliati, come sta?
Ti prego chiamami solo Luca. 1. Non ho ancora terminato il PhD. 2. Detesto i titoli e diffido delle persone che si nascondono dietro ad essi. Lo sa che a Roma basta parcheggiare la macchina per essere chiamati con il titolo di "Dotto'" o "Commendato'"?

Va bene Luca.
Grazie.

Di cosa ti stai occupando?
Sto lavorando ad un progetto molto interessante per la mia banca, la HSBC Investment Bank. Stiamo reingegnerizzando il sistema di front-office.

Si tratta di un sistema di GUI?
Non proprio. Non ti fare ingannare dal nome. I sistemi di front-office sono quelli nati all'interno delle organizzazioni di "investment" come conseguenza dell'automatizzazione dei mercati azionari. Sono sistemi che maggiormente concorrono alla generazione dell'introito nelle organizzazioni di investimento. Come ricorderai, intorno agli anni '80 le varie "Borse" hanno cominciato a svuotarsi del folclore, degli operatori che urlavano "Compra!", "Vendi!", per trasformarsi in vertiginose astratte sequenze di dati. Parlo dei famosi ECN.

Interessante, e di cosa si tratta esattamente?
È l'ambiente che utilizzano Sales, Traders e Brokers per contrattare Trades con clienti istituzionali. La parola chiave di questi sistemi è performance: è necessario gestire rapidissimamente enormi quantità di dati provenienti in real-time da mercati elettronici (streaming price), effettuarvi calcoli analitici, valutarne i fattori di rischio, e così via al fine di riuscire ad offrire quotazioni redditizie e competitive. Il passo successivo consiste nel fornire, sempre in tempo reale, gli stessi dati a sistemi in grado di riconoscere autonomamente pattern di investimento e di avviare il conseguente processo di contrattazione.

E dal punto di vista più quisitamente tecnico?
Inizialmente il sistema verrà installato nei quattro principali centri di business della HSBC: Londra, Parigi, New York e Honk Kong. I principali paradigmi architetturali usati sono SOA, e ambienti autonomi e federali. In particolare, ogni centro deve essere in grado di operare autonomamente, tuttavia, alcuni scenari richiedono l'interazione di più siti, non solo in termini di scambio di dati (quote, prezzi, etc.) ma anche in termini di collaborazione tra utenti del sistema. Per esempio, un Sale Londinese per gestire una richiesta di offerta relativa ad un bond governativo americano, deve interagire, in maniera automatica e trasparente, con il corrispondente americano, il tutto sempre in tempo reale. Ogni, sistema (in termini di deployment) è costituito da una dozzina di sotto-sistemi: il sotto-sistema di collegamento e gestione dei mercati elettronici, il sotto-sistema della gestione del mercato bilaterale interno, i sotto-sistemi di front-end (sales GUI, traders GUI) con i corrispondenti server-side, il sotto-sistema del calcolo del rischio, quello della gestione dei dati statici, il sotto-sistema per la sicurezza, di gestione del ciclo di vita dei trade, etc.
Inoltre, sebbene il sistema sia uno, ogni deployment è diverso anche perché è necessario tener presente le diversificazioni locali, legate al diverso impianto legislativo, ai differenti modi di concepire il business, etc.

Qual'è il tuo ruolo?
Senior Architect

Un po' giovane per questo ruolo, no?
In effetti sono il più giovane, e ciò, spesso, mi crea non pochi problemi.

Immagino... Quali tecnologie avete utilizzato?
L'ambiente di sviluppo è quasi totalmente basato su Java/J2EE. Tuttavia, vi è un sistema GUI sviluppato in C#. Inoltre, abbiamo utilizzato un ESB come middleware. Il relativo processo di selezione ci ha portati ad investigare le implementazioni di Sonic, CapeClear e Fiorano. Infine, l'ambiente di produzione è costituito, quasi interamente, da sistemi Linux.

E cosa ci dici dell'ambiente lavorativo londinese?
È decisamente faticoso e stressante ma, al tempo stesso, molto molto stimolante.
Londra non è l'Italia di oggi, è un paese assolutamente dinamico (con i relativi vantaggi e svantaggi) in grado di fornire, professionalmente, l'ambiente ideale per la circolazione di nuove idee. Mafie e "furbizie" varie non incatenato il paese. Le raccomandazioni sono assolutamente marginali (qui si chiamano networking).
Poi, si viaggia molto, si interagisce con persone di diversi background, dotate di diversi schemi mentali, diversi modi di lavorare, etc.
L'elevato livello di competitività impone alle aziende ingenti investimenti in tecnologia, considerata come una preziosa risorsa e non come paravento per accedere a particolari fondi.
Le aziende, quindi, finanziano progetti di grandi dimensioni, pianificati nell'arco di diversi anni, i quali pongono sfide uniche: tutto deve essere attentamente organizzato, bisogna porre attenzione anche ai minimi particolari, progettare attentamente le varie parti, coordinare i team, utilizzare processi di sviluppo formali, e cosi' via.

Parliamo della tua esperienza con MokaByte?
Si, certo... Siamo qui per questo, no?

Come è nata?
Bè... È trascorso molto tempo, però sono rimasto affezionato a MokaByte: è stata la prima rivista, a carattere non locale, su cui ho pubblicato un articolo e poi hanno avuto il coraggio, assolutamente in contro tendenza, di pubblicare un "mattone" sullo UML e sull'ingegneria del software, quando molte riviste preferivano pubblicare articoli su come collegare la telecamera X.Y al videoregistratore Z.
Credo che tutto risalga intorno al 1999. Venivo spesso consultato per problemi e quesiti relativi ai processi di sviluppo del software e all'UML. In quel periodo si trattava di argomenti pressappoco sconosciuti. Quindi, dietro consiglio di un mio "tutor" (Roberto Virgili) e grazie alla collaborazione di un altro (Antonio Rotondi), decisi di trasformare le mie nozioni in una serie di articoli. Inviai un primo articolo ad uno sconosciuto indirizzo di posta elettronica reperito sul web a cui rispose un certo Giovanni Puliti e quindi, iniziammo l'avventura e una conseguente amicizia virtuale.

Cosa ricordi di quell'esperienza?
La cosa più divertente è la confusione che Giovanni ed io riuscivamo a generare (più lui che io, però). Da parte mia, lo facevo impazzire inviandogli decine di versioni dello stesso articolo, lui, per "rivincita", pubblicava puntualmente la versione sbagliata, aggiungendo suoi errori ai miei. A volte, poi, combinava due miei articoli in uno solo, altre volte faceva il contrario. Giovanni mi supplicava di inviargli articoli brevi e due versioni al massimo, io invece gli inviavo dieci versioni dei testi lunghissimi: non avevo mai tempo per scriverne di più brevi!

Ed il libro? Come è nata l'idea?
Questa colpa va condivisa tra Roberto e Giovanni. Ricordo infatti che una volta esaurita l'esperienza dei primi articoli sull'UML, mi lasciai convicere che sarebbe stato un peccato lasciare morire quel materiale nel disco rigido di un server remoto. Mi persuasero che sarebbe stato uno sbaglio non riorganizzare lo "zibaldone" in un volume. Dicevano, che sarebbe bastato sistemarli un po', approfondire ora questo, ora quello di argomento, tagliare qua e là per poterne ricavare un volumetto di 100/200 pagine... Invece ci vollero tre anni di "studio matto e disperatissimo" per elaborare un volume di quasi 600 pagine!

Come mai?
Il primo problema è il mio perfezionismo: Francesco (Saliola) ne sa qualcosa... Dopo aver sistemato la versione 1002 di un capitolo, puntualmente, gli inviavo quella successiva, completamente rivista, ovviamente. Per ogni capitolo gli ho feci produrre 2.000 diversi pdf. Oltre a ciò, ci accorgemmo presto, che parlare di UML senza affrontare l'argomento dei processi di sviluppo sarebbe stato sterile, che ci volevano tanti esempi tratti dalla realtà lavorativa, etc. Antonio e Roberto, poi, erano sempre prodigi di nuove idee e di lunghissime critiche costruttive. Infine, i tanti diagrammi, i tool UML che non seguono mai lo standard, ecc. Ed ecco che il lavoro sfugge al controllo.

Quanto ha contribuito scrivere il libro alla tua carriera?
Non troppo, ahime'. Tuttavia durante i tre anni di studio intensissimo ho analizzato, studiato, confrontato e vagliato un'enorme quantità di informazioni, ho revisionato molti progetti, etc. Questo lavoro ha segnato la mia maturazione professionale permettendomi di passare dalla figura di programmatore (ancora lo sono) a quella di architetto. Però se penso che sono più di cinque anni che lavoro in quel di Londra dove la lingua di Dante non è molto popolare, capisco bene che non ho scritto per fare carriera. E poi chissà che non mi possa essere di aiuto un giorno a tornare nel Belpaese?