Votre organisation est-elle prête pour MACH ?
7 questions et réponses

L'ouverture et l'interopérabilité sont typiques de l'architecture MACH. Les applications sont construites en composants gérables plutôt qu'en monolithes. Le remplacement, l'amélioration et la suppression de services et de nouveaux releases sont relativement faciles et ne nécessitent pas une refonte complète du paysage. L'architecture « composable » de MACH offre une grande flexibilité et permet un taux de changement beaucoup plus élevé, or la philosophie Agile s'inscrit parfaitement dans ce cadre.

Friso Geerlings prévient : « Commencer à utiliser MACH ne signifie pas nécessairement que l'ensemble de votre entreprise doit être conçue de manière Agile au préalable, mais le département ou l'unité commerciale où vous allez commencer à utiliser MACH doit l'être. Commencez par nommer un bon Product Owner expérimenté, de préférence quelqu'un qui peut combiner les intérêts et les forces des individus et des équipes de l'entreprise et qui, en ce qui concerne MACH, est informé des exigences techniques. Mettez en place une équipe auto-organisée autour du Product Owner pour un contrôle optimal du pipeline des releases techniques. »

Friso poursuit : « Le controle du pipeline de release technique est d'une importance capitale, car vous voudrez profiter dès le départ de la rapidité du changement. Les objectifs initiaux de l'équipe consistent à contrôler le processus de mise en production et le déploiement continu (CD). Si le processus ne se déroule pas sans accroc, vous pouvez envisager d'effectuer davantage de releases. Ce n'est pas pour rien que l'on dit souvent : "Si ça fait mal, faites-le plus souvent." quand on parle de processus de release et de CD. L'agilité est une condition préalable à la bonne conception de ce processus. »

Autre raison de l'importance d'une organisation Agile : les processus dynamique et cycliques. Friso Geerlings explique : « La mise en place de MACH implique constamment la relation entre le choix des services et la conception de l'architecture complète. Chez iO, nous l'avons clairement constaté dans le cadre d'un projet de conception d'une architecture MACH. Nous avions initialement opté pour Contentful en tant que CMS headless, mais nous avons découvert au cours du processus que Storyblok était une meilleure option, car il offre de meilleures capacités de prévisualisation, ce qui était l'un des requirements. Des exemples comme celui-ci soulignent vraiment l'importance du processus de préparation. »

Les services MACH proposent des API qui sont débloquées dans un un front-end : le composant headless de l'architecture. Friso Geerlings précise : « Les développeurs front-end qui ont un background en design ou en design multimedia ont généralement du mal à gérer cela. C'est très différent d'une plateforme classique, où le travail est davantage axé sur la visualisation. Les compétences techniques de base et les qualités en matière de développement de logiciels sont beaucoup plus importantes pour les développeurs front-end qui travaillent avec les services MACH. Le ou les front-ends sont construits sur un ensemble de services MACH et connectés à l'aide d'API, ce qui nécessite la connaissance de frameworks tels que Vue, React, et beaucoup d'expérience avec JavaScript. »

Friso poursuit : « Un paysage MACH peut être entièrement composé en fonction des besoins individuels, les interfaces peuvent être uniques et l'intégration implique un travail sur mesure. On peut le comparer à un écosystème construit à partir des besoins uniques de l'entreprise. Le succès des produits et des services dépend des utilisateurs finaux, ce qui fait que l'UX et les tests utilisateurs sont plus importants que jamais. Après tout, l'objectif et de réussir à atteindre une expérience unique et une conversion optimale. Le mot d'ordre est de tester les concepts et les prototypes auprès des utilisateurs finaux en temps utile et d'utiliser les enseignements que vous en tirez pour améliorer les designs. »

MACH implique plus de défis techniques qu'une plateforme classique car il nécessite une vue d'ensemble du paysage, une plus grande intégration et davantage de choix individuels. Le développement des connaissances technique est de loin le plus grand défi pour les entreprises dans leur transition vers une architecture MACH. Qu'est-ce que cela signifie ?

