Control-M : Montée de version

Les versions de Control-M ne s'enchainent plus aussi vite qu'il y a quelques années, le rythme est désormais stabilisé à une version tous les 2 ans. La version 7 est annoncée pour la fin de l'année 2010 et la disparition de la 6.2.01 est dors et déjà prévue pour juin 2011.

Un exercice complexe

De nombreuses Productions utilisent encore cette version,  et parfois même des 6.1.03. Il est donc légitime de s'interroger sur un projet de montée de version d'un logiciel qui impact directement la Production informatique d'une entreprise.

Plus la différence entre la version source et la version cible est importante et plus le risque est majoré. Et même si l'on pense maitriser son outil et disposé d'un temps suffisant pour ce lancer dans une telle opération, la complexité de l'exercice, son besoin de rigueur et surtout l'objectif qui est de minimiser l'impact sur les utilisateurs le rend extrêmement complexe.

Un projet qui a besoin de temps, . . .

Si vous faite appel à une société de service pour réaliser votre montée de version Control-M, voila ce que elle ne pourra pas vous dire commercialement et qui est pourtant la dure réalité d'un tel projet. La durée du projet que vous imaginé de quelques semaines est beaucoup plus long que cela. Car inévitablement vous aurez au cours du projet des problèmes de tous ordres, mais aussi des besoins non evalués au départ.

La montée de version va vous faire repenser votre architecture et vous rencontrerez les problèmes liés à du nouveaux matériels, un nouveaux O.S., à la mise en cluster, à l'intégration dans votre P.R.A. ou à la rationalisation de votre architecture.

Plus la différence de version est importante, plus la montée de version va mettre au grand jour des incohérences de normes, des mauvaises pratiques à l'utilisation du produit, voir même des données erronées dans la base des définitions.  L'utilisation de scripts, de commandes, voir même de requêtes dans les bases de données dont la connaissance c'est estompée au fil des années, voir même est totalement ignoré de l'actuel administrateur, sont facteur de dérives majeures sur le projet.

La possibilité de mettre à jour les conversions effectuées tout au long du projet, de réaliser des tests en mode simulation ou sur un environnement dédié est fortement consommateur en temps, pour des équipes qui sont fortement sollicitées par les contraintes de Production.

. . . de maitrise et d'experience.

Mais sans l'expérience d'un intégrateur aguerri à ce type d'opération, vous vous aventurez parfois vers un parcours semé d'embuches.

D'abord pour toutes les raisons précédemment  évoquées que vous devrez affronter vous même. Mais aussi, parce qu'une montée de version sans une méthodologie adaptée ne permet pas de réaliser suffisamment de tests pour garantir l'intégrité et la viabilité des données.

Que comme pour tous les autres progiciels, les supports de cours, les conseils avisés du support et les témoignages recueillis dans les forums ne peuvent en aucun cas remplacer l'expertise d'un consultant certifié.

Parce que une montée de niveau ce doit être l'occasion de remettre en question tant son architecture, que ses bonnes pratiques ou l'intégration de son ordonnanceur dans une démarche de ITIL , ou encore de lui donner une autre place au sein de son Datacenter.

Et puis plus simplement, montée de niveau Control-M, ne se limite pas  à installer la nouvelle version, à convertir les données et à basculer. Nombreux sont ceux qui y ont crus et qui s'en sont mordus les doigts.

Ce n'est pas une opération pour laquelle il est recommandé de se faire accompagner.

Articles complémentaires :

Sur la normalisation des ordonnancements
De l'intérêt de re-normaliser ses Ordonnancements de Production
De l'intérêt de re-normaliser ses Ordonnancements de Production (2ème partie)
 
Supe les P.R.A. et les secours
De la disponibilité de l'ordonnanceur et du secours.
De la disponibilité de l'ordonnanceur et du secours (2ème partie)