Frayez-vous un chemin vers le Cloud

Tout processus de transformation Cloud qui implique la migration des applications sera complexe. Toutefois, malgré cette complexité, il existe quelques objectifs clairement définis sur le chemin vers le Cloud. L'un de ces objectifs concerne la manière dont l'application cible doit être "Cloud-Ready". Dans quelle mesure voulez-vous ou avez-vous besoin que l'application soit Cloud-Ready pour passer au Cloud dans les délais souhaités ? Dans ce document, nous décrirons certains de ces objectifs et mettrons en évidence les meilleures pratiques et les enseignements tirés de notre parcours. La clé du succès consiste à définir à l'avance et de manière précise vos objectifs de migration afin de pouvoir prendre des décisions optimales sur la façon de les atteindre. Vous vous trouverez face à de nombreuses voies potentielles. Au cours de votre migration, les développeurs, les équipes de prestation et les dirigeants devront analyser et décider de la marche à suivre.

Nous vous recommandons de privilégier les moteurs techniques et d'activité suivants lors de la prise des décisions nécessaire à la réalisation de vos objectifs commerciaux.

Évolutivité

Les services Cloud fournissent une puissance de calcul à grande échelle, bien au-delà de ce qui est possible avec une infrastructure gérée, ce qui permet à votre entreprise de se développer pour saisir les opportunités du marché. L'infrastructure en tant que service (IaaS) et la plateforme en tant que service (PaaS) basées sur le Cloud permettent aux ISV de se concentrer sur la création d'architectures évolutives au moyen de composants modernes. La migration présente un avantage supplémentaire : en déchargeant les équipes de développement internes de la gestion et de la mise à l'échelle des opérations informatiques, elles peuvent se concentrer sur l'ajustement et l'optimisation des performances.

Modernisation

La modernisation des ensembles d'outils, des services et des architectures facilite l'intégration entre les composants, ce qui permet aux applications de tirer pleinement parti des outils et des technologies disponibles dans le Cloud. Ces outils comprennent les mises à niveau de l'infrastructure, les pipelines de déploiement automatisés et les modèles d'apprentissage automatique intégrés qui améliorent les performances des applications. La modernisation est d'autant plus importante que les marchés connaissent des changements rapides et notables et que les applications doivent être dynamiques pour suivre le rythme. Dans certains cas, les services peuvent être complètement réécrits et rebaptisés, en tirant parti de la dernière pile technologique pour offrir des coûts inférieurs ou des options de service plus rationalisées. Ces changements peuvent remettre au goût du jour des produits vieillissants et peuvent perturber les marchés établis dans lesquels les offres sous licence sont la norme. Dans d'autres cas, les produits peuvent être remaniés avec de nouvelles approches, afin d'améliorer le service tout en préservant la notoriété de la marque et la fidélité des clients. Il n'est pas forcément nécessaire de modifier complètement la suite de produits.

Le passage au Cloud constitue le point de départ d'une vaste campagne de modernisation. Étant donné que le Cloud vous permet, à vous et à vos équipes, d'accéder à des services, des technologies et à une expertise qui n'étaient pas disponibles auparavant dans votre organisation, il devient possible d'atteindre de nouveaux objectifs et de fournir de nouvelles capacités. Vos équipes peuvent gravir “les couches de la pile” pour se concentrer sur les nouvelles fonctionnalités du produit applicables de manière globale plutôt que sur le code personnalisé lié à des déploiements spécifiques auprès de clients distincts. La fourniture de services, les mises à jour de produits et le support client étant tous plus rapides que jamais, les ressources peuvent se concentrer sur le développement de nouvelles fonctionnalités. De cette façon, la migration vers le Cloud ouvre la voie à une longue série d'activités de modernisation, qui transforme tout, de l'exécution des mises à niveau des produits à la qualité du Service Client.

---

"La migration vers le Cloud 2e génération a permis à Oracle de fournir avec succès ses services via un modèle DevSecOps robuste et nous a permis de soutenir les transformations d'entreprise de nos clients. Nous déployons désormais des logiciels quotidiennement et nous avons réduit le temps d'approvisionnement de plus de 98 %." — Karthic Murali, responsable principal de stratégie produit, Oracle Global Business Units

---

Standardisation

La standardisation entre IaaS et PaaS vous permet de réduire les frais généraux et de rendre les équipes plus flexibles et interchangeables. Au fur et à mesure que l'organisation se développe, vos équipes adopteront des outils de niveaux de maturité différents. La consolidation de ces ensembles d'outils au sein du service Cloud élimine en grande partie la complexité associée à cette couche de la gestion informatique. Elle permet le développement et l'utilisation de pratiques opérationnelles standard pour les tâches susceptibles de s'appliquer à l'ensemble du portefeuille. La standardisation rend également les activités ordinaires plus simples et plus prévisibles, ce qui réduit les besoins de main-d'œuvre pour les tâches de base. Les ressources qui étaient auparavant mobilisées pour gérer des processus variés et éventuellement incompatibles entre les différentes applications peuvent désormais se concentrer sur des problèmes plus importants, tels que le développement de produits et de services de nouvelle génération pour les clients.

La standardisation permet notamment de simplifier la mise en œuvre des politiques et des pratiques mondiales en matière de sécurité, de risque, de conformité ainsi que d'autres activités opérationnelles que vos équipes peuvent facilement appliquer aux produits existants et nouveaux. En fait, bon nombre des fonctionnalités intrinsèques de la plateforme IaaS, telles que les certifications de conformité accréditées, peuvent être héritées par l'application.

Optimisation des revenus

Il est possible d'optimiser les revenus de deux manières principales. La première, et la plus évidente, est la réduction des coûts. L'élimination des datacenters par l'utilisation de l'IaaS non seulement permet de passer d'un modèle financier de dépenses d'investissement (CapEx) à un de dépenses d'exploitation (OpEx), mais entraîne également généralement des économies significatives sur le coût total de possession. Ce qui est moins évident, ce sont les économies réalisées en rationalisant la pile technologique utilisée dans un portefeuille d'applications qui ont été migrées vers le Cloud. Les ensembles d'outils communs créent un savoir-faire institutionnel et éliminent les dépenses associées à la formation ad hoc pour des outils non standardisés. Dans le même ordre d'idées, les ensembles d'outils communs qui traitent l'infrastructure comme du code permettent une automatisation qui, à terme, fait gagner du temps et réduit les coûts de main-d'œuvre. Enfin, les équipes spécialisées dans les domaines fondamentaux qui s'appliquent à l'ensemble du portefeuille, tels que la sécurité, éliminent la nécessité de former des experts au sein de chaque équipe produit.

Deuxièmement, le passage au Cloud peut finalement optimiser les revenus en vous aidant à commercialiser plus rapidement. En effet, les délais de développement des produits sont généralement raccourcis dès lors qu'une application est Cloud-Ready ou Cloud native. Une commercialisation plus rapide se traduit par une accélération de l'obtention de revenus. Une fois qu'une application est Cloud-Ready, elle peut être déployée n'importe où dans le monde en quelques minutes.

La combinaison des principes exposés ci-dessus devrait permettre de standardiser les architectures de produits et de services et d'améliorer la rapidité et la qualité du déploiement. L'évolutivité résulte de la conception de schémas répétés, ce qui contribue à l'optimisation des revenus, à un retour sur investissement plus rapide et donc à la capacité de réorienter les ressources sur l'amélioration de la qualité et de l'intégrité du service pour les clients.

