Il viaggio verso il cloud

Qualsiasi processo di trasformazione cloud che includa la migrazione delle applicazioni sarà complesso. Eppure, nonostante questa complessità, ci sono alcune destinazioni chiaramente definite nel viaggio verso il cloud. Una di queste destinazioni implica fino a che punto dobbiamo essere "pronti per il cloud" per realizzare l'applicazione di destinazione. Fino a che punto vuoi/hai bisogno che l'applicazione sia pronta per il cloud per passare al cloud nell'intervallo di tempo desiderato? In questo documento verranno delineate alcune di queste destinazioni ed evidenziate le best practice e le lezioni apprese in base al nostro viaggio. La chiave del successo è definire in modo chiaro gli obiettivi di migrazione in anticipo per poter prendere decisioni mirate su come raggiungerli. Ti troverai di fronte a molti potenziali percorsi. Nel corso della migrazione, sviluppatori, team di consegna e dirigenti dovranno valutare e compiere molte scelte su come procedere.

Ti consigliamo di concentrarti sui seguenti driver tecnici e aziendali per inquadrare le decisioni da prendere e raggiungere i tuoi obiettivi di business.

Scalabilità

I servizi cloud forniscono potenza di elaborazione su larga scala, ben oltre ciò che è possibile per l'infrastruttura gestita, supportando la crescita della tua attività per soddisfare le opportunità di mercato. L'infrastruttura come servizio (IaaS) e la piattaforma come servizio (PaaS) basate su cloud consentono agli ISV di concentrarsi sulla creazione di architetture scalabili utilizzando componenti moderni. Un ulteriore benefit della migrazione è che, liberando i team di sviluppo interni dalla gestione e dalla scalabilità delle operazioni IT, l'attenzione può essere rivolta alla messa a punto e all'ottimizzazione delle prestazioni.

Modernizzazione

La modernizzazione di set di strumenti, servizi e architetture facilita l'integrazione tra i componenti, aiutando le applicazioni a realizzare tutto il valore degli strumenti e delle tecnologie disponibili nel cloud. Tali strumenti spaziano dagli upgrade dell'infrastruttura alle pipeline di distribuzione automatizzate fino ai modelli di machine learning integrati che migliorano le prestazioni delle applicazioni. La modernizzazione è molto importante laddove i mercati vivono un cambiamento rapido e coerente, poiché le applicazioni devono essere dinamiche per stare al passo. In alcuni casi, i servizi possono essere completamente riscritti e rinominati, sfruttando lo stack tecnologico più recente per offrire costi inferiori oppure opzioni di servizio più snelle. Tali cambiamenti possono aggiornare i prodotti obsoleti e sconvolgere i mercati consolidati in cui le offerte con licenza sono la norma. In altri casi, i prodotti possono essere revisionati con nuovi approcci, migliorando il servizio e preservando al tempo stesso la visibilità del brand e la fidelizzazione del cliente. Ciò non richiede necessariamente una modifica completa della suite di prodotti.

Il passaggio al cloud diventa un fattore scatenante per una spinta alla modernizzazione di più ampio respiro. Poiché il cloud fornisce a te e ai tuoi team l'accesso a servizi, tecnologie e competenze che non erano precedentemente disponibili nella tua organizzazione, diventa possibile raggiungere nuovi obiettivi e offrire nuove capacità. I tuoi team possono rinnovare lo stack tecnologico per concentrarsi su nuove funzioni del prodotto generalmente applicabili piuttosto che su codice personalizzato collegato a distribuzioni con clienti specifici. Con il provisioning dei servizi, gli aggiornamenti dei prodotti e il supporto clienti a ritmi più veloci rispetto al passato, le risorse possono orientarsi di nuovo allo sviluppo di nuove funzioni. In questo modo, la migrazione al cloud pone le basi per un'ampia ondata di attività di modernizzazione, trasformando tutti gli aspetti: dall'esecuzione degli upgrade dei prodotti alla qualità dell'assistenza clienti.

---

"La migrazione a Gen2 Cloud ha consentito a Oracle di distribuire con successo i nostri servizi tramite un solido modello DevSecOps e ci ha permesso di supportare le trasformazioni aziendali dei nostri clienti. Ora rilasciamo software ogni giorno e abbiamo ridotto i tempi di provisioning di oltre il 98%." - Karthic Murali, Senior Principal Product Strategy Manager, Oracle Global Business Units

---

Standardizzazione

La standardizzazione tra IaaS e PaaS consente di ridurre le spese generali e rendere i team più flessibili e sostituibili. Man mano che le organizzazioni crescono, i team adotteranno strumenti con vari livelli di maturità. Il consolidamento di questi set di strumenti all'interno del servizio cloud consente di estrapolare gran parte della complessità associata a questo livello di gestione IT. Consente lo sviluppo e l'uso di procedure operative standard per i task che possono essere mappati in tutto il portfolio. La standardizzazione rende più semplici e prevedibili anche le attività di routine, riducendo la domanda di manodopera per i task di base. Le risorse precedentemente impegnate nella navigazione di processi vari e possibilmente incompatibili tra le applicazioni sono ora libere di concentrarsi su problemi più importanti, incluso lo sviluppo di prodotti e servizi di nuova generazione per i clienti.

In particolare, la standardizzazione semplifica l'applicazione di policy e procedure globali in materia di sicurezza, rischio, conformità e altre attività operative che i team possono facilmente applicare a prodotti esistenti e nuovi. Di fatto, molte delle capacità intrinseche della piattaforma IaaS, come le certificazioni di conformità accreditate, possono essere ereditate dall'applicazione.

Ottimizzazione dei ricavi

L'ottimizzazione dei ricavi può essere ottenuta principalmente in due modi. Il primo e più ovvio è la riduzione dei costi. L'eliminazione dei data center mediante l'uso di soluzioni IaaS non solo sposta il modello finanziario da spese in conto capitale (CapEx) a spese operative (OpEx), ma in genere si traduce anche in significativi risparmi sul TCO. Un aspetto che potrebbe risultare non proprio ovvio è costituito dai risparmi sui costi ottenuti razionalizzando lo stack tecnologico utilizzato in un portfolio di applicazioni che sono state migrate al cloud. I set di strumenti comuni creano conoscenza istituzionale ed eliminano le spese associate alla formazione ad hoc per strumenti non standardizzati. In questo modo, i set di strumenti comuni che considerano l'infrastruttura come codice forniscono un'automazione che sostanzialmente consente di risparmiare tempo e costi di manodopera. Infine, i team specializzati in aree fondamentali applicabili all'intero portfolio, come la sicurezza, eliminano la necessità di creare esperti all'interno di ogni singolo team di prodotto.

In secondo luogo, il passaggio al cloud può in definitiva ottimizzare i ricavi aiutandoti a raggiungere il mercato più rapidamente, in quanto i tempi di sviluppo del prodotto vengono generalmente ridotti se un'applicazione è pronta per il cloud o cloud nativa. Raggiungere il mercato più rapidamente significa ottenere ricavi in tempi più rapidi. Se un'applicazione è pronta per il cloud, può essere distribuita ovunque nel mondo in pochi minuti.

Se abbinati, i principi discussi finora dovrebbero tradursi in architetture di prodotti e servizi standardizzati, nonché in una migliore velocità e qualità di distribuzione. Ridimensionare i risultati della progettazione per modelli ripetuti contribuisce all'ottimizzazione dei ricavi, a un time-to-value più rapido e alla conseguente capacità di orientare nuovamente le risorse al miglioramento della qualità e dell'integrità del servizio per i clienti.

