Barb MacLean, creator of Fintech Playlist and a veteran builder and an operator of business critical banking and payments platforms, picks up the digital wrench and gets to work with APIs
When I was a kid, we played this card game called Waterworks. The cards all had pictures of different kinds of pipes, taps, and faucets. Some of them were lead pipes and some of them were copper. And the lead pipes sometimes had leaks in them. The idea of the game was to be the first to place the required number of pipe cards to connect your tap to your faucet. And you couldn’t win if any section in your pipe had leaks. Along the way you could put a leaky pipe on top of another player’s lead pipe to slow them down.
Each player had a limited number of wrenches to fix the leak – or you needed to find the right length of sound pipe to fit on top. There were way more lead pipes than copper pipes cards in the pack, so you had to judge how fast you wanted to move: choose lead pipes and risk a leak or wait for the copper ones.
Sound familiar, my banking infrastructure friends? Technical debt is real. Every system has it. You can choose the lead pipes over copper. But you need to pay down that technical debt over time. If you only prioritise new features and moving quickly, the tech debt collector is eventually coming for you. You also need to learn what to refactor and what not to, and when.
There’s no handbook for this. It comes only from experience.
I presented at the Canadian Credit Union Association conference in early May 2022. I had the opportunity to speak on a panel about integration strategy, and, of course, we talked about open banking coming to Canada. And one of the questions I was asked was ‘what have you learned through building an integration platform over the last five years?’.
We told ourselves at the beginning of the panel that we wanted to focus on technology and not talk about people. But I couldn’t help sharing that people are at the heart of application programming interfaces (APIs). APIs may be the language in which two applications communicate, or receive data from each other, but you need people to understand the context in which that API fits; what value it’s supposed to deliver and to whom.
Only once you understand, can you build. You’ll need a small, highly skilled, autonomous team with equally high levels of trust and agency to do this work. It’s an obvious thing to say out loud, but developers think like developers: if you build APIs that you would want to use, chances are so would others.One of the reasons open APIs are so valuable is that they allow data to be easily shared.
It’s way more valuable when it is shared, combined, and recombined in new ways. Data is its own flywheel. The more it’s consumed, the more data is generated, and the more context you have about its use, and, therefore, its value. I love the description Matt McLarty from Mulesoft uses: APIs are the most liquid form of data. Open APIs are about standards. As the API guru Erik Wilde says, you may need point-to-point integrations, but they’re single-serve. And you don’t want to keep building custom integrations for every customer or use case.
In our collective pursuit to not recreate the same spaghetti soup that underpins so many financial institutions, we need to align to using standard data models for our own and other people’s applications. There won’t be One Standard To Rule Them All, because we have yet to find, globally, one that is suitable for every use case. But we are seeing specific widely adopted standards to support payments initiation, access to account or other personal information.
“Technical debt is real. Every system has it. You can choose the ‘lead pipes over copper’. But you need to pay down that technical debt over time”
What have we learned? That, if it’s not already decided, for instance by a regulatory body, pick a standard and start there. You can pivot to emerging standards over time if you need to. But you need a standard to drive scaling the use and sharing of data in a consistent and secure way.
We also learned that you probably don’t want to invent your own standard, or govern it. But being able to make contributions to it as part of a larger community of users is really valuable when you find a use case that it doesn’t support yet. This goes beyond data model standards. Make sure you are paying attention to basic web standards, like http error codes, and being consistent with their use, too.
Avoid having a single endpoint that is the only one that requires something other than Content-Type: application/json because why are you torturing your API users like that, with inconsistency? Something else we learned: the docs almost never match the implementation. Some people are really good about using tools to autogenerate their docs from their implementation. Most are not. Even with a standard that has wide adoption, every implementation is unique. It’s why I have seen organisations concurrently running three different versions of ISO 8583 in their environment! Just saying.
Finally, find people who are turned on by APIs. We’re out there! It’s a fascinating and exciting place to work. And, when you’re surrounded by passionate people, find ways to keep working with them. Because you’ll get to do the best work of your career with and through them.