Quels sont les enjeux de l’Industrialisation des processus de maintenance pour les DSI et les Directions Générales?
Les enjeux des DSI et des directions générales peuvent être résumés par la nécessité d’acquérir ou conserver un avantage concurrentiel grâce à son SI.
En d’autres termes, avoir un système plus efficace en termes de productivité à moindre coût.
Cela se décline en chantier de
- Réduction des coûts,
- Amélioration de la Maîtrise technique et fonctionnelle du SI,
- Optimisation des processus de développement et de maintenance,
- Réduction de la dette technique,
- Digitalisation des processus métier.
Il faut avoir en tête que la plupart de ces problématiques sont liées car le premier frein à la réduction des coûts et à la mise en place de processus agiles est lié aux adhérences des technologies utilisées avec des infrastructures obsolètes, chères à exploiter et/ou ne permettant pas de profiter des nouveaux outils et méthodes de développement.
Rationaliser son système et ses méthodes nécessite une modernisation technologique mais sans casser la dynamique commerciale du métier car « la vente continue pendant les travaux ».
La première étape de la rationalisation consiste à faire un état des lieux qui passe par un recensement technique et fonctionnel de son patrimoine.
Reprendre le contrôle de ses applications
Reprendre le contrôle de ses applications passe par la connaissance de ce qui est réellement exécuté en production. Cela n’est pas toujours le cas notamment sur des environnements Mainframe.
La problématique Mainframe
Voici quelques questions qui permettent de comprendre la problématique sur Mainframe :
- Avez-vous en production des load compilés avec des anciennes versions de compilateur ou avec des options de compilation différentes de celles en vigueur aujourd’hui ?
- Avez-vous en production des programmes linkés en statique avec des sous-programmes qui ont pu évoluer au cours du temps ?
- Avez-vous plusieurs versions de load dans les bibliothèques de production pour un même sources ?
- Recompilez-vos systématiquement tous les programmes qui utilisent une COPY quand celle-ci est modifiée ?
- Avez-vous des programmes en production pour lesquels vous n’avez plus les sources ou pour lesquels vous avez plusieurs sources possibles ?
- Avez-vous conservé par précaution des programmes non utilisés ou des lignes de code obsolètes dans les sources ?
Si vous avez répondu oui à une de ces questions ou si vous ne savez pas y répondre, il est probable qu’il y ait des axes d’amélioration sur vos processus de gestion de configuration et de maintenance.
L’objectif d’une gestion de configuration est de permettre de reconstruire en totalité une production à partir des sources des applications. Très peu d’organisations sont en mesure de le faire sur Mainframe.
Les environnement modernes
Sur les applications développées dans des langages modernes comme Java, il existe un grand nombre d’outils et d’usages permettant de bien gérer son patrimoine. Cependant, par manque de temps ou de moyens, on fait souvent du court terme.
Par exemple, pour disposer d’un référentiel de non régression à jour permettant de faire de l’intégration continue, il faudrait mettre en place une procédure de correction d’anomalie consistant à commencer par reproduire l’anomalie avec un cas de test qui viendra enrichir le référentiel avant de corriger l’anomalie. Là encore, peu le font réellement.
Les patrimoines Client / Serveur
Les patrimoines Client / Serveur sont entre les deux avec le plus souvent des applications gérées dans des gestionnaires de configuration mais des usages de programmation s’appuyant sur des langages évènementiels et souvent permissifs ce qui implique une explosion du nombre de cas de déclenchement d’un traitement. La programmation évènementielle n’ayant été que tardivement normée, on observe une duplication des traitements alors qu’il aurait fallu fonctionnaliser au maximum pour optimiser et sécuriser les évolutions et la maintenance.
L’accès aux données est également souvent géré de manière dispersée avec des requêtes saupoudrées dans tout le code, rendant délicate toute modification du modèle de données.
La cartographie Technique et Fonctionnelle
La cartographie Technique
La cartographie technique consiste à collecter tous les sources de tous les composants (Programmes, sous-programmes, JCL, Données, Copy, etc…) et de tirer entre eux les références croisées de manière identifier pour chaque composant :
- Les composants dont il a besoin
- Les composants à qui il est nécessaire
Sur la base des points d’entrée TP et Batch, l’atelier délimite le périmètre utile des composants et produits 2 listes
- Les Missings (Manquants) c’est-à-dire la liste des composants nécessaires mais dont le source n’a pas été fourni
- Les Unrefs (Non Référencés) c’est-à-dire la liste des composants dont le source a été fourni mais qui ne sont pas invoqués.
Il est nécessaire de collecter les sources des Missings qui potentiellement peuvent tirer des références vers de nombreux objets Unrefs.
Compléter la liste des points d’entrée permet également de référencer des composants identifiés comme Unrefs.
On voit bien qu’il s’agit d’un processus itératif et que le nombre d’itération dépendra de la qualité de la gestion de configuration.
La cartographie Fonctionnelle
On pourra compléter la cartographie Technique par une cartographie Fonctionnelle qui consiste à recenser la liste des fonctions ou applications métier. La granularité de ce recensement est un élément important pour permettre l’exploitation de ces informations.
On décrira la fonctionnellement la fonction ou l’application et on isolera le ou les points d’entrée.
La Synthèse
Le point d’entrée associé à chaque fonction ou application permet de lister de manière exhaustive les composants qui la supporte par application des références croisées issues de la cartographie Technique.
Les références croisées étant cross-technologie, on pourra suivre une transaction de bout en bout depuis le Front Client / Serveur ou Web jusqu’à la Table de la base de données DB2 sur Mainframe en passant par la transaction CICS développée en COBOL.
On pourra « scorer » la fonction ou l’application d’un point de vue tant technique, fonctionnel ou financier de manière à objectiver un macro schéma directeur qui permettra application par application de définir une cible optimum.
Les architectures mixtes
Quand la partie Cliente développée dans un L4G Client / Serveur s’appuie sur une partie Serveur sur Mainframe, il est très difficile d’avoir une vision de bout en bout de la transaction qui passe techniquement par différente couches applicatives et middleware et est de plus administrée par plusieurs équipes de développement.
Il est compliqué de tenir le cap optimum. Il convient d’être rationnel et de ne pas subir le régime des ayatollahs de la norme.
Avec une équipe expérimentée et connaissant très bien les applications, on peut faire quelques impasses et l’intuition des développeurs compensera le manque de rigueur. Mais tout à un prix, tôt ou tard, on subira un départ à la retraite, une démission, l’inflation mécanique des salaires et les résistances au changement.
Une bonne ligne nous semble être de profiter des apports technologiques en mettant en place la technologie et les processus permettant d’avoir une vue exhaustive de son patrimoine et des interdépendances entre les composants de manière à :
- Réduire le périmètre aux seuls composants utiles,
- Localiser plus facilement l’origine d’une anomalie
- Identifier tous les impacts d’une modification et réduire les effets de bord ou les régressions
- Permettre de détourer le périmètre d’une fonction pour urbaniser et améliorer on système
- Faciliter la montée en compétences des équipes de maintenance
- Sécuriser la maîtrise de ses applications
