Headless Architecture

The Good, the Bad, and the Ugly of System Architecture

Published March 19, 2021


Headless architecture has been around for some time but has picked up popularity recently, particularly in e-commerce, as the number of sales channels customers expect continues to grow. Any technology leader needs to learn the differences in architecture and understand the benefits and drawbacks of each. At the 20,000 foot view, there are three different architecture types.

The ugly - adding channels on a case-by-case basis utilizing whatever technology the implementing team finds most straightforward leads to disparate sales channels but gets the job done.

The bad - each sales channel implements business logic and uses a web service to connect to SAP ERP.

The good - a headless API with well-defined specifications separates the business logic and offers an integrated experience for all sales channels.

Not the web of the 90's anymore

With the advent of the internet came online shopping. For a long time, this was almost exclusively on an e-commerce website. Then the rise of native apps began, and some companies started adding this sales channel. Fast forward to today, customers now shop using smart speakers, social media apps, in-store kiosks, e-commerce platforms, text messages, and much more! The piecemeal approach that used to work is no longer adequate for the rapidly changing e-commerce space. E-commerce-focused enterprises require a future-proof long-term plan that can quickly adapt to the ever-evolving area.

The Ugly - Independently developed channels

IT departments have constraints, whether it's budgeting, technology expertise, timelines, or something else. The easy route is to approach each project individually and get it done using the least resistance path, which might provide short-term savings but has high long-term costs. There are numerous issues with this approach, the main ones being, adding new sales channels is still a very high level of effort task, and changing business logic requires changes on all integration layers. The former slows the pace of innovation, increases the total cost of ownership (TCO), and creates technical debt. The latter can lead to business logic errors, require a significant effort from the development team, and potential system downtime.

The Bad - Multichannel

A slightly better solution is a multichannel approach that uses a web service across channels, but each solution implements its business logic. This approach allows customers to purchase from various channels but requires duplicating development efforts for each channel. While it's an improvement over the Ugly architecture, it shares nearly all of the drawbacks and only slightly simplifies integrations. This approach might be acceptable to companies that only plan one or two sales channels and do not need a seamless user experience.

The Good - Omnichannel and headless

"The Good" solution is the best as it eliminates nearly all of the downsides from other approaches. However, it's not perfect; the initial implementation of this type of architecture requires more planning and can potentially take longer. It's an investment for the future if you know you want a seamless experience across sales channels. Headless architecture dramatically reduces the time to implement and deploy additional channels and allows customers to have a single source, regardless of their connection point. Imagine ordering via text and checking order status via Alexa.

Want to code like the top 1% of elite SAP developers?

Elevate your skills with exclusive insights, expert tips, and cutting-edge best practices. Don't miss out – become part of the elite SAP community today!

Related Posts


How Finance Leaders Can Use APIs to Assist With E-Commerce Operations

By reducing the time spent managing software integrations, APIs help finance leaders reduce costs and complexity when building out their e-commerce solutions.


What's the Most Effective Way to Get Your E-commerce Platform Production-Ready?

Automated testing is vital for ensuring your e-commerce platform is production-ready and that customers don’t have to deal with unforeseen issues themselves.


Our Journey with SAP ERP DevOps

The 2006 release of SAP ERP 6.0 predates Docker's initial release by seven years! The two technologies are geared towards different scenarios: think monolithic on-premise server vs. cloud-native microservices. What could be gained by combining the two? Software development teams outside of the SAP ecosystem are years ahead in leveraging DevOps ideas, automated testing/continuous integration, and modern version control tools (i.e., GitHub) to realize tremendous productivity and quality gains. Containerizing ERP would be a considerable step towards accessing these advantages for ABAP development.