Monolithic systems are inflexible - they make it difficult to adapt and innovate quickly.
High maintenance costs - they require more effort and resources to make changes.
Modern, modular architectures offer advantages - headless approaches enable more flexibility and scalability.
In the IT world, a monolith is a software system that attempts to solve all requirements and challenges posed to the application with a single software suite. In other words, the "all-in-one" solution; the egg-laying wool-milk sow that is often promised. But what sounds so simple is in fact often more complex than it seems - and than it should be. And what has since been replaced by new headless systems. Steep thesis? Let's take a closer look.
A special feature of monolithic systems is that the software components are firmly connected to each other and therefore interdependent - not loosely coupled, as is the case with modular systems or headless software. From our current perspective, this interdependence within monoliths is a problem: they quickly reach their limits when the application grows or needs to be adapted to the individual needs of the company.
Another monolithic characteristic, as already mentioned, is the wide range of functions that are mapped within this one system. However, the many features quickly lead to a huge and complex monolithic code base. This is not only more complex to manage, but also makes updates or further developments more difficult. Changes to one part of the software can lead to unintended effects on other parts - which requires longer development and test cycles.
However, like many things, the software system landscape has evolved. The fact that we as a digital agency tend to advise against monolithic systems today does not change the fact that the history of the monolithic Internet has long been crowned with success.
The World Wide Web is now a good 30 years old. In this country, the success story began when AOL brought broadband Internet to Germany in 1995. And it wasn't long before a number of companies also went online. In the dotcom boom phase of the 2000s, companies discovered the possibilities of the internet: whether it was to reach a wide audience, sell products, offer services or simply to show a digital presence.
The demand for simple, fast and universal website and platform solutions was there. And that's why the supply grew. During this time, many well-known CMS and e-commerce software suites were born, such as TYPO3 (2004), Sitecore (2001), Drupal (2000), Shopware (2004), Oxid (2003), First Spirit (2000) OpenText (1991), Magnolia (1997), Intershop (1992), Demandware (2004) and so on and so forth.
But how did it come about that in the past the monolithic solutions of a few large software providers often prevailed? As is so often the case, it has to do with security and trust.
When it comes to implementing software projects, it usually takes a company's IT experts to ensure that the software can be properly integrated into the company's existing infrastructure. The IT department therefore has a great responsibility to choose the right and most secure option.
This is why, especially in the past, many IT teams relied on the best-known standard solutions from legacy tech companies when deciding on CRM, PIM or ERP systems. And thus also on the solutions that enjoy a particularly high level of trust on the market. For example, many companies followed the "Microsoft strategy" or the "SAP strategy" - in other words, a large software manufacturer was selected as the company solution for all IT tasks. Over time, requirements such as web server IIS (Internet Information Server from Microsoft) and MSSQL databases emerged - because software and support were purchased and licensed from Microsoft anyway. This also had the advantage that interfaces between the systems could generally function seamlessly or were already in place. All in all, an IT decision that was certainly plausible at the time. This led to the following solutions:
Software that was close to the providers' software strategy
Solutions that were compatible with the database systems of the company software
Software for which updates and support could be purchased via framework agreements
Software that was already equipped with interfaces to CRM, ERP and PIM
Software that matched the company's IT infrastructure
Congratulations, trapped in vendor lock. When you opt for a system from a legacy tech provider, you are making a commitment to operate exclusively in the world of that provider. This also means that your own special requirements can only be developed with custom code and on the basis of the existing system and product landscape. With this decision, you get basic compatibility and security - but you pay the price of interchangeability and the ability to innovate. And also the price of maintenance costs, which we will briefly outline next from an agency perspective.
We want to be a little provocative here, because let's be honest: We have also benefited from this in the past. From an agency's perspective, selling monolithic on-premise solutions can be a profitable business model.
Because the suites are usually hosted on internal or external servers, they also need to be regularly maintained and serviced. In addition to security and bug fixes, regular software updates are required, which cannot be centralized - as is possible with a SaaS solution, for example. And because the monolithic code base is often adapted to the individual and very specific needs of the company, such updates and upgrades are very time-consuming and cost-intensive. As a rule, between 20 and 25% of the initial costs are incurred. To illustrate this, this means that in addition to the initial costs of 500,000 euros, for example, maintenance costs of between 100,000 and 120,000 euros are added - not including the annual license costs.
Extra requests and maintenance therefore have their price. From the agency's point of view, this is a business model that not only pays off financially, but also increases customer loyalty and therefore security.
Let's be clear: monolithic systems may have been the perfect solution in the past - but they are definitely no longer "all-round carefree packages". Legacy and monolithic content management systems require companies to make costly and resource-intensive deployments that are not necessarily future-proof.
This is because monolithic systems no longer (necessarily) meet the requirements of today's Internet and modern software development. In recent years, the market, the variety of solutions and the demands of users have evolved. A paradigm shift has taken place, which we will discuss in more detail in the second part.
In recent years, more and more systems have become established that outshine the advantages of monolithic systems. As already mentioned above, there is always an enormously high level of dependency with a monolith. In comparison, MACH systems offer the enormous advantage of flexibility. Headless CMS systems are particularly suitable when it comes to easily managing and adapting content across channels. Basically, the main point here is that in headless CMS systems, adjustments only have to be made in one place in order to be played out on all channels.
Headless architectures also offer great added value thanks to the simple linking of different modular systems. The right mix of systems and applications can be combined for every requirement, just like in a modular system. In the MACH world, there is no such thing as a "one-fits-all" solution. The focus is on customized solutions that bring out the best in every project.