Bien penser et concevoir les systèmes informatiques demandent d’avoir compris et intégré quelques principes relatifs à la notion de valeur.
Je me propose ici d’en illustrer quelques uns, dans la foulée du blog consacré au bien fondé d’une démarche d’analyse de la valeur (juillet 2011).
Pour ce faire, je vous propose les trois notions suivantes : valeur d’usage, valeur métier et valeur intrinsèque, auxquelles j’associerai les définitions qui suivent.
Le terme valeur est à interpréter comme traduisant la qualité du système construit, dans la dimension considérée.
La valeur d’usage traduit la capacité à exploiter au mieux les moyens disponibles.
La valeur d’usage traduit le respect des bonnes pratiques dans la mise en oeuvre et l’exploitation des moyens. Gestion de projet (Prince 2, …), architecture d’entreprise, exploitation (ITIL, …), … Avec la modération voulue, parce qu’optimiser la mise en oeuvre et l’exploitation des moyens demande de garder la porte ouverte à la créativité (les bonnes pratiques sous la forme de standards ne doivent pas étouffer l’intelligence des opérationnels).
La valeur métier traduit l’alignement des moyens disponibles sur les besoins métier :
– modèle de données complet ;
– données exactes ;
– règles et processus métier complets et exacts ;
– contribution à l’efficacité opérationnelle (apport sur la réduction des coûts, la productivité, la satisfaction du client, les possibilités de suivi métier, le reporting, la business intelligence, …) ;
– …
La valeur métier est liée à l’instant.
La valeur intrinsèque est relative à la qualité même des moyens disponibles.
En premier lieu sur les données :
– modèle de données de qualité (performant, facilement extensible ;
– actualisation des données bien prise en compte – pas de désynchronisation importantes ;
– maintien de la qualité dans le temps ;
– gestion uniformisée / accès par des voies obligées (pour garantir les contrôles nécessaires sur les données) ;
– dissémination contrôlée ;
– accessibilité ad hoc (IHM et critères de recherche adaptés aux profils utilisateurs) ;
– sécurité bien prise en compte (sous tous ses aspects) / gestion des droits aisée ;
– conservation dans le temps ;
– …
Ensuite sur les règles métier et traitements divers sur les données, pour lesquelles on retrouve grosso modo les mêmes critères, avec des ajouts comme :
– la lisibilité des règles et traitements ;
– leur faculté d’adaptation rapide ;
– la possibilité de retour en arrière dans les versions, facile et sans régression ;
– les possibilités de simulation (à la fois pour le métier et l’informatique) ;
– …
Les processus sont rangés dans les règles et traitements.
La valeur intrinsèque est dépendante de la qualité des moyens utilisé pour supporter les données et les règles : sur ce point des concepts comme la contextualisation et l’agilité sont des critères essentiels.
Sous l’angle des moyens de production, la valeur intrinsèque dépend en particulier de la disponibilité et de la capacité à monter en puissance (la scalabilité).
La valeur intrinsèque est liée à l’avenir. Elle traduit la durabilité d’un SI, c’est-à-dire l’aptitude d’un SI à durer dans le temps, sans perte de qualité importante (ou, dit autrement, sans augmentation importante de sa dette technique)
Selon ces définitions, la valeur d’usage peut être élevée alors que la valeur intrinsèque est faible. Cette situation est le reflet d’un personnel IT compétent et efficace, mais mal équipé pour l’avenir. Les insuffisances sont à trouver du côté DSI.
A l’inverse, la valeur intrinsèque peut être élevée alors que la valeur d’usage est faible. Conclusion inverse : les solutions sont mal exploitées.
La valeur métier est l’indicateur par excellence de l’efficacité de la collaboration entre personnel métier et personnel informatique.
Très rapidement, il me semble aussi intéressant de mettre cette réflexion sur les différentes facettes de la valeur en relation avec deux autres notions souvent rencontrées : l’agilité et la simplicité.
Agilité et simplicité ne sont en fait que deux reflets de la valeur intrinsèque d’un SI.
J’en profite pour rappeler que la simplicité est conditionnée par la mise en application correcte des mécanismes de gestion de la complexité. Pour en citer quelques uns (je ne saurais être exhaustif) :
– composition / décomposition (partitionnement – notion de domaines fonctionnels , de blocs fonctionnels, de services );
– généralisation / spécialisation ;
– héritage (pour simplifier la maintenance et garantir la cohérence) ;
– typage des composants (pour mettre en place des critères de qualité et des règles d’interactions entre les types, …) ;
– hiérarchisation (identification de niveaux ou couches) ;
– réutilisation (conditionnée par l’agilité) ;
– autonomie des composants ;
– utilisation du concept d’interface (masquage de l’implémentation – effet black box) ;
– contrat sur les interfaces (pour réguler / contractualiser les modalités d’interaction entre composants) ;
– couplage faible (réduction des dépendances (techniques, sémantiques, … – communication par messages et de préférence en mode asynchrone entre les domaines et blocs fonctionnels) ;
– points de passages obligés pour faciliter les contrôles de différentes natures (validations, sécurité, …) ;
– déploiements multiples d’une même implémentation lorsque nécessaire (pour éviter les bottlenecks) ;
– contextualisation des composants (mais on retombe ici sur l’agilité) ;
– …
Postulat ? : un SI durable est (d’abord) simple et (ensuite) agile.
En guise de conclusion; quelques unes de mes convictions :
– La valeur intrinsèque est trop souvent négligée. Il faut y voir l’une des causes importantes du gonflement de la dette technique.
– Si la gestion de projet ne se préoccupe pas de la valeur intrinsèque, elle risque de mettre en place une exploitation sur le mode gestion de crise dans la durée, une fois le système en production. Avec toutes les conséquences attenantes sur lesquelles je ne m’étendrai pas ici.
– Négliger la valeur intrinsèque c’est le plus souvent hypothéquer le TCO.
Leave a Reply