---

WorkForce Software fait migrer sa solution de gestion des effectifs vers Oracle Cloud Infrastructure et enregistre une augmentation de 30 % de ses performances.

"Nous avons obtenu des résultats financiers qui nous ont permis, dès le départ, d'économiser 30 à 35 % sur nos dépenses d'investissement (CapEx). En outre, grâce aux excellentes performances d'OCI, le ROI de notre suite ne cesse de croître." —Mike Morini, PDG, WorkForce Software

En savoir plus

---

Les voies vers la rentabilisation dans le Cloud

Le Cloud computing peut inclure un éventail de ressources IaaS et PaaS ainsi que de multiples modèles de déploiement de logiciels, incluant l'accès à des instances bare metal, des environnements conteneurisés intégrés et des piles de services entièrement fonctionnelles. Au niveau le plus élémentaire, le Cloud computing consiste à remplacer les composants de l'infrastructure physique par des ressources IaaS de base.

La plupart des applications d'entreprise n'ont pas été initialement conçues pour le Cloud. Pour de nombreuses applications, la conversion ou la conformité aux modèles du Cloud est une tâche longue et difficile. Changer la plateforme peut être coûteux tant en termes de temps que de main-d'œuvre. Il n'est donc pas surprenant de constater qu'il est parfois plus facile de concevoir des modèles Cloud natifs de A à Z. En prenant cela en considération, les entreprises se retrouvent généralement dans un des trois scénarios suivants lorsqu'elles envisagent une migration vers le Cloud.

• Quitter les datacenters existants : La gestion d'un datacenter coûte cher. Les bâtiments, les personnes, l'électricité, le refroidissement, la maintenance et les mises à niveau ne sont que quelques-unes des charges quotidiennes. De nombreuses entreprises s'efforcent activement de réduire ou d'éliminer leur dépendance aux datacenters en évaluant les portefeuilles d'applications afin de déterminer s'ils peuvent être déplacés hors des locaux. La priorité est de transférer les applications hors des datacenters colocalisés, en hébergement géré ou sur site afin de réduire ou d'éliminer les dépenses en capital. Souvent, on utilise une stratégie « lift and shift », qui consiste à migrer l'application telle quelle vers un serveur bare metal ou vers une machine virtuelle dans le Cloud.
• Faire évoluer la pile technologique : Dans ce cas, les entreprises commencent à apporter des changements progressifs aux applications qui nécessiteront des investissements supplémentaires, mais qui devraient également apporter davantage de valeur, au fil du temps. Un exemple de ceci serait le remplacement des versions sur site d'Oracle Database par l'Oracle Autonomous Database Cloud sans apporter de modifications majeures à l'application elle-même. Cette stratégie est parfois dite de déplacement et d'amélioration.
• Tout miser sur l'informatique Cloud natif : Les avantages de repenser l'architecture d'une application de A à Z afin qu'elle soit Cloud-Ready peuvent l'emporter sur les coûts liés au maintien d'une application moins mature lors de la mise en œuvre de l'un des scénarios mentionnés ci-dessus. Les applications Cloud natives sont hautement distribuée par nature, étant souvent construites selon les principes des 12 facteurs. Elles sont donc conçues pour être indépendantes de l'architecture sous-jacente, ce qui signifie que les applications continuent de s'exécuter même lorsque l'infrastructure sous-jacente tombe en panne. En bref, il convient d'évaluer si cette voie a du sens pour l'application cible, car le passage au Cloud sera certainement plus facile que le transfert d'une application étroitement liée à son infrastructure sous-jacente.

Pour découvrir comment Oracle conçoit le concept de « Cloud natif », les origines des applications Cloud natives et les meilleures pratiques à suivre lors de leur création, lisez cet eBook.

---

Une autre façon d'envisager ces scénarios consiste à considérer l'ensemble des actions que vous pouvez entreprendre pour convertir une application d'entreprise en une architecture Cloud native en la transférant vers Oracle Cloud Infrastructure. Voir la figure 1 ci-dessous.

Figure 1 : Niveaux de changements et d'investissements dans le cadre de la migration vers le Cloud

La partie gauche de la figure 1 représente le changement le moins important, le retour sur investissement le plus rapide et l'investissement initial le plus faible. Le niveau de changement, d'investissement et de temps augmente généralement à mesure que vous vous déplacez vers la droite, mais c'est aussi le cas de la valeur réalisée. Ce modèle vous aide à définir un moyen de prévoir les types d'investissements à envisager pendant la phase de transfert. Notez que les scénarios sont pas nécessairement distincts et qu'ils se chevauchent un peu car les applications sont construites de multiples façons.

Les scénarios décrits ci-dessus deviennent des points de référence clés pour évaluer les niveaux de maturité existants et les objectifs de transition vers le Cloud. L'écart entre votre état actuel et votre état cible fournit une estimation approximative de l'étendue des changements techniques et de processus requis pour la transition vers le Cloud. Dans un monde parfait, la transition vers le Cloud devrait aboutir à la transition de toutes les applications vers des modèles de prestation Cloud natifs. Cependant, compte tenu des contraintes de ressources et de temps, peu d'organisations sont en mesure de migrer l'ensemble de leur portefeuille vers un modèle Cloud natif en une seule fois. Même des efforts de restructuration simples peuvent nécessiter des ressources importantes et des investissements considérables rien que pour reproduire les fonctions existantes.

La transition vers le Cloud consiste donc à identifier les compromis entre le niveau de maturité optimal Cloud (où se situent les applications dans le continuum « hébergées par le Cloud » vers « Cloud natives » illustré ci-dessus) et l'investissement en ingénierie nécessaire pour réarchitecturer le produit et ses processus d'entreprise associés. À ce stade, l'étape clé consiste à identifier les niveaux de maturité actuels et cibles de chaque application, avec une estimation approximative de l'investissement de développement nécessaire pour combler l'écart.

Les applications qui changent de niveau de maturité au cours de la migration doivent également changer leurs modèles opérationnels et leurs attentes. Le changement des niveaux de maturité affecte les équipes, les processus et les politiques qui prennent en charge le service.

 

Évaluer l'état de préparation technique pour le Cloud

Une compréhension technique de l'application cible, ou du portefeuille complet d'applications pour les entreprises proposant plusieurs applications SaaS, est essentielle pour appréhender les exigences et les dépendances pour la migration. À ce stade, l'accent doit être mis sur l'identification des fonctions requises par l'application et sur leur lien avec ces dépendances. Cela permettra de déterminer le calendrier relatif des activités de migration ainsi que les principaux domaines d'intérêt. L'évaluation doit porter sur trois dimensions essentielles.

