Il viaggio verso il cloud

Qualsiasi processo di trasformazione del cloud che includa la migrazione delle applicazioni sarà complesso. Eppure, tra 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, delineeremo alcune di queste destinazioni ed evidenzieremo le best practice e le lezioni apprese in base al nostro viaggio. La chiave del successo è definire chiaramente in anticipo gli obiettivi di migrazione in modo da poter prendere decisioni mirate su come raggiungerli. Ti troverai di fronte a molti percorsi potenziali. Nel corso della migrazione, sviluppatori, team di consegna e dirigenti dovranno valutare e fare molte scelte su come procedere.

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

Scalabilità

I servizi cloud forniscono potenza di calcolo su larga scala, ben oltre ciò che è possibile ottenere con le infrastrutture gestite, consentendo così alla tua attività di crescere per soddisfare le opportunità di mercato. L'infrastruttura basata sul cloud come servizio (IaaS) e sulla piattaforma come servizio (PaaS) consente agli ISV di concentrarsi sulla creazione di architetture scalabili utilizzando componenti moderni. Un ulteriore vantaggio della migrazione è che, liberando i team di sviluppo interni dalla gestione e dalla scalabilità delle operazioni IT, è possibile concentrarsi sulla messa a punto e sull'ottimizzazione delle performance.

Modernizzazione

La modernizzazione di set di strumenti, servizi e architetture facilita l'integrazione tra i componenti, aiutando le applicazioni a realizzare il pieno valore degli strumenti e delle tecnologie disponibili nel cloud. Tali strumenti spaziano dagli aggiornamenti dell'infrastruttura alle pipeline di distribuzione automatizzate fino ai modelli di machine learning integrati che migliorano le performance 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 funzionalità. I tuoi team possono rinnovare lo stack tecnologico per concentrarsi su nuove funzionalità di prodotto generalmente applicabili piuttosto che su codice personalizzato collegato a implementazioni di clienti specifici. Con il provisioning dei servizi, gli aggiornamenti dei prodotti e l'assistenza clienti a ritmi più veloci rispetto al passato, le risorse possono essere riorientate sullo sviluppo di nuove funzionalità. In questo modo, la migrazione al cloud pone le basi per un'ampia ondata di attività di modernizzazione, trasformando tutto, dall'esecuzione degli aggiornamenti dei prodotti alla qualità del customer service.

---

"La migrazione a Gen2 Cloud ha consentito a Oracle di garantire la consegna di successo dei 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 di rendere i team più flessibili e sostituibili. Man mano che le organizzazioni crescono, i tuoi team adotteranno strumenti di vari livelli di maturità. Il consolidamento di questi set di strumenti all'interno del servizio cloud astrae gran parte della complessità associata a questo livello di gestione IT. Consente lo sviluppo e l'uso di pratiche operative standard per attività che possono essere mappate in tutto il portfolio. La standardizzazione rende anche le attività di routine più semplici e prevedibili, riducendo la domanda di manodopera per le attività 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 prossima generazione per i clienti.

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

Ottimizzazione dei ricavi

L'ottimizzazione dei ricavi può essere ottenuta in due modi principali. Il primo, e più ovvio, è la riduzione dei costi. L'eliminazione dei data center utilizzando soluzioni IaaS non solo sposta il modello finanziario da CapEx a OpEx, ma in genere si traduce anche in significativi risparmi sul TCO. Ciò che potrebbe non essere così ovvio sono i 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 trattano l'infrastruttura come codice forniscono un'automazione che alla fine consente di risparmiare tempo e costi di manodopera. Infine, i team specializzati in aree fondamentali che si applicano a tutto il 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 le entrate aiutandoti a raggiungere il mercato più rapidamente, poiché i tempi di sviluppo del prodotto vengono generalmente ridotti, se un'applicazione è pronta per il cloud o è nativa per il cloud. Entrare nel 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 implementazione. 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 riorientare le risorse sul miglioramento della qualità e dell'integrità del servizio per i clienti.

---

WorkForce Software migra la propria soluzione di gestione della forza lavoro su Oracle Cloud Infrastructure e realizza un aumento delle performance del 30%.

"Abbiamo ottenuto una performance finanziaria che ci ha permesso subito di risparmiare dal 30 al 35% di spese CapEx e, grazie alle ottime performance di OCI, il ROI che forniamo con la nostra suite continua a migliorare sempre di più." —Mike Morini, Chief Executive Officer, WorkForce Software

Per saperne di più

---

Percorsi verso il valore nel cloud

