Architecture eFTI S01E01 - Principes

18/5/2022

Temps de lecture :

4 minutes

Architecture eFTI S01E01 - Principes

18/5/22

•

Temps de lecture :

4 minutes

Sommaire

#Résumé-svp-pas-le-temps

Le DTLF SG1 "Paperless transport" Team 3 TaskGroup 2 travaille sur les règles générales et les lignes directrices pour l'utilisation et le déploiement des ressources informatiques dans l'écosystème eFTI. On badine un peu moins que dans certains articles précédents puisqu'on commence à taper dans le dur avec ceux qui ont les mains dans le cambouis conceptuel. Premier article d'une série sur le modèle de données eFTI alors que le DTLF commence à formaliser ces guidelines depuis mars 2022.

‍

Rappel : Deuxième dose

Commençons par un rappel de l'organisation du DTLF qu'il est bon de garder en tête quand on parcourt les travaux du DTLF puisque c'est le squelette autour duquel tout s'articule et que c'est un jargon bien utile, tout jargon qu'il soit :

DTLF SG1 :Paperless transport
Team 1 :Data modeling
Team 2 :Functional aspects
Team 3 :Technical aspects → Celui qui nous intéresse ici !
TaskGroup 1 :Legal requirements (Eric Grandry)
TaskGroup 2 :eFTI architectures principales (Rudy Hemeleers) → Celui qui nous intéresse ici !
TaskGroup 3 :Functional architecture
TaskGroup 4 :Building blocks catalogue
TaskGroup 5 :Technical architecture
Team 4 :Certification and implementation
DTLF SG2 :Corridor freight information systems
Team 1 :Plug and play
Team 2 :Technology independant services
Team 3 :Federation of platforms
Team 4 :Trusted, safe and secure
Ce subgroup est directement connecté à FENIX et FEDeRATED

‍

Méthodologie et process