1. Les exigences en matière d'infrastructure : Le Cloud dissocie le logiciel de son matériel sous-jacent ou de ses environnements d'exploitation. Les applications à haut niveau de maturité sont essentiellement indépendantes de leur environnement et ne dépendent que d'une ressource d'infrastructure générale, telle qu'un processus (CPU) ou un cluster Kubernetes, qui évolue facilement dans le Cloud. Les applications à faible niveau de maturité dépendent d'équipements, de composants ou d'environnements spécifiques fournis, tels qu'une infrastructure gérée ou d'autres systèmes dédiés. La mesure dans laquelle votre application sera fortement dépendante des composants et des configurations de l'infrastructure dans le Cloud doit d'abord être déterminée et finalement éliminée. Il n'est pas rare de trouver des personnalisations (réalisées par vous ou vos clients) qui sont liées/associées à l'infrastructure sous-jacente.
2. Les composants des services : Le Cloud offre des fonctions de support sous forme de services autonomes exploités et fournis indépendamment de l'application. Les applications à haut niveau de maturité sont conçues autour de composants distincts, avec un minimum de dépendances sur l'ensemble de la pile, ce qui permet des modifications et des mises à niveau ciblées et ce qui maximise la disponibilité. Les applications à faible niveau de maturité sont conçues avec de grands composants étroitement couplés, qui deviennent fortement interdépendants et qui doivent être gérés comme une seule entité. Il faut documenter ces relations de services pour chaque application.
3. L'état de préparation opérationnelle : Le Cloud modifie les architectures techniques ainsi que les processus de travail, les compétences, les outils disponibles et les modèles d'exploitation. Les applications à haut niveau de maturité s'exécutent déjà comme des applications Cloud et utilisent des processus, des normes et des ensembles d'outils qui fonctionneront correctement dans le Cloud. Les applications à faible niveau de maturité ne disposeront pas de services de support essentiels dans le Cloud, seront prises en charge par des équipes dont les compétences ne sont pas adaptées au travail dans le Cloud ou utiliseront des processus qui seraient interrompus par un passage au Cloud.

Lancer une migration en évaluant la maturité d'une application par rapport à ces facteurs vous permet de planifier de manière appropriée et d'éviter les surprises en aval qui créent des retards, qui augmentent les coûts et qui aboutissent à des objectifs manqués. Il est difficile de minimiser la complexité d'une migration, dans la mesure où les environnements de production actuels, les suites de services de support et l'environnement Cloud ciblé continueront d'évoluer tout au long du processus. La mise en évidence des liens entre les services et les applications permet non seulement une planification intelligente en amont, mais aussi une réaction flexible de celle-ci aux changements qui se produiront inévitablement pendant la migration. Lorsqu'elle est correctement documentée, cette évaluation devrait déboucher sur une liste claire de tâches à effectuer pour le processus de migration. Cela permettra de garantir que les calendriers de migration prévisionnels continuent de s'aligner sur les feuilles de route en constante évolution.

---

Zoom s'adapte rapidement et active des millions de réunions simultanées sur Oracle Cloud Infrastructure.

"Notre entreprise a récemment connu la croissance la plus importante de son histoire, ce qui a nécessité une augmentation massive de notre capacité de service. Nous avons exploré plusieurs plateformes et Oracle Cloud Infrastructure nous a aidés à faire évoluer rapidement notre capacité et à répondre aux besoins de nos nouveaux utilisateurs." — Eric S. Yuan, PDG, Zoom

En savoir plus

---

Les objectifs financiers

Comme pour toute initiative informatique, la transition vers le Cloud nécessite une série d'investissements pour atteindre sa pleine valeur, surtout si l'application ciblée a été conçue pour un modèle d'hébergement sur site. Les applications jugées dignes de passer au Cloud finiront par devenir Cloud natives au fil du temps ou seront abandonnées. Cependant, l'objectif initial est généralement de faire passer une application à un état de version Cloud.

