In some enterprises, getting the corporate buy-in for a comprehensive API strategy can be immensely challenging. Forward-thinking product owners are met with many roadblocks from stakeholders: “we’ve always done it this way,” “it’s too risky,” or “don’t we already have an API?”, among others.

In this article, we’ll take a look at six reasons not to adopt APIs. While these explanations can sometimes be valid, they’re usually just excuses. As a result, we’ll also explore how you can debunk these arguments, referring to advice from Maria Garcia, Innovation Strategist and Program Manager at Amadeus.

1 – “We’ve always done it this way”

Old habits are perhaps the single greatest cause of resistance to API adoption. You might think this was a bigger issue in the mid-2000s when web APIs had yet to prove themselves, but old habits continue to be a major part of our decision-making process. Just a few years ago, when looking to grow internal API consumption at Danske Bank, API Product Owner John Madsen identified old habits as a major setback. “You can present something that is brand new […] but people don’t really want to change that much,” he says.

So, how do you approach the issue of old habits? John recommends a slow and steady approach to changing company culture, by raising awareness for the strategic benefits of an API strategy and encouraging others to build more long-term solutions. However, the benefits aren’t always enough: Maria also acknowledges the risks of not adopting APIs, such as inferior digital agility or a loss of competitive edge. Make these issues clear to stakeholders, and it may help to sway them.

“People will only move towards the unknown if they genuinely believe that the risks of standing still are greater than the risks of moving forward.”

2 – “It’s not in the budget”

Cost is another reason organizations might be hesitant to build APIs. Aside from the opportunity cost of building APIs — which we’ll discuss in just a second — there are direct costs associated with maintaining them. Even if you’re developing it yourself, you still need to account for the cost of hosting, support, and marketing. And as soon as you outsource a developer portal or API gateway, the costs can quickly pile up.

If cost is a genuine concern, look to educate stakeholders on the potential cost savings or monetization opportunities of a well-executed API program. This is particularly powerful if you can provide concrete estimates of how the APIs will pay for themselves; for example, you may find that replacing existing partner integrations with APIs frees up account managers to work on other projects.

In the long term, know that repeatedly hearing “it’s not in the budget” might be an issue of misaligned priorities. If this is the case, Maria’s risk-focused approach to leading change can help to create urgency for APIs.

3 – “It’s not a good time”

As we’ve established, there is a clear, dollar cost associated with hosting APIs and their supporting assets. With that said, a much more significant cost is the opportunity cost of having developers spend months building APIs when they could be working on other projects. Especially if an organization presently derives value from one-to-one partner integrations, this might discourage stakeholders.

Know that this is a good reason not to want to drop everything and pursue an API strategy. However, it’s not a good reason to throw away APIs altogether. Assuming stakeholders already recognize their importance, Maria suggests starting small (while still thinking big). A minimum viable API product which supports just a few use cases can still demonstrate plenty of value, without requiring much commitment. You can then build on success with more support from stakeholders. If that doesn’t work, another strategy is to request the buy-in to begin working on APIs at a specified future date — say, 6 to 12 months down the line.

In recent years, the web economy has transformed into a platform economy. It could be argued that now is the absolute best time to focus on APIs. Otherwise, institutions will face missed business opportunities and missed partner opportunities as competitors become first to market.

4 – “It’s not our job”

This is another argument you may have heard when asking about APIs. It’s difficult to answer since the stakeholder isn’t denying their value; instead, they’re shifting responsibility to someone else. Of course, this can be a valid excuse at times: if someone else is responsible for integration strategy (or lack thereof), this response is only natural. But what about when this excuse is just that — an excuse?

First, make sure that stakeholders understand how wide-reaching the benefits of APIs are. Explain how they can bring value to businesses in practically any industry, in a variety of ways. Stakeholders might not be aware that an API infrastructure can serve partners while facilitating internal development. In fact, because of this, API adoption should be a collaborative effort across the entire organization. If this isn’t enough, you can always fall back on Maria’s suggestion to highlight the risks of standing still, especially as they relate to your team.

5 – “It’s too risky”

There are definitely risks involved in pursuing an API strategy, and stakeholders recognize this. During development, there’s the risk that things take longer than expected, increasing the opportunity cost and disrupting the timelines of other projects. Then, there’s the risk that nobody will use your APIs. Finally — and perhaps worst of all — there’s the risk your APIs will directly lead to a security breach.

You can try to balance these risks with those of not adopting APIs, as described earlier. Perhaps a more effective approach is to meet individual stakeholder concerns with plans for concrete mitigation measures. For example, if stakeholders are particularly worried about API security, Maria would suggest starting with a GET-only API. Similarly, if adoption is a concern, optimizing for developer success and improving marketing can improve engagement.

6 – “Don’t we already have an API?”

This last rebuttal originates from the fact that many large organizations already have some kind of legacy integration interface. Old, point-to-point processes may suffice in the eyes of stakeholders — or worse yet, they may be confused with APIs. After all, don’t they offer the same basic functionality?

To address this issue, ensure that stakeholders see the practical benefits of APIs over other integration methods. Most notably, APIs are flexible, one-to-many interfaces, while traditional integration methods, like those based on ESB or ETL, rely on single-purpose components. This means that APIs can serve a multitude of clients and use cases, boasting much greater value-for-money.

Postamble

If you’re pushing for API adoption at your organization, chances are that you’ve heard a fair few of these excuses. With any luck, these pointers provided by Maria, John, and ourselves will help you to score the buy-in for an API program. Remember: it’s all about highlighting the benefits of adopting APIs and the risks of not doing so… those skeptical stakeholders won’t know what hit them!