Bernd Leukert, SAP : « pourquoi nous privilégions le In-Memory »

Nouvelle caution technique au sein du comité exécutif de SAP remodelé par le Pdg Bill McDermott, Bernd Leukert, en charge des produits et de l’innovation, y remplace Vishal Sikka, le directeur technique qui a quitté la société voici tout juste un mois (la presse indienne parle de lui comme futur Pdg d’Infosys). Dans cet entretien avec une poignée de journalistes de la presse internationale (dont Silicon.fr), Bernd Leukert revient sur le lancement de Simple Finance, une évolution des applications financières de l’ERP Business Suite conçue pour la base de données In-Memory maison, Hana.

Proposée avant tout en mode Saas, dans le Cloud de SAP, cette application devrait également être disponible pour des déploiements sur site. Tout en embarquant des applications analytiques – y compris d’analyse prédictive -, Simple Finance promet une simplification drastique du code. Selon InformationWeek, Simple Finance sera proposée aux clients de la Business Suite sous ECC 6.0 dans le cadre de leur maintenance.

SAP vient d’annoncer Simple Finance, une évolution de ses applicatifs conçue pour la base de données In-Memory Hana. Est-ce à dire que le futur des applications SAP s’écrit forcément sur votre base de données ?

Bernd Leukert : Nous allons effectivement bâtir notre nouvelle génération d’applications sur notre plate-forme, mais celle-ci est compatible avec le standard du marché, SQL. Qui plus est, les autres fournisseurs de bases de données nous ont emboîté le pas et proposent désormais des fonctionnalités In-Memory. Nous allons nous éloigner d’un modèle basé sur le seul support des bases de données relationnelles pour aller vers une plate-forme In-Memory, tout en gardant la capacité à embarquer des SGBR traditionnels. Ceci afin de ne pas brider notre innovation.

Si on prend l’exemple d’une montée de version vers Simple Finance, qui donne la tendance de ce à quoi ressemblera notre suite, lors de la mise à jour, on sait si on a affaire à un environnement In-Memory ou relationnel. Dans les deux cas, les utilisateurs auront accès aux mêmes principales fonctions. Dès que les innovations que nous proposerons seront accessibles, avec des temps de réponse acceptables, aux utilisateurs fonctionnant sur des bases de données traditionnelles, nous les leur offrirons. Dans certains cas, les temps de réponse peuvent devenir inacceptables pour les utilisateurs travaillant avec des SGBR classiques – comme la fonction de recherche que nous proposons dans notre Business Suite sur Hana dès aujourd’hui -, même si, techniquement, ces fonctions restent accessibles car elles font appel au standard SQL. Ce type d’innovations sera alors réservé au In-Memory. Mais bien d’autres améliorations resteront accessibles aux utilisateurs de SGBDR.

Après le lancement de Simple Finance, quelles sont les prochaines étapes ?

La suite complète devrait être réécrite d’ici la toute fin d’année. Nous avons aussi un plan permettant aux utilisateurs de consolider ces produits de nouvelle dimension sur une instance unique. Cela sera le cas pour la supply chain, le SRM, le PLM, BW et le CRM.

En parallèle, nous redéfinissons le marché de l’analytique. Nos concurrents créent des extractions des données transactionnelles, les amènent dans un environnement différent et les ordonnent dans des cubes afin de proposer des fonctions d’analyse rapides. Mais ce concept génère des temps de latence ainsi que d’importants coûts opérationnels. Chez nos clients, de 30 à 40 % de la charge des ERP provient de l’extraction de données. Dans notre modèle, ces efforts ne sont plus nécessaires. Si vos outils analytiques interrogent directement les données transactionnelles, avec des agrégats créés à la volée, vous supprimez la latence, gagnez un accès aux données temps réel, améliorez la sécurité et éliminez les problèmes de qualité de données.

Le nouveau paysage que nous dessinons revient à utiliser Hana comme plate-forme, des applications analytiques directement intégrées à cette plate-forme – si les utilisateurs le souhaitent – et, au-dessus, les lignes métiers et les améliorations que nous proposons pour certains secteurs d’activité.

Par ailleurs, nous nous éloignons d’un modèle où nous appelions nos produits – SCM, SRM, PLM… – pour nous rapprocher d’un concept basé sur les services réels que nous proposons dans le Cloud. Et nous pouvons gérer notre riche ensemble de fonctionnalités de façon granulaire, dans notre Cloud, et exposer seulement les services appropriés à chaque client. Ce qui signifie que non seulement nous pouvons fonctionner sur une instance unique (client par client, NDLR) mais aussi que nous éliminons les réplications à l’intérieur du modèle de données.

