J’ai récemment posté un blog sur l’analyse de la valeur en tant qu’outil de réduction des coûts.

Dans la foulée je crois utile de commenter également l’intérêt de la gestion du patrimoine applicatif pour la même raison : la réduction des coûts.

La gestion du patrimoine applicatif consiste d’abord à recenser et caractériser les assets logiciels à forte composante  métier(*), bien entendu sous une forme facilement exploitable.

La gestion du patrimoine applicatif consiste ensuite à exploiter cette information  en vue de :
– éviter les doublons et gérer la réutilisation ;
– mutualiser / rationaliser ;
– identifier et éliminer les éléments obsolètes ;
– garantir la cohésion de l’ensemble du système d’information.
C’est à ce titre que la gestion du patrimoine applicatif intervient comme outil de réduction des coûts.

On peut considérer que la gestion du patrimoine applicatif est la synthèse de deux disciplines : le strategic reuse et le portfolio management.

La gestion du patrimoine applicatif doit aussi servir d’autres fins, comme :           
– aider aux analyses d’impact ;
– évaluer régulièrement la qualité de l’existant (en particulier la détérioration éventuelle dans le temps suite aux  activités de maintenance – autrement dit gérer ce que l’on appelle communément la dette technique des applications)
– déterminer les priorités dans le cadre d’un DRP ;
– si d’application, aider à identifier les applications susceptibles d’être outsourcées ou passées en mode SAAS ;
– si d’application, aider à identifier les applications pouvant faire l’objet d’un déploiement dans un cloud (privé ou public) ;
– maitriser les engagements de service et de sécurité ;
– valoriser son SI (très utile en cas de rachat, acquisition , fusion) ;
– …

La gestion du patrimoine applicatif est aussi une dimension essentielle de la démarche d’architecture d’enteprise, d’ailleurs la première de mon avis, parce qu’essentielle en tant qu’outil de maîtrise de l’existant, dans le cadre d’une vision globale et offrant un retour rapide pour un investissement raisonnable.

Plus encore, il est certain selon moi que se lancer dans une démarche SOA sans faire de la gestion de son patrimoine applicatif est une erreur flagrante.

Consciente de ce danger, et à titre d’exemple pour illustrer la démarche, Smals a procédé :
– d’une part à l’inventorisation de ses éléments réutilisables, en faisant la distinction entre les services (les éléments appelables à distance) et les composants (les éléments embarquables)
– d’autre part à l’inventorisation des ses applications proprement dites, par branche métier et sur base de ses projets de développement d’applications déjà menés.

Il s’agit d’un outil devenu indispensable à ses efforts de réutilisation, de mutualisation et de rationalisation de ses développements d’applications.

Une démarche complète de gestion du patrimoine applicatif doit intégrer plusieurs dimensions :
– une dimension descriptive (but visé par l’application, use cases principaux, données dont l’application est maître, autres données utilisées , liens avec l’environnement, …), objet de l’application card ;
– une dimension quantitative (nombre d’utilisateurs, nombre de sessions simultanées, volume des données, nombre d’incidents sur une période donnée, indice de satisfaction des différents profils utilisateurs, indice de maintenabilité,…), objet aussi de l’application card ;
– une dimension technique (lien avec la CMDB par exemple) ;
– une dimension financière (coûts de maintenance [évolutive et corrective]).

Les deux premiers points au moins doivent être couverts.

Je termine en rappelant le piège habituel dans lequel ne pas tomber : vouloir en faire trop pour la “beauté du geste”, en oubliant l’objectif poursuivi, à savoir la réduction des coûts et donc la juste mesure de l’effort à accomplir.

La démarche ne peut en aucun cas générer des frais généraux sans retour réel ! Elle n’est pas une fin en soi mais bien un outil au service de la maîtrise des coûts.

_______________

(*) A forte composante métier laisse entendre que les logiciels bureautiques et autres “commodités” ne sont pas dans les priorités. Il s’agit surtout de s’intéresser en premier aux applicatifs clés du (ou des) métier(s).