---

WorkForce Software migra la propria soluzione di gestione della forza lavoro sull'infrastruttura Oracle Cloud e realizza un aumento delle prestazioni del 30%.

"Abbiamo ottenuto prestazioni finanziarie che ci hanno permesso subito di risparmiare dal 30 al 35% di spese in conto capitale (CapEx) e, grazie alle ottime prestazioni di OCI, il ROI offerto con la nostra suite continua a migliorare sempre di più." - Mike Morini, Chief Executive Officer di WorkForce Software

Ulteriori informazioni

---

Percorsi verso il valore nel cloud

Il cloud computing può includere una serie di risorse IaaS e PaaS, nonché molteplici modelli di distribuzione del software, che includono l'accesso a istanze Bare Metal, ambienti containerizzati integrati e stack di servizi completamente funzionali. Al livello più elementare, il cloud computing si riferisce alla sostituzione dei componenti dell'infrastruttura fisica con risorse IaaS di base.

La maggior parte delle applicazioni aziendali non è stata originariamente creata per il cloud. Per molte applicazioni, la conversione o la conformità ai modelli cloud richiede tempo e risulta difficile. La conversione della piattaforma può essere costosa sia dal punto di vista del tempo che della manodopera, pertanto non sorprende che a volte possa essere più semplice progettare da zero i componenti principali cloud nativi. Se si tiene presente questo fattore, quando le aziende prendono in considerazione una migrazione al cloud in genere si trovano in uno dei seguenti tre scenari principali.

• Abbandono dei data center precedenti: la gestione di un data center è costosa. Edifici, persone, alimentazione, raffreddamento, manutenzione e upgrade sono solo alcune delle responsabilità quotidiane. Molte aziende stanno lavorando attivamente per ridurre o eliminare la propria dipendenza dai data center, valutando i portfolio di applicazioni affinché i candidati possano trasferirsi fuori sede. La priorità è spostare le applicazioni al di fuori di un hosting gestito collocato in un'unica posizione o dai data center on-premise nel tentativo di ridurre o eliminare le spese in conto capitale. Spesso viene utilizzata una strategia lift-and-shift in base alla quale si lascia invariata l'applicazione e se ne esegue la migrazione su un server Bare Metal o in una virtual machine nel cloud.
• Evoluzione dello stack tecnologico: in questo caso, le aziende iniziano ad apportare modifiche incrementali alle applicazioni che, nel corso del tempo, richiederanno ulteriori investimenti, ma si prevede anche che apporteranno maggior valore. Un esempio potrebbe essere la sostituzione delle versioni on-premise di Oracle Database con Oracle Autonomous Database basato su cloud senza apportare modifiche importanti all'applicazione stessa. Questa strategia viene a volte denominata move-and-improve.
• Migrazione dell'intero stack al cloud nativo: i benefit della riprogettazione totale di un'applicazione per fare in modo che sia pronta per il cloud potrebbero superare i costi derivanti dal mantenere intatta un'applicazione meno matura durante l'implementazione di uno degli scenari sopra menzionati. Le applicazioni cloud native hanno una natura altamente distribuita e spesso sono costruite utilizzando principi a 12 fattori. Di conseguenza, sono progettate per essere indipendenti dall'architettura sottostante, il che significa che le applicazioni continuano a funzionare anche quando l'infrastruttura sottostante si danneggia. In breve, vale la pena valutare se questo percorso ha senso per l'applicazione di destinazione, poiché il passaggio al cloud sarà sicuramente più semplice rispetto allo spostamento di un'applicazione strettamente collegata alla propria infrastruttura sottostante.

Per scoprire in che modo Oracle definisce il cloud nativo, le origini delle applicazioni cloud native e le best practice da seguire durante la relativa creazione, leggi questo e-book.

---

Un altro modo per immaginare questi scenari consiste nell'esaminare lo spettro di azioni che potresti intraprendere per eseguire la migrazione di un'applicazione aziendale a un'architettura cloud nativa mentre la trasferisci nell'infrastruttura Oracle Cloud. Vedi la figura 1 sottostante.

Figura 1: Livelli di cambiamento e investimento della migrazione al cloud

Il lato sinistro della Figura 1 rappresenta la quantità minima di cambiamento, il time to value più breve e l'investimento iniziale più basso. I livelli di cambiamento, investimento e tempo generalmente aumentano man mano che ci si sposta verso destra, ma anche il valore ottenuto è maggiore. Questo modello ti aiuta a definire un modo per prevedere quali tipi di investimenti considerare durante la fase di migrazione. Tieni presente che gli scenari non sono necessariamente distinti e sono leggermente sovrapposti, poiché le applicazioni sono costruite in tantissimi modi diversi.

Gli scenari sopra descritti diventano punti di riferimento chiave per valutare i livelli di maturità esistenti e gli obiettivi di transizione al cloud. Il divario tra lo stato attuale e lo stato di destinazione fornisce una stima approssimativa della portata delle modifiche tecniche e di processo necessarie per la transizione al cloud. A livello ideale, la transizione al cloud dovrebbe comportare la transizione di tutte le applicazioni ai modelli di distribuzione cloud nativi. Tuttavia, dati i vincoli di tempo e risorse, poche organizzazioni sono in grado di trasferire l'intero portfolio a un modello cloud nativo in un unico processo. Persino le semplici attività di trasformazione della piattaforma esistente possono richiedere molte risorse e investimenti significativi, anche solo per replicare le capacità precedenti.

La transizione al cloud consiste quindi nell'identificare i compromessi tra il livello di maturità cloud ottimale (livello in cui si trovano le applicazioni nel continuum sopra mostrato da "ospitata nel cloud" a "cloud nativa") e l'investimento tecnico necessario per riprogettare il prodotto e i processi aziendali associati. In questa fase, il passo fondamentale chiave consiste nell'identificare i livelli di maturità attuali e di destinazione di ciascuna applicazione con una stima approssimativa degli investimenti di sviluppo necessari per colmare il divario.

Per le applicazioni il cui livello di maturità cambia durante la migrazione, è necessario modificare anche i modelli operativi e le aspettative. La modifica dei livelli di maturità influisce sui team, sui processi e sulle policy che supportano il servizio.

 

Valutazione della disponibilità tecnica per il cloud

Una comprensione tecnica dell'applicazione di destinazione o dell'intero portfolio di applicazioni per le aziende che offrono più applicazioni basate su SaaS è fondamentale per comprendere i requisiti e le dipendenze per la migrazione. In questa fase, l'area chiave di interesse dovrebbe essere l'identificazione delle capacità richieste dall'applicazione e del modo in cui si relazionano con tali dipendenze. Questi fattori determineranno la tempistica relativa alle attività di migrazione e contribuiranno a identificare le aree chiave di interesse. La valutazione dovrebbe affrontare tre dimensioni critiche.