Il cloud computing può includere una serie di risorse IaaS e PaaS, nonché molteplici modelli di implementazione del software, che vanno dall'accesso a istanze bare metal ad ambienti containerizzati integrati a 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 difficoltà. La conversione della piattaforma può essere costosa sia dal punto di vista del tempo che del lavoro, quindi non sorprende che a volte possa essere più semplice progettare da zero i componenti principali nativi nel cloud. Tenendo presente questo aspetto, quando considerano una migrazione al cloud, le aziende in genere si trovano in uno dei seguenti tre scenari principali.

• Abbandono di data center legacy: la gestione di un data center è costosa. Edifici, persone, alimentazione, raffreddamento, manutenzione e aggiornamenti sono solo alcune delle responsabilità quotidiane. Molte aziende stanno lavorando attivamente per ridurre o eliminare la loro dipendenza dai data center, valutando i portafogli di applicazioni affinché i candidati possano trasferirsi fuori sede. La priorità è spostare le applicazioni al di fuori di un hosting collocato nello stesso punto e gestito o dai data center on-premise nel tentativo di ridurre o eliminare le spese di capitale. Spesso viene utilizzata una strategia lift-and-shift in base alla quale l'applicazione viene migrata così com'è su un server bare metal o su una macchina virtuale nel cloud.
• Evoluzione dello stack tecnologico: in questo caso, le aziende iniziano ad apportare modifiche incrementali alle applicazioni che richiedono investimenti aggiuntivi, ma ci si aspetta anche che col tempo apportino più 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 è a volte indicata come una strategia move-and-improve.
• Migrazione dell'intero stack al cloud nativo: i vantaggi della riprogettazione totale di un'applicazione per fare in modo che sia pronta per il cloud potrebbero superare i costi di mantenere intatta un'applicazione meno matura durante l'implementazione di uno degli scenari sopra menzionati. Le applicazioni cloud native sono altamente distribuite in natura e spesso sono costruite utilizzando principi a 12 fattori e sono quindi 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 come Oracle definisce il cloud nativo, le origini delle app cloud native e le best practice da seguire durante la loro creazione, ti invitiamo a leggere questo e-book.

---

Un altro modo per immaginare questi scenari è esaminare lo spettro di azioni che potresti intraprendere per migrare un'applicazione aziendale a un'architettura cloud nativa mentre la trasferisci a Oracle Cloud Infrastructure. Vedere la Figura 1 qui di seguito.

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

Il lato sinistro della Figura 1 rappresenta la quantità minima di cambiamento, il time to value più breve e l'investimento iniziale più basso. Il livello 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. Da notare 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 dell'ambito delle modifiche tecniche e di processo necessarie per la transizione al cloud. In un mondo perfetto, la transizione al cloud dovrebbe portare tutte le applicazioni a passare a modelli di distribuzione nativi nel cloud. Tuttavia, dati i vincoli di tempo e risorse, poche organizzazioni sono in grado di trasferire l'intero portfolio a un modello nativo nel cloud in un unico processo. Anche i semplici sforzi di trasformazione della piattaforma esistente possono richiedere molte risorse e investimenti significativi, anche solo per replicare le funzionalità legacy.

La transizione al cloud consiste quindi nell'identificare i compromessi tra il livello di maturità cloud ottimale (in cui le applicazioni si trovano nel continuum da ospitato nel cloud al cloud nativo mostrato sopra) e l'investimento ingegneristico necessario per riprogettare il prodotto e i processi di business associati. In questa fase, il passaggio chiave è identificare i livelli di maturità attuali e target di ogni applicazione con una stima approssimativa degli investimenti di sviluppo necessari per colmare il divario.

Le applicazioni che cambiano i livelli di maturità durante la migrazione devono anche modificare i modelli operativi e le aspettative. La modifica dei livelli di maturità influisce sui team, sui processi e sulle politiche 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 dell'attenzione dovrebbe essere l'identificazione delle capacità richieste dall'applicazione e il modo in cui si relazionano con queste dipendenze. Ciò determinerà la tempistica relativa alle attività di migrazione e aiuterà a identificare le aree chiave di interesse. La valutazione dovrebbe affrontare tre dimensioni critiche.

1. Requisiti dell'infrastruttura: il cloud separa il software dall'hardware o dagli ambienti operativi sottostanti. Le applicazioni a elevata maturità sono essenzialmente indipendenti dal loro ambiente, basandosi solo 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 della tua applicazione devono essere prima documentate ed eventualmente eliminate. Non è raro trovare personalizzazioni (realizzate da te o dai tuoi clienti) che sono legate/accoppiate all'infrastruttura sottostante.
2. Componenti dei servizi: il cloud offre funzionalità di supporto come servizi autonomi gestiti e forniti indipendentemente dall'applicazione. Le applicazioni ad elevata maturità sono progettate su componenti discreti con dipendenze minime nello stack, consentendo modifiche e aggiornamenti 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: il cloud cambia le architetture tecniche, i processi di lavoro, le competenze, gli strumenti disponibili e i 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à troveranno servizi di supporto critici mancanti nel cloud, avranno team che li supportano con set di competenze inadatti per il lavoro cloud o utilizzeranno processi che potrebbero subire interruzioni in seguito a un 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. È difficile sottovalutare la complessità di una migrazione, poiché gli attuali ambienti di produzione, le suite di servizi di supporto e l'ambiente cloud di destinazione continueranno a evolversi durante tutto il processo. La scoperta di collegamenti tra servizi e applicazioni non solo consente una pianificazione intelligente in anticipo, 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 con roadmap in continua evoluzione.

