One of the biggest web development trends in recent years is headless architecture, an approach that separates the behind-the-scenes logic and data of a website (the body) from the visible elements that users interact with (the head). Separating 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 results ranking.
- Increased agility; decoupling the key pieces of a website reduces inter-dependencies and therefore reduces the amount of testing required with each website code update.
- Enabling more content reuse across delivery channels like websites, mobile apps, in-store kiosks and automobile consoles.
It’s not surprising that companies are enticed to break apart their all-in-one solution, but be aware that this transition introduces new complexities that require research and preparation. Like knocking over 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 project and human resource plans that align with the unique nature of going headless.
Set New Goals
Every project needs goals, and like any project, business outcomes should be your measures of success. This is even more important in a headless project, where the promises are so convincing that project leaders 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 switch out one software with little impact to the others is one significant headless advantage. Your developers may latch onto that as a goal. However, your marketing department’s project goal might be increasing organic search traffic. If left uninformed, the developers will overlook tasks that support the marketing department’s goal.
Understand the expectations of the departments funding the project, and communicate them clearly to the implementation team. The goals should be measurable, and woven into task instructions and acceptance criteria. Don’t launch until they’ve been verified.
Catalog the Functionality
If you’ve torn down the towering skyscraper and are assembling smaller structures in its place, how can you be sure you’ll replicate the same functionality? Draft a blueprint by cataloging pre-existing functionality. Even if the website is being redesigned, you still need to document its required functionality. List all the capabilities the site performs, big and small. Pay attention to display logic, like if a listing of shoes is sorted by price. Don’t forget to capture admin functionality, like the ability to preview a draft page before it is published.
Ask your technical team to evaluate each item in the list and note how it will be recreated in headless architecture. Some will come easily and follow a standard procedure, but your team will inevitably find areas that require more research. A typical project plan misses these gaps because all-in-one solutions include base functionality like previewing and publishing. Now, they need to be built from scratch.
Rethink Staff Roles
Historically, tasks are divided between front end developers and back end developers. Front end developers make the user interfaces and implement the visual designs. Back end developers program the behind-the-scenes content types, business logic and services integration. It is historically pretty straightforward to plan responsibilities: assign design-related work to the front end team, and data and logic tasks to the back end developers.
Headless projects reshuffle the traditional team responsibilities. Headless solutions rely on a new generation of software libraries and visual frameworks that can process end user interactions without talking to the back office servers. Now, the task of fetching data that displays 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 (through endpoints). The front end developer plugs these endpoints into pages to display content — like a list of products, and can even manipulate the content without needing to interact with the 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 warrants a longer project duration. Not only is your team building an API and re-evaluating existing functionality, they’ll need time to perform the necessary testing and iterations to validate that the team has achieved the full set of success goals.
To estimate the effort to build the API, scan the functionality catalog for requirements related to displaying content. 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 is safer to overestimate in headless projects.
Headless solutions tend to involve more distinct layers of software, and each layer may have its own data storage functionality, also known as a cache. Carefully evaluate your caching strategy and budget extra time to work through the nuances of newly introduced technologies.
Recalibrate Your DevOps
Development operations (DevOps) for headless architectures are also going to be different. It’s likely that you previously pushed software updates, typically called “releases,” through one deployment channel, following a single process.
With headless solutions, you will have multiple layers or chunks of software, each with its own deployment process. The additional moving parts significantly increase DevOps complexity, but you’ll be rewarded with more flexibility.
Generally, software releases disrupt the entire system, including the back office systems that business users work in, forcing developers to wait until after-hours to push releases. By separating the layers, business users can continue with their daily work while changes are deployed to other layers of the system.
Conclusion: Reinventing Certain Parts of Content Wheel
Running a headless project can at times feel like you are reinventing the wheel — and indeed you are reinventing certain parts of the wheel. It is my recommendation that you enter these projects with that expectation. But with adequate planning and a healthy reset of team expectations, combined with thoughtful resource and timeline planning, you can also expect to find success. Like with any project, the key to success will lie in the following:
- Articulating and maintaining awareness of the project goals
- Documenting all desired functionality and planning how it be translated to the headless system layers, APIs and data structures
- Rethinking your team structure and human resource planning to align with the skills needed for headless platform development
- Creating a timeline that includes buffers for the unknowns
Once you have one headless project under your belt, future efforts and advances will feel much easier. Good luck preparing for your first headless project!