1. Requisiti dell'infrastruttura: l'uso del cloud isola il software dall'hardware o dagli ambienti operativi sottostanti. Le applicazioni a elevata maturità sono essenzialmente indipendenti dal proprio ambiente, in quanto si basano esclusivamente su una risorsa infrastrutturale generale, come una CPU o un cluster Kubernetes, facilmente scalabile nel cloud. Le applicazioni a bassa maturità dipendono da apparecchiature, componenti o ambienti specifici forniti, come l'infrastruttura gestita o altri sistemi dedicati. Le dipendenze reali dai componenti dell'infrastruttura e dalle configurazioni nel cloud dell'applicazione devono essere prima documentate ed eventualmente eliminate. Non è raro riscontrare personalizzazioni (realizzate da te o dai tuoi clienti) collegate/abbinate all'infrastruttura sottostante.
2. Componenti dei servizi: il cloud offre capacità di supporto come servizi standalone gestiti e forniti indipendentemente dall'applicazione. Le applicazioni ad elevata maturità sono progettate su componenti distinti con dipendenze minime nello stack, consentendo modifiche e upgrade mirati e massimizzando i tempi di attività. Le applicazioni a bassa maturità sono progettate con componenti di grandi dimensioni e strettamente collegati, che diventano altamente interdipendenti e devono essere gestiti come un'unica entità. Queste relazioni di servizi devono essere documentate per ogni applicazione.
3. Disponibilità operativa: l'uso del cloud determina un cambiamento in termini di architetture tecniche, processi di lavoro, competenze, strumenti disponibili e modelli operativi. Le applicazioni ad alta maturità funzionano già come applicazioni cloud e utilizzano processi, standard e set di strumenti che funzioneranno bene nel cloud. Le applicazioni a bassa maturità comportano servizi di supporto critici mancanti nel cloud, team di assistenza dotati di competenze inadatte al lavoro su cloud o processi che potrebbero subire interruzioni in seguito al passaggio al cloud.

Avviare una migrazione valutando la maturità di un'applicazione rispetto a questi fattori consente di pianificare in modo appropriato ed evitare sorprese a valle che creano ritardi, aumentano i costi e non consentono di raggiungere gli obiettivi. La complessità di una migrazione può essere difficilmente sottovalutata, in quanto gli attuali ambienti di produzione, suite di servizi di supporto e ambiente cloud di destinazione continueranno a evolversi durante l'intero processo. La scoperta di collegamenti tra servizi e applicazioni non solo supporta una pianificazione intelligente anticipata, ma consente a tale pianificazione di rispondere in modo flessibile ai cambiamenti che inevitabilmente si verificheranno durante la migrazione. Se documentata in modo efficace, questa valutazione dovrebbe tradursi in un chiaro elenco di cose da fare per il processo di migrazione. Ciò contribuirà a garantire che i programmi di migrazione previsti continuino ad allinearsi alle roadmap in continua evoluzione.

---

Zoom ridimensiona e attiva rapidamente milioni di riunioni simultanee sull'infrastruttura Oracle Cloud.

"Di recente abbiamo registrato la crescita più significativa che la nostra azienda abbia mai registrato e ciò ha richiesto un notevole aumento della nostra capacità di servizio. Abbiamo valutato quindi diverse piattaforme, ma l'infrastruttura Oracle Cloud è stata quella che ci ha permesso di aumentare rapidamente le prestazioni e soddisfare le esigenze dei nuovi utenti." - Eric S. Yuan, CEO di Zoom

Ulteriori informazioni

---

Obiettivi finanziari

Come capita per tutte le iniziative IT, la transizione al cloud richiede una serie di investimenti per ottenere il massimo valore, soprattutto se l'applicazione di destinazione è stata creata per un modello di hosting on-premise. Le applicazioni ritenute adatte al passaggio al cloud sostanzialmente con il tempo diventeranno cloud native o verranno dismesse. Tuttavia, l'obiettivo iniziale è in genere quello di portare un'applicazione a uno stato di rilascio su cloud.

Ciò che serve per portare un'applicazione dallo stato attuale allo stato di rilascio su cloud è il prodotto di una serie di decisioni e investimenti iniziali. Hai intenzione di spostare semplicemente l'applicazione su un server Bare Metal (nel qual caso la maggior parte dell'investimento è nell'infrastruttura cloud) o hai intenzione di rendere l'applicazione pronta per il cloud prima dello spostamento (nel qual caso saranno necessari alcuni investimenti per spostare parti dello stack dell'applicazione in un modello basato su cloud, ad esempio, spostando il database da on-premise a DBaaS o Oracle Autonomous Database)? Se hai creato personalizzazioni non modificabili per abilitare capacità specifiche del cliente, queste dovranno essere rifattorizzate per un modello in cui i componenti della piattaforma siano incapsulati e distribuiti tramite API come funzioni di prodotto. Le dipendenze hardware o di piattaforma dovranno essere rimosse per ridimensionare un'applicazione altamente distribuita nel cloud. Comprendere questi investimenti è un fattore critico per pianificare e raggiungere gli obiettivi finanziari associati al passaggio al cloud.

L'investimento iniziale prevede il tempo di sviluppo e la manodopera necessari per apportare al prodotto le modifiche richieste associate alla fase di migrazione al cloud appena illustrata. Tuttavia, è necessario contabilizzare anche le spese aggiuntive. La vasta gamma di spese che l'organizzazione potrebbe sostenere durante la transizione include:

• Investimenti per lo sviluppo: manodopera di sviluppo necessaria per riprogettare il prodotto o creare acceleratori per la migrazione, inclusa l'automazione per il supporto di attività come la migrazione del database e il provisioning delle applicazioni
• Esecuzione della migrazione: risorse di manodopera necessarie per il provisioning di nuovi asset, la migrazione di ambienti e dati esistenti e la disattivazione degli inventari precedenti
• Utilizzo dell'infrastruttura: canoni di sottoscrizione maturati attraverso il consolidamento delle soluzioni IaaS, che passeranno a uno stato stazionario, ma presenteranno nuovi aumenti durante il periodo della migrazione
• Infrastrutture bloccate: costi persistenti di ammortamento del data center e spese in conto capitale (CapEx) maturati durante l'attività di migrazione finché non possono essere eliminati o completamente ammortizzati
• Transizione della forza lavoro: spese associate alla formazione, istruzione o ristrutturazione dei team esistenti o all'acquisizione di nuove risorse dotate delle competenze necessarie per il cloud
• Transizione del cliente: costi associati a modifiche delle funzioni ambientali o dei termini del servizio che non possono essere supportati nel nuovo modello, inclusi nuovi sviluppi, incentivi, rinegoziazione di elementi contrattuali o abbandono del cliente

Ciascuno di questi costi è, in misura maggiore o minore, una componente necessaria del passaggio a una soluzione IaaS. Ogni fase avrà un impatto diverso sul tuo profilo di costo. Le spese di investimento per lo sviluppo e la realizzazione della migrazione, ad esempio, possono rientrare nella categoria delle spese una tantum, anche se le risorse associate a questo lavoro possono essere fisse. L'adozione di nuove infrastrutture comporterà un aumento netto delle spese per un determinato periodo di tempo fino all'eliminazione delle spese delle infrastrutture abbandonate. Alcune spese di transizione della forza lavoro e dei clienti, come la formazione o gli incentivi alla migrazione, rappresenteranno spese una tantum. Altre, come l'espansione della forza lavoro o le modifiche ai contratti dei clienti, potrebbero comportare nuove spese continuative.

Comprendere come si svolgeranno queste dinamiche nel tempo è essenziale per la tua organizzazione per preparare e definire le aspettative per la transizione al cloud. Se l'organizzazione è entusiasta degli straordinari benefit offerti dal cloud, ma non comprende chiaramente il rischio di transizione, rimarrà sorpresa dagli aumenti iniziali delle spese, in particolare durante l'assorbimento iniziale dei costi di migrazione, sovrapposizione dell'infrastruttura e transizione. Stabilire le giuste aspettative e non perdere di vista i progressi incrementali man mano che si verificano sono elementi essenziali per mantenere l'allineamento e la disciplina mentre l'organizzazione procede verso la transizione.

Inventario della migrazione al cloud