---

Zoom scala e attiva rapidamente milioni di riunioni simultanee su Oracle Cloud Infrastructure.

"Di recente abbiamo sperimentato la crescita più significativa che la nostra attività abbia mai visto, con la richiesta di un incremento enorme della nostra capacità di servizio. Abbiamo analizzato più piattaforme e Oracle Cloud Infrastructure è stata fondamentale perché ci ha aiutato a scalare rapidamente la nostra capacità e a soddisfare le esigenze dei nostri nuovi utenti." — Eric S. Yuan, CEO, Zoom

Per saperne di più

---

Obiettivi finanziari

Come con qualsiasi iniziativa IT, la transizione al cloud richiede una serie di investimenti per raggiungere il suo pieno valore, soprattutto se l'applicazione di destinazione è stata creata per un modello di hosting on-premise. Le applicazioni ritenute degne di passare al cloud alla fine diventeranno con il tempo native nel cloud o verranno dismesse. Tuttavia, l'obiettivo iniziale è in genere quello di portare un'applicazione a uno stato di rilascio nel cloud.

Quello che serve per portare la tua applicazione dal suo stato attuale allo stato di rilascio nel 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'app pronta per il cloud prima dello spostamento (nel qual caso saranno necessari alcuni investimenti per spostare parti dello stack dell'applicazione su un modello basato su cloud, ad esempio, spostando il database da locale a DBaaS o Oracle Autonomous Database)? Se hai creato personalizzazioni assolute per abilitare funzionalità specifiche del cliente, dovranno essere oggetto di refactoring per un modello in cui i componenti della piattaforma sono incapsulati e forniti tramite API come funzionalità di prodotto. Le dipendenze hardware o di piattaforma dovranno essere rimosse per scalare 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 le modifiche necessarie al prodotto, associate alla fase di migrazione al cloud di cui abbiamo appena discusso. Tuttavia, è necessario contabilizzare anche le spese aggiuntive. Tra le spese che la tua organizzazione potrebbe sostenere durante la transizione sono incluse:

• Investimenti per lo sviluppo: lavoro di sviluppo richiesto per riprogettare il prodotto o creare acceleratori per la migrazione, inclusa l'automazione per supportare 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 lo smantellamento di inventari legacy
• Utilizzo dell'infrastruttura: canoni di abbonamento maturati attraverso il consolidamento delle soluzioni IaaS, che passerà a uno stato stazionario, ma presenterà nuove fasi di aumento durante il periodo di migrazione
• Infrastrutture bloccate: Costi persistenti di ammortamento del data center e CapEx che maturano durante la migrazione fino a quando 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 con le competenze necessarie per il cloud
• Transizione del cliente: costi associati a modifiche alle caratteristiche ambientali o ai 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 in bucket una tantum, anche se le risorse associate a questo lavoro possono essere riparate. L'adozione di nuove infrastrutture comporterà un aumento netto delle spese per un periodo di tempo fino all'eliminazione delle spese infrastrutturali bloccate. 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, comporteranno potenzialmente nuove spese continuative.

Comprendere come si svolgeranno queste dinamiche nel tempo è essenziale per la tua organizzazione per preparare e impostare le aspettative per la transizione al cloud. Se la tua organizzazione è entusiasta degli straordinari vantaggi del cloud, ma non ha una chiara comprensione del rischio di transizione, rimarrai sorpreso dagli aumenti iniziali delle spese, in particolare durante la migrazione, la sovrapposizione dell'infrastruttura e i costi di transizione. Stabilire le giuste aspettative e mantenere la visibilità dei 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 di migrazione cloud? In breve, è un elenco di tutte le risorse della flotta e degli elementi di dati critici associati che descrivono ciascuna risorsa. Sono le applicazioni destinate allo spostamento e tutte le loro dipendenze. Il mezzo utilizzato per acquisire tali dati è irrilevante e non è raro utilizzare diversi strumenti poiché i dati spesso si estenderanno su più reparti di un'azienda. Le informazioni richieste sono solitamente sparse 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 delle risorse in dettaglio, fino ai server fisici e alle posizioni dei rack. Tuttavia, non includerà le considerazioni aziendali e dei clienti che sono vitali per determinare quando e come i clienti saranno informati della transizione. Tali informazioni sono spesso contenute in repository progettati per le operazioni e supportano le parti interessate. Inoltre, acquisizioni, casi d'uso speciali e silos di prodotti possono significare che le informazioni sono 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. Per esempio: qual è l'asset? Dov'è l'asset? Che prodotto supporta? Che cosa fa? Quali clienti supporta?

