Silo or not silo ?

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 ), 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 :

image

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) :

image

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 :

image

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 :

image

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 :

image

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 !

image

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 :

image

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).

image

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 :

image

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 :

image

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 ?

Posted in Uncategorized | Tagged | Leave a comment

Du NLP au programme, vraiment ?

Un retour sur un article qui m’a fait réagir : http://tcz.hu/the-future-of-programmers

L’idée est en gros de dire que la prochaine révolution industrielle va supprimer les métiers de docteurs et de conducteurs de véhicules, et que nous autres programmeurs seront les prochains, mais que nous aurons l’honneur de participer à cette destruction de métier en créant les logiciels qui vont nous remplacer.

L’auteur utilise ensuite comme illustration de son propos le fait qu’un programme est désormais capable d’analyser une règle métier écrite en texte, et de décomposer ce langage naturel en une arborescence de sujets, de conditions et d’actions. Il utilise pour cela un excellent exemple graphique, que je me permets de recopier de son article (source citée plus haut) :

nlp2.png

Jusque là, on est dans de la démonstration logique. Mais le saut à la conclusion est un peu abrupt : “How difficult is it to translate this into a computer program now?”. Ben, justement… c’est ça qui est difficile, et pas le reste. Parce que découper un texte correctement formaté en atomes reconnaissables et appliquer des actions dessus, c’est ce que font les moteurs de règles depuis 15 ans déjà !

Or, ce qui fait un “programme”, c’est justement tout ce qu’il y a autour et qui est incommensurablement plus difficile :

  • Tenir compte des règles non exprimées (tout client d’un éditeur de logiciel commence toujours par lui dire que son métier est simple… jusqu’à ce qu’on l’analyse ensemble et qu’il réalise que son métier est complexe, et qu’il ne lui apparait comme simple que parce que son expérience fait qu’il réalise inconsciemment 90% des tâches).
  • Tenir compte de règles floues.
  • Réfléchir au parcours ergonomique pour les utilisateurs.
  • Savoir régler les problèmes indirectement liés au programme : robustesse, sécurité, performance, etc.
  • Penser en termes holistiques, c’est-à-dire pas seulement au programme en lui-même comme silo étanche, mais en tant que bloc communiquant d’un Système d’Information. La valeur est désormais plus dans les interconnexions que dans les atomes du SI.

Au passage, c’est d’ailleurs pour cela qu’il est incomplet que dire que la data vaut de l’or : tant qu’elle reste dans son programme d’origine, elle n’en a pas, et n’en acquiert que lorsqu’elle est partagée, d’où l’importance économique de l’Open Data. Vous ne croyiez tout de même pas que l’Etat publiait de la donnée ouverte juste pour des raisons de transparence envers les citoyens ? Sourire

Bref, quand on me montrera un programme qui est capable d’analyser les conversations d’un comité de vingt personnes et d’en sortir une norme de communication informatique qui traite tous les cas d’usage évoqués, je reconnaitrai que le métier de développeur est mort. Mais je pense que je le serai bien avant…

Posted in Retours | Leave a comment

Hackathon ENI sur la sécurité

C’est suffisamment rare pour être souligné : un hackathon sur la sécurité. Si vous vous sentez des compétences de Ethical Hacking, l’ENI organise un hackathon sur le sujet les 29 et 30 septembre.

Détails et inscription sur http://www.editions-eni.fr/hackathon

image

Si le sujet ne suffit pas à vous motiver… le 1er du classement remportera plus de 7000€ de lots !

Posted in Uncategorized | Tagged | Leave a comment

Java, encore et toujours après la bataille

.NET a beau être né dix ans après Java, il reste depuis la version 2.0 systématiquement en avance sur lui. La gestion des lambda, les classes anonymes, la programmation fonctionnelle, les tâches, les délégués, etc. : à part l’injection de dépendances, il n’y avait pas un domaine du langage où .NET ne démontrait sa suprématie (bon, OK, j’exagère peut-être un peu juste pour taquiner Nico Sourire). Et encore, l’injection de dépendances avait tellement été mise à toutes les sauces avec Spring qu’il fallait presque faire une injection pour ajouter deux entiers.

Un article sur InfoWorld en date du 11 septembre 2015 annonce un effort d’Oracle pour rendre plus simple la gestion des dépendances et de la modularité en Java, et cet article entre en résonnance avec les multiples problèmes que je vois professionnellement autour de la gestion du CLASSPATH ainsi que des conteneurs OSGI. Tous ces problèmes sont réglés depuis longtemps en .NET grâce à NuGet, qui fait même désormais partie intégrante du nouveau SDK Core .NET.

