Con gli esercizi di taglio di budget cui la recessione costringe i Cio, oltre alla revisione del portafoglio applicativo, diventa prioritario riconsiderare e “modernizzare” il concetto stesso di Application Lifecycle Management, come disciplina e come processo. Già a novembre 2009 Gartner aveva lanciato l’allarme dal palco di Cannes con quell’ “Alzi la mano chi non ha abbastanza applicazioni”, di Andy Kyte, Vp e Gartner Fellow; e prima ancora (ottobre 2008) Phil Murphy, Principal Analyst, Forrester consigliava di “Guidare le decisioni di investimento nell’Alm, classificando le business application in classi orientate all’azione”. Azione in estrema sintesi riducibile a una terna: mantenere, rimpiazzare o dismettere; laddove nella classe “mantenere” si sceglierà volta a volta pragmaticamente l’opzione tecnologica appropriata fra razionalizzare, standardizzare, modernizzare o semplificare; mentre opzioni tipiche della classe “rimpiazzare“ sono outsourcing o sostituire con un “commercial off the shelf (Cots)” o un Saas. Sottintesa una strategia di autofinanziamento: recuperare capacità dalla somma dei Tco risparmiati, trovando risorse per rispondere alla domanda 2011. Una strategia in cui il risparmio su un Tco residuo (eliminato o ridotto) va però misurata come caso di business, dato che anche nella gestione di un ciclo di vita applicativo “non si può cambiare (in questo caso risparmiare) ciò che non si è in grado di misurare”. Insomma, almeno nella maggioranza dei casi, le azioni di investimento sono un eufemismo Forrester per azioni di disinvestimento.
Alm: revisione di scopo ed evoluzione di metodologie
C’è quindi una rifocalizzazione concettuale del processo stesso di Alm. Intanto il problema va diviso in due, ci dice Forrester: c’è un Application Lifecycle Management riferito alla sola Gestione dello sviluppo di una business application (dai requirement alla messa in produzione), tanto che “sarebbe meglio parlare di Application Development Lifecycle Management, Adlm”. E c’è il Ciclo di vita applicativo vero e proprio (Application Lifecycle), che invece descrive e traccia utilità funzionale e valore residuo o obsolescenza della business application in produzione. Dunque occorre anzitutto rivisitare l’Application Lifecycle Management da due punti di vista.
Il punto di vista Application Lifecycle, deve valutare utilità funzionale contro obsolescenza, identificando le “azioni di (dis)investimento” accennate, almeno per le applicazioni più rilevanti. In modo che, business case alla mano, si arrivi a una ristrutturazione del portafoglio applicativo utile a due obiettivi: evitare una distribuzione di tagli a pioggia e recuperare capacità.
Dal lato dello sviluppo (Adlm), il discorso invece si fa meno direttamente economico e più tecnologico, ruota attorno a come sfruttare realisticamente l’evoluzione delle metodologie. Adlm è l’erede dello storico Systems Development Lifecycle, che Adlm ha arricchito di tutta una visibilità funzionale al business sull’intero percorso dai requirement alla produzione. Ma appunto ne ha ereditato il governo dei processi usati per lo sviluppo e, crucialmente, le metodologie formali (dalle varietà “storiche” di Waterfall e di Iterative, alle più moderne di Model driven e Agile, vedi “Agile: un ponte fra business e It”. Il punto è che le metodologie di sviluppo sono decisive per la produttività, soprattutto a tendere: da un lato c’è la promessa di valore di Agile, riconosciuta aver ormai raggiunto una maturità mainstream, ma dall’altro c’è da fare i conti con la realistica capacità di adottarla da parte dei System Integrator e a maggior ragione delle aziende loro clienti, abituate, anche processualmente ed organizzativamente, a Waterfall o Iterative.
Progetti di sviluppo con i System Integrator: capacità di adozione della metodologia Agile
La metodologia di sviluppo Agile ha indubbiamente una forte attrattiva per due capacità intrinseche: primo, produrre software di qualità più velocemente, il che si traduce nell’adattabilità a inseguire i cambiamenti del business (basti pensare al processo di sviluppo spezzettato operativamente in team interfunzionali, ciascuno con un committente business, ma con un coordinamento unico, avulso da strutture aziendali e concentrato sull’obiettivo di realizzare un’applicazione adattativa a contesto e circostanze). Secondo, gestire il rischio dello sviluppo, contenendo gli impatti di scelte errate (figura 1): quando c’è una generale mancanza di chiarezza e un alto numero di incognite, un metodo basato su piccoli sviluppi sperimentali favorisce nei team di sviluppo una miglior comprensione dei problemi, con osservazioni che portano a correzioni di rotta, ivi compreso una cancellazione. Se un progetto si rivela sbagliato, è solo un vantaggio che venga chiuso e rilasci risorse, proprio perché “al crescere del valore del software da produrre, un aborto lento del progetto che non produce bene è un lusso che non ci si può più permettere”.
Figura 1 – Managing Risk is a Key Motivation to Move to Agile Methods
(cliccare sull'immagine per visualizzarla correttamente)
Ma ci sono almeno due ordini di inibitori nel migrare ad Agile: il primo è squisitamente tecnologico: scegliere nel coacervo di metodologie Agile quale (o quale combinazione) adottare fra Scrum, Agile Modeling, Feature driven development, Test driver development, Extreme Programming, per limitarci alle più gettonate non è semplice. E a monte scegliere la stessa strategia di adozione: scartando un irrealistico sforzo di migrazione ad Agile dell’intero sviluppo aziendale, probabilmente una forma di coesistenza governata fra isole aziendali che comincino a sperimentarla, e altri sottoinsiemi in cui le consolidate metodologie tipo Waterfall (Waterfall, Cmmi, Iso9000) o Iterative (Spirale, Rational Unified Process, Sviluppo iterativo) quantomeno permangono più a lungo.
Il secondo inibitore sta nella capacità (o almeno nella velocità) d’adozione di metodologie innovative da parte degli stessi System Integrator, cui le aziende clienti si rivolgono. In proposito il richiamo di Forrester suggerisce cautela.
Il Manifesto Agile descrive interazioni collaborative, cambi rapidi, e la frequente produzione di software funzionante, in luogo delle fasi formali di processo, della documentazione definita, e della forte enfasi sulla pianificazione (vedi figura 2). È evidente un impatto al consolidato modo di operare con cui sono organizzati i System Integrator e le stesse aziende clienti, per non parlare dell’intuibile problema per lo sviluppo, di reclutamento di risorse e competenze nuove e/o di skill upgrade delle esistenti.
Figura 2 – Conflict Between Agile Manifesto and Vendor Approaches
(cliccare sull'immagine per visualizzarla correttamente)
Non deve sorprendere dunque che le metodologie di sviluppo dei System Integrator restino ancorate per un 55% al tradizionale e all’iterativo, contro un 34% per la comunità di sviluppo in generale (vedi figura 3) emerge un loro “ritardo” rispetto alla Comunità di sviluppo in generale nell’adottare metodologie innovative.
Figura 3 – SIs Lag in Agile Adoption Compared With the Broader Development Community
(cliccare sull'immagine per visualizzarla correttamente)
E’ vero che c’è un numero (minoritario) di System Integrator già “specializzati” nell’uso di metodologie formali Agile. Ma è soprattutto vero che la maggioranza si avvicina all’ “agilità” su una linea di compromesso e di ibridazione, che non scardini il loro rapporto con l’organizzazione cliente. Magari comincia ad applicare principi Agile, ma discostandosi dal modello del Manifesto: ad esempio, piuttosto che sempre e solo rigorosamente software funzionante da provare, forniscono un prototipo. O viceversa mantengono una diversa metodologia, ma si accostano a tecniche Agile in situazioni in cui conviene (quando c’è un team, un problema e una forte dose di rischio). Un trend emergente è usare approcci Agile per lavoro di manutenzione, dove ben si presta l’orientamento ai frequenti rilasci di Agile, e la sua backlog best practice aiuta. E’ significativo (figura 4) che per un progetto in genere i System Integrator vedano “Agile come la metodologia favorita in molte parti” (sviluppo del core applicativo o di sistema, project management, requirement, interfaccia utente, integrazione, test: tutte riscuotono il favore di 12 o più System Integrator su 14).
Figura 4 – Systems Integrator Report Using Agile For Many Different Project Types
(cliccare sull'immagine per visualizzarla correttamente)
