[chapo]Même si le buzz commence à s’estomper, les microservices sont encore sur le devant de la scène. Pourtant, à nos yeux, un sujet n’a pas encore été vraiment abordé : comment faire travailler les architectes d’entreprise/urbanistes avec les projets microservices ? Une question légitime : ces deux mondes sont bien distincts, l’un travaillant souvent sur les vieux systèmes legacy, l’autre sur les projets dits digitaux de l’entreprise. Pourquoi ces deux mondes vont-ils avoir besoin d’échanger ? Quelles différences culturelles et méthodologiques vont-ils devoir dépasser ? Pourquoi ont-ils intérêt à travailler main dans la main ?[/chapo]
Pourquoi se faire rencontrer ces deux mondes ?
C’est un fait : ces deux mondes vont tôt ou tard se rencontrer. Pour une raison simple : si beaucoup de ces projets microservices sont le fruit des initiatives des « directeurs du digital » et autres CDO, tôt ou tard, ils doivent s’intégrer au reste du SI. Une nouvelle offre « Digital » ne peut pas éternellement faire comme si le reste du SI n’existait pas, car elle a besoin de réutiliser les briques déjà existantes, ou de « repackager » les offres business existantes vivant dans le monde Legacy. Tôt ou tard, il faut donc partager et échanger. À défaut, l’industrialisation de toutes ces nouvelles offres business ne peut se faire. Le gain est donc réel et très quantifiable, encore faut-il bien évidemment l’expliquer et le partager, car le risque d’incompréhension est grand.
En quoi s’opposent-ils ?
Soyons franc, la rencontre de ces deux mondes est difficile à orchestrer sans heurt. Quatre différences culturelles majeures les distinguent :
-
Une différence de méthode
Une approche générale très bottom-up pour ces projets microservices, où ce sont les développeurs qui ont défini les manières de travailler avec les métiers, quand l’approche d’architecture d’entreprise est très orientée top-down. L’architecte d’entreprise doit donc travailler beaucoup plus de concert avec les équipes de développement et apprendre à leur contact leurs méthodologies.
-
Une différence de tempo
Quand les projets microservices sont très souvent en agile, et sont capables potentiellement de délivrer tous les jours en production, les architectes d’entreprise peuvent facilement travailler sur des cycles de six mois minimum. Un bon tempo et une bonne synchronisation est donc à trouver, sans freiner ni dégrader le travail de chacun.
-
Une différence de vocabulaire
Le vocabulaire de ces deux parties est rempli de faux amis. Par exemple, les termes de processus, composant et de service tirent leur propre définition du monde du développement et des systèmes d’exploitation. Attention donc à bien se comprendre, et à expliciter exemples et documentation pour s’assurer de la compréhension mutuelle.
-
Une perspective différente pour « l’architecture »
Quand l’architecture d’entreprise cherche à intégrer, et à partager, les architectures microservices désintègrent et explosent les données et les processus.
Dernière remarque : il ne faut pas se baser entièrement sur les livres tournant autour des microservices. Non pas qu’ils soient inintéressants et inutiles, bien au contraire, mais rien ne vous dit que les grands dogmes ont tous été respectés. Ayez-les en tête, mais ne les prenez pas pour argent comptant. Et si vous cherchez un livre pour commencer, on ne saurait mieux vous conseiller ce livre.
Alors comment faire travailler ces deux mondes ?
Selon nous, la première étape est de faire preuve d’une grande humilité réciproque, et de multiplier les rencontres, afin déjà d’être capable de répondre aux questions suivantes :
-
Comment se décompose l’organisation du projet ?
Sachant qu’on peut avoir des architectes transverses entre x projets microservices, dont le travail commence justement à ressembler à un travail d’architecte d’entreprise…
-
Comment travaillez-vous avec les métiers ?
Bon nombre de projets microservices reposent sur la méthodologie du Domain Driven Design, qui apporte entre autres sa capacité à modéliser le domaine dans ce qu’on appelle le langage omniprésent (ou ubiquitous language si votre interlocuteur ne traduit jamais ce qu’il lit). Je vous conseille d’ailleurs chaudement la lecture de ce livre, très simple et très synthétique.
Après avoir répondu à ces questions, il faut que chacun trouve sa place. Pas simple, car l’architecte d’entreprise est tenté de penser qu’il est en haut de la « hiérarchie », alors que la mise en place d’une telle organisation risque soit de l’embarquer dans une charge de travail lourde, soit de freiner les projets. Il faut donc assumer que ces deux mondes travaillent sur des échelles de temps différentes.
Et par quoi commencer pour se lancer ?
Pour répondre à ces questions et dépasser les clivages, une piste doit être sérieusement creusée : celle de ce fameux langage omniprésent, qui potentiellement est une vue du modèle métier d’entreprise. Ce langage omniprésent ne représente pas forcément tous les objets métier et peut être implémenté de manière différente dans le code. Il représente donc un premier chantier à lancer, afin que l’accostage avec le modèle métier se fasse, mais également pour définir qui a le droit de modifier l’autre.
Faut-t-il être bottom up ou top down justement ? Faire un tableau d’équivalence ? Notre choix spontanément se porterait plutôt sur des va-et-vient dans les deux sens, mais à chacun de juger en fonction de son contexte. Enfin, n’oublions pas la question de l’outillage et de son éventuelle capacité d’automatisation et de publication des modèles de données représentées par les deux équipes. Une bonne compréhension et un bon outillage peut grandement faciliter les échanges, mais attention : à date aucune application de modélisation ne va vous aider spontanément…
Ce travail n’est évidemment qu’une première étape mais les gains, bien tangibles, peuvent être observés rapidement ! Les architectes d’entreprise devront se rapprochent encore davantage des équipes de développement qui, elles-mêmes, devront faire un effort de compréhension du rôle de cet architecte d’entreprise. Clé de la réussite : l’humilité et la bienveillance, pour apaiser les tensions et incompréhensions. Car, c’est une certitude, ces deux équipes ont beaucoup à gagner à travailler main dans la main !
Thomas JARDINET – Publié le 29 Mai 2017
