• Ann Lambrecht

The first comparison between food transparency platforms!


As independent Product Transparency Architect, I have been exploring several blockchain platforms which are commercially available in Europe.

Here a comparison of 2 platforms, active in Europe and targetting the agrifood value chains. As third option, I take a self-deployed blockchain-network.


Please give comments and corrections. I'll adapt my blog when appropriate!


Both transparency platforms target the agrifood supply chain and although there are many similarities, it is interesting to see, how they developed a totally different product.

I start by describing IBM Food Trust , https://www.ibm.com/blockchain/solutions/food-trust at 3 different levels: IT level, Data level, and ecosystem level.

And then I list the options OriginTrail. https://origintrail.io took in putting its offering on the market.


For both products, I relied on publicly available commercial and development documentation.

I am very open to any correction and comment, as this domain is evolving every day and I also want to learn myself! So please don’t take anything underneath as a biassed opinion, I am not a blockchain expert and do not have a looking glass into the future transparency market !


I did not include other platforms like for example provenance.org in my comparison.

Provenance.org is providing an even larger full service scope from technology up to marketing and business strategy, but currently focusses primarily to the UK market. As the mother of all transparency platforms, very interesting to follow!


I make abstraction here for the need of blockchain, the need for product transparency or end-to-end traceability or the need for sharing of data along a supply chain. I just assume the business requirement is there.


So , let’s start by describing how IBM Food Trust is setup !


The most important dimension to look at is the business ecosystem level.


IBM Food Trust is targeting all food supply chain partners in the world, which they estimated being the following number of companies: 570.000 farmers, 1 mio food suppliers, 126.000 food processors, 1.9 mio logistics companies, 33.000 retailers, 2.7 B customers, 600 regulators. Since many supply chains in agrifood are global, with many suppliers delivering food products via many different channels , one cannot easily identify totally independent sub-communities.

Therefore IBM Food Trust has been implemented as a “Global Food Business Data Sharing platform” : one shared SAAS platform accessible by any food related company in the world. It currently has approx. 100 customers of which several major retailers and food companies in the world (Wallmart, Carrefour, Nestlé, Unilever, Driscoll’s, Kroger,…) and some of its suppliers up to the farms.


(There is an option to deploy the whole setup of IBM Food Trust in a private way also , but I don’t consider this option in this blog , as this offering is only available via IBM Sales in a customized service offering).


In IBM Food Trust, a lot of design options have been taken care of, within the offering, at the 3 levels:


1. At IT level


- the blockchain is chosen: a Hyperledger blockchain, a permissioned private network, accessible via the platform by all member-companies. No discussions anymore which blockchain to select and how to implement it.

- The IBM Food Trust implementation of blockchain serves its major goals:

  • immutability, privacy , security, consensus and accountability for data

  • in a data sharing context with business partners who are known upfront (permissioned users (so no anonymous or public users) with the correct entitlements can get access to certain data)

  • Because of the very large target community, no smart contract logic is provided for the moment. The network does not apply any extra controls or automation on the provided data (for example quantities at shipping and receiving end can be different..). This is quite practical for a “neutral” implementation , where all logic can still be done at the application side, but where the network remains agnostic of any specific business rules.

  • The platform is implemented and running globally , decentralized, in IBM’s cloud datacenters and in some of the customer cloud datacenters, and supported globally.

  • The technical platform are managed and operated at IT-technical level by IBM, but IBM personnel do not have access to any data and IBM certainly does not use any of these data for any purpose.

  • No implementation services are needed at this IT level, since the SAAS is already implemented and running in production.

