January 23, 2023 | 3 min read
Who Wins in an API Economy?
Mario DiBenedetto
Managing Director
Creating systems that use APIs requires time and effort. i.e. money.
Ensuring those systems are secure requires penetration tests and vulnerability scans. i.e. money
And API usage is not free, despite the common misconception that it is.
So with every piece of the process costing time and money, who stands to win in the API economy?
For the uninitiated, APIs, or Application Programming Interfaces, allow different software systems to communicate with each other and share data. In an API economy, companies can use APIs to access data and services from other businesses, allowing them to build new products and services.
The perceived benefits of an API economy include:
- Increased innovation and collaboration: Companies can use APIs to access data and services from other businesses, allowing them to build new systems, products and services that they may not have been able to develop on their own. And, by doing so, companies can execute faster because they are electronically connected to one another.
- Improved efficiency: APIs can automate data exchange and reduce the need for manual data entry, allowing companies to streamline their operations and improve efficiency.
- Improved customer experience: APIs can allow companies to offer new and improved services to their customers, which can help improve customer satisfaction and loyalty.
A few housekeeping points for this article:
- Terms will be used that will drive actual programmers crazy because those terms have very specific implications to them. We apologize in advance.
- xcept for a very small subset of platforms that provide “low code” or “no code” development, using APIs requires a software programmer that knows how to code using APIs. If enough people ask, we’ll write something on when those low-code/no-code platforms are worth adopting.
- Lastly, there could be an entire article on how immature APIs can undermine your ability to get any benefits at all. So, let’s assume that all of the APIs we’re talking about are reasonably mature.
In a recent post, I noted how “anyone can submit an API request and get a response. Just get POSTman. The hard part is everything that surrounds that for workflow and exception handling.” And that is one of the biggest “gotchas” to using APIs:
KEY POINT: Complicated business processes are complicated to program, even with APIs.
If your team has to start with a base set of APIs and create entire programs from scratch, chances are, they will be writing a lot of code. And writing a lot of code should never be your goal.
Companies like Brimma present a counter example in that we have mature libraries of our own API “wrappers” (and we use that term very loosely here) that we have created over time. These wrappers do things like orchestrating individual API calls into groups of calls. When these are built, the exception and workflow variations are accounted for, so we can implement chunks of functionality all at once. This lets programmers write less new code.
That sounds nice on the face, but it’s actually a pretty complex exercise in software design. Knowing when to bundle stuff together and when not to can be the basis for serious geek debates.
And the design choices made when “bundling” APIs can have a dramatic effect on your ability to realize the benefits. Said differently, spending the time to design well is important!
KEY POINT: It takes an experienced (expensive) software developer time to design around how best to leverage APIs.
But even API wrappers, et al, don’t necessarily make it simple to leverage APIs. Let’s draw an analogy between developing systems using APIs and developing using Robotic Process Automation.
Again, for the uninitiated, Robotic Process Automation (RPA) is a technology that allows businesses to automate repetitive and routine tasks by mimicking the actions of a human user. It uses software “bots” or “robots” to automate tasks such as data entry, form filling, and other repetitive processes.
When an API developer is writing software, every API “call” has to account for all of the things that might go wrong. For example, what if the system it’s calling never responds or takes a long time to respond? What if the system it’s calling fails halfway through its response? What if the system it’s calling sends something back you never expected? These are examples of the exception handling previously mentioned. These examples barely scratch the surface of all of the things that require consideration by an API developer.
Additionally, API development is wonderful in that there is typically no forced set of options for what the software can do. The downside is that the developer is left to determine what all of the possible options can/should be. And the programmer needs to write code for every option and, in some cases, write code to prevent options they do not want to allow.
Now let’s contrast those two points with RPA. Since RPA typically operates on top of another piece of software, some subset of the exceptions that might occur are likely to be handled by the underlying software. So the RPA developer gets the benefit and does not have to handle as many exceptions. Similarly, the underlying software has a limited set of options for what can be done at any time. So a RPA developer need only concern themselves with the options available to them.
So RPA developers have inherent limits on what they can accomplish but those same limits can make it simpler for them to develop solutions. A common theme across most of our articles is that simpler is almost always better.
The tipping point in this particular example goes back to the amount of work that has been put into organizing, wrapping, and orchestrating APIs into a framework that fits most of the use cases and, as a result, does not need constant framework revisions. When any organization builds-up the critical mass of code that allows them to plug new APIs into their framework with limited concern for non-business exceptions because they can apply a pattern-based approach to handling them, they will be able to begin realizing the key benefits of the API economy.
This recipe is actually not as dire as it may sound, because there are frameworks available that can advance this agenda for your team. Which framework you use depends on your tech stack, but a quick search of the keywords gets a shortlist. The slightly painful part of this is that your team has to spend time analyzing the available options and learning best practices for implementing the framework. This is still preferable to trying to build from scratch, but does require an investment. Which brings me to another key point…
As described, developing against APIs takes time and, typically, expensive programmers. So, the winners in the API economy will be those that can afford the start-up costs (or partner with a company like Brimma that already has the expertise) and keep the expertise from their investment. A common problem for any employer is that programmers can almost always find a job that pays them more. So, like it or not, part of winning is creating an environment where your key cogs (programmers) feel like they are growing and learning and being compensated well. In the mortgage industry, it’s a lot like an underwriter that is trained on every loan product. If they walk out the door, the cost to train someone else to replace them can be significantly more than their base pay.
