L’architecture MACH, de par son acronyme, regroupe quatre pratiques courantes et actuelles dans le développement d’applications web.
C’est quoi Architecture MACH ?
Dans ce premier volet, nous allons nous concentrer sur les concepts fondamentaux qui composent ce concept : Microservices, API First, Cloud First, Headless, afin d’adresser l’objectif de chacun.
Tout d’abord un avis personnel, le fait de mettre ces concepts ensemble découle du bon sens : ce type d’architecture est considéré comme simple, efficace, intuitive, bien structurée, modularisée, bref… un travail que les vrais architectes doivent forcément apprécier !
Quid d’Amazon annonçant faire marche arrière pour Prime Video car la mise en application des micro-services implique un nombre d’orchestrations élevées ?
Les Micro-services, tels qu’expliqués dans d’autres articles (voir article micro-services), sont dans notre vision très fortement liés à un découpage DDD (Domain Driven Design).
Dans notre conception un micro-service définit un composant, dérivé d’un découpage métier et fonctionnel, agissant sur une donnée définie.
Le micro-service ne se limite pas uniquement à la partie back-end. Dans un contexte d’architecture web, il peut s’appliquer également au front-end.
Le Micro front-end et le Micro back-end se retrouvent intimement liés par une logique “composant d’affichage” et “composant qui traite applicativement la donnée affichée”.
Une architecture micro-services implique donc une certaine verticalité affichage, traitement et data.
API-First
C’est presque logique, on fait communiquer les différents composants par APIs.
Être API-first signifie d’intégrer la conception des APIs au cœur du processus de conception globale de l’application. Un peu comme si les APIs étaient le produit final.
Attention par contre, autant nous allons retenir l’API entre micro front end et micro back end, autant ce principe n’est pas partagé avec la communication entre le micro-service et d’autres composants du SI.
Une étude des différents patterns d’échange et un choix judicieux entre des méthodes synchrones et asynchrones est très importante pour éviter de mettre des contraintes fortes là où nous n’en avons pas besoin : pour partager une donnée avec les applications back office, tels qu’une confirmation de prise de commande avec un SAP, nous n’avons pas toujours besoin de désigner des flux synchrones ou API, nous pouvons par exemple découpler avec une logique de messaging, le cas d’usage nous le dira !
Cloud-First
Une vraie prédilection pour le Cloud, que du buzzword ?
En réalité, le fait de mettre en avant du Cloud dans cette démarche n’est que du bon sens.
Nous pouvons mettre en place une architecture on premise, pourquoi pas, mais dans certains cas il s’agit d’un vrai challenge : mise en place des serveurs, déploiement de la couche OS, des services, de la partie VM ou Container, etc.
Le Cloud First des architecture MACH vise la puissance des services managés, rapides de déploiement, scalables et élastiques, sur lesquels le déploiement en serverless ou en conteneur et la mise en place des chaînes CI/CD sont en pratique les seules choses à maîtriser, le reste étant fourni dans le package des fournisseurs de services cloud !
HEADLESS
Le Headless représente une tendance croissante dans le développement web et mobile. Cette approche met l’accent sur la séparation entre la couche de présentation, ou « front-end », et la logique métier, ou « back-end ». Cette séparation permet une plus grande flexibilité dans la manière dont le contenu est présenté et consommé. Elle offre ainsi une liberté de création sans précédent aux concepteurs d’expérience utilisateur et aux développeurs front-end.
Dans un contexte Headless, les front-ends peuvent être développés de manière indépendante. Les développeurs peuvent utiliser les meilleures technologies adaptées à chaque plateforme. Cela s’applique au web, aux applications mobiles, aux assistants vocaux, et à tout autre dispositif connecté. Cette approche favorise une innovation rapide. Cela permet aux entreprises de déployer ou de mettre à jour leurs interfaces utilisateur sans avoir à toucher à la logique métier sous-jacente.
La question qui nous vient à l’esprit maintenant est :
Ce type d’architecture s’applique à tout cas d’usage ? Certains sont plus réceptifs que d’autres de par leur configuration, gestion du parcours utilisateur ?
Un exemple dans le prochain épisode !
Articles qui pourraient vous intéresser
Un guide des bonnes pratiques d’Architecture pour le Numérique Durable: pourquoi faire ?
Un guide des bonnes pratiques d’architecture pour le Numérique Durable : pourquoi faire?
23 mai 2024
Architecture
Olivier Constant
Senior Manager Architecture
Le Numérique Durable ou Responsable est en plein essor. Des guides sont sortis récemment et proposent divers outils.
A notre niveau de cabinet de conseil et d’architecture des SI, il nous paraît indispensable d’ajouter notre pierre à cet édifice. D’autant que les précités n’ont pas tout dit…
Le Numérique Durable: pourquoi faire ?
On le dit et le redit et c’est bien le sous titre de notre travail : L’architecture est “Green by design”. En effet, depuis longtemps les architectes construisent des SI solides, non redondants donc sobres en fait…
Sans compter le temps passé à challenger les métiers sur leurs besoins. Et à éviter les travaux inutiles… Faire et défaire c’est du travail inutile et si on peut éviter c’est toujours ça d’économisé…
4 grands thèmes qui ne sont pas propres à l’architecture
Nous avons voulu que notre travail puisse être adapté en tant que guide à beaucoup d’expertise en plus de l’architecture :
Gouverner et former : qu’est ce que votre expertise / discipline / domaine de compétences peut mettre en place dans sa gouvernance et dans la formation des personnes pour intégrer les dimensions de responsable et de durable ?
Mesurer et montrer : que va-t-on pouvoir mesurer dans votre discipline et quels résultats va-t-on pouvoir montrer ?
Challenger : quels sont les thèmes ou autres domaines sur lesquels vous allez pouvoir challenger pour aller vers la diffusion des bonnes pratiques ?
Concevoir : quelles sont les bonnes pratiques lors de vos travaux de conception qui peuvent permettre d’aller vers plus de durabilité ?
Les architectes au coeur du Système d’Information
Le travail des architectes est on le rappelle ci-dessous :
L’Architecture d’Entreprise organise le dialogue entre les différents corps de métier pour définir une vision commune de l’entreprise de demain et de son SI, ainsi que la trajectoire pour y parvenir. Elle met en œuvre les approches nécessaires pour assurer la connaissance, la gouvernance et le pilotage opérationnel du SI.
A ce titre, les architectes sont au coeur des SI et des transformations et doivent donc jouer un rôle d’influenceur dans la direction du Numérique Durable. Ce guide est là pour fournir des clés à cette population particulière.
Impulsées par l’avènement du Cloud et du DevOps, les mouvances “as Code” et “Software Defined X” ont grandement amélioré la gestion du cycle de vie des assets informatiques (infrastructure, middleware, serveur d’application, …) avec principalement :
L’Infrastructure as Code (IaC),
La Configuration as Code,
Nous détaillerons dans un futur article le positionnement de chacun et les grands paradigmes en présence (procédurale vs déclaratif), qui reposent sur une caractéristique commune: l’utilisation de template/playbook au format normalisé (HCL, YAML, …) décrivant l’état final à atteindre ou le moyen d’y aller.
Même si la syntaxe est Human Readable, il peut être fastidieux à l’échelle d’un SI enperpétuelle évolution d’écrire et de mettre à jour ces fichiers de description.
Bien qu’il existe de plus en plus de plateformes simplifiant la création de ceux-ci sur base de conception visuelle en LowCode/NoCode ou de schématisation…Que diriez-vous de troquer d’un point de vue utilisateur le ”as Code” par du ‘as Prompt” ?
#GenAI à la rescousse
Le terrain de jeux des Large Language Models (LLM) et de la GenAI ne cesse de croître, en n’oubliant pas au passage l’ingénierie logicielle.
Imaginez pouvoir simplement demander “Provisionne un cluster de VM EC2 avec NGINX en exposition publique ainsi qu’une base Elasticache” pour voir votre souhait exaucé instantanément.
D’ailleurs, n’imaginez plus, car l’Infrastructure as Prompt (IaP) est déjà proposée par Pulumi AI, et bien d’autres en cours (depX) ou à venir.
Ce positionnement et les avancées rapides et significatives dans ce domaine ne sont pas étonnantes car nous sommes en plein dans le domaine de prédilection des LLMs: les langages.
Qu’ils s’agissent de langages parlés (Français, Anglais, …), de langages de programmation (Python, JavaScript, Rust), de langage de description (HCL, YAML, …), ils ont tous deux concepts fondamentaux:
Un dictionnaire, un vocabulaire, une liste de mots avec une (plusieurs) signification(s) connue(s),
Une grammaire et des règles syntaxiques plus ou moins strictes donnant un sens particulier à la suite de mots d’une phrase ou d’une ligne de fichier de configuration.
Plus le dictionnaire et la grammaire d’un langage sont dépourvus d’ambiguïtés, plus le degré de maturité et la mise en application de la GenAI et des LLMs sur celui-ci peut-être rapide.
L’Infrastructure as Prompt n’est pas une rupture totale avec le “as Code”, simplement une modernisation de l’interface “Homme-Clavier”.
En effet, peu importe le moyen (création manuelle, auto-génération via prompt) l’aboutissement de cette première étape est la disponibilité du fichier de description.
Le cœur du réacteur, à savoir la traduction du <fichier de conf> en actions pour <provisionner et configurer les ressources>, est toujours nécessaire.
A l’avenir elle pourra se révéler un parfait assistant pour faire des recommandations et propositions d’ajustement vis-a-vis de la demande initiale pour optimiser l’architecture à déployer:
Prioriser les services managés,
Prioriser le serverless,
Etre compliant avec les best practices des frameworks d’architecture des Clouders (AWS Well Architected Framework, …),
Security By Design,
RIght sizing de l’infrastructure,
Opter pour des ressources ayant une empreinte carbone et environnementale optimisées.
#La confiance n’exclut pas le contrôle
Bien que la baguette magique qu’apporte cette surcouche soit alléchante, nous ne pouvons qu’abonder les paroles de Benjamin Bayard dans son interview Thinkerview Intelligence artificielle, bullsh*t, pipotron ? (25min) : “tous les systèmes de production de contenus si ce n’est pas à destination d’un spécialiste du domaine qui va relire le truc, c’est dangereux.” Dans un avenir proche l’Infrastructure as Prompt // la Configuration as Prompt n’est pas à mettre dans les mains de Madame Michu (que nous respectons par ailleurs) qui ne saura pas vérifier et corriger le contenu de Provisioning, de Configuration ou de Change qui a été automatiquement généré. Nous vous laissons imaginer les effets de bords potentiels en cas de mauvaise configuration (impact production, impact financier, …) dont le responsable ne serait autre que la Personne ayant validé le déploiement. Impossible de se dédouaner avec un sinistre “c’est de la faute du as Prompt”.
Vous l’avez compris, la déferlante LLM et GenAI continue de gagner du terrain dans l’IT, le potentiel est énorme mais ne remplace en rien la nécessité d’avoir des experts du domaine. Le “as Prompt” se révèle être un énorme accélérateur pour l’apprentissage du sujet, ou dans le quotidien de l’expert .. qui devra avoir une recrudescence de prudence quant aux configurations qui ont été automatiquement générées.
Articles qui pourraient vous intéresser
Service Mesh/Event Mesh/Data Mesh – Rien à voir, mais tellement proche !
Service Mesh/Event Mesh/Data Mesh - Rien à voir, mais tellement proche !
J’ai pu constater régulièrement que beaucoup de gens s’emmêlent les pinceaux quand il est question de définir et d’expliquer les différences entre Service Mesh, Event Mesh et Data Mesh.
Ces trois concepts, au-delà de l’utilisation du mot “Mesh”, n’ont pas grand chose de semblable. Quand d’un côté, nous avons :
Le Service Mesh qui est un pattern technique pour les microservices, qui se matérialise par la mise en place d’une plateforme qui aide les applications en ligne à mieux communiquer entre elles de manière fiable, sécurisée et efficace
L’Event Mesh, qui est un pattern technique d’échanges, afin de désiloter les différentes technologies de messaging
Et le Data Mesh qui lui, est un pattern général d’architecture de données, qui se matérialise par toute une série d’outils à mettre en place, et qui pousse le sujet de la productification de la donnée
On se dit déjà que comparer ces trois patterns ne fait pas sens ! Néanmoins, il y a peut-être un petit quelque chose, une évidence naturelle, qui peut découler de la comparaison.
Mais commençons donc d’abord par présenter nos trois protagonistes !
Le Service Mesh, ou la re-centralisation des fonctions régaliennes des microservices
Historiquement, l’approche microservice a été motivée, entre autres, par cette passion que nous autres informaticiens avons souvent, pour la décentralisation. Adieu horrible monolithe qui centralise tout, avec autant d’impacts que de nouvelles lignes de code, impossible à scaler en fonction des besoins fonctionnels réels. Sans compter qu’on peut quasiment avoir autant d’équipes de développement que de microservices ! A nous la scalabilité organisationnelle !
Cela a abouti, de manière simplifiée bien sûr, au schéma suivant :
Chaque microservice discute avec le micro service de son choix, indépendamment de toute considération. La liberté en somme ! Mais en y regardant de plus près, on voit bien une sous-brique qui est TRÈS commune à tous les microservices, ce que j’appelle ici la “Technical Logic”. Cette partie commune s’occupe des points suivants :
La découverte de services
La gestion du trafic
La gestion de tolérance aux pannes
La sécurité
Or quel intérêt à “exploser” cette partie en autant de microservices développés? Ne serait-ce pas plutôt une horreur à gérer en cas de mise à jour de cette partie? Et nous, les microserviciens (désolé pour le néologisme…), ne serions nous pas contradictoire dans nos souhaits de décentralisation? Oui! Car autant avoir une/des équipes dédiées à cette partie, qui travaillerait un peu de manière décentralisée, mais tout en centralisant sur elle-même ce point?
C’est ainsi qu’est apparu le pattern de Service Mesh, décrit dans le schéma suivant :
Dans ce pattern, les fonctions techniques sont définies de manière centralisée (Control Plane), mais déployées de manière décentralisée (Data Plane) afin de toujours plus découpler au final son architecture. Et cela se matérialise par des plateformes comme Consul ou Istio, mais aussi tout un tas d’autres plus ou moins compatibles avec votre clouder, voire propres à votre clouder.
Maintenant que nous avons apporté un premier niveau de définition pour le service mesh, allons donc voir du côté de l’Event Mesh !
L’Event Mesh, ou la re-centralisation pour désiloter
L’histoire informatique a eu l’occasion de voir tout un ensemble de solutions de messaging différentes, avec des origines différentes. Qu’on retourne à l’époque des mainframes, ou qu’on regarde de côté des technologies comme Kafka qui ont “nourri” les plateformes Big Data, les solutions se sont multipliées. Et c’est sans compter le fait de faire du messaging par dessus du http!
On obtient donc assez facilement des silos applicatifs qui sont freinés dans leur capacité à échanger, comme montré sur le schéma suivant :
Certes, les solutions de bridge existaient, mais elles permettaient souvent de faire le pont entre seulement deux technologies en même temps, le tout avec des difficultés à la configuration et l’exploitation.
Et si on rajoute le fait qu’un certain nombre d’entreprises se sont dit qu’il serait intéressant d’utiliser les technologies propriétaires de chacun de leurs clouders, on imagine bien les difficultés auxquelles elles font face.
Est donc apparu le pattern Event Mesh, imaginé entre autre, implémenté et popularisé par l’éditeur Solace, qui permet de centraliser sur une solution unique, capable entre autres d’avoir des “agents” locaux aux SI (selon la zone réseau, le datacenter, le clouder, le domaine métier, etc…). Digression mise à part, on notera que le terme Event Mesh a été repris aussi bien par le Gartner que par des solutions open-source.
Indépendamment des architectures de déploiement, cela nous donne l’architecture simplifiée suivante :
Son intérêt vient qu’on peut ainsi relier tout le monde, y compris du Kafka avec du JMS, ou avec des API.
Le Data Mesh, décentralisation ou relocalisation des compétences ?
Le Data Mesh, de son côté, vient de son côté en réaction d’une précédente architecture très centralisée, faite de Data Lake, de Datawarehouse, de compétences BI, d’intégration via ETL ou messaging, le tout géré de manière très centralisée.
En effet, il était coutume de dire que c’est à une même équipe de gérer tous ces points, faisant d’eux des spécialistes de la data certes, mais surtout des grands généralistes de la connaissance de la data. Comment faire pour être un expert de la donnée client, de la donnée RH, de la donnée logistique, tout en étant un expert aussi en BI et en intégration de la donnée?
Ce paradigme d’une culture centralisatrice, a du coup amené un certain nombre de grosses équipes Data à splitter leur compétences, créant toujours plus de silos de compétences. De l’autre côté, les petites équipes pouvaient devenir très tributaires des connaissances des sachants métiers. Si cela vous rappelle les affres de la bureaucratie, ce serait évidemment pur hasard!
Ci-joint une représentation simplifiée de l’architecture dont nous avons pu hériter :
C’est ainsi qu’est apparu le pattern Data Mesh. Dans ce pattern, ce sont aux équipes Domaine de :
Collecter, stocker, qualifier et distribuer les données
Productifier la donnée pour qu’elle ait du sens à tous
Fédérer les données
Exposer des données de manière normée
Ce qui impose en l’occurrence de :
Mettre en place un self-service de données
Participer activement à la gouvernance globale
Et d’avoir un nouveau rôle de Data Engineer, qui doit mettre en place la plateforme de données pour justement faciliter techniquement, et proposer des outils.
Nous avons donc en schéma d’architecture le suivant :
Mais alors quid des points communs ?
Et en réalité, le gros point commun de ces trois patterns, c’est leur histoire !
Les trois proviennent de cette même logique centralisatrice, et les trois cherchent à éviter les affres d’une décentralisation dogmatique. A quoi cela sert de décentraliser ce que tout le monde doit faire, qui est compliqué, et qui en vrai n’intéresse pas tout le monde?
Et à quoi cela sert de forcément tout vouloir centraliser, alors même que les compétences/appétences/expertises/spécialisations sont elles-même “explosées” en plusieurs personnes ?
Certes, la centralisation peut avoir comme intérêt de mettre tout le monde autour de la même table, ce qui peut être intéressant pour de gros projets qui ne vivront pas, ou quand on est dans des phases d’une maturité exploratoire…
Et cela pousse tout un ensemble de principes, dont entre autre (liste non exhaustive):
Découvrabilité : Il faut pouvoir retrouver les services et les données simplement, en les exposants via des « registry » dédiés simples d’accès
Flexibilité et évolutivité : Il faut qu’une modification dans l’infrastructure ou dans un domaine puisse être accueilli sans douleur
Sécurité : Les politiques de sécurité sont propres aux champs d’actions de ces patterns, et sont donc inclus dans ces patterns
Distribution et autonomie : On distribue les responsabilités, les droits et les devoirs, afin de construire un système robuste organisationnellement
Alors oui, je vous entend marmonner “Et oui, c’est toujours la même chose! C’est comme ça”.
Mais en fait pas forcément ! En ayant en tête :
Ces éternels mouvements de yoyo,
Le Domain Driven Design qui est aussi un point commun au Data Mesh et à l’Event Mesh,
Cet article est le troisième d’une série présentant les évolutions des rôles des différents architectes dans la nouvelle version 6 du framework SAFe.
Après avoir étudié le System Architect et le Solution Architect, rencontrons l’Enterprise Architect ! Avant de rentrer dans le vif du sujet, nous souhaitions vous faire part de nos impressions quant aux évolutions du rôle de l’Enterprise Architect.
Dans les versions précédentes, le rôle de l’architecte d’entreprise n’était pas très détaillé. Il était clair que celui-ci intervenait dans la définition de la stratégie et aidait à mettre en adéquation les évolutions du système d’information avec celles du métier de l’entreprise, mais cela s’arrêtait là.
Dans cette nouvelle version, le framework contient beaucoup plus de détails sur les responsabilités de l’architecte d’entreprise. Celui-ci gagne ses lettres de noblesse et récupère dans sa bannette des sujets qu’il aurait toujours dû avoir (par exemple la rationalisation du portefeuille technologique). Son rôle n’est plus dans la pure stratégie décorrélée du terrain, il devient plus concret.
En revanche, il a aussi tout un lot d’activités nouvelles, que nous détaillerons dans la suite, et qui nous font dire qu’il faut avoir les épaules très larges pour occuper ce poste. L’architecte d’entreprise semble être partout à la fois, il est devenu une sorte de couteau-suisse ou d’architecte tout terrain si vous me passez l’expression.
Serait-il devenu l’architecte de l’entreprise ? Celui qui cumule bon nombre de responsabilités et qui collabore très largement avec l’ensemble de l’entreprise ? C’est ce que nous allons découvrir dans la suite !
De nouvelles responsabilités : De la définition de la stratégie, aux mains dans le code.
L’entreprise Architect s’est ainsi beaucoup musclé au passage de la version 5 vers la version 6 du framework Safe. Il est certes toujours responsable, au mot près, de la stratégie. Mais d’un rôle de facilitateur semi-passif (« Collaborating », « Assisting », « Helping », « Participating », etc…), il bascule vers un rôle de prescripteur. Un regard critique dirait qu’il retrouve ses prérogatives naturelles… Ainsi les différents (et nouveaux) rôles définis par le framework Safe sont :
Aligning Business and Technical Strategies
Coeur de métier de l’entreprise architect, son rôle est avant tout d’aligner l’architecture avec la stratégie IT, le tout en partageant ainsi sa vision et la stratégie business. Il identifie également les value streams à mettre en place, entretient ses relations avec les différentes équipes et va même jusqu’à participer aux démos.
Establish the Portfolio’s Intentional Architecture
Il s’agit là de définir une architecture cible avec des technologies cibles, des patterns d’architecture, le tout en synchronisant toutes les équipes ensemble. Fait marquant, l’apparition de la démarche inverse de Conway, consistant à définir une architecture, puis à calquer l’organisation sur cette architecture. Le contraire de ce qui est fait en général somme toute. L’architecte d’entreprise devient donc le responsable de la définition de l’organisation des équipes, ce qui en soit est un gros shift!
Rationalizing the Technology Portfolio
Le grand classique de l’architecture d’entreprise. On mutualise, on réduit les coûts, on réduit la complexité, etc…
Fostering Innovative Ideas and Technologies
Le titre est presque trompeur. Il s’agit surtout de permettre d’avoir un environnement technologique moderne et “propre”, en supprimant les technologies obsolètes, apporter du support aux environnements de développements, mais aussi en alignant les choix technologiques avec les business models pressentis.
Guiding Enabler Epics
Il est epic owner sur les initiatives d’architecture, et participe aux réunions safe pour s’assurer du bon alignement des équipes.
L’architecte d’entreprise reprend donc son rôle d’architecte d’entreprise, du métier aux développeurs, en passant par l’organisation des équipes. Par contre, son rôle est beaucoup plus étendu que dans la version 5, se retrouvant ainsi au milieu de nombreux acteurs.
Un accent mis sur la collaboration : D’une tour d’ivoire à un lean-agile leader
En effet, dans la version précédente de Safe, l’architecte d’entreprise était vu comme gravitant surtout dans les hautes sphères et ne collaborait qu’avec les autres architectes et des acteurs de haut niveau ou très transverses (Lean Portfolio Management, Agile Program Management Office, et le Lean-Agile Center of Excellence par exemple).
Il était supposé maintenir des relations avec les personnes de chaque Train mais ses activités quotidiennes ne s’y prêtaient guère. A présent que son périmètre s’étend considérablement, il sera amené à croiser des acteurs beaucoup plus nombreux. Il intervient comme proxy des acteurs business et doit être capable de porter la vision et la stratégie business auprès des différentes parties prenantes.
Il participe également à tous les événements en lien avec les enablers epics et aura donc l’occasion d’interagir avec les acteurs opérationnels des différents Trains.
Ses responsabilités étant également plus distinctes de celles des autres architectes, leur complémentarité est d’autant plus mise en évidence. Une collaboration efficace entre l’Entreprise Architect, le Solution Architect et le System Architect garantit l’alignement.
Enfin, l’Entreprise Architect doit incarner le Lead Agile Leader par excellence. Il mentore les équipes agiles, contribue à la mise en place de nouveaux modes de fonctionnement, et montre l’exemple en continuant à apprendre et à évoluer. Une forme de super héros inspirant tout le monde sur son passage, facile non ?
Si ces sujets vous intéressent…
Pour plus d’informations sur ces sujets et sur le rôle d’architecte dans un environnement agile, n’hésitez pas à aller voir notre série d’articles sur l’architecture et l’agilité.
Les articles 4 et 6 peuvent en particulier se révéler utiles :
Dans l’article 6, intitulé “Les 7 formations de l’Architecte Agile”, nous avions évoqué le besoin de formation SAFE pour l’architecte, et nous avions également parlé de la posture de coach de l’architecte via la process communication et la PNL.
Parmi la littérature conseillée par le framework Safe, on ne peut que vous conseiller le fameux livre “Team Topologies” qui évoque le rapprochement des équipes technologies et business :
