Au-delà de SAP Build

L'absence de proposition de valeur de SAP Build : Pas d'approche de développement low-code pour tout le monde

Le développement efficace d'applications logicielles est d'une importance capitale dans le monde des affaires numériques. Un regard détaillé sur les avantages, les défis et les contraintes de SAP Build et leur impact sur le développement d'applications révèle dans quelle mesure SAP peut tenir sa promesse de valeurs, notamment en ce qui concerne l'approche Low-Code.

SAP Build promet aux entreprises un environnement convivial dans lequel des applications peuvent être développées sans connaissances en programmation. La plateforme est basée sur le logiciel de l'entreprise Appgyver, qui a été rachetée par SAP en 2021. Elle offre de puissants outils de prototypage et de conception qui permettent aux développeurs de créer rapidement des interfaces utilisateur interactives. L'implication précoce des utilisateurs et le feedback continu doivent permettre d'optimiser les applications pour une expérience utilisateur optimale.

L'un des grands avantages de Build, comme de toute plateforme Low-Code, est d'accélérer le développement d'applications. La plateforme propose à cet effet des composants d'interface utilisateur et des modèles prédéfinis qui rendent le processus de développement plus efficace. La réutilisation de composants existants permet de réduire considérablement les temps de développement, ce qui accélère la mise sur le marché des applications.

Une collaboration et une communication efficaces sont essentielles à la réussite des projets de développement. C'est pourquoi SAP Build propose également des fonctionnalités telles que les commentaires, les notifications et le partage de projets afin de favoriser une collaboration transparente entre les développeurs, les concepteurs et les utilisateurs. Cela permet d'échanger des commentaires et de travailler ensemble sur des améliorations afin de développer des applications qui répondent aux attentes des utilisateurs.

Connaissances en programmation demandées

Cependant, malgré les avantages, l'utilisation de Build dans le processus de développement présente également plusieurs défis. Alors que les avantages résident dans le fait que les applications centrées sur l'utilisateur peuvent être développées rapidement et efficacement, les limites résident surtout dans l'utilisation du développement low-code pour les app-builders sans connaissances en programmation.

Dans la pratique, il s'avère que cette plateforme nécessite effectivement des connaissances considérables en programmation. Ainsi, une formation intensive à la plateforme est nécessaire, en particulier pour les utilisateurs, les développeurs et les concepteurs qui ne sont pas familiarisés avec la plateforme. Les nombreuses fonctions et possibilités de SAP Build nécessitent une formation adéquate pour pouvoir exploiter pleinement le potentiel de la plateforme.

Un autre problème de Build est le manque d'internationalisation de l'éditeur Wysiwyg. Alors que le contenu des applications créées peut être traduit dans différentes langues, l'outil lui-même reste exclusivement en anglais. Cela constitue un obstacle, surtout pour les entreprises des pays non anglophones, et rend l'utilisation de la plateforme plus difficile.

L'un des principaux problèmes est la fonction d'exportation limitée de SAP Build. Bien que la plateforme promette la création d'applications mobiles, seule la génération d'applications web est actuellement possible. En d'autres termes, il n'est actuellement pas possible de développer des applications natives iOS ou Android directement avec Build.

L'exportation d'apps vers une application web prend en outre un temps inhabituellement long et la notification par e-mail annoncée lorsque l'application est terminée fait défaut. Les applications web générées ne sont pas non plus basées sur le framework UI5 maison de SAP, mais utilisent React Native. Cela crée une dépendance qui ne peut pas être contrôlée par SAP et rend difficile l'édition et la réutilisation du code, car Build manque du langage de conception SAP Fiori habituel. Certes, une intégration avec les services mobiles SAP pourrait être possible à l'avenir, mais il n'y a actuellement aucune indication claire à ce sujet dans la documentation ou la feuille de route de SAP Build.

L'intégration de Build dans les environnements d'entreprise existants représente également un grand défi. Bien que la plateforme soit conçue comme une solution "low/no code", la connexion au backend s'avère complexe et concerne donc en particulier l'aspect du Citizen Developer. Il apparaît clairement que la liaison et le traitement des données, qui sont habituels dans l'environnement SAP, ne sont pas adaptés au Citizen Developer.

Connaissance d'OData

Pour connecter et afficher des données provenant de systèmes d'entreprise tels que S/4 Hana Cloud ou On-premises, des connaissances spécifiques sur le protocole OData, la cartographie des variables et leur intégration dans le cycle de vie de l'application sont nécessaires. Les mécanismes mis à disposition et l'éditeur de formules vont au-delà du concept de Low Code ou No Code. Il est donc difficile pour les Citizen Developers d'établir de telles connexions et de créer des formules complexes sans connaissances approfondies.