Fin dall'inizio, è importante rendersi conto che le specifiche sono un documento vivente. Devono essere flessibili, poiché evolveranno 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 delle migrazioni 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 delle migrazioni è 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. Troppe poche informazioni e l'inventario non è utile. Troppe e diventa un fardello da mantenere, che può rapidamente diventare obsoleto e inutilizzato.

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

Dall'inventario di migrazione all'inventario operativo

Sebbene ci siamo concentrati sull'inventario delle migrazioni, la transizione al cloud presenta in definitiva 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 di migrazione dovrebbe iniziare la transizione a questi nuovi schemi e processi di dati incentrati sul cloud. Sebbene le sfide gemelle della creazione dell'inventario e della migrazione dell'applicazione siano progetti separati, non dovrebbero essere perseguiti in modo isolato. La migrazione richiede il maggior impegno e potrebbe essere la prima volta che un'organizzazione crea una visione dettagliata e consolidata delle proprie risorse. È un momento di trasformazione che dovrebbe creare il modello per una nuova visone dell'inventario post-migrazione. Come discusso in precedenza, l'inventario delle migrazioni 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

In qualità di ISV che fornisce applicazioni basate su SaaS, hai bisogno di un'infrastruttura sicura, scalabile e di livello aziendale per ospitare i tuoi servizi e gestire i tuoi clienti in modo isolato. L'architettura di riferimento illustrata nella Figura 3 di seguito fornisce un framework convalidato che incorpora le best practice, consentendoti di ospitare le tue applicazioni SaaS su Oracle Cloud Infrastructure.

In questa architettura di riferimento, distribuisci e gestisci più istanze di applicazioni isolate. Ogni distribuzione è per un tenant specifico e queste singole istanze dell'applicazione tenant sono gestite tramite un livello di gestione comune.

È possibile scegliere di creare tutte le istanze dell'applicazione tenant da un'unica base di codice 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: un'architettura di riferimento delle best practice per le applicazioni SaaS su OCI

Per maggiori dettagli riguardanti l'architettura di riferimento di cui sopra, visitare Oracle Architecture Center. Inoltre, abbiamo creato strumenti basati su Terraform per assistere nella distribuzione dell'architettura per quattro tenant, oltre a una guida dettagliata. Infine, consigliamo sempre di seguire la Guida alle best practice di Oracle Cloud Infrastructure, che forniscono indicazioni su quattro obiettivi aziendali comuni: sicurezza e compliance, affidabilità e resilienza, ottimizzazione delle performance e dei costi ed efficienza operativa.

Oltre alle modifiche architetturali, devi pensare a come cambierà il tuo stack di servizi nel cloud. I set di strumenti principali utilizzati per il monitoraggio, la gestione della rete o la sicurezza distribuiti in ambienti legacy sviluppati per architetture on-premise si evolveranno per il cloud. Il passaggio al cloud offre l'opportunità di ampliare la portata di ciò che questi strumenti gestiscono. Invece di monitorare principalmente gli endpoint, gli strumenti basati su cloud offrono il monitoraggio di tutto lo stack. A volte un fornitore di servizi cloud offre strumenti di monitoraggio basati su cloud o ibridi oltre alle funzionalità principali. Nel caso di Oracle Cloud Infrastructure, una combinazione di funzionalità native di monitoraggio, tagging e auditing offre la possibilità di monitorare l'intero stack di servizi e spesso correggere automaticamente le anomalie rilevate al di fuori delle norme specificate. Se oggi utilizzi strumenti di monitoraggio di terze parti on-premise, tali fornitori possono offrire anche strumenti ibridi o basati su cloud.

---

Cisco Tetration migra la sua applicazione principale su Oracle Cloud Infrastructure e realizza un aumento delle performance di 60 volte.

"La partnership con Oracle è stata fantastica. Ecco perché sta accadendo tutta questa magia con Cisco Tetration." — Navindra Yadav, fondatore, Cisco Tetration

---

Sostieni il tuo programma pilota

Come con qualsiasi sforzo ingegneristico, iniziare con un piccolo programma pilota o prototipo massimizza le probabilità di successo, poiché fornisce al team e alla tua organizzazione un'idea di cosa si può fare e di come procedere. I programmi pilota e proof-of-concept identificano e risolvono le sfide senza le pressioni finanziarie e legate alle tempistiche che derivano da un cambiamento su vasta scala a livello di organizzazione. Muovendosi lentamente e acquisendo familiarità con il nuovo ambiente operativo, i programmi pilota possono aiutarti a gestire il cambiamento.

