[00:00:12] Prit: Good morning, everybody. Welcome to our fifth episode of Talking Edge, live from the sunny London. I’m your host Prit, Chief Executive Officer at ALT21. For this episode, I’m excited to be joined by John Schlesinger. John, who has many of you know through the newsletters this week, has been recently appointed to the board of ALT21.

Earlier this week, John, I spoke to a mutual friend of mine about your appointment, who had one thing to say to me, “No matter how much you think you know about any subject, John knows more. Make sure you listen to what he has to say.” We’re all very excited to have you on board and to have your strategic inputs in scale.

John’s been working in FinTech long before it was called FinTech or it was even called. He’s held a number of senior roles across firms that had a huge impact on FinTech, such as IBM, Capgemini and many more. But most recently, over the last decade, John has been Chief Enterprise Architect at Temenos, the large banking software company where he’s overseeing the transformation of the company’s technology to scale and meet the demands of the world’s largest banks, and move from on premise to cloud appointment.

In this episode, we’re going to discuss the important technology changes that have enabled the customer facing FinTech innovation. In addition, we’re going to debunk a few technology myths, as well as discuss practical lessons from John’s 40 years of modernizing enterprise software. John, welcome.

[00:01:49] John: Thank you very much, Prit.

[00:01:51] Prit: Maybe we’ll start off by just hearing from you a little bit about your background.

[00:01:55] John: I started my working life at IBM, as you said; I was there for 16 years. I did a new role every two years. Until I joined Temenos, that stayed true all through my career. I started off working with Shell, helping them move their systems from the old Shell Mech systems to the Shell UK system.

Then after various similar roles facing customers, I went over to France to help connect IBM mainframes to the Minitel systems. The Minitel is a forgotten thing now, but in the 1980s it was like a dry run for the internet. France had a terrible telecom system in the 1970s, the worst in Europe. They completely modernized and they built the first all-digital telephone and data network in the world. But they had no users and they won’t use it. They decided to give everybody a little terminal made by Sony, $200, in exchange for not taking the telephone directory. That created an incredible surge of digital services in France in the mid-1980s. My job was to help build the software that connected IBM mainframes to that Minitel network. When the internet came round a decade later, I said, oh, I’ve seen this before!

After doing that for two years, and the piece of software we wrote was phenomenally successful in France, which by the end of the 1980s was 95% of the world’s market for X25. It dominated X25, which was the open protocol before the internet came along.

I went and worked on CICS, Customer Information Control System, which was and still is the world’s most successful ever commercial software product. I think there were 400 of us working on CICS, and IBM’s profit per employee was a million dollars.

I never thought I’d leave IBM, but IBM had a meltdown in 1993. I left and went over to New York, where I’d always wanted to work. We worked on application middleware, then worked on data middleware. I became product manager for RSQL. We joined the invented ODBC with Microsoft.

After my stint at Information Builders doing that, I alternated between being chief architect for a software company and being a consulting enterprise architect. I did two years as the first Global Chief Architect for Dan and Bradstreet, then did integration projects on Wall Street as an enterprise architect, then went to Highway Software again as chief architect. Then I came back to London as enterprise architect at Capgemini and that’s us, and then joined Temenos. In this role I’m doing both at the same time. I’m acting like an internal enterprise architecture consult and also as a chief architect.

[00:04:59] Prit: Sounds like from your experience, you’ve seen technology change and move so quickly. How do you keep informed of all the changes that are going on?

[00:05:09] John: Well, technology is the opposite of a duck. You say, a duck looks like it’s serenely going along the water, underneath the stuff there is furiously churning. Technology is the opposite; the stuff at the top, fearlessly churning, but underneath things are pretty much the same all the time.

