Come responsabile della funzione aziendale indirizzata ad amministrare le tecnologie ICT all’interno di un’organizzazione, il chief information officer ha anche la responsabilità di pianificare le iniziative di modernizzazione dei software legacy, oggi ancora largamente presenti nelle imprese di qualunque categoria. E questa responsabilità del CIO, tipicamente, non resta semplicemente confinata nella sfera della strategia tecnologica da scegliere e implementare, di volta in volta, in azienda per modernizzare i sistemi legacy ed affrontare le sfide d’innovazione. Si estende, invece, anche agli aspetti organizzativi: questi ultimi riguardano la gestione del cambiamento a livello dei processi di business, e di tutte le persone che, con il loro lavoro e le loro specifiche competenze, contribuiscono a far funzionare i processi stessi.
Un aspetto chiave delle attività di change management attiene anche alla ristrutturazione dei contratti IT tradizionali in essere, che le imprese devono necessariamente attuare. Questo per riuscire a gestire la complessità dell’infrastruttura tecnologica on premise, tipicamente costosa da amministrare, rigida e difficile da adeguare alle attuali esigenze del business. Passare, da un classico contratto di fornitura di servizi IT, a un contratto di fornitura di servizi cloud permette a un’organizzazione di trasformare il proprio modello di spending. Infatti grazie al cloud è possibile migrare, da un paradigma Capex di gestione economica del business, a un modello Opex, che aumenta l’agilità di gestione delle risorse IT e ne commisura il costo in base all’effettivo consumo. Il CIO, tuttavia, deve possedere le capacità per guidare questa transizione in maniera corretta, analizzando e valutando con competenza le condizioni e le clausole specificate in ciascun contratto cloud.
A livello organizzativo, riuscire a gestire nella maniera meno traumatica possibile, per le persone e per la produttività del business, il processo di transizione nel trasferimento delle competenze, o nella creazione di nuove abilità, è già una prima grande sfida. Durante il percorso di modernizzazione del software legacy, il CIO si trova infatti a governare il passaggio generazionale. Da un lato, il personale tecnico, anziano ed esperto, se ne va in pensione, portando con sé un bagaglio di decenni d’esperienza nello sviluppo applicativo, o nella scrittura di codice custom per sistemi mainframe; dall’altro, le nuove generazioni di giovani sviluppatori neoassunti devono poter essere formate in breve tempo su tale eredità tecnologica, e al contempo essere preparate a integrare con essa le tecnologie software di ultima generazione, richieste per arrivare a sviluppare moderne applicazioni cloud native.
Per superare i limiti dell’infrastruttura IT tradizionale, in cui le applicazioni e i dati sono strutturati secondo una rigida architettura a silos, che rende complessa l’interoperabilità tra i diversi sistemi e dipartimenti aziendali, oggi il CIO, in maniera crescente, sta considerando le strategie di migrazione tecnologica basate sul cloud e sulle applicazioni cloud native. A questo punto, però, si pone il problema di come il responsabile dei sistemi informativi aziendali debba agire, per arrivare a scegliere con successo il fornitore dei servizi cloud e anche il system integrator che potrà aiutare l’organizzazione a compiere il proprio, personale, percorso di migrazione verso la nuvola nella maniera più naturale possibile. Il passaggio da software legacy ad applicazioni moderne, infatti, non dovrebbe mai essere uno shock insormontabile, ma un passaggio fluido e privo di intoppi.
Essenziale è non rimanere legati in modo indissolubile a un dato cloud provider. In generale, si parla di vendor lock-in quando un’organizzazione dipende fortemente dalla tecnologia, spesso proprietaria, di un dato fornitore, che risulta incompatibile con quelle di altri vendor. Allo stesso modo, il vendor lock-in, e i possibili, conseguenti, problemi o impedimenti nell’esecuzione della strategia di modernizzazione del sistema legacy, si possono verificare anche quando un fornitore cloud utilizza tecnologia proprietaria, che causa incompatibilità con altre nuvole. Per esempio, quando vengono adottate configurazioni custom, o API (application programming interface) e strumenti di gestione cloud di tipo proprietario. In altri casi, il lock-in è causato dalle condizioni di fornitura dei servizi cloud specificate nel contratto sottoscritto con il cloud provider, e dall’inclusione in esso di particolari vincoli o restrizioni.
Da tutte queste considerazioni sul processo di migrazione nasce l’importanza strategica di fare affidamento su partner di alto livello. Bisognerebbe quindi selezionare system integrator dotati di competenze in grado di spaziare su differenti piattaforme tecnologiche; di padroneggiare le tecnologie software più recenti (container, microservizi) e di orchestrare la portabilità delle applicazioni cloud-native da un provider all’altro. In altre parole, system integrator capaci di guidare in maniera adeguata l’organizzazione, sia verso il paradigma cloud, sia nel processo di selezione del cloud provider più corretto.