The top 4 use cases for going headless

With 64% of enterprises currently using a headless approach and 90% planning to evaluate, the rising popularity of headless architecture is undeniable. Yes, the headless hype is real and comes with clear benefits for the engineering team. However, as with any tech investment, it's crucial to take a step back and truly understand the issues your organization is trying to address and why going headless aligns with those use cases. 

So, what are you trying to achieve? If any of the following business requirements resonate with you, a headless content management system could be the ideal solution. 

Business requirement #1: Future readiness, avoiding vendor lock-in 
"We want to be future-ready, adapting to changing requirements with ease." 

For organizations seeking adaptability and the ability to replace components effortlessly, a headless CMS could be a good choice. Embracing a headless architecture forces teams to decouple the CMS from the frontend (or presentation layer) as well as the backend logic, in the form of microservices hosted outside the CMS. This empowers you with tremendous front-end and backend freedom. You can leverage various front-end frameworks like Vue, React, or Angular, or backend programming languages like .NET or Java, hosted as microservices on your preferred cloud platform. The flexible nature of a headless architecture ensures that you maintain loose-coupling between the key components so that if you ever have to replace your headless CMS, for example, your frontend and backend can stay, saving you the headache of deconstructing a monolith, if that’s even possible. 

Ask yourself: What are components of my stack that will likely change that I can decouple from the rest of the stack? 

Business requirement #2: Single content hub for multiple channels 
"We need a centralized content management solution for our various digital properties." 

If your business has multiple websites or channels like mobile apps, kiosks, or digital menus, consolidating into a single content hub allows you to manage all your content in one place. The National Rugby League, for example, uses Optimizely to manage content for 19 websites, a mobile app, digital displays, and four other digital properties. Similarly, Electrolux has been using Optimizely's CMS for over a decade to manage content for multiple brands. If your business requirement is really about having a single content repository, a headless CMS can provide you with that centralized solution for streamlined content management. This doesn’t mean an all-in-one CMS can’t support you to manage content for multiple channels. However, marketers who use a headless CMS are forced to think of content in a structured way, preparing for content reuse and delivery to multiple digital channels. 

Business requirement #3: Decoupled frontend and backend 
"We want to leverage React as our frontend framework." 

Decoupling the frontend and backend isn’t necessarily a business requirement itself, but rather an engineering solution driven either by architectural preferences or by the structure of your internal development teams. With separate front-end and back-end developer teams, each can “stay in their own lanes” and focus on their respective areas of expertise. This removes unnecessary dependencies, improves employee morale, and enables the business to go to market faster. Choosing a headless solution enables you to support many different architectural patterns. However, too much flexibility can become a liability so engineering teams who adopt a headless architecture need to be more disciplined in structuring and maintaining their code, so as not to build a monolith out of the glue code that is required to tie headless solutions together. 

Business requirement #4: Applications with high-interactivity 
"We have an eCommerce website" or “Our customers primarily transact with our mobile app” 

If the channels you want to manage content for accept lots of transactions from your customers, such as eCommerce or a mobile app, there’s a good chance there are lots of two-way interactivity happening. Choosing a headless solution for applications with high-interactivity requirements would make for an excellent choice, given there is going to be significantly more engineering work required in both the frontend and backend. Extracting both components from the headless CMS, as discussed in earlier points, makes for efficient software development. However, if your digital properties are composed of marketing websites or mobile apps that only display information, then choosing a headless CMS may be overkill. Choosing a headless solution over an all-in-one CMS for a simple use case forces teams to unnecessarily decouple the components. Not only do you have to maintain the frontend and backend logic, you also have to provide hosting for both, and additional elements like search functionality, preview capabilities, personalization, lead generation forms, CDNs, static site generation, and more. As a business, you'll have to manage multiple vendors, contracts, and varying SLAs, and integrate these solutions into your head. 

Ask yourself: Does my use case justify the added responsibility of working with many vendors, signing and negotiating multiple contracts, work with varying SLAs, and maintaining in-house glue code? 

Don’t forget your marketing team. 

Developers often push for headless because of the tremendous flexibility they get. On the other hand, marketers, content creators, and content editors need a CMS that easily works with their content creation process and may find that while a headless CMS will help them structure content without a presentation layer, the page/experience composition will now either be driven by engineering through code or through another software. Headless CMSs, as its name suggests, generally does not come with experience/page-builder capabilities. If they did, they aren’t pure headless. So, if you are choosing a headless CMS, ensure your marketers are also catered for by providing them a solution that allows for experience/page composition so marketers can move fast, too.

Can Optimizely be deployed as a headless CMS? 

Absolutely - Optimizely CMS has always decoupled the content from the presentation layer. Content lives in Optimizely’s database, and the presentation layer lives in code, whether hosted in or outside of Optimizely. This enables organizations, such as Dolby, National Rugby League, and Moco Food Services, to reuse content across multiple sites and various other digital properties, such mobile apps and digital displays. 

With the launch of Content Graph, we’ve strengthened our headless offering, providing engineers more options to deliver content, either by .NET SDKs, RESTful APIs or GraphQL. 

What makes Optimizely unique, is that it also has an optional page builder capability, ensuring marketers can still have comprehensive control over experience/page composition for websites. Instead of leaving this responsibility to engineers, or procuring another software to fill this gap that other pure headless players leave you with, Optimizely can help you solve this by enabling on-page editing features, if preferred. 

Conclusion 

1. Choosing a headless CMS provides tremendous freedom to your engineers. This enables you to go to market faster. However, too much flexibility can become a liability, so ensure an enterprise architecture and rigorous engineering practice is in place to avoid ending up in a monolith of custom code.
2. Headless CMS, as per its name, solves for content management, but not for presentation layer management. When choosing a headless CMS, ensure you also have an experience/page builder solution in place for marketers, so they have a high degree of self-sufficiency removing dependence on engineers for their day-to-day work.  
3. Choosing a headless CMS sets the business up for a composable digital ecosystem, which creates agility for the business. However, an ecosystem of multiple software vendors results in multiple contracts, varying SLAs, and possibly glue code to integrate all of them. Take a step back and reflect on whether your business use cases justify the added responsibility of managing multiple vendors, varying SLAs and maintaining in-house glue code.