It’s time for a thought exercise.
Think of any business document or other process-related data set that contains financial information of one sort or another. It could be a customer record in Salesforce. Or an invoice in SAP. Or an Excel spreadsheet containing daily purchases. Or any of a million other types of business information.
Now, let’s say that somewhere in those data is the figure $47.02. That figure could represent the earnings from a particular customer last month. Or the price per widget. Or maybe how much a store took in on a particular brand of gum last week.
Finally, let’s say that someone – let’s call him Fred – changes that figure to, say, $95.18. Time goes on, and other people change other values, perhaps even updating the one value Fred changed.
A month later, a manager – let’s call her Barb – notices the $95.18 number, or whatever value is the current value for that particular field. Barb scratches her head. Is that the right number? Who put it there? What was there before? How many people have changed the number, who were they, and what values did they put there? When did they change it? And why?
Many applications simply cannot give Barb any of the answers she’s looking for. Such applications simply don’t track what happens to one value or another.
The fallback may simply be to keep multiple copies of the information – say, the version of a file from last Tuesday. But that Tuesday version doesn’t just show you what happened to the field in question, but rather what the entire data set looked like at a point in time. And just how many copies of that data set do you want to keep around, anyway?
Other applications – especially ones that are built on top of relational databases – might keep an audit trail of such changes. Because such databases maintain tables where each changed ‘row’ is a record, such an audit trail will consist of such records.
However, each record may consist of many different values, not just the one Fred changed. How should we compare every column to figure out what changed and why?
And what if Fred is up to no good and wants to cover his tracks? He might be able to go into the database table and change things there.
Why We Need Transaction Chaining
To solve Barb’s problem, we need a way of tracking and relating what happens to each individual value – not just documents or records consisting of values in multiple columns. Such a method should automatically time stamp each change and chain related values together.
And most important: changes should be immutable, meaning that no one, not even Fred, can go back and change the permanent record.
No enterprise app, no SaaS app, and not even Excel, can track what happens to individual values this way – at least, not without a lot of burdensome, manual coding.
If all that weren’t bad enough, let’s raise the bar even further. On top of all these requirements, let’s assume that multiple people are collaborating on said data set – and those people might even be in different companies, for example, if two or more parties are negotiating over a contract.
In such a case, Barb wants to add the requirement that every party who has the right to view what’s going on with the data set can see the changes for each field, and furthermore, each of them can be fully confident that all other parties are seeing precisely the same changes at the same time.
Barb, you’re out of luck. There has been no practical way to give you everything you want – practical in the sense that there should be a scalable, secure approach that doesn’t require massive, cost-prohibitive hand-coding.
Without such insight into changing values, individuals, teams, partners, and companies inevitably waste a lot of time and effort coordinating with each other, thus reducing the speed and efficiency of the company overall.
The Key to Transaction Chaining
We call what Barb is asking for transaction chaining. In essence, we want to treat each change to every field as a separate transaction, and then we link together all such changes to each field into a chain.
Now, if Barb or anyone else with the proper permissions wants to review the transaction chain of that field, they can peruse the chain, thus determining the history, or provenance, of every value in the data set in question.
Furthermore, if multiple parties are involved, then each one gets an identical copy of each transaction chain – and if someone makes a change, the underlying transactional infrastructure insures that everyone else’s transaction chain is appropriately updated, as shown in the figure.
The technology that makes transaction chaining possible is an immutable distributed ledger. Immutable distributed ledgers have recently come on the scene under the name blockchain – but don’t confuse the ledgers we’re talking about here with the hype-driven, crime-ridden blockchain that underlies bitcoin and other cryptocurrencies.
True, bitcoin runs on its own immutable distributed ledger – but the focus of bitcoin’s blockchain is on ensuring that each unit of cryptocurrency is in only one place at a time, and that the transaction processors (miners) are rewarded for their efforts.
The blockchain technology that supports transaction chaining, like that from Boardwalktech, has different priorities. With Boardwalktech’s blockchain, the focus is on insuring the integrity of each link in every transaction chain – even though there could potentially be billions of individual fields across all the documents and systems shared across a group of large enterprises.
However, transaction chaining faces one particularly difficult challenge. Scaling the transaction chaining, given how many individual values may be involved – think of the data elements shared across your entire enterprise and every company it does business with – is far from straightforward.
Combining these capabilities at scale is the core of the technology Boardwalktech brings to market.
The Intellyx Take
I could very well have started this BrainBlog with ‘here’s a great use case for blockchain,’ but I didn’t – for a very good reason.
Today, the hype around blockchain has gotten so extreme that it obscures the rare blockchain-based offerings that promise real business value.
Sure, dropping the ‘blockchain’ name still draws people in – for now. But solving real business problems like the ones transaction chaining targets is the true story of any worthwhile technology.
However, we’re so used to working with business datasets without the benefit of transaction chaining that we may not even realize how important it is. Only when we’ve figured out how to solve previously intractable business problems do we then ask how it’s done.
Copyright © Intellyx LLC. Boardwalktech is an Intellyx client. At the time of writing, none of the other organizations mentioned in this article are Intellyx clients. Intellyx retains full editorial control over the content of this paper. Image credit: Boardwalktech.
