You’ve probably heard the “banks are becoming tech companies” sentiment. It’s an idea that’s been around for years, and it captures what seems like an evolution in the way we consume and use everything from food to money. As consumers, we want options at our fingertips, and perhaps it’s this forcing banks across the world to open up their services with APIs and microservices, and ultimately turning them into tech companies.

Eyal Sivan is Senior Director of Enterprise Architecture at the Canadian Imperial Bank of Commerce  (CIBC). At our 2018 Austin API Summit, he told the story of how and why one of Canada’s Big Five adopted an API and microservice architecture.

APIs are Nothing New

Another statement you’ll have certainly heard is that APIs are “nothing new”, which is true. Eyal acknowledges this — APIs have been around since the ’70s — but back then enterprise architecture could be described by a single, dreaded word… monolithic.

Monoliths were big and bothersome. As Eyal says, “sometimes they were on mainframes that filled entire buildings, and you would speak to these things however you could speak to them.” More an artifact of early digitization than anything else, monoliths had too many interfaces and systems that kept breaking down. It became too costly to maintain.

Enter the ERP, or enterprise resource planning solutions. These were proprietary building blocks that you could use to cut up, package up, and clean up your “spaghetti” (as he so affectionately remembers it). Needless to say, arbitrarily boxing up code didn’t really add much to the systems architecture; ironically, it ended up costing more.

Next came the EAI, or enterprise application integration. While this was an improvement over the ERPs thanks to a slightly more standardized framework, it still fell short in time — fixing none of the problems but being equally expensive and equally proprietary.

Finally, service-oriented architecture (SOA) rolls around. The industry now has a standard for API contracts, and with the introduction of an enterprise service bus each piece of the puzzle can be connected, albeit indirectly. However, as the service bus inevitably began to take on more logic, it grew big and messy in the same way an EAI would.

Since part of the problem was everyone interacting with the enterprise service bus in their own way, the next step was to federate the different schools of thought and give each party their own domain service bus, which could contain whatever logic and follow whatever rules, while still connecting to the main service bus.

Finally, there was a system that worked well for everyone…

Smartphones: Kindling a Change

…that is until smartphones were invented — completely changing the way we interact with IT services. Consumers now had a device which could do everything from everywhere, and that’s exactly what they wanted.

“Everything changed. Suddenly people could order a taxi, a hotel room, a pizza, with a couple of taps on their phone. And consumers expected exactly the same kind of interaction from everyone they do business with, probably most of all the banks.”

This changed the landscape of software development. The cost was no longer the deciding factor — speed was. Developers now wanted to create software that was flexible: easy to maintain and easy to upgrade.

The obvious solution was to break things up into parts, replacing every monolith with a whole suite of APIs and microservices which could be worked on individually.

Time to API Up

Once it was clear that an API and microservice architecture was the one to pursue, the bank pulled out their wallet and went to market. As Eyal explains, buy-over-build was the natural posture at a bank with plenty of money.

Analysts soon discovered that there were no leading solutions in the field, even after exploring the open-source projects, which are usually at the cutting edge of any new technologies. So CIBC took the bold decision to build.

They started with an open source core — the Light framework — before employing the owner of that project around whom to build an entire team. With this, they created the API Foundation, which was shared out to all the same analysts for review.

While they unanimously agreed that the documentation “sucked”, the platform was something new — and it held up to tests extremely well. Eyal justifies the decision to build their own solution for three reasons:

1. It hedges against an incredibly volatile market
2. It allows you to steer the direction of your platform (in this case, it was CIBC’s only solution for supporting GraphQL)
3. It cultivates critical development skills (OAS, Swagger — now OpenAPI, DevOps, daily releases, automated testing/deployment, and so on and so forth).

Building with Purpose

The decision had been made. CIBC was going to build their own microservice and API architecture, and now it was time to get work. But before they could do so, they’d need to establish their guiding principles — among other things — Eyal explains.

Guiding Principles Come First

Every organization has its own priorities, so there’s no one-size-fits-all approach to building whatever kind of network architecture — and although Eyal doesn’t mention it, this is another advantage of developing your own solution.

With that in mind, you need to establish your guiding principles before you get going. The dichotomy Eyal focuses on is proliferation versus standardization and governance. That is to say, do you value a solution that’s easy to build upon (with, say, adding new functionality every day), or a solution that’s well-kept and easy to maintain?

For the record, the right principle is probably somewhere in between.

The Goal Product

Next up, it’s important to appreciate the nature of the goal product. Eyal stresses that they did not build a “magic box” that takes care of everything, which would be a modern repackaging of SOA in that it eventually hits a wall.

Instead, they took a distributed gateway approach to embrace microservices — the “secret sauce”. Let’s note here, that while you might be able to package all the same functionality into a monolithic mainframe and expose that with APIs (which would be significantly simpler), you’d then be stuck with no space to grow.

CIBC then took the microservices and gave each one an embedded gateway. That way, the microservices can act and be managed independently to one another in every aspect, from security to analytics. There’s no blanket ban on centralized gateways, but they are used for operations that are truly centralized.

As Eyal points out, the rise in popularity for these architectures, or service meshes, is actually worsening volatility — yet another reason to cultivate development and management skills in-house.

CIBC’s Service Mesh Plus

Aside from the embedded gateways, CIBC has purpose-built plenty more features into their service architecture in order to make things as smooth-sailing as possible — hence the label of Service Mesh Plus.

For one, they’ve chosen to move away from the typical homogenous mesh (where each user shares the same mesh), including a series of light proxies and routers to improve compatibility.

What’s more, they’re looking to implement federated authorization — a trust network across OAuth servers.

Acting Like a Tech Company

While some of these things might seem foreign to you, Eyal notes that doing APIs and microservices the right way forces you to act like a tech company. That is “the critical skill here; treat your assets more like products.”

The uberization of banks is coming, so acting like a tech company is, according to Eyal, a “shift for banks to survive.”

That’s presumably why Eyal’s not afraid to share how far CIBC has come in that regard:

• The API Foundation is used across the bank, with a governance council mandating its use — unless there’s a good reason not to.
• There’s a managed container environment with a development network already in place.
• They’ve created an adjacent developer training program, with the goal to create an internal community around the platform.
• There’s a pilot of the API marketplace available today, with a self-serve model allowing developers to use the API without a single meeting or call (allowing cost savings of 50–70% per integration).

Eyal’s Tips for Your API Platform

Here are some of Eyal’s tips for building your own high-yield API platform, with the fantastic metaphor of a brick-and-mortar building:

• The four pillars: Developing a powerful network is a balancing act. Grow your API, cloud, DevOps, and agile strategies together to keep things running smooth.
• The foundation: Your solution needs to be built on top of a solid foundation, which runs from your technology and operations team, through the company’s organizational structure, down to corporate values and culture. Can you convince bank officials that innovation is the right focus to have?

Eyal finishes with what he considers the single most important idea for success: build for change. IT systems are changing, and while we can’t know where they’re headed, we can build with that uncertainty in mind.