Perspectives with Paul Sitoh — Part 1

We sat down with Paul Sitoh virtually, with him in London and us in Singapore. Paul has extensive experience working on blockchain and cloud technologies, and currently heads Blockchain at Elemental Concept and Aladdin Technologies Ltd. in the UK.

In this inaugural two-part interview as part of Chainstack’s Perspectives series on our blog, we discuss his journey into the world of the blockchain, his involvement with Hyperledger Fabric, enterprise blockchains, deployment, and several other topics.

Perspectives is a series of interviews, where we sit down with industry experts and thought leaders within and beyond the blockchain space.

Note: This interview has been edited and condensed for clarity.

Paul, with your couple of decades of experience as a technologist, could you start off by telling us about your experience with various technologies and how you actually entered the world of blockchains?

After my university in the UK, designing and building Enterprise Resource Planning (ERP) systems was my first choice of career. This was followed by a stint in creating an object-oriented database for the construction industry. I was part of a team trying to build a customized object-oriented database. In the building industry, everything easily fits into an object or a rule, and we wanted to provide a way to extract objects easily.

I returned to Singapore to work on a project called CORENET, a government initiative to digitize every building in the whole of Singapore. That was my first brush with something that might be vaguely called ‘smart contracts’. We didn’t call it smart contracts then, but, essentially, we were taking regulation and marking it up in English, so that it could be converted into a computer executable business logic. That opened the possibility of something, which is referred to as a Ricardian contract. I later had stints working in the supply chain and payments industries.

So my eventual interest in blockchain was a culmination of all those years of working with various technologies and a variety of problems. As for getting my hands into it, I got the opportunity at IBM. Unlike most people, it wasn’t cryptocurrency or Bitcoin that drew my attention- It was the possibility of using Ricardian contracts and solving pain-points of integrating fragmented systems.

So was that the aha moment, the fact that with a blockchain, you could now automate the kind of contracts you were thinking of several years ago?

Yes, it was. And that was also the time I got introduced to Ethereum’s smart contracts. And while not smart in the actual sense, it was a flashback to what I was trying to achieve way back — of using plain English to turn it into an executable. That led me further down the blockchain and its possibilities.

At this point in time, there are so many interesting things happening in the world of the blockchain, from governance models to the potential that tokenization holds. What areas do you find most exciting in terms of principles or practicality?

Having been exposed to the supply chain industry, I can now say that blockchain could certainly solve so many areas in the supply chain industry. This is one field that’s so fragmented, but one that requires a whole new way of thinking. I find people talking about how can they put documents on the blockchain. This only means that they are trying to force fit a powerful new way of doing things into a conventional mindset.

Talking about the conventional mindset, is it a fool’s errand to think of blockchain to solve world-scale problems?

We could certainly try using blockchain to enfranchise the billions of unbanked in the world. This is lofty indeed. But why not start small, really small? For example, two companies that don’t want to expose their APIs entirely to each other but need to do transact could use a blockchain. This is a textbook case and a real one at that in my experience.

Could you dig deeper into this example and tell us what were the scenarios before and after a blockchain was introduced?

When we started working with these two entities, they were sharing information via Excel files. They needed to transact and make payments depending on a checklist of done/not-done items, but they were also partially trusting of each other. We originally misunderstood it as a payments problem, but it was quite simply about lack of trust and information sharing. Further, communication and transactions could get quite messy to reflect policy changes. This would, in turn, require another set of updated Excel files.

In fact, our initial suggestion of a blockchain was met with an unqualified refusal. After all, why would two companies that operated in a distrusting loop want to expose transactions on the public blockchain? It’s only when we clarified that we would use a permissioned blockchain and, furthermore, no cryptocurrency, that we were able to win them over. A fair bit of consulting and design thinking workshops also helped in articulating how things would work on the blockchain. Coming from a traditional mindset and a regulated industry, I doubt we would have been able to convince the companies without those efforts.

When we did finally move the business process to a blockchain, it addressed every one of their bottlenecks in a short span of time. Even as a proof-of-concept and with a system far from flawless (we were using Hyperledger Fabric version 1.0 Alpha release), the two entities reaped more benefits than they could have possibly imagined.

Note that for over four years, the two entities had struggled to come up with a risk-free way to open up information to each other. Seen in that context, the blockchain was a leap into the future.

There are several businesses that need help articulating the problem they are trying to solve and deciding whether or not they even require a blockchain in the first place? How do you go about using design thinking or any other tool to help such businesses?

Design thinking starts off with a persona and their pain points. This approach is helpful in very many cases. In my experience with companies and helping them suss out the need for a blockchain, starting with a persona can be restrictive. Instead, I have found greater value in following an isolate-and-iterate approach.By this I mean, trying to isolate and going directly to the problem and looking at the actors involved.

“I then follow an iterative question-answer approach that involves asking the customer ‘What if they were to use a centralized database? Is that a possibility?’, ‘Are they prepared to use a centralized intermediary?’, ‘What’s the level of trust between the two parties: complete trust, partial trust, distrust?’, ‘Do they need provenance and immutability?’, and so on. It’s when all the boxes are ticked that the problem becomes a legitimate use case for a blockchain.”

What’s more important, we don’t employ a big-bang approach where blockchain is introduced to change everything. Instead, we slice out a large chunk of some business process into smaller ones and drilling down to the one clear process, where blockchain can make a difference.

Once these parts have been accomplished, it’s just a matter of making the right architectural choice in terms of whether it should be a public or permissioned blockchain.

This interview continues in part 2.