Comment SAP BW et HANA devraient fusionner à terme et pourquoi c’est important

Où en sont BW et HANA

SAP a entrepris de préparer ses principales plates-formes de gestion des données afin qu’elles puissent exploiter les capacités d'HANA. Par exemple, SAP a adapté BW au-dessus de HANA, pour faire du moteur in-memory la base de données persistente première de BW et permettre aux outils analytiques de BusinessObjects de se connecter nativement à la plate-forme HANA.

La première étape a été très basique. Globalement, BW considère HANA comme une simple base de données. BW sur HANA n'introduit que des modifications relativement mineures de schémas dans InfoCubes et les DSOs (Data Store Objects) pour optimiser ses performances sur HANA. La seule vraie optimisation pour HANA se trouve dans la procédure d’activation de données DSO, qui dans de nombreux scenarri s’exécute totalement dans la base et non pas dans le serveur d’application BW.

Avec cette configuration, on peut constater des gains significatifs de performances pour BW sur HANA. Mais c’est à peu près tout. BW n’exploite ni les possibilités d’intégration ni les fonctions de sécurité d’HANA et de son côté, la base in-memory n’exploite pas les nombreuses fonctions de BW. En outre, HANA propose peu de valeur, y compris au niveau de l’architecture, pour  la qualité de données et le support pour enrichir les données.

Quelle orientation dans les prochaines années

Alors que SAP poursuit son intégration de BW et de HANA, nous pouvons nous attendre à ce que BW exploite davantage de fonctions de HANA (et vice-versa), et que HANA se voit enrichie de fonctions pour supporter BW. D’ailleurs cette tendance prend peu à peu forme avec notamment BW 7.2 Support Package (SP) 8, qui supporte plusieurs scenarri où BW consomme des données de HANA (souvent de façon virtuelle et sans réplication de données). HANA met par exemple à disposition ses vues natives sur les données dans BW InfoProviders. Dans la mise à jour SP5, HANA propose une fonction pour marquer les données comme « inactives » (« not active ») qui garde ces données hors de la mémoire, sauf lorsqu'elles sont sollicitées. Economisant du coup une quantité significative de la mémoire. Dans le SP8, BW utilise automatiquement cette fonction.

Dans le futur, d’autres points d’intégration devraient être mis en place, le serveur d’application ABAP supportant progressivement HANA en natif. Hormis les routines ABAP, l’exécution des processus de transformation devrait être poussée vers HANA. Le moteur analytique de BW, complexe, prend en charge toute forme d’opérations, du reporting TDH (Time-dependent Hierarchy) à l’identification des valeurs non assignées des données maîtres. Ce moteur a déjà déporté certains de ses calculs vers HANA, mais nous pouvons nous attendre à ce que davantage de traitements analytiques soient poussés vers la plate-forme in-memory dans le futur.

Enfin, la couche ABAP de BW devrait prendre moins en charge l’exécution de la transformation des données, ainsi que les requêtes. Elle devrait être davantage dédiée à la maintenance des metadonnées et des informations sémantiques. Les plans d’exécution devraient être pris en charge par la couche HANA.

BW et HANA dans leur forme finale

 Au fur et à mesure que BW et HANA convergent, je pense qu’un des scenarii suivants a des chances d’aboutir :

• Le serveur d’application ABAP, ainsi que BW qui s’y adosse, restent séparés de la base de données HANA. Cette conclusion diffère de l’orientation prise par SAP : offrir des services applicatifs directement sur HANA, faisant de la plate-forme in-memory une combinaison entre une base de données et de serveur d’application. Néanmoins, il s’agit d’un scenario souhaitable, bien qu’avec certains inconvénients, les architectures trois-tiers base de données – application – client offrant des gains importants par rapport à une architecture deux-tiers.
• Les services 100% ABAP restants de BW (metadonnées, sémantiques, plans d’exécution) sont portés sur HANA, transformant ce BW de prochaine génération en une application totalement native pour HANA.
• L’architecture du serveur d’applications ABAP est portée pour fonctionner nativement sur le cluster HANA, et avec elle la couche ABAP restante de BW. Cela pourrait être possible soit au niveau de la couche OS ou en développant une version du serveur d’application ABAP fonctionnant au sein de la couche de services applicatifs d'HANA. Alors que le premier scenario implique de faire fonctionner le serveur d’application ABAP aux côtés de HANA au sein d’un même système, le second offre une approche plus native. Le niveau de difficulté pour chacun des deux scenarii serait immense. Je ne suis même pas certain que le scenario d’une intégration native est possible d’un point de vue technique.  Mais ce serait une avancée clé tant en termes d’améliorations des performances que de simplification de l’offre pour les clients SAP.

A ce stade, personne ne peut dire ce qui se passera. Dans chacune des hypothèses ci-dessus, le résultat ne prendra peut-être pas le nom de BW, mais je pense que SAP continuera de proposer les fonctions de BW – une nécessité pour les entreprises -  sous une de ces formes. Pour le moment, les utilisateurs doivent continuer à observer et attendre tout en développant quelques connaissances sur ces deux plates-formes. Dans tous les cas, le processus d’intégration de BW à HANA sera long, avec de nombreux rebondissements à venir.

Traduit par la rédaction