2. at Data Level


  • In order to share data between companies , one has to agree on the data coding standards. A standard to describe “visibility events” in logistics already exists . It’s called EPCIS and is issued by GS1, the same global organization which also issues all product codes when products are sold in retail with barcode labels , and also issues the EDI standards for shipping and invoice interfaces between suppliers and retail.

  • Therefore it’s only natural that IBM Food Trust also works with this standard.

  • What is special, is that it also allows “private codes”, which also follow the EPCIS standard, but are not based on the GS1 product (GTIN) and location (GLN) codes. For example, farms typically don’t have a GS1 company prefix yet. Farm products like for example living pigs, cows, truck loads of vegetables also don’t have a GS1 product code yet. So in any implementation of IBM Food Trust, one has to agree which codes to use for these entities within its subcommunity. One could for example use the standard codes issued by a regional farming datahub .

  • An IBM support desk is available to all customers for assistance in posting data and using the functions of the platform.

  • Implementation services can be offered either by IBM or by a local IBM Trusted Business partner, but it is important to mention here that the only implementation required is

  • a data posting interface between a company’s internal systems and the IBM Food Trust platform. So these services are at the “Data” level or “internal company IT” level and do NOT require any blockchain setup!

  • There are 2 options here:

  • 1. posting .xls files with a manual User Interface provided by the standard platform (no developer knowledge required to use this interface!)

  • 2. posting .xml files or converted .xls files via an automated program with REST API’s. Any developer can use these API’s!

  • Optionally, one can use predefined API’s, to get data out of the platform to use in an own developed application.

3. At Ecosystem and application level


  • Any data sharing network needs functions to accept and register new companies, users. IBM Food Trust offers this function , based on the company registration number of a company. Usage of the platform is invoiced locally by the local IBM company, available in most countries worldwide, at monthly prices which are publicly available. (companies who only post data do have to register, but get a free access to post data).

  • The evolution of the platform is governed , not by IBM, but by a committee of members, representing the Food customer community. All this is described publicly. The current committee consists of large retailers and large food companies, mainly in the USA, but now also starting in Europe.

  • Besides the basic Trace function, the platform also offers extra modules which might be useful for one or more Food company members. Following modules , priced separately, are currently available:

  • An API to request Trace data our of IBM Food Trust for use in for example a consumer app.

  • Certificate Management (Upload, share, and view certifications with supply chain partners)

  • Fresh Insights (View the freshness history of your food products, by expiration, best-by, or use-by date. Add registered products, and view your users and your pallets)

  • The platform is also open for other companies to develop extra modules.

So , how does OriginTrail compare with this?


In general OriginTrail targets any community which wants to implement trusted traceability . Food is one of their target markets, but also any other goods (logistics, pharmaceutical,…).

OriginTrail is a blockchain based protocol), that can be setup for any community.


(for example Halal Gtrail Ltd. is setting up a platform to prove the halal origin of food, their community is the total number of companies using their SAAS platform)


So here already a main difference. IBM Food Trust is an implemented SAAS platform for the Food Supply chain . OriginTrail provides a protocol to be implemented at your specifications for any community.


Let's dive a bit deeper in the comparison:


1. At IT level


- Tracelabs, a startup company from Slovenia, with 3 offices now in Slovenia, Serbia and HongKong, provides the protocol, called OriginTrail in Open Source.

- This protocol can work with different types of blockchain (Ethereum,…).

- Tracelabs launched a Partnership hub, called TraceAlliance, with now 75 members, typically IT Service Providers.

- A TraceAlliance Service Provider has to deploy the network.

- The data network is operated like a public network . A node holder can be any Service Provider. They are incentivized for their operations work by Tokens (like the miners in cryptocurrency networks). These Tokens are exchanged at a USDollar price on a cryptocurrency market. https://coinmarketcap.com/currencies/origintrail/


In IBM Food Trust all this is embedded in the SAAS platform.


2. at Data Level


- OriginTrail uses the same GS1 EPCIS standards as IBM Food Trust.

- IBM Food Trust simplified the codes according to this standard in 2 groups:

  • GS1 existing codes

  • IBM Food Trust codes (codes issued by the platform)

- In OriginTrail , the original GS1 EPCIS Standard is started from, leaving more options, but complicating a first project.


- Support at data level has be given by a TraceAlliance Service Provider


  • Knowing the EPCIS standards

  • Knowing the specifics of the standard set of common applications developed by Tracelabs, the provider of the protocol of OriginTrail, such as:

  • 1. network deployment tools: Software that helps setup and deploy the protocol

  • 2. API’s to help implement an interface between Origintrail and your ERP (SAP, Oracle,..)

  • 3. Consensus Check: implementing smart contract logic between sets of data coming from different origins (e.g. verifying that the quantities at shipping and receiving end are the same)

  • 4. Graphical user interface for a supply chain mapping and creation of the nodes

  • 5. Template consumer provenance app

  • 6. Track and Trace Application

