Introduction :

Si vous souhaitez en savoir plus sur les options de Licence HANA / Full Use / Run Time / Enterprise Edition, vous êtes sur la bonne page. Commençons par prendre un peu de recul.

Le travail d’architecture consiste à étudier les besoins et usages de nos clients afin de proposer un agencement d’outils qui est le plus pertinent en termes d’agilité, de fonctionnalité, de coût et d’évolutivité.

Ce travail est souvent compliqué par les limitations des licences et les termes d’usage des logiciels (SUR ou Software Usage Right). Il faut donc garantir la compliance des architectures proposées pour éviter les ennuis pendant les audits des éditeurs de logiciel.

Ce blog peut vous donner quelques pistes pour comprendre les enjeux et voir ce qui est faisable ou non en fonction de votre stratégie décisionnelle. Ce billet n’a pas de valeur légale et ne peut pas être utilisé contre SAP ou contre Bilink, nous vous recommandons de systématiquement valider vos schémas d’architecture par SAP ou votre intégrateur agréé avant de les implémenter pour ne pas vous mettre en infraction.

Dans le cas de SAP, et plus spécifiquement avec les technologies HANA, tout devient plus compliqué. Cela vient du double usages qui peut être fait de la technologie HANA :

  • Motoriser des applications tel que BW, BO, BFC, ECC, S/4 ou autres. Dans ce cas, la base de données HANA vient en replacement d’une autre base comme Oracle, SQL.
  • Développer des applications directement sur la base HANA en utilisant les moteurs de la base de données.

Conceptuellement, dans le premier cas c’est l’application qui interagit avec la base HANA, alors que dans le deuxième cas le développeur modélise directement dans la base de données. La technologie HANA permet les deux options et les exécute avec d’excellents résultats.

 

1. Quelles sont les options de licences HANA proposées par SAP ?

SAP propose deux catégories de licences : le Run Time (RT pour les intimes 😊) ou le Full Use :

 

1.1 La licence HANA Run Time

De manière générale le Run Time est utilisé dans les cas suivants :

  • Uniquement pour les applications SAP (S/4, BW/4, BW, BO etc.)
  • La modélisation, l’administration, la création de structures de données et l’utilisation de moteurs avancés doivent être effectuées uniquement via la couche application
  • Les données SAP et non SAP peuvent uniquement être chargées, exportées et gérées via la couche application et avec les technologies de provisionnement des données SAP.
  • Le chargement des données dans les structures de données générées par l’application SAP directement dans SAP HANA est autorisé avec DI, SDI et SLT uniquement.
  • Accès direct aux vues SAP HANA par des outils analytiques certifiés

Le Run Time permet de motoriser les applications supportées par la base HANA. Ce mode de Licence est lui-même décomposé en deux types :

  • RT8% aussi appelé REB, Run Time Edition for BW

Dans ce cas, la seule application pouvant être motorisée est BW et non BW/4

  • RT15% ou REAB, Run Time Edition for Applications and BW

Les applications pouvant être motorisées sont définies avec précision par SAP, mais elles incluent ECC, BFC, BPC, BW et la plupart des produits SAP.

L’illustration ci-dessous ; donne plus de détail sur les écarts entre le Run Time REAB et REB :

Ce schéma n’est pas contractuel, car il me semble que dans certaines conditions, le SLT à partir de données SAP est possible en Run Time (REB)

Par ailleurs certaines applications de data visualisation sont certifiées pour accéder directement à la base de données HANA même via le mode de Licence Run Time. Les applications sont recensées dans le lien ci-après :

https://www.sap.com/dmc/exp/2013_09_adpd/enEN/#/d/solutions?filters=326;405;352

 

1.2 La licence HANA Full use

De manière générale le Full Use est utilisé dans les cas suivants :

  • Pour toute combinaison d’applications SAP, non SAP, personnalisées, tierces et hybrides
  • Aucune limitation sur la modélisation des données, l’administration, la création de structures personnalisées et l’utilisation de moteurs avancés directement via SAP HANA studio ou d’autres applications
  • Aucune limitation sur le chargement et l’exportation des données SAP et non SAP directement dans et hors de SAP HANA
  • Aucune limitation sur la consommation de données directement depuis SAP HANA

 Le Full Use permet de développer directement sur la base HANA et se présente en deux offres :

  • Le Full Use Standard Edition
  • Le Full Use Enterprise Edition

