The new big thing is APIs! Ironic, since when I did my computer science degree back in the seventies I was taught that everything as about programming interfaces (what we now call application programming interfaces): firewalls against the evil bugs seeking to infect and bring down more and more of the system. My copy of Glenford J Myers’ seminal work “Reliable Software through Composite Design” – which introduced the measures of cohesion (a Good Thing: the degree to which the code behind an API stands on its own two feet) and coupling (a Bad Thing: the degree to which two pieces of API-supporting code depend on each others’ insides).i I was writing operating systems. When you are writing operating systems, your main job is to protect the computer (then it was a mainframe) from whatever the programs could throw at it. The program might fail: the whole computer must not. The pinnacle, it seemed to me, of safety in operating systems, was ICL’s VME (which I did, myself, ahem, work on) which not only had paging to allow multiprocessing but also segmentation which helped keep processes unable to infect each other. I won’t go into details (you’ll be grateful for that) but it helped. And that was where APIs were the be-all and end-all of what we did: everything had to come through published APIs. Divide and conquer, you see.
This is a rare thing: a Sibos blog that is not from Sibos. Oh I had big plans this year: I did a few blogs just to whet our appetite beforehand, in the lead up to Sibos. I had my themes all worked out for the daily blogs – from our Saturday night party (guest speaker, Dr Leila Fourie, CEO< Australian Payments and Clearing Association), from our Sunday morning round table business session (guest speaker, Kristy Duncan, CEO, Women in Payments), from our Sibos Booth (booth L51), from our Open Theater session (contextual banking) and from our lead sponsorship of the phenomenal Sibos-to-Money 20/20 currency race: the Great American Bank-Off – which, by the way, our racer, Ameélie Arras, won. Yeay!! And then… And then, the Sunday before I was set to travel, I ended up in hospital. Nothing threatening (though I didn’t know that at first). But no food, no drink, and certainly no travel, no Toronto, no Sibos. Instead, tubes, needles, tapes, drips, drapes, sips. Sips, actually, was a major step forward. So to my regular readers: apologies. I wasn’t able even to blog from my hospital bed (the doctors told me off for trying to type!) As consolation, one blog this year, post-Sibos, post-AFP, post-Money 20/20, post-EuroFinance, post-hospital, post-haste, post-free.
If I may get technical for a moment (don’t worry, bankers, I’ll return to banking in a bit), it all led to objects. One thing about low coupling and high cohesion is that you want the-code-behind-APIs (let’s just call them APIs) to be re-entrant. That means different processes can run the same code and it doesn’t get confused. For example, if a piece of code writes temporarily an important number to a named file and then reads it back later it isn’t re-entrant, because if two processes do it at the same time the one named file will get overwritten. More than this, there were often times when an API needed to store some information between different calls of the API: for example to assign a unique number different for each invocation. Objects arose first, then, as a way to preserve state across multiple calls of an API – without compromising coupling and cohesion. Nowadays, processes needs not only to be stateless but also need to survive being abandoned (just like what happens when use Expedia to find out the price of a ticket but don’t bother booking it). Abandonment causes all sorts of technical problems that are generally called garbage collection: thankfully, we bankers don’t need to worry about that.
Interestingly, the Big Leap Forward in usability came intricately intertwined with this object orientation. Alan Kay wanted a computer children could use as a learning tool and he needed to create simple graphics and keep them in their own places. So he came up with WIMPs: Windows, Icons, Mouse and Pointers. Before then (and anybody millennial or later won’t know this) to interact with computers you typed what was called a command – when the computer was ready (it usually said to you, “>”) – most of which elicited a response along the lines of “Error.” To build this, he needed lots of things to happen to lots of other things – eg windows, icons, mouse (clicks) pointers etc – but they all needed to be kept separate. So his colleague Adele Goldberg created a pure object oriented programming language called Smalltalk (beautiful but slow) from which by way of C came C++ (ugly and obtuse but fast) and then Java (much more interesting name).
Why, I hear you cry, oh why, does this matter to me?
APIs are the new FTEs. So says an article by Gaurav Jain in 2015i though I think I heard it before. But, as many commentators have noted, they are the way to open doors between enterprises. Once again, standards can make amazing things happen. Just look what they did for shipping – containerisation arguably destroyed the profitability of the ports of New York and Liverpool and fuelled the growth of Port Elizabeth and Rotterdam. See the box.ii APIs are the new FTEs because they do work for you. I can already get “computers” to do so many things for me – tell me where I am (GPS), what time it is (clock/alarm), what the weather is like, what the traffic is like as well as actions – submit my tax return, book a restaurant table, buy well, almost anything, gamble, advertise a job, get a job, etc. Anything you can do on the internet you can program a system (aka a product) to do.
Well, many of us know that and have done so, for a while. For me, the interesting thing is not just that it means if we can export services as APIs we can make money/invoke others’ services as APIs also make money. It is how it impact the sort of information that needs to pass along the API. So here’s a concrete example. Last weekend with some lifetime savings I opened two ISAs (a UK tax-efficient savings vehicle), closed two regular savings accounts (whose interest rates had dropped from 5% to 0.05%), open two replacements and moved several thousand pounds through enough accounts in this process using Faster Payments to make it like they do in the movies when they are hiding money. All in around half an hour on one day, plus another half hour to make sure the new accounts had the best rates. The APIs behind this do not just allow it to happen, they are full of associated information. For this, and extending to some other common scenarios you will recognise:
So, phew, banking. Contextual banking – that thing about understanding what a business is actually trying to achieve – and maybe even anticipating it – means lots of need for this sort of information. At Sibos our contextual banking platform went down a storm (and not just because everybody loved hearing Alexa on the Echo Dot). For example, when it helps you choose a method of payment by showing graphical ratings of speed, cost, safety etc, these are just what people want.
But – here’s the crunch – to get this it’s not just a front end from a channel system vendor. You have to have a payments system that can – through the APIs – tell the front end what each rail costs, how long it takes, how safe it is. That’s true contextual banking.
Want to see it? Go to igtb.com and watch the video at the bottom of the scroll.
And one thing I leanred: the human body is far more complex and fragile than you realise. Yes, I knew that. But from my hospital experience, I now truly know it.