The typical headless content creation experience is making content creators ask, "Why Headless"?
In the last few weeks, I heard a few stories about companies abandoning their headless website implementations for WordPress or HubSpot. They, almost apologetically, explained that they had systems that business users could not manage independently. Everything but the most straightforward text changes required a developer. Ultimately, it was more valuable for the business to work quickly within the limits of a garden variety CMS than maintain a higher-performing custom-coded solution.
Happy non-technical users, happy project
Business user interfaces are crucial for successful system adoption but seldom get the attention they deserve. The ability to create and iterate content is a significant advantage for design-driven applications like those managed by marketing and commerce teams. In the cases above, the older technology won out because it was easier for non-technical users. Take Adobe as an example; they always address business users' needs. Adobe Experience Manager (AEM), for instance, cultivates the fact that it has intuitive authoring workflows. It is easy to learn and takes fewer people to manage, and in the end, the reduced headcount justifies the licensing costs.
Custom-built systems are less likely to have intuitive interfaces. Business interfaces are difficult to do well and are considered a luxury by developers who find it easier to custom-code. So, in the end, they tend to be underfunded or skipped altogether. It also doesn't help that they get implemented at the end of the project and fall victim to budgets. JAMstack and MACH systems are decoupled by nature, providing, at best, a mishmash of system interfaces that turns into interface overload in large implementations.
Internal users want an amazing experience
Years ago, we were kicking off a big Adobe Experience Manager project for a tech company replacing a homegrown CMS. An engineering manager asked, "how many engineers will I need to do a content launch?". They had 12 engineers that worked with marketing to launch content. In the AEM world, you don't need engineers to publish content. They are required to add new capabilities but not for simple content publishing. At first, the engineering team was concerned. But eventually, once they saw that marketing could manage it, they were happy to let go of the publishing workflow. The result was a colossal efficiency boost; fewer people could do more faster, and engineering could focus on the actual product. Within 18 months, the process was simple enough that technical marketing support moved to global delivery.
We have the tools but not the process
Headless is a terrific way to build applications. It can deliver exceptional user experiences at scale, but it is an architectural pattern. It does nothing to define business workflows. Businesses are expanding their technology portfolios, so we need to think long-term about how to manage complexity and work efficiently.
Composable architecture becomes interesting because it begins to address business workflows and lifecycle concerns. It accounts for many of the common challenges like legacy and duplicate services. I think of composability as headless at scale. It brings significant long-term business value but requires us to think differently. With some foresight and the right tools, we can have both best-bread capabilities and a great internal user experience.