Un inventario della migrazione al cloud è fondamentale per il passaggio al cloud. Che cos'è un inventario della migrazione al cloud? In breve, è un elenco di tutti gli asset della flotta e degli elementi di dati critici associati che descrivono ciascun asset. Si tratta delle applicazioni destinate allo spostamento e di tutte le relative dipendenze. Il mezzo utilizzato per acquisire tali dati è irrilevante e spesso vengono utilizzati diversi strumenti quando i dati si estendono su più reparti all'interno di un'azienda. In genere le informazioni richieste si trovano in una serie di database operativi, di produzione e commerciali. Ad esempio, un database di gestione della configurazione può tenere traccia delle dipendenze tecniche e della posizione degli asset in dettaglio, tra cui i server fisici e i rack. Tuttavia, non includerà le considerazioni aziendali e dei clienti, che sono fondamentali per determinare quando e in che modo i clienti verranno informati della transizione. Tali informazioni sono spesso contenute in repository progettati per le operazioni e il supporto delle parti interessate. Inoltre, in caso di acquisizioni, casi d'uso speciali e archivi di prodotti, è possibile che le informazioni siano ulteriormente frammentate in più repository.

Lo scopo principale dell'inventario della migrazione è fornire una visione centralizzata dei fattori necessari per gestire la transizione al cloud. Ad esempio: qual'è l'asset? Dove si trova l'asset? Che prodotto supporta? A cosa serve? Quali clienti supporta?

Fin dall'inizio, è importante rendersi conto che il progetto è un documento dinamico. Deve essere flessibile, poiché si evolverà con il tempo, soprattutto nel caso di aziende con più applicazioni o più versioni di applicazioni. L'inventario si evolverà man mano che emergono nuovi problemi e vengono scoperte nuove esigenze. Anche l'infrastruttura cloud sottostante può cambiare nel corso di una migrazione, facendo così nuovamente evolvere l'inventario. L'inventario della migrazione dovrebbe acquisire quanti più dati disponibili, permettendoti di avviare la pianificazione iniziale e poi di aggiungere livelli di dettaglio man mano che la transizione rivela nuovi requisiti.

La gestione dell'inventario della migrazione è un progetto interfunzionale a sé stante che deve bilanciare la necessità di dati dettagliati con il lavoro di raccolta. Include anche elementi che identificano dipendenze, vincoli e risorse, che influenzeranno tempi e velocità, come specifiche tecniche granulari, approcci architetturali, requisiti del cliente e percorsi di trasferimento dei dati. Se il volume di informazioni è troppo ridotto, l'inventario non risulterà utile. Se al contrario è troppo elevato, sarà difficile da gestire e potrebbe diventare rapidamente obsoleto e inutilizzato.

Consigliamo il seguente framework di inventario della migrazione come punto di partenza per la migrazione al cloud.

Dall'inventario della migrazione all'inventario operativo

Sebbene la nostra attenzione si sia rivolta all'inventario della migrazione, la transizione al cloud in definitiva presenta due sfide. Più direttamente, crea la necessità di pianificare, assegnare priorità e tenere traccia delle attività di migrazione. Tuttavia, la migrazione stessa imporrà modifiche ai dati richiesti per il monitoraggio operativo quotidiano. Ad esempio, i dettagli di configurazione post-migrazione su server e rack fisici diventeranno irrilevanti e persino le informazioni sulle singole istanze diventeranno meno importanti. Allo stesso tempo, metriche come l'utilizzo complessivo e l'uscita di dati possono diventare critiche, in particolare quando le organizzazioni adottano modelli self-service.

La creazione di un inventario della migrazione dovrebbe dare inizio alla transizione a questi nuovi schemi e processi di dati basati sul cloud. Sebbene le sfide gemelle della creazione dell'inventario e della migrazione dell'applicazione siano progetti separati, non dovrebbero essere perseguite in modo isolato. La migrazione richiede il maggior impegno. Inoltre, potrebbe essere la prima volta che un'organizzazione crea una visione dettagliata e consolidata dei propri asset. Si tratta di un momento di trasformazione che dovrebbe creare il modello per una nuova visone dell'inventario post-migrazione. Come illustrato in precedenza, l'inventario della migrazione dovrà essere flessibile e adattabile. Se gestito correttamente, l'inventario della migrazione si evolverà in un prezioso strumento di gestione dell'inventario post-migrazione.

Seguire la strada verso il cloud

Progettazione dell'infrastruttura per l'hosting di applicazioni SaaS

Gli ISV che forniscono applicazioni basate su SaaS hanno bisogno di un'infrastruttura sicura, scalabile e di livello aziendale per ospitare i propri servizi e gestire i clienti in modo isolato. L'architettura di riferimento illustrata nella Figura 3 sotto riportata fornisce un framework convalidato che incorpora le best practice, consentendo di ospitare le applicazioni SaaS sull'infrastruttura Oracle Cloud.

In questa architettura di riferimento, è possibile distribuire e gestire più istanze di applicazioni isolate. Ogni distribuzione riguarda un tenant specifico e le singole istanze dell'applicazione tenant sono gestite mediante un livello di gestione comune.

È possibile scegliere di creare tutte le istanze dell'applicazione tenant da un unico codebase oppure offrire versioni personalizzate dell'applicazione a ciascun tenant. Questo modello è ideale per i clienti SaaS che richiedono il completo isolamento dell'ambiente applicativo.

Figura 3: Architettura di riferimento delle best practice per le applicazioni SaaS su OCI

Per maggiori dettagli sull'architettura di riferimento precedente, visita Oracle Architecture Center. Inoltre, abbiamo creato strumenti basati su Terraform per fornire assistenza nella distribuzione dell'architettura per quattro tenant, oltre a una guida dettagliata. Infine, consigliamo sempre di seguire la guida alle best practice dell'infrastruttura Oracle Cloud, che fornisce indicazioni su quattro obiettivi aziendali comuni: sicurezza e conformità, affidabilità e resilienza, ottimizzazione delle prestazioni e dei costi ed efficienza operativa.

Oltre alle modifiche a livello di architettura, è opportuno riflettere su come cambierà lo stack di servizi nel cloud. I set di strumenti principali utilizzati per il monitoraggio, la gestione della rete o la sicurezza distribuiti negli ambienti precedenti sviluppati per architetture on-premise si evolveranno per il cloud. Il passaggio al cloud offre l'opportunità di ampliare l'ambito di gestione a cui si dedicano tali strumenti. Anziché monitorare principalmente gli endpoint, gli strumenti basati su cloud consentono di monitorare tutto lo stack. A volte un provider di servizi cloud offre strumenti di monitoraggio basati su cloud o ibridi oltre alle capacità principali. Nel caso dell'infrastruttura Oracle Cloud, una combinazione di capacità native di monitoraggio, applicazione di tag e audit offre la possibilità di monitorare l'intero stack di servizi e spesso corregge automaticamente le anomalie rilevate rispetto alle norme specificate. Se oggi utilizzi strumenti di monitoraggio di terze parti on-premise, è possibile che questi fornitori offrano anche strumenti ibridi o basati su cloud.

---

Cisco Tetration esegue la migrazione dell'applicazione principale sull'infrastruttura Oracle Cloud e migliora le prestazioni di 60 volte.

"Quella con Oracle è una partnership straordinaria. Ed è per questo che Cisco Tetration sta avendo un successo strepitoso." - Navindra Yadav, Fondatore di Cisco Tetration

---

Sostieni il tuo programma pilota