Le processus nécessaire pour faire passer votre application de son état actuel à son état de version Cloud est le produit d'une série de décisions et d'investissements initiaux. Prévoyez-vous simplement de transférer l'application vers un serveur bare metal (auquel cas la majeure partie de l'investissement est dans l'infrastructure Cloud), ou envisagez-vous de rendre l'application Cloud-Ready avant le transfert (auquel cas des investissements seront nécessaires pour déplacer des parties de la pile d'applications vers un modèle Cloud : par exemple, transférer la base de données sur site vers DBaaS ou Oracle Autonomous Database) ? Si vous avez créé des personnalisations codées en dur pour activer des fonctions spécifiques au client, elles devront être remaniées pour un modèle dans lequel les composants de la plateforme sont englobés et fournis via des API en tant que fonctions généralisées. Les dépendances matérielles ou de plateforme devront être supprimées afin de faire évoluer une application hautement distribuée dans le Cloud. Comprendre ces investissements est essentiel pour planifier et atteindre les objectifs financiers associés au passage au Cloud.

L'investissement initial comprend le temps de développement et la main-d'œuvre nécessaires pour apporter les modifications requises au produit qui sont liées à l'étape de migration vers le Cloud dont nous venons de parler. Cependant, il faut tout de même tenir compte de dépenses supplémentaires. Parmi les nombreuses dépenses que votre organisation est susceptible d'engager pendant la transition, citons les suivantes :

• Investissements de développement : travail de développement requis pour repenser l'architecture du produit ou pour créer des accélérateurs pour l'effort de migration, dont l'automatisation pour prendre en charge des activités telles que la migration de la base de données et le provisionnement des applications
• Exécution de la migration : main-d'œuvre nécessaire à la fourniture de nouvelles ressources, à la migration des environnements et des données existants ainsi qu'à la mise hors service des inventaires existants
• Adoption de l'infrastructure : frais d'abonnement accumulés via la montée en puissance de l'IaaS, qui se stabiliseront, mais qui entraîneront de nouvelles augmentations pendant la période de migration.
• Infrastructure abandonnée : frais d'amortissement des datacenters et des dépenses d'investissement (CapEx) persistants qui s'accumulent tout au long de la migration jusqu'à ce qu'ils puissent être éliminés ou radiés
• Transition de la main-d'œuvre : dépenses liées à la formation, à la sensibilisation ou à la restructuration des équipes existantes, ou à l'acquisition de nouvelles ressources possédant les compétences Cloud requises
• Transition des clients : coûts associés aux modifications apportées aux caractéristiques environnementales ou aux conditions de service qui ne peuvent pas être prises en charge dans le nouveau modèle, notamment les nouveaux développements, les récompenses, la renégociation des éléments du contrat ou l'attrition client

À un degré plus ou moins élevé, tous ces coûts sont nécessaires à la transition vers l'IaaS. Chacun d'eux a un impact différent sur votre profil des coûts. Les investissements dans le développement et les dépenses liées à l'exécution de la migration, par exemple, sont susceptibles de faire partie des frais uniques, même si les ressources nécessaires à ce processus peuvent être fixes. L'adoption de nouvelles infrastructures entraînera une augmentation nette des dépenses pendant un certain temps, jusqu'à ce que les dépenses d'infrastructure abandonnées soient éliminées. Certaines dépenses liées à la transition de la main-d'œuvre et des clients, comme les encouragements à la formation ou à la migration, représenteront des dépenses ponctuelles. D'autres, tels que l'expansion des effectifs ou les modifications des contrats clients, entraîneront potentiellement de nouvelles dépenses courantes.

Il est essentiel de comprendre comment ces dynamiques vont évoluer au fil du temps pour que votre organisation puisse se préparer et fixer des attentes pour la transition vers le Cloud. Si votre organisation est enthousiasmée par les avantages considérables du Cloud mais ne comprend pas clairement les risques liés à la transition, vous serez surpris par l'augmentation initiale des dépenses, en particulier lorsque vous absorberez dès le début les coûts de migration, de chevauchement d'infrastructures et de transition. Fixer les bonnes attentes et maintenir la visibilité des progrès graduels au fur et à mesure qu'ils se produisent sont des éléments essentiels pour maintenir l'alignement et la discipline tout au long de la transition de l'organisation.

Inventaire de migration vers le Cloud

Un inventaire de migration vers le Cloud est indispensable pour effectuer cette démarche. Qu'est-ce qu'un inventaire de migration vers le Cloud ? En bref, il s'agit d'une liste de toutes les ressources de la flotte et des éléments de données critiques associés décrivant chaque ressource. Il s'agit de l'application (ou des applications) à déplacer ainsi que de toutes les dépendances qui s'y rapportent. Le support utilisé pour collecter ces données n'a pas d'importance, et il n'est pas rare d'utiliser plusieurs outils car les données concernent souvent plusieurs départements d'une entreprise. Les informations requises sont généralement dispersées dans un ensemble de bases de données de production, de vente et opérationnelles. Par exemple, une base de données de gestion de configuration peut suivre en détail les dépendances techniques et l'emplacement des ressources, jusqu'aux serveurs physiques et aux emplacements de rack. Cependant, elle n'inclura pas les considérations commerciales et clients qui sont essentielles pour déterminer quand et comment les clients seront informés de la transition. Ces informations sont souvent contenues dans des référentiels conçus pour les acteurs des opérations et du support. En outre, les acquisitions, les cas d'utilisation particuliers et les silos de produits peuvent entraîner une fragmentation supplémentaire des informations dans plusieurs référentiels.

L'objectif principal de l'inventaire de migration est de fournir une vue centralisée des facteurs dont vous avez besoin pour gérer votre transition vers le Cloud. Par exemple : Quelle est la ressource ? Où est la ressource ? Quel produit prend-elle en charge ? Que fait-elle ? Quels clients prend-elle en charge ?

Dès le début, il est important de comprendre que le plan d'action est un document évolutif. Il doit être flexible, car il évoluera au fil du temps, en particulier pour les entreprises ayant plusieurs applications ou plusieurs versions d'applications. L'inventaire évoluera au fur et à mesure que de nouveaux problèmes apparaîtront et que de nouveaux besoins verront le jour. Même l'infrastructure Cloud sous-jacente peut changer au cours d'une migration, faisant ainsi évoluer l'inventaire une fois de plus. L'inventaire de migration doit recueillir autant de données disponibles que possible, pour que vous puissiez commencer la planification initiale, puis il doit ajouter des détails approfondis à mesure que la transition fait apparaître de nouvelles exigences.

La gestion de l'inventaire de migration est un projet transversal à part entière qui doit trouver un équilibre entre le besoin de données détaillées et le travail de collecte de ces données. Il comprend également des éléments qui déterminent les dépendances, les contraintes et les ressources, qui affecteront le calendrier et la vitesse, tels que les spécifications techniques détaillées, les approches architecturales, les exigences des clients et les voies de transfert de données. Avec trop peu d'informations, l'inventaire n'est pas utile. Avec trop d'informations, il devient un fardeau à maintenir et est susceptible de devenir rapidement obsolète et inutilisable.

Nous recommandons le cadre d'inventaire de migration suivant comme point de départ pour la migration vers le Cloud.

De l'inventaire de migration à l'inventaire opérationnel

Alors que nous nous sommes concentrés sur l'inventaire de la migration, la transition vers le Cloud pose en définitive deux défis. Plus directement, elle crée le besoin de planifier, de prioriser et d'effectuer le suivi des activités de migration. Cependant, la migration elle-même obligera à modifier les données nécessaires au suivi opérationnel quotidien. Par exemple, les détails de configuration post-migration concernant les serveurs physiques et les racks deviendront inutiles, et même les informations sur les instances individuelles perdront de leur importance. Dans le même temps, des indicateurs clés tels que l'utilisation globale et la sortie des données peuvent devenir cruciaux, en particulier lorsque les organisations adoptent des modèles en libre accès.

La création d'un inventaire de migration devrait permettre de commencer la transition vers ces nouveaux schémas et processus de données centrés sur le Cloud. Si les deux défis que constituent la création de l'inventaire et la migration de l'application sont des projets distincts, ils ne doivent pas être menés isolément. La migration est l'effort principal, et c'est peut-être la première fois qu'une organisation crée une vue détaillée et consolidée de ses ressources. Il s'agit d'un tournant qui devrait servir de modèle pour les nouvelles vues d'inventaire post-migration. Comme indiqué ci-dessus, l'inventaire de migration devra être flexible et adaptable. S'il est géré correctement, l'inventaire de migration deviendra un outil précieux de gestion des stocks post-migration.

Mener à bien votre transition vers le Cloud

Concevoir l'infrastructure d'hébergement d'applications SaaS

En tant qu'ISV fournissant des applications SaaS, vous avez besoin d'une infrastructure professionnelle sécurisée et évolutive pour héberger vos services et gérer vos clients de manière isolée. L'architecture de référence décrite dans la figure 3 ci-dessous fournit un cadre validé qui intègre les meilleures pratiques, ce qui vous permet d'héberger vos applications SaaS sur Oracle Cloud Infrastructure.

Dans cette architecture de référence, vous déployez et gérez plusieurs instances d'application isolées. Chaque déploiement est destiné à un locataire spécifique et ces instances d'application de locataire individuelles sont gérées via une couche de gestion commune.

Vous pouvez choisir de créer toutes les instances d'application de locataire à partir d'une seule base de code ou d'offrir des versions personnalisées de l'application à chaque locataire. Ce modèle est idéal pour les clients SaaS qui exigent un isolement complet de l'environnement applicatif.

Figure 3 : une architecture de référence des meilleures pratiques pour les applications SaaS sur OCI

Pour de plus amples informations sur l'architecture de référence ci-dessus, rendez-vous sur la page de l'Oracle Architecture Center. De plus, nous avons créé des outils basés sur Terraform pour faciliter le déploiement de l'architecture pour quatre locataires, ainsi qu'un guide pas à pas. Enfin, nous recommandons toujours de suivre le Guide des meilleures pratiques d'Oracle Cloud Infrastructure, qui fournit des conseils sur quatre objectifs commerciaux communs : la sécurité et la conformité, la fiabilité et la résilience, l'optimisation des performances et des coûts, et l'efficacité opérationnelle.

Outre les modifications de l'architecture, vous devez réfléchir à la manière dont votre pile de services évoluera dans le Cloud. Les ensembles d'outils de base servant à la surveillance, la gestion réseau ou la sécurité déployés dans des environnements existants et développés pour les architectures sur site évolueront pour le Cloud. Le passage au Cloud offre la possibilité d'élargir le champ d'application de ces outils. Plutôt que de surveiller principalement les points de terminaison, les outils basés sur le Cloud offrent une surveillance tout au long de la pile. Parfois, un prestataire de service Cloud propose des outils de surveillance basés sur le Cloud ou hybrides en plus des fonctions de base. Dans le cas d'Oracle Cloud Infrastructure, une combinaison de fonctions natives de surveillance, de balisage et d'audit permet de surveiller l'ensemble de la pile de services et souvent de corriger automatiquement les anomalies constatées en dehors des normes spécifiées. Si vous utilisez aujourd'hui des outils de surveillance de tiers sur site, ces fournisseurs peuvent également proposer des outils hybrides ou basés sur le Cloud.

---

Cisco Tetration transfère son application de base vers Oracle Cloud Infrastructure et multiplie par 60 ses performances.

"Le partenariat avec Oracle est fantastique. C'est la raison pour laquelle toute cette magie avec Cisco Tetration se produit." — Navindra Yadav, fondateur, Cisco Tetration

---

Mettre en place votre programme pilote

Comme pour tout effort d'ingénierie, débuter par un petit programme pilote ou un prototype maximise les chances de succès en donnant à l'équipe du projet et à votre organisation une idée de ce qui peut être fait et de la manière de procéder. Les programmes pilotes et de validation de concept déterminent et résolvent les problèmes sans les contraintes de temps et d'argent qui accompagnent les changements à grande échelle dans toute l'organisation. En progressant lentement et en se familiarisant avec le nouvel environnement d'exploitation, les programmes pilotes peuvent vous aider à gérer le taux de changement.

Le pilote est l'occasion pour un noyau de développeurs et de membres de l'équipe d'exploitation de se familiariser avec l'environnement Cloud cible, en apprenant les architectures, les services et les modèles opérationnels. Cette équipe pose les fondations de connaissances pratiques, d'outils utiles et de meilleures pratiques ainsi que la confiance, l'expertise et l'expérience. En même temps que votre équipe développe ces connaissances, elle fait évoluer les règles de la collaboration inter-équipes dans un environnement Cloud. La migration vers le Cloud oblige les équipes applicatives à passer du statut de gestionnaires directs de ressources à celui de consommateurs de services fournis par d'autres équipes. Un pilote permet aux équipes applicatives de comprendre comment les frontières des services vont changer, de nouer des relations avec les équipes d'exploitation fournissant les services qu'elles utiliseront et d'apprendre à faire valoir leurs besoins auprès de ces équipes d'exploitation.

Les pilotes offrent les avantages suivants :

• Un contexte dans lequel valider (ou remettre en question) les hypothèses sur la portabilité des technologies, en particulier si celles-ci ont toujours fonctionné dans le même environnement. Cela aide les équipes à comprendre si elles sont prêtes à migrer et à déterminer ce qui doit changer pour y parvenir.
• Une occasion de confirmer que l'application/la base de données est prête à s'intégrer aux services de l'environnement cible. Les équipes savent ainsi quels changements sont nécessaires et quand l'application et l'environnement des services cible sont prêts pour la migration.
• La capacité de construire pour l'environnement cible, en créant un point d'ancrage, qui devient un point de départ pour le reste du portefeuille à mesure qu'il évolue vers de nouveaux services et un nouvel environnement. Les équipes disposent ainsi d'objectifs stratégiques pour leur portefeuille.

---

Manhattan Associates fait migrer ses solutions de Supply Chain vers Oracle Cloud Infrastructure et réalise une économie de 50 % par rapport à la solution Cloud précédente.

"La polyvalence et la flexibilité d'Oracle Cloud, tant au niveau des applications que de la base de données, nous ont permis de réaliser des économies d'environ 50 % par rapport à nos précédentes solutions Cloud en termes d'infrastructure." — Jeff Demenkow, vice-président, Manhattan Associates

---

Gérer un programme pilote

Le pilote est une expérience d'apprentissage pour les personnel technique et d'exploitation ainsi que pour vos équipes de direction et de gestion. Les équipes de direction et de gestion doivent être en communication permanente avec les équipes pilotes afin de lever les obstacles organisationnels et de s'assurer que l'organisation maximise les enseignements tirés du projet pilote (c'est-à-dire ce qui a fonctionné, ce qui a échoué, les meilleures pratiques, les leçons apprises et les patrons standard ou anti-patrons identifiés). Il est possible de collecter ces informations précieuses, puis de les partager avec le reste de l'organisation, ce qui, dans l'idéal, rendra les projets Cloud ultérieurs plus efficaces et plus efficients. Un pilote permet à la direction de tester les hypothèses qui ont servi à l'élaboration de leurs plans et d'éliminer les zones d'incertitude. Bien que ces hypothèses varient d'une organisation à l'autre, les pilotes mettent en évidence quelques défis clés dans toute migration.

• Formation : Les pilotes testent les compétences existantes, révélant à quel point l'organisation est préparée pour le travail de migration technique. La direction doit utiliser le pilote pour évaluer les compétences techniques, pour déterminer les outils et les fonctions qu'il est le plus important d'apprendre et enfin pour planifier la manière de former rapidement le personnel ou d'embaucher des personnes ayant des compétences dans ces domaines clés.
• Travail collaboratif : Les projets pilotes montrent comment les équipes de développement, d'exploitation et de support collaboreront différemment. La direction doit s'assurer que ces équipes travaillent réellement ensemble pendant le pilote, en exposant les nouvelles exigences et en faisant comprendre comment procéder dans ce nouvel environnement.
• Aspiration au changement : Les pilotes sont l'occasion de découvrir les barrières culturelles qui affecteront la migration au sens large. Un groupe qui rencontre des difficultés lors du projet pilote aura la même réaction à grande échelle. Le pilote est l'occasion pour la direction de cerner les problèmes, de mettre en place une formation et d'ajuster les plans en fonction des caractéristiques de son organisation.

La clé d'une migration en douceur réside dans la création d'une base solide. La première phase de la migration conduira au développement d'un ensemble de services et de plateformes de base, qui sera progressivement élargi au fur et à mesure de la migration. À terme, ces fonctions de base devront évoluer pour prendre en charge l'ensemble du portefeuille de migration. Il est donc essentiel que les premières versions du Cloud non seulement réussissent, mais qu'elles servent de fondation pour toutes les versions et mises à niveau suivantes.

S'adapter au changement organisationnel

Concevoir l'infrastructure d'hébergement d'applications SaaS

L'évolution du modèle de distribution de votre organisation et des relations avec la clientèle peuvent exiger de nouvelles compétences, connaissances et mentalités ainsi que de nouveaux processus d'entreprise. Ces changements peuvent avoir un impact considérable sur l'ensemble de l'organisation. Pour cette raison, le changement culturel est souvent considéré comme l'aspect le plus difficile de la transition vers le Cloud.

L'ampleur même de ces changements peut donner l'impression qu'une transition vers le Cloud nécessite une réorganisation à grande échelle et le remplacement du personnel par des personnes dotée d'une expérience et d'une expertise Cloud. Si les changements dans la spécialisation fonctionnelle interne et le recrutement axé sur les compétences Cloud sont des composantes majeures de la transition vers le Cloud, vous ne pouvez pas vous passer des processus, de la dynamique et des contributeurs établis qui ont été la clé de votre succès jusqu'à présent. Il est essentiel que vous parveniez à trouver un équilibre entre la rapidité du changement organisationnel et les perturbations potentielles des activités en cours et des expériences client. Le maintien de cet équilibre implique un réalignement des changements structurels aux capacités de perfectionnement professionnel, permettant aux employés actuels d'effectuer la transition vers le nouveau modèle opérationnel.

La transition d'une entreprise de logiciels de longue date vers des modèles de prestation Cloud nécessite un changement radical des hypothèses, du savoir-faire technique et des processus d'exploitation standard dans de nombreux domaines d'activité clés. Bien que l'ampleur des changements requis puisse être décourageante, nos expériences suggèrent qu'il est généralement préférable de conserver et d'investir dans les équipes existantes plutôt que de tenter une restructuration complète des équipes d'experts du Cloud. Les organisations qui planifient des transitions similaires devraient s'inspirer de la manière dont notre organisation GBU a commencé par une évaluation décentralisée et ascendante des besoins en matière de changement. Cela a permis à chaque équipe de créer ses propres inventaires de migration et ses propres feuilles de route de la pile de services afin de déterminer les étapes nécessaires dans leurs zones de contrôle respectives. Grâce à cette approche, les équipes ont pu aligner leurs programmes sur des facteurs de changement tangibles tout en évitant les hypothèses générales sur les besoins éventuels.

---

8x8 maintient le monde connecté, réduit ses coûts de 80 % et améliore ses services en passant à Oracle Cloud Infrastructure.

"Étant donné que les visioconférences sont rapidement devenues le moyen de communication par excellence du nouveau monde d'aujourd'hui, notre nombre d'utilisateurs a explosé. Pour soutenir cette croissance exponentielle, nous avons étudié plusieurs plateformes et nous avons choisi l'infrastructure Oracle Cloud 2e génération pour sa sécurité renforcée, son rapport qualité-prix exceptionnel et son support de classe mondiale pour faire face à cette nouvelle vague d'utilisateurs." — Vik Verma, PDG, 8x8

Regarder la vidéo

---

Répercussions sur l'entreprise :

Une transition réussie vers le Cloud est à la fois un moyen et une conséquence des changements opérés dans l'ensemble de l'organisation. Passer d'un portefeuille essentiellement hébergé ou sur site à une entreprise basée sur le Cloud nécessitera des changements fondamentaux quant à la manière dont votre organisation entre en contact avec ses clients. Toutefois, le degré de changement des pratiques commerciales et des hypothèses établies sera largement déterminé par l'ampleur des modifications de produits entrepris dans le cadre de la transition vers le Cloud.

Même dans les scénarios à faible changement, le passage à l'IaaS entraînera des transformations dans les processus d'entreprise. Nos GBU ont déterminé deux possibilités clés de changement dans ce contexte.

1. Remplacer la gestion d'infrastructure physique nécessitant de fortes dépenses d'investissement (CapEx) par des modèles de prévision orientés OpEx qui tiennent compte des fluctuations à court terme et des attentes à long terme
2. Faire évoluer les équipes chargées de la sécurité et de la conformité qui ont été libérées des responsabilités traditionnelles pour qu'elles se concentrent sur la fourniture de composantes de services

Les organisations qui abordent ces changements, ainsi que les changements techniques dans leurs applications, seront mieux placées pour tirer pleinement parti de la migration vers le Cloud.

L'alignement avec les clients

Le passage d'un produit "prêt à l'emploi", ou même d'un produit hébergé à un véritable service Cloud, est un périple que vous et vos clients entreprendrez ensemble. En fait, c'est cette transition vers un modèle « en tant que service » qui distingue le Cloud de toutes les modalités d'hébergement précédentes. Chaque modification apportée à un service Cloud aura un impact sur l'expérience client, qu'il s'agisse de l'évolutivité, de la disponibilité ou de la résilience. Dans certains cas, le client peut demander, voire exiger, le passage à un nouveau modèle de distribution. Dans d'autres cas, les attentes en matière de fonctionnalités, de fonctions et de coûts peuvent évoluer d'une manière qui ne peut être prise en charge que par une solution basée sur le Cloud.

Lorsque vous commencez à impliquer vos clients dans vos stratégies Cloud, il est important de vous préparer à ces deux points de vue : l'enthousiasme pour la feuille de route et la réticence à quitter ce qui est familier. Pour répondre à ces points de vue, il faut une stratégie de communication claire et mesurée qui indique l'orientation de la démarche sans se perdre dans les détails techniques ni inquiéter. C'est un moment clé pour impliquer les équipes en contact avec le client au sein de votre organisation afin de s'assurer qu'il comprenne l'effort en cours, l'investissement consenti par l'entreprise et les résultats attendus pour le produit et la prestation. Ce faisant, vos équipes en contact avec les clients doivent être mises à contribution pour traduire ce changement en termes qui renforceront la confiance des clients dans le service.

Pour les clients qui utiliseront le service Cloud, le cas de figure peut devenir un peu plus compliqué. Il existe des segments de clientèle qui souhaitent un service Cloud. Ces derniers comprennent les avantages que le SaaS leur procure en termes d'efficacité et d'agilité. Cependant, comme les options Cloud ou SaaS sont devenues de véritables enjeux, les clients doivent être informés sur les fonctions et les accords de prestation qui distinguent le service d'un fournisseur plutôt que sur la valeur du Cloud lui-même.

Tous les clients ne sont pas enthousiastes à l'idée d'un service Cloud. En particulier, les clients existants sur les modèles de services hébergés ou gérés peuvent être satisfaits de l'état actuel, notamment s'ils disposent de composants de service sur mesure ou d'environnements et de modèles d'accès non standard qui sont incompatibles avec les modèles de distribution Cloud. Même les clients qui reconnaissent les avantages d'une transition vers un service Cloud peuvent être réticents face aux modifications des modalités de livraison ou aux interruptions de service nécessaires pour migrer leurs environnements.

Rassurer les clients nécessite une coordination et une communication cohérente entre les équipes de marketing, de vente, de support et de succès client. Dans un monde idéal, le client ne serait pas du tout conscient que ses charges de travail ont été migrées ; il remarquerait un jour une amélioration des performances sans se douter des changements qui ont eu lieu. Dans les faits, la migration des services vers le Cloud nécessite souvent des mises à niveau, des temps d'arrêt, et potentiellement, des modifications des conditions de service ou des fonctionnalités disponibles. Accompagner un client à travers ces péripéties tout en maintenant l'alignement sur le calendrier global de transition est un exploit complexe, qui exige plus qu'une compréhension des avantages du changement. Il faut que le client adhère aux changements en cours et s'aligne sur les étapes de migration susceptibles d'avoir un impact sur son activité.

---

CMIC fait migrer son logiciel d'entreprise de construction vers Oracle Cloud Infrastructure et constate des déploiements 10 fois plus rapides.

"Outre les avantages financiers que procure OCI par rapport aux autres fournisseurs Cloud, nous sommes désormais plus agiles. OCI nous a donné un nouveau niveau de flexibilité technologique. Nous allons de l'avant avec des technologies comme Oracle Container Services et Oracle Autonomous Database afin de continuer à nous concentrer sur la fourniture du meilleur logiciel ERP de construction disponible." — Vince Di Piazza, responsable de l'infrastructure informatique et Cloud, CMIC

Regarder la vidéo

---

Une fois qu'un client a bien compris les avantages et les changements qui accompagneront la transition vers le Cloud, la dernière étape à laquelle votre organisation doit faire face consiste à déplacer les charges de travail du client vers le nouvel environnement. Le défi est alors de déterminer le moment optimal pour la migration et pour les tests de validation du nouvel environnement. Un client qui accepte de faire face à une période d'arrêt aura souvent un avis bien tranché sur le moment où cette indisponibilité doit se produire.

Bien que la préférence du client soit importante pour vous, vous devez tenir compte de nombreux autres facteurs. La planification des migrations implique un compromis entre une multitude de facteurs, notamment les attributs techniques d'un produit ou d'un service, la prise en compte des préférences de tous les clients, les limitations des ressources internes et les objectifs commerciaux tels que la consolidation/l'élimination des centres de données existants ou l'abandon des gammes de produits obsolètes. Pour concilier ces priorités contradictoires, il convient d'inclure les équipes en contact avec la clientèle dans les activités de planification de la migration, car elles seront leurs interlocuteurs privilégiés pour représenter les attentes du marché.

Tout comme votre entreprise doit se préparer à la fois à une période d'investissement et de migration et aux changements permanents de processus techniques et commerciaux d'un modèle de distribution Cloud, elle doit également se préparer à la manière dont elle implique les clients dans la migration et à un nouveau statu quo dans le produit et la relation client.

Nos GBU ont d'abord répondu à ces besoins en examinant comment la transition affecterait les clients sur le plan technique, opérationnel et en termes d'engagements de livraison. Elles ont isolé ceux qui nécessiteraient une attention particulière, un engagement et des changements potentiels dans la relation commerciale. Les efforts déployés pour préparer les équipes en contact avec les clients s'appuient sur une perspective similaire, impliquant une collaboration entre le équipes produit, d'exploitation, de la stratégie et autres afin de fournir des connaissances générales sur le Cloud tout en répondant aux changements spécifiques des produits et des clients.

Cet effort allait au-delà de la simple préparation des équipes en contact avec les clients afin qu'elles les impliquent. Le fait de réunir les principaux dirigeants interfonctionnels pour qu'ils s'alignent sur l'engagement client a également créé de précieuses occasions d'étendre des programmes, qui étaient essentiellement techniques, à des initiatives plus larges visant à réexaminer la valeur fondamentale de nos solutions, à réarticuler ce qui différencie nos produits et à planifier les meilleurs moyens de préserver et d'accroître cette valeur sur le marché.

Se préparer en amont

Concevoir l'infrastructure d'hébergement d'applications SaaS

Tout au long de ce guide, nous avons fourni des conseils sur les meilleures pratiques en nous appuyant sur les leçons que nous avons tirées de la migration de plus de 60 applications GBU hébergées sur des milliers d'instances. Nous résumons ci-dessous les cinq plus grands défis auxquels nous avons été confrontés tout au long de notre parcours, car nous pensons qu'ils sont applicables à toute organisation migrant des applications vers le Cloud.

1. Déterminer les efforts de développement avant la migration
   La préparation d'une application établie en vue de son lancement dans le Cloud peut impliquer un investissement important, notamment pour rendre un produit Cloud natif. L'investissement dans les principes d'application Cloud natives permet de tirer le meilleur parti du Cloud, malgré la nécessité de consacrer beaucoup de temps et de ressources de développement pour atteindre l'état final. Plus il faut de temps pour préparer un produit pour le Cloud, plus vous tarderez à profiter des avantages inhérents et progressifs du passage au Cloud et plus vous prolongerez potentiellement l'exposition aux risques généralement associés aux environnements existants. Dans le même temps, tous les produits ne bénéficieront pas des mêmes avantages, en fonction de la phase de leur cycle de vie et de la posture du client. Pour que la migration soit réussie, il est essentiel de bien comprendre et de documenter la quantité de travail de développement à entreprendre avant la migration.
   
   Le portefeuille d'applications de la GBU est diversifié, comprenant des produits à tous les niveaux de maturité et de phases de cycle de vie du Cloud. Alors que toutes les applications devaient être migrées vers le Cloud, il était difficile de déterminer dans quelle mesure les produits devaient être modifiés avant la migration vers le Cloud. Pour trouver le bon équilibre, l'organisation a dû évaluer le stade du cycle de vie de chaque produit, son potentiel de croissance et l'effort nécessaire pour le transférer dans le Cloud. Sur la base de ces évaluations combinées, les unités GBU ont déterminé le niveau de priorité et de dépenses qui seraient accordés à chaque produit.
2. Déterminer la composition du développement
   Les GBU ont eu du mal à trouver un équilibre entre la bande passante d'ingénierie à consacrer à la préparation des investissements dans le Cloud et le développement de nouvelles fonctionnalités et fonctions pour répondre à la demande du marché.
   
   Les GBU n'ont pas manqué de s'aligner sur la priorité de la transition vers le Cloud, mais les équipes produit ont eu du mal à déterminer la quantité de travail à accorder aux fonctionnalités du Cloud qui amélioreraient l'expérience et les performances des clients, mais qui ne remplaceraient pas les fonctionnalités demandées par ces derniers. Le développement Cloud nécessite d'investir dans des capacités opérationnelles sous-jacentes qui peuvent altérer la capacité de l'organisation à répondre à la demande de nouvelles fonctionnalités de la part des clients. Ces compromis rendent difficile la répartition du temps entre la préparation au Cloud et les initiatives d'amélioration des produits.
   
   Pour relever ce défi, les GBU se sont appuyées sur les cadres de maturité du Cloud abordés au chapitre 1 pour fournir un aperçu de l'investissement de développement relatif requis pour chaque voie. Elles ont ensuite examiné le retour sur investissement de chaque étape potentielle de la transition vers le Cloud et ont évalué ce résultat par rapport à la valeur ajoutée potentielle attendue du développement de nouvelles fonctionnalités. Cette démarche a permis d'établir un cadre d'évaluation commun qui a pu être utilisé pour déterminer la combinaison appropriée d'efforts, tout en maintenant la visibilité sur les résultats commerciaux cibles.

   ---

   Altair choisit le calcul haute performance sur Oracle Cloud Infrastructure et améliore le rapport qualité-prix de 20 %.

   "Lorsque nous avons étudié tous les fournisseurs de services Cloud, nous avons constaté qu'Oracle était très axé sur le calcul haute performance. Leur offre bare metal, qui était, je crois, la première du secteur, disposait d'un réseau à haut débit et à faible latence, ce qui est très important pour nous." — Piush Patel, vice-président senior des relations stratégiques, Altair

   ---

3. Comprendre la flotte
   Que votre entreprise dispose d'une seule application ou d'un vaste portefeuille, il convient de suivre et d'inventorier de nombreux facteurs lors d'une migration vers le Cloud. Afin de bien comprendre les changements à apporter, vous devez parfaitement comprendre l'inventaire actuel des référentiels d'applications existants ainsi que ce qu'il est prévu d'utiliser dans le Cloud. Si vous devez transférer un grand nombre d'applications, il se peut qu'il n'existe pas d'inventaire, ou que vous deviez vous fier à des connaissances tribales concernant l'état d'applications spécifiques. Même les entreprises qui n'ont qu'une seule application orientée vers le client doivent inventorier l'ensemble de la pile d'applications pour déterminer les aspects qui devront être modifiés lors d'une migration vers le Cloud. Comprendre quelles exigences vont changer dans le Cloud et à quoi doit ressembler la conception sont des aspects essentiels pour documenter le travail nécessaire à la transition.
   
   Chaque instance d'application nécessite des travaux de nature et de quantité différentes, en fonction de ses caractéristiques (version, dépendances matérielles/de plateforme, personnalisations, modèle d'accès du client, etc.). En outre, les données de l'application peuvent être réparties sur plusieurs systèmes d'enregistrement.
   
   Les GBU Oracle sont la consolidation de plus de 30 acquisitions avec une flotte qui s'étend sur 80 datacenters et sur plus de 12 000 instances d'application. Les données critiques relatives à ces instances étaient très fragmentées et n'étaient pas nécessairement gérées de manière cohérente entre les différentes équipes produit. Sans ces informations, elles ne pouvaient pas organiser et planifier efficacement le travail de migration. Afin d'avoir une vision claire de ce qui devait être migré, les GBU ont dû entreprendre un travail spécifique de collecte et de consolidation des données.

   ---

   "L'équipe GBU d'Oracle a pu réduire les dépenses d'investissement de 80 % et les coûts d'infrastructure de 64 % en migrant vers OCI." — Mike Prindle, vice-président, GBU Architecture Cloud
   

   ---

4. Prioriser et organiser l'effort de migration
   En fait, le transfert des charges de travail peut prendre plusieurs formes, allant de la copie d'images de machines virtuelles existantes à l'installation d'une nouvelle instance et à la réplication des données. Toutefois, toutes ces opérations nécessitent un certain niveau d'investissement technique ou de travail pour être achevées. Si l'on multiplie ces chiffres pour chaque environnement de produit de la flotte de l'organisation, la quantité et les différents types de ressources impliqués dans la migration deviennent facilement insurmontables. Les ressources disponibles pour la mener à bien sont limitées et souvent également chargées de la gestion des opérations quotidiennes.

   ---

   OceanX transfert ses systèmes de Business Intelligence vers Oracle Cloud Infrastructure depuis Amazon Web Services (AWS) et constate que ses performances sont multipliées par trois.

   "Nous avions besoin que notre plateforme de données puisse évoluer et offrir des performances élevées à moindre coût. La migration de la plateforme de données d'AWS vers Oracle a été l'une des migrations les plus réussies chez OceanX. Associée à un gain de performances significatif et à des économies substantielles, l'ensemble du programme a été une réussite extraordinaire. En fin de compte, cela nous permet d'offrir à nos clients une plateforme qui les aide à prendre des décisions plus éclairées, plus rapidement." — Vijay Manickam, vice-président des données et des analytiques, OceanX

   ---

   La transition vers le Cloud de la GBU a nécessité plus de 3 000 projets de migration individuels. À l'origine, ces projets étaient classés par ordre de priorité en fonction des préférences des clients (c'est-à-dire en donnant la priorité aux calendriers de migration en fonction des commentaires consolidés des clients) ou de l'état de préparation à la migration d'un environnement particulier. En fin de compte, cette approche n'a pas permis de générer des avantages commerciaux supplémentaires au cours de la migration. En l'absence de cadres communs de priorisation ou de coordination, les GBU ont vu un volume incohérent d'activités de migration. Les équipes chargées de mener à bien les travaux de migration ont ainsi dû faire face à une alternance de périodes de conflit de ressources élevé et de périodes de gaspillage des ressources disponibles.
   
   Afin de relever ces défis, les GBU ont créé à la fois un bureau central de gestion de programme dédié à la migration et un comité exécutif de surveillance, chargés de hiérarchiser les migrations en fonction des résultats commerciaux cibles et d'identifier les opportunités de transition.
