AWS Transformation Day è un evento pensato per Business e IT Decision Maker che desiderano creare sostenibili vantaggi competitivi per la propria azienda attraverso la trasformfdione digitale.
Giovedì 28 novembre, ho partecipato come uditore al AWS Transformation Day, un evento tenutosi presso la MegaWatt Court di Milano.
Abbiamo visto insieme i consigli di Jonathan Allen, AWS Evangelist, per ottenere con successo l’innovazione digitale.
Ora rielaboreremo questi pattern da un nuovo punto di vista, esaminandone i principi e benefici.
AWS Transformation Day: 4 steps to innovate
I 7 pattern che abbiamo conosciuto possono essere rimodulati in 4 mindset fondamentali:
- Break up the work (Monolith to Microservices)
- Invest in your workforce (And put them closer to your customers)
- Automate your bureaucracy (To start finishing)
- Build it in, don’t bolt it on (Assume attack and failure)
Break up the work
Obiettivo ridurre le dimensioni del lavoro, per trasformare la nostra azienda in una High Frequency Enterprise.
I principi sono:
- Multiple minor releases
- Reduce the scope of work
Occorre quindi passare da un unico rilascio annuale a multipli cambiamenti rilasciati progressivamente in produzione.
Un simile approccio è in grado di modificare le regole del gioco.
Ecco i benefici che un simile mindset conferisce all’innovazione:
- Frequent value delivery
- Smaller blast radius of risk
- Staged investments
Il primo è abbastanza self explanatory.
Il secondo fa riferimento al rischio che un aggiornamento rilasciato in produzione possa rivelarsi catastrofico. Procedere integrando piccoli cambiamenti in modo continuo riduce drasticamente il pericolo che qualcosa vada storto.
Grazie a tecniche come la Blue-Green Deployment, che consente il rapido role back a una versione precedente nel caso in cui la modifica rilasciata avesse anomalie.
Infine, il team deve possedere il diritto di rilascio, cioè la possibilità d’integrare le modifiche senza la necessaria autorizzazione di qualcuno esterno.
Invest in your workforce
Le persone sono una risorsa fondamentale.
Questo assunto pare venga spesso dimenticato dalle grandi organizzazioni.
Con un nuovo progetto all’orizzonte, il modus operandi è assumere nuove risorse.
Sbagliato.
Occorre abbandonare questa mentalità in favore di un nuovo mindset improntato sul reskilling.
I principi sono tre:
- You have the team you need – Reskilling
- Run what you build – DevOps Enabled
- Realign around customer value, not systems.
A ruota, ecco i benefici:
- Cultural shift to change as constant
- Reduce tech debt from handoffs
- Put your organization close to your customer
Il team che lavora a un prodotto deve quindi essere piccolo, decentralizzato, agile e veloce (in inglese, nimble) e avere il diritto di rilasciare in produzione modifiche.
Secondo Jeff Bezos le dimensioni dovrebbero essere contenute: abbastanza da sfamare il team con sole due pizze.
Il focus sul progetto prevede invece molte più figure, ma pur sempre contenute.
Nella descrizione di azienda tecnologicamente innovata, concorrono i seguenti concetti:
- ITIL (for operational excellence)
- Agile development
- Infrastructure automation
- Broad open source adoption
- RESTful APIs
- Virtualization
- Private Cloud
- Test Driven Development
- DevOps CI/CD
- Big Data Implementation
- Cloud experimentation
- Real-time Analytics
- Cloud Migration
- Machine Learning
- Containers/microservices
- Serverless
Automate your bureaucracy
La burocrazia è ostica al cambiamento e all’innovazione.
Occorre ridurla il più possibile e automatizzarla.
I principi di questa mentalità sono:
- Replace gatekeeping with automated controls
- Standardize on reusable building blocks
- Finished means released
I benefici chiave invece:
- Enable teams to work with agile IT assets on their own timeline
- Shorten time from idea to implementation
- Make bureaucracy lean!
Build it in, don’t bolt it on
L’innovazione è un processo interno all’azienda e non dovrebbe essere raggiunto sopra i vecchi sistemi.
A caratterizzare questo mindset, segnando un drastico punto di rottura con il passato, troviamo i seguenti principi:
- Failure experiments
- Embed compliance and security
- Make security/reliability everyone’s job
Ed ecco i benefici:
- Resilient, flexible systems
- Stems natural drift
- Builds a culture of security
Bonus: Caos Engineering
Prima di chiudere, un ultimo concetto.
In che modo le high-frequency organization sviluppano resilienza?
Ecco il principio del Caos Engineering.
Caos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system capacity to withstand turbulent conditions in production
Caso Engineering
Un caldo abbraccio, Andrea.