IBM Food Trust is also providing most of these functions.

  • 2. , 4 .and 6. is also provided by the IBM Food Trust in some way.

  • 1. is not needed.

  • 3. is not provided in the current version

  • 5. is provided in the form of an API. The consumer app itself can be developed by any developer.


3. At Ecosystem and application level


  1. Any data sharing network needs functions to accept and register new companies, users. This has to be setup by a TraceAlliance Service Provider.

  2. The evolution of the protocol and common applications is governed by TraceAlliance , a service provider community.

  3. The Service Provider is needed to support the environment and the applications.

  4. The implementer of the community governs the evolution of the platform.

And how does this compare to a self-deployed blockchain setup?


1. At IT level


One needs blockchain experts who can deploy a blockchain network. They are quite scarce and expensive and speak a quite complex “blockchain language”. There are many different blockchains and one has to be carefull not to end up in a “blockchain project” instead of a “food transparency project”.

A lot of options have to be taken, which impact the business functionality and the ecosystem. So therefore, one needs a very good knowledge of the business case requirements to give the right input to the blockchain experts. This is the most difficult part !

Support on IT level has to be given again by these scarce blockchain experts.


2. At Data level


To be modelled in the project. EPCIS can be used, but still a lot of User interface and applications to be developed to post and access data.


3. At ecosystem and application level


All functions to be designed and developed. Nothing out of the box.


Selection recommendations


So, with selecting between these 3 totally different business models,

  • IBM Food Trust, a global SAAS model

  • Origintrail, an opensource protocol provider with an alliance of Service Providers,

  • Self deployed blockchain

I would recommend the following in the following cases:


  • Food companies or retailers operating in a global supply chain, needing data exchange with its partners in a global world : use IBM food Trust directly (no need for complex setup, no need for a specific Service Provider, no need to buy tokens, support available globally, no initial setup cost, only pay per use contract needed with local IBM company and an initial local business partner of IBM to guide the first project.)

  • A platform provider with an internal traceability requirement between different companies, with extensive “smart contract” requirements, who wants to make accessible its trace information to the large public on a public blockchain etc. : setup your own community inside your platform based on the OriginTrail protocol.

  • Implement a pilot project with 3 companies, with the least amount of effort, focusing on the business case: use direct file exchange , and scale with IBM Food Trust when needed or when needed for accountability between the partners)

  • Don’t start a self deployed blockchain project , if there are commercially available offerings at a higher level in the IT and business function stack.

Scalability


For the moment I do not have information or experience with the scalability of both solutions. IBM , as one of the founding members of Hyperledger , and as global technology provider, should be able to scale its platform together with its customer base.

OriginTrail still has to prove the scalability of its business model, its technology and its business overall.


Interconnectivity


Since IBM has only one global implementation, any customer can interconnect with any other customer without any issues.

Separate blockchain networks are not interconnectable for the moment.

The market will evolve towards 1,2, 3 leading providers and these providers will then make bridges between them. IBM is already working on such an initiative with a private blockchain network.

I assume that 2 separate OriginTrail communities are not interconnectable either. But I assume interconnecting 2 OriginTrail communities might be simpler than connecting an OriginTrail community with an external blockchain platform.


Lost efforts when having to change the platform


Since both platforms use EPCIS , the analysis work done at data level can be largely kept.

There will be some “porting” work, since standards are never defined and implemented for 100% of the data.

But all technical setup work, required to initiate an OriginTrail base community is lost at that moment. At IBM Food Trust there is no technical setup work.

Both platforms provide API’s to post data. The customer application using these Api’s will have to be adapted to use the other one.


Conclusion


With OriginTrail , one has more degrees of freedom, so more decisions to take upfront, more work upfront and all business ecosystem work has to be organized by the community project.

With IBM Food Trust, the technical, data and ecosystem decisions have been made by the platform and its current community. Just follow the community unless you encounter a requirement which really makes the customization unavoidable and required.

Never use a self-deployed blockchain, if you can use commercially available platforms at a higher level in the IT and business logic stack, providing the required functionality.


0 keer bekeken