eFTI Architecture S01E01 - Principles

05/18/2022

Reading time:

4 minutes

eFTI Architecture S01E01 - Principles

18/5/22

Reading time:

4 minutes

Contents

#Briefing

DTLF SG1 "Paperless transport" Team 3 TaskGroup 2 is working on general rules and guidelines for the use and deployment of IT resources in the eFTI ecosystem. We're not so much kidding around as in some of the previous articles, as we're starting to get into the nitty gritty with those who have their hands in the conceptual dirt. First article of a series on the eFTI data model as the DTLF starts to formalize these guidelines since March 2022.

‍

Reminder: Second dose

Let's start with a reminder of the organization of the DTLF, which is good to keep in mind when reading the work of the DTLF, since it is the skeleton around which everything revolves and it is a very useful jargon, however jargon it may be:

DTLF SG1: Paperless transport
Team 1: Data modeling
Team 2: Functional aspects
Team 3: Technical aspects → The one we are interested in here!
TaskGroup 1: Legal requirements (Eric Grandry)
TaskGroup 2: eFTI main architectures (Rudy Hemeleers) → The one we are interested in here!
TaskGroup 3: Functional architecture
TaskGroup 4: Building blocks catalog
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
This subgroup is directly connected to FENIX and FEDeRATED

‍

Methodology and process

The working group uses the TOGAF methodology to define the reference architecture principles for eFTI. It is a methodology supported by the Open Group. The Open Group was created in 1996 at the end of the UNIX war by merging the Open Software Foundation and X/Open with other groups in the past to carry neutral standards in the computer engineering domain. TOGAF has become an industry standard for enterprise IT architecture. It is based on three concepts: the ADM cycle (in eight requirements-based phases), the content framework (classifying all the elements involved and their relationships in the form of an ontology/meta data model), and the capability framework (defining the structure that will implement the architecture). But enough of COBIT, ITIL, and ADM, we will remember that the eFTI architecture principles have been defined in two groups:

‍

ID	Principle	Description	Profit	Point of reflection
P1	Data is Shared at Source	eFTI platforms are decentralized access points for publishing data	The information is synchronized without the need for duplication at the level of each actor thanks to a unique identifier for each data subset	What will be the data mining mechanism? If the data is never duplicated, how to manage the multiplicity of eFTI platforms to decide which eFTI platform is THE source?
P2	Data Sovereignty	The owner of the data remains the sole owner of this data by the regulations in force	Ensuring trust in the ecosystem in line with the RGPD	The management of access authorizations by each economic actor involves determining which actor can see what, for how long, and within which perimeter of the chain.<br>
P3	Decentralized Approach, Common Rules of Interaction	The exchange of information will be done through the nodes of a network whose rules will be defined in the Delegated Acts and the Implementing Acts	Two types of systems support the ecosystem: the eFTI platform for economic actors to publish data and authorities' systems to validate them	An issue on the Access points (details to follow) and their operating methods (exchanges between access points? unique A2A exchange? opening to a B2A network?
P4	Trust, Non-Repudiation by Default	Mechanisms guarantee the origin and integrity of data in the eFTI ecosystem	Building trust and adoption of eFTI practices	ALL transactions must be recorded in a register for future reference. Stakeholder trust issue
P5	Security, Appropriate Authentication	Implementation of an authentication method adapted to the exchange of regulatory data	The mode of access to the ecosystem must facilitate exchanges, not the opposite	The multiplicity of users: natural persons, legal entities, computer systems, and access points. The fundamental need to implement alternatives to the traditional signature. Based on the maturity of eIDAS-type mechanisms (EU Regulation 910/2014). Integration of EORI for companies
P6	Access and Rights	The owner of the data controls its access by third parties (including the competent authorities)	Ensure confidence in the integrity of the data throughout its life cycle.	Stake on the delegation of ownership and access. Compatibility with eIDAS-type authentication mechanisms? Adaptation to a decentralized mechanism? This is one of the most difficult principles to define today
P7	Once-Only	Respect of a unique eFTI platform called source which is in charge of storing data and broadcasting the unique identifier	Authorities can access ALL the information of transport (including multimodal) in a single request	Conflict resolution issue if several platforms control the data. How to define the official source? The first to publish? An ad hoc agreement? How to manage the delegation of rights?
P8	Open Specifications and Standards, Interoperability	Prioritization and reuse of open (non-proprietary) standards and interoperability with existing and developing systems	Ensure the easiest and broadest possible collaboration	Involves comprehensive and widely distributed documentation. Examples of standards: are TAF-TSI (Rail), RIS (IW), eTIR/eCMR (Road). DIGINNO also relies on the PEPPOL infrastructure to save time. Who maintains the standards? How to deal with the current lack of multimodal standards while reusing existing standards?
P9	Technology Independence	Ability to work in the eFTI ecosystem with any type of technology	Increased accessibility and possibility of evolution by avoiding technological dead ends	Involves combining historical solutions (sometimes proprietary) with the latest technologies
P10	Easy Deployment, Integration and Transition	The benefit of the deployment should more than offset the cost	Reduction of digitization costs for all networks (B2B, B2A...), even beyond the initial scope of the eFTI	Compatibility issue with tools widely deployed in SMEs. Cutting short solutions that would only benefit large companies with greater resources to update their systems. Availability of user interfaces in all EU languages with an implication on the synchronization of the versions installed in each player
P11	Support a Transition Period	Each economic actor is free to continue using the paper version during a probationary period	Three choices: Paper or Paper + Digital or Digital + eFTI certification	The eFTI ecosystem will have to be compatible with a hybrid process to take into account the paper documentation. A paper exit door will have to be maintained in the long term, especially in the case of goods leaving the EU
GP1	Holistic Thinking	Consideration of the whole system in each design choice	The implementation of a new component in the ecosystem must be subject to an impact study to confirm that it brings more benefits than drawbacks.	The issue of the coordination of all stakeholders and potentially conflicting interests for the use of a given functionality
GP2	KISS (Keep if simple and stupid)	Avoid complexity that does not serve an essential function	It is the core of the machine that must dictate the level of complexity of the whole	The issue to never lose sight of the goal of the eFTI ecosystem and the functions needed to achieve it. Topic actively under discussion.
GP3	Scalability	Capacity to absorb an increase in users	If the ecosystem achieves its goal, it will have to be able to process all documentary transactions on the territory of the EU	Very strongly linked to the holistic design of eFTI
GP4	Modularity	Creation of a set of coherent components that are as little interdependent as possible	Facilitates the maintenance of the ecosystem, the identification of bugs, the scalability	The subject is under active discussion.
GP5	Maintenance and Development	Maintenance of access points and dissemination of guidelines	Taking into account the needs expressed by user groups, associations, or regulatory constraints	Compatibility with various data repositories (XML, JSON-LD, RDF). Governance issue that will manage the changes made in the ecosystem.
GP6	Sustainability	Staying in line with EU policies and objectives for environmental sustainability	A technical base optimized in terms of energy consumption	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 principles that follow from the eFTI regulation (P1, ..., P11).
6 principles that derive from the general principles of IT architecture (GP1, ..., GP6).
For each principle (Name), we briefly describe the rule that it embodies (Statement), the benefit that we expect from it (Rationale) and the consequences that it implies (Implications). Wherever possible, the related considerations are detailed: link with the work of other working groups, alternative solution or limitations (Discussion) and mention is made of the projects that materialize the principle (Reference).

