An API Story Chapter 1
The Glaciers are Melting!
Authors: Roland Brunner, Simon Alioth
“Mince alors!” Coming from the lips of general partner Jean-Jacques Leboeuf, a man bred from an early age to display the poise and dignity of an old-school Geneva private banker, the outburst was a shock to everyone at the executive committee meeting.
CIO Louise Lagrange was also shocked, but not surprised. Like the alpine glaciers that feed Lake Geneva, Banque Leboeuf’s assets under management had been in slow retreat for years. But the announcement from chief relationship manager Philippe Belloni that a twenty-five-year old chemical company heir had just withdrawn 300 million Swiss francs was like one of those huge chunks of ice falling off into an alpine lake and flooding the whole valley. Any more catastrophes like this and the bank’s future would be in serious jeopardy.
Leboeuf continued his uncharacteristic tirade, aimed squarely at the embarrassed-looking head of relationship management:
“What are you guys thinking of? You’re going to have to up your game. What’s the point of spending millions sponsoring events like the Geneva Regatta if our highest-potential clients are going to jump ship?”
Philippe tried to defend himself:
“I know you think the old wine-and-dine recipe is all it takes, but those tactics just don’t work anymore, especially not with our younger clients.”
Leboeuf grunted. The argument had been simmering for several months now, but with no sign of resolution.
This bothered Louise. Since joining the bank straight out of university with a PhD in applied math, she’d worked her way up through the ranks. She’d grown to value the old-fashioned approach that had made the institution so successful for more than 200 years. But she wasn’t blind or stupid, either. Things were changing fast in private banking, and they were struggling to find a response. IT, she reckoned, should be part of the solution. But half the time, with the business clamoring for fixes and nine-tenths of her team’s time spent on fire-fighting, or compliance and data privacy issues, it felt like IT was more the problem.
Privately (she didn’t dare admit it to anyone else), she was pretty frustrated.
Suddenly, Louise was jolted out of her inner monologue by something Philippe was saying to Jean-Jacques:
“The latest generation of high-net-worth individuals aren’t interested in sailing or golf. What they want is mobile banking and investment apps with all the digital bells and whistles.”
Philippe’s words jogged Louise’s memory. A couple of weeks back she’d received a memo from her youngest and brightest IT project manager, Finn Galbasini. He’d explained that he’d caught up with an old college buddy at a reunion in Zurich who was now working for Google on an API driven integration project. This friend had talked about his work, and it got Finn thinking about how the bank could be using APIs to facilitate the development of new digital apps for clients and relationship managers.
All of a sudden, Louise realised Leboeuf was talking to her:
“What about you people in IT? If it’s basically a tech problem, I expect you to be taking the lead.”
Louise took a deep breath. It was now or never.
“Funny you should ask. I have something that could work. Any of you heard of API led architecture?”
Judging by the blank looks she received from everyone around the table – apart from CFO Tania, the only other female in the C-suite, who gave her an encouraging nod − Louise was going to have a lot of explaining to do.
First thing she did after the meeting was call her trusted consultant:
“Tell me what you know about APIs. Should we be thinking about getting our API management capabilities up to speed?”
There was a brief pause, and what sounded to Louise like a chuckle, before the consultant replied:
“I thought you’d never ask. Where do I start?”
“You could start with the basics: why do we need an API platform?”
“The bottom line is that it’ll save you a lot of money – and a lot of blood, sweat, and tears.”
“How so?” asked Louise.
“Because it cuts out a whole layer of work and costs involved in doing things the traditional way. Once you’ve invested in your core applications to offer API capabilities, you can build on the existing APIs whenever you launch a new project – instead of having to reinvent the wheel every time you want to integrate a new application.”
Louise though she got what he was saying, but wasn’t quite sure. “I think you need to really go back to basics.”
The trusted consultant took a deep breath before speaking. “Okay. It works like this. Every IT system has its specialisation; in other words, it does what it’s best at. In an API driven architecture, each system exposes its core capabilities through APIs. These are so called system APIs. In an API platform, there are micro services which orchestrate a more complex process by calling system APIs in the correct order. These micro services expose their capabilities themselves as so called process APIs. Finally, when integrating external applications, you only have limited possibilities to define how the APIs are designed. You are limited to what the vendor offers. Here, the experience APIs come into play. To integrate the application, you will build very light weight micro services, which accept the API structure defined by the vendor and map it to internally available APIs. Such an API platform is designed to enable each IT system to make its specialisation available for other systems to benefit from, gradually hide the complexity of internal processes and leverage existing integration ways. To do that it uses so-called system APIs. With me so far?”
“Yep, I think so.”
“Good. A crucial component of the API platform is a catalog of all the available functionalities. Often, this catalog comes in the form of a developer portal where all existing APIs are published with their structure and some supporting documentation. When designing the architecture for a new systems you can use this catalog to select the suitable APIs to integrate with. This means that instead of having to do project-specific integrations each time, you can re-use what you already have and…”
“So that’s where the cost savings come in,” interrupted Louise.
“You got it!” The trusted consultant sounded pleased. “Now you’ve grasped the basics, I think we should get together to start drawing up a business case.”
Louise was excited: “If it works for you, I can free up the whole of next Wednesday. I’ll make sure my project manager’s there too.”
“Great. I suggest inviting your head of Release Management along as well, at least for part of the meeting. Introducing micro services will have a significant impact on your technology stack and release processes. That’s why in the meantime, you might want to think about hiring a DevOps engineer. Good ones are pretty hard to find, especially on short notice. See you next Wednesday.”
To be continued…