Il progetto pilota è un'opportunità per un gruppo di sviluppatori e personale operativo 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 tuo team acquisisce conoscenza e sviluppa regole pratiche per la collaborazione tra team in un ambiente basato su cloud. La migrazione al cloud richiede che i team delle applicazioni evolvano da gestori diretti di 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 sostenere le proprie esigenze con questi team operativi.

I progetti pilota offrono i seguenti vantaggi:

• Un contesto in cui convalidare (o sfidare) i presupposti sulla portabilità delle tecnologie, soprattutto nei casi in cui le tecnologie sono sempre state eseguite nello stesso ambiente. Questo aiuta i team a capire se sono pronti per la migrazione e identifica cosa deve cambiare 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 sia l'ambiente dell'applicazione che quello dei servizi di destinazione sono pronti per la migrazione.
• La capacità di costruire per l'ambiente di destinazione, creando un punto d'appoggio, che diventa un punto di partenza per il resto del portfolio mentre si spostano verso nuovi servizi e un nuovo ambiente. Questo dà ai team obiettivi strategici per il proprio portfolio.

---

Manhattan Associates migra le proprie soluzioni per la supply chain su Oracle Cloud Infrastructure e consente di risparmiare il 50% sui costi rispetto alla precedente soluzione cloud.

"La versatilità e la flessibilità di Oracle Cloud sia a livello di app che di database ha portato a un risparmio di circa il 50% rispetto alle nostre precedenti soluzioni cloud in termini di infrastruttura." — Jeff Demenkow, Vicepresidente, 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 continuamente con i team del progetto pilota per aiutare a rimuovere gli ostacoli organizzativi e garantire che l'organizzazione massimizzi le nozioni che emergono dal progetto pilota (cioè cosa ha funzionato, cosa non ha funzionato, le best practice, le lezioni apprese e i modelli standard o i non modelli individuati). Queste preziose informazioni possono essere acquisite e quindi condivise con il resto dell'organizzazione, rendendo idealmente i successivi progetti cloud più efficaci ed efficienti. Un progetto pilota consente al management di testare i presupposti utilizzati nella progettazione dei piani e di 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 strumenti e capacità sono più importanti da apprendere e pianificare come sviluppare rapidamente (o assumere) competenze in queste aree chiave.
• Collaborazione: i progetti pilota mostrano come 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.
• Voglia di cambiamento: i progetti pilota sono un'opportunità per trovare barriere culturali che influiranno sulla migrazione in maniera più ampia. Un gruppo che ha problemi in un progetto pilota avrà la stessa reazione su larga scala. Il progetto pilota è un'opportunità per il management di identificare i problemi, formare le persone e adeguare i piani per tener conto delle realtà della loro particolare organizzazione.

La chiave per una migrazione senza problemi è 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 funzionalità di base dovranno essere dimensionate per supportare l'intero portfolio di migrazione. Di conseguenza, è fondamentale che le versioni cloud iniziali non solo abbiano successo, ma aprano la strada per tutte le versioni e gli aggiornamenti successivi.

Adattarsi ai cambiamenti organizzativi

Progettazione dell'infrastruttura per l'hosting di applicazioni SaaS

I cambiamenti nel modello di consegna 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 si dice che il cambiamento culturale sia l'aspetto più difficile della transizione al cloud.

La portata di questi cambiamenti può creare l'impressione che una transizione al cloud richieda una riorganizzazione su larga scala e l'introduzione di sostituzioni della forza lavoro con personale esperto e competente di cloud. Sebbene i cambiamenti nella specializzazione funzionale interna e le nuove assunzioni incentrate sui set di competenze cloud siano componenti principali della transizione al cloud, non puoi permetterti la perdita di processi, dinamiche e collaboratori consolidati che sono stati la chiave del tuo successo fino ad oggi. È essenziale bilanciare la velocità del cambiamento organizzativo con potenziali interruzioni dell'attività in corso e delle esperienze dei clienti. 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 di software di lunga data verso modelli di distribuzione cloud richiede un enorme cambiamento nei presupposti, nel know-how tecnico e nei processi operativi standard in numerose aree aziendali chiave. Sebbene la quantità di modifiche necessarie possa essere scoraggiante, le nostre esperienze suggeriscono che generalmente è meglio mantenere e investire nei team esistenti piuttosto che tentare una revisione completa degli esperti di cloud. Le organizzazioni che pianificano transizioni simili dovrebbero esaminare come la nostra organizzazione GBU è iniziata 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 a Oracle Cloud Infrastructure.