« La complexité augmente avec la taille du paysage. Si le paysage MACH est encore petit et consiste en deux ou trois services, il est assez facile au départ de les relier point par point. L'expansion du paysage entraîne souvent la nécessité d'introduire une couche d'intégration et d'accès, telle qu'une passerelle API (Gateway). Cette couche est utilisée pour contrôler le transfert de données et la logique (API), ce qui sera d'une grande importance si des services externes de partenaires sont liés à votre paysage MACH », explique Friso.

Il poursuit : « Cela nécessite une connaissance des technologies courantes telles que REST, API, JSON et OpenID Connect, ainsi qu'une connaissance en matière de message queueing. AWS ou Azure Serverless, Webhooks et GraphQL pourraient être nécessaire pour les configurations plus complexes. La passerelle API est un autre exemple. La conception et le développement d'une stratégie API, y compris la conception de l'API, le versioning de l'API et l'expérience développeur qui l'accompagne, sont des compétences d'intégration typiques et importantes à maîtriser dans un grand paysage MACH. Le plug and play n'est pas le point fort de MACH, car il est destiné aux développeurs. Par rapport à une plateforme classique, il nécessite plus de travail de développement et moins de configuration, ce qui est généralement accueilli avec enthousiasme par les équipes de développement. »

« Les entreprises qui se lancent dans un projet complexe comme celui-ci font souvent appel à des partenaires digitaux tels qu'iO pour apporter leurs connaissances et lancer le projet sur de bonnes bases. En outre, un partenaire digital apporte une expertise sur des aspects complexes et spécialisés, qu'il développe et intègre. Après un transfert de connaissances approfondi, les ressources de ces partenaires sont généralement réduites une fois qu'une base solide permet aux entreprises de poursuivre leur activité de manière indépendante », raconte Friso.

« Le principal défi de MACH est l'intégration. Bien que les services - qui présentent les modèles de données puissants et soigneusement conçus ainsi que la logique que vous avez élaborée - offrent en eux-même une bonne fonctionnalité, les choses peuvent vraiment mal tourner lors de l'intégration. Ces aspects cruciaux requièrent sans aucun doute les connaissances adéquates, que ce soit en interne ou par l'intermédiaire d'un partenaire digital. »

Alors qu'une plateforme classique dispose d'un login intégré et central, celui-ci doit être configuré pour une architecture MACH. Dans certains cas, celle-ci se limite à un, deux, voire trois services liés. Dans ce cas, la sécurité et la connexion sont généralement traitées de manière adéquate dans les services individuels. Si la double connexion et l'administration des droits s'effectuent assez facilement, les choses changent lorsque le paysage s'agrandit ou commence à utiliser une couche d'intégration. Dans ce cas, les rôles, les droits d'accès et les informations d'identification sont répartis entre plusieurs microservices. La gestion de la sécurité end-to-end est alors une autre histoire.

« Vous allez entrer dans le domaine de la gestion des identités et des accès (Identity and Access Managament - I&AM) et de l'authentification unique (Single Sign-On - SSO), prévient Friso Geerlings. À mesure que le paysage se développe, je recommanderais de retirer l'I&AM et le SSO des services et de les regrouper sous une plateforme de gestion des accès et des identités, telle que AWS Cognito. Cela permet un SSO bien conçu et un contrôle d'accès basé sur les rôles, et de démontrer leur fonction. Cette configuration présente de nombreux avantages, en particulier si ces services MACH sont utilisés dans un environnement de marché certifié ou réglementé, comme ISO 27001, PCI-DSS ou dans le domaine des soins. »

L'architecture MACH est facile à tester et adaptée aux automated test streets, qui sont également d'une grande importance pour les releases fréquents. Les services peuvent être testés une par un, car les services MACH sont accessibles via des API. L'ensemble du paysage est donc beaucoup moins une « boîte noire » qu'une plateforme classique.

