The use of blockchain distributed ledgers in business processes is now a common theme in many business software vendors’ presentations. The technology has a multitude of potential uses. However, presentations about the opportunities for digital transformation always leave me wondering: How is this magic going to happen? I wonder this because the details about how data flows from point A to point B via a blockchain are critically important to blockchain utility and therefore the pace of its adoption.
At this stage in the evolution of blockchain use it’s still necessary to mention at the outset that while all cryptocurrencies such as bitcoin operate on blockchains, most blockchains in use today aren’t associated with cryptocurrencies. Moreover, while cryptocurrencies operate in an unpermissioned environment, I expect almost all B2B interactions will occur in a permissioned blockchain environment. This discussion of developing blockchain technology has nothing to do with cryptocurrencies.
I’ve written about using blockchain distributed ledgers as a machine-to-machine universal data connector for business-to-business transactions. Tim Berners-Lee, the creator of the World Wide Web, anticipated that the internet would evolve to support a web of data, not just documents. He used the term “linked data.” Blockchains’ ability to serve as a universal data connector, however, depends on their ability to connect disparate systems with a “loosely-coupled” architecture that supports many-to-many relationships. In computing, a loosely coupled system is one in which each of its components has little or no knowledge of the details of other components. When two such systems connect, the sender communicates a message in its native form and format in the expectation that the receiver will be able to fully and accurately understand the content of that message.
To do so, however, requires some form of semantic standardization. This is achieved when the data format and the protocol used to structure the data makes it possible for disparate systems to correctly process the data. Semantic standardization is not especially difficult to achieve in a narrowly defined task with a limited number of participants. In this arrangement, it’s relatively easy for the participants to agree on data structures and protocols. Specialized forms of semantic standardization can be useful for defined groups, especially those that exchange high volumes of relatively standard messages, such as in securities trading and interbank payment systems. This sort of specialized blockchain is useful and will be an important part of the landscape, but for broader utility a more generalized semantic standardization is necessary.
Establishing semantic standardization in a general-purpose, machine-to-machine universal data connector isn’t straightforward. To make this workable will require what I call “self-describing data.” Self-describing data “tells” any system reading it the form, meaning and context of the data. To do this will require the development of a syntactical system with dynamic extensibility for general business transactions. This would be similar to BLONDiE, which was developed for cryptocurrencies like bitcoin. This sort of syntactical system is a set of formal specifications that defines the data-related classes and concepts, their properties and roles. “Dynamic extensibility” means the system is structured to enable ongoing modifications and additions, a feature necessary for business-to-business commercial communication.
An existing example of dynamic extensibility is eXtensible Business Reporting Language (XBRL), which is used to make listed companies’ U.S. Securities and Exchange Commission (SEC) filings machine-readable by the SEC and investors. The systems that are used to report companies’ financial results are entirely independent of those used to “read” those reports. In between is XBRL, a taxonomy that all systems use to make the information in the filing understandable.
Semantic standardization in a general-purpose, machine-to-machine universal data connector needs an architecture to ensure self-describing data is always understandable. This must not be an afterthought but a part of the current efforts if blockchain technology is to be made useful for commercial purposes. Considering this issue now should limit the damage caused by ad-hoc efforts that result in unwieldy and duplicative approaches to data interchange.
As a starting point I suggest the creation of an initial taxonomy designed for organizing more task-specific approaches to semantic standardization. I’ll leave it to others to decide whether there needs to be some sort of open-source group to curate the structure and how the process of creating and updating entries would work. This effort is similar to and would likely build on the semantic-web initiative but would be more narrowly focused so that a minimally viable result is available in a relatively short period to facilitate adoption.
Here are a couple of use cases that demonstrate how a general-purpose, semantic-standardization approach can be applied to a specific B2B interaction. One is the creation of open business networks that support the purchase and sale of materials and services using smart contracts. The other is cross-posting intra-company transactions to the other party’s general ledger.
Blockchains – permissioned ones in almost all cases – will serve as an open but secure platform for all forms of smart contracts that automate the B2B buying and selling process. Business networks for purchasing and sales already exist in the form of proprietary electronic data interchange (EDI) networks, which provide secure machine-to-machine connections to exchange documents. Open networks are likely to be available at little or no cost to participants because providers will use different business models to defray the cost of the service, for instance, as part of a broader or complementary service such as freight transportation or business-credit scoring or supported by advertising. In a low- or no-cost environment, buyers and sellers will want to belong to multiple permissioned blockchains. Publish-and-subscribe messaging will enable either or both sides of a transaction to post sales offers and tender offers to the blockchains and their enterprise software or some service that will interact with the blockchains. Software will either receive and filter responses for human intervention or automatically purchase items. Both will reduce the cost of buying and selling standard commercial products and services that lend themselves to this type of commerce.
The second example of a use of blockchains as a universal data connector is cross-posting accounting transactions. In contrast to the many eye-catching use cases for blockchains – global trade payments, securities trading, food provenance and medical health records, to name just four – this activity probably seems trivial but it can have an outsized impact on finance department operations.
Cross-posting would eliminate at the source virtually all the issues that create the need for intra-company reconciliations. For example, today when ABC Corporation’s legal entity Q sells a case of widgets to ABC Corporation’s legal entity R, the sale and purchase are recorded separately in the two accounting departments. Because the data is entered twice by two different people, it can give rise to inconsistencies. The price charged and paid for the quantities might be recorded differently. If the two operate with different functional currencies there can be a foreign exchange discrepancy. In some cases, there may be time stamps that fall in different accounting periods. When ABC consolidates its books at the end of the month, any discrepancy will cause the books to be out of balance. The cause of this imbalance then must be identified and reconciled. Reconciliation management software can reduce this tedious, time-consuming process. But cross-posting would go even further and make remediating inconsistencies a trivial task, especially for companies that operate globally and with extended or complex supply chains.
Note that I’m suggesting the use of blockchains to complement, not replace, the ERP system. Although associated with the word “ledger,” blockchains are data repositories, not transaction-management systems. Moreover, their strength as data repositories does not mean they should serve as the system of record for an organization because their structure is not optimized for transactions processing or the type of reporting and analysis that modern ERP systems can provide. Blockchain distributed ledgers are best employed as a universal accounting data connector. In this role, the blockchain distributed ledger would function as a publish-and-subscribe structure, with the lead publishing entity posting the entry to the blockchain. Every subscribing general ledger within the corporation would periodically “scan” the blockchain for posts made since its previous scan and use that data addressed to it to generate its own journal entry that faithfully mirrors the lead accounting entry. Cross-posting would shorten a company’s close process by eliminating the need to remediate almost all unbalanced transactions. The advantage of the publish-and-subscribe model is that it could significantly reduce the time and cost of integrating systems, especially after acquisitions.
There’s been a great deal of progress in underlying blockchain technology over the past year. Yet there’s a gaping hole in the development process: the lack of the architecture necessary for self-describing data in general-purpose blockchains. There’s still a great deal of work that must be accomplished to make blockchain a mainstream technology for businesses, so it may be jumping the gun to focus on the now-non-existent challenge of architecting blockchains to efficiently handle self-describing data. However, I’m raising the issue because decades of experience with IT-related matters makes it easy to foresee a data management issue. If we don’t deal with this issue in parallel with the development of basic blockchain technology, the mess that likely will ensue will impede adoption of blockchain and unnecessarily raise the costs of using them.
Regards,
Robert Kugel
Senior Vice President Research
Follow me on Twitter
and connect with me on LinkedIn.