"Poiché le riunioni video sono diventate rapidamente il tessuto connettivo del nuovo mondo di oggi, abbiamo visto aumentare il numero di 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 performance-prezzo e il supporto di livello mondiale." — Vik Verma, CEO, 8x8

Guarda il video

---

Impatti aziendali

Un pivot di successo verso il cloud abilita ed è allo stesso tempo abilitato dalle modifiche all'interno dell'organizzazione. Il passaggio da un portfolio prevalentemente in hosting oppure on-premise a un'azienda basata su cloud richiederà cambiamenti fondamentali nel modo in cui la tua organizzazione interagisce con i propri clienti. Tuttavia, la misura in cui le business practice consolidate e le ipotesi cambiano sarà in gran parte modellata 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à CapEx con modelli di previsione orientati all'OpEx che tengono conto delle fluttuazioni a breve termine e delle aspettative a lungo termine
2. Fai evolvere i team di sicurezza e compliance che sono stati liberati dalle responsabilità tradizionali per concentrarsi sulla fornitura di componenti dei servizi

Le organizzazioni che affrontano questi cambiamenti, insieme al cambiamento tecnico nelle loro applicazioni, saranno in una posizione migliore per realizzare il pieno potenziale della migrazione al cloud.

Allineamento del cliente

Il passaggio dall'offrire 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 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 funzionalità, capacità e costi si evolvono in modi che possono essere supportati solo attraverso una distribuzione basata su cloud.

Quando inizi a coinvolgere i tuoi clienti nelle tue strategie cloud, devi prepararti a entrambi i punti di vista: l'entusiasmo per la roadmap e la riluttanza a lasciare ciò che è familiare. Rispondere a queste prospettive richiede una comunicazione chiara e misurata che indichi dove è diretto lo sforzo senza perdersi nei dettagli tecnici o sollevare bandiere rosse. Questo è un momento chiave per coinvolgere i team a contatto con i clienti all'interno della tua organizzazione e garantire che comprendano l'impegno profuso, l'investimento effettuato dall'azienda e i risultati previsti per il prodotto e la sua distribuzione. In tal modo, i tuoi team a contatto con i clienti devono tradurre questo cambiamento in termini che rafforzeranno la fiducia dei clienti nel servizio.

Per i clienti che utilizzeranno il servizio cloud, lo scenario può diventare un po' più complicato. Ci sono segmenti di clienti che richiedono un servizio cloud e che comprendono i vantaggi offerti dalle soluzioni SaaS in termini di efficienza e agilità. Tuttavia, poiché le opzioni cloud o SaaS sono diventate una posta in gioco, i clienti devono essere istruiti sulle capacità e sugli accordi sul livello di servizio che contraddistinguono il servizio di un fornitore piuttosto che il valore del cloud stesso.

Tuttavia, non tutti i clienti vogliono un servizio cloud. In particolare, i clienti esistenti su modelli di servizi in hosting o gestiti possono essere soddisfatti dello stato attuale, soprattutto se dispongono di componenti di servizi personalizzati o ambienti non standard e modelli di accesso non coerenti con la fornitura del cloud. Anche i clienti che vedono i vantaggi del passaggio a un servizio cloud possono sentirsi a disagio con le modifiche ai termini di consegna o le interruzioni del servizio necessarie per migrare i propri ambienti.

Rassicurare i clienti richiede coordinamento e comunicazione coerente tra i team di marketing, vendita, supporto e successo dei clienti. In un mondo ideale, il cliente non si dovrebbe accorgere che i suoi carichi di lavoro sono stati migrati e un giorno noterà un miglioramento delle performance senza rendersi conto dei cambiamenti avvenuti. La realtà è che la migrazione dei servizi al cloud richiede spesso aggiornamenti 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 alla linea temporale generale di transizione è un'impresa complessa, che richiede qualcosa in più rispetto alla comprensione dei benefici derivanti dal cambiamento. Richiede l'adesione ai cambiamenti in atto e l'allineamento alle fasi di migrazione che possono potenzialmente avere un impatto sull'attività del cliente.

---

CMIC migra il proprio software aziendale di costruzione su Oracle Cloud Infrastructure e le sue implementazioni diventano 10 volte più veloci.

"Oltre ai vantaggi 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, Director of IT and Cloud Infrastructure, CMIC

Guarda il video

---

Una volta accettati i vantaggi e le modifiche che accompagneranno la transizione al cloud, il passaggio finale da affrontare è spostare effettivamente i carichi di lavoro del cliente nel nuovo ambiente. Questa 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à avrà spesso un'idea precisa su quando dovrebbe verificarsi tale periodo di inattività.

Sebbene la preferenza del cliente sia importante per te, devi trovare un compromesso con una serie di altre preoccupazioni. 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/eliminazione dei data center legacy esistenti o la cessazione di linee di prodotto deprecate. 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.