‍

eFTI seeks architectural mantra

The architecture principles are the mantras of a Big Brother that would not have turned sour, of an Oceania where War is peace becomes Data is shared at source, Freedom is slavery becomes Technology independence and Ignorance is strength becomes Holistic thinking. Below is an attempt at synthesis, a little desperate given the richness of the subject, which gleans some ideas from the Statement, Rationale, Implication and Discussion of each principle.

‍

With a large number of working groups in operation, it is now time to consolidate and compare the results of each group's work. The purpose of the gaps analysis is to identify discrepancies and inconsistencies in the work done by different groups. There are three types of gaps analysis that can be used for this purpose.

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)
They allow to enrich and harmonize the efforts of the different groups.

‍

Gluttony is a bad habit

Here are a few reference documents that constitute references in the ongoing work of the DTLF, most of them purely technical or normative, while others are feedback on full-scale experiments such as the CEERIS. We learn less about the metaphysics of human existence than in Dostoyevsky, but a little more about the paths toward European interoperability than in Capital:

Reference architecture model of the IDS (International Data Spaces).
The Once Only Principle Project supported by Horizon 2020 within the European Commission.
The EIF (European Interoperability Framework) is driven by the EU.
The WCO (World Customs Organization) publication Dematerialization & paperless processing.
UNECE recommendations on document validation without signature.
The architecture principles of the RIS (River Information System) on the implementation of an IWT (Inland Waterways Transport) system which takes the form of CEERIS in Eastern Europe.
Principles and feedback from FENIX and FEDeRATED (e.g. within the Master plan).
The EUDIN (European Data Interchange) interface on waste regulation, whose site has disappeared but of which there are still some traces on the European Commission site.

‍

Do you want to be more productive?

Schedule a demo

‍

Who is going to do it?

‍

Here is a list of DTLF SG1 Team3 TG2 members:

Name	Organization
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

‍

Appendix

The following is a summary of the architecture principles specific to eFTI developed by the DTLF, as no one knows it better than the DTLF themselves.

‍

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 systems or eFTI platforms 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 in the eFTI exchange environment can control the access to the data they legitimately hold. The data holders keep authority and control over data following applicable European, national, or international legal provisions, as well as business agreements. They attach usage restriction information to the data 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) behavior. These common sets 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 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 and other business partners can access this data on the source eFTI platform through 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 disseminates 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 to 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 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 can 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, the 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 that drives essential complexity.
GP3	Scalability	The design of the IT solutions allows them to be adaptable to an increase in users, interactions, data sizes, etc. 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, 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 to regulatory compliance.
GP6	Sustainability	The platform should ensure first, its carbon emissions in its operation and maintenance are reduced 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.

‍