I moderni paradigmi di sviluppo software, come la metodologia Agile e la pratica di integrazione continua (CI) stanno facendo sempre più strada anche nel settore bancario. E, ciò nonostante, il mondo finance rimane uno degli ambiti più conservativi e riluttanti nell’abbracciare le nuove metodologie di creazione e distribuzione del codice che costituisce le applicazioni di business. In questa prospettiva, un buon esempio d’innovazione del software nel settore finance riguarda il percorso di evoluzione tecnologica compiuto in questi anni da un noto gruppo bancario italiano.
Creare sistemi di trading facilmente aggiornabili
Con l’obiettivo di sviluppare alcuni strumenti software strategici per aumentare l’efficienza e la redditività del proprio core business, l’istituto bancario ha avviato verso la fine del 2015 un progetto per realizzare applicazioni di trading proprietarie, destinate ad uso interno e in grado di gestire sofisticate operazioni che, tipicamente, possono includere funzionalità di pricing, quotazione di beni, gestione del rischio. Un’altra esigenza chiave della banca, manifestatasi soprattutto di recente, era la necessità di sviluppare e aggiornare con agilità e rapidità questi applicativi, accelerando il ritmo d’introduzione dei nuovi cambiamenti e funzionalità.
Piattaforme di trading fortemente personalizzate
“Un requisito fondamentale – spiega Luigi Leoni, responsabile del team di pratiche DevOps all’interno di Sorint.lab, uno dei partner tecnologici che ha maggiormente contribuito alla realizzazione del progetto – era sviluppare tali applicazioni ad hoc, sulla base delle indicazioni fornite dai trader interni della banca, che desiderano un software aderente al loro modo di lavorare, e in grado di farli operare il più velocemente possibile. Queste applicazioni sono piattaforme classificabili in funzione del segmento di prodotti finanziari che coprono come, per esempio, commodity, certificate, derivati o quant’altro.
In sostanza, è l’esperienza utente che guida lo sviluppo dell’applicazione, sia in termini di utilizzo, sia di funzionalità. Sono piattaforme che si differenziano dai classici software pacchettizzati forniti dai vendor del settore, caratterizzati da funzioni e modalità di utilizzo precostituite, a cui l’utente deve necessariamente adattarsi”. In aggiunta, le piattaforme sviluppate da Sorint.lab non sono applicativi client, ma sono tecnologicamente inquadrabili come web app, funzionanti su macchine server. Web app quindi in grado di rispondere a requisiti di elevata affidabilità, accessibili e utilizzabili attraverso un apposito browser, con funzionalità specifiche per svolgere varie operazioni sui file.
Sette applicativi sviluppati “from scratch”
Trattandosi di applicazioni nuove, da realizzare da zero, Sorint.lab non è partita dall’architettura tecnologica preesistente nella banca, fondata unicamente su application server e applicazioni Java Enterprise. Ha invece adottato, fin dall’inizio e in sinergia con il responsabile interno del gruppo bancario, quella che oggi viene da più parti definita una strategia di “modern application development” (MAD). “A seconda dei requisiti da soddisfare e della convenienza, abbiamo utilizzato l’approccio basato su microservizi, su miniservizi o su application server”.
Dal punto di vista delle metodologie di sviluppo, al fine di soddisfare l’esigenza dei trader bancari di utilizzare rapidamente le applicazioni, ma al contempo di garantire la fornitura di software aggiornato frequentemente e di elevata qualità, Sorint.lab ha implementato da zero una pipeline di integrazione continua, indirizzata a velocizzare il ciclo di sviluppo del codice. Nel complesso, la pipeline CI realizzata gestisce totalmente le attività di sviluppo delle sette piattaforme di trading finora progettate, a loro volta composte da una quarantina di moduli applicativi e dalle relative librerie software.
“Un altro aspetto fondamentale su cui è stata posta particolare attenzione è garantire la qualità del codice, sia a livello sintattico, sia semantico. Per ottenere questo obiettivo, sono stati definiti vincoli stringenti, tesi a far sì che la qualità del software raggiunga standard molto elevati. Il processo di quality assurance è consentito da strumenti open source di verifica della qualità, e, in parte anche della sicurezza, integrati all’interno della toolchain che costituisce la pipeline CI”. Quest’ultima è dotata di una scalabilità on-demand, e supporta la creazione di un elevato numero di build software.
Obiettivi raggiunti e sfide tecniche
E i risultati? Leoni riporta che l’istituto bancario si dice soddisfatto dei sistemi di trading realizzati, perché funzionano bene, sono veloci, e sono caratterizzati da un’elevata affidabilità. “Soprattutto sono molto apprezzati dagli utenti finali, cioè dai trader, che gradiscono un applicativo in grado di operare come loro desiderano. Questo è anche il motivo per cui un progetto avviato ormai sette anni fa, con una sola soluzione prototipale, è stato progressivamente esteso portando alla nascita di queste sette applicazioni di trading che continuano a evolvere sempre più, anche in virtù del ritmo a cui ora il software viene rilasciato. Attualmente, infatti, grazie alla pipeline CI, per ciascuna delle sette applicazioni, è possibile eseguire un nuovo rilascio ogni 14-15 giorni, e ciò rende rapidissima l’introduzione delle nuove funzionalità”.
Per quanto riguarda gli ostacoli incontrati durante il processo d’implementazione del progetto, Leoni ha le idee chiare. “Per noi, e per i nostri sviluppatori, sicuramente è stato impegnativo comprendere il molto complesso contesto del mondo finance e acquisire le necessarie competenze. Sul versante delle metodologie di sviluppo, invece, la difficoltà è stata trovare il giusto compromesso per riuscire a introdurre l’approccio DevOps all’interno dell’istituto bancario, eliminando il più possibile le barriere culturali e organizzative, incontrate all’inizio del nostro intervento di modernizzazione”.
Miglioramento continuo, lo step DevSecOps
Per sua natura, il modello DevOps è indirizzato a potenziare di continuo la qualità, robustezza, affidabilità di questi applicativi bancari. All’orizzonte, però, c’è un ulteriore passaggio. “Auspicando in prospettiva una completa integrazione della metodologia CI con la componente CD della pipeline, quindi la distribuzione continua del codice – attualmente non completamente automatizzata in ambiente di produzione – il nostro obiettivo è introdurre il paradigma DevSecOps. Quello che vorremmo fare è irrobustire ulteriormente la qualità del codice, anche sotto il profilo della sicurezza, il cui livello, tuttavia, oggi soddisfa ampiamente i criteri di security dell’istituto bancario. Al momento, queste verifiche avvengono solo dopo il rilascio del software, mentre il nostro obiettivo è implementare i test di vulnerabilità e sicurezza direttamente all’interno del ciclo di sviluppo” conclude Luigi Leoni.
