Glossary & Background
Monoliths
There are various fundamentally different approaches to the architecture of ecommerce systems. After the first series of often self-built systems at the end of the 1990s, the first mass-produced store systems appeared in the early 2000s. These were mostly large, monolithic PHP applications that were customized by customer or agency developers and hosted on dedicated servers. Over the years, an extensive ecosystem of agencies and extension developers has formed around these systems, many of which are still very widespread today. At their core, however, they are still often 15 or 20-year-old monolithic systems that are difficult to renew due to the extensive extensions and pose considerable challenges when it comes to scaling. As a result, they are rarely considered for the requirements of an enterprise system today.
API First, Headless
The 2010s saw a new wave of ecommerce systems with a more modern and scalable architecture. In contrast to their monolithic predecessors, attention was paid to separating the frontend and backend. At first, older systems were supplemented with APIs that mapped parts of the store functions. Later, "API First" systems were also developed, which could be operated entirely via the API. Another specialty was the first "headless" systems, in which the ecommerce system is basically offered without a front end, i.e. only an API is provided. This is due to the assumption that large (enterprise) customers usually develop their own frontends due to the high degree of customization and only do not want to develop the underlying store functionalities (shopping cart, payment, order processing) themselves. From a technical and functional point of view, these are commodities that are purchased as services. The disadvantage of this solution is, of course, that the front end first has to be completely developed, which usually takes months and means that development teams have to rediscover the wheel in many places.
All-in-One-Suites
There are a number of non-modular systems that map the entire range of functions of the online store. The disadvantage of complex, closed systems is an all-or-nothing approach. Although you get all the functions from a single source and everything is ideally well coordinated, the elements are not modular and interchangeable. If individual functions are not sufficient for your own requirements, the system can hardly be expanded. For better or worse, the store operator is therefore stuck with the standard of the system. Many systems on the market have also grown over time through acquisitions, meaning that the provider's system was quickly expanded through the purchase of additional products. The integration of different software products is very difficult, which often results in a "Frankenstein effect" in practice, where different functionalities do not fit together seamlessly, but rather appear patched together and there are noticeable breaks and inconsistencies in use.
Best of Breed
As an alternative to all-in-one suites, the "best of breed" approach has become widely accepted. Here it is recognized that a complete e-commerce landscape is too complex in itself and the respective requirements are too different for a single system to optimally cover every single functional area. The range of functions is therefore split across various components, with the best tool of choice ("best of breed") from different providers being used from each functional area, e.g. recommendation engine, email marketing, personalization, CRM, ERP, logistics, pricing, etc.
The store systems that follow this standard focus on core functions such as catalog management, product pages, shopping cart and order entry. Additional functions (e.g. personalization, recommendations, AB tests) are mapped as part of the store system, for which specialized products are then used and connected. The advantage of this is that you can create a tailor-made system that is optimized in every area. The disadvantage is that this is associated with considerable effort and costs. It is not uncommon to have to purchase dozens of systems (each of which can be very expensive) and connect them all together. This in turn requires large development teams that are familiar with the various products and combine them on one platform. In practice, this means that many medium-sized stores only offer a few core functions and are simply unable to map many extended but important functions, which means that the customer experience and ultimately conversion suffer.
Composable Commerce
Composable commerce initially describes the idea that the various components that map different business domains (product master data, shopping cart, order management) should be able to be combined with each other as required (see "Best of Breed"). In practice, however, there are no technical standards here. Even if the various manufacturers each offer interfaces, for example Rest or GraphQL, they all still have to be connected to each other. There are no uniform standards for data exchange formats (product data, order data), which means a lot of programming work, the use of costly middleware and tedious tracking in the event of changes. In addition, due to the high performance requirements of online stores (e.g. Google Web Vitals, Time-To-First-Byte), it is hardly possible to connect these different components and micro services with each other in real time. The additional logic is usually only executed downstream, i.e. integrated asynchronously, or e.g. via the front end (e.g. AB tests), which also leads to usability problems (e.g. CLS).
Micro Services
Einer der größten IT Architektur Trends der letzten Jahre war es, monolithische Applikationen in kleinere Services aufzuteilen, die jeweils in sich geschlossene, logische Funktionalitäten abdecken und untereinander kommunizieren, sofern nötig. Dies hat eine Vielzahl von Vorteilen bei der Entwicklung und Wartung der einzelnen Services, die kleiner und überschaubarer sind. Nachteil hierbei sind vor allem der Mehraufwand bei der Überwachung und dem Betrieb vieler einzelner Services, sowie die zusätzliche Latenz bei Kommunikation zwischen den Services.
Cloud Native
Dies bezeichnet den Ansatz, die Software bzw. einzelne Services als Container (Docker, Kubernetes) auf Cloud Servern zu betreiben, wodurch sie (jeder für sich) leichter zu verwalten und skalierbarer sein sollen. Es gibt keine offizielle Definition zu diesem Begriff und heute wird er auch von vielen Anbietern irreführend verwendet, die lediglich ihre monolithischen Applikationen auf einem virtuellen Server bei einem Cloud-Anbieter hosten. Dabei ist die Applikation nicht viel skalierbarer als vorher, lediglich die Hardware wurde ausgelagert.