Come avviene per qualsiasi attività tecnica, iniziare con un piccolo programma pilota o prototipo aumenta al massimo le probabilità di successo, poiché offre al team e all'organizzazione un'idea su cosa si può fare e come procedere. I programmi pilota e proof-of-concept identificano e risolvono le sfide senza incorrere nelle pressioni finanziarie e di tempo che derivano da un cambiamento su vasta scala a livello di organizzazione. I programmi pilota possono aiutarti a gestire il cambiamento supportando una transizione più lenta e consentendoti di acquisire familiarità con il nuovo ambiente operativo.

Il progetto pilota offre a un gruppo ristretto di sviluppatori e personale operativo l'opportunità di esplorare l'ambiente cloud di destinazione e di analizzare le architetture, i servizi e i modelli operativi. Questo team sviluppa una conoscenza pratica, strumenti utili e best practice, nonché fiducia, competenza ed esperienza. Allo stesso tempo, il team acquisisce conoscenza e sviluppa regole pratiche per la collaborazione tra team in un ambiente basato su cloud. La migrazione al cloud richiede che il ruolo dei team delle applicazioni si evolva da responsabili diretti delle risorse a consumatori di servizi forniti da altri team. Un progetto pilota consente ai team delle applicazioni di comprendere come cambieranno i confini dei servizi, creare relazioni con i team operativi che forniscono i servizi che utilizzeranno e imparare a far valere le proprie esigenze con questi team operativi.

I progetti pilota offrono i seguenti benefit:

• Un contesto in cui convalidare (o contestare) i presupposti sulla portabilità delle tecnologie, soprattutto nei casi in cui le tecnologie sono sempre state eseguite nello stesso ambiente. In questo modo i team potranno capire più facilmente se sono pronti per la migrazione e identifica cosa modificare per esserlo.
• Un'opportunità per confermare la disponibilità di applicazioni/database all'integrazione con i servizi nell'ambiente di destinazione. Questo indica ai team quali modifiche sono necessarie e quando l'ambiente dell'applicazione e quello dei servizi di destinazione sono pronti per la migrazione.
• L'abilità di costruire l'ambiente di destinazione, creando un punto d'appoggio, che diventa un punto di partenza per il resto del portfolio durante il passaggio a nuovi servizi e a un nuovo ambiente. In questo modo, i team ricevono obiettivi strategici per il proprio portfolio.

---

Manhattan Associates esegue la migrazione delle proprie soluzioni dedicate alla supply chain sull'infrastruttura Oracle Cloud e ottiene un risparmio dei costi del 50% rispetto alla precedente soluzione cloud.

"La versatilità e la flessibilità di Oracle Cloud sia a livello di applicazione che di database hanno determinato un risparmio di circa il 50% rispetto alle nostre precedenti soluzioni cloud in termini di infrastruttura." - Jeff Demenkow, Vice President di Manhattan Associates

---

Gestire un programma pilota

Il progetto pilota è un'esperienza di apprendimento per il personale tecnico e operativo, nonché per i team esecutivi e di gestione. I team esecutivi e di gestione dovrebbero comunicare costantemente con i team del progetto pilota per contribuire a rimuovere gli ostacoli organizzativi e garantire che l'organizzazione massimizzi le nozioni che emergono dal progetto pilota (ad esempio, cosa ha funzionato, cosa non ha funzionato, le best practice, le lezioni apprese e i pattern standard o gli anti-pattern identificati). Queste informazioni preziose possono essere acquisite e poi condivise con il resto dell'organizzazione, in modo da rendere i successivi progetti cloud più efficaci ed efficienti. Un progetto pilota consente al management di testare i presupposti utilizzati nel creare i propri piani e chiarire le aree di incertezza. Sebbene questi presupposti possano variare da un'organizzazione all'altra, i progetti pilota mettono in risalto alcune sfide chiave in qualsiasi migrazione.

• Formazione: i progetti pilota testano le competenze esistenti, rivelando fino a che punto l'organizzazione è pronta per il lavoro di migrazione tecnica. Il management dovrebbe utilizzare il progetto pilota per valutare le competenze tecniche, capire quali sono gli strumenti e le capacità più importanti da apprendere e pianificare come sviluppare rapidamente (o assumere personale con) competenze in queste aree chiave.
• Collaborazione: i progetti pilota mostrano in che modo i team di sviluppo, operativi e di supporto lavoreranno insieme in modo diverso. Il management dovrebbe garantire che questi team lavoreranno effettivamente insieme durante il progetto pilota, individuando nuovi requisiti e sviluppando una comprensione di come operare in questo nuovo ambiente.
• Desiderio di cambiamento: i progetti pilota sono un'opportunità per individuare barriere culturali che influiranno sulla migrazione a livello più ampio. Un gruppo che riscontra problemi in un progetto pilota avrà gli stessi problemi su larga scala. Il progetto pilota è un'opportunità per il management di identificare i problemi, formare le persone e adeguare i piani per tenere conto delle realtà della propria specifica organizzazione.

La chiave per una migrazione senza problemi consiste nel creare una base solida. La prima fase della migrazione guiderà lo sviluppo di un nucleo di servizi e piattaforme, che si espanderà gradualmente con il procedere della migrazione. Alla fine, queste capacità di base dovranno essere ridimensionate per supportare l'intero portfolio di migrazione. Di conseguenza, è fondamentale che le release cloud iniziali non solo riescano, ma aprano la strada a tutte le release e agli upgrade successivi.

Adattarsi ai cambiamenti organizzativi

Progettazione dell'infrastruttura per l'hosting di applicazioni SaaS

I cambiamenti nel modello di distribuzione dell'organizzazione e nelle relazioni con i clienti possono richiedere competenze, conoscenze, processi aziendali e approcci nuovi. Questi cambiamenti possono avere un impatto radicale su tutta l'organizzazione, motivo per cui spesso il cambiamento culturale è considerato l'aspetto più difficile della transizione al cloud.

L'ambito di questi cambiamenti può creare l'impressione che una transizione al cloud richieda una riorganizzazione su larga scala e l'introduzione di una forza lavoro sostitutiva con personale esperto e competente in materia di cloud. Sebbene i cambiamenti nella specializzazione funzionale interna e le nuove assunzioni incentrate sui set di competenze cloud siano componenti importanti della transizione al cloud, è altrettanto importante non perdere processi, dinamiche e collaboratori consolidati che sono stati fondamentali per il proprio successo fino ad oggi. È essenziale bilanciare la velocità del cambiamento organizzativo con potenziali interruzioni dell'attività in corso e delle esperienze cliente. Il mantenimento di questo equilibrio comporta un riallineamento dei cambiamenti strutturali alle capacità di sviluppo della carriera che consentirà ai dipendenti esistenti di passare al nuovo modello operativo.

La transizione di un'azienda software di lunga data verso modelli di distribuzione cloud richiede un enorme cambiamento a livello di presupposti, know-how tecnico e processi operativi standard in numerose aree aziendali chiave. Sebbene la quantità di modifiche necessarie possa essere scoraggiante, le nostre esperienze suggeriscono che generalmente è meglio conservare e investire nei team esistenti piuttosto che tentare una revisione completa degli esperti di cloud. Le organizzazioni che pianificano transizioni simili dovrebbero esaminare in che modo la nostra organizzazione GBU ha iniziato con una valutazione decentralizzata e dal basso verso l'alto delle esigenze di cambiamento, consentendo a ciascun team di creare i rispettivi inventari di migrazione e roadmap dello stack di servizi e individuando così i passi necessari all'interno delle rispettive aree di controllo. Questo approccio ha consentito ai team di allineare i propri programmi a fattori di cambiamento tangibili, evitando ipotesi di alto livello su ciò che potrebbero richiedere.

