Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

Valorizzare il portafoglio applicativo: come e perché

pittogramma Zerouno

Valorizzare il portafoglio applicativo: come e perché

09 Dic 2009

di Nicoletta Boldrini

Le applicazioni aziendali non sempre sono oggi in grado di rispondere velocemente alle esigenze di un business costantemente in cambiamento. La loro modernizzazione rappresenta un percorso importante per lo sviluppo di nuove capacità e l’approccio può essere sia tattico sia strategico. Vediamo come. L’ Osservatorio Modernizzazione delle applicazioni aiuta a comprendere come valorizzare il portafoglio applicativo con articoli, interviste, documenti, white paper.

Su queste tematiche suggeriamo anche la lettura di “CIO oggi, domani di più!”, un white paper che contiene alcuni suggerimenti a possibili approcci tattici e strategici verso la modernizzazione delle applicazioni e alcuni esempi di casi concreti. Consigliamo anche la lettura dell'articolo "Modernizzazione applicativa: i vari passaggi".

 


 


Problema ormai comune a quasi tutti i Cio è che il lungo termine diventa sempre più breve: ed è in un lasso di tempo sempre più breve che devono dare risposte a sostegno del business. Concretamente, per il Cio significa: sviluppare progetti in grado di supportare la crescita del business, collegare il business con piani e strategie It, migliorare la qualità dell’offerta di servizi. Come? Già trovare il punto di partenza è una bella sfida.
Una via possibile è quella della valorizzazione del portfolio applicativo dell’organizzazione in un’ottica di razionalizzazione e modernizzazione.
Le applicazioni legacy sono vitali per le aziende, soprattutto per le grandi organizzazioni, e per l’intera economia mondiale perché, secondo gli analisti delle più note società di ricerca americane, elaborano tutt’ora circa l’80% di tutte le transazioni aziendali. Parliamo dunque di applicazioni “business-critical” che nel corso dei decenni sono state fortemente personalizzate seguendo una logica strategica secondo la quale più si customizzava e verticalizzava, più si realizzava un valore esclusivo abilitatore di competitività.
Approcci certamente validi e che hanno prodotto gli attesi risultati di business ma che, oggi, incontrano alcuni ostacoli. Benché fondamentali per il successo del business, le applicazioni legacy  sono spesso difficili da aggiornare con quella flessibilità e tempestività che oggi sembrano essere divenute le prioritarie “regole del gioco” per rimanere sul mercato.
Le applicazioni aziendali intorno a cui ruota il business consumano risorse economiche e umane. Per la maggior parte delle aziende, il semplice mantenimento dell’enorme assortimento di vecchie e nuove tecnologie assorbe circa il 70% dei costi It (alcuni analisti parlano addirittura dell’80%), lasciando ben poco margine di spesa per l’innovazione e il cambiamento che invece rappresenta la leva competitiva principale.
Per questi motivi, sono ormai molte le aziende che hanno scelto di intervenire sul proprio parco applicativo: alcune hanno deciso di sostituire le loro applicazioni chiave con soluzioni preconfigurate e pacchettizzate, altre hanno optato per la riscrittura delle soluzioni core utilizzando linguaggi di programmazione più recenti.
Tuttavia, secondo quelle “regole del gioco” che impongono tempestività e flessibilità, simili opzioni, benché validissime nei risultati, rischiano di tradursi in progetti lunghi e costosi (che per altro possono addirittura prevedere interruzioni delle attività): la riscrittura in toto delle applicazioni di solito non è nemmeno necessaria e implica comunque un livello di rischio troppo elevato, oltre a dei ritorni minimi sull’investimento; la sostituzione con soluzioni pacchettizzate risulta essere certamente una scelta meno rischiosa e più veloce in termini di attuazione ma va ad eliminare  quelle caratteristiche esclusive create nel corso degli anni (con la customizzazione delle applicazioni), che sono comunque state fonte di vantaggio competitivo dell’azienda.
Qual è allora l’alternativa? È la modernizzazione che invece di proporre riscrittura ex-novo o sostituzione delle soluzioni, consente di mantenere le applicazioni core riutilizzando in veste nuova il codice esistente.
Fantastico sulla carta, ma come in tutti i progetti It, esistono criticità e sfide da superare che vanno valutate prima di qualsiasi intervento di tipo tecnologico.

