Una migrazione al cloud si compone di tre pilastri: persone, processi e tecnologia. Troppo spesso, le organizzazioni si concentrano sul miglioramento dei processi e sull’implementazione tecnologica, ma ignorano l’aspetto umano. Molti leader ammettono che i primi due sono semplici da modificare, mentre influenzare la cultura è più complicato. Questa sessione affronta i metodi migliori per aiutare ai clienti come affrontare questa sfida. Scopri i ruoli e le responsabilità pertinenti alla fase di transizione e di post-adozione del cloud. Valuta i gap della tua organizzazione tra le capacità e le competenze richieste. Crea modelli di addestramento efficienti che portano ad un’efficace cultura DevOps.
Speaker: Danilo Poccia, Senior Evangelist, Serverless, AWS
3. Sfide alla trasformazione del cloud
Nell'adozione del cloud, la principale
sfida non è la tecnologia: sono le
persone e i processi che devono
cambiare e adattarsi.
Persone e processi
" Le 13 sfide principali
per il passaggio del
business al cloud
- Articolo di giugno 2017
"
6. Sfide
Costi elevati e
produttività ridotta
Servizio non flessibile
6 mesi per ogni release
Time-to-Market
Mesi per acquisto/provisioning
Debito tecnico
Il 60-80% di impegno
Collaborazione
Lavoro non pianificato
Interruzioni, bug, conformità
Esperienza del cliente
Difficoltà tecniche di integrazione
con altre business unit
Prestazioni e interruzioni
7. Pensa in grande, inizia con poco, vai veloce
1. Agire come una startup (che è finanziata e ha competenze nel dominio)
2. Adottare il cloud computing
3. Utilizzare lo strumento adatto per ciascun requisito
4. Utilizzare funzionalità pronte all'uso dove possibile
5. Creare un'architettura di microservizi
6. Adottare l'approccio YAGNI (You Aren’t Going to Need It, non ne avrai bisogno)
7. Implementare cultura e processi DevOps
8. Basarsi sul concetto "You build it, you own it" (lo costruisci, è tuo)
Nuovi principi
8. Nuovi principi
Pensa in grande, inizia con poco, vai veloce
1. Agire come una startup (che è finanziata e ha competenze nel dominio)
2.Adottare il cloud computing
3. Utilizzare lo strumento adatto per ciascun requisito
4. Utilizzare funzionalità pronte all'uso laddove possibile
5. Creare un'architettura di microservizi
6. Adottare l'approccio YAGNI (You Aren’t Going to Need It, non ne avrai bisogno)
7.Implementare cultura e processi DevOps
8. Basarsi sul concetto "You build it, you own it" (lo crei, è tuo)
10. Legge di Conway:
«Ogni organizzazione che progetti un sistema (definito in senso
lato) produrrà un progetto la cui struttura è una copia della
struttura comunicativa dell'organizzazione stessa».
Melvyn Conway, 1967
http://www.melconway.com/Home/Conways_Law.html
Strategia inversa di Conway:
«eliminare i silos che vincolano la capacità del team di
collaborare in modo efficace»
Jonny Leroy/Matt Simons, 2010
http://jonnyleroy.com/2011/02/03/dealing-with-creaky-legacy-platforms/
11. Impatto dell'organizzazione sullo sviluppo del prodotto
Prodotto
Sviluppo Controllo
qualità
DBA/DBE
Architettura Operazioni
Progettazione
NOC
Concetto Sviluppo Produzione
12. Impatto dell'organizzazione sullo sviluppo del prodotto
Prodotto
Sviluppo Controllo
qualità
DBA/DBE
Architettura Operazioni
Progettazione
NOC
Concetto Sviluppo Produzione
13. Impatto dell'organizzazione sullo sviluppo del prodotto
Prodotto
Sviluppo Controllo
qualità
DBA/DBE
Architettura Operazioni
Progettazione
NOC
Concetto Sviluppo Produzione
14. Impatto dell'organizzazione sullo sviluppo del prodotto
Prodotto
Sviluppo Controllo
qualità
DBA/DBE
Architettura Operazioni
Progettazione
NOC
Concetto Sviluppo Produzione
Sistema di
ticketing
17. Trasformazione del cloud AWS
Quali competenze
e capacità
servono?
Come comporre il
team di adozione?
Come strutturare i
programmi cloud?
Qual è la strategia
per distribuzione e
operazioni di
qualità?
I clienti ci chiedono la generale
logica organizzativa per tutta
l'azienda per associare le esigenze
aziendali alle capacità dell'IT,
rispecchiando i cambiamenti in
termini di agilità, integrazione e
standardizzazione che il cloud
computing ha portato nel settore
dell'IT.
Il rischio
aumenterà?
Siamo in grado di
eseguire un cloud
sicuro e conforme?
Quali sono le
priorità?
Quando
distribuire le
soluzioni?
Come progettare le
basi?
Come migrare i
carichi di lavoro?
Di quali strumenti
necessitiamo?
Qual è il nuovo
ciclo ITSM?
Qual è l'impatto
sul business?
Cosa misurare?
Come misurarlo?
18. Trasformazione del cloud AWS
Chi? Come?
Assurance?
Quando?
Cosa?
Dove?
Perché?
Perché?
Come?
Chi?
Quando?
Cosa?
Dove?
Impatto sul business, valore, costi/benefici
Modello di erogazione dei servizi: iterativo,
modulare, agile e adattabile
Competenze giuste, team giusti, partner giusti
Misurazione e bilanciamento della maturità di
persone/processi/tecnologie, comprensione dei
rischi
Architetture concettuali/logiche/di
implementazione, modelli di migrazione,
mappatura ad architetture di riferimento
Gestione dei servizi cloud, SLA/OLA, Business
Continuity, standard e policy
Assurance? Raggiungimento degli obiettivi in
termini di rischi, sicurezza e conformità
19. Quadro per l'adozione del cloud AWS
Pianificazione, creazione, gestione e
supporto per l'ambiente cloud
Linee guida per instaurare,
sviluppare e gestire un ambiente
abilitato per cloud AWS
Struttura in cui il business e l'IT
possono collaborare verso una
strategia e una vision comuni
Prospettiva
persone
Prospettiva
processo
Prospettiva
sicurezza
Prospettiva
maturità
Prospettiva
piattaforma
Prospettiva
operazioni
Prospettiva
business
20. Cloud Adoption Maturity Model
Fase 1 Fase 4Fase 3Fase 2
Esplorazione ImplementazioneAllineamento
Livellodimaturità
Proof of
Concept
Risultati
immediati
Account sparsi
Struttura ridotta
Modello
operativo per il
cloud
Innovazione
aziendale dall'IT
Ottimizzazione
dei costi
Migrazioni
importanti
Carichi di
lavoro nativi
per il cloud
Allineamento
del business
completo
Strategia cloud
Persone
Valutazione
applicazioni
Contratti
formalizzati
Ottimizzazione
21. Modello persone
Struttura
organizzativa
Ruoli e descrizioni
delle funzioni
Competenze e
capacità
Formazione e
Certificazione
Gestione del
personale
Gestione dei
cambiamenti
aziendali
Il modo in cui gestisci le persone è la parte più importante
in assoluto della trasformazione verso il cloud
22. Il percorso delle persone
Valutazione di ruolo
e competenze1
Esecuzione
4
3
Piano di
formazione2
CCoE
23. Competenze e capacità
Obiettivi
organizzativi
Capabilities
(Funzionalità)
Attività Competenze
Gestione dei costi
dell'IT
Distribuzione di servizi IT
di qualità
Miglioramento delle
funzionalità IT
Strumenti e
supporto per gli utenti finali
Descrizioni delle funzioni
Ruoli
Responsabilità
Assegnazioni
Valutazione di ruolo
e competenze1
24. Ruoli e descrizioni delle funzioni: modello RACI
R - Responsible
A - Accountable
C - Consulted
I - Informed
Valutazione di ruolo
e competenze1
25. Il talento c'è già
Ingenium: talento creativo; innovatività;
persona con capacità estremamente
brillanti e creative.
Piano di
formazione2
26. Risultato della formazione
1a formazione fornita
1.400 studenti formati
11 mesi
Applicazioni
di
produzione
Orario
2015 gen Set 2016
0
~100
Piano di
formazione2
29. Cloud Center of Excellence (CCoE)
• Definizione di un "team cloud" core
• Membership basata
sull'entusiasmo per la diversità di
ruoli
• Utilizzo di CCoE per selezionare i
team interni restanti
• Creazione di competenze interne e
sviluppo di standard cloud
3 CCoE
30. Best practice: Cloud Center of Excellence
Servizi cloud o Cloud Center of Excellence
Servizi applicativi aziendali
OperazioniInfrastruttura Sicurezza
Progettazione cloud
Architettura
aziendale
Governance
Formazione e
coinvolgimento
Cloud Business Office
Gestione dei
cambiamenti
aziendali
Finance
3 CCoE
31. Il fulcro della trasformazione dall'IT tradizionale a un "modello
operativo nativo per il cloud" è l'adozione di un modello di
distribuzione incentrato sul cliente e orientato al prodotto in tutta
l'organizzazione.
Ciò significa organizzare sulla base dei risultati, non delle attività.
Questo include non solo i team delle applicazioni, ma anche quelli
di infrastruttura, operazioni e sicurezza.
Prodotto o Progetto:
Allineamento per risultati o Attività
Esecuzione
4
32. Persone & DevOps
Persone
Elaborare
DevOps
Cambiamento del paradigma culturale
Formazione trasversale di competenze
Collaborazione e coinvolgimento dei team
su tutti gli aspetti, dalla progettazione al
monitoraggio dell'applicazione
La domanda che tutti dovrebbero porsi è:
"Nel suo stato attuale, la mia applicazione
sta fornendo valore per il business?"
Nelle organizzazioni è possibile creare un
team di abilitazione DevOps a breve
termine e ad interim
Esecuzione
4
Tecnologia
38. Che cos'è DevSecOps?
DevSecOps = accelerare continuamente questo ciclo
clienti
rilasciotestbuild
pianificazione monitoraggio
pipeline distribuzione
ciclo di feedback
Ciclo di vita dello sviluppo software
sviluppatori
39. DevSecOps e Agile
DevSecOps aumenta l'efficienza del ciclo di vita
Agile pone l'accetto su:
• Persone e interazioni anziché processo e strumenti
• Software di lavoro anziché documentazione
• Collaborazione con i clienti anziché contrattazione
• Risposta al cambiamento anziché rispetto di un piano
40. DevSecOps e Agile possono essere implementati
in modo indipendente*
DevSecOps e Agile
DevSecOps aumenta l'efficienza del ciclo di vita
Agile pone l'accetto su:
• Persone e interazioni anziché processo e strumenti
• Software di lavoro anziché documentazione
• Collaborazione con i clienti anziché contrattazione
• Risposta al cambiamento anziché rispetto di un piano
41. Amazon raggiunge velocità e agilità con i “two pizza team"
I team decentrati
e di piccole
dimensioni
Gestisci ciò
che crei
42. Individuare atteggiamenti
e comportamenti
desiderati per
un'efficace adozione del
cloud
Comunicare
atteggiamenti e
comportamenti
Allineare sistemi di
ricompensa espliciti e
impliciti
Allineare assunzioni,
formazione e
prassi di incentivi
Come influenzare il cambiamento culturale?
43. Conclusioni
• La trasformazione del cloud riguarda tanto le persone quanto
la tecnologia e i processi
• Apporta le modifiche necessarie nell'organizzazione per
ottenere l'agilità offerta dal cloud computing
• Individua le lacune in termini di competenze all'interno
dell'organizzazione
• Crea team interdisciplinari più piccoli che includano membri
dei team IT e sviluppo e altre discipline
• Vai VELOCE!