Nell’articolo “Portafoglio applicativo: quando e come va gestito” abbiamo considerato in primo luogo, a grandi linee, i vantaggi di carattere economico e di maggiore efficienza nella risposta al business (e, in ultima analisi, di rivalutazione del ruolo strategico dell’It aziendale) che portano a considerarne l’adozione. Quindi siamo passati a tratteggiare le quattro fasi che si possono considerare propedeutiche ad una strategia di Apm e che sono comuni ad ogni progetto del genere. Vale a dire: 1) fare l’inventario delle applicazioni; 2) individuare e raccogliere le metriche relative; 3) definire una metodologia per l’aggiornamento periodico delle stesse; 4) stabilire assieme al business i criteri che guideranno dal punto di vista dell’azienda e della sua organizzazione la trasformazione del portafoglio applicativo. In questo articolo tratteremo invece del vero e proprio sviluppo di un progetto Apm e degli strumenti che si possono usare a questo scopo, appoggiandoci ancora una volta all’indagine svolta sul tema Apm da Forrester Research. L’indagine, del maggio 2011, è stata effettuata tramite interviste a più di 30 aziende utenti di diversi settori (servizi bancari e finanziari, manifatture, società farmaceutiche ed enti pubblici) e ad alcuni primari fornitori It in area Apm.
Il percorso che porta a realizzare un sistema di Application Portfolio Management varia, in modo anche notevole, a seconda degli obiettivi definiti dal progetto, delle risorse mobilitate e della maturità ed esperienza del team dedicato. In ogni caso, per evitare due rischi molto comuni, che sono l’essere assorbiti dall’uso degli strumenti perdendo di vista i processi e ottenere risultati anche accurati ma inutili, bisogna prima di ogni cosa effettuare un’accurata indagine presso i cosiddetti ‘stakeholder’ delle applicazioni per raccogliere le informazioni necessarie per definire le metriche del portafoglio applicativo (o di una parte consistente dello stesso) e stabilirne i metodi di aggiornamento. Gli stakeholder sono i proprietari o comunque i responsabili (lato business e lato It) dell’applicazione; gli utenti, interni o esterni; lo staff di supporto e manutenzione e così via. In breve: chiunque abbia un qualsiasi interesse a che l’applicazione funzioni al meglio. A costoro si dovrà chiedere quali sono gli aspetti che contano per la risposta dell’applicazione ai suoi bisogni e in che scala d’importanza vanno considerati.
Questa raccolta d’informazioni è fondamentale per stabilire, in funzione del valore attribuitovi dagli stakeholder, quali siano le applicazione realmente ‘core business’ e dove vadano modernizzate e va condotta in modo continuato o almeno periodico a seguito degli aggiornamenti introdotti nel parco applicativo. Si può fare con un comune spreadsheet, attribuendo pesi diversi alle risposte date in modo da stabilire una scala d’importanza dei cambiamenti da fare, ma Forrester suggerisce l’uso di un programma di collaborazione, tipo SharePoint, che permette di condividere le informazioni ma dà il vantaggio di poter mantenere separato il dominio informativo del business da quello della funzione It.
Ma per quanto questo lavoro vada fatto prima di ogni altra attività (soprattutto prima che un’applicazione vada in produzione e prima che abbia un processo di disaster recovery) si raccomanda di non affrettarsi a raccogliere informazioni prima di avere ben chiaro come farne uso, per non dimenticare elementi utili o, al contrario, registrarne di irrilevanti.
Gli strumenti di analisi e il loro uso
Se l’indagine presso gli stakeholder dà opinioni soggettive sugli aspetti tecnologici e funzionali delle applicazioni e sul valore che questi hanno per il business, gli strumenti di application mining traggono dall’analisi del codice sorgente dati oggettivi per decidere l’aggiornamento dell’applicazione. Si tratta di due approcci opposti, il primo di tipo top-down e il secondo bottom-up, che proprio in quanto tali risultano complementari ed utili entrambi ai nostri fini.
Gli strumenti di mining si dividono in due grandi categorie, a seconda che indirizzino l’analisi di singole applicazioni o di un portafoglio applicativo. I primi (Application analysis) servono agli sviluppatori per stabilire lo ‘stato di salute’ di un’applicazione e per valutare l’impatto di un eventuale cambiamento. Attraverso il controllo e l’analisi del codice generano metriche sulla sua struttura e sulla sua aderenza agli standard di qualità, sui function point e così via. Servono a stabilire se e come aggiornare una data applicazione e il loro impiego va quindi visto più in chiave tattica che strategica, anche se continuando a modernizzare le applicazioni si finisce per migliorare l’intero portafoglio. Gli strumenti di Portfolio analysis hanno invece repository che permettono di misurare più applicazioni contemporaneamente e trarne indicazioni di tendenza e di benchmarking.
Cambiano quindi anche i criteri di valutazione: per l’analisi applicativa basta verificare che lo strumento copra le tecnologie in uso (linguaggi e framework di programmazione e loro combinazioni con i Dbms) e se possa anche analizzare job control e job scheduling. Per gli strumenti d’analisi di portafoglio va invece considerata la ricchezza dei data model e la flessibilità dei sistemi di reporting, dato che si devono poter adattare dinamicamente a nuove esigenze. In particolare, bisogna verificare la capacità di espandere i data model a fonti esterne, come i configuration management database, l’help desk (gestione incidenti), gli organigrammi (ownership delle applicazioni) e così via.
Gli strumenti di application mining vengono impiegati in primo luogo nell’assessment del parco applicativo, generalmente in combinazione con le metodologie di survey e analisi customizzate che costituiscono il valore aggiunto dei vendor che forniscono questo tipo di servizio. Un secondo campo di applicazione è poi nei programmi di portfolio management di grande portata, specie se interessano un numero elevato di applicazioni sviluppate in casa e ad hoc. Qui servono a creare un repository d’informazioni necessarie ad accelerare e rendere più accurati i cambiamenti e a sostituire conoscenze che si sono perse con l’avvicendamento degli addetti all’It.
Vi è poi una famiglia di strumenti di analisi che ha finalità analoghe ai tool di Apm ma anziché rivolgersi alle applicazioni si applica a progetti e programmi. Gli strumenti per il Project portfolio management (Ppm) hanno capacità di demand management e di gestione delle risorse che si integrano perfettamente con gli obiettivi di un programma di Application portfolio management. Hanno inoltre funzionalità metodologiche, di workflow e, talvolta, anche di gestione economica, che sono cruciali per poter affrontare progetti complessi ed intercollegati ma risultano comunque utili anche nell’Apm.
L’implementazione del Ppm segue passi analoghi a quella dell’Apm: si incomincia con l’inventario dei progetti e delle proposte di progetto e si prosegue raccogliendo le metriche e i dati relativi a costi, benefici, risorse e ownership. Tutte queste informazioni vengono poi analizzate per avere una visione più approfondita delle operazioni da porre in atto.
Figura 1 – La figura che riportiamo, tratta dalla citata ricerca Forrester, schematizza le sinergie tra gli strumenti Apm e Ppm e il supporto che questi ultimi possono dare a un programma di application portfolio management.
(cliccare sull'immagine per visualizzarla correttamente)
