DevOps avec SAP - sexy plutôt que paresseux ?

À l'époque des "Release Often, Release Early", le développement, l'assurance qualité et la mise à disposition de logiciels se heurtent à de nombreuses difficultés. La pression des collaborateurs, les efforts de communication manuels et les innombrables versions partielles en sont des exemples.

On pourrait être tenté d'ajouter des ressources à ces difficultés. Cependant, l'histoire a souvent montré que l'augmentation des ressources n'est pas synonyme d'augmentation de la vitesse, de la qualité et de l'étendue des fonctionnalités dans le développement de logiciels.

DevOps et les méthodes agiles peuvent offrir une approche pour relever ces défis. Il est important de noter que DevOps n'est pas la panacée pour chaque entreprise.

Et pour ceux pour qui une approche DevOps semble pertinente, une stratégie claire et la globalité de la mise en œuvre constituent les principaux facteurs de réussite.

Venons-en maintenant à la question de savoir si une approche DevOps peut être "sexy". Le terme "sexy" en rapport avec le monde du travail est généralement associé à des associations telles que "jeune", "nouveau" et "innovant".

Cela se reflète le mieux chez les collaborateurs de l'environnement SAP qui sortent tout juste de l'école ou de l'université ou qui osent se reconvertir du monde non-SAP.

Si ces personnes sont jetées dans une structure d'entreprise marquée par des concepts classiques de modèle en cascade avec des versions majeures et mineures, cela a un effet très désenchanteur et peut fortement freiner la soif d'innovation que ces personnes apportent.

Avez-vous déjà entendu la phrase "c'est historique" ? Trouvez-vous cette affirmation fascinante et incitant au changement, voire à l'innovation ? Nous non plus !

Dans l'environnement SAP, beaucoup de choses ont évolué au fil du temps, mais cela ne doit pas occulter la possibilité d'innover dans l'approche du développement logiciel.

L'introduction de DevOps peut, grâce à ses concepts modernes et motivants, relancer le moteur de l'innovation de ses propres collaborateurs, car ceux-ci peuvent voir plus loin que le bout de leur nez grâce à de nouvelles tâches et responsabilités.

Il est toutefois beaucoup plus difficile de réunir les différents départements informatiques pour permettre le DevOps que de simplement fusionner les noms des départements en ce mot artificiel qui est devenu de plus en plus hype au cours de la dernière décennie.

L'expérience a montré, en particulier lorsque des services SAP et non-SAP sont impliqués, que les processus pertinents des deux écosystèmes peuvent être très différents. Malgré cela, il est possible, avec un peu d'effort, de rendre utilisables pour le monde SAP les outils connus et largement répandus dans le monde non-SAP.

Il en résulte la possibilité de mettre en place un pipeline homogénéisé à partir d'outils utilisés en commun. Il n'est plus nécessaire de gérer les deux mondes séparément, ce qui réduit les frais généraux.

De plus, en utilisant les mêmes moyens pour SAP et non-SAP, une terminologie uniforme se forme parmi tous les collaborateurs. Cela permet d'abattre les murs de la communication et de renforcer le sentiment d'appartenance.

Pour une utilisation judicieuse de DevOps, une culture d'entreprise qui favorise la compréhension de la stratégie globale et qui rapproche toutes les parties prenantes de cette stratégie doit donc se dégager.

Ce n'est que lorsque les mondes SAP et non-SAP sont familiarisés avec les méthodes de travail de l'autre qu'il est possible d'en tirer de nouveaux potentiels. Ce sont ces effets de synergie qui font le succès d'une approche DevOps.

La conclusion ne peut donc être que la suivante : Oui, DevOps dans SAP peut être "sexy" ! À condition qu'il y ait une compréhension du processus global par les collègues SAP et non SAP et une volonté d'apprendre les uns des autres, le monde SAP, soi-disant si lent, peut apparaître sous un jour tout à fait nouveau et passer du statut de frein à l'innovation à celui d'accélérateur d'innovation.