Con questo post iniziamo una mini-serie di articoli (presumibilmente 3) dedicati ad esplorare una tematica sempre più comune: DevOps e il mondo outsourcing.
Senza alcuna pretesa di dare una “ricetta pronta all’uso”, vedremo gli aspetti cruciali annessi alle situazioni in cui lo sviluppo viene esternalizzato e come possiamo adottare DevOps in questi ambiti, parlando di alcune strategie di successo.

DevOps and Outsourcing: OutOps

Come ci sforziamo da tempo di evidenziare, DevOps è prima di tutto un approccio culturale, così come sintetizzato dalla definizione seguente:

 Culturale in cui l’intera Line of Business si assume la responsabilità della creazione di Valore per il cliente.

Developers e Operations sperimentano continuamente nuovi modi di lavorare insieme, andando a standardizzare e padroneggiare i processi attraverso la ripetitività e la pratica [cit. FP]

Tutto interessante, di valore e dai forti riflessi applicativi pratici, ma…. come sempre, purtroppo, esistono situazioni in cui tale livello di integrazione tra “Dev” e “Ops” non è concretamente realizzabile per il semplice fatto che l’azienda ha adottato una strategia di outsourcing (totale o predominante) delle attività di sviluppo.

In pratica, i “Dev” non ci sono proprio!

Quindi si potrebbe, a primo acchito, essere tentati nell’affermare che: “DevOps non è applicabile nei contesti fortemente caratterizzati dall’outsourcing”.

Se questa affermazione d’impeto ha dei fondamentati (di cui discuteremo a breve), la realtà, fortunatamente, non è nera o bianca, ma esistono diverse possibilità per applicare DevOps con successo anche in questi contesti, proprio perché si tratta prima di tutto della capacità di cooperare perseguendo un obiettivo comune.

Infatti, è come se la parte di “Dev” diventasse un “artefatto” da incastrare nel proprio processo di delivery, gestendo sempre l’ottimizzazione del flusso complessivo delle attività, in contrapposizione alla logica dell’ottimizzazione locale tipica degli approcci tradizionali.

Per indicare questo scenario, andremo a coniare uno specifico acronimo: OutOps (Outsourcing & Operations).

Va specificato che si potrebbe avere anche il caso duale, ovvero “Dev” interno e “Ops” esterno, dando vita a un ipotetico DevOut (Development & Outsourcing). Questo caso è però molto più raro nella realtà, perché tipicamente la governance della infrastruttura è quasi sempre interna alle diverse aziende, indipendente dal fatto che l’hardware sia in-house, gestito da terze parti o in cloud. Infine, il caso di Out-Out, in cui tutto è in outsourcing, ci porta nel dominio del Software-as-a-Service: l’azienda compra la soluzione sotto forma di servizio, svincolandosi da tutti gli oneri realizzativi. Tale scenario è chiaramente poco attinente al discorso che si sta facendo.

I diversi scenari sono rappresentati dal seguente DevOps Outsourcing quadrant, in relazione all’outsourcing di “Dev” e “Ops”.

DevOps Outsourcing quadrant

Nel prosieguo faremo riferimento al contesto specifico di OutOps.

Be C.A.L.M.S and Stay Agile

Prima di parlare delle possibili strategie di adozione di DevOps in realtà ousourced-orinted, è bene fare alcuni richiami a quelli che sono gli elementi fondanti di questo approccio.

DevOps si basa su cinque pillar (pilastri) fondamentali: Comunicazione, Integrazione, Collaborazione, Automazione e Misurazione, ognuno dei quali deve essere presente all’interno della propria azione di delivery per poter operare in chiave di Continuous Improvement.

DevOps Pillar

Si tratta di un ecosistema complessivo che può assumere diverse sfaccettature e va opportunamente bilanciato al fine di ottimizzare l’intero flusso di delivery in funzione degli obietti di business, in chiara logica Lean.

Proprio per attuare questo bilanciamento, all’interno del proprio DevOps journey, è possibile sfruttare il meta-framework operativo C.A.L.M.S., creato da Damon Edwards e Jez Humble, il cui nome è formato dalle diverse leve a disposizione per raggiungere tale obiettivo:

• Culture – gestire il cambiamento focalizzandosi sulla collaborazione e la comunicazione
  • Hearts & Minds, Embrace Change;
• Automation – rimuovere le azioni manuali lungo la catena del valore
  • Continuous Integration, Continuous Delivery/Deployment, Infrastructure-as-a-code;
• Lean – utilizzare i principi Lean per velocizzare, standardizzare e rendere efficienti le attività
  • Customer Value focus, Small batch size;
• Metrics – misurare qualsiasi cosa, utilizzando i risultati per rifinire costantemente le attività
  • Measure Everything, Show the improvement;
• Sharing, condividere le esperienze di successo e di fallimento per una crescita diffusa
  • Open Information Sharing, Collaboration. 

Il livello di ciascuno di questi 5 elementi vi permette di avere una istantanea dell’azione di Change Management in chiave DevOps, evidenziando punti di forza e debolezza e portando ad individuare opportune strategie di miglioramento.

Nel contesto specifico di OutOps è chiaro che alcune leve sono più aggredibili di altre, in particolare: Automation, Lean e Metrics. Questo non vuol dire che le altre siano assenti, ma che assumono delle forme meno libere, e più vincolate da aspetti relazionali spesso regolamentati da specifici contratti o accordi formali.

Questo primo post termina qui. Nel prossimo vedremo le strategie di OutOps e i relativi vantaggi operativi.

Stay tuned