Aligner l’architecture opérationnelle et l’architecture technologique #4

Cet article fait partie de notre série sur le thème de l’architecture numérique d’entreprise. Les articles de la série publiés jusqu’à maintenant sont les suivants :

• Partie 1 : L’architecture informatique dans le contexte de la transformation digitale
• Partie 2 : L’architecture d’entreprise en 4 frameworks
• Partie 3 : Les avantages de l’architecture opérationnelle
• Partie 4 : L’architecture technologique, qu’est-ce que c’est ?
• Partie 5 : Aligner l’architecture opérationnelle et l’architecture technologique
  • #1
  • #2
  • #3

Dans la partie précédente, nous avons abordé la troisième étape de la numérisation d’une entreprise : la numérisation des objets. Dans cette partie, je voudrais aborder la numérisation de la collaboration qui constitue la quatrième étape de la numérisation d’une entreprise.

4. Numérisation de la collaboration

Une entreprise est toujours implantée dans un plus grand écosystème. Celui-ci est composé de la clientèle (individus et organisations), des fournisseurs et partenaires, mais aussi des services administratifs et des prestataires de services généraux. Si on ne considère pas seulement les chaînes de création de valeur comme limitées à l’entreprise, mais qu’on inclut également d’autres intervenants de l’écosystème, il est alors possible d’éviter les récurrences et d’accroitre l’efficacité de la création de valeur. Sur ce point, il est crucial que la synergie entre toutes les parties prenantes fonctionne sans accrocs et soit aussi automatisée que possible. Ainsi, différentes informations, qui surviennent ou sont nécessaires dans le processus de création de valeur, sont regroupées dans un flux de données central, qui s’écoule comme un fil rouge sur toute la chaîne de production de valeur. C’est ce qu’on appelle le « digital thread ».

Au lieu de la création de valeur, une telle intégration globale peut également être réalisée tout au long du cycle de vie d’un produit ou d’un bien particulier. Ainsi le digital thread devient un fil rouge qui assimile tout l’historique d’un produit ou d’un bien. Des données qui, dans l’idéal, sont collectées et utilisées par un jumeau numérique. Ce cas de figure est particulièrement important lorsqu’il est question de composants de sécurité (p. ex. des pièces d’avion) dont la chronologie, de leur production à leur élimination en passant par leur utilisation et leur maintenance, doit être traçable.

Étant donné que le long d’un digital thread, différents systèmes de divers fabricants sont impliqués et que les limites mêmes des organisations participantes sont dépassées, l’harmonisation de la sémantique des informations engendrées et requises le long du digital thread représente un défi particulier : comment par exemple assurer que la même chose soit comprise tout le long du cycle de vie pour le concept de « commande » ou de « longueur » ? Ici, de nouveaux standards tels que eCLASS (voir référence 1) ou GS1 (voir référence 2) s’offrent comme solution, mais des modèles d’information ou des ontologies formelles peuvent aussi entrer en jeu, j’en discuterai plus en détail dans une partie à venir de cette série.

Les bases conceptuelles pour l’intégration de différents systèmes, parfois au-delà des limites de l’entreprise, constituent une « architecture orientée services » (SOA). Le service est ici bien défini, proposé par un prestataire, utile à une ou plusieurs parties concernées et consultables au besoin. Dans le cadre d’une SOA, les trois rôles suivants occupent une place centrale :

• Service Provider: Le prestataire d’un ou plusieurs services bien définis qui seront utilisés par le Service Consumer.
• Service Consumer: L’utilisateur ou consommateur d’un service défini proposé par un ou plusieurs prestataires.
• Service Directory: Un Service Provider spécial qui propose comme service un répertoire de services et de Service Provider à disposition (Service Discovery).

Une entente portant sur la qualité du service à fournir est souvent conclue entre le Service Provider et le Service Consumer. Cette entente est ce qu’on appelle le Service Level Agreement (SLA). Le concept de SOA ne se limite en aucun cas aux systèmes informatiques, mais peut aussi bien être appliqué à notre société de services. Toutefois, je voudrais ici me limiter aux systèmes informatiques, c’est-à-dire aux services accessibles par voie numérique qui proposent de l’information ou exécutent certaines actions en se basant sur les informations mises à disposition.

D’un point de vue technique, l’utilisation fructueuse d’un service nécessite que le Service Provider et le Service Consumer s’entendent sur les éléments suivants :

