A historically grown monolith with a strong ecosystem.

5.8

Composability

Composable architecture means that it is easy to assemble and scale a software product according to individual functionality requirements. Composable software should be plug-and-play even across different products. Adobe or Magento Commerce is a monolithic platform that is deployed with all the features included, not just the ones required. It is not possible to decompose any of the features that are initially provided. However, Magento offers two main means of extension and customization. The first is through third-party integrations from the Adobe ecosystem. There are more than 300,000 Magento developers and a huge partner network, making Adobe’s ecosystem and community a real asset. Secondly, Adobe Commerce can be extended using custom solutions provided by the customer. However, these inevitably require traditional development with considerable effort. Adobe Commerce doesn’t offer no-code or low-code customizations, serverless functions, or easy ways to change APIs. Extensibility is therefore fundamentally available, but the ecosystem only offers the ease of use of composable commerce as long as the built-in functionalities and capabilities of the ecosystem are sufficient to meet a business’s requirements.

3.3

Modularity

Modular systems can be achieved in various ways, e.g. via microservices or PBCs (Packaged Business Capabilities). Due to the increasing relevance of composable solutions, modular systems are becoming more and more essential and must be adaptable accordingly.
Microservices are an architectural pattern where individual pieces of business functionality are developed, deployed, and managed independently. The architecture of Adobe Commerce is not based on microservices. It is a historically grown monolith, with all the advantages and disadvantages that come with that. On the plus side, it is easy to implement Adobe Commerce, allowing for comparably short time-to-market. On the other hand, the plug-and-play simplicity of the monolithic platform comes at the expense of the benefits that microservices would provide: easier testing, improved productivity, flexibility, and scalability. Users implement more or less all existing functionalities, whether they need them or not, and it’s difficult to add new custom functionality as it often clashes with existing features. Only certain services, like the analytics capability called Business Intelligence, can be added for an extra cost. But only a few such capabilities are available, and they are not as granular and functionally independent as true microservices.

4.9

API First

An API-first approach means that a software product is built based on the assumption that it will be consumed through APIs. Adobe Commerce generally offers the Magento web API framework, which provides integrators and developers the means to use web services that communicate with the Magento system. Adobe Commerce does not follow an API-first approach, though. Magento built an online shop system with inseparable GUI, and an API layer was added later. This is, inevitably, always reflected in the architecture. 

Today, Adobe Commerce offers their own PWA framework that communicates with the backend system through APIs. Technically, these APIs follow several industry standards such as OAUTH and REST. However, they don’t provide versioning, and output types are mostly hard coded using JSON. This limits flexibility. Capability coverage with APIs is relatively high overall, but less so with B2B features.

5.6

Cloud Native

Cloud-native technologies are an approach to designing, constructing, and operating workloads which are built in the cloud, and which leverage it beyond storage and hosting. Being cloud-native is about speed, agility, and scalability. Adobe or Magento Commerce can be deployed either as an on-premise solution, or in the cloud on AWS or Azure. Thanks to partnerships with major cloud providers, Magento Commerce Cloud is, overall, a robust solution. Modern standards like on-demand self-service and resource pooling are provided. A substantial disadvantage is that Adobe Commerce Cloud doesn’t yet support autoscaling, resulting in limitations in terms of maximum transaction throughput. The second considerable drawback is inconvenient core updates. Dependencies in the code aren’t fully transparent. Modules have implicit access to other modules’ business logic. As a result, updates—especially of customized features—are potentially fatal. Changes to one part of the product may cause unforeseen consequences elsewhere due to the intransparent cause-effect relationship of a monolithic system. The fundamentally solid cloud solution from Adobe, respectively Magento, thus falters when it comes to the actual strengths of the cloud: elastic scaling and seamless deployment.

6.1

Headless

A headless application has an architecture that completely separates the backend content, data storage and complex functionality from the client-side rendering of the information. Due to the dependency issues already explained under “Cloud Native,” Adobe Commerce does not decouple the business logic from the frontend. This means that it is not a headless solution, but rather a hybrid. Magento Commerce generally offers a standard frontend and the PWA Studio. And while other frontends can be added, the original one cannot be removed. The many out-of-the-box skins that are available in the marketplace are one of Adobe Commerce’s strengths, but are more of a declarative nature than enabling a platform to integrate current and future channels like voice or car. This is one aspect where Magento has benefited from being acquired by Adobe, as this has opened up the possibility for integrations with other services such as Adobe Experience Cloud. However, the user experience cannot be customized as freely and flexibly as might be desired. PHP is set, major parts of the JavaScript environment are set, and certain elements cannot be removed without major effort.