By Kirill Timofeev, Software Project Manager, DataArt At our consultancy, we are seeing more and more big clients looking at using distributed ledger technologies to change and eventually substitute existing business processes with enhanced alternatives, and it clearly shows that the market for distributed ledger technologies grows over time exponentially. Nonetheless, I ought to say that blockchain is not a revolution, neither is it a disruptive technology, it is foundational, meaning there are longer adoption cycles and broader impact. Although I share the enthusiasm for blockchain potential, I worry about the hype. Our blockchain experience tells us that if there is to be a blockchain movement, many barriers such as technological, governance, and organisational will have to fall. I came up with a blockchain hierarchy of needs, which is a generic concept that illustrates a minimal viable ecosystem to build a successful blockchain project. Fundamentally there are five layers: Servers, databases, networks, physical access, disaster recovery, etc. are all the requirements to run a distributed application across multiple networks in different organisations. Typically, it requires but is not limited to running and supporting containerised applications, following best practices to make environments disposable, setting up tunnels and security policies between companies and networks. For example, even a relatively basic Hyperledger Fabric blockchain solution requires two peer nodes, one orderer node, one certificate authority and a data-tier layer to run it. It is no longer feasible to manage infrastructure manually, automation is one of the many keys to blockchain transformation. Infrastructure — **Application and Data Structures -**Interface, logical access, data flow, data transformations. There are different flavours of a blockchain, and there is no silver bullet, each and every blockchain has its own strengths: Fat blockchains are technologies that can deploy and run programs or smart contracts (a certain logic that handles a business process) on the network and agreed to by all its members. In contrast, thin blockchains have a limited pre-defined number of operations and can only move assets from one account to another. Public blockchains are networks that are open for everybody to join, mine, transact and audit. Typically, they require complex consensus algorithms to make systems scalable and reliable. On the flip side, private blockchains form a federation that require participants to be approved and on-boarded beforehand. For example, the recent boom of initial coin offering (ICO) campaigns to a large extent uses Ethereum network to deploy and distribute smart contracts. It is a no-brainer to use a popular public blockchain to facilitate a market effect. On the other hand, if you are looking to fix a very specific problem across several companies you can consider using private blockchain to restrict access to a network only to approved members. Business Process Banks and other financial institutions are not going to change overnight. It is not possible to substitute any existing solution with a new shiny technology no matter how promising it sounds right away. There is market resistance. Typically, such transformation involves three levels, and it always starts with some pain points and locally improves them: a) Point solution b) Process level c) Market-wide solution — What it would take to run a blockchain application under specific legal conditions. Legal Framework For example, aims to create secure applications for consumers claiming “data protection by design and default.” This means building and architecting applications considering privacy as a first-class citizen. I believe that in a blockchain world this is a zero-sum game and distributed ledger technology (DLT) provides more secure principles then traditional approaches. General Data Protection Regulation (GDPR) — Benefits to business, barriers to implementations Strategy Let’s use an example of cross-border payments. McKinsey estimates that B2B payments yield the biggest cross-border revenues for banks, with such transactions representing 75% of all cross-border payments totalling more than $150 trillion in 2015. Cross-border payments are inefficient because there is no one single ubiquitous global payment system. Five challenges must be overcome to improve the cross-border process: : Domestic infrastructures are not designed to handle cross-border payments, most payment systems are based on local laws and practices within existing domestic banking and financial structures. a) Infrastructure : Lack of a common global standard and variations between systems have reduced the ability of both bank and corporate treasury/enterprise systems to seamlessly pass data between each other. b) Standards : Government regulations are changing how payments are made. Payments are subject to domestic regulations which compounds the challenges of cross-border payments because often rules vary between an originating and receiving country. c) Regulations : According to McKinsey research on cross-border payments, the average time to complete a cross-border transaction is three to five business days. d) Speed : It’s usually difficult for senders and receivers to track their payments while the funds are in transit, creating uncertainty about both delivery timing and the final payment amount. It can be especially difficult to quickly trace transactions when problems arise, such as incorrect account numbers. e) Opacity Today, cross-border payments are slow, inefficient and costly for banks and businesses. Increase in global trade and improvements in physical supply chain efficiencies are creating demand for process improvements. Improvement in the efficiency and effectiveness of cross-border payments is likely, but all stakeholders are being required to increase investments to change the systems and processes of corporations, banks and payment systems. Distributed ledger technologies provide an opportunity to fix those processes and specifically improve transparency throughout a shared ledger, increase speed of transactions settlement, and improve standards — blockchain could become a unified protocol that companies would use to read and write data. Start small, but do start. Avoiding blockchain is not an option. Choose a point problem and do MVPs, do not attempt to plan a large scale transformation though, blockchain technology is still very young and will change over time. When you have promising results, build production-grade solutions on top of those MVPs. To sum up: About the author. Kirill Timofeev is a recognized expert and thought leader in innovation and new technologies in the financial services sector. As a Software Project Manager at DataArt, he has delivered enterprise-grade projects for some of the world’s largest institutions in financial services and capital markets, such as securities settlement platform and a digital money solution for payments and FX. Kirill has authored numerous thought leadership pieces on cutting-edge technologies, is a regular participant in blockchain conferences and communities, and an active contributor on its uses in fintech. Originally published at http://www.bobsguide.com/guide/news/2017/Oct/6/building-a-blockchain-mvp/ .

Flow

Chain

Plan A

Trace

Transit

Too Long; Didn't Read

Discover Saakuru: Web3 Mass-Adoption with 0-FEES

What It Takes to Build a Blockchain MVP

Too Long; Didn't Read

Companies Mentioned

Coins Mentioned

DataArt

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

What It Takes to Build a Blockchain MVP

Too Long; Didn't Read

Companies Mentioned

Coins Mentioned

DataArt

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES