Smart Contracts and Enterprise

In this series of blog posts we will examine how Luther Systems is applying Blockchain Technology within enterprise environments. Blockchain means different things to different people. This is typical of infrastructure technologies which can be used in different ways. In these blogs posts we talk about how we view Blockchain Technology, detail how we use it to enhance enterprise processes, and discuss how our internally developed technology provides scalability, repeatability, and flexibility to new and old processes and applications.

Blockchain is a new technology which uses modern network, database, distributed systems, and cryptography technology. Blockchains enhance numerous existing applications and enable many new applications which were not possible before, and we will cover these application in future blogs as well on Luther’s website. Areas in which Blockchain Technology has gained most attention and traction are within the financial services industry and particularly financial transactions.

We, at Luther Systems, focus primarily on applications of private Blockchains to enterprise processes. Still within enterprises blockchain technology can be used in different ways, including business processes, data verification and sharing, digital representation of assets, and many others. In this blog post we provide a description of one way we leverage Blockchain technology for enterprise processes.

What follows is one of many different ways blockchain technology can be applied within enterprise environments to great effect.

Fragmented Processes

Numerous enterprise processes are comprised of separate units and teams with their own set of functionalities. Most of these functionalities are designed and optimized individually and separately, with the functionality of other units taken as given and treated as a given set of inputs and outputs. Each of these units and teams have over time specialised and optimized their functionalities.

When a process is designed, units and teams are often connected to each other via local point-to-point connections. Each unit is connected to units it directly needs to connect with, and often treats other units as mere inputs/outputs (to/from which to send/receive data). Generally units do not have a holistic view of the entire process progress and execution.

There is currently no process connecting (orchestration) system in the market which

executes events,

verifies, validates, stores process data and information flows,

ensures parts of the process are coordinated and “on the same page” during execution,

is a system of record,

is resilient to inevitable changes in functionalities of units, groups and teams over time.

This leads to inefficiency and opaqueness, which requires multiple groups and teams to resolve

duplication of effort,

propagation of errors throughout the process,

constant need for reconciliation of events and transactions.

One example is the insurance claims fulfilment process. In this process

a claim is made and approved and a supplier is appointed to fulfill the claim,

an estimate and invoice of the replacement/repair generated by the supplier,

estimate and invoice are verified and validated and matched by the insurer,

a payment to the suppliers is triggered and verified,

the claim is fulfilled and closed.

This process involves multiple units and teams, which are individually optimized to perform their own task, however this process

wasn’t designed end to end with units collectively developed to fulfill the process, rather,

it was developed by locally connecting existing units and teams. Each with their own separate functionality, inputs/outputs, teams ...

These attempts do not provide a process orchestration and coordination system for these units and teams. In other words, what is needed is a system which provide process execution, verifies, validates and stores process data, and is resilient to changes to individual functions and functionalities of the process.

We think of these processes as a number of villages in the old wild west where a messenger on horseback travels from village to village carrying messages. Each village knowns its own tasks and needs but is never quite sure if the messenger made it to the next village.

We can model the process, which is comprised of a number of units and teams, as a series of connected nodes in a network which execute their functionality in a predetermined order. If we organize these network nodes as a blockchain network, we can execute the process with full visibility and connectivity of the process events and information flow.

Each node represents a unit or team’s function or event. Once a function is complete, the corresponding node informs the rest of the network of the occurrence of its event or completion of its function.

In a blockchain network all of the nodes must agree that the process was completed successfully, and that all nodes have seen and confirm that they agree with the outcome of the process. This means that at each stage of the process all nodes have the same information and have confirmed that the step was completed successfully. All other nodes receive, verify and store the function or event, before the next function or event is triggered. This way all units, groups or team’s receive, verify, and store a function or event before triggering the next function or event in the process.

The key part of this is that the next node is not able to start their process until all nodes agree that the previous steps have been completed and know which node will perform their function next. This is how Smart Contracts provide processing visibility, verification, validation, and real-time reconciliation.

Smart Contract as Railroads

Going back to our wild west analogy, we can think of implementing a process as a smart contracts as building railroads between the villages. Where each village is a now a station on the train tracks. In this analogy the stations are units and teams across process, and the train represents the execution of the process. The train stops at each station, things happen at the station, and the train moves to the next station. All stations know where the train is at all times and what was done at each station.

Smart contracts connect the units and teams across the process and remove the friction between each of these functions, as well as providing full visibility, to all units and teams, into the current execution status and data flows of the process. The whole itinerary is clear to all the participants and they are all aware of what has taken place and what is yet to come in the process.

Going back to our insurance claims process, we can think of the following stations along the process (i) claim validation, (ii) supplier, (iii) estimate processing, (iv) invoice processing, (v) payments. At each of these stations data and information is processed, verified and validated, all stations are informed and agree on the status of the specific journey, and then the train leaves a station and arrives at the next.

Execution, data verification and validation, storage for processes all under one roof

Smart Contracts (i) orchestrate the entire process, (ii) trigger and execute the steps of the process, (iii) verify and validate the information and data at each station, and (iv) all events, data and information is stored by all units and teams. All of these properties are provided by a single product. Interestingly if the functionality of a station can be expressed as a set of logical rules then that station’s functions can be executed by the smart contract itself.

In our next blogs we will discuss in detail the benefits of Smart Contracts and provide a detailed comparison with alternative approaches to process execution.

Not Rip & Replace

Let’s go back to our railroad analogy. We did not change or replace or remove any of the villages, rather we simply built railroads connecting them. The villages are still there and still function as before and still send messages to each other, we just connected them.

In an enterprise environment, it is costly and risky to rip out an existing unit or team, or to replace an existing unit or team, or to even modify the functionality of an existing unit or team in a meaningful way.

Smart contracts do not require ripping out, replacing, or even making meaningful modifications of any of the existing systems. Smart contract simply augment your existing process by streamlining the interoperation of its units and teams. In this way enterprises can benefit from all the advantages of Smart Contracts without having to change their existing systems or way of working.

Finally

As Smart Contracts evolve and enterprise gets more familiar and comfortable with them, there will be scope for Smart Contracts to take on more responsibilities and potentially execute large portions of an enterprise’s numerous processes. Our goal is to provide connected enterprise pipelines and plumbing which allow for smooth and low friction flow of events, information and data, through the application of blockchain technology.

Imagine not noticing enterprise processes happening in the background, the way we don't notice the flow of clean safe running water in our homes. Decades ago they dreamt it, today we don't notice it.