La complexité des systèmes d’information a beaucoup augmenté durant les deux dernières décennies. Les entreprises ont souvent réagi à des pressions de réactivité en répondant à un besoin par un projet de développement qui a ajouté une nouvelle application avec des données répliquées à partir des applications existantes. L’architecture qui en a résulté est accidentelle, le parc applicatif obèse, avec des redondances de données et de fonctions.
La plupart des entreprises n’effectuent pas d’inventaire global de leurs applications, ni de benchmark.
Le manque de visibilité sur leur parc applicatif est une des premières causes de difficultés des DSI. Une étude du BPM Forum en 2004 mettait en exergue le fait que 25% seulement des sondés effectuaient une fois l’an un inventaire global de leurs applications, et que 73 % des entreprises ne disposaient d'aucun moyen de détection des applications obsolètes ou redondantes
L’observatoire « modernisation des SI et maturité des entreprises » de Sapientis confirme ces constats en 2009, où les sondés ont reconnus majoritairement avoir des limitations d’architecture applicative en redondance de fonctions, puis en 2010, où la majorité des sondés ne faisait pas d’inventaire annuel (avec des chiffres toutefois en augmentation et plus satisfaisants que l’étude du BPM forum) et n’employait pas de méthode systématique pour étudier les capacités de l’existant avant tout projet de refonte.
LimitationArchi.png Légendes figurant dans l’image
Figure 7-1.
Les limitations d’architecture qui contraignent l’évolution du SI
Source observatoire « Modernisation des SI et maturité des entreprises » Copyright Sapientis
Inventaire.png
Légendes figurant dans l’image Figure 7-2.
Pratiques d’inventaire du patrimoine applicatif
Source observatoire « Modernisation des SI et maturité des entreprises » Copyright Sapientis
EtudeExistant.png Légendes figurant dans l’image
Figure 7-3.
Pratiques d’étude de l’existant avec refonte
Source observatoire « Modernisation des SI et maturité des entreprises » Copyright Sapientis
La méconnaissance de l’existant s’explique d’une part par la difficulté à maintenir une documentation à jour pour des modifications au fil de l’eau des programmes, d’autre part, par des difficultés à trouver le bon grain de collecte, ou la bonne représentation (au sens d’une modélisation partageable par toutes les parties prenantes) des informations décrivant le système d’information. Les projets de cartographie de l’existant, sans parler des choix de méthodes difficiles à évaluer, pèchent par leur inertie (temps de retard sur les besoins métiers) et n’arrivent pas à être en ligne avec l’accélération des rythmes d’évolution qu’impose une économie désormais mondiale.
Les causes se peuvent comprendre à l’aune des logiques d’organisation qui privilégient le court terme (la réactivité à la demande exprimée par le client) au long terme (inscrire la réponse à la demande dans un cycle vertueux de mise à jour des connaissances). Restent les conséquences : dans certains cas, pour retrouver la connaissance du système d’information, pour savoir réellement ce qu’il fait et comment, il faut plonger dans les programmes des applicatifs existants.
Est-ce le côté aride des bases de données ou des algorithmes de programmation (peu lisibles naturellement par un non technicien), le manque de liens sémantiques, qui fait que l’exploitation de la valeur de la connaissance codée des systèmes d’information de gestion hérités du passé est insuffisante ? Toujours est-il que beaucoup de ce qu’on appelle la logique métier est enfouie dans des codes sources et peu ou pas utilisée.
Parce que l’information ne répond pas à des critères de qualité, telles que l’accessibilité (il est souvent difficile de l’identifier et de la localiser dans des millions de lignes de code pour partie obsolète), la fiabilité (le manque de précision sur le contenu, la fréquence de mise à jour, le type de source, etc.), la pertinence (sans qualification il est difficile pour un utilisateur de l’exploiter), et que, ne connaissant pas le réel intérêt de cette information
«presque» perdue, le coût de remise à niveau de la qualité est jugé souvent prohibitif, jusqu’à, bien entendu être mis en demeure de le faire.
En passant, on imagine le coût de maintenance et la perte de connaissance liés aux 11 millions de ligne de code en macro-assembleur de la société américaine Union Pacific, pour que cette dernière se lance dans un programme de migration de 150 à 200 millions de dollars, dont la fin est prévue en 2014.
Le défi à relever ici, s’il est devenu partiellement technique au sens où il peut être nécessaire de faire appel à des technologies de rétro-ingénierie pour aider à reconstituer une cartographie de l’existant, est à l’origine essentiellement organisationnel.
En effet, il n’y a pas le plus souvent de responsabilité (de rôle ou d’entité sponsorisé par la direction) désignée à l’évaluation du portefeuille applicatif, c’est à dire :
à la mesure de la qualité des applications existantes, et ce en termes pragmatiques de valeur métier, de capacité à évoluer et de risques d’obsolescence ;
à la prévention des risques d’obsolescence ;
à la suppression des applications obsolètes ou redondantes ;
à l’évaluation a posteriori des réutilisations possibles, cette évaluation étant complexifiée par l’adhérence des anciennes applications à des technologies et des plate-formes spécifiques.
Il s’agit donc pour le DSI de reprendre connaissance de l’existant, non seulement en termes d’infrastructures techniques et d’applicatifs, avec un diagnostic de l’état de lieux, mais également en termes de mesures lisibles par toutes les parties prenantes, de l’apport du S.I. Pour cela, il ne peut agir seul. Il a besoin de la
nécessaire implication des directions métiers. Ce qui est un autre défi à relever.