Monolith

Traditional Sitecore could be your CMS, Frontend, Marketing Engine, Email Service, and maybe even more. This is a lot to cope with. I have always seen Sitecore as a monolith system. It's a massive tool to build websites. Using a monolith system is like sailing in a massive ship with all kinds of containers (not docker-related, real containers). Some containers aren't even used! That's the problem with monolith systems, it's an all-in-one toolbox, and it requires custom work to integrate a different tool.

There is a need out there for more flexibility to choose and easily integrate the right tool for the job. This is what the DXP concept brings you.

Below you see a simplified architecture in a traditional MVC Sitecore project. Not so long ago it was a common practice to get data from business logic APIs or even internal NuGet packages, add template mappings and pass this as a model to a Razor view. Interactivity was, for example, added by jQuery at the frontend.

All of these MVC projects are tiny abstraction layers. All these layers together became a huge project, where Sitecore logic is mixed with business logic. The downside of a project like this is, it will become blurry to see the difference between Sitecore and the implementation of Sitecore. Sitecore should manage and deliver content, but mixing it with business logic can be troublesome for all kinds of reasons. This coupled way of working often results in people talking about "Sitecore websites" or "websites build with Sitecore". Which is odd, Sitecore is just a CMS, isn't it?

MACH and DXP

With the introduction of Composable DXP, Sitecore embraces the MACH architecture and takes a step away from being a monolith system:

• Microservices
• API-based
• Cloud Native
• Headless

Composable DXP enables you to easily integrate products via APIs. In line with this concept, you should try to avoid talking about Sitecore as a product. Sitecore is a company, which has excellent products in it's portfolio. For some tasks, you might want to use Sitecore products and maybe a non-Sitecore product for something else. The integration and scaling is easier, so it's a great evolution.

In a headless context, the role of Sitecore XM is to manage and deliver content. This is where Sitecore excels. In my opinion, a specialist usually delivers better quality. A colleague of mine likes to use the metaphor of hiring a plumber to do some gardening, it makes no sense. There is a need out there for more flexibility to choose and easily integrate the right tool for the job.

This is what the MACH architecture and the decoupling concept bring you. Part of MACH is headless. Let's explore that next.