Headless CMS in the Enterprise

Enterprise Headless CMS Ibexa DXP

Headless Content Management is a trend that has been around for over half a decade now. Already a staple for boutique implementations for smaller companies and campaign sites, it continues to gain traction in enterprise projects too.

But before diving head-first into a headless CMS project you should consider how it fits your organization’s needs. Like a lot of IT jargon, the term ‘Headless CMS’ is not clear-cut. Before we begin, it is good to have a quick overview of some of the concepts used in this article:

• Content API: A tool used by editors to manage content which provides a raw content feed to be consumed by other development tools – not to users directly
• Display layer: A system (or systems) that render the feed provided by a Content API to be displayed to users. A website or a mobile app for example. In this eBook we shall focus on the web.

For both these components, there are a number of options on the market. To learn more about different Content API options, be sure to check out our Introduction to Content as a Service.

Together the combination of a content API and display layer result in a Headless CMS implementation. This differs from a typical, traditional CMS where the content API and display have been more coupled together forming a single system. Both approaches have their advantages and challenges.

From Killer Apps to Killer APIs

Today the Content Management industry is mature, meaning there exists a lot of accumulated experience and best practices. This in turn makes CMS implementation projects relatively humdrum routine work in the world of IT.

The challenges are in the business logic, whereas the technology itself might not seem very exciting to technologists. Riding the API economy hype wave, headless Content Management tools challenge the status quo – providing an alternative approach to delivering content.

The recent excitement around APIs is mostly around distributed ones using web technologies. The headless CMS is a manifestation of this trend for Content Management.

With the arrival of the web and smartphones, the desktop operating system lost its dominant position. The company had to adopt and let go of its reliance on Windows to stay relevant and be a part of the new world introducing cloud services and subscription-based pricing for its Office productivity suite.

But things are rarely black and white. While desktop computing is certainly not a growth industry, there are areas where it continues to be the best option - from fields requiring real realtime precision like making music to mundane tasks like writing blog posts and doing random productivity work. Personal Computer ownership has reached a tipping point and is in decline however the vast majority of office workers continue to wield a desktop or laptop computer every single day.

This story is an analogy to the Content Management space as well. It is easy for entrenched CMS vendors to point out the missing capabilities in pure headless systems, whereas CaaS providers’ marketing teams labor to produce content underlining the deficiencies of “legacy CMS” products. In reality there is room for both approaches. It’s a diverse field with different requirements and use cases.

User Needs and Product

A Headless CMS is primarily used for managing content

Today the term CMS (Content Management System) is used to describe a system whose function reaches well beyond creating, modifying and editing content.

These systems have outgrown their initial scope, and many are now on their way to transitioning from a CMS to a DXP (Digital Experience Platform). This topic was covered in-depth in a blog post titled From CMS to DXP to Deliver Digital Success by Roland Benedetti, CPO of Ibexa.

A headless CMS is truer to its definition. It is a system primarily used for MANAGING CONTENT. Period. This makes it more approachable to users, but also less capable than a traditional enterprise CMS. This ambivalence of what a CMS does can create some surprises during the implementation process. You might take for granted some features which are (and have always been) beyond the scope of a Content Management System.

When replacing an existing traditional CMS or DXP with a headless CMS configuration, an important task is to identify the tasks that your content editors, marketing staff and other users perform daily.

Map out any feature gaps between the two in key functionalities. In addition to content management needs, things like rich content models and workflows, be sure to map features for peripheral site management tasks such as:

• Managing navigation, redirects and other similar tasks
• Adding tracking scripts for marketing,
• usability tracking, etc.
• User management with your corporate user backend
• Scheduling promotions for weekends
• Modifying landing page structures
• Previewing content and a collection of content items.

All of the above can be achieved with either an integrated system or a combination of a content API and a display layer. The difference is that for the latter you might need to add third-party tools and additional integrations.

Don’t take product features for granted when you’re moving from an integrated software suite to a microservices architecture built from highly specialized individual components.

Implementation Complexity and Robustness

A combination of the right skills and technology are required

Because of their maturity, traditional CMS implementations of large projects are easier (not easy!) to estimate than a headless implementation project of similar scope. This is not due to the technology being better or worse, but because there are more established ways of working, expectations for what a system does and who does what. One can rely on past experience rather than guesswork for realistic estimations.

Today this is not often the case for complex headless implementations. The client is often doing this type of implementation for the very first time and the integration partner may not have sufficient experience. This can lead up to some hiccups and unexpected costs during and after the project, even if you’ve done your due diligence on features as described in the second section in this article. Well managed, these are not an issue.

One key characteristic of a CMS project is that it is most likely a multivendor project using multiple technologies. While some CMS vendors do implementation projects themselves, it is quite rare for a CaaS (Content as a Service) provider to provide implementation services.

It is simply not something that is compatible with the business model of an API provider. Like with any technology project you should examine an implementation partner’s experience and references using the content API of your choice. You don’t want to be their first try at it.

Integration architecture is another point to consider. Content Management Systems have traditionally been server-side systems, and it is natural that connections to external systems have been built on the server.

An emerging trend is moving integrations to the client – the browser. This trend is not directly related to whether you are using a headless CMS or not, but the two often coincide in the same projects because both are novel technologies.

JAMStack is one moniker given to the technical architectural approach where the browser becomes the integration platform.

