We have collectively forgotten what monoliths are

Even though there are a million articles about this, we have somehow grown numb to their content. In the race to composable DXP, we have collectively forgotten what monolithic software actually entails. Let’s re-learn the basics before we call modern platforms that add additional features the new monoliths. We are in the middle of the race to the middle!

In the early 2000s, content management systems were predominantly built as monoliths - large, tightly integrated software packages that offered a wide array of out-of-the-box features. These systems aimed to provide comprehensive functionality, covering approximately 75% of typical use cases without requiring additional customization.

To illustrate the difference between monolithic and composable systems, consider the analogy of sandwich-making:

• Monolithic platform: A pre-made sandwich with standard ingredients, nicely wrapped in some parchment paper and cut in the middle to shows its contents. To customize, you must “open up the sandwich, change the cheese, close it up again” - requiring some effort but leveraging existing components.

• Composable platform: Individual ingredients that allow you to “make exactly your own sandwich.” This approach offers more flexibility but demands greater expertise in “sandwich-making.

The misconception of modern platforms as monoliths

The term “monolith” is being misapplied to modern headless API-driven vendors who are expanding their feature sets. This mischaracterisation overlooks the fundamental differences between true monolithic systems and the flexible, API-driven platforms of today.

Key distinctions

• API-Driven Architecture: Modern platforms are built on API-first principles, allowing for seamless integration and interoperability with other systems. This is in stark contrast to traditional monoliths, which were tightly coupled and difficult to integrate with external services.

• Modularity: Unlike monoliths, contemporary platforms offer modular functionality that can be easily added or removed based on specific needs. This flexibility allows businesses to tailor their tech stack without being locked into a single, all-encompassing system.

• Scalability: Modern headless CMS platforms are designed for scalability, allowing components to be scaled independently. Monoliths, on the other hand, often required scaling the entire system, even when only specific features needed additional resources.

The evolution of CMS

The transition from monolithic to composable architectures represents a significant shift in the CMS landscape:

• Monolithic era: Characterized by all-in-one solutions with tightly integrated features.

• Headless revolution: Introduced decoupled content management and delivery.

• Composable present: Offers a mix-and-match approach to functionality

While it’s true that some modern CMS vendors are expanding their feature sets, it’s crucial to recognize that this expansion does not equate to a return to monolithic architecture. This is the race to the middle.

The key differentiator lies in the underlying design principles: API-first, modular, and inherently flexible. As the industry continues to evolve, it’s important to maintain clarity in our terminology.

Modern platforms that offer expanded features while maintaining an API-driven, composable architecture are not monoliths – they are the next evolution in content management platforms, providing the best of both worlds: comprehensive functionality with the flexibility to adapt to changing business needs.

Concluding

Headless vendors adding functionality is putting the customer first and listening to the needs. Idealistically chasing the headless dream makes customers set up procurement teams for 15 different vendors and countless SLAs. More over, composable architectures are complex. Getting more out of the box of a single vendor allows customers to use the same solution engineers and support to get more features for their dollars.

Modern composable software like Contentstack is sold as a platform. If a certain business case requires more specific features, build your own or use a different vendor and connect the systems. Due to its platform nature, you can also build on the platform using the developer hub or the automation product.

Let’s stop chasing idealistic headless sovereignty and start listing to our customers who demand software that solves their business problems…