As you said, after four decades you see the same things coming around every 10 years. As my boss at Temenos once said, “I teach at the fashion industry. You get all these fashion terms that are, a moment of microservices, APIs, et cetera. Before that it was service oriented architecture, and before that was client service – all these fashion terms. But the underlying reality of what you have to do to make it work hasn’t changed at all.” Every time a fashion term comes along, I have to make a decision in my own mind. Is this just fashion, and people generating churn for its own sake, or is there something real behind it?”

I dismissed SOA as being a myth. I’m embracing microservices from the point of view of you need it for maintainability, especially on shared services. Vendor architecture is absolutely essential. Some of them are worth having, some aren’t.

When I arrived at Temenos, my job was to tell a story about how you take a monolith and break it up. I had six slices of the monolith to break it up, and we told stories about those six slices and we’re still telling them. For example, one slice was to slice of the user interface off and make all the surfaces headless, which I called the interaction framework. It’s about interaction. People now call that APIs. But API is a thoroughly misleading. What people call APIs are actually remote procedure calls, not local application programming interface calls. Secondly, you use remote procedure calls and local API calls all over the place for different things, but the thing they want to use it for is interaction. You can’t use it end to end for integration, for example. In fact, I would say that’s the number one mistake people make in enterprise architecture, is confusing interaction and integration. It’s very easy to do that. I had integration and interactions in two of my slices, but we now call them APIs and events because it’s trendier.

[00:07:37] Prit: You obviously have a vast wealth of knowledge and experience in being a sharp end of innovation. But what would you say is a good reference point for somebody to really learn about enterprise software or the industry as a whole? Or are you going to write a book one day and let us all find out?

[00:07:55] John: I’m going to write the book. I started writing the book when I was running the enterprise architecture practice at Atos Consulting. I wrote a half a dozen papers to form the spine of the book. But I’ve been learning so much at Temenos, about application software that I’ve been putting it off until I’ve got that organized. But I think now is the time. My aim is not to write a book next year.

[00:08:26] Prit: Amazing. There you go, Talking Hedge first, getting exclusive on the book to be read by everyone. Bringing it back to maybe a rapidly scaling company like ALT21, what’s the single piece of advice you might give somebody like us at this stage?

[00:08:46] John: From an enterprise architects point of view, the single most important thing about the systems that support a company like ALT21 is making sure you know who owns them. Ownership is the number one question, which is one of the reasons I hate working for government or doing something with government, because it’s extremely hard to answer the question in government, who owns the system?

I remember one of the first engagements that Achas was the creation of Yodel, the delivery company. It was formed from two other delivery companies that merged. We had a big meeting up in the Northwest, everybody was there, and they started talking about the systems. Every time they mentioned a new system, I would ask the same question. I’d say, “Who owns this?” Inevitably someone in IT would say, “Well, I own it.” I’d look at him and say, “Oh, so you paid for this out of your own budget.” He goes, “Oh no, I don’t pay for it.” I said, “Well, surely the owner is the person who pays for it. It’s not the person who runs it, it’s not the person who uses it, it’s the person who pays for it.” They’d say, “Oh, okay. So you want to know who pays for the system?” I go, “Yeah. I want to know who pays for the system.” In some cases, they would have to think hard to find out who owned it.

I did some work with Freshfields, a huge law firm. They had an excellent chief architect there. He had on his wall a lovely diagram, which showed all of the systems that supported Freshfields. If it had a single unequivocal owner, it was coded in green. If they didn’t know who owned it, they coded it in red. If they thought it had multiple owners, they coded in a mixture of red and green. He said, “My aim is just to turn this diagram green.” That was brilliant. I thought that was one of the best things I’ve seen.

I’ve been on the technical advisory committee with ALT21, a lot of what I’ve been doing is saying: who owns this domain? Who owns the banking domain? Who owns the foreign exchange domain? Who owns the customer domain? Who owns the back office domain? Who owns the analytics domain? Just make sure that you’re providing value for money for that person.

[00:11:08] Prit: Very good way of breaking down the business ownership of that project. I think we often get too deep in the weeds of it all to look at it.