---

8x8 mantiene il mondo connesso, riduce i costi dell'80% e migliora i servizi passando all'infrastruttura Oracle Cloud.

"Man mano che le riunioni video sono diventate rapidamente il tessuto connettivo del nuovo mondo di oggi, abbiamo visto aumentare il numero dei nostri utenti. Per supportare questa crescita esponenziale e servire questa nuova ondata di clienti, abbiamo esaminato diverse piattaforme e scelto l'infrastruttura Oracle Cloud Gen 2 per la sua consolidata sicurezza, l'eccezionale rapporto prestazioni/prezzo e il supporto di livello mondiale." - Vik Verma, CEO, 8x8

Guarda il video

---

Impatti aziendali

Una svolta riuscita verso il cloud favorisce ed è favorita dai cambiamenti che si verificano in tutta l'organizzazione. Il passaggio da un portfolio prevalentemente in hosting oppure on-premise a un'attività basata su cloud richiederà cambiamenti fondamentali nel modo in cui l'organizzazione interagisce con i propri clienti. Tuttavia, il livello di cambiamento di prassi e presupposti aziendali sarà in gran parte influenzato dall'ambito della modifica del prodotto intrapresa nella transizione al cloud.

Anche in scenari in cui si registrano poche evoluzioni, il passaggio a IaaS guiderà i cambiamenti nei processi aziendali. Le nostre GBU hanno identificato due opportunità chiave di cambiamento in questo contesto.

1. Sostituisci la gestione dell'infrastruttura fisica ad alta intensità di spese in conto capitale (CapEx) con modelli di previsione orientati alle spese operative (OpEx) che tengono conto delle fluttuazioni a breve termine e delle aspettative a lungo termine
2. Promuovi l'evoluzione dei team di sicurezza e conformità che sono stati liberati dalle responsabilità tradizionali per concentrarsi sulla distribuzione di componenti dei servizi

Le organizzazioni che affrontano queste trasformazioni, insieme al cambiamento tecnico nelle rispettive applicazioni, si troveranno in una posizione migliore per realizzare il pieno potenziale della migrazione al cloud.

Allineamento del cliente

Il passaggio dall'offerta di un prodotto "sigillato", o anche da un prodotto in hosting, a un vero e proprio servizio cloud è un viaggio che tu e i tuoi clienti intraprenderete insieme. In effetti, è questo passaggio a un modello as-a-service che differenzia il cloud da tutte le precedenti modalità di hosting. Ogni modifica apportata a un servizio cloud avrà un impatto sull'esperienza del cliente, dalla scalabilità ai tempi di attività fino alla resilienza. In alcuni casi, il cliente potrebbe chiedere un passaggio, anche complesso, a un nuovo modello di distribuzione. In altri, le aspettative per funzioni, capacità e costi si evolvono in modi che possono essere supportati solo attraverso una distribuzione basata su cloud.

Quando inizi a coinvolgere i clienti nelle strategie cloud, devi prepararti ad affrontare entrambi i punti di vista: l'entusiasmo per la roadmap e la riluttanza a lasciare ciò che è familiare. Rispondere a questi punti di vista richiede una comunicazione chiara e misurata che indichi dove è diretto lo sforzo senza perdersi nei dettagli tecnici o allarmare gli interlocutori. Questo è un momento chiave per coinvolgere i team a contatto con i clienti all'interno dell'organizzazione e garantire che comprendano l'impegno profuso, l'investimento effettuato dall'azienda e i risultati previsti per il prodotto e la relativa distribuzione. Durante questa fase, i team a contatto con i clienti devono tradurre questo cambiamento in termini che rafforzino la fiducia dei clienti nel servizio.

Per i clienti che utilizzeranno il servizio cloud, lo scenario può diventare leggermente più complesso. Esistono segmenti di clienti che richiedono un servizio cloud e che comprendono i benefit offerti dalle soluzioni SaaS in termini di efficienza e agilità. Tuttavia, poiché le opzioni cloud o SaaS sono diventate opzioni percorribili, i clienti devono essere informati delle capacità e degli accordi a livello di servizio che contraddistinguono il servizio di un fornitore piuttosto che il valore del cloud stesso.

Non tutti i clienti desiderano un servizio cloud, tuttavia. In particolare, i clienti esistenti che utilizzano modelli di servizio in hosting o gestiti possono essere soddisfatti dello stato attuale, soprattutto se utilizzano componenti di servizi personalizzati o ambienti non standard e modelli di accesso non coerenti con la fornitura del cloud. Anche i clienti che riconoscono i benefit offerti dal passaggio a un servizio cloud possono sentirsi a disagio con le modifiche ai termini di consegna o le interruzioni del servizio necessarie per effettuare la migrazione dei propri ambienti.

Rassicurare i clienti richiede coordinamento e comunicazione coerente tra i team di marketing, vendita, supporto e successo dei clienti. A livello ideale, il cliente non si dovrebbe accorgere che è stata effettuata la migrazione dei suoi carichi di lavoro e un giorno dovrebbe notare un miglioramento delle prestazioni senza rendersi conto dei cambiamenti avvenuti. In realtà, la migrazione dei servizi al cloud richiede spesso upgrade e periodi di inattività e, potenzialmente, modifiche ai termini del servizio o alle funzionalità disponibili. Guidare un cliente attraverso questi eventi mantenendo allo stesso tempo l'allineamento alle tempistiche generali della transizione è un'impresa complessa, che richiede più della comprensione dei benefici derivanti dal cambiamento. In particolare, richiede l'adesione ai cambiamenti in atto e l'allineamento alle fasi di migrazione che possono avere un impatto sull'attività del cliente.

---

CMIC esegue la migrazione del software aziendale di costruzione sull'infrastruttura Oracle Cloud e le sue implementazioni diventano 10 volte più veloci.

"Oltre ai benefit ottenuti in termini di costi di OCI rispetto ad altri provider cloud, ora siamo diventati più agili. OCI ci ha dato un nuovo livello di flessibilità tecnologica. Ci stiamo muovendo verso il futuro con tecnologie come Oracle Container Services e Oracle Autonomous Database in modo da poter continuare a concentrarci sulla fornitura del miglior software ERP di costruzione disponibile." - Vince Di Piazza, Direttore di IT e infrastruttura cloud, CMIC

Guarda il video

---

Una volta accettati i benefit e le modifiche che accompagneranno la transizione al cloud, il passaggio finale da affrontare è lo spostamento effettivo dei carichi di lavoro del cliente nel nuovo ambiente. Questa operazione diventa una sfida per determinare il momento ottimale per la migrazione e il test di convalida del nuovo ambiente. Un cliente che accetta di dover affrontare un periodo di inattività probabilmente avrà un'idea precisa del momento in cui dovrebbe verificarsi tale periodo di inattività.

Sebbene la preferenza del cliente sia importante, devi trovare un compromesso con una serie di altre questioni. La pianificazione delle migrazioni implica un compromesso tra una moltitudine di fattori, inclusi gli attributi tecnici di un prodotto o servizio, la riconciliazione delle preferenze di tutti i clienti, le limitazioni delle risorse interne e gli obiettivi aziendali, come il consolidamento/l'eliminazione dei data center precedenti esistenti o la cessazione di linee di prodotto obsolete. Per bilanciare queste priorità contrastanti, includi i team a contatto con i clienti nelle attività di pianificazione della migrazione, poiché saranno una voce chiave nel rappresentare le aspettative del mercato.

