BW/4HANA, une page se tourne
La nouvelle génération du Datawarehouse SAP nommée « BW/4HANA » est disponible depuis le troisième trimestre 2016. Afin de comprendre la stratégie de SAP revenons sur son historique en quelques mots.
En 2012 SAP introduit BW sur HANA, BW s’équipe de quelques nouveautés majeures telles que les « Hybrid Providers » le « semantic partitioning » ainsi qu’une intégration accrue avec les outils BO. Son intégration avec HANA améliore drastiquement les performances tant au niveau reporting que chargement.
En 2013 la nouvelle version 7.4 permet une simplification et une virtualisation du modèle de données avec l’apparition de l’Advanced DSO et la possibilité de modéliser des vues via l’outil de modélisation Eclipse. Les guides de bonnes pratiques sont mis à jour en conséquence. (Le « dynamic tiering » qui faisait initialement partie des grandes fonctionnalités mis en avant par SAP sera abandonné par la suite au profit des « extended node ».)
En 2015 SAP propose deux nouvelles versions :
- SAP BW 7.5 powered by HANA (Pour les clients ayant déjà un system BW antérieur opérationnel)
- SAP BW 7.5 édition for SAP HANA (Pour les clients ne disposant pas de SAP BW)
L’idée consiste à permettre aux développeurs d’initier de nouveaux projets en adéquation avec les nouveaux objets BW/4HANA tout en supportant les anciens objets tels que les cubes et les infosets …
On comprend bien la démarche « pas à pas » de SAP qui avait pour objectif de préparer l’arrivée de BW/4HANA.
Les dates de fin de maintenance pour SAP BW sont comprises entre fin 2017 pour la version 7.0 à fin 2020 pour la version 7.4.
Source: SAP
BW/4HANA : Le bouleversement
L’une des différences majeures entre BW sur une base relationnelle et BW/4HANA réside dans le passage d’un modèle de donnée physique à un modèle virtualisé et/ou hybride. BW Netweaver incite à extraire, transformer et stocker les données, tandis que BW/4HANA recommande de virtualiser les modèles de données afin d’exposer et traiter les données en temps réel.
Cela n’est devenu possible que récemment avec l’amélioration du hardware et les innovations apportées par les bases de données en mémoire telles que HANA.
Ce changement de paradigme permet, en plus d’apporter une fraîcheur des données en temps réel, de réduire drastiquement le volume des données répliquées ainsi que les temps de chargement pendant la nuit applicative, et donc les coûts de maintenance applicative et d’infrastructure.
Néanmoins, s’agissant d’un bouleversement des modélisations, cela demande beaucoup d’efforts pour migrer d’un concept à un autre et la question du choix entre migrer un système existant ou repartir d’une feuille blanche est tout à fait pertinente.
Les grands chemins de transition vers BW/4HANA
Trois grands scénarios de transition vers BW/4HANA sont avancés par SAP :
- Le premier est un nouveau départ avec une nouvelle installation, mais cela ne signifie pas forcément reconstruire tout votre modèle de données BI puisque les objets compatibles avec BW/4HANA peuvent être recopiés sur le nouveau système lors de l’initialisation.
- Le second consiste à migrer un système BW existant, comprenant selon votre point de départ plusieurs étapes d’upgrade et conversions. (Depuis BW 7.3 l’upgrade direct vers 7.5 est recommandé).
- Enfin le troisième scénario nommé « landscape transformation » est un scénario hybride permettant de prendre en compte les contextes multi systèmes les plus complexes.
Les étapes de migration d’un BW existant
La migration d’un système existant BW 7.x se fait en 3 étapes.
- Première étape, l’upgrade vers SAP BW 7.5 SP05 sur HANA :
SAP BW 7.5 en SP05 est la condition sine qua non à toute migration vers BW/4HANA. Même si vous préférez patienter avant de migrer vers BW/4HANA, il est fortement recommandé de passer à cette version pour tous les développement futurs afin de pouvoir d’ores et déjà appliquer les recommandations de virtualisation des modèles LSA++ et créer des objets optimisés pour HANA comme les « Advanced Datastore Objects » à la place des cubes et ODS. Il est recommandé de profiter de l’upgrade vers SAP BW 7.5 sur HANA pour réaliser un nettoyage des tables et objets obsolètes de votre système, afin d’éviter d’inutiles coûts de stockage dans la base comme lors d’une migration standard.
- Deuxième étape, mettre à niveau les objets non compatibles avec BW/4HANA :
L’avantage de la version 7.5 SP05 est qu’il est déjà possible de commencer la conversion des objets vers des versions compatibles avec BW/4HANA, un rapport standard liste d’ailleurs les objets qui nécessitent d’être convertis : « RS_B4HANA_CHECK_ENABLE ». Il y a cependant fort à parier qu’une grande part des objets listés soient inutilisés ou obsolètes, il est donc fortement recommandé d’y faire le tri et de supprimer les objets non nécessaires. Il est ensuite possible de choisir entre une conversion progressive ou complète des objets en fonction de vos priorités et contraintes.
- Troisième et dernière étape, migrer vers SAP BW/4HANA :
Une fois l’ensemble des objets convertis, le rapport « RS_B4HANA_ENABLE_CHECK » vous permettra de verrouiller la création d’objets non compatibles. Il sera alors possible de migrer vers SAP BW/4HANA pour rendre disponible les nouvelles fonctionnalités de la solution.
Votre projet de migration ne sera cependant pas encore à son terme car pour tirer pleinement profit des possibilités de BW/4HANA, il sera nécessaire d’optimiser certains flux de données, par exemple en remplaçant les transformations en ABAP par des calculs au niveau des vues HANA.
Nouvelle installation BW/4HANA
De par ses performances de restitution et l’accès aux données opérationnelles en temps réel, BW/4HANA offre de nouvelles possibilités en termes de résolution des problématiques BI.
Les besoins métiers adressés lors d’un projet BI quelques années auparavant pourraient fort bien trouver une solution plus efficace sur cette nouvelle plateforme.
Ces besoins pourraient même avoir changé depuis, il est alors intéressant d’envisager de repenser et améliorer les solutions BI de votre entreprise plutôt que de les transférer telles quelles sur ce nouveau système.
Selon votre point de départ, de la quantité de domaines fonctionnels ou du nombre d’objets à convertir, l’effort de migration évoqué précédemment pourrait également paraître trop coûteux.
Dans ces deux cas vous pouvez choisir de passer à BW/4HANA à partir d’une installation vierge.
L’avantage de cette solution est de pouvoir procéder par lotissement, domaine par domaine, en laissant cohabiter les deux solutions sans risque d’impact sur la BI existante. Il convient néanmoins de prendre en compte les aspects financiers. En suivant cette approche la maintenance et l’infrastructure de deux systèmes nécessitent une double maintenance et peut s’avérer coûteux en fonction de votre planning de migration.
Notre conseil
Il est très important de bien analyser votre situation de départ au moment d’envisager le saut vers BW/4HANA puisque deux choix s’offrent à vous, migrer l’existant ou refondre vos solutions dans un nouveau système.
D’une part le résultat d’une simple migration pourrait être décevant en termes d’amélioration de votre solution BI. Et d’autre part, le coût de migration de systèmes ayant vécu plusieurs années de développement pourrait être déterminant.
Il est néanmoins envisageable de réaliser un mix des deux solutions, en migrant certains domaines applicatifs et en repartant d’une feuille blanche pour d’autres.
Il n’y a pas de solution universelle, il faudra choisir la solution la plus adaptée à vos besoins et à votre situation.
Quelques liens (en anglais) pour trouver quelques compléments d’information :
https://blogs.saphana.com/2016/09/07/the-road-to-sap-bw4hana-part-1/
https://blogs.saphana.com/2016/09/18/the-road-to-sap-bw4hana-part-2/
https://blogs.sap.com/2016/09/14/bw4hana-what-when-why-whow/
Emilien Gaignette