Four Key Practices for Effective DLT System Integration
By Dan Porter
Businesses far and wide are looking toward Distributed Ledger Technology (DLT) – the more general class of technology that blockchain belongs to – and the advantages it promises in terms of increased efficiency, security, audit-ability, and more. While everyone under the sun is writing about DLT and its benefits, understanding DLT system integration for today’s business can feel elusive. Let’s go over a few keys to building that understanding.
As a long time software engineer and architect, understanding and integrating new technology is a situation I’m familiar with. The ever-evolving list of software libraries, languages, and solutions is difficult to keep up with at best. Understanding which technology to use, when to use it, and how to integrate it, is a real challenge. Lessons learned from good general software development practice still apply to projects that include DLT system integration – maybe even more so.
Four key practices teams can use for effective DLT system design are to:
Communicate with stakeholders
Identify and discuss tradeoffs
Choose the right DLT platform
1. Communicate with Stakeholders
It’s easy to run quickly through a set of requirements when development/engineering teams are eager to get software programming off the ground — they often have a ton of work to do and sitting around talking about it doesn’t get them any closer to completion, but there are critical design questions stakeholders should answer before jumping into development. A starting list for each team can include:
What areas of the business present the best opportunities for DLT integration?
How will DLT change or improve business operations?
How can DLT help create advantages over my competition?
How will DLT impact operational and capital expenses?
What properties do I need from a DLT platform?
What DLT platforms meet business and technical needs?
How do I evaluate and assess a particular platform?
Do my use cases require private DLT, public DLT, or a hybrid approach?
What low-risk ways can I find to experiment with DLT in order to understand technical and operational realities?
Will I need additional staff for DLT-related support and development?
How will DLT affect agility and velocity across teams?
How will DLT affect customer experience?
How will DLT impact potential customer conversion rate?
Will DLT have an impact on customer feedback and support?
Does DLT create additional marketing and promotion opportunities?
Software Architects & Lead Engineers
What existing components in my software change when DLT is added?
What new components need to be built & maintained?
How can I manage the additional complexity DLT brings to my system?
What data will be stored on DLT? Are there privacy concerns?
How does development, testing, and deployment change?
2. Identify and Discuss Tradeoffs
In the system design process, stakeholders often create requirements without understanding the trade-offs. For example, they might say “The system needs 100% uptime”, or “Policy dictates all critical services be run in-house”, or “Language/runtime X is the only option.”
If the software architects take these requests literally, without helping business leaders understand the trade-offs, they may spend time and money on unneeded efforts.
Let’s examine these examples a bit closer:
Reliability: “The system needs 100% uptime”
Here the stakeholder is often communicating that downtime costs money. However, further understanding the ramifications of requiring 100% uptime (namely, excessive cost) is important. In actuality, can the system be down for 5 minutes during a patch? Can it be down for 15-20 minutes during off-peak hours? The answers to these questions drastically change the cost and development time for a system. While a system can have near perfect uptime, it will be much more expensive to implement and operate, and most systems don’t actually require perfect uptime.
Performance: “The system needs to be as fast as possible”
Stakeholders fear slow transaction rates that detract from their product or brand. However, does every request need to be returned within 100ms? Which interactions need this kind of performance? Is 500ms acceptable for certain interactions? Are performance demands the same at all hours of the day? Might 9-5 EST actually be the only critical business hours? Answers to each of these questions will help define the software architecture and operational costs.
Software Environment: “Language/runtime X is the only option”
Stakeholders fear complexity and mistakes related to adding / changing systems and languages, but understanding the issues or constraints involved and preparing ahead of time so that teams have stable support is critical. How imperative is the choice of language or runtime? Is it possible to run a small, isolated set of servers with the new runtime environment to get a feel for things? Are cloud-based servers or services an option? The answer to these questions will allow you to create the most functional and economical system possible while managing risk.
3. Choosing the right platform
Choosing the right DLT platform can make a world of difference. Not all platforms offer the same features, but even when they do, the differences are worth careful consideration.
Open Source: Zero cost to acquire and offers community updates and support. Many engineers across the world contribute to these projects, so look for an active and engaged community when pursuing an open-source platform. This is especially important if using a public DLT where protocol code visibility is key to confidence in security.
Public/Private: Can you run a private network that is closed to the public? Businesses should carefully consider the trade-offs of public and private networks. Running a private DLT can mean better performance guarantees, full control over privacy, and zero transaction fees, but also higher costs to set up and maintain. Staffing, servers, storage, backups, and security should be considered.
Messaging: Messages are a basic feature, but can be leveraged to add notes, order numbers, or internal identifiers to transactions, improving integration and auditability.
Custom Assets: Platform features vary when it comes to asset types. Some platforms directly offer “first class” support for creating tokens or other assets, while others rely on smart contracts that force the developer to implement these features themselves. Take the time to carefully consider your options here, understanding this can open doors that simplify DLT integration or enhance business opportunities.
Multi-Signature Transactions: Some DLTs can enforce rules about having multiple authorized signers in order to complete transactions. This is a powerful way to add checks and balances to DLT workflows.
Transaction Rate: How many transactions can the platform handle before it can’t keep up? Even if a platform meets your needs today, what kind of growth you expect should be factored into the decision. Depending on business needs, this may be a make-or-break point for a platform. Transaction rates vary from single-digits to tens of thousands per second.
Transaction Latency: How long does it take before a transaction is confirmed / recorded? The nature of the transactions may mean this is more or less important. If used for real-time payment processing, higher latency may have a negative impact on the business. On the other hand, if the platform is used for document verification, latency may be less important. Latencies vary from fractions of a second to full minutes.
Interface: The interface dictates the skills needed by your technical team, and to some degree, the tools they need. HTTP/REST interfaces are well known and technical staff are often well-practiced with using them. This may not be true for other types of interfaces, and many smart contract languages require highly specialized developer resources.
These are just a few factors to consider when deciding which platforms are best suited for your business. Business leaders will bring one part of the picture, while engineers and technical staff will bring another. Working together to understand what the top priorities are will give you the best chance of finding the right fit.
4. Architect Success
Software systems grow over time, and without attention to architecture, they can become increasingly difficult to work with. Why is that? I believe a large portion of it has to do with architecture, or more precisely, a lack of intentional architecture.
Technical teams are often given a project goal, a pile of requirements, and then asked to estimate resources and set schedules about the project when they know little more than what they have just been told. This is a difficult position to be in, but it happens often. Give them time to digest the information, ask questions and architect a solution.
A successful architecture is designed and documented in a way that allows clear communication across teams — each person should understand the system structure, and design decisions that dictated the software architecture, so that teams don’t waste time working against the design, or constantly going over the reasons behind a design.
DLT (including blockchain) is a software system, so considering DLT in the context of other software systems can be helpful. Businesses today are often using accounting, customer relationship management, and database systems. The collection of existing software in use forms a landscape. Understanding this software landscape, the relationship between the pieces, and their roles in a business are the first step to creating a viable, DLT-based solution.
As a business leader, work with your software architect or lead engineer to review the high-level system architecture. This can help with understanding the landscape, where DLT fits in, and where complexities may be in integrating it. It also creates an opportunity for cross-exposure to business and engineering complexities which cultivates a sense of shared purpose and goal.
Integrating DLT for potential advantages makes sense, but by now it should be clear this isn’t a problem you can simply throw at your technical team. Business and engineering skills must come together to create success.