The term comes from JavaScript, APIs and Markup (JAM). The core idea is to shop around for best-of-breed API providers for authentication, e-commerce, payments and so forth and integrate them in the browser, freeing you from running server-side systems.

At best a JAMStack implementation allows you flexibility to choose the best technology at low cost, at worst it’s a fragile mess of services that can be time-consuming to figure out when there is trouble. In reality, the average experience is likely somewhere in between.

Project and Long-Term Maintenance Costs

Pay attention to the total cost of ownership and budget for growth

The cost of a headless CMS implementation boils down to the cost of the Content API and the API Consumer(s). The total cost is accrued during the initial development phase and over the years of development and maintenance.

The Content API is easier to figure out, since you’ll need to consider the available options on the market and choose the one that gives you the capacity and required features at the most competitive price. A game of numbers, pluses and minuses.

When choosing a content API be sure to take into account at least the following points:

• Required capacity (number of content items, repositories, editors…)
• Available features vs. custom development
• Hosting cost (for CMS vendors)
• Subscription cost (for CaaS)

Here you need to find the solution with the best balance for your individual needs.

A CaaS provider’s pricing might be very attractive at low volume but may skyrocket at the scale your organization needs. An open source systems’ lack of licensing fees can be offset by higher cost for hosting. Be sure to calculate future expenses if your desire is growth.

A PaaS like eZ Platform Cloud on the other hand could provide a cost benefit over IaaS providers by reducing the personnel cost of running your own internal DevOps team.

With a content API provider chosen, it’s time to consider the display layer. This is an area where there is literally an unlimited of options available.

From completely tailored boutique builds to product-based implementations based on frameworks like Next.js or Nuxt.js to static site generators like Gatsby.js or Hugo. Virtually all of these tools are open source, so the cost is based on labor. Again, look for experience when selecting an implementation partner, as it yields higher quality and higher development velocity.

For long-term cost, things can become tricky. The content API costs are subject to change – generally prices are usually quite stable - but technically a CaaS provider could hike prices literally overnight based on the subscription terms that you’ve agreed on.

However, this is quite unlikely because there are plenty of alternatives and moving between providers is relatively trivial. You will need some reworking of your implementation, but a wellarchitected content display layer, “the head”, can accommodate this without introducing prohibitive cost.

Continuously Architect for Change

Reap the benefits of a microservices environment

In a headless CMS solution, the display layer (API Consumer) becomes a strategic choice. When deploying a traditional CMS, the templates and front-end implementation are often disposable.

In enterprise implementations where a Web Content Management System (WCMS) can be live for five to 10 years after the initial implementation project, the design undergoes multiple clean slate refreshes. In the backoffice features keep adding up.

In an integrated end-to-end content management solution, the content API and display layer are by nature tightly coupled together - they’re a part of the package.

One of the key value proposals of the headless architecture is that the two are independent. But there is a natural tendency for feature investments to accumulate to the display layer, making the original goal of being independent to swap out either of the components a moot point.

If you couple your implementation tightly to a given design layer, you can end up with rising cost. Over time as your display layer accumulates technical debt, which in turn requires increased development efforts.

Your capability to evolve is hindered and a heavy rewrite might be in the cards. It is easy to live in an illusion of having a decoupled system simply because of the high-level architecture you chose initially. Staying agile requires effort.

Software is by nature bound to be obsolete sooner or later but you can architect a system so that parts are replaceable.

The key to maintaining the flexibility of a headless implementation is to consciously develop functionalities to be disposable.

Split complex capabilities into reusable services that are not tied to any given display layer. This will allow you to reap the benefits of the decoupled approach even over years of development.

Conclusion

Today there are more options than ever for a technical implementation of an enterprise IT solution. The headless approach can be a breath of fresh air to someone working with a cumbersome system whose technical service life is way beyond its best-before date, but it is not necessarily always the best match.

The abundance of options can make it more difficult to choose the right option, and it can be easy to choose something that is not the ideal match.

For example, if you do pure multichannel content publishing, you have no need for site management then headless CMS implementation is a perfect fit. Don’t pay for features you don’t need.

At the same time keep in mind that having a new option available does not render existing tools obsolete. While features do become genuinely obsolete, there are functionalities that are essential — a sort of necessary evil — to have in a content management project implementation.

For these needs you can use features from integrated offerings like DXPs or go with a pure headless CMS and integrating third party tools to fill in the gaps. In large projects adding more systems, partners and systems add up and can start consuming the original perceived benefits.

Instead of being able to introduce changes rapidly and at lower cost, you could spend that same time and resources on coordinating multiple system vendors and paying fees to fragmented service providers. This is especially true when you consider the total cost of ownership of a solution over its lifetime.

Remember that no technology guarantees success. The team and their collaboration make or break your project implementation. This is true for small and large efforts, but the odds of success tend to fall the more people and technologies you introduce. A very successful approach for a team of five can yield opposite results when your team size is thirty.

For more insights about multichannel publishing download our free eBook titled Digital Publishing’s Evolution: From Website to Multi-channel.

If you’d like to know more about Headless CMS solutions, or if you’re currently in the midst of an evaluation project, why not request a demo with our Digital Experience experts or to discuss your requirements for successful digital transformation in your organization?

Photo by Jenny Ueberberg on Unsplash