5. Gérer le changement organisationnel
   Les changements impliqués dans la transition vers le Cloud nécessitent de nouveaux types de connaissances, de compétences et de processus, ainsi que d'autres formes de changement culturel. La gestion de ces défis en matière de ressources humaines peut s'avérer plus difficile que celle des composantes techniques de la transition vers le Cloud. Pour y remédier, les GBU Oracle ont aidé les équipes existantes à évoluer vers des équipes Cloud en mettant l'accent sur la formation. Pour savoir quand recruter de nouveaux talents et quand trouver des mécanismes permettant de faire évoluer l'organisation, les GBU ont dû procéder à une évaluation des effectifs par rapport à leurs principaux domaines fonctionnels et groupes de produits, puis définir l'initiative d'amélioration appropriée pour chaque cas d'utilisation. Si votre entreprise doit transférer plusieurs applications, pensez à l'endroit où vous pouvez acquérir des connaissances fondamentales sur le Cloud qui s'étendent à tous les produits, comme la sécurité et l'IaaS en général.

Célébrer les résultats

Ce guide est basé sur les apprentissages que nos équipes Oracle GBU ont accumulés lors de la migration de plus de 60 applications SaaS vers Oracle Cloud Infrastructure. Ces applications prennent en charge les fonctions essentielles des entreprises dans huit marchés verticaux et auprès de plus de 199 000 clients dans le monde. Une migration minutieuse, planifiée et bien exécutée a permis d'obtenir des avantages substantiels.

