DevOps è diventato ormai il killer-approach per la delivery di soluzioni che siano in grado di avere un basso time-to-market e ottimizzare l’intero value stream aziendale annesso.
Devo ammettere che da sempre considero DevOps la naturale estensione dell’Agile, con una positiva contaminazione dei principi Lean (che ricordo sono derivati dal mondo manifatturiero), cosa che mi porta ad amare poco il termine “DevOps” in sé perché, almeno lessicalmente, sembra limitare il tutto ai Developer ed agli Operation oltre che all’ambito IT.
Detto questo, è importante evidenziare che DevOps non “appartiene” solo al mondo dell’IT, bensì è un approccio che spinge a far propri i 3 principi portanti: Flow, Feedback e Learning (così come sono oggi riformulati rispetto alla prima enunciazione), per un’azione efficace nella creazione di Servizi e Prodotti negli ambiti più diversi. A tal proposito segnalo l’interessante approfondimento degli amici di AgileReloaded: L’orizzonte allargato di Agile.
Resta comunque indubbio che l’IT è la culla di DevOps, trasformando gradualmente le azioni annesse allo sviluppo di soluzioni complesse da attività “artigianali” ad attività più “ingegneristiche”, con precisi elementi di riferimento. Ciò fa si che le aziende percepiscano sempre più il proprio IT per quello che deve essere: un Asset strategico al servizio del Business e non un Centro di Costo.
E le parole sono estremamente importanti: parlare di “divisione IT” porta ad immaginare un Silos a sé stante con regole proprie e ben identificabili. Ciò è quanto di più semplicistico si possa immaginare perché l’IT è estremamente pervasivo e condiziona, restandone a sua volta condizionato, tutte le aree aziendali.
La centralità di DevOps, anche se non del tutto maturata nel nostro contesto nazionale, è confermata da un’indagine di IDC che oggi ne vede l’adozione in oltre il 70% delle principali aziende mondiali (con livelli diversi e penetrazione diversa) e stima il superamento della soglia dell’80% entro il 2019.
Ma questa penetrazione così profonda, quali sfide comporta?
Anche qui dobbiamo avere una visione olistica del contesto poiché molte aziende che provano a sperimentare DevOps su un progetto pilota o un’area di riferimento, si accorgono rapidamente che è necessario coinvolgere tutte le diverse funzioni aziendali, per cui lo Scaling diventa inevitabile e anche estremamente veloce.
Ma torniamo alla nostra precedente domanda, andando ad evidenziare le sfide primarie che ogni azienda incontra nell’adozione concreta di DevOps e, quindi, nel profondo percorso di trasformazione e cambiamento Culturale:
- Sponsorship aziendale: adottare DevOps significa investire e avere pazienza nell’ottenere risultati tangibili localizzati a breve termine, ma complessivamente visibili nel medio termine. L’investimento è sia in termini finanziari che in termini di impegno delle Persone (vi prego… non usate il termine “risorse” per indicarle!), per cui solo se è uno dei massimi dirigenti aziendali (CxO) a supportarla, l’adozione potrà avere il sostegno necessario e raggiungere risultati lusinghieri;
- Abbandonare le rigide strutture di controllo del passato: una Cultura volta al continuo miglioramento, basata su applicazioni empiriche, mal si lega con una organizzazione aziendale basata sul pattern command-and-control, in cui è difficile cambiare. I manager devono imparare a delegare, mentre le linee più operative ad avere coraggio, cercando di rendere la struttura più flessibile ma soprattutto focalizzata sul value stream;
- Il Core know-how deve essere in azienda: considerare l’IT un “centro di costo” ha portato negli anni ad abusare dell’outsourcing, perdendo conoscenza, controllo e capacità di gestire le nuove sfide di mercato. Questa tendenza deve trasformarsi in un’outsourcing bilanciato in cui gli elementi chiave, per rispondere efficacemente e prontamente al Business, sono all’interno e ci si appoggia ad un’outsourcing controllato per gli elementi corollari (abbiamo parlato abbondantemente di questo aspetto nella serie DevOps and Outsourcing: OutOps);
- Ridurre la resistenza al cambiamento: DevOps è Cultura, e una trasformazione aziendale nella sua direzione comporta nuovi modelli organizzativi, nuovi ruoli e un diverso approccio alle prospettive di carriera. Questi aspetti spingono ad aumentare la resistenza al cambiamento per restare nella propria “confort zone” e ridurre al minimo la necessità di rimettersi in discussione. È compito dell’organizzazione fare chiarezza su questi aspetti e creare le opportunità a sostegno dei desideri intersechi (leggasi Management 3.0) ed estrinsechi di ogni singolo collaboratore;
- Fail Fast o meglio… Learn Fast: il fallimento è una componente poco desiderata ma fortemente presente, e a volte indispensabile, nel mondo dei sistemi complessi. Il mantra non deve essere: “non fallire mai…” ma “fallire il meno possibile e quando accade far tesoro del fallimento stesso”. In pratica ogni fallimento diventa un tassello nel cambiamento e nell’ottimizzazione complessiva… chiaramente questo non vuol dire fallire sempre!
- Mai applicare qualcosa “out-of-the-book”: DevOps è un cambiamento culturale da ricamare nel proprio contesto e come tale necessita di essere capito profondamente nelle sue varie sfaccettature. Non basta comprare un libro e leggere qualche blog per iniziare la propria trasformazione: il rischio di fallimento è estremamente elevato! Meglio affidarsi al supporto di professionisti che accompagnano l’organizzazione a muovere i primi passi e ad individuare gli elementi focali che consentono affacciarsi al mondo DevOps con maggiore fiducia e minori incertezze.
Se tutto questo vi spaventa o vi fa tornare nel “vostro mondo” fatevi una domanda: possiamo permetterci di non cambiare quando tutto sta evolvendo ad un ritmo frenetico ed inarrestabile?
In fondo bisogna lasciare andare il passato per essere padroni del futuro.
Stay tuned J