Même les systèmes nouveaux et complexes peuvent être stables

L'objectif principal de toutes les organisations SAP du monde est la stabilité. Conformément à la devise "Never touch a running system", elles continuent à collecter des correctifs, des adaptations et des développements individuels, les réunissent dans une grande version, la soumettent à des tests approfondis et répétés et la mettent en production une ou deux fois par an au maximum. Cela ne devrait pas changer dans le nouveau monde S/4. C'est notamment pour cette raison que de nombreux clients SAP existants réduisent de manière inadmissible la discussion sur le thème du cloud à la question du lieu idéal d'implémentation et d'exploitation de la nouvelle génération de logiciels de Walldorf.

Dans ce contexte, pour SAP, le cloud est avant tout une question d'architecture optimale pour les logiciels et le développement de logiciels du futur. Cela signifie des services spécifiques aux fonctions et réutilisables au lieu de monolithes logiciels et la publication de corrections, de modifications et d'extensions à un rythme soutenu dès qu'elles sont disponibles. L'époque des grandes versions à intervalles réguliers est donc révolue.

Cela va de pair avec la devise émise par SAP "Keep the core clean". Walldorf encourage les clients existants de SAP à ne développer et mettre à disposition des adaptations individuelles que sous forme d'extensions. Et pour éviter la coexistence de modifications rapides et flexibles dans le noyau d'une part et dans les extensions d'autre part, SAP recommande à ses clients de suivre le chemin d'or de son Cloud Application Programming Model (CAP). Dans ce modèle, les développeurs peuvent se concentrer sur leurs tâches spécifiques et développer du code dans d'autres langages de programmation qu'Abap. Tout va dans le sens de normes ouvertes pour une plus grande compatibilité et réutilisabilité, aussi et surtout en interaction avec des applications tierces.

De plus en plus de modifications en un temps de plus en plus court, de nombreuses petites versions à une fréquence élevée, davantage de langages de programmation, une séparation conséquente des niveaux de base de données, d'application et de représentation - le monde SAP devient plus complexe dans la nouvelle génération. Mais plus de complexité signifie plus d'efforts et plus de sources d'erreurs, l'horreur pour les organisations SAP qui s'accrochent d'autant plus obstinément au statu quo.

Dans ce contexte, la frontière entre les partisans et les opposants au changement ne se situe pas entre l'informatique et le reste de l'entreprise, mais au sein de l'informatique, entre le développement et l'exploitation. Commandé hier, livré aujourd'hui - c'est ce qu'attendent non seulement les utilisateurs professionnels, mais aussi les développeurs. Ils ne veulent pas attendre que l'environnement de test soit prêt pour leurs modifications et extensions créées avec des méthodes agiles, ni s'attarder sur leurs effets sur le fonctionnement et la stabilité de l'environnement de production.

Leur idéal est la standardisation et l'automatisation. Mais pour cela, ils ont besoin de leurs collègues de l'exploitation informatique. Et ceux-ci doivent mieux les comprendre. C'est précisément l'objectif du concept DevOps, qui crée la base nécessaire à cet effet grâce à une collaboration étroite au sein d'équipes interdisciplinaires.

DevOps est avant tout une question de culture. Et comme celle-ci fait défaut dans de nombreuses organisations SAP, la confiance dans cette approche fait défaut. Mais sans cette confiance, il n'y a pas non plus de mouvement de fond qui atteigne un jour une masse critique et assure pour ainsi dire de lui-même le changement nécessaire. C'est ce que l'expérience des trois à cinq dernières années a montré contre toute attente.

Un mot d'ordre de la direction doit imposer le Dev-Ops. Car sans agilité, un "running system" devient rapidement un "failing system" à l'ère du cloud. Une chaîne d'outils continue - du développement et de la correction itérative des erreurs jusqu'aux tests et à la livraison du code - aide à faire accepter cette décision : Pour que la confiance acquise dans la collaboration ne se brise pas sur la dure réalité des systèmes productifs, mais que les deux - le développement et l'exploitation - profitent de la mise à disposition rapide et fréquente, mais à faible risque, des logiciels.