This article was originally published on the commercetools blog.
In the 1990s, commerce applications were made to produce output that was suitable for the technical infrastructure back then: PCs, large CRT monitors with 800px resolution and slow dial-up modems. At the time, nobody thought about creating and maintaining a public-facing API, the main reason being that no-one could consume the data provided by an API and do something useful with them. Online retail was exclusively done via PC-based browsers.
With the beginning of the mobile web and the rise of the Internet of Things, this has changed considerably. These days, there are more and more applications and devices which are using various APIs to send and receive data. Take native mobile apps for example: Once you install them on your smartphone, they still need to communicate with an entity which is delivering the data. If you are using the BestBuy app, it needs to fetch all product data and send the shopping cart info back to the server once you have decided to buy things. This communication happens via APIs – they have become the central and universal hub for data exchange.
As a result, vendors of aforementioned commerce application monoliths decided to do something about it and quench retail companies’ thirst for APIs. After all, these applications have been (and still are) at the core of some of the biggest web stores in the world. They introduced various API layers to their already very complex applications to open up retail data and processes to the API economy. Also, retailers invested heavily in creating their own customized APIs and put them on top of their existing platforms.
A few years ago, next-generation commerce platform providers such as commercetools opted for an entirely different approach to account for changing user behavior. They are building platforms which follow an API-first strategy: solution architects and developers focus on making a well-documented, flexible and secure API before thinking about frontend applications and anything else. In other words, instead of creating an API afterwards and upgrade an already existing legacy solution, they are building an API from scratch.
Todays’s retailers need APIs – both to let their customers interact with new devices and to enable applications to exchange data. If they are running a monolithic commerce platform and want to add an API, they have two options:
1) API-First: Migrate to a modern solution and benefit from an API which is available out-of-the-box
2) API-Last: Keep the legacy solution and add a customized API
Implications for business
Solution architects and developers will most likely be inclined to choose option 1, for a number of reasons Kelly Goetsch has pointed out in his recent article (Why APIs Are the Future of Commerce). However, how about business owners? What are the business benefits of going for API-first? Or, put differently, what are the risks of an API-last strategy?
1. Increased effort for development and maintenance
Retailers relying on applications which were built in the 1990s will have to invest considerably into making them ready for today’s commerce. Depending on their data structure and the overall infrastructure, adding an API can be very costly – both regarding implementation and maintenance. In fact, there are many cases in which those efforts surmount the costs of a complete migration to state-of-the-art technology.
2. No sustainability, detriment to long-term vision and investment
If a retailer aims at getting a quick win by adding a half-decent API to his stack to perform a certain task – maybe to offer a new function – option 1 is often more attractive at first sight. However, this is not a sustainable strategy, and, in the long run, companies build up more risk. Every investment retailers make into short-term solutions takes business decision makers further away from realizing their long-term goals. It is a vicious circle of investment: Every million they pour into adding more bits and pieces to their old stack makes it less likely for them to overthrow it completely at one stage because so much has been invested already.
3. Keeping staff and hiring new talent becomes harder
Developers like to work with technology which is up-to-date and allows them to get tasks done professionally. What they do not want is to experience any bad surprises because new code they add brings down the entire application. In other words, they do not want to be held responsible working on an already very fragile construction. If they have the chance, they will move to companies who are more advanced technologically, making their everyday work more productive and secure. Also, if they are API experts, it is far more likely they will choose an employer “who gets APIs.” Retailers sticking to old tech and only patch things up will see a serious brain-drain and will have to put much more effort into hiring new talent.
4. No possibility for externalized R&D and fostered innovation
By definition, the setup of API-last applications makes is necessary to rely on internal resources for innovation. Whenever an idea comes up that would require API functionality, business owners would have to engage in “API addition projects” before this idea could be realized. Ergo: time and money. On the other hand, having an API out there by default and being able to externalize it allows third parties to use it at will and get creative. Retailers should think of this as their external R&D department giving them clues about where new business opportunities might develop.
5. Missing out on new revenue streams and wider reach
There are numerous examples of retailers benefitting from opening up their API already: the REWE grocery delivery service provides an API that allows members of cooking communities to buy the ingredients for their recipes right from their site. In other words, REWE creates new distribution channels, builds new partnerships, and extends its reach without having to invest in a new API – being API-first, it is already there. Other examples of major retailers externalizing their API are BestBuy, Target, and Zalando.
In the future, we will see many more examples of retailers benefitting from an API-first strategy, and business owners are well-advised to view a highly advanced API as a strategic investment. Otherwise, they keep patching up timeworn machines with some shiny new gadgets – not a viable option for a long-term vision.