<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1267344923293614&amp;ev=PageView&amp;noscript=1">
menu

AMM

AMM: Application Modernization & Migration per lo sviluppo applicativo

La Digital Transformation

AMM | La Digital Transformation

Cosa significa “trasformarsi”?

La Digital Transformation rappresenta un cambiamento strategico per le aziende. Permette alle compagnie di adattare i loro servizi in base al cambiamento nella pressione della concorrenza o alla nascita di nuove regolazioni, e rilasciare aggiornamenti non appena una nuova vulnerabilità viene scoperta. Allo stesso tempo, non esiste una definizione comune per la Digital Transformation che sia diversa dal “cambiare le cose come stanno”.

Il termine Digital Transformation viene talvolta utilizzato per indicare nuove architetture, come i microservizi, o nuovi processi, come il DevOps, o ancora nuove tecnologie, come i container e le API (interfaccia di programmazione di un'applicazione). Quando qualcosa significa tutto, alla fine non significa niente. La Digital Transformation non è un oggetto specifico che si può acquisire. È qualcosa che ciascuna organizzazione deve definire in maniera unica per sé stessa.

Una questione critica alla quale prestare attenzione lungo il percorso della Digital Transformation è che non si tratta soltanto di un cambiamento nelle tecnologie: la trasformazione si alterna tra cambiamenti nei processi, nelle persone e nelle infrastrutture, ma quelli più importanti sono i cambiamenti nella cultura aziendale.

Puoi creare l'architettura più bella che puoi, ma una volta che avrai cominciato a coinvolgere le persone e i processi dovrai creare anche il giusto ambiente culturale che supporti il rilascio continuo e la disciplina architettonica, perché i cambiamenti nei processi o nelle strutture non durano veramente per sempre. Le persone non seguono le regole. Cosa significa tutto questo? Che il retaggio delle strutture organizzative manderanno a monte la tua bellissima architettura ogni singola volta!

La chiave per guardare ai software o alle tecnologie come a importanti opportunità di cambiamento è comprendere che l'evoluzione è una funzione naturale del loro ambiente. Nel business, questa è la cultura.

Secondo la legge di Conway “la struttura di un'organizzazione è la copia esatta della struttura di comunicazione dell’azienda”.

A questa legge sono correlate due interpretazioni: cambiare l'architettura non servirà a niente, a meno che non cambi anche la struttura di comunicazione; e, cambiando questa, si avrà un miglioramento nei processi e nelle infrastrutture, a prescindere dalle infrastrutture utilizzate.

Segui la stella

Non esiste un singolo pattern architettonico o piattaforma tecnologica che funzionino in maniera impeccabile in ogni singolo ambiente. Le organizzazioni che hanno successo con la Digital Transformation sono quelle che hanno una chiara comprensione dei loro obiettivi e della loro cultura: ciò sarà differente da caso a caso.

Per esempio:

  • Walmart ha effettuato il deployment di un codice durante il Black Friday, con 200 milioni di persone online.
  • Amazon rilascia aggiornamenti di codice ogni secondo (50 milioni di aggiornamenti all'anno) su centinaia di applicazioni e su milioni di istanze cloud.
  • Etsy effettua 60 deployment al giorno con un'applicazione monolitica.
  • Netflix effettua deployment centinaia di volte al giorno grazie a una complessa architettura distribuita, con un singolo cambiamento di codice che passa dal check-in alla produzione in soli 16 minuti.

Ciascuna di queste aziende lavora con tecnologie, basi di codici, architetture e team strutturati in maniere molto differenti.

Il punto focale della questione non è che tali aziende si sono focalizzate su l'uno o l'altro pattern, o sull'una o l'altra tecnologia e tutto ha funzionato a dovere. Sono tutte partite dalla valutazione dei loro team, del debito tecnico corrente e delle loro strategie di business, e hanno poi fatto proseguire le loro aziende nella direzione voluta, in maniera volontaria e coerente. E così hanno ottenuto i risultati che volevano.

La metodologia DevOps

AMM | I primi passi grazie al DevOps

I primi passi grazie al DevOps

Le applicazioni, così come le strategie di business, sono un riflesso dei team e della comunicazione usata per crearle. La metodologia DevOps coinvolge più stakeholder nello discussione sullo sviluppo e consente uno sguardo più ampio su come gli operations si occupano della manutenzione del software e delle infrastrutture (e su come i clienti e i partner stanno effettivamente usando le applicazioni). L’approccio DevOps crea un circuito di feedback più rigoroso tra i vari team coinvolti e richiede canali aperti di comunicazione. La comunicazione aperta costituisce le fondamenta per ogni successivo stadio evolutivo.

La metodologia agile è stato un approccio al design di software che ha cercato di unire tutte le parti coinvolte, come i garanti della qualità, il product management, gli sviluppatori e persino gli addetti alla documentazione, in un gruppo coeso. L’idea era quella di chiarire gli obiettivi attraverso brevi iterazioni focalizzate su task specifici, espressi come obiettivi per ciascun utente (o storie). Tale processo abbandonava del tutto il tradizionale metodo “a cascata” impiegato nello sviluppo dei software, come una sorta di caserma di vigili del fuoco dove un team passava compiti ad un altro team.

La metodologia DevOps rappresenta un cambiamento culturale mirato ad abbattere il muro che divide gli sviluppatori, i sistemisti e i vari stakeholder. La separazione che esiste tra questi gruppi è reale, ma del tutto artificiale. Un team può includere più persone che condividono una funzione lavorativa: il DevOps cerca di ridefinire la costituzione del team includendo chiunque sia coinvolto nel ciclo di vita di un’applicazione, e possa quindi aprire le vie di comunicazione tra i gruppi.

Il cambiamento culturale va oltre il DevOps o la metodologia agile o altri metodi. È un impegno nell'includere tutti quanti in un solo grande team. Se cambierai i tuoi pattern di comunicazione, cambierai anche i tuoi risultati. Se, invece, stai avendo difficoltà nella creazione di una cultura DevOps, fai passare ai tuoi sviluppatori un po' di tempo assieme ai sistemisti.

Vedere il modo in cui gli altri team funzionano, direttamente sul posto, può essere una spinta potente per incoraggiare i team a cambiare i loro processi o aprirsi alla comunicazione.

I vantaggi del DevOps

Il report di Puppet sullo “State of DevOps” mostra quanto efficace possa essere il cambiamento nella struttura e nella comunicazione dei team. La ricerca ha rivelato che i team che si sono affidati al DevOps hanno ottenuto:

  • tempi di risposta 2,555 volte più veloci;
  • numero di deployments 200 volte più grande;
  • tempi di ripristino da errori 24 volte più veloci;
  • tasso di fallimento nel cambiamento 3 volte più basso;
  • 22% in meno di tempo speso sulla rilavorazione.

La velocità è uno dei vantaggi più importanti del metodo DevOps, attenzione però: Gartner ha scoperto che “il 90% delle organizzazioni che si approcciano alla metodologia DevOps senza prima aver rivisto le loro fondamenta culturali falliranno inevitabilmente”, quindi sii pronto al cambiamento!

Container e Self-service Infrastructure

AMM | Introdurre piattaforme tecnologiche moderne

Introduci piattaforme tecnologiche moderne

Questa fase rappresenta un cambiamento basato sulla tecnologia, introducendo efficienze che sono tipicamente associate con le moderne piattaforme tecnologiche.

I container e i cataloghi self-service permettono a sviluppatori e sistemisti di accelerare i lavori in maniera consistente; in alcune organizzazioni, il tempo di risposta per le nuove istanze passa da alcuni giorni a pochi minuti.

Un’immagine container è un pacchetto eseguibile stand-alone di dimensioni leggere di un software, che include tutto ciò che serve per eseguirlo: codice, runtime, strumenti di sistema, librerie di sistema, impostazioni.

I software nei container sono disponibili per app sia su Linux che su Windows e sono sempre eseguibili, indipendentemente dall'ambiente: i container isolano il software dall'ambiente circostante, es. di sviluppo o di staging, e aiutano a ridurre i conflitti tra i team che eseguono software differenti sulla stessa infrastruttura.

Aumenta la produttività

Un primo passo verso la Digital Transformation prevede l'adozione della cultura DevOps, con team dinamici di dimensioni ridotte e una comunicazione efficace. Il passo successivo mette al centro la tecnologia, serve cioè fare riferimento a un’infrastruttura adeguata che supporti cicli di sviluppo rapidi. Infrastrutture elastiche e self-service ti permetteranno di richiedere e ricevere istanze in base a caratteristiche specifiche, quasi in tempo reale.

Se l’avanzamento tecnologico avviene durante questa fase della trasformazione, la produttività aumenterà in maniera tangibile: un cliente Red Hat ha introdotto un catalogo self-service, in modo da permettere agli sviluppatori di richiedere con rapidità sistemi virtuali, riuscendo così a ridurre il tempo di risposta da 5 giorni a circa 15 minuti e ad automatizzare l'intero processo. Un tale cambiamento permette di liberare risorse lato sistemisti e migliora la produttività (e l’umore) degli sviluppatori.

Business Process Automation e Orchestration

AMM | Automazione e orchestrazione dello sviluppo

Automazione e orchestrazione dello sviluppo

L’automazione dello sviluppo è un cambiamento che si articola in due parti. Da un punto di vista tecnologico, esistono motori di deployment avanzati come Red Hat Ansible o Puppet, ma richiede anche un cambio di processi.

Molte organizzazioni hanno dei processi rigorosi riguardo alla gestione del cambiamento e del rischio: senza adattare tali processi in metodologie più agili, non sarà possibile trarre vantaggio dalle nuove tecnologie.

Sia l’automazione che l’orchestrazione si fanno carico della gestione di operazioni quotidiane e banali, permettendo così ai team IT di focalizzarsi su attività strategiche che generano valore.

Ad ogni modo, quando parliamo di automazione, ci riferiamo a un singolo task o funzione che vengono portati a termine senza l’intervento di un essere umano, mentre per orchestrazione si intende l’organizzazione di tali task automatizzati in un flusso di lavoro consolidato. Per dirla con parole semplici: l’automazione riguarda i task individuali, mentre l’orchestrazione riguarda i processi.

Uno dei principali benefici dell’approccio DevOps è l’abilità di ridurre il tempo di immissione sul mercato di un’applicazione attraverso l’unione dei team di sviluppo e operations, creando processi standardizzato che riducono il tempo impiegato per iniziare a utilizzare un’applicazione.

Questi processi standardizzati vengono sviluppati attraverso l’orchestrazione di diversi task automatizzati, per creare dei flussi di lavori ripetibili e riutilizzabili.

In una cultura DevOps efficace, l’automazione e l’orchestrazione lavorano a stretto contatto per semplificare il deployment di applicazioni. In altre parole, l’orchestrazione mira a ottimizzare e standardizzare i processi, mentre l’automazione è lo strumento effettivamente impiegato per raggiungere tale obiettivo.

Cosa e come automatizzare e orchestrare

A questo punto, forse ti starai chiedendo perché non hai ancora automatizzato o orchestrato tutti i tuoi bisogni informatici. Alcune persone affermano che sarà proprio questo il prossimo passo della metodologia DevOps: tutti gli sviluppatori saranno liberati dai task per progredire nell'innovazione. Di seguito, ecco alcuni consigli per la scelta di cosa e come automatizzare e orchestrare:

  • prendi in considerazione le necessità del tuo business, non soltanto cosa è meglio per il tuo team IT;
  • automatizza quei compiti che possono essere eseguiti più velocemente e accuratamente dalle applicazioni o dalle macchine, rispetto ad un essere umano, anche nel caso l’automazione sia qualcosa di semplice come inserire una riga di codice. In questo modo potrai evitare gli errori umani;
  • orchestra i flussi di lavoro più adatti in modo da permettere ai team di occuparsi di progetti più importanti che invece non sono semplici da orchestrare, come le produzioni creative e innovative, o l’avvio di nuovi progetti;
  • scegli progetti che creano un valore di business significativo e misurabile. Se stai utilizzando l’orchestrazione soltanto per velocizzare il processo di completamento dei task, non riceverai il vero valore di business che l’orchestrazione può fornirti.
  • Con l’automazione e l’orchestrazione che continuano a migliorare lo svolgimento dei task e l’automatizzazione dei processi, sia nell’IT che in altri ambiti, sempre più team potranno lavorare con l’obiettivo di creare il prodotto ideale, che incorpori un numero sempre maggiore, se non tutti, dei requisiti richiesti.

CI/CD: Continuous Integration e Continuous Delivery

AMM | CI/CD: Continuous Integration e Continuous Delivery pipeline

CI/CD pipeline

L’integrazione e la distribuzione continua (CI/CD) sono il simbolo di una cultura, di un set di principi operativi e di una serie di pratiche che permettono ai team di sviluppo delle applicazioni di realizzare cambiamenti di codice più frequenti e affidabili. L’implementazione è conosciuta anche come la pipeline CI/CD, ed è una delle migliori pratiche che i team DevOps possano implementare.

L’idea di una pipeline è che esistono sia processi che tecnologie che riducono il rischio di un codice di bassa qualità o malfunzionante, dalla creazione fino al deployment. Tale livello mostra la maturità di tutti gli altri step, ossia il DevOps e la comunicazione aperta tra i team, i processi messi in atti sulla base dei test e dello sviluppo, e i test e il deployment automatizzati. Quando ciascuna di queste fasi sono ben solide, allora sarà possibile velocizzare l’inserimento di codice: ecco cos’è una pipeline.

Molti team che implementano le pipeline CI/CD su ambienti cloud utilizzano anche container come Docker e Kubernetes. I container permettono di impacchettare e inviare le applicazioni in un modo standardizzato e portabile. I container possono essere utilizzati anche per aumentare o ridurre gli ambienti con carichi di lavoro variabili. CI/CD è inoltre una best practice nel DevOps perché fa fronte ai disallineamenti tra gli sviluppatori che vogliono effettuare modifiche con frequenza, e operations che vogliono applicazioni stabili. Una volta messa in atto l’automazione, gli sviluppatori potranno effettivamente attuare modifiche in maniera più veloce. I team operations vedranno una maggiore stabilità perché gli ambienti avranno configurazioni standardizzate, con testing continui durante il processo di consegna, variabili ambientali che sono separate dall'applicazione, e procedure retroattive automatizzate.

CI/CD è uno dei casi d’uso più noti per OpenShift Container Platform. OpenShift fornisce un container Jenkins certificato per la costruzioni di pipeline di Continuous Delivery, e scala l’esecuzione delle pipeline sulla base di disposizioni on-demand di macchine slave di Jenkins in container. Questo permette a Jenkins di svolgere più lavori in parallelo e di diminuire il tempo di attesa per eseguire le versioni in progetti di ampio respiro. OpenShift fornisce una soluzione end-to-end per la costruzione di pipeline di rilascio complete e permette l’automazione necessaria richiesta per la gestione del codice e i cambi di configurazione immediati attraverso la CI/CD pipeline.

Continuos Integration

La Continuous Integration è una filosofia di coding e un set di pratiche che guida i team di sviluppatori a implementare piccoli cambiamenti e controllare il codice delle repository delle versioni di controllo frequentemente.

Dato che la maggior parte delle applicazioni moderni richiedono lo sviluppo di codice per piattaforme e strumenti differenti, il team ha bisogno di un meccanismo per integrare e convalidare i suoi cambiamenti.

Quando si mette in pratica l’integrazione continua, gli sviluppatori inseriscono molto spesso il codice in repository delle versioni di controllo, e la maggior parte dei team non si preoccupa di immettere il codice almeno una volta al giorno. La ragione alla base di ciò è che è più facile individuare i difetti e le problematiche nella qualità del software su piccoli differenziali di codice, rispetto a quantità più grandi che si sono sviluppate nel corso del tempo. Inoltre, quando gli sviluppatori lavorano su cicli di commit più brevi, è meno probabile che più sviluppatori modifichino lo stesso codice e che richiedano quindi una fusione durante il commit.

L’obiettivo tecnico della Continuous Integration è quello di stabilire una modalità consistente e automatizzata per lo sviluppo, l’impacchettamento e il testing delle applicazioni. La consistenza nel processo di integrazione permette ai team di effettuare il commit del cambiamento di codice con maggiore frequenza, che conduce a una migliore collaborazione e una migliore qualità del software.

Continuous Delivery

La Delivery inizia laddove la Continuous Integration finisce. Essa infatti automatizza il rilascio delle applicazioni agli ambienti di infrastrutture selezionati. La Continuous Delivery è l’automazione che spinge le applicazioni verso gli ambienti di rilascio. La maggior parte dei team di sviluppo possiedono solitamente uno o più ambienti di rilascio e di testing, dove i cambiamenti per l’applicazione vengono testati e revisionati. L’automazione della Continuous Delivery effettua ogni chiamata di servizio necessaria ai servizi web, ai database e ad altri servizi che potrebbe aver bisogno di essere riavviati, o di seguire altre procedure nel momento in cui un’applicazione viene rilasciata.

Con Continuous Integration e Continuous Delivery gli sviluppatori e i leader aziendali hanno la soddisfazione di poter vedere i nuovi prodotti andare sul mercato più velocemente. Gli operations possono rilasciare riparazioni e persino occuparsi di vulnerabilità ed esposizioni al rischio critiche (CVE) in un tempo assai ridotti, dando vita a un sistema più sicuro e performante.

Advanced Deployment

AMM | Diversi percorsi di Advanced Deployment

Diversi percorsi di Advanced Deployment

Una volta che i processi e l’infrastruttura sono stati sistemati per rilasci rapidi, sarà allora possibile cominciare a usare il tuoi sistemi di rilascio in modo da evitare ogni rischio derivante da aggiornati, valutarne l’efficacia o la funzionalità e fornire le basi per testing in situazioni reali per nuove idee.

Questo può includere l’avere ambienti e bilanciamenti del carico separati tra di loro durante il rilascio (blue-green deployment), utilizzare due ambienti diversi per testare l’interazione dell’utente (A/B testing), o distribuire aggiornamenti a piccole percentuali di utenti e aumentare quel numero in maniera sicura (canary deployment).

Le tecniche di rilascio avanzato apportano struttura e chiarezza all'innovazione. Le metodologie mature di rilascio creano un ambiente che permette sperimentazioni, feedback e analisi vere e proprie. Migliori sperimentazioni conducono a una migliore innovazione. Questi di seguito sono pattern di rilascio comuni: potrebbero essere tutti adatti, a seconda della natura della tua applicazione e del tuo ambiente utente.

Blue-green Deployment

Un ambiente blue-green è un modo per mitigare il rischio nel rilascio di modifiche. Un nuovo sviluppo viene fatto passare attraverso tutti gli ambiente nella CI/CD pipeline. Per la produzione ci sono due ambienti identici (blu e verdi), ma soltanto uno è attivo. La modifica viene distribuita in produzione sull'ambiente inattivo; una volta che l’ambiente è stato verificato, il router viene scambiato e il traffico spostato sull'ambiente aggiornato.

Canary Release

Un rilascio “canarino” (canary release) è simile a un blue-green deployment, tranne che per il rilascio iniziale che viene indirizzato a un subset di utenti all'interno dell’ambiente (come il famoso canarino nelle miniere di carbone). Dopo aver raccolto il feedback degli utenti, tale subset può essere incrementato gradualmente fino a quando tutti gli utenti non avranno effettuato il passaggio. Questo processo può costituire parte di una tecnica di testing per valutare diverse funzionalità o design per applicazioni con piccoli gruppi, all'interno di un ambiente di produzione attivo e con pattern di traffico e utilizzo reali.

A/B testing

L’A/B testing presenta agli utenti due design diversi e successivamente valuta quale dei due ha ottenuto risultati migliori, in base alle metriche desiderate. Può trattarsi di un processo esplicito, come chiedere agli utenti di valutare la loro esperienza o fornire feedback, ma può trattarsi anche di qualcosa di più discreto. Per esempio, combinando l’A/B testing con deployment del tipo canary si possono comparare due potenziali design o persino delle funzionalità nascoste, e successivamente valutare il modo in cui gli utenti interagiscono con i diversi design, con l'ambiente corrente come base di riferimento. Dopo aver verificato quale dei due design avrà avuto più successo, allora si potrà rilasciare a un set più ampio dell'ambiente, come avviene nel caso della canary release.

Se tale processo viene messo in atto in maniera efficace, si potrà trasformare un ambiente di produzione in un ambiente di sperimentazione, e si darà la possibilità ai team di essere più innovativi e realizzare design più pertinenti. Questo tipo di testing si basa più sui dati che sulla semplice intuizione.

Microservizi

AMM | Microservizi

Cosa sono i microservizi

Una delle definizioni più utilizzate al momento per descrivere un’architettura distribuita è “microservizi”. Esistono delle somiglianze con altri design modulari, come le architetture orientate ai servizi (SOA), ma i microservices nascono da una specie di abbinamento tra servizi e indipendenza dei servizi. Un microservizio è una piccola applicazione che svolge una singola funzione discreta. L'architettura globale dell'applicazione potrebbe aver bisogno di svolgere dozzine o centinaia di funzioni disparate, e ciascuna di queste funzioni viene definita e orchestrata in un microservizio.  Un'architettura a microservizi o qualunque architettura dei calcolatori distribuita è allo stesso tempo complessa è semplice. La manutenzione, l’aggiunta e il ritiro dei servizi individuali sono molto più facili da effettuare, anche se l'architettura è più complessa.

Facili da creare, integrare e mantenere

La definizione di un singolo servizio è solitamente molto chiara, con i servizi che possono essere aggiunti, aggiornati o rimossi dalla più ampia architettura con facilità. Questo comporta benefici sia per la scalabilità dinamica, sia per la tolleranza ai guasti: i servizi individuali possono essere scalati al bisogno senza alcuna necessità di infrastrutture pesanti, o possono effettuare il failover senza avere un impatto sugli altri servizi.

Quando viene fatto bene, un “design basato sui microservizi è la manifestazione definitiva di tutto ciò che hai imparato sul modo migliore di creare il design di un’applicazione” (Ben Cotton).

Questa elasticità all'interno dell'architettura è il motivo per cui microservizi vengono solitamente associati a compagnie estremamente dirompenti e innovative, come Netflix e Google.

I vantaggi dei microservizi

La fluidità di un’architettura a microservizi comporta una stretta associazione con tecnologie dinamiche come i container e gli ambienti cloud, che permettono alle istanze individuali di essere messe in rotazione e distrutte con agilità, anche in maniera programmatica.

L’immediatezza del calcolo distribuito offre benefici diretti sia per le aziende che per i team, che possono osservare l’impatto del loro lavoro grazie a:

  • Tolleranza al guasto migliorata e minimizzazione delle interruzioni di servizi.
  • Protocolli semplici come JSON/REST e HTTP/OAuth per una più facile integrazione.
  • Servizi poliglotti per flessibilità di sviluppo
  • Time-to-market più veloce per applicazioni e funzionalità.

Recupero dati e condivisione tra servizi semplificati, senza dover ricorrere a message bus pesanti o conversioni.

Come insegnare a un elefante a danzare

darwinismo digitale

Insomma, che c'entrano tutti questi elefanti?

L’elefante rappresenta il punto in cui (forse) si trova la tua organizzazione oggi. Ci sono fasi di cambiamento tra gli ambienti tradizionali e quelli moderni che vengono alimentate dai microservizi e dall'approccio DevOps. Alcune organizzazioni possono permettersi il lusso di partire da zero, ma per la stragrande maggioranza delle aziende la sfida è insegnare al loro goffo elefante a volteggiare come un’agile ballerina.

Qualunque sia il punto in cui la tua impresa si trova in questo momento, può muoverla nel punto in cui dovrebbe essere (con il debito tecnico, i difetti nel design e tutto il resto), con intenzione e una strategia ben definita: ciò significa che devi avere capito in maniera chiara cosa stai cercando di raggiungere e quanto quella cosa è lontana dal punto in cui ti trovi oggi.

Ed è proprio questo il modo per insegnare ad un elefante a danzare!

Un processo snello e continuo

Esiste una tendenza a considerare il reparto IT o le iniziative di Digital Transformation come processi binari: o fai una cosa, o ne fai un’altra, diversa. Questa mentalità non funziona per diversi motivi. Innanzitutto, a volte puoi scegliere di fare più di una cosa, o scegliere una soluzione ibrida. In secondo luogo, perché spesso non si tratta soltanto di cambiare un solo fattore, perché diversi tipi di cambiamento potrebbero richiedere diversi cambiamenti fondamentali, o potrebbe dipendere da cambiamenti culturali o nei processi.

Un approccio più costruttivo può essere quello di guardare alla Digital Transformation come ad un continuum, con fasi diverse lungo il percorso che permettono l’accesso al passo successivo dell’evoluzione.

L’elefante può essere addestrato in una creature agile e trasformativa, a condizione che ci sia una chiara visione su quale dovrebbe essere lo stato finale. È questa la Digital Transformation come processo evolutivo. Non esiste un risultato ideale, adatto a tutti: ciascun percorso evolutivo riflette gli obiettivi unici e la personalità dell’organizzazione stessa.

Per una trasformazione unica

Determina ogni singola fase dell’evoluzione digitale: DevOps, ambienti self-service o elastici, automazione e orchestrazione, CI/CD pipeline, Advanced Deployment e microservizi. Costruisci la tua strategia di trasformazione digitale intorno al livello di evoluzione che soddisfa al meglio le necessità del tuo business.

Focalizzati sulla costruzione della tua cultura e bilancia i cambiamenti nelle tecnologie con i cambiamenti nei processi corrispondenti, di modo che la tua tecnologia possa essere supportata appieno dai tuoi team. Man mano che il tuo processo arriva a maturazione, comincia a valutare la tua applicazione e la tua architettura. In base alle necessità, isola o sviluppa servizi indipendenti e crea un’architettura agile che possa essere adattata durante l’emergere o il cambiamento di nuove priorità di business. Infine, promuovi la capacità di innovazione. Questo significa tollerare un certo livello di rischio o possibile fallimento (nei limiti dei tuoi obiettivi di business e dei bisogni dei tuoi clienti). Mettere da parte risorse di tempo, denaro e infrastrutture richiederà molta disciplina.

La sperimentazione è alla base dell’innovazione, e moltiplica le possibilità di avere successo nella Digital Transformation; grazie ad essa, ritroverai un po’ di quell'emozione che ha attirato così tanti sviluppatori e sistemisti nel settore delle tecnologie: la capacità di creare e osservare la creazione con i propri occhi.