[00:11:22] John: If what we’re providing isn’t giving good value for money, you have to find it from somewhere else.

A breakdown of a business between brand, risk and compliance

[00:11:28] Prit: When we had a call last week, John, you gave a very simple breakdown of a business between brand, risk and compliance, which I thought was just brilliant. Maybe you could just give that overview for our listeners.

[00:11:42] John: I have very few original ideas, but I’m very good at picking up ideas from some other people and applying them maybe in areas they wouldn’t have thought of. Just before the dot com crash during the dot com boom, a lot of companies with no expectation of profit had huge valuations on Wall Street and JP Morgan. JP Morgan, that was before they merged with Chase, wanted to know what they could do to get some of the valuations for their shareholders. They had a think-tank called Lab Morgan – an absolutely wonderful place. They said what you needed to do was to turn the company into separate IPO units, and they reckoned there were about 50 IPO business units in JP Morgan. That raised the question: if these 50 units could be sold, what represents JP Morgan? What is the central bit?

The brilliant insight they had was that it’s brand, risk and compliance, which marries neatly into the front middle back view of commerce and record-keeping, and there’s a thing called resources, events and agents, which is the accountant’s view of record-keeping as opposed to bookkeeping, which I think is another brilliant insight. It lines up with that as well, because they said the events have three kinds, and they line up with brand, risk and compliance.

Brand is the front office. It’s how you relate to your customers. You can have brand across all of your business units. That belongs to the entity as a whole. Your risk lines up with your middle office. In fact, I once met the guy who claimed he invented middle office and he said, it’s about management of real time risk. That’s where you have your relationship with your stakeholders – the people who invest in the company and the employees. Compliance is the back office, and that represents your relationship to the communities in which the company operates.

The brand, risk, and compliance, I’ve used that ever since as a way of explaining what’s going on in the organization, trying to tease out the relationships. It works brilliantly. But in the end, the JP Morgan didn’t IPO 50 businesses, instead they merged with Chase. That was quite interesting because we were starting a project called straight-through information at JP Morgan, to create these independent units that represented brand, risk and compliance run by the head of finance. There was no office in JP Morgan on Wall Street big enough to hold the kickoff meeting. We actually held it at the top of Chase. The chief financial officer said, “Welcome to this project, here in the heart of enemy country.” Next day, they announce their merging with Chase, and cancel the project.

Software has changed a lot, but is there still a typical lifecycle of a software company?

[00:14:40] Prit: Thanks for that, John. Going on to enterprise software, software has changed a lot. But is there a typical life cycle for a software company?

[00:14:52] John: Yes, and this doesn’t have to be enterprise software. I think this applies to pretty much all software companies. There are thousands of people all the time with brilliant ideas for software. They’ve played with PCs and they know how to program, they have an idea. They quit their job and they maxed out their credit cards, and they do a lot of coding. 99% of those never get their first customer. The first thing is finding someone who’s going to pay for what you’ve done. That’s the first phase. Once you have your first customer, you’ve got going. You have you bonafide a software company. The problem is that it’s such an effort to get that first customer, especially in enterprise software.

For the second customer, you do the same thing you did for the first customer, which is just do whatever they want to make sure that they buy the product. If you do that roughly 30 times and you don’t maintain a common code base across all of your customers, you end up with an unsupportable customer set. You’re spending so much time and effort on the maintenance that you no longer have any bandwidth to do new product developments.

Temenos, we’ve acquired a many of the companies we’ve acquired, because they’ve got to that step that they’ve got 30 customers, but that the maintenance overhead is overwhelming them.

