Quelle méthode pour simplifier le SI ?
Par Alexandre Feray, directeur de Nextops

mardi 13 mai 2008

20080513_16 La complexité - souvent inutile, toujours couteûse - est un des problèmes majeurs des DSI qui accumulent des couches de sédimentation déposées depuis des dizaines d'années. Alexandre Feray propose quelques éléments de réflexion dans l'article ci-dessous qui s'inscrit dans la préparation de la conférence DSI 2010.

Naturellement, les systèmes d'information des entreprises se complexifient au cours du temps car ils doivent supporter les évolution des entreprises (évolution de leur métier, fusions...), les évolutions de leurs processus (réorganisations, optimisations...), et les évolutions technologiques (systèmes ouverts, internet...). Cette complexité croissante réduit l'agilité de l'entreprise, détériore la qualité de service et augmente les coûts. Pour cette raison les DSI sont sans cesse confrontés à des programmes de rénovation ou de simplification des legacy.

On distingue quatre grandes stratégies de rénovation du SI :

- L'obligatoire, justifiée par une contrainte réglementaire incompatible avec le système actuel ou par la disparition d'une technologie. Elle se passe de justification économique et doit aller au plus vite. Pour ces raisons, il est conseillé que son périmètre se restreigne bien à la résolution de la contrainte obligatoire.

- L'autonome, qui se justifie économiquement par les seuls gains liés à la simplification. Elle est rare (vue les coûts de rénovation) mais peut se rencontrer à la fin d'un programme de rénovation. En effet, un business case technique peut justifier l'abandon d'une plate-forme qui ne supporte plus qu'un legacy fortement amaigri.

- L'opportuniste, qui consiste à profiter de projets et gains métier pour construire une base qui permet la simplification du SI. Elle doit être bien partagée avec le métier pour concilier les impératifs du projet et la cible en terme d'architecture.

- Le programme stratégique, qui consiste en une refonte générale des processus et systèmes d'information afin de les aligner avec une nouvelle stratégie d'entreprise (fusion, objectifs stratégique de gains de productivités...). Son périmètre et sa complexité doivent être bien maîtrisés.

Dans tous les cas, la rénovation doit être précédée et accompagnée d'une réflexion en terme d'Architecture d'entreprise, telle que la définit par exemple le CEISAR.

La complexité du système doit s'évaluer selon les trois axes de l'architecture d'entreprise : l'axe métier (entités, processus et fonctions métiers...), l'axe organisation (acteurs, processus organisés et activités...) et l'axe technologie de l'information (matériels, technologies, qualimétrie...). Et la mesure de la simplification du patrimoine applicatif ou de la maturité architecturale doit se lire selon cette même grille de lecture.

La méthode de simplification peut se décrire en 4 étapes de préparation, suivies d'une ou plusieurs stratégies d'implémentation.

20080513_14

Les 4 étapes de préparation sont :

- La description du système existant: système d'entreprise, cartographie des blocs applicatifs et architecture technique

- La description du système cible: système d'entreprise cible: définition des entités du métier, modélisation des processus; cartographie des blocs applicatifs: urbanisation du SI; et architecture technique: stratégie d'intégration (SOA...), choix des technologies (ERP, middleware...)

- La sélection des blocs applicatifs à conserver, transformer ou remplacer. Elle est issue de la décomposition des blocs, de leur évaluation (en terme de complexité et de gap entre le système d'entreprise futur et existant), et d'une analyse de la propagation de la rénovation (liée aux interdépendances)

- La mise en place d'une gouvernance de la simplification: qu'elle soit stratégique ou au niveau des projets, elle est clef et doit impliquer les métiers, disposer de métriques et mettre en place des comités d'architecture.

On entre alors dans le processus concret de transformation ou du remplacement des blocs applicatifs. Il est compliqué en termes d'architecture et en termes techniques et spécifique à chaque projet. Il existe toutefois des grilles de lectures et des processus privilégiés selon la situation.

20080513_15

Ainsi, dans une stratégie de transformation, il est conseillé en premier lieu de mettre en place des services réutilisables d'accès aux données (conforme à la modélisation cible), puis de transformer les applications pour qu'elles utilisent ces services. Dans un deuxième temps, on fait de même avec les fonctions métier réutilisables qu'on expose sous forme de services logiciels. Enfin, on ré-interface les blocs et élimine les parties mortes.

Dans une stratégie de remplacement, il est conseillé de maintenir dans une premier temps une compatibilité ascendante au niveau des interfaces du système rénové puis de mettre à jour les systèmes périphériques afin qu'ils utilisent les nouvelles interfaces, et ensuite de les rénover à leur tour.

Selon la criticité des systèmes et leur caractère opérationnel, on conduira la stratégie de remplacement en mode big-bang (plus simple et plus rapide, mais qui nécessite une préparation minutieuse et des phases pilotes) ou en mode exécution parallèle (les deux systèmes ancien et nouveau tournent en parallèle et se synchronisent ; cela requiert de grandes précautions d'architecture et coûte plus cher au final, mais permet de réduire les risques).

______________
Alexandre Feray est directeur de la société Nextops, société de conseil spécialisée dans la rénovation des systèmes legacy.Il fait également partie de l'équipe de consultants du CEISAR.

Imprimer l'article