Finding enterprise use cases worth development dollars Earlier this year, the GSMA, the world’s most influential telecom consortium, published a paper detailing Some of them were compelling. Others, less so. fifteen blockchain use cases for mobile network operators . As an , I was happy to see this kind of attention given to my still-nascent field. (Is all press good press?) But as a founder whose ability to buy Chipotle burritos rests on how seriously and successfully telecom carriers adopt blockchain technology, the addition of those less compelling use cases had me worried. entrepreneur in the telecom and blockchain space The sad truth is that the blockchain world is rife with misinformation, poorly-thought-out applications, and centralized tech pretending it’s “de-”. If left to their own devices, I could imagine carriers attempting the use cases I saw as less promising and being forever turned off of blockchain. So, although it’s against my very nature as a native Midwesterner, I see no other alternative to raining on this particular parade. As Warren Buffett wisely said in his : '17 shareholder letter The less the prudence with which others conduct their affairs, the greater the prudence with which we must conduct our own. In this article, I’ll attempt to be a voice of prudence. The applications that the GSMA proposes range from great and world-changing to fundamentally flawed, and I’ll explore four of them in the sections that follow. In so doing, I’ll draw out lessons worth remembering not only in telecom but also in broader enterprise blockchain R&D. A quick note on methodology: as an IDEO CoLab Fellow last winter, I learned that new tech is most interesting when it is desirable (i.e., adds real value for real people), feasible (i.e., technologically possible), and viable (i.e., good business). Check out IDEO’s explanation here if you’re curious, but it’s easiest to just witness them in action. You’ll get it. #1: Smart contracts for 5G network management “To realise the 5G promise of ubiquitous access across various networks, CSPs will need to handle heterogeneous access nodes and diverse access mechanisms. Selecting the fastest access node for every user or machine will be a central challenge in the future. …Rules and agreements between the various access providing networks can be coded into autonomous smart contracts. These contracts can be dynamic in nature wherein any time a policy needs to be changed, only the contract code needs to be changed.” The GSMA’s first use case falls prey to a classic problem of outside-in entrepreneurship — it describes a solution that every consumer wants but no business will offer. Is it to connect to any network freely and get the best value for the best service? Of course! I don’t care who gives me four bars of LTE service as long as I can reliably stream the #7-ranked Michigan basketball game in the back of my Uber. desirable But from the carrier’s point of view, this solution is neither feasible nor viable. On the technological side, the use case makes a number of critical leaps into still-unknown areas of blockchain tech, but far more damning is the business critique: why would carriers ever give up control of their customers? Carriers have built empires by leveraging their network assets to attract customers and reduce churn. Would they really buy into a protocol that forces them to auction for every data session, text, and call? feasibility viability Sounds tautological, but it’s surprisingly easy to forget. Yes, real-time bidding for connectivity would be amazing. But if it ever exists, it will only be after a prolonged battle with operators the world over. The lesson here is for prospective entrepreneurs: keep the enterprise in mind when designing enterprise blockchain products. #2: IOT connectivity “While localised networks in for instance a manufacturing line can provide great benefits, self-organised global supply chains powered by IOT can help streamline processes that require a lot of paperwork and governance. This would shift the focus from centralised IOT platforms (in technology and governance) to self-governed mesh networks… IOT can also be used for automatic tracking for quality and conditional parameters during transports, switching of ownership and provenance use cases.” The GSMA offers up three use cases in the IOT space. Unfortunately, they all fall prey to the same problem — they’re smart, and should probably happen, but they probably shouldn’t happen on a blockchain. These use cases are : IOT management via blockchain is a use case well-explored by startups and large enterprises alike. They may even prove to be : IOT is a huge and growing industry, devices will get smarter and smaller over time, and managing devices efficiently is a huge, valid concern. feasible viable The problem arises, though, when we consider the of blockchain in this context given the problems we are asking it to solve. desirability As I understand it, the problem is that we can’t get good data about products flowing through a manufacturing line or a multinational supply chain, so we’re asking blockchain to help. Walmart, for instance, now mandates that farms that supply their stores leafy green vegetables enter “ ” that they’ve build in conjunction with IBM. detailed information about their food into a blockchain database But wouldn’t that “detailed information” be just as useful in a normal database? In my mind, this type of supply chain management is a poor use of blockchain. If you can’t trust your supply chain partners (or much less, the folks on your manufacturing line) to produce accurate data, it doesn’t matter whether you use a blockchain, a database, or a stone tablet to store it: your customers are still going to . Garbage in, garbage out. (Or, due to blockchain’s immutability, it’s more like garbage in, garbage forever.) get E. coli from your lettuce Blockchain is expensive, slow, and non-private. It costs significant time and resources to write to a blockchain. Barriers to entry are high. (Do Walmart’s farmers now have to own wallets or accounts with IBM?) The lesson here is never to use blockchain when a normal database will do. This is not to say that blockchain won’t have a place in IOT; I think it will. But I’m willing to bet that device security turns out to be a better use case than provisioning or self-maintaining supply chains, because the former is a better fit to the unique constraints and benefits of blockchain. #3: Fraud prevention The telecom industry has not yet found a way to effectively and sustainably prevent fraud. In a general sense, working together to combat interoperator fraud is a good way to start. Blockchain could for instance be used to govern access to fraud detection information shared between operators…another angle is fraud caused by delays in sharing [call detail records] between operators. As blockchain works in real-time, using a shared administration of network activity could help identity plausible fraudulent connections faster. Smart contracts could be deployed to actively enforce network usage compliance rules and help us resolve inter operator disputes easier. Surprise twist: I actually this upcoming use case! In fact, I like it so much that I’ve been working on it for the past year with . (Is that cheating?) like drect.ly From a standpoint, blockchain has some clear advantages over other solutions in fraud prevention. In fact, it’s so good that you get to (justifiably) recite the holy text of blockchain use cases: desirability This is a case when mutually-distrustful actors need to coordinate to maintain a shared version of the truth for an economically-valuable digital record. That sentence is why blockchain was created; in this use case, we’ve just replaced the economically-valuable digital record of bitcoin ownership to a record of which telecoms have provided how much coverage to which roaming customers. Those records, it turns out, are incredibly valuable (and therefore, if managed well, can sustain a business model). Every year, telecom carriers lose over $38 billion to fraud; even a relatively small dent in that number is large in absolute terms. viable My own incredible bias notwithstanding, I do recognize some challenges here with . Billions of records are exchanged daily, which poses scalability problems. These records expose significant, closely-held data about network usage and subscriber behavior, which poses privacy concerns. Governance is challenging, for it’s unclear how centralized my ownership of the code base makes this project. And how can you get bad actors to sign onto a platform that demands higher responsibility? feasibility All that said, these are solvable problems. And perhaps that’s another lesson: ensure that your use case is a great fundamental fit with the unique value prop of blockchain technology — and then prove the feasibility haters wrong. If you think about it, that’s really the only way that technology advances. any #4: Hosted services Distributed Ledger and/or Blockchain network operators are responsible for configuring the network and granting access to network participants. In general, they specify the use case(s) that the network is serving, and are often involved in managing the network in terms of software upgrades, arbitration services, etc. A network can be operated by a single entity or a federation of multiple, separate entities. As a strategy consultant at Deloitte, I helped write a . It generated over 100 million views before being lost to the sands of business-thought-pieces past, but I’ll always remember it as the first time that I learned John Hagel’s concept of innovation “ .” trends report on ecosystems thinking antibodies The SparkNotes version of Hagel’s idea is that antibodies (i.e., agents of resistance) arise in big organizations whenever change is coming. They fight for the preservation of the status quo that helped them rise to power, and, even if well-intentioned, they often stifle the speed of change by insisting that old rules, norms, and values govern fundamentally new contexts. For example, a new business unit might be shut down because it’s cannibalizing sales of the core product; that is judged by the old rule of “protect the core,” rather than the new reality that any player could release the cannibalizing product and it’s better to optimize for growth. In the blockchain context, antibodies take the form of centralized services masquerading as blockchain technology. In the old world, businesses want efficiency and control — but Proof of Work is deliberately inefficient, and blockchain networks are intentionally decentralized. When I read a use case like the “hosted services” from above, where blockchains are treated like permissioned databases, I can’t help but remember Hagel’s antibodies. The whole point of blockchain technology is to make public commitments that are impossible to reverse; to open up previously siloed networks; and to radically decentralize power, code, and economic value accrual. So, my final lesson is this: You’ll want to do so — believe me, as someone who has built these systems — but if you do, you’ll be further from the real promise of blockchain technology and closer to designing a really bad database. After living in a centralized world, decentralization feels innately wrong. But as we enter this new age of decentralized technology, we ought to remember that it’s okay to break all of the old rules. never surrender decentralization when designing blockchain use cases. In fact, that’s the whole point. To connect with Christian, reach out on Twitter ( @cdkeil ) or via email at christian [at] drect.ly.
