There is one factor powering most major technology megatrends that’s not immediately obvious: from Crypto to AI to Data Science, everything depends on APIs and a broad API ecosystem. Let’s take a look at this hidden megatrend and why you need to address it to stay ahead of the game.
Megatrends
On the buzzword bingo scale, this term certainly scores high. :) Looking beyond the word which is being thrown around a lot, there seems to be agreement that there are certain trends which many people expect to have a global impact or relevance. Thought leaders usually are the large analyst firms such as Gartner, and they make their bets on things like AI, blockchain / crypto, sustainability and something they call “superapps” (think Tencent’s WeChat).
Of course they’re not omniscient, but they have a pretty good grasp of the current hype cycle, and looking towards Asia helps making predictions of what will be relevant globally - simply because Asia as a market is so powerful and often ahead of the curve. In other words: in order to thrive, companies need to adapt to these megatrends - the sooner, the better.
If you look at Gartner’s strategic technology trends, you will notice that they have one thing in common: they massively depend on APIs to retrieve and exchange data to deliver their respective value. Without APIs, there is no crypto and no superapp. And it’s not just an API here and there, it’s a whole ecosystem that connects all the dots to provide the foundation these megatrends are built upon.
The API Economy
The role of APIs has changed over the years. From simple interfaces to transmit data between software monoliths, they have matured into the core binding element that glues modern services together and, as a result, have become a core part of the "operating system" of our world. Our lives depend on APIs, may it be for transferring money between bank accounts, making phone calls, booking a holiday trip, routing internet traffic, or buying that cool gadget in your preferred online store.
Just in the same way professions of people diversified more and more over time to allow for more specialization on increasingly complex tasks, software was broken down into services to solve specific problems in the best possible way. By applying (standardized) public interfaces, these services became interchangeable, essentially turning them into lego bricks.
This works as a catalyst for rapid growth. Rather than building everything yourself, you can now focus on building the core of your value proposition and take advantage of the lego brick infrastructure for authentication, payment, database connectivity, shipping goods and the like. Taking this one step further, you can also utilize APIs to distribute code, control virtual machines, and even host a website (Vercel) or APIs themselves (say hello to WunderGraph Cloud! :). At the same time, this allows you to always use the best solution available, preventing you from re-inventing the wheel in potentially inferior quality.
As an example, take a car manufacturer such as Volkswagen. They have created platforms upon which all VW brands build their individual cars. Most of the components can be taken off the Volkswagen shelf so no time and effort has to go into developing the basics like engines, buttons, infotainment screens and the like. And still, even if an Audi's DNA is largely VW, it still feels, drives and looks like an Audi. That's the Audi engineers' value creation on top of Volkswagen standard parts which allows them to sell their cars at a premium price.
Instead of solving all challenges as part of a product, the API economy allows you to build a product on top of existing building blocks that solve specific problems. This allows you to focus on value creation rather than reinventing the wheel.
On the supplier side, making services available through APIs expands their business opportunities.
Still, many tech executives think about their services and features first, and then about the internal and external APIs to accompany them. In my opinion, this is fundamentally wrong and will lead to companies either going out of business or missing out on growth opportunities.
For success, adopt an API first mentality and strategy
As you will know from agile methods, it’s all about the mindset. Thinking API first is the same paradigm shift like thinking about solutions instead of features. In a solution-driven, customer centric approach, you work your way backwards from identifying the true customer need to the product that solves the problem, rather than thinking “this feature is cool, let’s build it because we like it so much” (I’m oversimplifying, of course ;).
Applying this to APIs may seem counterintuitive at first. Building an interface before you actually have the service ready? I’m not talking about the concept of mocking an API, which usually happens after the feature has been defined. It’s a good approach, but API first goes beyond by asking and answering these questions:
- How can we help customers create substantial value by using our API?
- Which API landscape is relevant to our customers?
- How would our customers prefer to integrate an API?
- How would our customers use the API
- How can we make our service most accessible to our customers through the API?
In general, your product can be as good as it gets - if your API falls short, your chances of success are considerably reduced. One might argue that there are many companies out there providing sub par APIs and people are still using them, but one effect of the API economy is that the overall quality bar is rising, and what customers accept today might be no longer viable in the very near future.
By building an API with a great developer experience, you will make it easy for devs to want to use your service (do not underestimate this factor). If you got the value proposition right, building out the functionality behind the API will be absolutely customer centric, and it’s very likely that your teams will be very efficient. After all, it’s clear from the start what the API needs to serve and in which way, so creating your user stories should benefit from a lot of focus.
An example for API first and commoditization of services
Let’s assume you’re a meteorology company and you want to leverage the value of your weather data. The usual way is to just expose an omnipotent API in the way you see fit. The API first way would be to validate what would actually provide the most value to your customers - is it really the full set of data? Is it different data? How often will they need it? Which information are your customers about to correlate your weather data with? This is likely geo data, so it’s probably smart to start your API design with a great and simple way to query for a certain location. But wait - is this a single geo coordinate, or is it actually a region represented by a polygon shape on a map? How do you need to aggregate your data to deliver the right information in this case?
By answering these questions (and many more), you will end up with an API design that tells you exactly how to build the service behind it, and it should also be possible to deduct an MVP that will already make many of your customers happy. At the same time, you will not waste any developer hours by building something that’s not relevant.
Even more importantly, with your new weather APIs (as you’ll likely opt to expose several small APIs rather than one fat “know-it-all” API), you are able to compete with other services. If you have done your job well, your weather services will become lego bricks used very frequently by other developers who build their products on top of, or including yours. If you fall short in this race, you risk not being a factor in the value creation of others as part of the API Economy, which leads to missed business opportunities and, at the end of the day, to a lack of relevance in a critical market.
In order to participate in the API economy, commoditize your APIs by breaking them down into smaller units rather than offering a fat and heavyweight API that does everything.
Providing the right added value through the right API will become a critical element of success.
Building the API bricks
To stick with the bricks example, and to circle back to the term API Economy, the importance of providing the best possible bricks increases as services are built more and more on top of others.
As an OEM, you will want to control parts of your value chain, but you certainly don’t want to build every component yourself as it increases your process complexity and cost base (there are exceptions, of course). It’s all about the right focus: do what you’re good at, what nobody else can do better than you - and for everything else, select the best of breed and include it in your product through an API.
Following this logic, more and more products will appear that are powered, not just supported, by external services – also because it’s faster to build that way for the vast majority of products. And, as we know, being faster than the competition is a huge advantage – time to market makes a difference.
Successful companies will have a clear idea of which services they need to provide as part of the API Economy in order to be relevant, and maybe even become a quasi-standard for an entire industry.
Assuming all these advantages are compelling enough, why do many companies still not take that route?
Challenges to overcome in order to go API first
From my standpoint, there are three main reasons:
Internal APIs are not mature enough
Of course, in order to expose data in the right way, you need an infrastructure that’s up to the task. If your internal APIs are a mess, it will be very hard exposing data through an external API. Usually the problems that exist internally just travel and become a liability for your development team and, subsequently, your customers. This is an area where an open-source tool like WunderGraph can make a big difference.Developers are inexperienced with building a world class API
Not every developer is an expert, and this is absolutely fine. However, building a really good API experience will be hard if your team has no or little experience in doing so. If you still go for it, you might end up with a mess of tools, integrations and infrastructure dependencies. As a side note, this is the reason why we’re building the cloud version of WunderGraph, which will remove the infrastructure problem once and for all (sign up for the beta wait list here).Traditionalists at work
This is maybe the biggest, non-technical issue. Many times in my professional career, growth opportunities were missed because decision makers clung to their traditional ways. One specific challenge is to understand one’s product as “just a building block” rather than the greatest invention humanity has ever seen. At the end of the day, the question is if business opportunities are more favorable if your product acts as a lego brick and thus participates in the API Economy, or if you keep it walled off.
There may be more factors at play, but it all starts with bringing up the topic of API first and doing a thorough review of your product and technical landscape if you haven’t done so already. On the management side, it is paramount that you ensure the discussion is open-minded and honest, and that you always focus on the opportunities, not the challenges. You will be able to tackle them soon enough if your teams unite behind the idea of going API first.
Taking advantage of the API Economy
So, which benefits come with the API Economy? Just to name a few (feel free to add more):
On the API supplier side:
- Minimum waste, maximum focus on value creation for the customer
- Goes hand in hand with the goal of customer centric product development
- Working with your services internally will become a breeze, allowing you to build on what you already have much faster than before, reducing time to market (even more so if you use WunderHub to share APIs :)
- Your service may become a critical element in other companies’ products, unlocking additional revenue and insights
On the API consumer side:
- The larger the API Economy, the more choice you have of selecting the best possible solution for a specific part of your product
- If you manage your APIs by means of a tool like WunderGraph, the services you’re using become interchangeable. Not happy with a service? Just swap it for something better!
- You can build a new product super fast if the right building blocks are available (might not apply to every product, of course!)
- You abstract away problems that others have already solved, allowing you to focus on true value creation
How WunderGraph unlocks the benefits of the API Economy for you
As a general statement, you should consider which tool you will be using for your API ecosystem, regardless if you’re a supplier or a consumer. The more APIs you have, the greater the challenge of managing and maintaining them - internally and externally. Doing this without a dedicated tool is likely to become a challenge in its own right, so take care of this before your journey begins.
We have built WunderGraph to address all these challenges and provide the best possible developer experience. WunderGraph not only allows you to integrate and manage all your APIs and data sources, but also to expose auto-generated, secure APIs as needed. On top of that, WunderGraph Cloud will provide a ready-made platform so you don’t have to worry about infrastructure when you build your back-end. Finally, to bring all your APIs together in one place, there’s WunderGraph hub streamlining the collaboration on and distribution of your APIs.
In short, you should be asking yourself if building APIs is your core expertise and value creation. If it’s not, then let a tool like WunderGraph help you. Metaphorically speaking: when you have chosen your path to enlightenment (API first), make sure you follow that path in a race car, not barefoot. :)
Disclaimer
This is an article in the “Business” section of our blog. As much as technical readers are welcome, you’re likely better served in our Education or OpenSource categories.
Top comments (0)