Orchestration et fédération / Blogs / Perficient

Partie 3 dans notre «déballer la pile« La série sur les martech composables concerne uniquement les données – en particulier l’accès aux données – la couche intermédiaire de la pile. Le prochain ensemble de fonctionnalités que nous explorons est l’orchestration et la fédération. Ces deux capacités vont bien ensemble car elles sont très similaires et se chevauchent dans une certaine mesure, alors décompressons-les.

Orchestration et fédération dans une architecture composable

À un niveau élevé, la catégorie « orchestration et fédération » représente l’accès et le routage sous-jacents aux données à travers une variété de produits martech back-end – du PIM, CMS, gestion des commandes, DAM, automatisation du marketing, bases de données propriétaires internes et externes, etc. Alors que les sujets précédents de FEaaS et Créateurs d’expérience concentrez-vous sur l’expression visuelle du contenu, des données, et les capacités de mise en page, d’orchestration et de fédération fournissent un accès (et de l’intelligence !) au contenu et aux données réels pour hydrater ces expériences. Comprenons mieux les différences ici.

Orchestration vs Fédération

La réalité est que ces termes sont souvent utilisés de manière interchangeable, donc les définitions ci-dessous sont mon point de vue basé sur la façon dont ils sont souvent utilisés dans la réalité et… un peu de dictionnaire :

• Fédération signifie rassembler plusieurs sources de données/contenu dans un « lieu » consolidé et prévisible – en réalité, le « lieu » peut être un outil martech qui contient une copie de toutes les données/contenus, ou simplement une façade API qui se trouve au-dessus des API des systèmes sous-jacents. Plus d’informations à ce sujet dans un instant. Le point clé ici est qu’il s’agit d’une couche d’unification dans la pile martech, un point d’entrée unique pour accéder aux systèmes back-end via une seule API.
• Orchestration est la même que la Fédération, cependant, elle apporte un peu plus de logique à la partie données, fournissant un certain niveau d’intelligence et de contrôle sur exactement quelles données/contenus sont fournis pour la consommation. C’est comme le contrôle du trafic aérien pour le flux de données provenant des systèmes back-end.

Exemples de fédération de contenu

La fédération de contenu est une fonctionnalité d’unification qui vous permet de combiner plusieurs sources back-end dans une pile composable. Voici quelques exemples :

Fédération de contenu Hygraph

Sources distantes Hygraph unifiez plusieurs API du système source back-end directement dans l’API Hygraph afin que le consommateur (par exemple, une application Web) n’ait besoin d’accéder qu’à l’API Hygraph et non directement à tous les autres systèmes sous-jacents. Vous pouvez en savoir plus sur le concept de fédération de contenu de Hygraph ou voyez-le en direct dans une vidéo! Une chose à noter est que Hygraph ne récupère et ne stocke pas réellement de données externes dans Hygraph, mais le schéma de l’API de la source distante est ajouté à l’API Hygraph, de sorte qu’un seul appel à l’API Hygraph effectuera un appel « sous le capot » vers l’API externe. API de Hygraph au moment de la requête.

Références externes de Contentful Content Orchestration

Références externes de contenu (ironiquement) est une fonctionnalité de « l’orchestration de contenu » Contentful (voyez ce que je veux dire par ces termes utilisés de manière interchangeable ?). Les références externes permettent aux utilisateurs du système d’enregistrer des sources d’API externes qui sont fusionnées dans l’API Contentful GraphQL afin qu’un consommateur n’ait besoin d’utiliser qu’une seule API. Cette capacité est presque identique à Hygraph, cependant, une chose importante à noter est que Contentful permet l’édition bidirectionnelle de données externes. Cela signifie qu’un utilisateur du CMS peut modifier directement les données externes à partir de l’interface utilisateur Contentful CMS (en supposant que l’API soit configurée pour gérer cela). L’un des principaux avantages de l’édition bidirectionnelle est qu’un utilisateur professionnel n’a pas besoin de se connecter aux autres systèmes pour effectuer des modifications, il peut rester dans l’interface Contentful pour effectuer toutes les modifications.

Netlify Connecter

