An unfortunate truth of APIs is that they rarely sell themselves. Even internally, many organizations find themselves met with subpar adoption when they take a set-and-forget approach to rolling out new APIs. The good news, however, is that there are plenty of ways to mitigate this, ensuring steady API consumption among both internal and external developers.

In this article, we’ll look at three reasons an API development team at Danske Bank — the largest bank in Denmark — saw poor adoption of their internal APIs, and the steps they took to set growth on a much steeper gradient.

The Path Towards APIs

Before they adopted APIs, Danske Bank’s technical architecture very much fit the stereotype of any bank: monolithic and slow-moving. With some systems that were over fifty years old — and continuously growing — it was difficult to improve, fix, or build anything. Not to mention, many of the systems were built on outdated technologies. John jokes that many issues could only be solved by “that one specific person.”

Naturally, this heavy IT architecture resulted in a reduced speed of change. It could easily take half a year, a year, or even longer to develop new products and services. As a result, the organization decided enough was enough — and it was time to untangle the mess.

John briefly explains the process of how Danske Bank managed to silo their technical systems into API-ready subdomains. To start with, they divided their existing stack into three layers: a foundational layer (mainly consisting of a system of records), a process or function layer (providing meaningful data to consumers), and an experience layer (responsible for individual customer touchpoints such as apps).

Then, at the foundation layer, the bank broke down its system of records across object-oriented subdomains — for example, customers. Each of these objects then became the basis for an API (or set of APIs).

Set-and-Forget Performance

After successfully abstracting away from the complexity of their mainframe, Danske Bank was able to build an extensive suite of intuitive, internal APIs. Having created these APIs, they expected consumption to quickly grow without much promotion.

Unfortunately, the team was met with a slow, steady consumption graph — and not the hockey stick curve they had anticipated. John imagines that this is the case for many banks and financial institutions that took the same approach. But what did Danske Bank do wrong to be met with this sub-par internal API consumption?

Identifying Setbacks… and Addressing Them!

In hindsight, John identifies three particular setbacks in the consumption of their internal APIs: old habits, friction, and a lack of marketing. He explains each of these issues in-depth, also discussing some of the solutions used to tackle them.

Old Habits

Despite a suite of brand-new, sleek REST APIs, the team found that developers were unenthusiastic to change. This is because, elsewhere in the organization, separate groups were continuing to support alternative integration forms. The prevailing viewpoint was: if I can still use this point-to-point integration, why change?

The Fixes

A definite solution to this reluctance for change was simply to deadline older integration methods. By announcing that they would drop support for a specific point-to-point integration in three or six months time, John found that developers were quick to react, adopting the new APIs. Of course, this harsh approach requires buy-in from managers. In doing so, Jon notes that timeframes can always be used as a bargaining chip.

Perhaps a more accommodating fix was that the team also pushed for changes in company culture. By encouraging others to build longer-term solutions with the APIs — and defending the importance of doing so with managers — the team was frequently able to nudge developers onto a more strategic course.

Friction

Developers who did want to adopt the new APIs were met with another issue: friction in discovering and consuming the APIs. Indeed, the team offered an API discovery tool, but John says that simply too much “stuff” had been pushed into there, leading to early frustration.

A subsequent cause of friction was security tokens; developers were unsure how to create them. This misunderstanding made the new REST APIs challenging to consume from separate platforms.

The Fixes

The natural solution to this friction was to improve the developer journey. By improving the above areas to make the onboarding process easier, developers were more likely to pursue API-based solutions. One area Danske Bank did not struggle with was API-specific documentation, but others might.

Marketing

It should come as no surprise that the team — a group of techies “down in the dungeon” — completely overlooked the importance of marketing. Battling a tight schedule, they did almost no promotion for their new APIs. Naturally, this meant fewer developers knew the APIs existed in the first place.

The Fixes

The fix for this lack of marketing was simple: the team had to get out and sell their new APIs. This meant knocking on plenty of doors. They reached out to internal development directors, engineers, architects, CIOs, and business folks to share their latest developments. John found that with each meeting, the initiative gained momentum.

The Results

So, what were the results of Danske Bank’s many maneuvers to improve API consumption? Fortunately, growth quickly sped up. While it wasn’t the exponential growth John had hoped for, he could sense that the new APIs were gaining traction through the organization. Tell-tale signs of this new-found growth, he reminisces, were when developers began to call him — saying things like “I heard from him/her that you have some new APIs” — or when business folk began to invite him to present the new APIs to others.

Summary

Even the best APIs can suffer from slow adoption. In this post, we looked at three reasons why Danske Bank’s internal APIs were slow to gain traction. According to John Madsen, a Product Owner who fought this battle on the frontline, old habits, onboarding friction, and a lack of promotion are all major causes of poor API growth. With any luck, the solutions presented herein should help to minimize these issues, ensuring sure and steady adoption.