Vous parliez de proposer aux utilisateurs le choix de leur base de données In-Memory. Mais les schémas de développement ne sont pas identiques entre Hana et les options proposées par Oracle, IBM ou Microsoft…

Oui, c’est vrai. Nos concurrents n’ont pour l’instant pas suivi notre concept consistant à réunir les traitements transactionnels et analytiques dans un seul outil. Ils ont préféré utiliser des réplications à l’intérieur même de la base de données. Ce qui, tôt ou tard, ne fonctionnera plus. Pourquoi ? Dans les entreprises où nous installons l’ERP sur Hana, nous atteignons un facteur de compression de 5. Si on part d’un volume de 10 To par exemple, on arrive après compression à environ 2 To. Les approches de nos concurrents consistent à créer un réplicat In-Memory. On aboutit donc dans ce cas à un total de 12 To avec un facteur de compression de 5 pour le réplicat. Pourquoi pouvons-nous proposer maintenant de consolider tous les produits de nouvelle dimension dans une seule instance ? Tout simplement grâce à cette réduction massive de l’empreinte utilisée par les jeux de données, ce qui diminue la consommation de mémoire de chaque application prise individuellement. Ce qui n’est pas possible avec l’approche proposée par nos concurrents, une approche finalement hybride qui se contente d’exploiter la vitesse qu’amène le In-Memory. Mais cette accélération doit être mise au service de l’innovation.

Une étude de McKinsey montre que les nouvelles applications, construites à côté du socle applicatif, qu’il s’agisse de commerce ou d’Internet des objets, échouent faute d’un socle consistant. Pour réussir le déploiement de ces nouvelles applications, les entreprises ont besoin d’un modèle de données solide, en interne mais aussi auprès de leurs partenaires, pour implémenter la nouvelle génération d’applications. Imaginons par exemple un concepteur d’articles textiles. S’il gère ses différents canaux (magasins, distributeurs, Web…) dans des silos de données séparés, un magasin sera incapable de livrer au client tel article, dans tel couleur même si celui-ci n’est pas dans ses rayons et même s’il est disponible dans un entrepôt utilisé par le canal Web non loin de là. A l’inverse, si les canaux sont consolidés et l’information est partagée, de nouveaux scénarios deviennent possibles : achat sur le Web pour une livraison dans tel magasin, utilisation des magasins comme de petits entrepôts déportés… Cette stratégie échouera si chaque canal conserve son propre modèle de données.

In fine, vos nouvelles applications Simple – Simple Finance aujourd’hui, Simple Suite demain – fonctionneront-elles avec d’autres bases de données que Hana ?

Oui, techniquement cela sera possible car nous utilisons le standard SQL. Mais je ne peux pas garantir que la vitesse sera identique à celle qu’offrira Hana.

Quel est le scénario de migration pour une entreprise sous ECC 6.0 – dernière version de la Business Suite – et que deviennent les développements spécifiques ?

Pour une entreprise sous ECC 6.0, le chemin est balisé. Nous l’avons emprunté à de nombreuses reprises déjà. Plus de 1 000 entreprises font aujourd’hui tourner leur ERP sur Hana. Il faut simplement mettre en œuvre un package d’amélioration (Enhancement Pack en terminologie SAP, NDLR) au cours duquel nous remplaçons la base de données. Une fois que l’entreprise a effectué cette transition vers Hana, passer à Simple Finance ne prend que quelques heures. En interne chez SAP, nous avons migré notre ERP sous Hana en août dernier, et quand Simple Finance était prêt, en mars dernier, nous nous sommes donnés pour objectif de passer à cette mouture avant Sapphire (qui se tenait du 3 au 5 juin, à Orlando, Floride, NDLR). En 8 semaines, le projet a été mené à bien. C’est une transition douce qui revient à éliminer les structures de données inutiles, mais conserve tous les documents et la structure que le système utilise déjà.

Concernant le code spécifique, il continue à fonctionner. Je ne connais pas un seul client qui, lors de sa migration vers Hana, ait connu des problèmes avec ses spécifiques. Au contraire, on peut espérer que ce code maison tournera plus vite, même si cela dépend de la façon dont a été codée l’application. Par ailleurs, quand une entreprise se lance dans cette migration, elle en profite souvent pour éliminer des spécifiques devenus inutiles ; nous proposons d’ailleurs un service dédié. Dans le cas de SAP, lors de la migration de l’ERP vers Hana, nous avons ainsi isolés quelques 3 000 modifications du code standard qui n’avaient pas été exploités depuis plus de 12 mois.

En complément :

Sapphire Orlando : Bill McDermott veut faire rimer SAP et simplicité

Sapphire Orlando : l’avenir de SAP s’écrit sur Hana… et avant tout sur Hana

SAP Walldorf : à la découverte du plus grand centre européen de R&D logicielle