Découplage de l’AS/400 : méthode et intérêt pour les entreprises
Né à la fin des années 80, l’AS/400 est toujours utilisé, même s’il ne permet pas une architecture orientée services – devenue une nécessité aujourd’hui. Si changer d’outil demeure un défi, il existe des méthodes éprouvées pour réussir la bascule, nous explique le CTO de kbrw.
par
Arnaud Wetzel, CTO co-fondateur de kbrw
Publié le: 15 mars 2023
Standard de gestion et de vente d’une qualité incontestable conçu à la fin des années 80, l’AS/400 est toujours utilisé de nos jours. Cette structure « monolithique » ne permet cependant pas d’avoir une architecture d’entreprise orientée services, alors qu’il s’agit aujourd’hui d’une nécessité pour développer son activité.
Or changer d’outil d’exploitation demeure un défi de taille pour les grandes organisations, surtout lorsqu’il contient les modèles de données et de fonctionnement en transversalité des métiers.
Fort heureusement, il existe des méthodes pour faire la bascule avec succès.
L’architecture de microservices comme cible principale
Comportant notamment une base de données et des éléments de sécurité avancés, la force de l’AS/400 réside dans sa robustesse et le niveau de sécurité qu’il offre. C’est la raison pour laquelle, contrairement à une PME, il est particulièrement délicat pour les grandes organisations de s’en séparer. Elles ont « customisé » leurs métiers, codé leurs transactions dans ce monolithe et ont pu se développer grâce à cela. D’autant plus que l’AS/400 génère moins de dépendance externe (plus on a de logiciels plus il y a des risques). Le « Run » est simple et unique, et tous les systèmes sont cohérents entre eux.
Quel est donc l’intérêt de changer ?
Réponse : développer leur activité en capitalisant sur la problématique métiers, c’est-à-dire en améliorer les processus de contrôle et les façonner en y ajoutant des services en fonction de leur évolution. Autrement dit, la dimension métier sera au cœur de la conception.
Pour y parvenir, les processus ont besoin d’être digitalisés et automatisés (dans le monde des mainframe, il n’est pas possible de les switcher, car ils sont prédéfinis). Ainsi, grâce au gain de temps obtenu, les fonctions métiers vont retrouver la capacité de construire et de faire évoluer facilement et rapidement l’ensemble des caractéristiques qui les compose.
Switcher de modèle ne s’improvise pas
Basculer d’un modèle AS/400 vers une structure protéiforme n’est toutefois pas chose aisée pour de nombreux développeurs.
Il faut déjà pouvoir dire que l’outil doit être remplacé, car il est obsolète, or l’AS/400 offre des services d’interfaçage biaisant cette notion. D’autres opérationnels considèrent qu’il faut repartir de zéro avec un big bang, plus rapide et plus efficace selon eux, bien que potentiellement dangereux pour une grande structure.
Quoi qu’il en soit, pour quitter l’AS/400, il faut que l’intérêt métier soit maximisé. Car ne nous mentons pas : le découplage permet de gagner en flexibilité et en évolutivité, mais il introduit également des risques en termes de sécurité et de performance.
Pour quitter l’AS/400, il faut que l’intérêt métier soit maximisé.
Aussi, la bonne stratégie pour franchir le cap consiste à continuer de penser « monolithique » pour acquérir une vision « non-monolithique ». On nomme ce principe « le mirroring ». L’objectif étant, lors de la construction du nouveau logiciel, de reproduire temporairement le comportement de l’AS/400 et d’en analyser les flux pour permettre aux équipes IT de construire les nouveaux services, petit à petit, puis de le décommissionner progressivement.
Bien que cette méthode n’emporte pas l’adhésion de tous les développeurs qui ont le sentiment de monopoliser des équipes pour réaliser quelque chose qui a vocation à être supprimé, elle reste le moyen le plus sûr pour réussir la bascule.
Toutefois, pour être un succès, elle demande une organisation agile avec la mise en place d’epics. Il va plus précisément s’agir d’aider les équipes à décomposer leur travail en sous-groupes, tout en continuant de poursuivre un objectif plus important et de livrer de la valeur aux clients sur une base régulière.
Conclusion
Décommissionner un AS/400 n’est pas une action à négliger. Bien plus qu’une permutation de logiciel, cette démarche réinterroge toute l’organisation informatique : nouvelles problématiques de gestion du risque, architecture continue et organisation agile, pour permettre au métier d’être à la source du modèle IT.
C’est en s’emparant de tous ces sujets qu’une transition réussie est possible.
Pour approfondir sur Architectures logicielles et SOA
