Blog de JP Gouigoux

Après avoir lu de nombreux articles sur les problèmes des silos dans l’informatique (je ne vais pas faire la liste) ainsi qu’un article très intéressant car prenant à rebrousse-poil les précédents (article d’Hank Marquis) et quelques commentaires associés (ici et là), je vais essayer d’apporter mon humble pierre à l’édifice, en tentant de formaliser QUAND les silos sont mauvais et QUAND ils ont du bon.

L’idée est d’appuyer l’opinion d’Hank Marquis avec des retours d’expérience, et de participer ainsi à contredire les Docteur Follamour de l’architecture informatique qui pensent que détruire un SI pour le reconstruire “proprement” est une hypothèse envisageable dans la vraie vie.

Le bon silo et le mauvais silo

Les silos sont bons quand ils séparent des applications informatiques qui n’ont rien à voir, par exemple une application de gestion de fabrication et une application de paie :

Inutile en effet de mélanger les choux et les carottes : une étanchéité “physique” permettra de ne pas risquer que les problèmes de l’un n’affecte l’autre (ex : plus de place sur un serveur de base de données commun, ou un changement de version des documents générés pour la bureautique, j’en passe et des meilleurs)

Les silos sont mauvais lorsqu’ils conduisent à de la duplication de données, par exemple si une application gère des bénéficiaires de subventions et l’autre des destinataires de courriers, car il y a de bonnes chances que ce soient des mêmes personnes qu’ils s’agissent (même si chaque application aura bien sûr ses spécificités de traitement des personnes, voire ses propres données complémentaires) :

Les problèmes sont là aussi multiples : duplication des commandes de modification des enregistrements, risque de ne pas avoir la même adresse pour le même tiers dans les deux silos, etc. La duplication des données dans les SI industriels est une des principales causes de perte économique.

Première approche d’interop

La réponse des EAI et ETL étaient de relier les silos par des mécanismes informatiques d’échange de données automatisés. Cela fonctionne assez bien quand il n’y a que deux ou trois silos avec des formats différents :

Mais les EAI posent le problème d’un Single Point Of Failure (en tant que point central, s’il dysfonctionne, tout le système est hors service). De plus, passé 4 à 5 silos échangeant de la donnée, on perd plus de temps à synchroniser techniquement qu’à travailler réellement sur le métier des applications, et on recrée dans l’EAI le plat de spaghetti dont on cherchait à se débarrasser dans le SI :

Approche d’interop plus moderne

La solution est de passer à des architectures orientés services, et de ressortir dans notre exemple un référentiel des personnes :

Mais, et j’en reviens à l’article de Hank Marquis, en mettant en place ce référentiel, il est important qu’il soit complètement autonome et le plus indépendant possible des autres métiers qui le consomment… bref que lui-même se comporte comme un silo !

Et là normalement, vous me dites que je suis en train de me contredire car on retombe sur de l’EAI, avec des transformations dans tous les sens. En fait, non, car il y a le second effet kisskool : la centralisation, si elle est accompagnée d’une normalisation des échanges, permet de ne placer des connecteurs de médiation que sur les logiciels ne la supportant pas encore, et d’avoir une grammaire commune pour chaque entité du SI :

C’est typiquement dans ce cadre que des approches de type ESB s’épanouissent : connecteurs de médiation au standard Entreprise Integration Pattern, asynchronisme pour lisser les effets de la centralisation sur la performance, robustesse de livraison des messages pour contrebalancer la complexité dûe à l’augmentation des acteurs sont trois des responsabilités d’un bon ESB. Et un bon ESB est un allié précieux dans la mise en œuvre d’une architecture SOA, même s’il est appelé à s’effacer progressivement devant des API web standards (architecture WOA).

Attention aux cas particuliers

Est-ce à dire que tout doit être découpé et que chaque silo doit communiquer avec les autres ? Comme d’habitude, tout est affaire de juste mesure, et il y a des cas particulier. Imaginons par exemple le cas d’un SI RH. Il existe effectivement un peu de redondance entre les personnes en tant que salariés et les personnes en tant que bénéficiaires d’une bourse, par exemple leur patronyme ou leur adresse :

