With many online retailers looking to adopt a headless approach, there is a surprising lack of end-to-end analysis of its impact on day-to-day operations. Reading through articles from the first few pages of Google results on this topic, I see numerous examples of headless commerce benefits but very few (or almost zero) mentions of challenges to consider when implementing this type of architecture.
This article is meant to be an honest overview of both the good and bad that come with headless commerce. Having a clear understanding of headless architecture’s impact on your business will help you to decide 1) whether this approach is the right fit for you and 2) what processes and systems need to be in place to maximize the ROI of your journey into headless commerce.
Benefits of Headless Commerce
Better UX
The main reason companies like Amazon, Netflix, Net-a-Porter, Best Buy and many others have chosen to invest in headless architecture is the beautiful and consistent user experience it helps them to deliver. A continuous growth of customer expectations made UX a clear focus for retailers in 2017, with 43% of them listing delivery of a seamless customer brand experience among the top three priorities, according to Boston Retail Group). Furthermore, retailers are now required to do more than just meet current customer expectations; they need to anticipate what those customers might want tomorrow, next month, or even next year. In fact, 50% of consumers are likely to switch brands if a company doesn’t anticipate their needs (NRF’s 2018 Retail Trends Report). Headless commerce’s rich capabilities can help retailers gain a competitive advantage through delivering a superior UX regardless of UI or geographic location while also enjoying many other benefits of this approach.
Faster Turn Around for Front-End & Flow Changes
Now that changes to the front-end don’t affect back-end systems and vice versa, plus the ability to reuse APIs and assets, the testing scope is contained to individual components of your commerce architecture. As such, platform upgrades, performance fixes and the addition of new features and functionalities take less time and resources. In traditional commerce architecture, updates can be deployed every few weeks; headless architecture allows you to reduce that time to days or even hours (and seconds in the case of Amazon).
Lower Development Costs
As there is a larger pool of resources specializing in the languages and technologies used in common headless frameworks than in Oracle Commerce/ATG, implementation of headless commerce often results in savings as retailers can assemble teams of highly skilled front-end developers without breaking the bank.
Easier to Find Answers to the Technology-Related Questions
There is a very large and strong community around headless architecture, microservices, and the common languages, toolkits, and platforms used. This makes it pretty easy to find answers to your questions in either publicly available documents or by asking for advice on one of many forums dedicated to Node.JS or React, as examples.
Lower Load on ServersIt can take a significant load off of the ATG servers if you move logic up to the headless layer. If you have a caching layer, such as Redis server cluster between the headless layer and ATG, you can drive an even greater reduction in load on the ATG tier of your eCommerce infrastructure.
Lower Risk of Critical Failures
If done right, compartmentalizing different functions of your commerce environment and introducing limited interconnections ensures that failures or risks associated with one API remain isolated, preventing/minimizing the impact on other systems.
Reduced Dependencies on Individual Technologies
You can now mix and match different technologies to create the exact commerce solution your business needs. You no longer need to compromise or use a solution that meets less than 100% of your needs. For instance, you can now power your commerce with an eCommerce engine from one solution (e.g., Oracle Commerce, SAP Hybris, etc.) while using a CSM from another and an Inventory Management solution from yet another – and so forth.
Benefits/Challenges
Lower/Higher Commerce Licensing Costs
Depending on your licensing model, going headless can allow for additional savings or result in additional costs. Decoupling the front-end from the back-end means moving work off to “headless” servers, which is great if you use core-based commerce licenses. On the other hand, since many headless layers will make multiple API calls to Oracle Commerce/ATG per page, costs for metric-based licenses can increase.
Challenges of Headless Commerce
Higher Infrastructure Costs
The result of decoupling your front-end from the back-end is two separate environments (or sets of environments) that need to be hosted and managed. As you will need more infrastructure to support the same level of traffic, related costs can also go up. In addition to the month-to-month infrastructure costs, there is an upfront investment required to redesign your commerce application and design the front end.
Harder to Manage
A whole new set of technologies (Node.js, REACT, npm, etc.) comes with its own set of bugs and security vulnerabilities that need to be monitored, patched and upgraded on an ongoing basis. As a result, you will need to expand your team’s skill sets (or find a right partner to provide them) in order to properly install, configure, tune, troubleshoot and support your front-end along with your back-end 24x7x365.
Longer Time to Troubleshoot
Adding layers to your commerce environment can increase the time and skillsets required to identify the root cause of issues and troubleshoot them. If you are getting the wrong response or bad data somewhere, you now have additional layers, tools, and technologies involved that the transaction has to be traced through and for which debugging and/or log analysis has to be performed.
More Development Resources Needed
This is the other side of enabling small and fast releases. With more independent development projects taking place simultaneously, there is a need for more resources to handle this additional work. Separate development teams for the back-end (ATG) and the front-end (headless layer) must be created and managed. Testing efforts also need to be split up with separate test cases and, in some cases, separate QA teams.
As long as you have clear, repeatable processes in place, knowledgeable people on your teams and reliable partners to implement and manage the new architecture, headless commerce can be a game-changer for your business. Check out our Headless Acceleration Framework page to find out how to reduce traffic to your Oracle Commerce application by 70%.