Da dove partire
Secondo i dati di Aberdeen Group (www.aberdeen.com), “Nelle aziende vengono utilizzate applicazioni mainframe per un valore di 2 miliardi di dollari che coprono circa il 70% di tutta la logica e i dati critici. La razionalizzazione e l’ammodernamento di queste applicazioni rappresenta un’opportunità incredibile per ridurre il Tco e migliorare la capacità di rispondere dinamicamente alle esigenze del business”.
Rimangono però alcuni ostacoli da superare, primo fra tutto l’informazione.
Uno dei principali problemi da affrontare per pianificare e gestire in modo efficace il “cambiamento” del parco applicativo è capire il punto di partenza: in molte realtà c’è la mancanza di informazioni aggiornate, accurate e dettagliate sulle innumerevoli applicazioni intorno a cui ruota il business. Molte aziende sono addirittura sprovviste di un inventario delle applicazioni che possiedono e dell’uso che ne viene fatto (vedi i risultati dell'indagine realizzata da ZeroUno in collaborazione con NetConsulting riportati nell’articolo “Modernizzare le applicazioni: come e con quali strumenti”).
Non solo: anche riuscendo ad avere una buona fotografia del proprio parco applicativo, scegliere cosa e come modernizzarlo non è compito facile. Ogni situazione è unica e per modernizzare le applicazioni è disponibile un’intera gamma di tecniche che vanno dall’integrazione con nuove tecnologie alla re-implementazione o sostituzione. Il giusto approccio dipende dalla piena comprensione delle opzioni disponibili e dall’analisi dei costi e dei vantaggi basata su dati affidabili. Il processo di modifica è sempre difficile da gestire. La qualità del servizio deve essere mantenuta (se non migliorata) ma al tempo stesso è necessario controllare i costi. Occorre misurare gli effetti del cambiamento e verificare i miglioramenti e risultati che si desidera ottenere.
In altre parole, va individuato il corretto approccio e quindi il percorso più opportuno. Fatta l’eventuale mappatura dell’esistente sarà necessario capire quali sono le applicazioni che possono essere, lentamente e per gradi, “dismesse” o “riviste” e soprattutto verificare se le applicazioni disponibili sono tattiche o strategiche rispetto agli obiettivi del business.

Scegliere la tattica o la stretegia?
Parlare di modernizzazione delle applicazioni significa, per il Cio, raggiungere obiettivi di soddisfacimento delle richieste di nuove funzionalità, maggior facilità d’uso e miglior qualità (ed efficienza) espresse dagli utenti aziendali (dal top management a tutte le Lob). Il tutto sfruttando le nuove tecnologie che, per altro, promettono riduzione dei costi di sviluppo e di esercizio delle applicazioni e dei servizi forniti.
Facendo prima una premessa doverosa sugli aspetti tecnologici, vediamo i possibili approcci che un’azienda può adottare nell’affrontare la modernizzazione delle applicazioni.
La premessa è questa: Il Cobol (acronimo di COmmon Business-Oriented Language, ossia, letteralmente, “linguaggio orientato alle applicazioni commerciali comuni”) è uno dei primi linguaggi di programmazione ad essere stato sviluppato. Progettato nel 1959 con lo scopo di creare un linguaggio di programmazione adatto all'elaborazione di dati commerciali è stato da sempre usato come linguaggio base per le applicazioni aziendali, grazie alla sua stabilità (gli applicativi Cobol sono alla base, per esempio, del funzionamento dei Bancomat e dell'operatività di molte banche e assicurazioni). Dagli anni sessanta a oggi, il Cobol ha subito continue evoluzioni e oggi è un linguaggio che supporta le tecnologie a oggetti, l’interscambio di dati Xml, l’integrazione con Java, le piattaforme J2ee, .Net , le architetture Soa e il Cloud Computing.
Considerando dunque il Cobol quale punto di partenza di un approccio alla modernizzazione applicativa il Cio può seguire approcci tattici (riduzione dei costi delle postazioni di sviluppo; incremento della produttività e della qualità dello sviluppo software; riduzione dei costi di manutenzione, ecc.) o di tipo strategico (che racchiude tutti gli elementi di un approccio tattico in una roadmap evolutiva che ha come obiettivo finale il vantaggio competitivo del business).
Adottare un approccio di tipo tattico, significa innanzitutto intervenire su aree specifiche con progetti mirati e “isolati” (anche se poi isolati non sono). Se spesso, infatti, per ottenere dei risultati tangibili occorre pianificare interventi complessi ed articolati nel tempo (oltre che costosi), nell’ambito della modernizzazione si possono raggiungere importanti benefici anche partendo da azioni ridotte, con investimenti minimi e bassi rischi.  Si tratta, ad esempio, delle azioni di trasferimento delle postazioni di sviluppo, di arricchimento delle funzioni tramite l’integrazione di nuove componenti nei sistemi esistenti, di cambiamento degli ambienti operativi, di consolidamento delle piattaforme di esercizio. Parliamo di modernizzazione di tipo tattico in riferimento, ad esempio, al passaggio dagli ambienti mainframe ad ambienti che garantiscono la totale compatibilità tra quanto sviluppato su piattaforme Windows, Unix o Linux con tool di conversione rapidi e semplici. Anche l’arricchimento delle funzioni applicative può seguire un approccio di tipo tattico, sfruttando tool in grado di “recuperare” le vecchie componenti per produrre nuovi servizi e funzionalità, cercando quindi di rispondere alle richieste dell’utenza aziendale con una scelta tecnologica non troppo invasiva e, soprattutto, applicabile in tempi brevi e con ritorni pressoché immediati.
Seguire un approccio tattico risulta vantaggioso nei casi in cui gli interventi sono ritenuti “urgenti” e, a causa di budget o risorse limitate, bisogna trovare il modo per “andare avanti”, cioè riuscire a fare innovazione anche con poco.
Abbiamo parlato di scelte e interventi “isolati” ma è ovvio che non lo siano perché anche una scelta di tipo tattico può tradursi ed inserirsi in un contesto più ampio e di visione più strategica. Per parlare di evoluzione applicativa strategica, è necessario prima di tutto capire quali sono le aree e gli interventi necessari che possono portare quel valore aggiunto in termini di maggior servizio e migliori performance.
Il punto di partenza di qualsiasi disegno strategico sta nel conoscere lo stato delle singole applicazioni, così come la consistenza del proprio portafoglio applicativo e dei suoi costi di gestione e manutenzione, correlandoli al valore generato per il business. Conoscenza che deve essere di alto livello per potersi confrontare con il top Management dell’azienda, ma anche di dettaglio per capire dove e come intervenire sul piano tecnico (in relazione alle esigenze delle Lob). Si tratta quindi di individuare le applicazioni critiche sulle quali si basano i processi aziendali, la loro complessità e le relative dipendenze per poi disegnare la roadmap degli interventi in base a priorità, fattibilità, obiettivi, ecc.

Ad ognuno la propria strada
Disegnare percorsi strategici non è cosa semplice, molte sono le variabili e non è quasi mai ipotizzabile identificare un approccio “buono per tutte le occasioni”.
La strategia più opportuna va identificata in contesti specifici e deve essere il frutto di un insieme ottimale di scelte tattiche, che unitamente connesse in un percorso evolutivo hanno tutte il medesimo e comune scopo.
Diversi sono i contesti aziendali, diversi i punti di partenza, le esigenze e i modelli di business e di governo dei processi. Quindi, diverse sono le strategie e gli approcci. In comune, però c’è il fatto che per ottenere i risultati migliori è necessario avere le giuste competenza sulle possibilità offerte dalle nuove tecnologie, disporre di una mappa sempre aggiornata dello stato del proprio portafoglio applicativo, e di una roadmap che delinei (sulla base degli obiettivi e delle richieste) le tappe del percorso di cambiamento (identificando tempi, risorse, costi, ecc.).

Leggi anche: "Modernizzazione applicativa: i vari passaggi"

Vai all’Osservatorio Modernizzazione delle applicazioni di ZeroUno

Nicoletta Boldrini

Giornalista

Articolo 1 di 5