Composable

For many, the name "commerce software" evokes a monolithic system, perhaps extended through plugins, that realizes all the necessary functionality in a single codebase. And it's no surprise, as such systems are simpler to set up and easier to reason about. But they have a critical shortcoming: should you need to change a single component in any way, you may need to change the entire system.

Higher Adaptability

Any function that is not achievable through the core feature set or via delegation APIs (plugins, extensions, etc.) either becomes a compromise you accept or disqualifies the entire system. And re-platforming the whole organization is a painful process.

Anecdotal evidence shows that many organizations underwent these platform changes in a cyclical fashion, where the commerce solution was rebuilt from scratch every five to ten years. Internal pressure wanted the platform to change more often as it lacked the functions necessary to maintain a competitive edge. Meanwhile, leadership pushed for longer periods as every change was costly and detrimental to the organization's health.

We believe for larger companies, a more modular architecture is a better approach. If monolithic software is a single program, composable architectures are like an operating system with multiple programs running. Each specializes in its area of responsibility and delegates other tasks to the remaining systems.

Of course, this modularity comes at a cost: with more moving parts, some complexity is inevitable. However, when one of the components is deemed insufficient, you only need to replace that single component and its connections to the adjacent systems. Through clever application of the strangler pattern, the architecture can be evolved without disrupting other teams and business units. It's not free or painless, but the scope of every change is much smaller, the timelines shorter, and the risks involved are easier to contain.

This, in turn, can lead to greater autonomy and efficiency of organization units. The benefits of enabling teams to pick their tools can quickly outweigh the one-time cost of integrating them.

Shared Responsibility

An argument can be made that open-source counters the problem of outgrowing a monolith as it allows the software to be customized beyond what the authors originally intended. And it's true in the technical sense because you can hire software engineers to modify the source code.

But with every modification, you stray further away from the original system. Upgrading the system becomes harder, if not impossible, as you need to keep track of every change and modification; the documentation is yours to maintain as the system no longer behaves the same way. And should anything go wrong, you are likely the only organization in the world using your unique set of modifications.

Composable architectures allow strict borders of responsibility to be drawn across different delegation paths. Every system is maintained by its respective vendor or team, and every system can be upgraded independently as long as the contracts of the delegation APIs remain intact. This allows you to mix SaaS vendors with on-premise solutions and get the benefits of both managed services with their SLAs and custom software with unquestionable flexibility without owning the entire software stack.

Lower TCO

This last benefit is crucial for another reason. For most organizations, owning software is not a goal; it's a compromise. Unless you work for a software house or a software conservancy, maintaining software and the necessary infrastructure is a recurring cost that is best applied sparingly, where it helps to differentiate your business and benefits your customers directly.