Headless Commerce: Your Integration Strategy is Critical for Success

Headless is gaining popularity with digitally native brands and brands that have scaled to the point where they are pushing the visual content and personalisation limits of mainstream SaaS ecommerce platforms. The desire for visual consistency across all channels in a unified commerce-forward world makes headless interesting. In my last blog article on headless commerce, I examined the API-centric approach of decoupling the front end visual layer from the back end business functions. Clearly, headless is not for everyone; an understanding of edge issues is important.

In this article, we will explore the need for a comprehensive integration strategy in light of headless commerce. The integration strategy will impact not only application choices but also integration architecture and data warehousing. If you search the internet, you will find dozens of articles talking about the speed and ease of RESTful API integration in a headless world. I love all these articles because they paint an almost perfect world where data flows easily and without constraints across APIs. The reality is far from true as anyone on the front line will tell you.

APIs have Constraints

Every RESTful API has a personality. The personality reflects the mindset and experience of the developers who made design choices and built out the API as well as the underlying tools that were used to construct the API layer. APIs also have transaction and data limitations. These limitations again are based on design decisions, platform constraints and include things like API throttling, the number of calls that can be made to an API, access to data elements as well as business objects, the latency of data return, etc. The presence or absence of web hooks makes a huge difference for near real-time speed, and not all RESTful APIs have webhooks built in. Then there is the increasing use of Graph QL.

None of this ever gets mentioned in the headless discussion. Ask any seasoned integration expert and they can tell you stories about lack of functionality, throttling, and data elements that are either not accessible or simply not available. Despite what you read in many, many internet articles, it is not API nirvana.

Strategy Becomes Critical

So when considering headless over a monolithic SaaS e-commerce platform, one needs to make the integration strategy front and centre as it will impact success as much as the content layer and the back office functionality. So why does strategy become so critical, you ask?

I will outline a few examples of where customer experience can be impacted by poor integration or application latency.

In a monolithic platform environment where product inventory, store level availability and prices are loaded into the platform from internal back office applications, the speed at which the data can be served up is fast because the data resides within the ecommerce platform. Updating this data in the single platform model is either done through webhooks from the internal system that push data to the API layer when things change, or via API calls to pull the data from the internal systems on a regularly scheduled basis. In most ecommerce implementations, this approach is sufficient and clean enough to satisfy most needs. The only limitation is what data the APIs can handle and the speed at which data can be processed and served up.

Headless Requires Proper Architecting

In a headless world, because data is not warehoused within the visual layer, the data needs to be served up in a timely manner. Take inventory, individual store level availability and product price data for example. This data is not housed in the content layer but housed in either a data warehouse or within back office applications. It could also be warehoused in an ecommerce platform where the check out is being used depending on the approach. Either way, the data is requested from the back end by the front end layer as a customer navigates through the site. By separating the business back end from the content layer, API speed and agility become a critically important factor in customer experience and retention. In fact, APIs on both sides become the most critical element.

Complex loyalty models are another real-world example. A customer may want to redeem loyalty points as part of the purchase or see a real-time point balance within their account. In a headless world, calls to the back end would have to be made to access or update the data as the customer asks for it and as they check out. Once again speed, accuracy and API accessibility is critical.

There are countless other examples of where headless requires a rethink of integration approaches in a customer-centric and multi-channel world. It is not a simple plug-and-play or linear approach that will work in the headless world.

In the third and final part of this blog series, I will outline two integration approaches for headless commerce that will satisfy most back office implementations. Both require proper budgeting and API evaluation. The integration strategy must be at the forefront of the design decisions and cannot be an afterthought as it often is in the monolithic world of SAAS platforms. Along with being at the forefront, a proper budget must be put in place in order to execute in a timely and effective manner.

Subscribe:

Be the first to know when Part 3 of our Headless Commerce article series is published