SAPanoptikum mai 2017

Godfather and Master of Desaster

C'est lors d'un symposium DSAG sur Hana à St. Leon-Rot, près du siège de SAP à Walldorf, que tout le malheur a été révélé :
Le code Hana est plus mauvais que jamais !

Plus de 200 clients SAP existants ont répondu à l'invitation de DSAG pour s'informer sur l'état actuel et l'utilisation de Hana dans la pratique. La base de données in-memory computing inventée par le professeur Hasso Plattner et maintenant développée par le directeur technique de SAP, Bernd Leukert, est actuellement en très mauvais état.

Le taux d'erreurs des versions Hana livrées en permanence est en augmentation. Du point de vue de la DSAG et des clients SAP existants, la qualité diminue fortement et les utilisateurs courent ainsi d'une situation d'erreur critique à l'autre.

La réponse de M. Leukert, directeur technique, n'est pas vraiment utile : tous les 30 jours environ, SAP propose une mise à jour du logiciel. Cela part peut-être d'une bonne intention, comme l'ont expliqué quelques personnes concernées en marge de la manifestation de la DSAG, mais dans la pratique, cela ne peut pas être administré.

L'installation d'une nouvelle version tous les 30 jours est impossible à organiser pour la plupart des clients SAP existants.

Les applications ERP classiques ont besoin d'un noyau stable et d'une base de données robuste. Bien sûr, on peut discuter des approches „DevOps“ pour le développement d'applications mobiles et de l'IoT, où un nouveau code de programme est souvent déjà créé chaque semaine.

Pour un environnement de développement Scrum et DevOps, même un cycle de 30 jours, comme celui que SAP utilise actuellement avec le code Hana, peut être avantageux. Mais pour cela, il faut disposer de la bonne infrastructure informatique.

Lors de la réunion DSAG à St. Leon-Rot, on a également appris qu'il manquait des outils centraux pour l'administration de la mise à jour de la version Hana. Il n'existe pas encore de fonction de recherche avec une catégorisation, y compris des filtres adaptés, qui permette de trouver et d'évaluer les impacts (bugs) existants.

Comme le SolMan n'est d'aucune aide à ce niveau, la planification des changements de version et des mises à jour reste une affaire de chance et doit être mise en œuvre manuellement par les clients SAP existants, ce qui demande beaucoup d'efforts.

La fin de cette triste évolution ne s'est pas dessinée lors du symposium DSAG sur Hana. Un participant a déclaré que, selon la feuille de route de SAP, il faudra probablement attendre début 2020 pour que tous les composants Hana soient programmés et consolidés et mis à disposition dans une nouvelle version - peut-être Hana 3. (pmf)