L'organizzazione deve prepararsi sia a un periodo di investimento e migrazione, sia ai continui cambiamenti dei processi tecnici e aziendali di un modello di distribuzione del cloud, ma deve anche prepararsi a come coinvolgere i clienti per quanto riguarda la migrazione e a un nuovo status quo nel prodotto e nella relazione con il cliente.

Le nostre GBU hanno risposto a queste esigenze prima esaminando in che modo la transizione avrebbe influenzato i clienti dal punto di vista tecnico, operativo e in termini di impegni di consegna, isolando gli aspetti che avrebbero richiesto particolare attenzione, impegno e potenziali modifiche alla relazione commerciale. Gli sforzi compiuti per preparare i team a contatto con i clienti si basano su una prospettiva simile, che implica la collaborazione tra team di prodotto, operativi, strategici e di altro tipo per fornire una conoscenza generale del cloud, affrontando al tempo stesso cambiamenti specifici a livello di prodotto e cliente.

Questa attività va oltre la semplice preparazione dei team a contatto con i clienti e ha l'obiettivo di coinvolgere i clienti. Riunire una leadership centrale e interfunzionale per essere in linea con il coinvolgimento dei clienti ha anche creato preziose opportunità per espandere programmi precedentemente per la gran parte di natura tecnica in iniziative più ampie riguardanti la rivisitazione del valore fondamentale delle nostre soluzioni, una nuova articolazione di ciò che differenzia i nostri prodotti e la pianificazione dei modi migliori per preservare e far crescere quel valore all'interno del mercato.

Prepararsi in anticipo

Progettazione dell'infrastruttura per l'hosting di applicazioni SaaS

In questa guida vengono fornite indicazioni sulle best practice basate sulle lezioni apprese durante la migrazione di oltre 60 applicazioni GBU ospitate in migliaia di istanze. Di seguito viene fornito un riepilogo delle cinque principali sfide affrontate durante il nostro viaggio, poiché riteniamo che siano applicabili a qualsiasi organizzazione che esegue la migrazione delle applicazioni al cloud.

1. Stabilire l'impegno in termini di sviluppo prima della migrazione
   La preparazione di un'applicazione consolidata per il rilascio nel cloud può comportare un ingente investimento, soprattutto se si tratta di portare un prodotto a uno stato cloud nativo. L'investimento nei principi delle applicazioni cloud native produce il massimo benefit che puoi ottenere dal cloud e consuma una grande quantità di tempo e risorse di sviluppo per raggiungere lo stato finale. Più tempo è necessario per preparare un prodotto per il cloud, più ritarderai l'accesso ai benefit intrinseci e incrementali del passaggio al cloud, prolungando potenzialmente l'esposizione ai rischi in genere associati agli ambienti precedenti. Tuttavia, non tutti i prodotti ne beneficeranno allo stesso modo, a seconda della fase in cui si trovano nel loro ciclo di vita e della posizione del cliente. Comprendere e documentare appieno la quantità di lavoro di sviluppo da intraprendere prima della migrazione è la chiave per una migrazione riuscita.
   
   La flotta di applicazioni della GBU è diversificata e comprende prodotti a tutti i livelli della maturità cloud e delle fasi del ciclo di vita. Sebbene fosse necessario eseguire la migrazione nel cloud di tutte le applicazioni, si sono riscontrate difficoltà con la quantità di modifiche da apportare al prodotto prima del rilascio del cloud. Trovare il giusto equilibrio ha richiesto all'organizzazione di valutare ogni fase del ciclo di vita del prodotto, il suo potenziale di crescita e l'impegno necessario per portare il prodotto su cloud. Sulla base di queste valutazioni combinate, le GBU hanno determinato il livello di priorità e di spesa che sarebbe stato assegnato a ciascun prodotto.
2. Definire il mix di sviluppo
   Stabilire la quantità di larghezza di banda da dedicare alla preparazione degli investimenti nel cloud rispetto allo sviluppo di nuove caratteristiche e funzioni in risposta alla domanda del mercato ha rappresentato un difficile equilibrio da raggiungere per le GBU.
   
   Le GBU erano allineate sulla priorità della transizione al cloud, ma i team di prodotto hanno avuto difficoltà a capire quanto lavoro dovesse essere dedicato alle capacità cloud che avrebbero migliorato l'esperienza del cliente e le prestazioni, pur senza sostituire le funzioni richieste dai clienti. Lo sviluppo del cloud richiede investimenti in capacità operative sottostanti che potenzialmente distraggono dall'abilità dell'organizzazione di soddisfare la domanda dei clienti di contare su nuove funzioni. Questi compromessi rendono difficile capire come distribuire il tempo tra la disponibilità del cloud e le iniziative di miglioramento del prodotto.
   
   In risposta a questa sfida, le GBU si sono affidate ai framework di maturità del cloud discussi nel Capitolo 1 per ottenere approfondimenti sull'investimento di sviluppo relativo richiesto per ciascun percorso. Hanno quindi esaminato il ROI di ogni potenziale fase di transizione al cloud e hanno valutato tale risultato rispetto alla potenziale contribuzione ai ricavi prevista dallo sviluppo di nuove funzioni. Ciò ha fornito un framework di valutazione comune che potrebbe essere utilizzato per determinare il corretto mix di impegno, mantenendo la visibilità sui risultati aziendali finali.

   ---

   Altair sceglie l'High Performance Computing sull'infrastruttura Oracle Cloud e migliora il rapporto prezzo/prestazioni del 20%.

   "Quando abbiamo esaminato tutti i fornitori di cloud disponibili, abbiamo scoperto che Oracle dava particolare rilievo all'HPC. La sua offerta Bare Metal, che credo sia stata la prima nel settore, prevedeva una rete ad alta velocità e a bassa latenza, aspetti per noi molto importanti." - Piush Patel, Senior VP, Strategic Relations di Altair

   ---

3. Comprendere la flotta
   Indipendentemente dal fatto che la tua azienda disponga di una singola applicazione o di un ampio portfolio, ci sono molti fattori da monitorare e inventariare durante una migrazione al cloud. Per comprendere appieno quali modifiche devono essere apportate, è necessario conoscere a fondo l'inventario corrente dei diversi repository di applicazioni esistenti, nonché tutti gli elementi pianificati per l'uso nel cloud. Se le applicazioni di cui eseguire la migrazione sono molte, è possibile che non esista alcun inventario esistente o che si faccia riferimento a conoscenze implicite per quanto riguarda lo stato di applicazioni specifiche. Anche le aziende che dispongono di un'unica applicazione per i clienti devono comunque fare l'inventario dell'intero stack di applicazioni per stabilire quali aspetti devono cambiare quando si passa al cloud. La comprensione dei requisiti che cambieranno nel cloud e dell'aspetto del progetto è fondamentale per documentare il lavoro necessario per la transizione.
   
   Sono richiesti tipi e quantità di lavoro diversi per ciascuna istanza dell'applicazione, a seconda delle caratteristiche dell'istanza (versione, dipendenze hardware/piattaforma, personalizzazioni, modello di accesso del cliente e così via). Inoltre, i dati delle applicazioni possono essere distribuiti su più sistemi di record.
   
   Le Oracle GBU sono costituite dal consolidamento di oltre 30 acquisizioni con una flotta che si estende su 80 data center e oltre 12.000 istanze di applicazioni. I dati critici relativi a queste istanze erano altamente frammentati e non necessariamente gestiti in modo coerente dai diversi team di prodotto dei componenti. Senza queste informazioni, i team non potevano organizzare e pianificare efficacemente il lavoro di migrazione. Al fine di ottenere una chiara comprensione degli elementi di cui eseguire la migrazione, le GBU hanno dovuto avviare una raccolta dati dedicata e concentrarsi sul consolidamento.

   ---

   "Il team Oracle GBU è riuscito a ridurre le spese in conto capitale (CapEx) dell'80% e i costi di infrastruttura del 64% mediante la migrazione a OCI." - Mike Prindle, VP, GBU Cloud Architecture
   

   ---

