Software is getting smaller. The era of the monolithic, all-in-one enterprise solution is giving way to a range of focused tools that do a few things exceptionally well.

The content management system (CMS) is no exception to this trend. Any CMS that supports a large enterprise's website probably took many months (and many millions) to implement and it undoubtedly includes functionality to author, template, store, render and present every single page of the website. 

In some cases, this all-in-one CMS may still be the right choice for an organization. However, many enterprises are beginning to realize that a more light-weight, focused solution may provide more flexibility and control. 

The Headless CMS 

This lightweight CMS option is often referred to as "headless" or "decoupled", because it is not used to render a site or application. With the front-end functionality (or "head") removed, the tool is now a specialized backend focused on delivering content via an API. 

Most enterprise websites already take advantage of several APIs. Therefore, one way to look at the headless CMS is that it simply takes the API revolution to its logical next step: if companies are already getting maps and pricing data from an API, why shouldn't their text and images be delivered the same way? 

Application Agnostic 

Enterprises need to manage content assets and publish them. They aren't making just WebPages anymore, they are feeding content to a bevy of applications on a variety of device types. As this becomes the norm, content management becomes a service like anything else. Organizations need APIs that are available to serve content on demand, in a manner that is decoupled from design or functionality. Since the headless CMS decouples itself from design and presentation, it stores and delivers content to all kinds of applications more seamlessly than the current, traditional CMS. 

For example, if a company codes the front-end of their website in Angular, the site can get the content it needs, without any constraints or implications to the design and functionality of the front-end code. Then, when they upgrade part (or all) of their site's design, the new website uses the same content API. In contrast, a traditional CMS is extremely expensive to upgrade, and with each passing year, the amount of legacy content grows, causing each successive upgrade to become more and more expensive.

The headless CMS is also ideal for Android and iOS users, since they are accustomed to using APIs for app development. The advantage here is that both web and mobile applications will draw content from the same API, reducing redundancy across the organization.

Back to the Front

The Headless CMS owes credit for its rise in part to the evolution of the browser. During the past few years, browsers have become more robust. Features that used to require dynamic code running on a server can now be moved directly to the client. The traditional CMS, with its templates and component-level constraints, tends to limit what front-end developers can do, especially when it comes to taking advantage of open source libraries. With a headless CMS, developers can decide on the programming language, design, and features of their project much more freely. 

Initially, this client-side approach will require an organization to rely on a skilled front-end team; while developers are comfortable editing pages in Markdown and submitting them to Github, content authors will find this process unwieldy at best. However, as the site matures, content editors can start to leverage reusable components and a lightweight tool to add content and pages easily. Most static CMS tools (such as Contentful) provide simple WYSIWYG content editing.

The Static Future

As websites move away from the monolithic CMS, they are also embracing the performance & workflow improvements of the statically generated site. The traditional CMS is dynamic. Every client request goes back to the database, requiring highly efficient queries and caching strategies. Though caching can be effective for dynamic sites, statically-generated sites allow for a clean split between static and dynamic content, which makes it easier to take advantage of the performance improvement provided by a CDN. Performance is even more important for mobile devices, where sites are expected to perform well on weaker cellular connections. 

The dynamic CMS is also much more vulnerable to attack. Since Wordpress powers 23 percent of the web, it is unsettling to realize that 70 percent of Wordpress instances are vulnerable to attack. A few months ago, over 12 Mn Drupal sites needed an emergency patch to account for a vulnerability. Though statistics for proprietary enterprise CMSs are hard to come by, there is much anecdotal evidence of vulnerabilities. 

Developer happiness and ease also comes into play with static site generators (such as Jekyll), since they are easier to use and more accessible, making it easier to launch sections of a site without needing to rebuild an entire database. In a test-and-learn environment, this sort of convenience is critical. 

Born in the Cloud 

Many traditional CMSs are now "cloud-ready". However, porting a software product to the cloud doesn't mean that it can take full advantage of the efficiencies that the cloud brings. A solution that is architected for the cloud can best leverage its advantages. 

The headless CMS delivers content via an API, and statically generated sites are immediately ready to take advantage of CDNs like Akamai. Through use of a hosted Content API (like Contentful), an organization's devops team no longer needs to worry about maintenance and upgrade costs. 

End of an Era There was a time when a monolithic CMS was really the only option for the challenge of managing the jungle of pages, departments, approval workflows, and conflicting goals for a large website. 

The headless CMS and static site isn't going to magically solve the complexity, but it can certainly help empower developers, speed internal processes and improve site performance.