L’image ci-dessous donne quelques exemples sur les principales différences entre l’Edition Enterprise et l’Edition Full use.

 

1.3 Les licences Full Use vs Run Time

Les différences entre le Run Time et le Full Use sont explicitées dans le tableau ci-dessous. La version du Full Use décrite ci-dessous est la version Enterprise Edition et non Standard Edition. Ce tableau est un bon résumé de la SUR (Software Use Rights) même si elle ne le remplace pas :

 

2. Les fonctionnalités de chaque model ? Cas d’emploi

Pour faire simple, vous pouvez quasiment tout faire en Full Use Enterprise Edition, il existe des restrictions fonctionnelles en Full Use Standard Edition et finalement les restrictions sont les plus fortes en Run Time 15% puis 8%.

Nous allons détailler par la suite les aspects coûts et ROI, car ces contraintes vont aussi avec un modèle de prix diffèrent et qui est, dans la plus par des cas, décroissant parallèlement à la réduction des fonctionnalités.

De manière générale, si vous souhaitez utiliser votre base de données HANA comme une plateforme d’intégration au sein du paysage applicatif, qui stock et propage vos données avec des systèmes Non-SAP ou avec des utilisateurs techniques, tout en utilisant les fonctionnalités natives de la base sans passer par la couche applicative, vous êtes dans un scénario Full Use.

Ci-dessous des cas d’usage Full Use :

  • Ecrire directement dans la base HANA sans passer par la couche applicative
  • Créer des tables dans la base HANA sans passer par SDI/SDA/SLT ou une application comme BW
  • Connecter vos outils de reporting non SAP sur la base HANA (Tableau, Qlik etc..)
  • Modéliser des applications en base et y accéder via des outils de visualisation type Fiori
  • Utiliser le SLT avec des sources des données Non-SAP

Il existe un aspect qui n’est pas très clair tant dans la documentation que dans les communications de SAP : c’est la possibilité technique de motoriser une application SAP BW via une Licence Full Use Standard Edition. Il me semble que cela soit possible au vu du document : « SAP List of Prices and Conditions SAP Software and Support 2019/4 ».

En revanche si votre objectif est d’accélérer une application existante telle que BW grâce aux performances In-Memory et le stockage en colonnes que propose HANA, le mode de Licence Run Time est l’approche la plus appropriée et souvent la plus économique.

Ci-dessous des cas d’usage Run Time :

  • Accélérer votre application BW
  • Bénéficier des nouvelles fonctionnalités liées à HANA dans BW
  • Accélérer votre développement en base grâce à des Calculated Views que vous consommez via BW
  • Utiliser la réplication temps réel SLT à partir de Source SAP via la base HANA de BW
  • Profiter d’une taille de base Illimitée sous HANA

Les listes de fonctionnalités n’engagent ni SAP, ni Bilink, et sont ma simple compréhension des avantages et contraintes des modes de licences.

 

2.1 Considérations avancées sur les licences HANA

Voici quelques points qui pourront élargir votre réflexion sur les problématiques de licences décisionnelles SAP :

  • Il est possible de mettre en place une installation Multi-Tenants HANA avec un Tenant Full Use et un Tenant Run Time pour optimiser l’usage des licences. Dans ce cas l’activation du cross tenant n’est possible que pour échanger des informations de base à base dans le sens Run Time => Full Use. Pour charger des données du Full -Use vers le Run Time, il est nécessaire de passer par l’application SAP BW.
  • Le point ci-dessous même s’il semble intéressant engendre une complexité à gérer sur le long terme et complexifie les schémas d’architecture. Dans un cas de budget important, passer l’intégralité des bases HANA en Full Use est l’option la plus simple d’un point de vu d’architecture.
  • Il est possible de ne payer le Run Time qu’en pourcentage de la valeur de l’application motorisée et non sur l’intégralité du paysage applicatif.
  • La mise en place d’une couche applicative BW4HANA sur une base HANA en Run Time active la possibilité d’export de données vers des applications tierces. Cela est particulièrement intéressant dans le cas où l’on souhaite stocker des quantités importantes de données sous HANA (Run Time n’est pas limité en taille) tout en ayant la possibilité de les exporter vers des applications tierces (Rendu possible avec BW4HANA).

 

