AWS Transformation Day è un evento pensato per Business e IT Decision Maker che desiderano creare sostenibili vantaggi competitivi per la propria azienda attraverso la trasformazione digitale.
Giovedì 28 novembre, ho partecipato come uditore al AWS Transformation Day, un evento tenutosi presso la MegaWatt Court di Milano.
Questo è quello che ho appreso.
AWS Transformation Day: Culture over technology
Ad aprire le danze, Jonathan Allen AWS Enterprise Strategist & Evangelist.
Tralascio i convenevoli e vado dritto al punto: l’innovazione, anzi la trasformazione digitale deve prima essere culturale e solo in seconda fase tecnologica.
Per realizzare con successo questo cambiamento dobbiamo mettere in pratica alcuni pattern.
Vediamoli assieme.
Ricordo che questo, è sopratutto un post con consigli operativi.
IT Spectrum
Definiamo un concetto che chiameremo Enterpise IT spectrum.
L’Enterpirse IT Spectrum è banalmente un grafico che visualizza la frequenza dei rilasci che un’azienda fa del suo prodotto nel corso di un anno lavorativo.
Lo spettro di un’azienda innovatrice e di successo ha molte creste distribuite uniformemente, sul grafico in azzurro chiaro.
Quello di una obsoleta, ha l’aspetto di un’unica onda, sul grafico arancione chiaro.
Per innovare, e farlo davvero, serve il primo spettro. La domanda diventa allora come possiamo svilupparlo?
La risposta è attraverso una serie di modelli, o pattern.
Ecco quali.
Sizes
La caratteristica comune delle tradizionali aziende dal mindset fisso e antiquato è quella di focalizzarsi su una grande visione, rilasciando una modifica all’anno.
Big vision, single major release.
La mia professoressa di lettere direbbe: “no buono!”
Il primo pattern prevede allora la sostituzione di questo schema operativo con una nuova mentalità: microservizi e piccoli cambiamenti frequenti
Small steps, multiple minor releases
Questo implica la scomposizione del lavoro in piccole unità indipendenti che devono essere rilasciate in finestre ti tempo brevi, anche due settimane.
Questo è il primo pattern:
from big bets to reduce batch size and frequency of releases
Bravery
Il secondo pattern richiede un cambio di mentalità ancora più profondo.
Offuscati dalla paura di commettere errori i Decision Maker preferiscono proteggere il core business evitando l‘integrazione continua.
Oggi, grazie alle numerose tecnologie del cloud è possibile integrare modifiche e rilasci in assoluta sicurezza.
Il secondo pattern che abbiamo imparato conosciuto all’AWS Transformation Day è quindi:
from protecting the core business to safely continuous integration
Data
Quando deve essere presa una decisione, negli uffici delle grandi aziende si cerca l’individuo responsabile: il decision maker.
Così è stato coniato il termine HiPPO (Hihghet Paid Person’s Opinion), proprio in riferimento alla tendenza che un impiegato ha di fare affidamento all’opinione data dalla persona con la busta paga più alta dell’ufficio.
Col tempo questa espressione è andata a descrivere l’affidamento di una azienda all’istinto umano, soggettivo e suscettibile di errori, anziché ai più oggettivi dati.
Airbnb insegna infatti che i dati “sono la voce del cliente, e la data science ne è l’interpretazione”.
I dati sono fondamentali, lo sono sempre stati.
La differenza è che oggi è possibile analizzarli velocemente, grazie anche a sofisticate tecnologie di data analysis.
La decisione deve quindi essere conseguente all’analisi dei dati, solo così può essere testata e misurata.
Ecco il terzo pattern:
from HiPPO-based to Data-driven decision-making.
Sharing
Capita sovente che la parola d’ordine nelle aziende sia compartimentazione: “io mi tengo le mie informazioni e te le tue”
Tutti felici, e l’azienda muore.
Introducing: The Silo Mentality
La Silo Mentality è un modus operandi tipico delle organizzazioni grosse ancorate a un mindset arretrato.
Il sintomo principale è la mancata condivisione d’informazioni, quali obiettivi, strumenti, priorità e processi, tra dipartimenti e gruppi manageriali.
Rompere questa mentalità è fondamentale per la longevità dell’azienda.
Il quarto pattern è quindi:
from Business and IT Silos to Teams that span business and technology
Agile
Uno dei principi cardine della metodologia Agile è:
Simplicity – the art of maximizing the amount of work not done – is essential
Agile Manifesto
Massimizzare l’ammontare di lavoro non svolto è fondamentale.
Detto in altri termini, occorre massimizzare l’ammontare di tempo svolto a non fare del lavoro inutile.
Quante belle negazioni.
Prendi Excel.
Hai presente quante diamine di funzioni ha? Certo che no.
Probabilmente ne avrai usate solo il 20%, per fare l‘80% del tuo lavoro. L’amato principio di Pareto torna sempre.
Secondo questo principio della metodologia Agile Microsoft dovrebbe allora soffermarsi sulle feature necessarie anziché su quelle che sarebbe bello avere.
Definite le prime, mettiamo le seconde nel cesto del “lavoro non svolto”.
Cosa dicevamo prima? Ripetilo con me… “dobbiamo massimizzare il lavoro non svolto”.
Ecco, ora è tutto più chiaro.
Dobbiamo quindi passare dallo sviluppare feature probabilmente poco utili all’identificare quelle di vero valore, procedendo continuamente all validazione della loro rilevanza.
All’ AWS Transformation day il quinto pattern è quindi stato:
from large feature sets to constantly validating for relevance
Qui trovi un delizioso approfondimento.
Test
Testare è una parola fondamentale.
Quando diventa soggetto delle frasi proferite dai Business Decision Maker delle organizzazioni obsolete, iniziano a tremare le sedie.
In passato testare avrebbe significato investire tempo e risorse, compiendo un salto nel vuoto e rischiando molto.
Oggi, grazie alle tecnologie che il Cloud mette a disposizione è possibile testare un prodotto in pochi giorni, validando rapidamente un’idea con una spesa irrisoria.
Occorre quindi passare dallo sviluppo di sistemi lenti e complessi, al test agile e veloce (in inglese, nimble) che prevede la drastica riduzione del tempo che intercorre tra un’idea e la sua implementazione e messa a terra.
Un esempio pratico?
Il team di AWS, sfruttando alcuni tra i 150 e oltre servizi della Cloud Console, è riuscito a creare una demo funzionante di un sistema per il tracking in tempo reale di un videogioco di corse.
Decine di metriche erano collezionate sulla macchina locale e inviate attraverso un sistema di Gateway e Lambda Function a un applicazione React hostata in cloud.
Tutto questo in 2 giorni.
In generale, ecco il sesto pattern:
from processes that aren’t nimble to reducing the idea-implementation time
Train
Prepariamoci al peggio.
Smettiamo d’ipotizzare la soluzione migliore, il best case scenario è per le storie di fantasia.
Alleniamoci a gestire situazioni di rischio preparando i nostri sistemi a resistere in caso di failure.
Un sistema cloud deve essere costruito tenendo a mente il cambiamento come caratteristica anziché eccezione.
In questo modo il codice deve arrivare a essere più flessibile e affidabile dell’infrastruttura sulla quale è rilasciato.
Il focus non deve essere solo sulla protezione in caso di fallimento della rete ma anche per possibili attacchi esterni.
Da questo punto di vista il modello è di particolare rilevanza per gli sviluppatori IoT, i cui device sono facilmente attaccabili da potenziali intrusi.
Proteggere la rete diventa qui un’operazione fondamentale e di essenziale rilevanza.
Il settimo pattern in una frase:
from planning for best case operating state to assuming attack and failure
Con questo abbiamo concluso i 7 pattern presentati da Jonathan Allen al AWS Transformation Day di Milano
Un caldo abbraccio, Andrea
