Read this article in English uk-flag

Sur place ou Côte-à-côte
Quelle est la meilleure stratégie à adopter pour un upgrade SAP BusinessObjects ?

upgrade-sap-business-objects

La réalité des upgrades SAP BusinessObjects

Avec l’arrivée récente de SAP BusinessObjects BI 4.3 en Juin dernier, de nombreuses organisations préparent leurs projets d’upgrade ou de migration, selon les cas de figure.

Malgré toutes les promesses qu’apporte cette nouvelle mouture, nous observerons comme à chaque nouvelle version SAP BusinessObjects, une forme de méfiance vis à vis des bugs qu’elle peut apporter. Ainsi, la réalité c’est que de nombreuses organisations attendront le premier service pack, voire sa première mise à jour prévue, en générale, un mois plus tard (BI 4.3 SP01, patch1).

SAP fait référence à un upgrade quand il s’agit d’une mise à jour entre deux versions mineures, comme par exemple de 4.x à 4.x, plutôt que d’une migration qui est plutôt pour des versions majeures telles que de 3.x à 4.x. Il y a deux façons de procéder à un upgrade de 4.x à 4.x : sur-place (on peut également parler de “patching”) ou côte-à-côte (étapes similaires à une migration). 

Lorsque je parle de patching, je fais référence à l’upgrade d’un service pack vers un autre (par exemple BI 4.2 SP06 vers BI 4.2 SP08) comme vous le feriez pour bénéficier de nouvelles fonctionnalités telles que Snowflake qui est désormais supporté.

Une petite précision que je voudrais apporter ici c’est que ceux qui sont encore sur SAP BusinessObjects XI 3.1 devront d’abord migrer en BI 4.2 pour ensuite upgrader vers BI 4.3.

Dans un webinar récent, nous vous posions la question sur la meilleure stratégie à adopter selon vous, avant même d’exposer les avantages et les inconvénients de chacune. Voici les résultats :

Quelle est selon-vous la meilleure stratégie pour un upgrade vers SAP BI 4.3?

Stratégie 1 : Patcher sur place (même serveur)
0%
Stratégie 2 : Migration vers un nouveau serveur (côte-à-côte)
0%
Ne sait pas
0%

Upgrade SAP BusinessObjects sur-place (ou “patching”)

À mon avis, SAP recommande cette approche pour encourager ses clients à se mettre à niveau fréquemment plutôt que de mener un projet de migration, car sur papier, cela demande moins d’efforts. Un upgrade de type patching implique les étapes suivantes :

  1. Téléchargez tous les logiciels à patcher (serveur, outils clients, addons, etc.).
  2. Installez le tout sur votre (vos) serveur(s) et poste(s) de travail existants. 
  3. Testez et réparez les problèmes éventuels. 

Je vais commencer par mon seul argument pour de cette méthode – vous pouvez utiliser le même matériel et les mêmes dépendances ! Vous n’aurez pas besoin de l’intervention de l’IT, si ce n’est pour faire une sauvegarde et d’être prêt à intervenir en cas de problème, via un retour en arrière.

MAIS… Oui, j’aurai toujours un “mais” vis à vis cette méthode. Le téléchargement et l’installation du tout sur un serveur existant signifie que votre celui-ci est hors service pendant une très LONGUE période, ce qui signifie que vos services SAP BusinessObjects ne seront pas disponibles pour les utilisateurs. Cela peut durer de plusieurs heures comme plusieurs jours, ce qui n’est pas acceptable pour la majorité des entreprises.

Vous ne pourrez pas non plus effectuer de tests complets et il sera même difficile de faire des tests autres que des tests fonctionnels, car vous ne disposerez plus de l’ancien environnement pour effectuer une comparaison avant / après. Certaines choses peuvent même être impossibles à tester. C’est un problème majeur, car évidemment, plus longue sera l’installation, plus longue sera l’attente des utilisateurs qui n’auront plus accès à leurs données. Avec ce temps d’arrêt, il y aura fort probablement des reconfigurations à effectuer, par exemple la mise à niveau de Tomcat (qui vous obligera à configurer votre SSL et peut-être à nouveau le SSO), ainsi que des travaux de réparation sur les univers et/ou les documents qui doivent être corrigés. Certains anciens services et add-ons tels que Lumira peuvent également devoir être mis à jour et d’autres peuvent ne pas exister dans les versions futures, par exemple, Explorer n’existera pas dans SAP BI 4.3. Là encore, plus les tests et les réparations sont longs, plus votre plateforme sera hors service. Une fois la mise à jour terminée et que vous êtes “en production”, il sera difficile de revenir en arrière, car elle sera déjà opérationnelle pour les utilisateurs. Si vous procédez à une restauration, vous perdrez le contenu qui aura été créé et modifié depuis la sauvegarde. 

Pour illustrer mon propos, j’aime utiliser l’analogie de iPhone pour décrire cette méthodologie :

Mettre à jour mon iPhone (même téléphone):

  • Brancher mon iPhone pour avoir assez de batterie
  • Accès à mon Wifi
  • Faire un Backup (si assez de place sur iCloud!)
  • Installer l’Update (iPhone indisponible pendant ce temps)
  • Redémarrage (croise les doigts!)
  • Reconfigurer certaines choses (E.g.: Vodafone)
  • Tests (certaines applications ne supporteront pas ce dernier iOS)
  • Retour en Arrière: Difficile / Impossible
    • Si nouveau backup iCloud a été fait, il ne pourra pas être restauré

