Blockchain as a Service

Chapter 4. Architecture of a BaaS Application

BaaS simplifies planning a blockchain application because it supplies easy access to many of the technical components, with accompanying technical support. But the technical components are only one layer of a successful blockchain application. After planning your business use case, the next critical step is considering the flow of your BaaS application.

According to Paige Krieger of IBM, “Once you’ve decided on your use case, then you can hold a design thinking workshop, onsite or at one of our IBM Garage locations. It’s where you map out your whole process from start to finish. It seems mundane at first, but it is important because that’s when everybody in the group starts to realize that you’re focusing on the end-user experience of your blockchain application, and then working backwards.”

Paige added, “Design thinking methodology isn’t just an IBM thing, but it’s a practice that we’ve seen a lot of success with, and we encourage all customers to go through it so they can be sure that the use case they are pursuing is the right one.” If you want to create your own design thinking workshop, there are many online resources to help you to succeed.

In this chapter, we will look at considerations for determining the architecture for your BaaS application, including security, data handling where privacy law applies, types of client software for working with the data in the blockchain application, and implementing a standalone versus integrated workflow.

Top Architectural Consideration: Security

As when developing any application, security is a top consideration when implementing an application that uses BaaS. Any app available on a network is subject to immediate attacks by hackers looking for ways into the system. Make sure that the BaaS provider you choose offers at least industry-standard security.

Blockchain projects often disrupt the status quo, which is bound to generate attention. If you are building a sensitive application—one that will be controversial or highly competitive—it could be especially subject to breach attempts and denial-of-service attacks. One nice thing about a BaaS is that you should not own the main responsibility of administering backend security, as this falls mostly on the BaaS provider. However, since security is critical to everything else you are doing, it is wise to pay close attention to how it is administered, and to the security of your internal systems. Be especially alert when integrating with other systems, making sure any user clients and credentials are locked down and that your programmers and administrators are credible.

It is also very important to plan and budget sufficient resources to maintain your application’s code with security upgrades, as new exploits are constantly being discovered. Frequently, all of the code and dependent systems must be kept up with the latest releases to prevent new exploits. While your BaaS upgrades should happen through the provider, programming changes or administrative steps may be required to convey these to your own applications. Never let security updates pile up—always install them once you are sure they have not been recalled or otherwise updated. Otherwise, you may find that your application code soon becomes obsolete due to missing security updates, which can no longer be applied without causing your application to break.

Even the secure architecture of blockchain can’t make up for security holes and user identity theft, so be sure to implement best practices for security and system updates.

Immutability Versus Privacy

Let’s forget BaaS for just a moment and think about your application and its users. People using the system will expect to be able to manage their own personal information such as their name, email address, and payment information. Remember that personal information must be managed in accordance with applicable laws. The European Union’s General Data Protection Regulation (GDPR), one such law that impacts companies in the EU and companies in the US that do business with EU-based companies, mandates (among other stipulations) the “right to be forgotten.”

This means that data subject to the GDPR will need to be stored separately, since data slated for deletion can’t be placed on a blockchain. One solution for this is to create a hash on a blockchain that allows verification of the private data, but doesn’t store the data using blockchain.

I asked Todd Little, architect at Oracle Blockchain Platform, how organizations can deal with the GDPR and similar data privacy regulations, considering the reported immutability of blockchain data. According to Todd, “Data that needs to be deletable can be stored elsewhere, and a hash of that data can be computed and stored using blockchain. This allows data stored off-chain to be verified by creating a hash of that data. Then the hash is compared to the original hash that is stored using blockchain. If the hashes do not match, then the copy of the data being tested does not match the original data.”

The hash stored in a blockchain can’t be reversed to produce the original data. This means that private data can be changed or removed, and there is no permanent record of the data in the blockchain. If the GDPR applies to your use case, consider this carefully when planning application architecture that uses blockchain technology. Make sure that the BaaS you select has the capability to keep certain information private and mutable in accordance with your specific requirements and applicable laws. If there is a question about whether or not your application is impacted by privacy laws, check with your legal advisors. Data privacy laws can be strict and fines for noncompliance can be heavy.

Blockchain Clients

Blockchain uses a peer-to-peer network architecture, and the system runs on each node. A client system of some sort is required for users to interface with the blockchain system—even though the blockchain resides on its own peer. The client system can be an existing piece of software, such as a third-party wallet, or can be implemented via API calls that sit behind a customer user interface (UI).

Decentralized Apps (dApps) Versus Centralized/Decentralized Apps

In a blockchain system, the application’s backend code can run entirely on a decentralized peer-to-peer network. This is known as a decentralized app, or dApp. It might be helpful to architect the application so part of the backend code runs locally, and part runs on the cloud or on another server behind a firewall. This is known as a centralized/decentralized approach.

Blockchain Clients and Integration with Existing Systems

The BaaS UI elements can be incorporated with other elements of the application functionality, so users aren’t intimidated and additional training isn’t necessary. Instead of approaching the project as creating a BaaS/blockchain application, approach this as creating an application that integrates with BaaS at various touchpoints.

If prospective users in your organization already sign in to a business system that drives related functionality, it may make sense to use this system to add and manage participants in the blockchain. The other participating organizations can also look at their existing systems for logical points of UI integration.

Standalone Application or Integrated Workflow

Workflow is the process by which information moves through the employees of an organization as well as its systems. When workflow is implemented programmatically, this helps issue reminders and track the status of business processes so costly mistakes are avoided. Applications with workflow features frequently surround BaaS and tie into the blockchain at critical touchpoints.

