Picture this: a registered voter who doesn’t pay much attention to the news and doesn’t understand the candidates’ platforms walks into the voting booth and votes for the first name they recognize from a TV ad or lawn sign. Sadly, this describes how some decisions happen in the digital world: we go after the latest buzzword or flashy name. Unfortunately this describes what's happening in many organizations deciding whether to adopt headless architecture.
I previously named poor leadership decisions as one of the top five reasons why digital transformation efforts fail. Leaders must appreciate that success is a direct consequence of every decision we make, including which candidate to vote for and which product to buy. When our decisions are rooted in knowledge and understanding, the probability of success increases substantially.
Comparing Headless Architecture vs. Monolith Architecture vs. Microservices Architecture
More and more of my customers are grappling with this decision: “To Headless, or not to Headless.”
Headless architecture refers to an application where the back-end logic and data storage are only connected with a presentation layer via a set of APIs, rather than being built as an end-to-end platform. This decoupling allows for seamless management of both the front end and the back end without disrupting each other, by simply adhering to the APIs that connect the two.
The headless approach has a lot of upside and very little downside. It even prompted end-to-end platforms to make their applications available (if needed) as headless through a set of APIs.
Another popular architecture that extends headless architecture by creating more decoupling and decreasing dependency is microservices architecture. Microservices design further breaks down the back end logic into a collection of decoupled services wrapped in a set of APIs — the microservices. The advantages of seamless management are taken to another level here by reducing the dependency of the overall architecture on each and every service it consumes.
It might seem simple to look at the benefits of headless architecture and declare it the best way to go. But most products and design patterns work best within a specific set of circumstances. This isn’t about what you can and can’t do, it is about what you should and shouldn’t do with headless or not based on your use case.
A headless approach makes the most sense in quite a few use cases. Similarly, a monolith approach makes more sense in a number of use cases when considering what is being achieved. To declare one product, solution or approach as the winner regardless of the use case is lazy and a good indicator of biased opinion. So how does one decide on headless, or not?
Related Article: Is a Headless CMS Right for You?
What’s Your Current Software Landscape?
Assessing your organization’s current landscape and investments is a good place to start when evaluating headless. Some organizations are built entirely around one or two large software platforms, with multiple products and solutions enacted from the same product ecosystem. These platforms buy and build multiple products and capabilities in the hopes they can cross-sell them to their customers over time. The strategy works because these products and solutions tend to have native connections and integrations that make it more efficient and powerful to use them together.
Analogously, some organizations have already invested in a decoupled, headless and/or microservices architecture that makes it easier to embrace new, decoupled and best-in-breed products into their existing ecosystem.
With the existing landscape in mind, one must not confuse current with optimal. While following the current path of your organization's footprint might be easier, it does not mean it is the ideal way forward. Change is not only good, but also often necessary.
Where Do You Want the Complexity?
The concept of complexity in digital transformation is much like energy in physics: you can move it around, but it remains constant. For a technical architecture that supports a specific and consistent business use case, the complexity is constant. An organization may choose to have that complexity within the products they procure (platform approach). Since platform products are usually natively connected, this decreases the integration complexity in the same infrastructure. The opposite is true for headless architecture. The product complexity is greatly reduced by focusing on pointed solutions rather than large platforms, but the complexity within the integration layer is increased at a similar rate. The increased complexity within the integration layer is necessary because now it is the organization’s job to stitch the headless tools together.
How Big Is Your Organization?
Because of the shift in complexity, headless architecture makes more sense in an organization with a large technical support arm to help build and maintain both the application and the integration layers. Larger organizations usually have very complex and diverse infrastructure and cannot hitch their wagons to one platform end-to-end. Smaller organizations with a limited number of dedicated technical resources usually have a hard time following through on a complete headless infrastructure and fare better with an end-to-end platform. A platform gives smaller IT teams an easier target and requires less diverse set of skills to maintain.
Related Article: MACH Architecture: What It Is, Why You Should Know It
What Is Your Expected Time-to-Market?
Time-to-market is another big factor in deciding whether to go headless or not. When evaluating which direction to take, consider the expectations around the timeline. If headless is the direction of choice and the job requires building a new integration layer for your headless point solutions, expect a delayed time-to-market. Headless architecture requires some foundation and setup that would significantly delay going live if starting from scratch. Some organizations already have a headless infrastructure in place so adding a headless product to the mix would be quick and easy. For a quick time-to-market, end-to-end platforms are usually the way to go. They are often easier to standup and come equipped with a ton of out-of-the-box functionality.
What Is Your Vision Around Emerging Technologies?
Platform solutions usually come equipped with everything you need connected out-of-the-box — but that has its drawbacks. When you supply an all-inclusive product, it is usually harder to replace and upgrade pieces of that product with more state-of-the-art technologies. Headless architecture has the advantage here, as it makes it possible to replace and upgrade pieces of your architecture without disrupting any other part of your application. This advantage is not limited to existing functionality within an application but also connecting to new and emerging technologies such as Internet of Things (IoT) devices. Connecting these new channels through APIs is possible with both headless and non-headless architectures, but headless architectures are built for this use case where non-headless architectures merely tolerate it.
Is a Headless Architecture Right for You? It Depends
The decision to go headless or not isn’t simple or straightforward. When making this decision, an organization should weigh all the relevant factors because it will affect much more than which products it procures. At the end of the day, you don’t want to be the one with blindfolds on at the voting booth.