La tua organizzazione deve prepararsi sia per un periodo di investimento e migrazione, sia per i continui cambiamenti dei processi tecnici e aziendali di un modello di erogazione del cloud, ma deve anche prepararsi sia su come coinvolgere i clienti per quanto riguarda la migrazione sia per 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 prodotto, operazioni, strategia e altri team per fornire un'alfabetizzazione generale del cloud e, al tempo stesso, si affrontano prodotti e modifiche specifici del cliente.

Questo aspetto andava oltre la semplice preparazione dei team a contatto con i clienti e aveva l'obiettivo di coinvolgerli. Riunire una leadership centrale e interfunzionale per essere in linea con il coinvolgimento dei clienti ha anche creato preziose opportunità per espandere ciò che erano stati in gran parte programmi guidati tecnicamente in iniziative più ampie sulla rivisitazione del valore fondamentale delle nostre soluzioni, su una nuova articolazione di ciò che differenzia i nostri prodotti e sulla 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, abbiamo fornito indicazioni sulle best practice basate sulle lezioni apprese durante la migrazione di oltre 60 applicazioni GBU ospitate in migliaia di istanze. Di seguito riepiloghiamo le 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 dobbiamo portare un prodotto allo stato nativo del cloud. L'investimento nei principi delle applicazioni native del cloud produce il massimo vantaggio che puoi ottenere dal cloud, consumando 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 vantaggi intrinseci e incrementali del passaggio al cloud, potenzialmente prolungando l'esposizione ai rischi tipicamente associati agli ambienti legacy. Allo stesso tempo, non tutti i prodotti ne beneficeranno allo stesso modo, a seconda della loro fase del 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 di successo.
   
   Il parco di applicazioni della GBU è diversificato, comprende prodotti a tutti i livelli della maturità cloud e delle fasi del ciclo di vita. Sebbene tutte le applicazioni dovessero essere migrate nel cloud, hanno avuto 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 nel 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
   Decidere quanta larghezza di banda offrire alla preparazione degli investimenti nel cloud rispetto allo sviluppo di nuove caratteristiche e funzioni in risposta alla domanda del mercato ha presentato 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 doveva essere dedicato alle funzionalità cloud che avrebbero migliorato l'esperienza del cliente e le performance, ma non erano le sostituzioni delle funzionalità che i clienti chiedevano. Lo sviluppo del cloud richiede investimenti in capacità operative sottostanti che potenzialmente distraggono dalla capacità dell'organizzazione di rispondere alla domanda dei clienti di nuove funzionalità. Questi compromessi rendono difficile capire come distribuire il tempo tra la disponibilità del cloud e le iniziative di miglioramento del prodotto.
   
   Per rispondere a questa sfida, le GBU si sono affidate ai framework di maturità del cloud discussi nel Capitolo 1 per fornire informazioni sul relativo investimento di sviluppo richiesto per ciascun percorso. Hanno quindi esaminato il ROI di ogni potenziale fase di transizione al cloud e hanno valutato tale risultato rispetto al potenziale contributo ai profitti previsto dallo sviluppo di nuove funzionalità. Ciò ha fornito un quadro di valutazione comune che potrebbe essere utilizzato per determinare il corretto mix di impegno, mantenendo la visibilità sui risultati aziendali di destinazione.

   ---

   Altair sceglie il calcolo ad alte prestazioni su Oracle Cloud Infrastructure e migliora il rapporto prezzo/performance del 20%.

   "Quando abbiamo esaminato tutti i fornitori di cloud disponibili, abbiamo scoperto che Oracle era molto concentrato sull'HPC. La loro offerta bare metal, che credo sia stata la prima nel settore, aveva una rete ad alta velocità e a bassa latenza, aspetti per noi molto importanti." — Piush Patel, Senior VP of Strategic Relations, Altair

   ---

