Un système d’information est composé de logiciels fournissant des fonctions permettant d’exécuter les processus métiers nécessaires à l’activité de l’entreprise. Ces fonctions sont nombreuses, parfois redondantes, sans compter qu’une même fonction peut être remplie par plusieurs logiciels voire une seule fonction nécessiter la mise en oeuvre de plusieurs logiciels. Bref, tout cela est il vraiment nécessaire ? Et comme à la maison, n’y a- t-il pas du ménage de printemps qui pourrait être fait ?

De la quantité et de la pertinence des fonctions du SI

J’avais été surpris quand j’avais lu les chiffres de l’étude du Standish Group concernant l’utilisation des fonctions du SI :

Cette étude établit que presque la moitié, 45%, des fonctions d’un SI ne sont jamais utilisées. Nous pouvons débattre de ce chiffre, mais mon intuition me dit qu’il est vrai. Cela fait du consulting projet facile : je vous propose de réduire le coût d’un projet de moitié rien qu’en supprimant les fonctions inutiles ! Cela peut même être plus du fait du coût indirect quant à la complexité de cette moitié de code supplémentaire. L’impact sur la maintenance doit également être avéré même si je suis moins catégorique du fait que la maintenance corrective doit à priori être effectuée uniquement sur des fonctions réellement utilisées.

De la quantité et de la pertinence des applications du SI

Je suis également toujours surpris par la quantité importante de logiciels présents au sein des systèmes d’information, pour des raisons historiques mais avant tout organisationnelles, en application directe de la loi de Conway qui avance que l’architecture applicative d’un système d’information est le résultat de l’organisation humaine en place. En version originale :

…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations. Melvin Conway. 1968.

Lorsque j’étudie dans mes missions les applications et les liens entre ces applications, je retrouve bien souvent le miroir actuel ou passé de la séparation entre groupe de personnes différentes (équipe projet, département, sites géographiques, etc.). Ainsi, la composante sociale de l’entreprise est profondément enracinée dans le système d’information sans lien direct avec l’organisation actuelle et une architecture rationnelle et efficace.

J’ai assisté à la conférence de Richard Pawson à QCon London sur le succès de l’approche « Naked Object » expérimentée au sein du SI de l’administration irlandaise. Richard Pawson est le créateur de l’approche intitulée « Naked object« , qui emprunte de larges principes au Domain Driven Design. Ceux qui me connaissent savent je suis un grand promoteur du DDD, je vous conseille l’excellent ouvrage « Domain Driven Design with Naked Objects » sur cette combinaison. Cette approche promeut ainsi des applications toutes entièress construites autour des objets métiers, les trois principes sont :

  • Les objets métiers encapsulent toute la logique métier
  • L’interface utilisateur doit être une réprésentation directe des objets métiers, avec les actions utilisateurs consistant à créer, récupérer et invoquer les méthodes de ces objets (et pas de CRUD hein ! des vraies méthodes avec une signification métier qui font un changement d’état sur l’objet)
  • De ces deux principes découle le troisième qui est le fondement de l’approche : toute l’interface utilisateur est créée automatiquement à partir des objets métiers

Pourquoi parler de cette approche par rapport à la profusion d’applications dans les SI d’entreprises ? Tout simplement parce qu’avec cette approche unifiée, le SI de l’administration irlandaise n’est constitué que…d’une seule application déployée ! Les bénéfices sont nombreux en termes de coût de gestion et d’intégration.

Devant cette profusion de fonctions et d’applications construite de manière empirique, la culture du minimalisme doit s’imposer !

Michael Feathers propose la même chose pour le code : supprimer automatiquement des lignes de code afin d’en réduire la quantité. Et je suis d’accord avec lui pour affirmer que le code et les applications représentent un stock et donc plus il y en a et plus cela coûte, en même temps, et c’est le paradoxe, le système d’information représente un actif immatériel pour l’entreprise.

Conclusion

La suppression des fonctions et des applications devrait être des activités réalisées fréquemment pour viser la simplification du système d’information et diminuer ainsi le coût d’exploitation du système d’information tout en le recentrant sur l’essentiel : le coeur du  domaine.

Commentaire

  1. Il serait intéressant de connaître le périmètre de l’étude !

    * Fonctionnel : Autant les chiffres me semblent cohérents dans un SI équipé de progiciels (tout n’est pas destiné à servir) ou dans des structures développant à partir de frameworks, autant il me semble exagéré d’imaginer que 45 % des fonctionnalités développées spécifiquement sur un projet restent inutilisées ;

    * Temporel : Les fonctionnalités inutilisées le sont elles depuis toujours ? Ne sont elles pas à conserver pour traiter les données de l’historique ? Auquel cas, il n’y a pas d’économie projet, mais une charge de « ménage » à prévoir (maintenance, évolution des jeux d’essais pour trancher le périmètre de non-régression, gestion de configuration pour conserver les outils en phase avec les données historisées …) ;

    Enfin, même si je suis en accord avec l’analyse de Michael Feathers, il me semble que comptablement le stock est bien un actif. Les opérations envisagées de « nettoyage » s’apparentent donc à des sorties de stock pour obsolescence et mesurent donc la cohérence de la production par rapport à la demande.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Voir plus
scroll to top