Si l’on ajoute à ça que, de toute façon, avec l’avènement des conteneurs et des architectures à microservices, la modularité est désormais hissée au niveau du service lui-même (ce qui est le niveau de granularité idéal), on se rend compte qu’Oracle est encore en train d’apporter une solution avec Jigsaw à un problème qui n’en est désormais plus un. L’inconvénient d’avoir une gouvernance qui avance à la vitesse d’un escargot rhumatisant…

Pendant ce temps, du côté .NET, ça avance sur l’asynchronisme à tous les niveaux, les TypeProviders en F#, la compilation native, la structure modulaire non pas des dépendances mais carrément de la runtime, le calcul parallèle, etc. Java garde une tête d’avance pour ce qui est du nombre de projets utilisateurs, mais pour ce qui est de la richesse fonctionnelle, il y a du boulot pour rattraper .NET. Et il ne fait que peu de doute que le second critère est plus important que le premier.

Posted in Uncategorized | Tagged | Leave a comment

La roue tourne…

Assez drôle de voir qu’après tant d’années à moquer la concurrence, Apple se retrouve aujourd’hui à sortir un iPad Pro en réaction au succès grandissant de la Surface de Microsoft…

Et le coup du stylet désormais vanté après avoir été voué aux gémonies, rétrospectivement, ça fait quand même pas mal rire Sourire

Permalien de l'image intégrée

Posted in Uncategorized | 2 Comments

Hard Code d’Eric Brechner en français !

Ca y est : après des mois et des mois de problèmes administratifs, et donc plus d’un an après avoir fini de le traduire, le livre d’Eric Brechner traduit en français par mes soins est ENFIN disponible à la vente sur le site de Microsoft Press. La page n’est pas très explicite, car la couverture montrée est celle de la version originale, mais c’est bien la version française que vous y trouverez.

image

Eric Brechner est un manager de Microsoft dont la liberté de ton est reconnue et qui nous gratifie tous les mois d’un édito de grande qualité sur la façon de gérer une équipe informatique, sur son blog http://blogs.msdn.com/b/eric_brechner/.

Il se trouve que je suis tombé sur ce livre au moment où les besoins de mon entreprise ont fait que j’ai dû rajouter une corde “management” à mon arc, en plus de celle d’architecte logiciel. Et il s’est révélé une véritable mine. J’ai lu une bonne quinzaine d’autres livres sur le sujet, mais presque tous se trouvent résumés dans quelques articles de blogs d’Eric Brechner. Aujourd’hui, je me rends souvent compte que la façon dont je gère mon équipe est fortement influencée par telle ou telle expérience développée par Eric.

La quatrième de couverture, pour vous donner envie Sourire :

image

Enfin, un grand merci à mes relecteurs Clémence Chanel, Guillaume Collic et Olivier Dupont !

Et pour acheter (35,99 $), c’est ici : https://www.microsoftpressstore.com/store/i.m.-wrights-hard-code-a-decade-of-hard-won-lessons-9781509301201

Bonne lecture !

Posted in Veille | Tagged | 2 Comments

Livre sur Docker en approche

Mon dernier livre va bientôt être publié chez l’ENI. Le sujet est Docker et les microservices. J’ai essayé de faire un livre très pratique sur Docker, orienté développeurs, en montrant comment on peut créer une architecture de microservices où chaque service est contenu dans une image Docker, en faisant exprès d’utiliser plusieurs technos, pour montrer un peu toutes les astuces : JEE, .NET Core, Python et Node.JS sont au programme !

L’idée est de montrer une application de gestion de l’optimisation d’un emprunt, avec une interface, une persistance, un scheduler d’optimisation, un module d’optimisation d’emprunt, et un module de calcul parallélisable avec lien asynchrone. Tout ça est créé en mode microservices et avec des API pour montrer une architecture correctement urbanisée, qui est la cible idéale des développements Docker.

Rendez-vous sur le site des Editions ENI pour tous les détails… et les pré-commandes (Daddy needs an EV3) Sourire

image

Posted in Uncategorized | Tagged | Leave a comment

.NET sur Linux dans Docker sur cluster CoreOS dans Azure