• Consolidation de 80 datacenters en 11
• Réduction de 80 % des dépenses d'investissement (CapEx)
• Réduction de 64 % des coûts d'infrastructure
• Réduction du nombre de fournisseurs de logiciels réduit 28 à 10
• Réduction des dépenses logicielles de 42 %
• Passage aux versions logicielles quotidiennes
• Réduction du temps d'approvisionnement de plus de 98 %
• Réduction des temps d'arrêt planifiés de plus de 98 %

Bien que ce guide ISV soit basé sur les enseignements tirés par nos équipes GBU, leur initiative n'était qu'une des nombreuses grandes migrations vers Oracle Cloud Infrastructure. Compte tenu des revenus et du nombre de clients sur l'ensemble de nos applications SaaS, Oracle peut être considéré comme l'un des plus grands ISV au monde, et nous comprenons le processus de migration. Nous avons en fait transféré l'ensemble de notre portefeuille de produits, y compris Oracle Fusion Cloud ERP, Oracle Fusion Cloud EPM, Oracle Fusion Cloud HCM, Oracle Advertising and CX et Oracle Fusion Cloud SCM vers Oracle Cloud Infrastructure. Ces migrations font partie de notre initiative de transformation que nous appelons Oracle@Oracle. Il s'agissait d'un projet pluriannuel impliquant des dizaines de milliers d'applications réparties sur des dizaines de datacenters.

