The Ethereum public blockchain (“mainnet”) has been gaining quite some attention in the enterprise world.
Is it a solution looking for an enterprise problem, or is it more? Let’s see how the mainnet could be used in a traditional enterprise context to make web3.0 a reality.
A modern enterprise is not alone. Rich digital ecosystems contain partners, suppliers, platforms and customers. With APIs and blockchain technology you don’t have to do everything yourself. Partnerships are about finding your own core capabilities — let others take care of the rest. Yet as an IT Architect I see that integrating multiple enterprises is hard.
Manual B2B integration
Businesses have been relying on tedious manual communication to exchange information since forever. Even the biggest corporations call each other up to send details of a deal, reconcile payment data or confirm identities. On top of that, plenty of data is still transmitted in unstructured formats like PDF and Excel sheets. These files are hard for computers to understand and process. Data quality is low, and friction among businesses is high.
All of this results in a suboptimal experience for the end user. That is because customer journeys typically involve many steps, offered by different businesses. Take Real Estate Finance, where an investor is looking to buy a particular object. The journey involves manual steps where data is replicated and transformed.
What happens to this data? Can we be sure of the quality and validity? Is this all data? How much time did we consume in the process? There is no practical way to gain control of data across the ecosystem if it’s this chaotic.
API based integration
Of course, it can be improved: API’s to the rescue. API’s are great. They provide point-to-point connections between software components. This means machines can start talking to each other. Defining API’s forces developers to clearly structure the data and expose well defined interfaces.
The challenge is that API’s are usually exposed from the perspective of a single business. Enterprise thinking is still common today. A typical question is: what kind of services can we expose as an enterprise?
This leads to a jungle of potential connections with limited coherence. From an ecosystem perspective this is very challenging: all machines talk different languages. As a developer, it is hard to find your way through all these available interfaces.
Single source of truth
When I talk to businesses in the real estate sector, many seem to struggle with the fact that data is often out of sync. There is a tremendous need to have up to date and high-quality data, as if there were a single source of truth in the ecosystem. If we all know that we’re looking at the same version of the world, and talk in the same language about it, we have frictionless business interaction.
The typical architecture to solve this is by introducing a central data hub that mediates all data in the ecosystem. It provides a simple and standardized mechanism to share data across many businesses.
However, it comes with serious drawbacks. Centralized systems could introduce substantial risks. From an IT perspective there is a single point of failure: if the central system is down, the network is down. From a business perspective there is a lot of trust to be placed on a single entity. In financial industries this is generally not acceptable.
Blockchain technology promises a decentralized solution. It’s definitely not the holy grail for all problems. It should be well known by now that blockchains are useful to track ownership of assets. But there is a catch: they are particularly bad at storing data.
The point of blockchains is to figure out what needs consensus. On which data attributes do we need to establish a trust mechanism? A blockchain could be well suited for managing the data about the data, also called the metadata. This provides answers to questions like:
- What is the context of the data?
- What is the format?
- Where is it stored?
- Who is the data owner?
- How do I get consent to read or update data?
- Which data delivery agreements apply?
Data governance is what businesses want to reach consensus on. It is about making proper data agreements and decisions about the distribution of data. And this would fit better on a blockchain: the size of the metadata is much lower compared to the actual data.
Any metadata should include a description of the context. If you see metadata on the blockchain, you want to know what it is actually describing. Blockchains are already used for registering ownership of assets. This provides an excellent frame of reference for the metadata. Essentially linking ownership of assets to data is what this is all about.
Implementing this model to a public blockchain network would take this to the next level. For example, in the future real estate ownership could be registered in an ERC20 compatible token on the Ethereum mainnet (inner ring). Consumers and businesses have a high interest in assessing the value of the real estate before buying or selling the asset. So, they look at the metadata stored on the Ethereum mainnet (middle ring) to request access. The actual data (outer ring) is stored in a database at a particular business. After all, data does not belong on the blockchain.
By connecting an asset to a metadata ring, entities can request access to current and historic data related to the asset. The metadata can describe anything related to the building, think about: rental contracts, appraisal reports and maintenance. The building owner creates the building passport on the blockchain, and provides the essential integration hub for data residing anywhere in the ecosystem.
What remains is the exchange of the actual data. We have already been doing that for years using API’s and proven cryptography standards. There are industry specific syntactic and semantic data formats like ISO20022 and XBRL that already standardise inter-business messaging. Any request for data over an API can be verified against the data agreements stored on the blockchain. Various oracle services such as ChainLink exist that could bridge the gap from smart contract to external data.
Real estate is just an example. To truly bridge the gap between traditional enterprises and web3.0 we need to look broader than this. Question to you: how would this architecture hold for other asset types?
Data should be kept in databases. Data should be exchanged according to industry standards and the rules on the blockchain. Asset passports provide the necessary integration mechanism to make our ecosystems truly digital.