3. Capire la flotta
   Indipendentemente dal fatto che la tua azienda disponga di una singola applicazione o di un ampio portfolio, ci sono molti fattori di cui tenere traccia e inventariare durante una migrazione al cloud. Per comprendere appieno quali modifiche devono essere apportate, è necessario comprendere appieno l'inventario corrente tra i repository di applicazioni esistenti e ciò che è stato pianificato per essere utilizzato nel cloud. Se hai molte applicazioni da migrare, un inventario esistente potrebbe non esistere o potresti fare affidamento sulle conoscenze comuni relative allo 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 dovranno cambiare quando si passa al cloud. Comprendere quali requisiti cambieranno nel cloud e come deve essere il progetto sono aspetti critici per documentare il lavoro necessario per la transizione.
   
   Sono richiesti tipi e quantità di lavoro diversi rispetto a 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 il 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 tra i team di prodotto dei componenti. Senza queste informazioni, non potevano organizzare e pianificare efficacemente il lavoro di migrazione. Al fine di ottenere una chiara comprensione di ciò che doveva essere migrato, le GBU hanno dovuto avviare una raccolta dati dedicata e concentrarsi sul consolidamento.

   ---

   "Il team Oracle GBU è riuscito a ridurre le spese capex dell'80% e i costi di infrastruttura del 64% migrando 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. Moltiplicato per ogni ambiente di prodotto nella flotta dell'organizzazione, la quantità e i vari tipi di lavoro coinvolti nella migrazione diventano facilmente schiaccianti. Le risorse disponibili per portarla a termine sono limitate e spesso responsabili anche della gestione delle operazioni quotidiane.

   ---

   OceanX sposta i propri sistemi di business intelligence su Oracle Cloud Infrastructure da Amazon Web Services (AWS) e vede un miglioramento delle performance di 3 volte superiore.

   "Avevamo bisogno che la nostra piattaforma dati fosse scalabile e fornisse performance elevate a un costo inferiore. La migrazione della piattaforma dati da AWS a Oracle è stata una delle migrazioni di maggior successo di OceanX e, insieme a un significativo aumento delle performance con notevoli risparmi sui costi, ha reso l'intero programma un risultato straordinario. Questo alla fine ci consente di fornire ai nostri clienti una piattaforma che consente loro di prendere decisioni più informate, più velocemente." — Vijay Manickam, Vice President of Data and Analytics, OceanX

   ---

   La transizione della GBU al cloud ha richiesto più di 3.000 progetti di migrazione singoli. Questi progetti erano originariamente 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 particolare ambiente. In definitiva, questo approccio non è riuscito a favorire vantaggi aziendali incrementali nel corso della migrazione. Senza priorità comuni o quadri di coordinamento, le GBU hanno visto un volume incoerente di attività di migrazione. Ciò ha gravato sui team responsabili del completamento del lavoro di migrazione con periodi alternati di elevata contesa delle risorse e disponibilità di risorse sprecate.
   
   Per risolvere queste sfide, 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 target di business 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 sfide relative alle risorse umane può essere più difficile 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. Gestire la questione di quando portare nuovi talenti rispetto a quando trovare meccanismi per far evolvere l'organizzazione ha richiesto alle GBU di condurre valutazioni della forza lavoro rispetto alle loro principali aree funzionali e gruppi di prodotti e quindi mappare l'iniziativa di miglioramento appropriata per ogni caso d'uso. Se la tua azienda ha più applicazioni da migrare, considera dove puoi creare una conoscenza cloud di base che abbraccia 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 a Oracle Cloud Infrastructure. Queste applicazioni supportano le funzioni aziendali principali in otto settori verticali e oltre 199.000 clienti in tutto il mondo. Una migrazione diligente, pianificata e ben eseguita ha portato a vantaggi sostanziali.

• 80 data center consolidati a 11
• CapEx ridotto dell'80%
• Costi di infrastruttura ridotti del 64%
• Fornitori di software ridotti da 28 a 10
• Spese software ridotte del 42%
• Passati 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 è stato solo una delle numerose grandi migrazioni a Oracle Cloud Infrastructure. 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 a Oracle Cloud Infrastructure. Queste migrazioni fanno parte della nostra iniziativa di trasformazione che chiamiamo Oracle@Oracle. È stato un progetto pluriennale che ha coinvolto numerose migliaia di applicazioni distribuite su decine di data center.

Ecco alcuni dei vantaggi che abbiamo riscontrato come risultato di questo impegno.

• Infrastruttura: raggiunto il 99,99% di disponibilità nel nostro portfolio di applicazioni con un risparmio sui costi del 30% e miglioramenti delle performance da 2 a 10 volte
• Finance: acquisita la capacità di chiudere i libri contabili e segnalare i profitti in meno di 10 giorni
• Human resources: tempo del ciclo di revisione dei talenti ridotto del 70%
• Supply chain: ciclo di pianificazione della supply chain ridotto da 1 settimana a 48 ore, un miglioramento del 71%
• CX: tempi di lead della campagna ridotti da 4 settimane a 5 giorni, un miglioramento dell'82%
• Sostenibilità: riutilizzato o riciclato il 99,4% delle apparecchiature dismesse raccolte presso Oracle nell'esercizio 2019

Partnership con Oracle

Stiamo aiutando gli ISV a espandere il loro mercato di riferimento, aumentando al contempo il loro potenziale di crescita dei ricavi. Inviaci una e-mail all'indirizzo: oraclecloud-isv_ww@oracle.com per saperne di più.

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 Considerazioni e modelli di hosting cloud

---

Krber consolida i sistemi di warehouse management su Oracle Cloud Infrastructure ed è più veloce del 40%.

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

Guarda il video

---