Et pourtant, est-ce que cela a du sens de dire que les agents d’une collectivité qui attribue des bourses doivent pouvoir espionner le salaire de leur collègue parce qu’il a demandé une bourse pour son enfant ? Bien évidemment que non. Si on creuse un peu plus ce concept de personne, nous nous rendons compte que les deux applications ne traitent pas réellement de la même chose. La gestion de bourses traite des personnes en tant que bénéficiaires (l’élève ou l’étudiant) ou mandataire (ses parents ou tuteurs qui reçoivent l’argent tant que le bénéficiaire n’est pas majeur), tandis que la gestion de paie traite des personnes en tant que salariés :

L’enseignement de ceci est qu’il est essentiel pour atteindre une bonne décomposition informatique des services d’avoir approfondi fortement la conceptualisation du métier. Par expérience professionnelle, je peux citer plusieurs cas où un défaut de conceptualisation a amené à des modifications d’applications se comptant en dizaines, voire centaines, de jours hommes. Juste pour donner une idée du niveau nécessaire à atteindre, continuons justement sur les “personnes”. Un concept que tout un chacun comprend, car il appartient à notre vie de tous les jours. Pourtant, sauriez-vous clairement définir la différence conceptuelle entre un individu, une personne, un tiers moral ou un tiers physique ?

Bref, comme toujours en informatique, on en revient à la compréhension du domaine métier. C’est le principe du Domain Driven Design de baser la conception informatique sur une grammaire partagée et décrivant de manière non ambigüe le métier ciblé. Souvent, cette compréhension du métier passe par son expression la plus pure, à savoir la loi. Pour l’exemple ci-dessus, c’est la règlementation qui donnera les règles de gestion des tiers (un exemple parmi tant d’autres : un tiers peut être moral et physique à la fois lorsqu’il agit en tant qu’auto-entrepreneur). Et pour revenir à la gestion des bourses, la loi dit que l’attributeur d’une bourse a droit de connaitre les ressources financières du demandeur. Evidemment, cela donne une idée du salaire du demandeur (ou du tuteur éventuel), mais ces deux informations restent conceptuellement différentes, et il n’y a donc pas de problème à garder la seconde dans un silo étanche, hors de portée de l’attributeur.

Conclusion

Ce ne sont pas les silos qui posent problème en soi. Comme dit Hank Marquis, l’étanchéité et la claire séparation des responsabilités sont des points importants. Le problème apparait lorsque les silos doivent communiquer. La première approche, trop rustique, consistant à détruire les silos, revient à jeter le bébé (la séparation des responsabilités) avec l’eau du bain (la difficulté à faire interopérer). Il faut, pour garder les deux avantages, faire l’effort de contractualiser les échanges entre les silos. Ainsi, chacun reste indépendant, tout en évitant la duplication de données qui est un problème aussi important que le manque de séparation claire des responsabilités.

Au final, si vous êtes architecte SI, ne vous imaginez pas qu’une architecture SOA relève de la technique et des services web ou de la conception technique d’API. Au contraire, votre travail principal pour atteindre une architecture de services propres est de travailler sur les contrats d’interopération. Pour cela, les normes (iCal, vCard, ebXML, CMIS, et des centaines d’autres) sont à votre disposition et en leur absence, votre boulot principal est de décrire précisément le métier ainsi que de contractualiser sa représentation technique, à savoir un format qui servira de pivot dans tous le SI.

Votre meilleur allié pour cette tâche de conceptualisation et de standardisation est l’approche Domain Driven Design avec son concept de Bounded Context, et en particulier le bouquin fondamental d’Evans.

Un bonus, et une question

Un cadeau pour finir : la vidéo de la présentation de DDD par Eric Evans sur InfoQ. Et une question pour alimenter le débat (et les commentaires) : pour vous, la notion de Bounded Context est-elle assimilable à celle de silo dans le cas d’une architecture microservices, où tous les silos ont été découpés au maximum du raisonnable pour le métier ?