• L’API (Application Programming Interface) du service contient aussi bien la définition de la syntaxe du service pour y faire appel que la sémantique du service, c’est-à-dire sa fonctionnalité exacte (prérequis avant d’y faire appel et garanties après y avoir fait appel) ainsi que les spécifications de l’exacte signification des informations échangées.
• Le protocole du service définit l’art et la manière dont un Service Provider et un Service Consumer échangent des commandes et des informations entre eux, c’est-à-dire le format technique des informations échangées ainsi que les éventuelles directives concernant la marche à suivre pour faire appel au service (séquence et timing).

Tous les systèmes impliqués dans une intégration doivent s’accorder sur ces deux éléments. Si de nombreux systèmes très différents sont utilisés, il y a un risque qu’un système individuel doive être capable de communiquer en même temps avec différents protocoles de service. Ici, le concept d’« Enterprise Service Bus » (ESB) s’offre comme solution. Il s’agit d’une plateforme centralisée qui prend en charge les appels de service dans différents protocoles et ensuite, après une conversion requise des protocoles, les transmet au Service Provider compétent (architecture de réseau en étoile « Hub and Spoke »). Une telle ESB a alors la possibilité d’effectuer en parallèle toutes les harmonisations de sémantique nécessaires.

Les technologies

Il existe de nombreux standards éprouvés à différents niveaux d’abstraction en ce qui concerne les protocoles de services, comme REST, JSON ou SOAP/XML, HTTP, RPC, TCP/IP ou UDP ainsi que les standards pour la communication mobile comme LTE ou 5G.

LLa définition de l’API est en général propriétaire puisque c’est ici que sont spécifiées les fonctionnalités propres à l’application. En ce qui concerne les fonctionnalités le plus souvent utilisées, il existe cependant également des standards comme SNTP pour le trafic d’e-mail, FTP pour l’échange de données ou UDDI pour le Service Discovery. En particulier dans le milieu industriel de l’IoT (Internet of Things) et de l’IIoT (Industrial IoT), OPC-UA est un standard de communication selon le principe SOA qui est destiné spécifiquement aux besoins du contrôle et de la surveillance des machines.

La conception, la maintenance et le développement de sa propre API de service, mais aussi l’utilisation ciblée d’API de service publiquement accessible, sont ce qu’on appelle l’« API Management ». Une publication habile de ses propres services et l’utilisation de services publics permettent d’atteindre un plus haut degré de réutilisation qui, en outre, peut également être monétisé.

Finalement, je voudrais ici encore aborder la « Distributed Ledger Technologies » (DLT) (la technologie de registre distribué). Celle-ci permet de mettre à disposition des données entrantes importantes sur une longue période, de manière contrôlée, à toutes les parties prenantes. Dans le même temps, cette technologie garantit qu’une fois les données publiées, celles-ci ne puissent que difficilement être modifiées. Elle est ainsi idéalement adaptée pour enregistrer un Digital Thread de la vie complète d’un composant essentiel ou critique pour la sécurité. De plus, la DLT convient parfaitement comme plateforme d’intégration permettant aux utilisateurs autorisés de s’abonner, par exemple, à une livraison d’informations (comme IOTA, voir référence 3).

Exemple d’EU-Rent

EU-Rent tient un Digital Thread pour chacun de ses véhicules. Celui-ci réunit toutes les informations pertinentes et les incidents de la vie d’un véhicule possédé par EU-Rent au sein d’un registre distribué. Ces informations comprennent aussi bien les données de configuration et de mouvement actuelles du véhicule que la chronologie de location et de maintenance. Les données des véhicules sont lues par une API REST directement à partir des véhicules (voir référence 3 pour un exemple). La chronologie de location et de maintenance est assumée par le PGI (progiciel de gestion intégrée ou ERP en anglais) propriétaire d’EU-Rent. Ces informations sont mises à disposition de toutes les parties autorisées selon leurs tâches respectives (personnel de vente, mécanicien, client, mais aussi assurances, constructeurs de véhicules et autorités). Grâce au SmartContract basé sur la DLT, il est de surcroît possible de veiller à ce que les maintenances nécessaires d’un véhicule soient également réellement effectuées.

Dans la dernière partie sur l’alignement de l’architecture opérationnelle et l’architecture technologique dans le cadre de la transition numérique d’une entreprise, nous discuterons de la thématique de la transformation des opérations.

À lire également :

• Partie 1 : L’architecture informatique dans le contexte de la transformation digitale
• Partie 2 : L’architecture d’entreprise en 4 frameworks
• Partie 3 : Les avantages de l’architecture opérationnelle
• Partie 4 : L’architecture technologique, qu’est-ce que c’est ?
• Partie 5 : Aligner l’architecture opérationnelle et l’architecture technologique
  • #1
  • #2
  • #3

Références :

• 1 https://www.eclass.eu/fr
• 2 https://www.gs1.org/
• 3 https://eclass.iota.org/