Loading...
D’un strict point de vue comptable, la réponse est oui car un accroissement de la taille des données va provoquer, dans le pire des cas, un accroissement du temps de traitement de ces données. Mais cette inéluctabilité n’aura des conséquences fâcheuses que si rien n’est entrepris pour conserver les performances dans des limites acceptables. Cet article a pour but de défricher une approche possible et d’apporter quelques réponses à ce problème.
Dans le contexte des applications d’entreprise et plus précisément dans le contexte des applications légataires, une dégradation des performances est généralement constatée par les utilisateurs métier. La nouvelle de cette dégradation arrive ensuite aux oreilles de la DSI. A partir de là, un premier constat s’impose : les performances de réponse du système aux sollicitations des utilisateurs ont-elles fait l’objet d’un contrat d’agrément comportant un objectif de performance chiffré et objectif ?
Si la réponse est négative, il y a fort peu de chances que le SI puisse être considéré comme mature et de telles dégradations n’en sont qu’un des symptômes. Bien entendu, si vous avez adopté une démarche SOA ou si votre architecture de données en silos étanches est maîtrisée de bout en bout, cet article ne va pas vous aider à y voir plus clair, je m’adresse avant tout aux heureux propriétaires de solutions légataires le plus souvent développées au fil de l’eau sans démarche d’architecture. Et la réponse que j’apporte n’est pas d’entamer une démarche SOA à grande échelle quoiqu’une telle solution puisse être appropriée dans un SI mature.
Plutôt que de parer au plus pressé et de faire intervenir des experts coûteux dont les actions ne seront que des optimisations locales source du syndrome du « reculer pour mieux sauter », la première chose à faire est de définir ces fameux objectifs de performance pour chaque interaction entre un utilisateur et le système légataire. Cet objectif peut prendre par exemple la forme d’une limite majorant le temps de réponse (par exemple : telle recherche aboutit à un rafraîchissement de l’IHM après un maximum de 200 ms). Ces limites doivent être réalistes et correspondre à ce que les utilisateurs sont en droit d’attendre.
Si je parle des bases de données (ou, au sens large, de systèmes de persistance) c’est qu’il s’agit de mon domaine d’expertise. La dégradation des performances des autres composants d’une application suit le même chemin. Dans le cadre des bases de données légataires, après la définition des objectifs de performance intervient la partie la plus ardue de l’audit du modèle et des données. L’audit du modèle cherche à mesurer l’écart entre la conception effective de la base de données et les bonnes pratiques. Il est réalisé par un expert indépendant en collaboration avec la MOE et la MOA. Cet audit doit être exhaustif et aboutira à des préconisations. L’audit des données doit être réalisé par la MOA et nécessite le support d’un expert qui va préalablement aider la MOA à modéliser ses entités métiers et leur cycle de vie (en l’absence de documentation sur le sujet, il va de soi).
Ces deux audits ont pour but de dégager un ensemble d’éléments de conception et d’entités récupérables c’est-à-dire nécessaires à l’activité sous-tendue par l’application légataire. Les éléments de conception non récupérables sont destinés à être supprimés (ou archivés dans le cas de tables). Les données non récupérables sont destinées à être archivées, le plus souvent dans une base de données distincte, en lecture seule. L’ensemble de ce processus doit être suivi et documenté, il constitue en soi un projet.
A aucun moment une re-conception ou une ré-écriture du code n’ont été entreprise. C’est un facteur clé de succès de la démarche de ne pas altérer les objets récupérables. Une fois cette étape franchie, il est nécessaire d’en apprécier les effets sur les performances. Si les objectifs définis au préalable sont atteints, la démarche initiale prend fin. Sinon, des optimisations locales de requêtes peuvent être envisagées si la base de données dispose d’une API métier découplée de ses clients. Dans le cas contraire, une re-conception de l’architecture de l’application est à planifier au plus vite.
Une démarche qui a fait ses preuves dans ce dernier cas est de découpler au maximum la base de données de ses clients en ne concevant que l’API d’accès aux données. Entamer une démarche orientée services à ce stade peut être bénéfique. L’objectif à atteindre est de rendre le code des clients (serveurs d’application, services, batchs) neutre par rapport au modèle de données. Je présenterai une approche plus concrète de cette technique dans un prochain article à paraître ici.
