OK, but what is headless CMS and ecommerce?
Headless is a systems architecture design that utilizes RESTful API’s to execute application tasks within customer-facing touchpoints separate from its native presentation layer.
Huh?
In the context of digital experiences, headless basically means you can use your web CMS or ecommerce platform to power various customer-facing experiences such as native mobile apps, smart devices or existing web applications not built directly within the platform itself.
What are the best use cases for headless?
Let’s look at the three best use cases for headless in today’s modern digital environment.
1. Improving the digital experience on existing web applications and mobile apps
Many organizations operate dozens of legacy web applications or mobile apps that power various phases in the customer journey. One example can be found in financial services. Most banks have built custom web applications for personal banking which customers access via mobile apps or desktop browsers.
Rather than spend hundreds of thousands or millions of dollars to swap out these legacy systems with commercial CMS or ecommerce applications, organizations are choosing to implement a headless CMS which can display banners, articles and promotional offers to users within their personal banking experience – a crucial requirement for many financial institutions looking to create account stickiness with cross-sell and up-sell offers.
2. Reaching customers on emerging touchpoints
Smart home devices are on the rise, with over 83 million households owning at least one smart device in 2019. These smart devices often use on-board services like Google Home or Alexa to deliver experiences to consumers. As these platforms expand in adoption and maturity, organizations need a CMS or ecommerce platform that can deliver content to, or processing orders from these channels. A headless CMS or ecommerce application can do both. A headless platform will be able to integrate to the underlying framework used by smart devices (e.g., Google Home, Alexa) to deliver experiences. This can be as simple as allowing users to place orders with your organization using voice from the device or as sophisticated as powering an Alexa Skill directly onboard an Amazon Echo.
3. Ground-up builds for digitally native startups
Digital is transforming every industry, virtually. From Uber and Acorn, to 23andMe and Casper, digitally fueled startups are challenging the status quo while capturing market-share. As you may have guessed, they’re using headless to do it. Technology executives have seen first-hand how monolithic applications lead to experience siloes that are expensive to manage and discourage customer engagement. This is why digitally native start-ups are building consumer apps using dozens or even hundreds of headless microservice applications that plug into a single company-built presentation tier.
This cross-functional front-end code creates continuity in the user experience and theoretically makes organizations faster in delivering on their mission while also making organizations more responsive to changing customer expectations. This is a smart strategy for a well-funded start-up with high ambitions and rockstar engineering talent. However, most organizations buying digital experience and ecommerce technologies today are not in this position, making the case for a cross-functional presentation layer moot. Over time, the presentation tier will become a hinderance to innovation as the front-end code becomes bloated and developer resources are stretched thin across a growing business. Technology professionals should scrutinize pure-headless architectures lest they recreate the monolithic nightmare in their front-end code.
Is headless right for me?
What’s most important for marketers and technology professionals with regards to headless is to answer the question, “Will it help my organization close the gaps in our customer experience faster, cheaper or better than existing alternatives?” The answer? It depends. Headless carries several large implications along with its benefits. Here are two:
IT dependency
Any touchpoint you power with headless becomes tech debt. Just like everyone needs a head on their shoulder to function, every touchpoint enabled by headless needs a head to operate. In the case of digital experiences, your IT organization or systems integrator must build a custom presentation layer and integrate to the headless platform using API’s. In cases where there is no display (smart devices) or legacy applications (personal banking apps), this cost may already be absorbed by your organization. However, if you’re considering adopting a headless platform for your primary .com experience, you will need front-end developers to “build your head” and you’ll need to keep paying them long after your site launches to make changes. This puts engineers on the critical path for customer experience who may already be stretched thin with other initiatives. This can actually make headless implementations more expensive and take longer than a traditional approach.
Loss of functionality for marketing users
Since headless removes the presentation layer shipped with the application, most headless platforms do not support leading native business user tools like in-context editing or content preview before publishing. When marketers or merchandisers are editing their site experience, they often use the same presentation layer as end-consumers to edit, preview and publish changes to the live website. Without these functions, marketing users are flying blind with one hand-tied behind their back. Engineers can “build a better UI” for your marketing organization, but this is putting good money after bad.
Is there a good alternative to headless?
Unless you’re a Venture Capitalist-backed software-as-a-service startup or your digital success depends on your ability to push content to existing apps (and not revamp your own .com experiences), you will probably overpay for headless in the long run. This is because most digital transformation initiatives include both a re-design of your primary web experience on your .com website and deliver improved experiences within new touchpoints and legacy web applications. If this is the case, a hybrid-headless architecture works perfectly. Hybrid-headless platforms such as Episerver have RESTful API’s to deliver experiences on emerging touchpoints such as smart devices and can push content into legacy web applications or mobile apps. Since hybrid-headless platforms ship with a standard presentation layer, they do not create developer dependency or sacrifice business user functionality when a company is building its website or launching a native mobile app.
If you want to nerd out on the differences between pure- and hybrid-headless architectures grab your copy of our Decoupled & Headless Content Management Whitepaper.
What role does a RESTful API play in headless?
The make-or-break moment for pure-headless or hybrid-headless vendors is their RESTful APIs. As stated earlier, headless is powered by API’s. Without strong API’s, you cannot push content into another presentation layer nor can you receive commands from the users into the headless application. API’s are the key aspect of headless architectures.
What types of APIs should I look for?
In the land of RESTful API’s, you want a CRUDy API. C.R.U.D. stands for Create, Read, Update and Delete. If the API cannot execute these four actions in the use cases you are attempting to deliver, whether it is a pure-headless vendor or a hybrid-headless vendor, you’re going to come up short.
Another aspect of headless in delivering content to emerging touchpoints, legacy web applications or mobile apps is the flexibility of the data model to retrieve various content types. When evaluating a headless vendor, it’s critical to understand how they support html, images, JavaScript and other content types to ensure you can bring the right content to the right user in the right environment.
A final, and often overlooked aspect of RESTful API’s, is personalization. API’s that look-up customer records need to be able to identify which user the request is coming from and determine which content the user should receive based on their unique profile. This is a potent combination of headless and artificial intelligence to deliver relevant experiences to users. Episerver’s Content Recommendations service can be leveraged in both Episerver powered web experiences and headless use cases for this very reason. Episerver also publishes our headless API documentation for both Content and Commerce use cases on our community website.
Any final words of advice?
In short, don’t lose your head when it comes to headless. A lot of CIOs are running around like a bunch of chickens right now trying to implement headless architectures. And, in many use cases, headless architectures are helping close the customer-centricity gap in digital experience (i.e., what customers expect versus what organizations are delivering). It’s important not to lose your head entirely over headless. If your organization needs to deliver exceptional experiences quickly on your web channel, implementing a custom presentation layer may make heads roll once you’re a few years in.