As shown in Figure 4-1, on-chain and off-chain workflows can tie together mission-critical processes like purchasing and accounting, with processes that support specific collaborations. In this example, our use case is for local egg delivery. Since the distributor can sell locally sourced eggs for more money, it has been defined in the contract. In our case, we are defining “local” as originating from within 50 miles of the warehouse. The distributor wants to track the mileage that the eggs travel and approve the invoice payment through a blockchain smart contract. If the eggs travel more than 50 miles they will still accept delivery, but the invoice will be discounted by 20%.

Figure 4-1. On-chain and off-chain workflow combine to serve new purposes.

Figure 4-1 shows how that might flow. Since not everything needs to be kept on the blockchain, some of the steps that take place inside the distributor’s purchasing and accounting systems don’t need to be fully tracked. There might be a team of 10 people involved in the life cycle of an order, yet there might only need to be a single block recorded on blockchain once, stating that all of the steps have been completed. This prevents the creation of multiple user IDs for managing the blockchain and allows the purchasing and accounting systems themselves to act as blockchain participants.

The steps that take place at the transport company are all critical, and each one must be recorded as a blockchain transaction. However, since this is a small local carrier, they do not have other systems that require integration.

In this example, once the workflow from the distributor has been completed and recorded on the blockchain, tests can be run on the transaction, such as whether or not the eggs traveled less than 50 miles. If not, a 20% discount is applied. Once the smart contract’s criteria have all been met, automatic payment of the invoice occurs and payment information is recorded as a blockchain transaction.

There are several factors to consider when deciding whether you want your BaaS application to stand alone or be part of an integrated workflow with other organizational systems:

• Is this a pilot intended primarily to prove concept? If so, a quick standalone application might be best for the first prototype. By doing this you can find out if your application will be a success before you spend the money and time on integration.

• Do you plan to start with a pilot only for the purpose of getting feedback, then roll directly into the next phase of development? In this case, it may make sense to start the project by integrating with the existing systems of each participating organization.

• Do you not have other backend systems that manage users and provide workflow? Are your backend systems outdated and difficult to integrate with? Will other organizations have access to your backend systems or be integrating their own systems? If not, then a complex standalone multiuser workflow application might be in order. Keep in mind that for most applications, you will want to abstract the workflow away from the smart contract, to avoid causing undue overhead.

Custom Application Elements

Consider other new elements your BaaS application might offer, either as frontend features or administrative panel functions. Design workflows into your system that automate functions that currently use less efficient methods, such as emails or phone calls.

Out of the data you plan to exchange and store, determine which data is best stored in a traditional database versus on a blockchain. If the data isn’t transactional or doesn’t need to fit the way blockchain works (shared, transparent, immutable, and traceable), then consider storing that portion of the data in a database.

Workflow and Integration Scenarios for a BaaS Application

Here, we will analyze the very simplified workflow of a blockchain-based auto-leasing network that is available through Hyperledger and IBM Cloud. (This example is free to download and install.) In Scenario 1, we will examine which parts of the application could be built as a standalone application, and how they tie into the BaaS. In Scenario 2, we will examine how the auto-leasing example could be expanded to meet a more practical set of real-world requirements, through integration with existing systems.

Scenario 1: Standalone Multiuser Application

Your developers would usually download and install the software development kit (SDK) made available by your BaaS provider and download corresponding sample client code from a repository. Code is generally included that allows you to develop a simple password-protected client with basic workflow capabilities. User credentials are set up and maintained using the administrative interface provided with the BaaS.

In a standalone application, the frontend client is typically built with a web stack that supports multiple users and roles. While using the sample code can speed up the time to first results, you could quickly discover that the frontend included in the SDK does not meet your needs. The good news is that the UI layer is already abstracted away from the core blockchain logic, so you can build your own user and administrative frontends in programming languages that your organization already supports, and integrate them with the smart contract and supporting features via BaaS APIs.

Scenario 2: Integration with APIs and Web Services

Since blockchain applications involve a network of users—which can include multiple organizations or even siloed departments within one organization—it is a fantastic way to break down barriers and enjoy the benefit of efficient data sharing. However, each organization will need to determine the best approach for integrating blockchain with its systems. Because of this, you’ll still want to add a basic client that can be used by an organization that can’t integrate, or a new organization that needs time to do so.

Most organizations already support a very large number of systems which users are required to learn. Training is expensive, and a lack of training can prove catastrophic. Furthermore, maintenance of credentials is an expensive process, and adding another layer of authentication can be labor-intensive. In this scenario, it is most useful to start by analyzing all of your systems and defining each touchpoint for both users and the blockchain.

For instance, an account representative responsible for verifying that freight whas been delivered to a client might log on to a portal that manages all orders. There, the rep sees their normal functionality, possibly enhanced with a Verify button and a status indicator. Completely invisible to the rep, the proposal is submitted to the smart contract, which verifies that the information is true by going through predetermined steps (which could involve checking multiple backend systems). Finally, when the result is returned, verifying or not verifying the commitment of the transaction to the blockchain, the rep sees the status change in the portal. If the account rep needs more information, the blocks can be retrieved in a human-readable form and presented on their portal.

Behind the scenes, the system creates a series of blocks that contain information related to each series of transactions. This series of blocks creates an audit trail that provides traceability back through the various systems that reside in multiple or siloed organizations.

Summary

Because of the distributed nature of a blockchain network and the abstraction of its layers, the combinations of technologies that can be used to build a BaaS application are practically limitless. If you are looking for a proof-of-concept, keep the project simple and develop it quickly. Don’t spend money and time on integrations that can be done manually as a test. If you are sure you want a BaaS application for the long term in a large organization, then it could be worthwhile to create a fully integrated application from the start.

Using a BaaS can help to ease the burden of administering everything inside the blockchain layer, and help to distribute this layer in a secure and simplified way.