Risque: Moyen

upgrade-ios

Upgrade SAP BusinessObjects côte-à-côte (vers un nouveau serveur)

L’autre option pour un upgrade entre versions mineures c’est de faire un upgrade côte-à-côte. Ça se présente comme suit :

  1. Obtenez un ou plusieurs nouveaux serveurs et les dépendances telles que les bases de données System et Audit.
  2. Téléchargez, installez et configurez le logiciel.
  3. Migrez le contenu de A à B.
  4. Effectuez des tests aussi longtemps que vous le souhaitez et réparez si nécessaire.
  5. Migrez le contenu qui a changé depuis la première promotion (delta) 
  6. Passez en production.

Les autres serveurs existants sont toujours actifs et fonctionnent pendant que le ou les nouveaux serveurs sont déployés, installés, testés et que le contenu est réparé si nécessaire. Les utilisateurs ne se rendront même pas compte qu’un upgrade est en cours.

À mes yeux, cette méthode présente de nombreux avantages. Tout d’abord, vous pouvez prendre autant de temps que vous le souhaitez pour effectuer la mise à niveau. Étant donné que l’ancien environnement est toujours disponible pour les utilisateurs, vous n’aurez pas besoin de bâcler l’upgrade aux dépens de la qualité. Deuxièmement, comme cet environnement fonctionne parallèlement à l’ancien, vous pouvez également tester aussi longtemps que vous le souhaitez, ce qui réduit le risque de problèmes et de maintenance post-upgrade.

Un upgrade côte-à-côte de SAP BusinessObjects est également une bonne occasion de mettre à niveau les systèmes d’exploitation et autres dépendances tierces (par exemple, les pilotes de base de données, le serveur d’application web comme Tomcat). Vous pourriez même profiter de cette occasion pour passer de l’hébergement on-premise à l’hébergement dans le cloud – tout compte fait, ce type de projet est l’occasion parfaite pour tout revoir. 

L’inconvénient c’est qu’il faudra l’aide de votre équipe informatique pour vous fournir un ou plusieurs nouveaux serveurs et les dépendances nécessaires, et vous devrez peut-être aussi procéder à d’autres changements d’architecture, par exemple, un pare-feu et un SSO (single sign-on). 

Si je reviens à mon analogie avec l’iPhone, un upgrade côte-à-côte fonctionne de la même manière que le remplacement de votre iPhone par une version plus récente :

Mettre à jour mon iPhone (et en profiter pour remplacer mon vieux iPhone 7) :

  • Acheter mon nouveau iPhone 11
  • Démarrer le nouveau téléphone
  • Configuration initiale (préférences, wifi, etc)
  • Restaurer le backup iCloud
  • Tester les applications et nouvelles fonctionnalités
  • Retirer et Insérer ma carte SIM et derniers tests
  • Retour en arrière: Facile. Réutiliser mon vieux iPhone avec la même carte SIM.

Risque: Faible

iphones
the-ultimate-sap-businessobjects-upgrade-checklist
Obtenez votre check-list ultime pour vos upgrade SAP BusinessObjects

Sur place vs Côte-à-côte: conclusion

À mon avis, un upgrade “sur place” de type patching est rarement la meilleure méthode. Sur la base de mes 15 années d’expérience sur le sujet, je conseillerais presque toujours un upgrade “côte à côte” étant donné la réduction des risques et le temps que vous aurez pour réaliser vos tests et assurer la qualité de votre projet. Peu nombreuses sont les entreprises qui aiment prendre des risques, dans la majorité des cas, elles choisiront cette dernière option. 

Toutefois, au bout du compte, tout dépend de l’importance du déploiement de SAP BusinessObjects pour l’entreprise. Si vous pouvez facilement vous passer de votre (vos) serveur(s) de production pendant une période potentiellement longue et que vous avez effectué des tests complets dans un environnement presque identique, vous pourriez opter pour un upgrade sur place.

Maintenant que vous connaissez les avantages et les inconvénient de chaque stratégie, quelle est selon-vous la stratégie la plus adaptée à un upgrade vers BI 4.3 ? Nous avons reposé cette question aux participants de notre webinar, à la fin de celui-ci, beaucoup d’entre-eux ont changé se tournent désormais vers la stratégie d’upgrade côte-à-côte :

Avez-vous changé d’avis ? Quelle est selon-vous la meilleure stratégie pour un upgrade vers SAP BI 4.3 ?

Stratégie 1 : Patcher sur place (même serveur)
0%
Stratégie 2 : Migration vers un nouveau serveur (côte-à-côte)
0%
Ne sait pas
0%

N’oubliez pas que si vous êtes sur la version SAP BusinessObjects XI 3.1, vous devrez d’abord migrer vers BI 4.2, puis vers BI 4.3. Alors pourquoi attendre, migrez dès aujourd’hui !

Vous avez besoin d’aide et de conseils pour votre prochain upgrade SAP BusinessObjects ?

optimisez-migration-business-objects-ebook

Publications similaires

Laissez un commentaire