The second phase is getting past 30 customers with a single code base. That’s when you enter the race to be a unicorn, is when you get past that phase. Then the third phase, and I’ve worked for several companies that were at that third phase when I was working for them, roughly when you get to half a billion in revenue in dollar terms. To get there, you’ve built a team of people that the CEO, possibly still the founder, really trusts. The modus operandi is to give roles to people, not assign people to roles. That will get you to half a billion. It’s unlikely to get you to a billion in revenue. A billion valuation is a unicorn, but a billion in revenue is a big software company. If you want to get to that billion in revenue you have to at some stage flip it. This is typically when the founder leaves and the new CEO is put in place. You flip it so that you have an organization that you know can scale and you fit people into roles in that organization. You flipped from some giving roles to people to giving people to roles. That’s the final stage. At that stage, you’ve now become scaling up to be a worldwide global, large software company.

How important has the separation of distribution and manufacturing been for innovation?

[00:17:38] Prit: That’s very interesting. One of the most important changes we’ve seen in the last 20 years, probably brought on by the internet then most recently open banking, has been this separation of distribution manufacturing. How important is that change for innovation?

[00:17:59] John: It’s absolutely crucial. Again, this is something that I brought to Temenos. The very first whiteboard session I did with my boss, the CTO, was about separating out distribution for manufacturing. At that stage, I was still calling it front office and middle and back office. In fact, it wasn’t until a buy-in, banking industry architecture network meeting, where the CTO of DBS presented, that I started using the terms distribution and manufacturing.

But the reason I was able to bring that to Temenos when I joined was because, those two or three years during integration projects on Wall Street were all about the separation of the buy-side from the sell-side, which has exactly the same separation.

Before that I’d done work in travel when I was at IBM, and that was the first industry in terms of its system support, to separate distribution manufacturing.

In the early 1980s, the US government had an anti-competitive lawsuit against American Airlines because of what they were doing with the Sabre reservations systems. They were offering travel agents, and whenever they asked for a route they were showing the American Airlines segments first. A whole bunch of things happened to settle that dispute, one of which was setting up six global distribution systems in the airline industry. A travel agent would not talk directly to one of the airline reservation systems or one of the hotels systems or one of the car rental systems. Instead, they’ll talk to a global distribution system. The four big ones were American Airlines and Sabre, Worldspan, Galileo and Amadeus. I was working for IBM when we built the Galileo data center, in Greenfield, London, which then got moved to Swindon and became a nationwide data center later, and then moved to Denver.

I was on the due diligence team 20 or 30 years later when Swindon acquired Galileo. I saw that from beginning to end.

But the global distribution systems now provide all the information to the travel agents, and the intermediary travel agents from the reservation systems. They should call it global distribution systems, because that’s what it is doing. They called all the systems behind inventory holders, but there are manufacturing systems.

The problem with the airline industry is as well as having the airline reservation system, they also have to fly airplanes. The banks work exactly the same way, except for they don’t have to fly their planes; what comes out to the manufacturing is the product. That’s what I say about Temenos. We’re in this unique relationship with our customers, because we write the product that manufactures and distributes their product.

All industries started to follow that separation of distribution for manufacturing, starting with travel. I don’t get my phone service from a company that runs a phone network. I don’t get my gas and electricity from companies that generate gas and electricity. In financial services, capital markets are separate from the sale side to the buy side. The buy side is distribution, the sell side is manufacturing.

Banking and insurance are the last two industries that are still monolithic. The only way you can get a bank accounts is through its channels. I started talking about this separation when I joined in 2011. In fact, I started to talk about it a decade before that, the CIBC. We did the architecture for capital markets. I was talking to the then Chief Architect in 2001, and I said “Don’t you think the same thing is going to happen to banking?” We drew up what it would look like, and I was reusing those diagrams. I’m still using those diagrams now.

Open banking is like a chisel neatly placed between the front office and the middle and back office, separating distribution from manufacturing. The regulators put the chisel there. What we don’t know is how hard it’s going to hit the chisel. Is it going to hit it with a 10-kg sledgehammer or is it going to hit it with a feather? It’s looking more like a feather than the 10-kg sledgehammer. But PSD2 has prompted open banking regulatory initiatives all over the world. There are over 60 jurisdictions doing it now, and they are separate. That will cause open banking to occur.