La connexion transparente aux données S/4 Hana Cloud ou sur site reste donc un défi au sein de la plateforme de construction. L'authentification, l'autorisation et la connexion aux sources de données ne sont pas non plus au point et n'offrent que des possibilités limitées aux développeurs professionnels. L'attribution des rôles et un système complet de rôles et de droits font également défaut.

L'évolutivité et les performances des applications d'entreprise sont d'une importance capitale. Lors de l'utilisation de Build, il est important d'examiner l'architecture en profondeur, de développer un code efficace et d'effectuer des tests en conditions réelles afin d'identifier et de résoudre rapidement les goulots d'étranglement ou les problèmes de performance.

Sécurité et protection des données

La sécurité et la protection des données sont d'autres aspects importants du développement d'applications d'entreprise. Lors de l'utilisation de Build, les entreprises doivent s'assurer que toutes les exigences en matière de protection et de sécurité des données sont remplies, en particulier lorsque des données sensibles de l'entreprise sont traitées.

L'un des principaux inconvénients pour les équipes informatiques et les développeurs SAP professionnels est que la création avec SAP Build n'est pas aussi flexible que la programmation dans Abap, par exemple. Abap permet aux développeurs de mettre en œuvre des logiques commerciales très complexes et de répondre à des besoins spécifiques. Avec la plateforme low-code SAP Build, il est difficile d'implémenter de telles logiques complexes et de demander des adaptations supplémentaires ou des solutions de contournement.

Un facteur non négligeable réside également dans l'acceptation au sein de la communauté SAP, connue pour son puissant langage de programmation Abap. Au sein de la communauté, différentes approches ont toutefois été discutées dans le domaine du développement Low-Code/No-Code. Diverses coopérations et acquisitions de SAP dans le passé proche dans le domaine du Low et No Code ont certes été fortement poussées, mais n'ont jusqu'à présent pas vraiment convaincu la communauté SAP. La communauté SAP a développé un certain scepticisme lorsqu'il s'agit de plates-formes Low-Code/No-Code.

Un aspect qui a suscité des discussions dans ce contexte au sein de la communauté SAP est l'annulation d'une coopération avec Microsoft et son produit Power Apps. De nombreux membres de la communauté SAP ont été déçus, car Power Apps possède une communauté importante et active. Toutefois, ce refus a également eu pour conséquence que d'autres fournisseurs de plateformes low/no code, comme Simplifier, ont désormais la possibilité de gagner des clients SAP existants et des partenaires en présentant de manière convaincante la valeur ajoutée de leurs solutions pour le développement d'applications centrées sur SAP. 

Il vaut donc la peine pour les entreprises d'oser regarder avec les utilisateurs et les équipes de développement SAP des alternatives low-code plus légères et plus flexibles comme Simplifier, afin de comparer leurs propres exigences avec les possibilités et les fonctionnalités des plates-formes, pour finalement trouver une technologie low-code appropriée qui réponde à leurs besoins.

Dans l'ensemble, on peut dire que SAP Build ne tient pas sa promesse de plateforme de développement low-code. Tant les utilisateurs spécialisés que les développeurs pro-code sont confrontés à diverses restrictions et lacunes. La plateforme n'est pas encore suffisamment mature et n'offre pas une approche globale et surtout unifiée pour le développement d'applications d'entreprise. À l'origine, SAP Build était présenté comme une solution permettant aux entreprises de créer leurs propres applications et processus sans connaissances en programmation. Mais dans la pratique, il s'avère que cette plateforme nécessite en fait des connaissances considérables en programmation.

Alternative minceur

Simplifier est un fournisseur de Low-Code qui est désormais connu dans le monde SAP comme "alternative allégée à SAP Build" et qui a convaincu de nombreuses entreprises ayant atteint leurs limites avec la chaîne d'outils de SAP et de BTP. Grâce à sa technologie moderne basée sur le framework UI5, très apprécié de la communauté SAP, la plateforme Low-Code a su séduire de nombreux développeurs SAP et Abap. Les avantages liés à l'utilisation de Simplifier sont notamment les multiples possibilités d'intégration standardisées, l'UI la plus flexible pour l'utilisation d'applications sur tous les terminaux (y compris les wearables), un degré élevé de réutilisation pour tous les contenus créés et existants et un concept opérationnel allégé lors du déploiement et de l'utilisation d'applications et d'applications mobiles.