Enseignements

pas
se débarrasser de la base de données existante. Ce serait en effet trop coûteux.
Trop de programmes dépendent de la structure actuelle et la logique d’accès aux
données y est profondément intégrée. Il est préférable de copier les données,
les transformer et les nettoyer selon les besoins, puis les stocker sous une forme
plus favorable au traitement analytique.
On peut ensuite implémenter les nouvelles fonctionnalités sur la nouvelle base
de données organisée en conséquence. Une telle méthode de modernisation peut apporter
de nouvelles possibilités de traitement intéressantes et tous les coûts d’implémentation
sont associés aux nouvelles fonctions, et non au redressement du système existant.

Un autre enseignement est que toutes les modernisations ne sont pas une partie
de plaisir. La mise à  jour d’une application s’apparente parfois à  la rénovation
d’une vieille maison, pièce par pièce, alors qu’on y habite. Ce qui était superbe
au départ a été défait par les démolitions, les réparations et les peintures.
Cependant, comme nous l’avons vu ci-dessus, le remplacement pur et simple de l’ancienne
structure peut s’avérer trop coûteux ou trop perturbant. Ou, pour des raisons
politiques, on ne peut obtenir le personnel et le budget pour réécrire l’ensemble.
Dans de telles situations, la meilleure solution peut passer par une modernisation
lente et progressive. Autrement dit, il faut cacher les améliorations du système
dans la maintenance, en se préparant pour le jour où la société décidera qu’il
est temps d’adopter une interface graphique ou une extension Internet .

Les systèmes vieillissent parce que les techniques se démodent, supplantées par
de nouveaux langages, fonctions, API et protocoles. Mais aussi parce que nous
ne tirons pas le meilleur parti de la maintenance. Nous effectuons la maintenance
à  la va-vite, en faisant juste ce qu’il faut pour corriger le problème immédiat
ou pour ajouter la fonction demandée. Pourquoi ne pas innover carrément et décréter
qu’après la maintenance, un programme devrait être en meilleure forme qu’avant
l’intervention ?

La plus grande partie du travail de maintenance consiste à  trouver le code existant
approprié et à  le comprendre. Il faut capturer cette information en enregistrant
ce que l’on a trouvé sous forme de commentaires internes ou de documentation externe.
Dès lors qu’on comprend le code, il faut l’améliorer sous forme de modules et
en le restructurant. Lorsqu’on ajoute une fonction, il faut la concevoir, l’insérer
et l’intégrer comme si elle faisait partie du système initial plutôt que de la
rajouter comme une rustine.

Chaque fois que l’on touche à  un programme, il faut l’amener au niveau des standards
actuels. Peut-être faut-il utiliser RPG IV, les standards de dénomination actuels,
un meilleur traitement des dates, ou de nouvelles API. Lorsque de nombreux programmes
d’un module sont concernés, il faut amener tout le module au niveau des standards
actuels. Certes, c’est un peu plus cher et un peu plus long, mais il en résulte
un système qui s’améliore continuellement et qui reste jeune plus longtemps.
De plus, la maintenance est ainsi plus intéressante et plus gratifiante.

La maintenance permet, entre autres, de modulaiser les règles de gestion sous
forme de programmes appelables. La modernisation d’une application consiste souvent
à  ajouter de nouveaux clients comme un frontal graphique ou Web, ou même à  s’intégrer
à  un processus de workflow Domino. Il ne suffit plus alors d’accéder aux données
de l’application. Il peut être difficile de lire efficacement les données avec
SQL ou des routines d’accès au niveau enregistrement. Il faudra peut-être appeler
la logique d’accès aux données depuis l’application existante.
Quand le nouveau client met à  jour la base de données, il faut valider les données,
calculer des valeurs comme les prix et mettre à  jour des données redondantes ou
connexes. Et l’on se gardera bien de dupliquer la logique de règles de gestion
actuelle dans le code client, au risque de créer des clients  » lourds  » peu performants,
mal sécurisés, sujets à  erreurs et obligeant à  une double maintenance. Il faut
plutôt pouvoir appeler la logique de gestion et les routines d’accès aux données
existantes, à  partir du client. On fait cela généralement en utilisant des procédures
cataloguées par l’intermédiaire d’ODBC ou de quelque forme d’appel de procédure
à  distance.

Malheureusement, l’architecture de la plupart des systèmes traditionnels ne permet
pas ce genre d’accès. La correction de cette déficience par la modularisation
est importante pour le processus de modernisation. (L’article  » Sept choses à 
connaître à  propos de l’écriture de programmes RPG modulaires « , donne des conseils
sur la modularisation.)

Le coût de remplacement complet d’un système est généralement sous-estimé. Outre
les coûts informatiques, il faut considérer l’impact sur les utilisateurs, le
temps des participants impliqués, y compris le management (le coût réel et le
coût d’opportunité), et le risque d’échec du projet ou des dégâts causés par le
passage au nouveau système. Construire sur l’existant et augmenter le budget de
maintenance pour améliorer les systèmes de façon continue n’est peut-être pas
aussi spectaculaire qu’une refonte complète du système, mais c’est certainement
une solution de bon sens.