Skip navigation EPAM

Is an API-First Development Approach Right for Your Business?

  • Retail & Consumer

Headless and API-first have become buzzwords in past years as digital transformation is at the forefront of business priorities. We spoke with Pavel Veller, who brings nearly 20 years of diverse experience, most recently driving digital technology innovations and R&D efforts at EPAM, to get a deeper understanding of Headless and API-first. We dig into what this means for a business and what the price may be for those not making the transition.

Is there a difference between Headless and API-first?

Yes, API-first is more about the product strategy or philosophy, while Headless is more about the pattern of how you integrate with a platform or product.

How should we think about API-first compared to monolithic digital platforms?

A monolithic digital platform that has been around for a while is unlikely to have APIs as its main product, but rather features and capabilities that manifest themselves in a number of different user interfaces, integrations, frameworks and, potentially, APIs. The platform would also own the process of rendering the end user experience. When you integrate a platform via headless, you do not use its rendering engine. Instead, you build your own front-end or have another platform own the rendering process on top of the platform’s APIs, therefore removing the “head” from the platform. Monolithic platforms don't typically have all their features enabled through APIs. Their APIs have not been thought of as the main product and, since they can't typically get everything done through an API, the implementation team will have to create workarounds or build custom APIs to expose required functionality.

Why did API-first become popular?

API-first became popular due to the rise of omnichannel and the proliferation of all the different ways people interact with brands. We have web, mobile, mobile apps, digital kiosks and even bots, and consumers want a connected, customer-centric experience. In order to deliver this and not build snowflake solutions for every channel and touchpoint, brands need decoupled architectures that can cater to each channel’s unique front-end technology/medium while providing essentially the same functionality.

Do you have an industry-specific example?

When looking at the retail industry, there are many factors that drive the popularity of API-first. To be successful, retailers rely on a number of apps for in-store digital experiences, digital signage, in-store personnel support and more. These apps consume functionality that will be provided by the same content or eCommerce platform. The way to build all of this is to have the functionality available now as an API in order to use a channel specific method of building the user experience. Then you can go and grab content delivery APIs, or commerce transactional APIs, or personalized messaging APIs.

Is there a set roadmap for success with API-first or does it follow a more custom approach?

There is always a degree of “custom” when it comes to the business challenges within a company, which are always specific and unique. When we solve particular challenges, we can recommend what tech is most applicable. However, before that can be done, many questions need to be addressed, such as:

  • Is the issue within a single channel?
  • Is there a different long term or short term strategy?
  • What are the consumer expectations?

What are the challenges with monolithic platforms that make API-first necessary?

The constraints of a monolithic platform will push you toward decoupled, isolated architectures. While going API-first or headless is custom for each business, many are already on their digital journey and might be using one monolithic platform or several, which can bring up challenges. A common challenge with monolithic platforms is that they can't deliver features fast enough. Deploying two times a month may be good for a monolithic platform. However, if you have features you want to push every day, and you want to innovate and A/B test, a monolith will not give you the speed and flexibility that you need. If you don't need the speed of innovation in all areas (maybe you need it in check-out, but not on your product landing page), headless allows you to decouple instead of working as a single deployment.

If you decouple instead of using single deployments, what are the benefits?

There are many benefits, for example:

  1. You remove the need for regression testing of the entire monolithic app every time you deploy.
  2. By decoupling, you can move quicker. It can feel risky every time you touch the monolith, making you move slower, but with API-first you gain speed and flexibility in different places. API-first and more specifically micro-services architectures allow you to split your monolith into multiple independent components and work on each one independently. That’s where you get the speed gains.
  3. API-first systems allow you to focus on something specific that is more important to you, rather than always having to focus on the whole.

What’s the best way to get a unique brand experience using this technology?

If your business wants to provide a unique experience that represents your brand, you need to “own the glass.” The glass refers to the top layer or the front-end architecture – the one customers see and interact with on their browser or mobile phones. If you want to own this and be free to do what you want on the front end, you don't want to be constrained by how the platform prescribes you should render and deliver to every channel. To do this, you need front-end engineers to build a beautiful front end, without ever having to think about what systems are underneath. This process removes the “head” from whatever platform sits underneath. The desire to own the glass pushes companies toward headless.

What if I want innovation but I have a monolithic platform and I don't want to spend years replacing it all?

If you have the desire to be faster and innovate in different places independently, you can still make a headless pattern on monolithic systems. This is a great first step. If you don't want to spend years re-platforming, you can decouple the front end and own the glass first. This is essentially going headless on top of what you have right now.

That sounds great, then what?

If you go headless over what you have right now, you can start to own the glass piece by piece. Using the strangulation pattern, you attach the APIs to the now decoupled front end. Before you know it, you have replaced a monolith with an API-first architecture.

Can you give an example of success from switching to API-first?

One recent example that comes to mind is a company that was deploying once a month and, after switching to API-first, headless and decoupled front-end and a micro-services architecture in the back, they now deploy 70 times a week. They are now able to do this because they can push individual features to production quickly. However, it is to be noted that you can't take an existing work structure at an enterprise that deploys one time per month, even if they look agile, and then switch to deploying multiple times a week without making changes. Both a new culture and structure are required within the company to ensure success. This is not just within engineering, but also within the business. This shift requires vertical teams that are theme-oriented, strong product ownership embedded into individual teams and strong program management. Essentially, you don't want teams to run in different directions to innovate. You need program structure and a single vector for the company with enough independence for teams to innovate in order to ultimately see success in the long run.

It's also important to note that nothing comes for free. Modern digital architectures with decoupled front ends, API-based integrations and microservices are more complex than the equivalent monolithic architecture on a single DXP platform. It’s more complex to operate, to observe and to troubleshoot. We pay for all the flexibility and speed gains with increased complexity. Companies that decide to go in this direction need to be ready for this investment and that is why companies like EPAM exists. We are here to help implement customized solutions that work best for your unique business needs. If you decide not to because everything seems to be okay, think about how in a few years from now your competition will have learned these lessons and will be moving at 10x the speed of change and innovation compared to you.

Any final words on why API-first is so important?

Enterprises are competing with digitally native companies, so they feel the need to either become a tech company or they need partners to help enable their technology so they can remain competitive. For example, retailers need to get their engineering to a level of Amazon to properly compete. What we see in the market is that the demand from enterprise businesses to build these experiences is pushing the capabilities of the platforms to meet this demand.

You can find the original article here.

Hello. How Can We Help You?

Get in touch with us. We'd love to hear from you.

Our Offices