The benefits of going headless


Going headless requires intelligence. Project and HR plans that align with headlessness are a start.

One of the biggest web development trends of recent years is headless architecture, an approach that separates a website’s behind-the-scenes logic and data (the body) from the visible elements that users interact with ( the head). The separation of content, back-office logic and user interface functionality promises many advantages over traditional monolithic systems, such as:

  • Faster website speed, which Google rewards with higher search result rankings.
  • Increased agility; decoupling key elements of a website reduces interdependencies and therefore reduces the amount of testing required with each website code update.
  • Enable greater reuse of content across delivery channels such as websites, mobile apps, in-store kiosks, and automotive consoles.

It’s no surprise that companies are pressured to separate their all-in-one solution, but be aware that this transition introduces new complexities that require research and preparation. Like knocking down a Jenga tower, you have to rebuild, but this time you’ll assemble multiple structures.

If this is your first headless implementation, be prepared to recalibrate your previous web development experience and planning tools. Create HR projects and plans that match the unique nature of going headless.

Set new goals

Every project needs goals, and like any project, business results should be your measures of success. This is even more important in a headless project, where the promises are so compelling that project managers may assume that “going headless” is the goal. Clarify the business objectives that a headless solution will support.

Give your technical team the right target to hit. For example, software flexibility and the ability to change one software with little impact on others is a significant headless advantage. Your developers can stick to one goal. However, the goal of your marketing department’s project may be to increase organic search traffic. If left uninformed, developers will neglect tasks that support the goal of the marketing department.

Understand the expectations of the departments funding the project and communicate them clearly to the implementation team. Objectives should be measurable and incorporated into task instructions and acceptance criteria. Do not cast until they have been verified.

Related Article: 34 Free or Premium Headless CMSs That Should Be on Your Radar

Catalog feature

If you demolished the towering skyscraper and are assembling smaller structures in its place, how can you be sure to replicate the same functionality? Write a plan by cataloging pre-existing features. Even if the website is being redesigned, you still need to document its required functionality. List all the features of the site, big and small. Pay attention to the display logic, like if a list of shoes is sorted by price. Don’t forget to grab admin features, like the ability to preview a draft page before it’s published.

Ask your technical team to evaluate each item on the list and note how it will be recreated in a headless architecture. Some will come easily and follow standard procedure, but your team will inevitably find areas that require more research. A typical project plan misses these shortcomings because all-in-one solutions include basic features like preview and publishing. Now they have to be built from scratch.

Related Article: Content Teams: Beware the Headless CMS

Rethink staff roles

Historically, tasks are divided between front-end developers and back-end developers. Front-end developers create the user interfaces and implement the visual designs. Back-end developers program background content types, business logic, and service integration. Scheduling responsibilities has historically been fairly straightforward: assign design-related work to the front-end team and data and logic tasks to back-end developers.

Headless projects redistribute traditional team responsibilities. Headless solutions rely on a new generation of software libraries and visual frameworks that can handle end-user interactions without talking to back-office servers. Now the task of retrieving data that appears on a web page is shared by both roles.

The back-end developer’s efforts go into creating an application programming interface (API) that connects systems, and requests and returns data (via endpoints). The front-end developer connects these endpoints to pages to display content, like a product listing, and can even manipulate the content without having to interact with web servers. Cross-training your existing team will maintain the balance of tasks, but, if possible, hire additional front-end developers.

Build a realistic timeline

Rome wasn’t built in a day, and your first headless website won’t be built in three months. The complexity of a headless project justifies a longer project duration. Not only will your team build an API and re-evaluate existing functionality, but they will need time to perform the necessary testing and iterations to validate that the team has met the full set of success goals.

To estimate the API creation effort, analyze the feature catalog for content display requirements. This will reveal the necessary API endpoints. A shortcut is to assume that every page element needs an API endpoint. Some can be shared, but it’s safer to overestimate in headless projects.

Headless solutions tend to involve more separate software layers, and each layer can have its own data storage functionality, also known as caching. Evaluate your caching strategy carefully and plan extra time to work on the nuances of newly introduced technologies.

Related article: Rethink your content strategy for a headless CMS

Recalibrate your DevOps

Development operations (DevOps) for headless architectures will also be different. Chances are you’ve previously pushed software updates, commonly referred to as “releases”, through a deployment channel, following a single process.

With headless solutions, you will have multiple layers or pieces of software, each with its own deployment process. The extra moving parts greatly increase DevOps complexity, but you’ll be rewarded with more flexibility.

Typically, software releases disrupt the entire system, including the back-office systems where business users work, forcing developers to wait after business hours to push releases. By separating the layers, business users can continue their day-to-day work while changes are deployed to other layers of the system.

Conclusion: reinventing parts of the content wheel

Running a project without a head can sometimes feel like reinventing the wheel – and in fact, you’re reinventing parts of the wheel. I recommend you go into these projects with this expectation. But with proper planning and a healthy reset of team expectations, combined with thoughtful resource and schedule planning, you can expect to be successful too. As with any project, the key to success will lie in the following elements:

  • Articulate and maintain awareness of project goals
  • Document all desired functionality and plan their translation into headless system layers, APIs and data structures
  • Rethink your team structure and human resource planning to align with the skills needed to develop a headless platform
  • Create a timeline that includes buffers for unknowns

Once you have a headless project under your belt, future endeavors and progress will feel much easier. Good luck preparing for your first headless project!


Comments are closed.