What’s the best way to unite stakeholders around your enterprise blockchain project? Partner with other companies to launch a consortium, then jointly fund and develop a distributed ledger technology (DLT)? Is it better to hold off involving other stakeholders until after your blockchain project is underway — so you retain more control? Or should you sell a blockchain-based solution to clients directly, without a coalition at all? While there’s no one-size-fits-all way for companies to build their enterprise blockchain projects, most DLTs follow one of three coalition patterns. Each pattern has its advantages and its difficulties depending on the company’s goals for the technology. In this article, we’ll first review these three patterns so you can identify which best applies to your blockchain solution. Then, we’ll discuss common problems that companies who fit each pattern experience. When you’re finished reading, you’ll be able to understand the opportunities that come with each pattern and avoid their common pitfalls. Let's Begin. Coalition Pattern 1: Solo Solution In this pattern, a single company that sells a blockchain-based solution directly to clients. Whether through a SaaS, a white-label, or another model, the company provides blockchain-based tech in a manner consistent with other traditional “enterprise software”. Many “Solo Solutions” use blockchain-based tech to help one client company streamline inter-business transactions via a ledger. For example, offers clients a custom application builder that extends Salesforce CRM access to their clients’ network of partner organizations. While many “Solo Solutions” are often not true “distributed ledger technologies” due to their control and maintenance lying on the shoulders of the solution provider (Salesforce in this the example above), they still provide clients with some of the benefits of a shared ledger; notably, the ability to record multi-party transactions or otherwise share data. Salesforce Blockchain Other “Solo Solutions” use blockchain-based technology in a manner similar to a traditional database; allowing a client company to store their own records on a ledger. We’ll discuss in the final section of this article why these solutions often miss the target. In the other two coalition patterns to follow, multiple companies collaborate with transparency, shared responsibility, and shared risk. Before we jump into the other two patterns, let’s review some of the advantages and difficulties that “Solo Solution” projects experience. Pattern 1 Opportunities: Pattern 1 blockchain solutions are often more palatable to enterprises, who are used to traditional enterprise software models and may be wary of full distributed ledger systems Due to a solution provider hosting nodes and maintaining the blockchain-based system, there is a very low barrier to entry for client businesses to integrate with the technology. Pattern 1 Pitfalls: Blockchain technology managed by one company is functionally identical to a typical database. As multi-stakeholder distributed ledger networks become the norm, Solo Solution blockchain software is likely to become obsolete. Coalition Pattern 2: Founder Comes First In “Founder Comes First” projects, the tech often comes before the coalition. A single company builds a blockchain solution, then later founds a consortium or association and works to involve other stakeholders in the solution. The notable difference between “Solo Solution” and “Founder Comes First” projects is that “Founder Comes First” projects want to eventually distribute the solution they’re building to more than one client. This allows member companies to be able to see the full benefits of blockchain technology through the joint maintenance of a shared ledger (or single source of truth). Founding companies often retain greater control, which can lead to problems onboarding coalition partners later in the scaling process, who fear they may not be treated equitably. While a single company is the clear driver of the projects that meet this pattern, stakeholders must be consulted early and often to breed success. , is a good example of both what can be done wrong, and what can be done right when designing a “Founder Comes First” blockchain system. In 2017, one of the largest international trade logistics companies, Maersk, built a blockchain-based freight logistics system. They waited until after the technology and governance had been designed to begin engaging stakeholders they hoped to onboard to the platform. Prospective member companies were hesitant to engage because they feared that Maersk may have baked in advantages for itself in the platform; they also believed they didn’t have enough say in the system’s governance. After Maersk analyzed its pitfalls (not involving stakeholders early enough, and giving them the delegated control they needed), Maersk scrapped their initial platform, and re-launched Tradelens — only this time, with heavy amounts of input from as many industry players as possible. Governance was re-designed in a manner that instilled trust and buy-in amongst parties involved. Since the re-launch, Tradelens has integrated hundreds of ports, cargo ships, and shipping partners on one platform over the past few years. Maersk Tradelens Let’s briefly review what works and what doesn’t for companies founding a coalition later in project development. Pattern 2 Opportunities: Founding companies can initiate the development of a blockchain solution, and reap the rewards of a jointly-verified single source of truth through onboarding additional stakeholders as validators. “Founder Comes First” projects can offer an innate “baked in” advantage to the tech’s creator (which can be a good and bad thing!) Due to having one clear leader, “Founder Comes First” projects are able to make decisions and launch solutions with more agility (in comparison with pattern 3 projects) Pattern 2 Pitfalls: Pattern 2 is a balancing act between pursuing what the founding company believes to be best and involving stakeholders in intimate design and development conversations. Without sufficient transparency, trust between the project creator and other stakeholders often breaks down or is never sufficiently established. Governance design and maturity can become complex as new stakeholders are onboarded to the solution. If other stakeholders are not invited to participate in all decision-making for the project’s future, they’re unlikely to buy into the coalition. Coalition Pattern 3: Teamwork Makes the Tech Work In “Teamwork Makes the Tech Work” projects, multiple companies form a consortium (contractual or entity based) to fund, develop, and jointly maintain a blockchain solution from the get-go. This often happens organically amongst organizations that are already involved in industry groups together. They’re friendly competitors, each other’s vendors, or partners on some other project. When they hear about the possibilities of blockchain tech for their industry, conversations result in a concept. The first step is usually forming an exploratory group, which evolves over time into a formal association or consortium. Early coalition partners agree on the idea, then pool resources for research and development. A perfect example is , co-founded by multiple pharmaceutical companies. Each stakeholder contributed to fund and develop Melloddy’s artificially intelligent, blockchain-based drug discovery system. Once governance was established, Melloddy onboarded new coalition members to scale further. Melloddy Consortium Pattern three shares no pitfalls with the other two coalition strategies. That doesn’t mean these early consortium projects are problem-free — it simply means the issues and advantages are different. Pattern 3 Opportunities: Interested parties are involved from the outset to further ensure project success. Trust and stakeholder buy-in are generally high in founding companies. Multiple stakeholders means each must invest less time and fewer resources than pattern one and two projects. Member companies are able to see the full benefits of blockchain technology through the joint maintenance of a shared ledger. Pattern 3 Pitfalls: When five to ten stakeholders must agree on a decision, the consensus process takes longer. Because no one company has a majority interest, these projects can get deprioritized or postponed. Consortia with no clear leader move slowly, sometimes taking as many as five years to progress from a focus group to a workable blockchain platform. Blockchain Tech Is Inherently Multi-Stakeholder (So Yours Should Be, Too) 2020 marked a transition from a surplus of pattern one projects to a growing number of pattern two and three projects. The value of active, multi-stakeholder collaboration in blockchain systems is impossible to deny. This is because only blockchain platforms that are built and used by multiple companies can realize the full potential of blockchain tech: a jointly verified single source of truth. Without multiple stakeholders to jointly use and maintain an immutable ledger by mutually verifying transactions, a blockchain project offers no more benefit than a traditional database. As you develop the roadmap for your enterprise DLT, be intentional about how you involve stakeholders in your design, scaling, governance, and system maintenance. Previously published at https://kirstenpomales.com/nov_03_2020.html
