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.
Jérôme Blanc
Derniers articles parJérôme Blanc (voir tous)
- SAP HANA Native Storage Extension (NSE) | Q&A : Questions / Réponses - 6 février 2020
- Comment optimiser les investissements de votre Data Platform ? - 4 février 2020
- Ne dites plus « BI Manager » mais « Digital Data Manager » - 1 avril 2019