But I have to say that the banks are not embracing it, they’re tolerating it. When I was at IBM, we used to say for everything we had to do when developing CRCS: IS this a best of breed or a least hit change? I think that the banks are treating open banking as a least hit change.

Is the role of APIs overblown and why?

[00:22:39] Prit: It’s a good way of thinking about it. You briefly touched on APIs earlier. People get very excited about APIs, APIs being the root of all ecosystem models. Would you argue the role of APIs is overblown? Is that what I caught earlier from you? If so, why is that?

[00:23:00] John: Well, you have to position the API correctly in the architecture. The APIs, which are remote procedure calls, are the way you separate the user interfaces from the services behind them. That’s an absolutely crucial role, and is necessary. It’s much more difficult than people think it is. Here’s why: if you want third parties to use your API, your API can break the programs that use it. The evolution that takes place, and there will be an evolution, it has to take place in an upward compatible way, at some level.

The problem with accessing business systems through APIs is that the business systems may be changing. You may be configuring them to have new data, or you may be refactoring your system. You need to have an API that you offer third parties that is about the capability they’re offering, and not about the systems that implement them. That in itself is difficult. People talk about having two layers of APIs: an API that you offer to the public, programmers would call that public interface but the industry tends to call that an experience API; and then the API that you talk to the actual underlying systems, programmer call it a private interface, but the industry calls it an enterprise API. You have experience and enterprise API, they have to map one to the other. That’s what you would do to have an open API that wants to do it.

But that’s not what banks are doing. What banks are doing is they are commissioning user interface has to be written for a set version of the systems and the API. Then when that changes, they just rewrite the whole thing. That works for them because they own both user interface and the systems. But that certainly wouldn’t work if they’re offering it to third parties. That’s one of the reasons why open banking is looking at least hit, not best of breed.

What’s interesting is, people are calling their APIs rest, which stands for representative state transfer, which was the architectural concept underneath HTTP 1.1, built by Roy Fielding. Probably one of the most successful protocols ever deployed, maybe up there with TCP/IP, maybe even more successful than TCP/IP.

Roy Fielding wrote a thesis about it and published some papers on representational state transfer. people call their HTTP API rest, but they aren’t. They are straight up PCs, procedure calls. But if people were to do a proper rest API, that would have all those characteristics that you want. It would be about the resources, not about the underlying systems. It would allow you to write a user agent that would exploit the resources that are defined at the time you write it, and if new resources are added, it would allow you to tolerate them until you write a new version of the user interfaces that exploits them again. You’d have exploit, tolerate; exploit, tolerate; progression. For one reason or another, no one’s doing that. Open APIs in banking are suffering.

The other thing is that people are seeing PSD2 as being about APIs. But it isn’t. PSD2 is a business to business relationship between distributors and manufacturers. If you look at all the other industries that separate distribution from manufacturing, none of them use APIs. They all use messaging protocols. The airline industry has a messaging protocol between global distribution systems and the inventory holders. When the buy-side separated from the sell side in capital markets, they use fixed sessions. They still do, but that all happens over fixed. That is not an API, it’s a renting mechanism. The reason for that is the only way to scale this distribution manufacturing separation is to use asynchronous events.

One of my party pieces in banking is to say, there is one part of banking that separated distribution from manufacturing a long time ago. That is the ATM, the automated teller machine, or people call them ATM machines. That’s an automated teller machine machine. They use a pin number, which is a personal identification number number. When you go to the machine, stick your card in and ask for a hundred euros, it will go to the bank account for funds reservation, then will come back and say yes or no if there is funds reservation, and it will give you the money or not. But that is not synchronous, it’s asynchronous. It’s two one-way messages: funds authorization request that gets sent, and a separate funds authorization response that comes back. The device handler behind the ATM, typically base 24 from ACI, will receive the request, put it in its database, admit the request for funds authorization, and commit the task. Then it will go and do other work and eventually a message will come back. A listener will pick up the message, give it to the handler software in the device handler, and it will correlate that message to the database, pick up the session, say: yes, you can your money.

