Is The Future of Commerce Headless?
When talking to people about commercetools being a headless commerce platform, not everybody sees the immediate benefit. Quite the contrary: does this also mean that a headless solution has, in the literal sense, no brains? And can such a system be the proper basis for a future-oriented commerce strategy? It very well can, and this blog post talks about why.
The First Frontends
The first webshop system that I worked with was OsCommerce. Launched in 2001, it was, technically speaking, a PHP spaghetti-code application, but along with its derivatives like Gambio, xt: Commerce and a few others, it’s still prevalent to date. There is a large developer community, an incredible number of plugins and integrations and the software can be very quickly – and very dirty I might add – adapted to the particular circumstances. What sounds like a recipe for disaster for software engineers seems to work for business developers: German retailer of bathroom products Reuter manages to generate a turnover of 121 million Euros (2016) with its modified OsCommerce version. According to the EHI, this means the vendor is one of the top 50 successful webshops in Germany.
At the time, the OsCommerce frontend already had much of what would become e-commerce standard in the following years: category and product detail pages, shopping cart with discount and coupon functionality, checkout with various payment and shipping options. Also a search function, a my-account section, and even a rudimentary CMS, in which retailers could maintain their text modules for the imprint and the data protection regulations.
At that time the standard frontend presented itself in a three-column, baby-blue layout. But that was fashionable back then – Amazon did not look much more welcoming at the turn of the millennium:
Technically, the frontend was tightly wired to the backend; there was no separation between the two, everything interacted with everything. A monolithic PHP4 solution in which layout, business logic, and data persistence all took place in the same files. Put differently: creating a snippet of HTML for a table on the product detail page was only a few lines of code away from accessing the shop database.
Magento changed this situation. Launched in spring of 2008, the software was developed by the US agency Varien, which had previously worked mainly with OsCommerce. Quite noticeably, the Magento software architects have solved things much more professionally and fixed what OsCommerce was suffering from: separation and abstraction of application layers, object-oriented programming, and the notorious EAV data model. It almost seems as if the old OsCommerce ghosts should be driven away by this architecture, which has often been criticized to be over-engineered.
Interesting in this context is the frontend topic because here, at least layout-wise, Magento did not move far away from the standard. Again, we find the usual ways to discover products as well as a configurable checkout logic. What’s new is above all a working facet navigation and gadgets like product comparisons, which are made possible by the new attribute system.
Technically speaking, the frontend is much cleaner: individual content blocks are arranged using XML, structured using (P)HTML, and styled using CSS. This makes individualization much more complicated than, for example, with OsCommerce. Experience has shown that in many projects those involved limit themselves to giving the frontend only a slightly new look instead of reinventing the UI wheel. Unintentional or not, a more modern architecture cements the frontend status quo.
Beautiful New Mobile Shopping World
Ten years have passed since the launch of Magento. The world has shot a Tesla to Mars and unlocks her cell phones with her face. The mobile age has begun, meanwhile more people use the Internet via a mobile device than via a stationary computer. In fact, we witnessed Peak-PC in autumn 2016:
Vendors of commerce software responded with new, mobile-capable templates, responsive web design quickly emerged as best practice. The idea behind it: if you code a frontend in a way that it adapts to the context of the respective device, it becomes more usable, and visitors can order more efficiently. That’s true, but was often not thought through thoroughly. Although controls have been made larger and more finger-friendly, most web shops are still the complex product catalogs and endless forms of almost 20 years ago – even though they are viewed on a brand new iPhone X.
Speaking of iPhone X: Another mistake in this context is the idea that smartphones are just smaller, more portable browsers. That the flow “customer searches for a product using her favorite search engine” – “finds vendor XY, who has invested well in SEO and SEM” – “visits the commerce website” – “finishes the transaction by going through the checkout” can also be adapted to mobile devices. In fact, mobile users are using apps, spending time on Facebook, Instagram, and Youtube, or in messengers like WhatsApp and iMessage.
In other words, the primary entry point is less and less likely to be the mobile browser and the “free” Internet behind it, but a handful of apps that allow potential customers to get in touch with their favorite brands, get inspired by their influencers and be persuaded by their friends. And if you add utterly new device classes such as voice devices or order buttons or look at what chatbots and AR applications can already do today, vendors are facing a world that cannot be tackled by using the same old mechanisms of user interaction.
So what do you do as a commerce platform vendor in this complicated and rapidly changing world? The answer: Build a headless system like commercetools! This is the approach of providing backend functions that can be used by all imaginable data producers and data consumers via a generic API. The head is missing in this picture, only the body along with its vital signs remains.
What might look a bit Frankensteinian from a medical-anatomical point of view certainly has relevance for the commerce world. Whether it’s a mobile app, a messenger, an order button or a voice command that triggers an order and sends data via the API to the body is totally irrelevant. This ignorance also works in the other direction: the body sends price information which is either read out by Alexa, which appears on Instagram, or which has a red diode light up in a self-built IoT display machine.
Brain vs. default
Of course, a headless system has a lot of (artificial) intelligence built in, for example, to model complex product catalogs as well as price and discount structures, to integrate third-party systems from all possible areas and to scale efficiently and reliably even with high traffic. Ultimately, however, such a system is a commodity: it just has to work.
The real “brain” lies elsewhere, namely exactly where customer interaction takes place and where added value is created. This brain can not be standardized by frontend technology, but has to be built and tested (with a lot of brain power). This can be an Alexa-Skill, an Instagram connection or a native app with that certain something, through which one convinces and binds itself to customers.
Here’s to headlessness!