Le groupe de travail utilise la méthodologie TOGAF pour définir les principes d'architecture de référence pour l'eFTI. C'est une méthodologie portée par l'Open Group. L'Open Group a été créé en 1996 à l'issue de la guerre des UNIX en fusionnant notamment l'Open Software Foundation et X/Open succédant à d'autres groupes en anciennement pour porter des normes neutres dans le domaine de l'ingénierie informatique. Le TOGAF est devenu un standard industriel en matière d'architecture informatique d'entreprise. Il repose sur trois concepts : le cycle ADM (en huit phases axées sur les exigences), le cadre de contenu (classifier tous les éléments en jeu et leurs relations sous forme d'ontologie/méta modèle de données) et le cadre de capacité (définir la structure qui va implémenter l'architecture). Mais trêve de COBIT, ITIL et ADM, on retiendra que les principes d'architecture eFTI ont été définis en deux groupes :

‍

ID	Principe	Description	Bénéfice	Point de réflexion
P1	Data is Shared at Source	Les platesformes eFTI constituent des points d'accès décentralisés pour publier des données	L'information est synchronisée sans nécessité de duplication au niveau de chaque acteur grâce à un identifiant unique pour chaque data subset	Quel sera le mécanisme d'exploration des données ? Si la donnée n'est jamais dupliquée, comment gérer la multiplicité des plateformes eFTI pour décider quelle plateforme eFTI est LA source ?
P2	Data Sovereignty	Le propriétaire de la donnée reste l'unique maître de cette donnée conformément à la réglementation en vigueur	Assurer la confiance dans l'écosystème dans la lignée de la RGPD	Implique la gestion des autorisations d'accès par chaque acteur économique (Quel acteur peut voir quoi, pendant combien de temps, sur quel périmètre de la chaîne ?)
P3	Decentralized Approach, Common Rules of Interaction	L'échange d'information se fera via les noeuds d'un réseau dont les règles seront définis dans via les Actes délégués et les Actes d'exécution	Deux types de systèmes soutiennent l'écosystème : plateforme eFTI pour que les acteurs économiques publient les données et systèmes des autorités pour qu'elles les valident	Enjeu sur les Access points (détail à suivre) et leurs modalités de fonctionnement (échanges entre access points ? échange A2A unique ? ouverture à un réseau B2A ?
P4	Trust, Non-Repudiation by Default	Des mécanismes garantissent l'origine et l'intégrité des données dans l'écosystème eFTI	Renforcement de la confiance et de l'adoption des pratiques eFTI	TOUTE opération doit être inscrit dans un registre pour consultation ultérieure. Enjeu de confiance entre les parties prenantes
P5	Security, Appropriate Authentication	Mise en place d'une méthode d'authentification adaptée à l'échange de données réglementaires	Le mode d'accès à l'écosystème doit fluidifier les échanges, pas le contraire	Multiplicité des utilisateurs : personnes physiques, morales, systèmes informatiques, point d'accès. Besoin fondamental d'implémenter des alternatives à la signature traditionnelle. Repose sur la maturité de mécanisme type eIDAS (Réglement UE 910/2014). Intégration de l'EORI pour les entreprises
P6	Access and Rights	Le propriétaire de la données contrôle son accès par les tiers (y compris les autorités compétentes)	Garantir la confiance sur l'intégrité de la donnée pendant tout son cycle de vie.	Enjeu sur la délégation de propriété et d'accès. Compatibilité avec les mécanismes d'authentification type eIDAS ? Adaptation à un mécanisme décentralisé ? C'est l'un des principes les plus difficiles à circonscrire aujourd'hui
P7	Once-Only	Respect d'une unique plateforme eFTI dite source qui est chargé de stocker une donnée et de diffuser l'identifiant unique	Les autorités accèdent à TOUTE l'information d'un transport (y compris multimodal) en une seule requête	Enjeu de résolution de conflits si plusieurs plateformes sont maîtresses de la donnée. Comment définir la source officielle ? Le premier qui publie ? Un accord ad hoc ? Comment gérer la délégation de droits ?
P8	Open Specifications and Standards, Interoperability	Priorisation et réutilisation des standards ouverts (non propriétaire) et interopérabilité avec les systèmes existants et en développement	Assurer la collaboration la plus facile et large possible	Implique une documentation exhaustive et largement diffusée. Exemple de standards : TAF-TSI (Rail), RIS (IW), eTIR/eCMR (Route). DIGINNO s'appuie également sur les infrastructures de PEPPOL pour gagner du temps. Qui maintient les standards ? Comment gérer l'absence actuelle de standard multimodal tout en réutilisant les standards existants ?
P9	Technology Independence	Possibilité de travailler dans l'écosystème eFTI avec tout type de technologie	Accessibilité accrue et possibilité d'évolution démultipliée en évitant des impasses technologiques	Implique l'alliance des solutions historiques du marché (parfois propriétaires) avec les technologies les plus récentes
P10	Easy Deployment, Integration and Transition	Le bénéfice du déploiement doit largement compenser son coût	Diminution des coûts de digitalisation auprès de l'ensemble des réseaux (B2B, B2A...), au-delà même du périmètre initial de l'eFTI	Enjeu de compatibilité avec les outils largement déployés dans les PME. Couper court à des solutions qui ne bénéficieraient qu'aux grandes entreprises disposant de moyens plus important pour mettre à jour leurs systèmes. Enjeu de disponibilité des interfaces utilisateurs dans toutes les langues de l'UE avec une implication sur la synchronisation des versions installées chez chaque acteur
P11	Support a Transition Period	Chaque acteur économique est libre de continuer à utiliser la version papier pendant une période probatoire	Trois choix : Papier ou Papier + numérique ou Numérique + certification eFTI	L'écosystème eFTI devra être compatible avec un process hybride pour prendre en compte la documentation papier. Une porte de sortie papier devra être maintenue à long terme notamment dans le cas où la marchandise sort de l'UE
GP1	Holistic Thinking	Prise en compte du système dans son ensemble à chaque choix de conception	L'implémentation d'un nouveau composant dans l'écosystème doit faire l'objet d'une étude d'impact pour confirmer qu'il apporte plus de bénéfices que d'inconvénients.	Enjeu sur la coordination de l'ensemble des parties prenantes et des potentiels intérêts antagonistes pour l'usage d'une fonctionnalité donnée
GP2	KISS (Keep if simple and stupid)	Eviter toute complexité qui ne remplit pas une fonction essentielle	C'est le coeur de la machine qui doit dicter le niveau de complexité de l'ensemble	Enjeu pour ne jamais perdre de vue le but de l'écosystème eFTI et les fonctions nécessaires pour l'atteindre. Sujet activement en discussion.
GP3	Scalability	Capacité à absorber une augmentation d'utilisateurs	Si l'écosystème atteint son but, il devra être capable de traiter l'ensemble des transactions documentaires sur le territoire de l'UE	Très fortement lié à la conception holistique de l'eFTI
GP4	Modularity	Création d'un ensemble de composants cohérents mais les moins interdépendants possibles	Facilite la maintenance de l'écosystème, l'identification des bugs, l'évolutivité	Sujet activement en discussion.
GP5	Maintenance and Development	Maintenance des points d'accès et diffusion des lignes directrices	Prise en compte des besoins exprimées par des groupes d'utilisateurs, des associations ou des contraintes réglementaires	Enjeu de compatibilité avec des référentiels de données variés (XML, JSON-LD, RDF). Enjeu sur la gouvernance qui régira les modifications apportées à l'écosystème.
GP6	Sustainability	Rester en line avec les politiques et les objectifs de l'UE en matière de soutenabilité environnementale	Un socle technique optimisé d'un point de vue de sa consommation énergétique	L'écosystème eFTI pourrait être un canal pour obtenir des données sur l'implémentation des stratégies de verdissement de l'UE en matière d'émission CO<sub>2</sub>

‍

11 principes qui découlent de la réglementation eFTI (P1, …, P11).
6 principes qui découlent des principes généraux de l'architecture informatique (GP1, …, GP6).
Pour chaque principe (Name), on décrit succinctement la règle qu'il incarne (Statement), le bénéfice qu'on en attend (Rationale) et les conséquences qu'il implique (Implications). Autant que possible, on détaille les réflexions connexes : lien avec les travaux d'autres groupes de travail, solution alternative ou limites (Discussion) et on mentionne les projets qui matérialisent le principe (Reference).

‍

eFTI cherche mantra architectural

Les principes d'architecture sont les mantras d'un Big brother qui n'aurait pas tourné au vinaigre, d'une Océania où War is peace devient Data is shared at source, Freedom is slavery devient Technology independence et Ignorance is strength devient Holistic thinking. Ci-dessous une tentative de synthèse un peu désespérée au vu de la richesse du sujet qui glane quelques idées dans le Statement, le Rationale, l'Implication et la Discussion de chaque principe.

‍

Vu le nombre élevé de groupes de travail arrive le moment où il faut consolider et confronter le fruit du travail de chacun. C'est l'objet des gaps analysis, au nombre de trois :

Architecture principles (DTLF SG1 Team3 TG2) vs Regulatory architectural requirement (DTLF SG1 Team3 TG1)
Architecture principles (DTLF SG1 Team3 TG2) vs Goals and principles for the Transport of Waste (WSR - Waste Shipment Regulation)
Architecture principles (DTLF SG1 Team3 TG2) vs Architecture principles (DTLF SG2)
Elles permettent d'enrichir et d'harmoniser les efforts des différents groupes.

‍

La gourmandise est un vilain défaut

Voici quelques documents de référence qui constituent des références dans le travail en cours du DTLF, la plupart purement techniques ou normatifs, d'autres sont des retours d'expérience sur des expérimentations grandeur nature comme le CEERIS. On en apprend moins sur la métaphysique de l'existence humaine que dans Dostoïevski mais un peu plus sur les pistes vers une interopérabilité européenne que dans le Capital :

Reference architecture model de l'IDS (International Data Spaces).
The Once Only Principle Project porté par Horizon 2020 au sein de la Commission européenne.
L'EIF (European Interoperability Framework) ou Cadre européen d'interopérabilité piloté par l'UE.
La publication Dematerialization & paperless processing du WCO (World Customs Organization).
Les recommandations de l'UNECE sur la validation de document sans signature.
Les principes d'architecture du RIS (River Information System) sur l'implémentation d'un système à l'échelle des voies navigables intérieures (IWT - Inland Waterways Transport) qui prend la forme du CEERIS en Europe de l'Est.
Les principes et retour d'expérience de FENIX et FEDeRATED (e.g. au sein du Master plan).
L'interface de l'EUDIN (European Data Interchange) sur la régulation des déchets, dont le site a disparu mais dont il reste quelques traces sur le site de la Commission européenne.

‍

Vous souhaitez gagner en productivité ?

Planifier une démo

‍

Qui s'y colle ?

‍

Voici une liste des membres du DTLF SG1 Team3 TG2 :

Name	Organisation
Rudy Hemeleers	INE Inland Navigation Europe
Antonella Di Fazio	FDC
Bojan Cekrlic	CargoX d.o.o.
Christian Lüpges	Federal Ministry of Transport and Digital Infrastructure, Germany(on behalf)
Jan Bergstrand	Trafikverket/MS Sweden
Jean-Marc Ors	GTF
John Kanellopoulos	ICCS
Sylvie LABETOULLE	GTF
Jean-Philippe Méchin	Cerema
Mikko Västilä	Västilä
Norbert Pfaffinger	Austrian Federal Ministry of Environment (authority)
Patrick Grassl	Austrian Federal Ministry for Climate Action, Environment, Energy, Mobility, Innovation and Technology
Riho Vedler	Intepia
Ulrika HURT	Single Window Initiative Estonia
Jean Willain	EC - DG ENV

‍

Annexe

En anglais dans le texte, voici un descriptif synthétique des principes d'architecture spécifiques à l'eFTI par le DTLF, parce qu'on n'est jamais mieux servi que par soi-même.

‍

ID	Principle	Definition
P1	Data is Shared at Source	The eFTI exchange environment provides the participants the ability to securely share access to data among each other, without the need to copy the data locally in their own systems or eFTI platforms in order to process it. When an economic operator makes the information available through their preferred (certified) eFTI platform, the competent authority can “pull” the information from that eFTI platform when needed and justified. Other economic operators in the logistics chain may also access and process the data subset(s) on the eFTI platform of their business partners, data subset(s) that they can also uniquely identify using the “pushed” metadata.
P2	Data sovereignty	The participants to the eFTI exchange environment have the ability to control the access to the data they legitimately hold. The data holders keep authority and control on data in accordance with applicable European, national or international legal provisions, as well as business agreements. They attach usage restriction information to the data that that can be accessed by public authorities and supply chain participants, in line with the provisions in these legal acts and, where appropriate, business agreements.
P3	Decentralized approach, common rules of interaction	The eFTI exchange environment is established as a decentralized network of nodes (ICT systems) that interact by following a common set of rules that defines their (minimum) behaviour. These common set of rules are defined by the eFTI implementation specifications (delegated and implementing acts). All nodes
P4	Trust, Non-Repudiation by Default	The eFTI exchange environment has built-in features that ensure that all participants can have proof of the origin and the integrity of the data. In practice, such features make it very difficult for any participant successfully claim not knowing from whom or from where a message came from or deny the authenticity and integrity of that message. The result is a network of participants who can know and trust each other. This trust needs to be upheld by design or through governance, both at the level of the network’s nodes and individual actors (legal and physical persons), and at the level of actions.
P5	Security, Appropriate authentication	The chosen method of authentication shall be as reliable as appropriate for the purpose of the data message. Avoid creating electronic solutions that are more cumbersome or costly than the manual process.
P6	Roles and Rights, Authorization	Data holders making data available in the eFTI exchange environment can exercise fine-grained control/authorization of who can have access to which of their data for what purposes, including the access granted to control authorities.
P7	Once-Only	The eFTI data related to a specific shipment or transport operation is recorded only once on an eFTI platform, the “source eFTI platform”. Authorities other business partners can access this data on the source eFTI platform by means of the metadata/ unique identifying link. The economic operators who (are obliged to) initially collect and prepare data and (where applicable) metadata should provide it to the eFTI platform, as well as provide the metadata/unique identifying link for accessing that data. The source eFTI platform maintains the data (and potentially disseminate edits and updates).
P8	Open specifications and standards, interoperability	The design and implementation of the systems in the eFTI exchange environment give preference to open specifications and standards, taking due account of the functional needs, maturity and market support and innovation. Interoperability with existing systems or under development relevant for the transport and logistics sector is another main criterion when setting those specifications. The architecture concept shall allow the easy integration of already existing systems and ensure interoperability with them and with new systems. Thus, allowing a smooth integration with the existing systems. Both national, sector and platform specific systems.
P9	Technology independence	The eFTI exchange environment architecture concept is independent of specific technology choices and therefore. Therefore, it has the ability to run on a variety of technology platforms.
P10	Benefits outweigh investments, Level playing field	For as many parties as possible benefits should outweigh costs as much as possible. All economic operators, independent of size, can take advantage of the efficiency increase, with the same opportunities to participate in the eFTI ecosystem. For all actors on the market, benefits outweigh the costs of participation. For the authorities, the benefits of efficiency and effectiveness of policy monitoring and enforcement in particular, are maximized, including with a longer term view.
P11	Support a Transition Period with Both Paper and Digital Evidences	The eFTI exchange environment architecture allows logistics operators to use processes that support paper (digitalized proof, but originals as papers) and digital transport documents, at least for the period
GP1	Holistic Thinking	The architect should strive to think holistically about the system, its components, its usage contexts, and other relevant systems.
GP2	KISS	Keep It Simple and Stupid (… and robust). Architectures that are more complex than necessary will result in sub-optimal systems. Essential complexity is that which is essential to deliver functionality before complexity slips in. Functionality drives complexity in any given concept. But “Functionality” is often defined as a surrogate for a much broader set of functions for which the product will be used. Therefore, it is the (often implicit) robust functionality which drives essential complexity.
GP3	Scalability	The design of the IT solutions allows them to be adaptable to an increase of users, interactions, data sizes, etc. in order to ensure their continuous functioning/availability.
GP4	Modularity	Build IT solutions from cohesive, loosely coupled components (modules). One of the architect’s roles is to ensure the best modularization of the system architecture, so as to allow for all the benefits of modularity: easier testing, easier accommodation of new requirements at the component level, and easier accommodation of new components at the system level.
GP5	Distributed Operations, Maintenance and Development	The operations, development of new features and maintenance of the access points and common set of rules. There will be specific groups/associations that specify their data requirements with their members. These specifications can be aligned with the overall model. The same approach can be applied for regulatory compliance.
GP6	Sustainability	The platform should ensure first, its carbon emissions in its operation and maintenance are reducing as foreseen in the EU strategy. Second, the platform should enable the sharing of emissions data between Economic Operators and Authorities. Foreseeing that the near future will include reporting of carbon emissions in freight transport, the eFTI platform will need to support the control that the reported emissions are indeed correct.

‍