4. Stabilire le priorità e organizzare la migrazione
   In realtà, lo spostamento dei carichi di lavoro può seguire diversi percorsi, che vanno dalla copia delle immagini delle VM esistenti all'installazione di una nuova istanza e alla replica dei dati, ma tutti richiedono un certo livello di investimento tecnico o impegno lavorativo per essere completati. Moltiplicati per ogni ambiente di prodotto nella flotta dell'organizzazione, la quantità e i vari tipi di lavoro coinvolti nella migrazione possono facilmente sembrare eccessivi. Le risorse disponibili per portare a termine la migrazione sono limitate e spesso sono anche responsabili della gestione delle operazioni quotidiane.

   ---

   OceanX sposta i propri sistemi di business intelligence sull'infrastruttura Oracle Cloud da Amazon Web Services (AWS) e registra un miglioramento delle prestazioni di 3 volte superiore.

   "Avevamo bisogno di una piattaforma dati scalabile che fornisse prestazioni elevate a un costo inferiore. La migrazione della piattaforma dati da AWS a Oracle è stata una delle migrazioni più riuscite di OceanX e, insieme a un significativo aumento delle prestazioni con notevoli risparmi sui costi, ha reso l'intero programma un risultato straordinario. In definitiva, ciò ci consente di offrire ai nostri clienti una piattaforma che consenta loro di prendere decisioni più informate, più velocemente." - Vijay Manickam, Vice President, Data and Analytics di OceanX

   ---

   La transizione della GBU al cloud ha richiesto più di 3.000 singoli progetti di migrazione. In origine questi progetti venivano assegnati in base alle preferenze del cliente (ovvero, dando priorità ai tempi di migrazione in base al feedback consolidato dei clienti) o alla disponibilità alla migrazione di un determinato ambiente. Alla fine, questo approccio non è riuscito a generare benefit aziendali incrementali nel corso della migrazione. Senza priorità comuni o framework di coordinamento, le GBU hanno registrato un volume incoerente di attività di migrazione. Ciò ha gravato sui team responsabili del completamento del lavoro di migrazione con periodi alternati di forti conflitti di risorse e disponibilità di risorse sprecate.
   
   Per risolvere queste difficoltà, le GBU hanno creato sia un ufficio centrale di gestione del programma dedicato alla migrazione, sia un comitato esecutivo di supervisione, responsabile della priorità delle migrazioni rispetto ai risultati aziendali finali e dell'identificazione delle opportunità strategiche.
5. Gestire il cambiamento organizzativo
   I cambiamenti coinvolti nella transizione al cloud richiedono nuove aree di conoscenza, competenze e processi, nonché altre aree di cambiamento culturale. La gestione di queste difficoltà correlate alle risorse umane può essere più difficile della gestione dei componenti tecnici della transizione al cloud. Per risolvere questo problema, le Oracle GBU hanno aiutato i team esistenti a evolversi in team cloud concentrandosi sulla formazione. La gestione della questione di quando assumere nuovi talenti e quando scoprire meccanismi per far evolvere altrimenti l'organizzazione ha richiesto alle GBU di condurre valutazioni della forza lavoro a fronte delle principali aree funzionali e dei gruppi di prodotti, per poi mappare l'iniziativa di miglioramento appropriata a ciascun caso d'uso. Se l'azienda dispone di più applicazioni da migrare, rifletti su dove puoi creare una conoscenza cloud di base che includa tutti i prodotti, come la sicurezza e l'IaaS generale.

Ottenere i risultati auspicati

Questa guida si basa sulle conoscenze accumulate dai nostri team Oracle GBU durante la migrazione di oltre 60 applicazioni basate su SaaS all'infrastruttura Oracle Cloud. Queste applicazioni supportano funzioni aziendali di base in otto settori verticali e oltre 199.000 clienti in tutto il mondo. Una migrazione diligente, pianificata e ben eseguita ha portato a benefit sostanziali.

• 80 data center consolidati a 11
• Spese in conto capitale (CapEx) ridotte dell'80%
• Costi di infrastruttura ridotti del 64%
• Fornitori di software ridotti da 28 a 10
• Spese software ridotte del 42%
• Passaggio alle versioni giornaliere del software
• Tempi di provisioning ridotti di oltre il 98%
• Tempi di inattività pianificati ridotti di oltre il 98%

Sebbene questa guida ISV sia basata sulle conoscenze acquisite dai nostri team GBU, il loro impegno ha rappresentato solo una delle numerose grandi migrazioni all'infrastruttura Oracle Cloud. Tenendo conto delle entrate e del numero di clienti di tutte le nostre applicazioni SaaS, Oracle può essere considerato uno dei più grandi ISV al mondo, in grado di comprendere il processo di migrazione. Abbiamo effettivamente spostato il nostro intero portfolio di prodotti, tra cui Oracle Fusion Cloud ERP, Oracle Fusion Cloud EPM, Oracle Fusion Cloud HCM, Oracle Advertising and CX e Oracle Fusion Cloud SCM nell'infrastruttura Oracle Cloud. Queste migrazioni fanno parte della nostra iniziativa di trasformazione che chiamiamo Oracle@Oracle. Si tratta di un progetto pluriennale che coinvolge decine di migliaia di applicazioni distribuite in decine di data center.

Ecco alcuni dei benefit che abbiamo registrato come risultato di questi sforzi.

• Infrastruttura: è stato raggiunto il 99,99% di disponibilità nel nostro portfolio di applicazioni con un risparmio sui costi del 30% e miglioramenti delle prestazioni da 2 a 10 volte
• Finance: è stata acquisita la capacità di chiudere i libri contabili e segnalare i profitti in meno di 10 giorni
• Risorse umane: il tempo del ciclo di revisione dei talenti è stato ridotto del 70%
• Catena di fornitura: il ciclo di pianificazione della catena di fornitura è stato ridotto da 1 settimana a 48 ore, per un miglioramento del 71%
• Esperienza clienti: il lead time della campagna si è ridotto da 4 settimane a 5 giorni, con un miglioramento dell'82%
• Sostenibilità: è stato riutilizzato o riciclato il 99,4% delle apparecchiature dismesse raccolte presso Oracle nell'esercizio 2019

Partnership con Oracle

Aiutiamo gli ISV a espandere il proprio mercato di riferimento, aumentando al contempo il potenziale di crescita dei ricavi. Per ulteriori informazioni, inviaci un messaggio di posta elettronica all'indirizzo: oraclecloud-isv_ww@oracle.com.

Per ulteriori informazioni sul motivo per cui gli ISV scelgono Oracle Cloud, consulta le seguenti risorse:

• isv.oracle.com
• Programma Oracle@Oracle per ISV
• Esplora il microsito dedicato alle considerazioni e ai modelli di cloud hosting

---

Körber consolida i sistemi di gestione del magazzino nell'infrastruttura Oracle Cloud e aumenta del 40% la velocità.

"Quando abbiamo valutato i diversi punti decisionali, OCI è apparso molto strategico per ciò che stavamo cercando di fare in termini di strategia di go-to-market." - Rick Schrader, Vice President senior North America Sales and Alliances di Körberö

Guarda il video

---