Netlify Connecter est un autre bon exemple de fédération suivant un modèle similaire à Hygraph et Contentful. Dans Netlify Connect, vous pouvez configurer plusieurs « couches de données » sur les systèmes back-end à l’aide des intégrations prédéfinies fournies par Netlify, ou sur votre propre système propriétaire à l’aide du SDK Netlify. Un excellent cas d’utilisation de cette approche personnalisée est si vous disposez d’un système propriétaire dont il est difficile d’extraire des données et qui nécessite un code personnalisé.

La différence la plus notable avec Netlify Connect est qu’il récupère et met en cache vos données externes dans sa propre base de données et expose des instantanés des données historiques. Cela signifie que vous pouvez utiliser les révisions des données historiques pour interroger un ensemble spécifique de données à un moment donné, en particulier si vous devez dépanner ou restaurer l’état d’une expérience.

Graphique optimisé

Contrairement aux exemples précédents, Optimizely est un DXP plus traditionnel qui s’appuie fortement sur le sans tête avec des sites comme Sitecore, Adobe, dotCMS et autres.

Optimizely Graph est la nouvelle API GraphQL destinée à proposer des expériences sans tête basées sur Optimizely. Une fonctionnalité subtile (et peut-être négligée ?) de Graph est la possibilité d’enregistrer des sources de données externes et de les synchroniser dans Graph. Basé sur la documentation dans l’état actuel des choses, il semble que ce travail soit principalement dirigé par les développeurs et nécessite que les développeurs écrivent du code personnalisé pour récupérer, préparer et soumettre les données à Graph. Cela dit, les avantages mentionnés précédemment sont toujours valables. Cela permet aux expériences sans tête de consommer le contenu d’une seule API tandis qu’en coulisse, le processus de synchronisation récupère et stocke les données externes dans Graph.

Entrez la vitesse

Entrez la vitesse est un bon exemple de produit pureplay qui se concentre sur l’unification comme couche intermédiaire dans une architecture composable. Il vous permet d’ingérer des données externes, de transformer ces données et de les transmettre à différents points de contact, le tout via un réseau périphérique haut débit.

WunderGraph Cosmo

WunderGraph fournit une fédération de microservices GraphQL. Il s’agit d’un produit open source et hébergé qui vous aide à gérer plusieurs bases de données back-end, API, fournisseurs d’authentification, etc. De plus, il est conçu de manière à permettre aux développeurs de déclarer le type de compositions d’API qu’ils souhaitent à l’aide de codesuivant une approche basée sur Git, au lieu de nécessiter une installation et une configuration basées sur l’interface utilisateur.

rencontré

rencontré fournit Fédération GraphQL similaire à WunderGraph. Il fournit une seule API GraphQL aux consommateurs avec la possibilité de connecter plusieurs systèmes sous-jacents tels que les API REST et les bases de données (par exemple Postgres, SQL Server, Oracle, etc.).

Exemples d’orchestration

Orchestration de l’expérience numérique avec Conscia

DXO est une capacité émergente lancée par Conscia.ai pour aider à résoudre le problème de l’intégration de nombreux back-ends à de nombreux front-ends. DXO aide à orchestrer la complexité intermédiaire via une couche unifiée avec laquelle tous les services back-end et systèmes d’enregistrement communiquent, ainsi qu’une API frontale unifiée pour les expériences à consommer :

Un principe clé de cette approche est de continuer à exploiter les API en temps réel des systèmes back-end, par exemple un CMS sans tête pure play et un moteur de commerce. Le DXO agit non seulement comme une façade front-end de ces systèmes back-end (semblable à une passerelle API), mais il offre également d’autres avantages :

• Unifie les données sur les systèmes d’enregistrement back-end, comme vous le voyez avec Federation
• Fournit une logique et des règles métier améliorées en permettant aux utilisateurs professionnels d’enchaîner les API, évitant ainsi la logique statique écrite dans le code par les développeurs.
• Offre des améliorations de performances en mettant en cache les appels en temps réel aux API back-end et en poussant autant de calculs (par exemple, la logique métier) vers la périphérie, plus près des utilisateurs finaux.

L’une des propositions de valeur clés du DXO de Conscia est un canevas convivial permettant d’intégrer plusieurs réponses aux appels d’API et de créer des chaînes d’appels. Par exemple, la réponse à un appel d’API peut devenir une entrée pour une autre API, qui est souvent une logique codée en dur écrite par les développeurs :