The typical timeout before you say it could not contact your bank is 43 seconds. I’ve calculated that if you didn’t do it with two asynchronous messages, you’d need about 300 times as many CPUs, if the banks were going slow. It may be 300 times cheaper to do two one-way messages than to do synchronous call.

When you go from one system to another, it’s always going to be cheaper and better to use one-way messages than to do synchronous calls. But because people fixate on the user interface and its interaction with the front office systems, they forget about this. It always a rule of thumb when I was at IBM doing business system planning, that for one transaction entered by a person pressing a button into an information system, that you do five more transactions behind the scenes. If you concentrate just on the user interface and its transactions, you’re only talking about one sixth of what the enterprise does.

One of the reasons that was hidden is because a lot of it takes place in bulk process. But as we move to event-driven architecture, which is cheaper, better, faster, and that bulk gets broken down into real-time events, it will become much more obvious that five, six, or what the enterprise does is that event-driven stuff.

[00:30:08] Prit: Do you think people think APIs are about integration when in reality they’re about experience?

[00:30:14] John: Yes, I do. One of the reasons for that is that a lot of the people who start doing integration architecture started as programmers. Just a universal rule for me, every programmer thinks integrations are remote procedure calls. I do have a good experience; the Bank of Ireland, I took them through doing enterprise architecture in 2007. It was my first big engagement at Capgemini. I took him through this. It’s my fifth golden rule of integration: for one system to get any other system to do something, you have to have three transactions.

I’ll take them through this. I set, for example, the ATMs, and they said the ATMS are synchronous. I said, “No, they’re not.” We got out of the base 24 manuals, and there’s two one-way messages. That was 2007. 2012 when I was at Temenos, I got a call from one of those architects, who said, “John, are you a pint?” I said, “Why?” He said, “Because ACI came to talk to me about their new systems, and they didn’t know that base 24 does two one-way messages!”

It’s knowledge you have if you’ve done it. But if you haven’t, you think it works another way. This for me is the fundamental problem of enterprise architecture, to separate interaction from integration.

Do you have any golden roles for people trying to create systems that allow them to make better decisions?

[00:31:46] Prit: We’ve got five minutes left. I’m just going to run through a couple of questions that we’ve had. I think I’ve only got halfway through the questions I wanted to ask you.

I’ve got a question from somebody who’s in a high growth business and working on reporting and creating a suite of dashboards to allow them to make better decisions in real-time. Do you have any golden roles for people trying to create systems that allow them to make better decisions?

[00:32:13] John: Yes. The industry calls it CQRS, command, query responsibility separation. But again, the airline industry, when I did that project, Swindon to acquire Galileo, the airline industry was adapting to travel agents being replaced by booking engines, looking at Skyscanner and Travelocity. When a professional worker does the job, you can pretty much say there’ll be five reads for every right, five looks for every book as they say in the airline industry. The look to book ratio for years, was 5:1 one. When Saber had to face Travelocity and Skyscanner instead of travel agents, it went to a 1000:1. All of the global distribution systems the shopping query onto a separate system designed for that, and then have the updates go through the original airline reservation system.

In banking, as our channels increasingly are internet facing, not employee facing, we have to do the same thing. We should expect look to book ratios of 1000:1. I’ve run round all the banks and asked them, “What’s your look to book ratio?” They say, “Well, we don’t track it. But we can tell you that the average online mobile bank user logs on 25 times a day, and doesn’t do any transactions.” They are saying, from that point of view, that the mobile bank is like infinite look to book ratio, and they do it for transactions on a laptop.