« Un environnement d'assurance qualité (QA) distinct est généralement mis en place pour des tests approfondis, qui nécessitent un test set de qualité, automatisé et fiable. L'architecture MACH le permet. Les releases fréquents sont une stratégie qui convient parfaitement à MACH, mais seulement si le test set est en ordre », précise Friso.

L'organisation de l'approvisionnement en données de test est importante, mais pas toujours évidente : « La disponibilité de données de test de qualité et réalistes, et l'inclusion de ces données dans le service MACH (de test) peuvent poser problème. Le chargement automatisé des données de test devrait vraiment être un critère de choix d'un fournisseur. Vous pourriez envisager d'investir dans l'anonymisation automatique des données de votre environnement de production pour le testing sur le long terme. »

Chaque service MACH fait l'objet d'un fee mensuel. Friso Geerlings fait remarquer que « cela peut sembler très facile à suivre et attrayant. L'implémentation d'une plateforme classique implique en effet des frais de licence initiaux considérables, tandis que les services MACH offrent la liberté d'opter pour un fit-for-use. »

Il prévient toutefois : « Il est important de bien comprendre le modèle de tarification d'un service avant de faire un choix. Si votre ambition est d'étendre vos services à un grand nombre d'utilisateurs à faible valeur ajoutée, les coûts des services dont les prix sont basés sur le nombre d'utilisateurs finaux peuvent monter en flèche. Auquel cas, il serait préférable de payer pour l'utilisation réelle, par exemple le nombre d'appels API ou de groupes d'appels API. En outre, le développement de l'écosystème MACH implique la nécessité d'un SSO. C'est souvent là qu'intervient la version enterprise des services MACH : le SSO n'est généralement pas inclus dans les tiers economy starters, et les versions enterprise sont plutôt onéreuses. »

« Un paysage MACH est généralement aussi coûteux qu'une plateforme classique. Le fait de commencer à une échelle limitée (avec peu de services ou d'utilisateurs) offre un avantage, rendant les coûts de démarrage considérablement plus attractifs par rapport à une plateforme monolithique. Il est toutefois recommandé d'effectuer l'analyse de rentabilité d'un paysage MACH en s'appuyant sur d'autres aspects que l'avantage supposé en termes de coûts. Examinez les questions sous des angles tels que l'agilité commerciale, la possibilité de créer une expérience unique ou l'amélioration de l'intégration de chaînes de valeur complexes. MACH apporte réellement une valeur ajoutée dans ces domaines, s'ils sont pertinents pour votre entreprise », souligne Friso.

De l'avis de Friso Geerlings, « une architecture MACH nécessite une double surveillance et la conception de deux cockpits : l'un opérationnel et l'autre technique. Le fait de pouvoir surveiller en détail l'ensemble de vos performances permet de repérer facilement les problèmes. Envisagez une combinaison d'Application Performance Monitoring (APM), Analytics et BI. Cela implique naturellement des outils prêts pour MACH. »

Comme nous l'avons démontré, une architecture MACH implique bien plus que le simple fait de commencer à utiliser une plateforme SaaS en ligne. Le Technology Director d'iO conclut : « Des spécialistes expérimentés de l'intégration et du front-end (qu'ils soient déjà employés dans l'entreprise ou impliqués en tant que partenaires) sont essentiels. Les questions techniques liées à MACH sont assez complexes, en particulier si le paysage se développe en un écosystème. Je recommanderais de commencer par une expérience imitée et de poursuivre en faisant des choix réfléchis après une mise à l'échelle de plus de deux ou trois services. Cela peut sembler évident, mais ce n'est pas nécessairement simple. Et, bien que MACH permette de reconsidérer facilement les choix pour chaque composant, il est en fin de compte plus difficile de remplacer le "ciment" du paysage. Testez à temps, contrôlez judicieusement, sécurisez et intégrez avec expertise. »