Le DXO de Conscia offre deux fonctionnalités clés :

• Moteur DX en tant que couche de fédération pour unifier plusieurs sources back-end de données et de contenu, ainsi qu’en tant que moteur de règles et prise de décision intelligente pour orchestrer le contenu et les données adaptés à l’expérience individuelle.
• Graphique DX comme un hub centralisé de toutes les données, particulièrement utile si vous disposez de systèmes back-end existants ou de systèmes propriétaires avec des données difficiles d’accès. Le DX Graph peut se connecter à des API modernes pour visualiser (via un graphique !) Toutes vos données, mais il devient également un hub centralisé pour les données propriétaires qui peuvent nécessiter des tâches de synchronisation planifiées, un traitement de fichiers par lots et des méthodes d’intégration similaires.

Modèles similaires : passerelles API et BFF

Est-ce comme un Passerelle API?
Oui et non. Une passerelle API fournit une façade au-dessus de plusieurs services back-end et API, mais elle effectue principalement une chorégraphie en tant que courtier d’événements entre le back-end et le front-end (client). Un système d’orchestration place le cerveau dans la passerelle API, constituant un hub centralisé, et permet aux utilisateurs professionnels de contrôler davantage la logique.

Est-ce similaire au BFF (backend pour frontend) design pattern?
Sorte de. Si les outils de fédération ou d’orchestration spécifiques que vous utilisez vous permettent de contrôler la forme de vos réponses API pour des consommateurs spécifiques (par exemple, les clients frontend dans un BFF), alors vous pouvez réaliser un BFF. C’est certainement un bon cas d’utilisation pour Conscia.

Pourquoi l’orchestration et la fédération sont-elles importantes dans l’architecture composable ?

Dans une pile véritablement composable, nous devons considérer le fait que plusieurs systèmes utilisés signifient plusieurs sources de vérité : CMS, un autre CMS, peut-être un autre, PIM, DAM, OMS, la liste est longue. Il est tout à fait possible d’intégrer directement tous ces systèmes directement depuis votre tête (la mise en œuvre de l’expérience que vous proposez comme un site Web, une application mobile, etc.). Cependant, les intégrations directes comme celle-ci ont tendance à échouer lorsque vous évoluez vers plusieurs expériences, car toute la logique d’intégration des données back-end se trouve dans une implémentation/une tête d’expérience spécifique (par exemple, le code de l’application du site Web).

Alors, quelle est l’alternative à mettre les intégrations directement dans votre tête ?

• Faites un résumé et construire une couche d’intégration DIY : cela semble demander beaucoup de travail, mais c’est certainement possible. Cependant, il peut être difficile à mettre à l’échelle, à ajouter des fonctionnalités et à maintenir, car il deviendra un produit sur mesure au sein de votre architecture.
• Acheter un outil de fédération/orchestration : pourquoi le construire quand il existe des produits qui gèrent déjà cela ? Concentrez-vous sur votre activité spécifique au lieu de créer (et de maintenir !) un produit sur mesure (comme un CMS, un PIM, un OMS, etc.)

Une couche de fédération/orchestration dédiée offre les avantages clés suivants :

• Une API unique et unifiée pour les consommateurs (site marketing, portail web, application mobile native, syndication de données vers d’autres systèmes/canaux, etc.)
• Favorise le concept selon lequel les systèmes d’enregistrement doivent véritablement posséder leurs données et évite d’avoir à écrire un middleware personnalisé pour gérer l’orchestration et la logique sur de nombreux systèmes (par exemple, une intégration basée sur la tête ou une couche d’intégration personnalisée)
• Encourage la réutilisation des données et du contenu : il propose des données en tant que service, afin que vous puissiez vous concentrer sur la manière de les activer sur vos chaînes.
• Peut fournir une intelligence contextuelle pour contrôler et personnaliser les réponses API aux visiteurs individuels dans une couche de données dédiée afin de proposer des expériences omnicanales personnalisées.

Nous avons tout, alors quelle est la prochaine étape ?

On dirait que nous avons tout ce dont nous avons besoin ici, qu’y a-t-il d’autre ? (Re)regroupons les trois premières capacités dans un sujet plus vaste – restez à l’écoute pour la partie 4 où nous parlerons de Composition de l’expérience numérique (DXC).