We use cookies to improve the relevance of our website when you interact with it. Cookies help us to understand how you use our website so that we can tailor content to you. For more information about the different cookies we use, read the Privacy Policy.
Cookie preferences
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Logistics blog


eFTI Architecture S01E01 - Principles

eFTI Architecture S01E01 - Principles


eFTI Architecture S01E01 - Principles

Reading time:
4 minutes
eFTI Architecture S01E01 - Principles

eFTI Architecture S01E01 - Principles

Reading time:
4 minutes
eFTI Architecture S01E01 - Principles


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:

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


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.