Il cloud: moda tecnologica o strumento di business?
19/05/2020
Il Cloud non è più una tecnologia di frontiera, ma è strumento di tutti i giorni, soprattutto in questo periodo. Tuttavia, come tutte le strategie di Aton, la scelta di usare il Cloud non è l’inseguimento di una moda, ma una precisa scelta di business, ragionata sui termini della strategia aziendale. Vediamo perché.
Uno dei principali impatti dell’adozione delle tecnologie cloud è certamente il cambiamento del modello dei costi di un progetto. In un progetto tradizionale, bisogna inizialmente calcolare un insieme di risorse, misurarle su di un ipotetico consumo di picco, acquisirle ed impegnarle per una durata ipotizzata di utilizzo. Ci sono molte incertezze e molte incognite, amplificate dalla volatilità del mercato odierno, anche in situazioni migliori della contingente. In un progetto in cloud, invece, le risorse sono consumate giorno per giorno, tariffate per ora (o meno) di effettivo utilizzo e fatturate di mese in mese. Spesso, la loro allocazione può essere modificata momento per momento, inseguendo (anche automaticamente) il profilo della domanda di prestazioni.
Certo, è sempre necessario fare qualche ipotesi per scegliere gli strumenti più adeguati e per avere un’idea dei costi mensili; ma cambiare direzione in corsa è semplice ed economico: se una risorsa è poco utilizzata, la si riduce o la si elimina, e non la si paga più; se una risorsa è molto utilizzata, calcolare il ROI del suo impiego o del passaggio ad una architettura differente è facile, e si basa su dati certi.
Il cloud trasforma allocazioni di CAPEX fatte su ipotesi azzardate, in voci di OPEX che possono essere studiate con metodi numerici su dati reali, ed essere modulate con cognizione di causa.
Le risorse in cloud, immateriali nella loro consistenza, non vanno maneggiate “a mano” ma si esprimono al meglio guidate da processi automatici che riducono le occasioni di errore e costruiscono catene del valore. La costruzione di una versione per la consegna non è una cerimonia dove qualcuno segue una serie di passi documentati all’inizio del progetto, ma un processo automatico, “programmato” secondo le esigenze del progetto e in grado di evolvere con esso; prende ogni modifica del codice, la tratta secondo le sue caratteristiche, e la va a depositare dove deve trovarsi perché possa essere messa facilmente in test, oppure in produzione. Eventualmente, anche questo in questo caso con un altro automatismo, se possibile.
Al posto di un documento ideale che troppo facilmente può scollarsi dalla pratica quotidiana, la costruzione del software e l’erogazione del servizio sono accompagnate a diventare una catena del valore, che parte dal requisito tracciato, che diventa modifica o aggiunta nel codice o nella configurazione del prodotto, che diventa artefatto installabile e in grado di produrre valore. Tutto questo in un ciclo dove si può, con cognizione e controllo, decidere dove investire e quale arco accorciare o modificare; in ogni momento, a seconda delle esigenze del progetto. E dove la conoscenza è certa, letteralmente “codificata” nelle istruzioni che pilotano la costruzione del software, e come il resto del codice custodita, tracciata nella sua evoluzione e accessibile a chiunque si avvicendi nel team di sviluppo.
Da costo per progetto, a investimento di prodotto, a consumo per utente.
I termini di servizio a cui gli utenti sono sempre più abituati, per l’esperienza con i prodotti/servizi consumer, cominciano ad interessare anche la clientela business. Sempre più spesso le aziende preferiscono allocare risorse in reparti di ricerca e innovazione, piuttosto che in centri di costo di IT strutturale, e diventa così sempre meno insolito che un progetto non abbia delle risorse interne al cliente dove appoggiarsi per l’esecuzione, ma invece la richiesta sia di un prodotto fruibile senza impegno amministrativo, con un canone a consumo. Per chi sviluppa questa richiesta si traduce in una spinta potente verso un’organizzazione di prodotto il più possibile configurabile sulle esigenze del cliente, ma che deve poter essere eseguito consumando risorse in modo comparabile con quanto il cliente è disposto a pagare o ha bisogno in quel momento. È vero che la sfida è grande, ma la possibilità di ampliare la platea dei clienti verso le dimensioni più piccole (ma anche verso le molto, molto grandi) e le efficienze in innovazione che si possono (e si devono) ricercare per ottenere questo risultato sono un premio assai allettante, quando non un imperativo per competere con efficacia.
La sinergia fra la richiesta di flessibilità da parte dei clienti e le innovazioni possibili sfruttando il cloud al meglio cambiano profondamente la catena del valore del produttore di software, ma lo spingono anche a evolvere ad un nuovo livello di efficienza nell’esecuzione e di comprensione del suo business.
