ISG Software Research Analyst Perspectives

SAP Highlights Its Blockchain Efforts

Written by Robert Kugel | Mar 26, 2018 7:07:01 PM

SAP recently held a teleconference to highlight its blockchain strategy. Lately, the major business software vendors have been calling attention to their blockchain initiatives. While the focus on this technology might seem premature to those who still equate it with cryptocurrencies, evidence is pointing to a future pace of adoption similar to the rapid take-up of the internet in the 1990s. That blockchain is useful for a wide range of business functions isn’t news – just google “blockchain use cases.” Payment, provenance, testament and efficiency are four main themes driving a multitude of applications of the technology. That said, blockchain isn’t technology in search of a mission but is something more like the internet, both in its broad utility and in value multiplication through network effects.

SAP has been energetically pursuing the application of blockchain technology to its offerings under its SAP Leonardo brand. Specifically, the company highlighted pharmaceutical traceability from factory to consumer as an example of how it can be used to serve all interested parties – manufacturers, marketers, wholesalers, regulators, healthcare providers, retailers and consumers. Verifying that the pharmaceuticals are genuine, not counterfeit, and monitoring prescription purchasing are two practical applications of the use of blockchains. Other use cases that SAP customers are exploring include distributed manufacturing using 3-D printing, secure bidding in procurement, supply chain security in pharmaceuticals and trusted digital credentials. Digital credentials have the potential to provide greater security of personal information as well as shift ownership of medical records to the individual rather than having them scattered across multiple systems or controlled by some agency.

SAP stated that over the past year its engagement with customers on blockchain efforts have moved from theoretical and exploratory to creating proof-of-concept use cases. It stated it has 3,000 members in its blockchain community.

While it’s still in its infancy, the adoption of blockchain technology is advancing faster than I, and I suspect most other people, expected. Protocols and platforms are maturing rapidly, spurred by an energetic open-source community and a broad belief that blockchain technology has great commercial promise

A recurring theme in SAP’s blockchain use cases is the technology’s ability to control data – and therefore data integrity – end-to-end in any process. Maintaining data integrity is essential to ensure trust between parties in commercial transactions. Better data integrity also supports a higher degree of process automation and a reduction of back-office workloads. Yet, I assert that data management is the main flaw in SAP’s and other vendors’ blockchain strategies.

Blockchain will not achieve its full potential without a universal system of self-describing data, as I detailed in an earlier research note. “Self-describing” means that the system that creates the data need not address what system is going to use the data, and those receiving the data will be able to interact with it without having to know anything about the system that created it. This sort of loosely-coupled approach is necessary for general purpose, permissioned commercial blockchains. This enables permissioned blockchains to serve as a sort-of USB data connector.

That noted, there will be many situations where it will best for blockchains to have unique data structures and protocols, especially for use cases requiring high-volume transactions between a defined set of trading partners such as interbank payments or securities trading. This approach will be desirable or even necessary in cases where efficiency in data transport is a paramount consideration and where the investment in proprietary, standardized forms of data interchange is small compared to the value of efficiency gains.

Therefore, at this stage in the development of blockchains, self-describing data should be a priority for technology companies and the open-source community. Otherwise we’re heading for a future where blockchains underperform their potential for three reasons.

Without self-describing data, valuable network effects are blunted by data interchange issues. An important reason behind the rapid worldwide adoption of the internet was the development of a standard protocol that enabled anyone to be connected to everyone. Metcalfe’s law states that the value of any telecommunications network is proportional to the square of the number of participants on that network. The internet is immensely valuable and has attracted so many users because of the absence of barriers to participation. Standard hypertext protocol and free browsers running on already ubiquitous personal computers were major factors spurring rapid widespread adoption. This precedent must be followed: Without self-describing data, the performance of computing systems will be degraded because of the processing overhead to handle the translation of data as it moves from system to system. And without self-describing data, costs will be inflated by the need for individual companies to create and maintain data mappings that manage data translations.

There’s been a great deal of progress in blockchain technology over the past year. Yet we still lack the architecture necessary to use 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

SVP & Research Director

To read more perspectives by Rob, visit https://robertkugel.ventanaresearch.com/