Oggi, il portfolio applicativo che le aziende si trovano ad avere è frutto di anni di installazioni di soluzioni legacy o di customizzazioni e verticalizzazioni di tecnologie standard che nel tempo, proprio a causa delle personalizzazioni, sono diventate sempre meno standard.
Per non correre il rischio che si perda il controllo di applicazioni business critical, Phil Murphy, analista di Forrester individua alcuni punti da condividere:
1) Le aziende che non modernizzano ristagnano: non fare nulla potrebbe essere un’opzione (e per molti CIO è stata la scelta adottata negli anni passati nella convinzione che prima o poi le applicazioni legacy sarebbero state rimpiazzate con altre tecnologie) ma si tratta di un approccio decisamente rischioso. Il rimpiazzo tecnologico, specialmente su applicazioni core, può presentare molte incognite e richiedere tempi lunghi; anche se la strategia aziendale fosse indirizzata al rimpiazzo, le applicazioni esistenti non solo devono continuare a funzionare ma devono poter integrare il più possibile le nuove tecnologie.
2) Avere informazioni statiche serve a poco: le aziende sono consapevoli del fatto che un assessment delle applicazioni basato su informazioni statiche (raccolte magari manualmente) è poco significativo. Ciò che può davvero fare la differenza è l’analisi dinamica del parco applicativo, che consenta in modo integrato di avere informazioni dettagliate e aggiornate (anche se, sottolinea l’analista di Forrester, le tecnologie che vanno nella direzione dell’integrazione tra i tool di Application Management e quelli di gestione dinamica delle informazioni devono ancora maturare).
3) Razionalizzare è necessario, ma va fatto in un contesto di business: l’analisi delle applicazioni esistenti deve sempre essere rapportata alle esigenze espresse dalle line of business. È la rispondenza a queste esigenze che determina il valore dell’applicazione stessa e quindi è da questa rispondenza che deriva un indicatore determinante per comprendere la strada da intraprendere nel percorso di modernizzazione.
5) Proattività e planning strategico rimangono di competenza del CIO: dal punto precedente consegue che ci deve essere una vision comune, IT e top management aziendale, sulle applicazioni strategiche la cui modernizzazione va “orchestrata” in modo che segua gli strategic plans del business.
(Clicca sull’immagine per ingrandirla)
Indice degli argomenti
Modernizzazione: serve un piano di Application Management Continuum
Uno degli errori più gravi che possono commettere i Cio – sottolinea Murphy – è di considerare la modernizzazione delle applicazioni come un progetto a se stante, indipendente dalla gestione del portfolio applicativo, dalla razionalizzazione e dai piani strategici. I Cio devono invece imparare a considerare la modernizzazione come un continuum dell’Application Management (vedi figura 1). L’Application Management Continuum disegnato dall’analista, mostra la progressione della maturità della gestione delle applicazioni; ossia, fa comprendere come, in un corretto approccio strategico, ogni singola fase legata alle applicazioni (modernizzazione, razionalizzazione, gestione, piano strategico) sia strettamente correlata alle altre e non uno step a sé stante. Partendo proprio dalla modernizzazione, Murphy spiega come queste fasi siano collegate e cicliche.
1) La modernizzazione delle applicazioni legacy può essere vista come una delle possibili scelte legate alle applicazioni esistenti in azienda (scelte che l’analista definisce “destini” delle applicazioni e sono: lasciare tutto com’è; modernizzare; rimpiazzare; dismettere – figura 2). Scelte che fanno capo all’It e che hanno una stretta correlazione con la razionalizzazione.
2) Bisognerebbe adottare un application portfolio management che possa fornire informazioni intelligenti sullo stato del parco applicativo e consenta quindi di raccogliere metriche di valutazione. Metriche che verranno poi usate anche per definire e pianificare la razionalizzazione (e quindi anche la modernizzazione).
3) Ed è proprio con la razionalizzazione basata su informazioni e metriche adatte che si può pensare alla modernizzazione e, più in generale, alla definizione di piani strategici.
(Clicca sull’immagine per ingrandirla)
Le raccomandazioni ai CIO
Murphy riconosce che mentre è facile vedere “sulla carta” l’effetto dell’Application Management Continuum, non si può dire che sia semplice attuare questo approccio. Tuttavia, l’analista suggerisce di utilizzare questo schema per identificare qual è il livello di maturità della propria azienda in relazione all’Application Management Continuum. Cioè capire quanto queste fasi sono correlate e integrate e, quindi, cosa fare per raggiungere uno stato di efficienza maggiore. Seguendo comunque alcune raccomandazioni:
1) Smettere di dare giustificazioni tecniche: “Perché l’It dice che è necessario” non è più una giustificazione valida e sufficiente per fa si che gli uomini di business approvino automaticamente gli sforzi di migrazione/modernizzazione. Portare al top management giustificazioni business, che facciano capire il valore dell’operazione seguendo i quattro pillar fondamentali del Tei (Total Economic Impact): costi, benefici, rischi, flessibilità.
2) Disegnare il proprio livello di maturità nell’application management all’insegna della continuità: ogni azienda adotta un proprio percorso verso la modernizzazione; essa può essere anche tattica e gestita a fasi a seconda delle necessità incombenti. Ciò che però può davvero aggiungere valore al business, è la garanzia che questi singoli progetti siano inseriti all’interno di un modello di application management (in modo che si possa avere la visione degli eventuali prossimi step).
3) Far leva sui vendor: progetti di modernizzazione su larga scala richiedono assistenza in relazione alla modernizzazione delle soluzioni (modernizzazione dal punto di vista tecnico), alla loro migrazione, ai tool e ai servizi utilizzabili. L’aiuto dei vendor IT può rivelarsi utile per: lavorare insieme all’introduzione di nuove tecnologie; sfruttare la loro esperienza legata alla migrazione di piattaforme, database, linguaggi di programmazione, ecc.; gestire progetti di vasta scala (attraverso framework e best practice fornite direttamente dai vendor e con l’ausilio di business cases).