2.2 Conversion d’un modèle de licence HANA à l’autre

La règle d’or est de ne jamais diminuer le flux de maintenance annuel dû à SAP, de 17% à 22% du CAPEX en fonction de vos conditions (A l’exception des conversions d’investissement vers le Cloud où la règle est de 1 pour 1.4 car il n’y a pas de maintenance en cloud).

Néanmoins lorsque ces règles sont respectées il est théoriquement possible de convertir vos investissements.

  • Run Time => Full Use

ou

  • Full Use => Run Time

Le dernier cas se révèle moins fréquent pour les raisons que nous allons détailler par la suite.

 

2.2.1 Passer du Run Time au Full Use

Comme évoqué précédemment, si cette évolution est portée par la nécessité d’exporter des données vers des applications tierces, la solution BW4HANA combinée au Run Time doit aussi être évaluée en parallèle du Full Use. En revanche s’il devient nécessaire de développer dans la base directement, de répliquer des données non SAP, d’utiliser les moteurs HANA de manière native, la conversion de l’intégralité de la base en Full Use ou la création d’un Side-Car est nécessaire.

 

2.2.2 Retour au Run Time

Les clients qui ont une base installée en Full Use ont souvent profité et configuré des fonctionnalités qui ne sont plus possibles en Run Time. En effet même si les règles de conservation de flux de maintenance sont validées, il faut aussi que la base soit utilisée en accord avec les conditions d’utilisations.

Cela étant dit, ce n’est pas parce que cette conversion est moins fréquente qu’elle en est moins intéressante lorsqu’un client décide de déployer une base de taille conséquente sous HANA afin de profiter des performances de la technologie.

 

3. Question du TCO

Dans la discussion de fin d’année avec SAP, les aspects de fonctionnalités sont importants mais les investissements qui permettent de réduire le TCO des applications existantes sur le long terme sont rois.

Les études de TOC se font en général sur une prévision de 3 à 5 ans. Cela permet de comparer différentes options : Full Use, Run Time 8%, Run Time 15%, Plus de Run Time, As-is etc…

En fonction :

  • Du CAPEX SAP
  • Du coût du Run Time, via Oracle ou SAP HANA en 8% ou 15%
  • Des capacités HANA Full Use supplémentaires à acquérir
  • Du flux de maintenance lié au Run Time (Oracle ou HANA) et à l’applicatif
  • Des achats à venir (users + applications)
  • Du coût de l’hébergement

Le coût cumulé sur plusieurs années permet d’identifier si une solution se dégage en termes de TCO et ROI. Un investissement qui s’argumente sans problème apporte des gains fonctionnels et démontre un ROI grâce à une baisse du TCO en moins de trois ans.

 

Conclusion

Pour conclure cette réflexion et ces pistes d’optimisation non exhaustives, vous avez pu apprécier, si ce n’était pas encore le cas, que ce sujet est particulièrement compliqué et engendre des impacts financiers et fonctionnels très importants. Bilink peut vous accompagner :

  • pour étudier quel serait le paysage applicatif idéal au vu de vos besoins,
  • définir le TCO de votre solution, et
  • vous aider dans l’argumentation pour convaincre votre management que ces changements sont nécessaires et fournissent un ROI satisfaisant.
The following two tabs change content below.
Jérôme Blanc

Jérôme Blanc

A la sortie de sa formation d’ingénieur de l’Ecole Centrale d’Électronique, Jérôme s’est spécialisé dans les technologies SAP décisionnelles. Avant de fonder Bilink, Jérôme a passé plusieurs années à Londres et à Chicago au sein d’une société experte sur les solutions SAP BI. Jérôme souhaite apporter au sein de notre cabinet les meilleures pratiques qu’il a pu apprécier au cours de ses expériences à l’étranger tout en veillant au respect de nos propres valeurs. Jérôme a aujourd’hui pour rôle de garantir le bon déroulement des projets de transformation BI de nos clients
Donec elit. libero mattis lectus consequat. massa diam vel, id, consectetur
Share This