Voici quelques-uns des avantages que nous avons constatés à la suite de ces démarches.

• Infrastructure – Nous avons atteint une disponibilité de 99,99 % pour l'ensemble de notre portefeuille d'applications, avec une réduction des coûts de 30 % et des performances multipliées par deux voire par dix
• Finance – Nous avons acquis la capacité de clôturer les comptes et de déclarer les gains en moins de 10 jours
• Ressources humaines – Réduction de 70 % de la durée du cycle d'évaluation des talents
• Supply chain– Cycle de planification de la Supply Chain réduit de 1 semaine à 48 heures—une amélioration de 71 %
• CX – Réduction du délai d'exécution de la campagne de 4 semaines à 5 jours—une amélioration de 82 %
• Développement durable – Réutilisation ou recyclage de 99,4 % des équipements déclassés collectés chez Oracle au cours de l'exercice 2019

Partenariat avec Oracle

Nous aidons les ISV à étendre leur marché potentiel tout en augmentant leur capacité à accroître leurs revenus. Envoyez-nous un e-mail à : oraclecloud-isv_ww@oracle.com pour en savoir plus.

Pour en savoir plus sur les raisons pour lesquelles les ISV choisissent Oracle Cloud, veuillez consulter les ressources suivantes :

• isv.oracle.com
• Oracle@Oracle program pour les ISV
• Explorez le microsite considérations et modèles d'hébergement cloud

---

Körber consolide ses systèmes de gestion d'entrepôt sur Oracle Cloud Infrastructure et ceux-ci s'exécutent 40 % plus rapidement.

"Lorsque nous avons évalué les différents points de décision, OCI était très pertinent par rapport à ce que nous essayions de faire en termes de stratégie de mise sur le marché." — Rick Schrader, vice-président senior des ventes et des alliances en Amérique du Nord, Körber

Regarder la vidéo

---