Le Hub - ONE Record for humans

by Im3pact


Posted on 10 Dec 2022


Logistics Event Hub homepage

Earlier this year we teamed up with Webhookie, Scan Global Logistics, KLM Cargo, and Swissport to participate (and actually win :-) in IATA’s ONE Record Hackathon in Amsterdam. In this post we look at what is new and different about ONE Record vis-à-vis the traditional message-based data exchange standards from a process and business perspective.

What strikes us in discussions around ONE Record is how often this is primarily viewed as a technical upgrade, from EDI to API. What we seem to struggle with is articulating the impact ONE Record can have from a business and process perspective. So below we are taking a stab at outlining where we see some of the key changes (and challenges) ONE Record can bring to our industry.

In general, electronic data exchange across company boundaries in international transport logistics has come some way in digitizing paper-based processes (“eFreight”). However, the paradigms and standards on which this data exchange has been based in the past have also limited its potential to pragmatically solve real-world operational challenges between the players in this fragmented transport chain.

For example, the operational data messages traditionally exchanged are largely based on transport documents – we have “digital twins” not of physical objects in the transport chain but of pieces of paper used in the process. This imposes a number of limitations and challenges:

  • Key documents underlying these data messages (e.g., HAWB and MAWB) are only accessible to the two parties between which the document constitutes a commercial relationship. Data elements which apply throughout the transport process (say commodity information or a handling instruction) will have to be replicated in different messages without having a single source of truth for these elements (and in some cases not even consistent semantics).

  • Conversely, data elements that apply to only one segment of the transport chain are added within this segment but then carried along throughout subsequent segments. Customs status and screening instructions are examples of this.

  • It becomes difficult to extend the scope of data exchange beyond the core group of participants linked to the respective documents (say forwarders, airlines, and their subcontractors), even though the individual data elements have much wider applicability (and in many cases ownership) from shipper to consignee and other third parties.

  • The model becomes very hard to adapt and extend without also changing the underlying documents, making this process painfully slow and cumbersome. Two or more parties seeking to exchange only a small piece of additional data to address a specific operational issue may spend years in pushing required extensions to the existing standards.

  • The underlying documents have a long history of being highjacked for purposes they were not designed for. In the process, they have accumulated various extensions and add-ons that facilitate workarounds for purposes other than the original transport document (Letter of Credit, Customs Filing, PLACI, etc.). This now presents an extra challenge when trying to remove the paper contract of carriage or dismantle the electronic versions of it.

This document-centric, message-based model also leads to a linear data and information flow, mirroring the physical flow of goods and documents where exchange only happens between (contractually) adjacent parties, thus preventing timely visibility of information across the entire chain. For example, the party with the best ability to mitigate or resolve an exception occurring along the transport may not have access to this crucial information. There is also no mechanism to define, configure, and maintain the rules governing which data can be shared with which parties at a sufficiently granular level.

On the technology side, interconnected message exchange hubs have become the middlemen in this world. Originally labelled “Cargo Community Systems” (CCS), these platforms have provided a useful service in allowing their members to just connect to one hub rather than to myriad of supply chain partners. However, as new technology and emerging standards increasingly support lightweight, self-service connectivity between individual players, the hubs that facilitate the traditional message exchange risk becoming an impediment to progress. While they provide connectivity to virtually any party connected to any CSS, they enshrine the document-centric, message-based protocols of the past. They also foster a “lowest common denominator” mindset where the least capable member of the community tends to set the pace of change.

In global airfreight, the emerging IATA ONE Record standard is a giant leap forward to overcome the limitations imposed by the legacy exchange model:

  • It decouples data from documents, avoiding duplication of data and allowing for a single source of truth for any particular data item. Where needed, documents can be created by re-mixing the required data elements on the fly. At the same time, downstream processes don’t have to wait for a document to be complete to access a specific data item in that document if the item is available earlier.

  • It resists the temptation to centralize the repository of these unique data elements and rather implement a distributed shipment record through a domain specific semantic web, allowing parties to find and access the data they need (provided they are properly authorized – see next bullet), independently of where a particular data element is stored.

  • It allows for fine-grained control of who can access what data, including the ability to delegate authorization for access to establish chains of trust.

  • It does this through lightweight modern technical protocols, supporting an intuitive publish-and-subscribe logic that is aligned with the event-driven nature of the underlying business process.

  • Through all of the above, it is (relatively) future-proof, as it can flexibly evolve with changing requirements.

In principle, this new standard supports a world in which it becomes easy for any two or more players in the transport chain to collaborate by exchanging the precise data they need to solve a specific business challenge in near real-time with minimal overhead. This is particularly useful for event data generated along the transport and associated exceptions. Timely sharing and visibility of events and exceptions is crucial to effectively manage the flow of cargo and to prevent small hiccups from turning into major disruptions.

There is a catch however: by (rightfully) resisting the temptation to implement ONE Record on one central platform the new model requires individual participants to implement (or have someone else implement on their behalf) a ONE Record compliant server to make their data discoverable and shareable under the new protocol. As tools and capabilities mature, this may become as normal as hosting the company website. At the moment though, in an industry with tens of thousands of small to medium sized participants, this poses a formidable adoption challenge.

Our hackathon entry, the Logistics Event Hub, seeks to overcome this adoption challenge by combining three aspects:

  • Rather than tackling the entire scope of transport related data, it focuses on logistics events - i.e., status updates about the cargo in transit or the underlying business process. This allows Le Hub to provide a domain-specific framework in which participants can use preconfigured tools to quickly address specific transport execution challenges.

  • It is built on the ONE Record standard, thus reaping all the benefits outlined above.

  • Participants may use Le Hub as “their” fully managed, ONE Record compliant server to make their event-related data discoverable and shareable, while exercising fine-grained control over what data is shared with which parties. Using Le Hub as an externalized ONE Record Server for specific (event-related) use cases is optional. Participants can at any time choose what portion of the technology they want to manage themselves, either in the cloud, on their own premises, or with another third party, as long as it complies with the ONE Record API and security standard.

The focus for Le Hub is on the first bullet – helping to solve real world challenges in global transport chains. The third bullet provides merely a convenient on-ramp for parties who are new to this, and who are not yet ready to implement their own ONE Record compliant platform. The intent is to have the third bullet above fade away over time, as participants own capabilities and available tools mature. By maintaining this focus, Le Hub avoids the lure of becoming yet another centralized aggregator of data. Instead, it enables the people involved in solving the actual logistics challenges to leverage future-proof, scalable technology and forward-looking standards for their specific needs.