My recommendation would be, whenever you design anything that’s going to be channel facing, have the reporting run on a separate service, separate database, from the record keeping. In the 1980s, we thought you can have a single database to do both, but we now know you can’t. It’s because the physical model, the record keeping database scale should have no indexes, the reporting database scale should be fully indexed. They have different logical models. The logical model of the record keeping is, I need to keep just enough information to have the precondition of the next transaction. I don’t want to keep any more information than that. Any more than that makes the system cost more. The reporting system is the exact opposite. It’s a historical view of everything that’s happened.

Different logical models, different physical models. That’s the number one rule for scaling a channel facing system.

What’s the role of that complaint banking, albeit on a customer web 3.0?

[00:34:43] Prit: I have another question here from somebody. I didn’t think we’d get this session without a question on distributed ledge technology. They’re asking: what’s the role of that complaint banking, albeit on a customer web 3.0?

[00:34:56] John: Distributed ledger technology is two things, smart contracts and blockchains.

I did some research and wrote a paper for the Temenos back in 2015, on blockchain. It’s a distributed database, that’s the first thing. Just looking at distributed ledger, to begin with, the smart contract ledger, there are roughly speaking three kinds of distributed database. That’s because of the cap there. Database can be consistent and/or available and/or partition-tolerant. It can be any two, but not all three. You can have one that’s consistent and available, and you can have one that’s a consistent and partition-tolerant, and you can have one that’s available and partition-tolerant. Those are the three.

The distributed ledger is one that’s available and partition-tolerant, which gives it a problem with consistency. Well, they’re all designed to be consistent and partition-tolerant, which gives you a problem with the availability. The way I position DLT is it’s really a back office database. What that means is it manages an asset – manages the ownership of an asset. Your application fits DLT if it’s about the ownership of an asset in the back office, if it’s inherently collaborative and if it’s relatively slow-changing. The reason for that is, it’s back office database, so it’s about change of ownership by managing ownership of assets.

It’s collaborative. Instead of having multiple instances of database maintained by different people with messages passing between them, you have one instance of the database they all access. That’s the collaborative bit. Because that involves a distributed consensus, possibly relatively heterogeneous, it’s not going to be very fast. In the middle office where you exchange risk, that’s always two parties. It’s never multi collaborative. You don’t want to use DLT for middle office. What do you want to use there is a message. But you can use it for the back office.

I looked at what we do in Temenos, and what we do is front and middle office. We don’t do back office. We don’t manage the general ledger of the bank. We send data to the general ledger, but we don’t manage it. There’s no asset that we own and manage in the Temenos product line. I said, “There are lots of use cases with DLT, none of them are central to Temenos. However, there’s one use case that we could go into as a new line of business where DLT would be relevant, and that’s settlement payments.” If you look at DLT projects have gone anywhere in finance, they’ve all been about settlement.

Now we come to smart contracts. Smart contracts involve immutable code. We as an industry are useless at that. I’m very wary of smart contracts, in fact that there’d been a whole series of catastrophes because of smart contracts and not being able to change the code. DIO crashed and burned, the Parity Wallet crashed and burned. The Bitcoin split was because, even though it’s not churn complete, the Bitcoin blockchain does have smart contracts and they couldn’t be changed.

I’m very wary with smart contracts. I’ve had to IBM, when I was working on CICS, we pioneered approving modules and kicks correct. We worked with the programming research group at Oxford on using a Zed to specify some modules. The modules were five times longer to design, but were five times more reliable in production. But they still had bugs. You just cannot produce 100% bug-fee code.

[00:39:00] Prit: I’m conscious of time. I’d like to thank you for joining us on the podcast today. It was very insightful for me to hear your overview and experience and background, and I look forward to working closely with you over the next few years at this important stage of the company. I thank you listeners for joining. Thank you very much for your time.

[00:39:17] John: Thanks very much, Prit. I’m looking forward to it.