Ca y est : la vidéo de notre session au TechDays avec Guillaume Collic est en ligne, sur https://techdays.microsoft.fr/programmes/2015/fiche-session.aspx?ID=50a5208e-fa8c-4dd1-a0bd-88a9a46577c6. Vous pouvez donc retrouver l’explication détaillée sur comment faire du .NET sur Linux de manière supportée par Microsoft dans un conteneur Docker, puis comment utiliser Azure pour monter un cluster de CoreOS dans lequel vous déploierez vos images Docker en mode load-balancé.

Le contenu est le même sur YouTube : https://www.youtube.com/watch?v=eY2l6c0cjZ4

image

Posted in Retours | Tagged | Leave a comment

ReBUILD : ça arrive bientôt !

Le 1er Octobre 2015, c’est l’évènement ReBUILD à Nantes Sourire

image

J’aurai le grand plaisir d’y présenter une conférence intitulée “Docker : déployer du .NET dans des micro-conteneurs isolés sous Linux et bientôt Windows”. Avec un peu de bol, ça tombera en même temps que la sortie de mon nouveau bouquin, justement sur Docker, aux Editions ENI comme souvent. Si vous vous demandez comment mettre en œuvre une architecture de micro-services avec Docker, je vous engage à jeter un coup d’œil sur ceci.

Pour ReBUILD, les préinscriptions sont ici.

Posted in Retours | Tagged | Leave a comment

L’agilité expliquée à mon banquier…

Des fois, c’est une bonne pratique d’essayer d’adopter un point de vue complètement différent, et le vocabulaire associé, pour mieux comprendre des concepts qu’on est (à peu près) capable d’expliquer avec son dialecte habituel. Du coup, au lieu de rester dans mon jargon informatique, je vais essayer d’expliquer l’agilité en termes financiers.

L’agilité – par rapport au traditionnel cycle en V où on conçoit quelque chose, puis on le fabrique, puis on le teste, puis on le vend – consiste à fournir un produit sous forme de petits incréments qui apportent de la valeur à chaque fois. Par exemple, un robot ménager avec dans un premier temps juste le moteur, le bol standard et le hachoir, qui est l’outil le plus utilisé. Ensuite, on pourra ajouter un blender pour la soupe, un autre outil pour râper, un autre pour faire des tranches, etc.

L’avantage est que l’investissement initial en R&D, production, stockage, vente et autres activités est alors moins élevé. Du coup, le retour sur investissement arrive beaucoup plus tôt :

image

Comment réussir à atteindre cet état financier enviable ? La solution principale a été rapidement abordée, à savoir réaliser des petits incréments. Mais imaginons maintenant que le robot soit vendu sans moteur, et que nous ayons ajouté les râpes, le blender et tout le bazar, mais toujours pas le moteur. Bref, le robot n’aurait que très peu de valeur pour un potentiel utilisateur. C’est pour cela que nous sommes plutôt parti d’une version minimale mais fonctionnelle, et que nous avons progressivement ajouté des items dont la valeur était moindre. L’idée de l’agilité et du Lean est de commencer systématiquement par les fonctionnalités qui ont le plus de valeur.

Dit comme ça, on pourrait se demander pourquoi ces idiots d’informaticiens (j’en suis) ne commencent pas par les fonctionnalités de plus haute valeur. Il se trouve que le métier étant relativement récent (quelques dizaines d’années, ce qui n’a pas permis une industrialisation pour l’instant), les équipes ont tendance à souvent réinventer la roue et mettre en place des fonctionnalités “de base” mais qui n’ont pas de valeur immédiate, avant de travailler sur le métier, puis seulement en fin de projet mettre en place une interface graphique pour piloter le tout. Or, le client a besoin de l’interface graphique. En fait, il ne voit même que ça et le reste est pour lui du blabla pur et simple…

Pour résumer, l’idée de l’agilité est de mettre le plus possible de valeur dans le produit en amont. Typiquement, là où dans une approche traditionnelle, peu de fonctionnalités sont accessibles à l’utilisateur (20% après consommation de 80% du budget), l’approche agile permet l’inverse du Pareto (80% de la valeur après avoir consommé 20% du budget). Il arrive d’ailleurs assez souvent en mode agile que le projet s’arrête avant la fin de la consommation du budget, car quasiment toute la valeur est atteinte. Si le projet est bien tenu, seules des fonctionnalités peu importantes restent à réaliser, et parfois le client préfère garder son reliquat de budget pour autre chose.

image

Si jamais des financiers lisent mon blog, je serais heureux de recueillir leur retour pour savoir si j’ai réussi à leur expliquer l’agilité Sourire.

Posted in Agile | Tagged | Leave a comment