System Deep Dives. Platforms Without an Agenda.
Understanding commerce architectures. Making informed decisions.
Ten independent analyses of e-commerce platforms with distinctly different approaches. No rankings, no preferred technology and no implementation agenda. Instead, a considered examination of where each platform may be suitable, what it requires and the economic consequences of choosing it.
The right platform follows the requirements. Not the other way round.
Choosing an e-commerce platform today means deciding considerably more than how an online shop should operate. The decision affects business processes, data, integration and the long-term ability of a retail or commerce organisation to adapt.
The commerce platform is not the entire commerce architecture. A capable storefront can be undermined by unreliable inventory information, inconsistent pricing or poorly integrated enterprise processes, even when the underlying problem has little to do with the commerce engine.
An extensive feature list is no guarantee of operational suitability either. A highly customisable system may provide one company with a meaningful competitive advantage while burdening another with development, integration and operating costs that its business requirements cannot justify. Technical capability only becomes an advantage when the organisation has the capacity to maintain it and the economic case remains sound over time.
The differences between commerce platforms therefore extend beyond functionality. They concern how technical responsibility is distributed, which processes can be standardised, how existing systems are integrated and what capabilities the organisation must maintain over time.
Unified Commerce and Agentic Commerce add further considerations. Consistent cross-channel operations and controlled access by AI agents to product information, business logic and transactions extend the architectural challenge. They do not, however, remove the need to align technical choices with business requirements.
The System Deep Dives examine ten platforms from these perspectives. Each analysis considers the platform within its own intended operating context, distinguishes documented capabilities from practical requirements and identifies material limitations.
The outcome is not a universal platform recommendation. It is a more reliable basis for making decisions.
The ten System Deep Dives
Commerce platforms can perform quite different roles. Some provide a largely standardised, centrally operated commerce core. Others offer extensive customisation or deliberately separate services from which companies can assemble their own architectures.
These differences shape not only implementation, but also long-term operations and economic sustainability.
Each Deep Dive examines the defining characteristics of a platform, its relationship with existing enterprise processes and the conditions under which it can be deployed or developed further.
The analyses are displayed in descending order of their most recent substantive editorial update. Where dates are identical, platform names are sorted alphabetically. Their position is not an assessment of quality.
Shopify
Updated:
Standardised SaaS commerce between operational efficiency and platform constraints
Shopify offers a centrally managed commerce core supported by a substantial ecosystem of applications, interfaces and extension options.
Standardisation can significantly reduce technical operating responsibilities and make established commerce processes relatively straightforward to implement. The extent to which individual requirements can be accommodated, however, depends on available platform capabilities, the relevant plan and complementary applications.
These conditions require careful examination in complex B2B environments, specialised checkout processes and extensive cross-channel operations. The ongoing costs of additional applications and integrations also form part of the economic assessment.
The Deep Dive considers when Shopify's standardisation delivers a business advantage and when extension requirements and platform dependencies become more significant.
Read the Shopify Deep Dive
Adobe Commerce
Updated:
Custom business logic between architectural freedom and technical responsibility
Adobe Commerce allows substantial customisation of product models, business rules and purchasing processes. This can make it relevant for businesses whose requirements extend beyond standard commerce workflows.
The scope for customisation and the associated operating responsibilities depend on the deployment model. Extensions, integrations, security updates and the long-term maintenance of bespoke developments therefore need to be assessed within the specific architecture. Additional products from Adobe's portfolio do not automatically create seamless business processes.
The Deep Dive examines how Adobe Commerce can support complex trading requirements and how customisation, deployment choices and integration effort affect its long-term economic viability.
Read the Adobe Commerce Deep Dive
BigCommerce
Updated:
Managed SaaS commerce with open integration and frontend options
BigCommerce combines a centrally operated SaaS commerce core with APIs, headless options and various ways to connect additional applications.
This approach may suit businesses that wish to delegate the operation of core commerce functionality while retaining the ability to develop bespoke storefronts or integrations. It remains essential, however, to distinguish business logic supported within the platform from requirements that depend on other systems or custom development.
For more demanding B2B processes, multiple sales channels and international business models, the actual architecture determines the effort involved and its economic consequences.
The Deep Dive examines BigCommerce through the relationship between SaaS standardisation, technical openness and responsibility for the surrounding components.
Read the BigCommerce Deep Dive
commercetools
Updated:
Composable Commerce as a deliberate choice about architectural responsibility
commercetools provides commerce capabilities as API-based services that can be combined with different frontends and complementary systems.
This allows businesses to design a commerce architecture around their particular operating models. At the same time, the organisation assumes substantial responsibility for selecting, connecting and evolving the individual components. The platform supplies important commerce capabilities, but not an automatically integrated trading environment.
Its economic suitability is therefore closely linked to the organisation's architectural competence. Integration, testing, monitoring, governance and ongoing operations must be managed accordingly.
The Deep Dive explores when this freedom creates measurable business value and when the additional architectural burden may outweigh the benefits.
Read the commercetools Deep Dive
OXID eShop
Updated:
A controllable commerce architecture with an established DACH ecosystem
OXID eShop is an established commerce platform in German-speaking markets, offering opportunities to extend storefront functionality and adapt business processes.
For organisations with established and specialised requirements, that adaptability may be valuable. The capabilities available in practice, however, depend on the edition, the extensions employed and the operating model selected.
Access to suitable developers and implementation partners, together with the long-term maintainability of customised solutions, also matters. For existing OXID installations in particular, the question is which requirements can be met through further development and where genuine structural limitations remain.
The Deep Dive assesses the platform in the context of mid-market commerce architectures, existing investments and responsibility for operations and integration.
Read the OXID eShop Deep Dive
Salesforce Commerce Cloud
Updated:
Different commerce product families within the wider Salesforce ecosystem
Salesforce Commerce Cloud encompasses offerings for different commerce business models, including B2C and B2B. Connections to other Salesforce products create opportunities to bring together commerce, CRM, customer information, service and agent-assisted interactions.
The B2C Commerce and B2B Commerce product families have distinct technical foundations that need to be considered individually. A shared suite name does not necessarily imply common data models or fully integrated business processes, although integration between the products may be achievable through the relevant services and architecture.
Salesforce temporarily adopted the name Agentforce Commerce before returning to Commerce Cloud for the suite. Regardless of that naming history, the different technical foundations of its commerce products remain an important architectural consideration.
The Deep Dive examines the respective commerce models, their integration with the wider Salesforce ecosystem and the conditions required for coherent use of additional data, service and agent capabilities.
Read the Salesforce Commerce Cloud Deep Dive
SAP Commerce Cloud
Updated:
Commerce as part of complex enterprise and B2B processes
SAP Commerce Cloud is particularly relevant to organisations whose trading operations are closely connected to extensive product information, customer-specific commercial terms and existing enterprise systems.
In B2B environments, organisational purchasing structures, negotiated pricing, approval workflows and integration with ERP-related processes can be central requirements.
The SAP ecosystem provides several integration possibilities. It does not remove the need to establish how data, permissions and business processes are coordinated across participating systems. Considerable integration and operational responsibilities may remain even within a comprehensive enterprise suite.
The Deep Dive therefore considers SAP Commerce Cloud not as standalone shop software, but as a potential component of a complex enterprise architecture with corresponding technical, organisational and economic requirements.
Read the SAP Commerce Cloud Deep Dive
SCAYLE
Updated:
Commerce for complex retail organisations operating across brands and markets
SCAYLE emerged from a technology-intensive retail environment and is particularly directed towards retailers managing extensive assortments, international operations and demanding commercial processes.
Its defining characteristic is an emphasis on retail requirements where multiple brands, markets and complex product and inventory structures must be coordinated.
The distinction between functions provided by the platform and those delivered through complementary systems remains important. Connections to ERP, logistics, customer management and other applications form an essential part of the architecture decision.
The Deep Dive examines SCAYLE's documented retail capabilities and the conditions under which they can be integrated into an existing trading organisation.
Read the SCAYLE Deep Dive
Spryker
Updated:
Modular commerce architecture for individually designed transaction processes
Spryker addresses business models in which standard storefront processes are insufficient and substantial bespoke commerce or transaction logic is required.
These may include complex B2B operations, marketplace arrangements and other models involving multiple participants, order workflows and system boundaries.
Its modular architecture allows these processes to be designed around specific requirements. It also requires an organisation capable of developing, testing, operating and maintaining those individual solutions over time.
The critical question is therefore not modularity in itself, but whether the business requirements justify the resulting architecture and whether the organisation can sustain its complexity.
The Deep Dive examines Spryker from this perspective, distinguishing documented platform capabilities from business logic that must be developed separately.
Read the Spryker Deep Dive
Shopware 6
Updated:
A modular commerce core with different extension and operating models
Shopware 6 combines a modular commerce core with sales channels, APIs and a range of extension mechanisms. The platform is particularly established in German-speaking markets and can support different B2C, B2B and international commerce models.
The available design options depend, among other things, on the edition and deployment model. Not every form of extension is available under every operating arrangement. Additional B2B capabilities and integrations must also be assessed in terms of their scope and actual availability.
When connecting ERP, PIM, OMS or store systems, the key distinction remains between processes handled within Shopware and responsibilities assigned to the surrounding architecture.
The Deep Dive examines these differences and considers Shopware's role within different mid-market commerce environments.
Read the Shopware 6 Deep Dive
How we examine the platforms
The System Deep Dives follow a common methodology without forcing the distinctive characteristics of each platform into a rigid assessment framework.
Every analysis distinguishes documented product capabilities from practical operating requirements and their implications for architecture, organisation and long-term economics.
What the platform actually provides
The starting point is the technical and functional foundation of the system. This includes architecture, business logic, commerce capabilities, interfaces, extension mechanisms and deployment models.
Actual availability matters just as much. Not every documented feature is included in every edition. Some capabilities require additional licences, specific operating models, separate components or particular regional conditions.
Others remain in beta or have only been announced.
These distinctions are made explicit. A product announcement is not treated as evidence of functionality available for production use.
What practical implementation requires
A documented feature does not establish that a complete business process will operate reliably within a particular enterprise architecture.
The Deep Dives therefore examine integration with ERP, PIM, OMS, POS, CRM, payment services and other systems. Data quality, security, operational responsibility and organisational competence are equally relevant.
The economic assessment extends beyond licence and deployment costs. Development and integration work, ongoing maintenance, external service providers, internal capabilities and responsibility for operating the wider architecture all contribute to the cost of ownership.
Extensive technical freedom has economic value only where the differentiation it enables justifies the corresponding effort.
What businesses can reasonably conclude
Each analysis brings documented capabilities and practical requirements together into an independent assessment.
Vendor information is distinguished from the author's analysis, independent evidence and documented implementation experience.
Independent evidence is not available to the same standard for every platform or capability. Such limitations are identified rather than concealed. An absence of independent evidence does not establish that a feature is unavailable. Equally, it does not justify treating a vendor's claims as verified operational experience.
The analyses deliberately avoid numerical scores and general platform rankings. A system may serve certain requirements exceptionally well while presenting substantial limitations in other business contexts.
What matters is understanding the conditions under which a particular solution may be suitable.
What is changing in commerce
Commerce platforms evolve alongside the business processes and systems of which they form a part.
Two developments are particularly significant for commerce architecture. Unified Commerce concerns the consistent execution of business processes across channels. Agentic Commerce extends the ways in which AI agents can access product information, business logic and transactions.
Both increase the importance of integration, data quality and governance. Neither necessarily requires an existing commerce platform to be replaced.
Unified Commerce does not begin at the storefront
Operating several sales channels does not, by itself, create an integrated commerce organisation.
Consider a customer who orders online and collects the purchase from a physical store. For that process to work reliably, inventory information must be current, stock reservations must be respected and the participating systems must agree on the status of the order.
Similar requirements arise with cross-channel returns, customer-specific commercial terms, in-store ordering and the reconciliation of customer identities.
Unified Commerce is therefore more than a shared interface or the technical connection of several sales channels. It requires consistent business rules and reliably coordinated processes across the trading organisation.
Three different levels need to be distinguished. A platform may provide a function natively, connect to another system through an interface, or form part of an architecture that orchestrates complete business processes across multiple systems.
These are not equivalent capabilities.
An API that retrieves inventory quantities does not, for example, demonstrate that competing reservations can be handled correctly. The organisation must also establish which system takes precedence when records conflict and how failed operations are detected and corrected.
Effective Unified Commerce therefore emerges from the interaction of platform capabilities, data architecture, process orchestration and organisational accountability.
Agentic Commerce changes how customers and systems interact
AI agents create additional ways of accessing products and commerce processes without necessarily using a conventional storefront.
Different forms of agent involvement need to be distinguished.
An agent may provide product information, interpret requirements and recommend suitable options. It may also prepare a purchase, check variants and availability, or assemble a basket. More advanced capabilities can allow an agent to perform actions only within a clearly defined scope of delegated authority, backed by enforceable permissions and appropriate transaction controls.
Each level brings different security, authorisation and control requirements.
Providing product information is not the same as enabling a complete agent-mediated purchase. Preparing a basket does not mean an agent has authority to place an order. Access to a tool does not, by itself, authorise a transaction. And a checkout explicitly confirmed by the customer must be distinguished from an action executed under previously delegated authority.
A meaningful assessment must therefore consider the entire transaction lifecycle. This includes product discovery and advice, selection, price and availability checks, basket preparation, payment authorisation, order execution and post-purchase service.
Emerging protocols and interfaces provide different technical foundations for these processes.
The Universal Commerce Protocol (UCP) and Agentic Commerce Protocol (ACP) address the integration of commerce capabilities into agent-mediated interactions and transactions, each through its own specifications and integration models.
The Agent Payments Protocol (AP2) focuses particularly on verifiable payment authorisation in agent-driven transactions.
The Model Context Protocol (MCP) provides structured access to data and tools. WebMCP seeks to make tools within web applications accessible to agents, although its standardisation remains in development.
These technologies are not interchangeable. Supporting one of them does not demonstrate complete integration of commerce processes or generally available autonomous transaction capabilities.
Where agents can execute actions, customer and agent identities, permissions, spending limits and the scope of delegated authority become particularly important. So do the ability to revoke that authority, an auditable record of actions and appropriate procedures for escalation to a human decision-maker.
The System Deep Dives therefore examine specific documented capabilities and their availability. They distinguish native functionality from additional products, integrations, partner solutions and bespoke development.
An integrated AI assistant or MCP endpoint is not sufficient evidence of a complete delegated purchasing process.
New capabilities do not necessarily require a new platform
Unified Commerce and Agentic Commerce bring a fundamental architectural question into sharper focus.
Which responsibilities need to sit within the existing commerce core, and which are better addressed through specialised services or additional integrations?
New product-data services, integration layers, agent tools or payment services can extend existing platforms, provided their business logic and data can be accessed in a controlled manner.
Nor should a broad product suite automatically be regarded as a fully integrated architecture.
Common branding, shared technical services, consistent data models and genuinely end-to-end business processes represent different levels of integration. Even products from the same vendor may require additional connections, coordination and organisational ownership.
Businesses must therefore evaluate technical possibilities alongside their economic consequences.
Not every additional capability justifies a new platform. Equally, genuine structural limitations should not be dismissed simply because another integration could make an individual requirement technically achievable.
When changing platforms makes sense
Replacing a commerce platform is one of the more consequential decisions a commerce organisation can make. It affects far more than a software application, often touching established business processes, integrations, data structures and substantial existing investments.
That makes understanding the causes of current problems particularly important.
Unreliable inventory information may result from limitations in the commerce platform. It may equally be caused by faulty ERP processes, poor data quality or inadequate integration.
Complex custom developments do not necessarily prove that the existing platform is unsuitable either. They may reflect historical decisions whose original business justification no longer applies.
A substantial proportion of technical debt also exists between systems. Specialised rules for pricing, customer accounts, inventory, fulfilment or returns may have developed over many years. Replacing the commerce core does not automatically remove them. A migration may reduce these dependencies, but it can also reproduce them within a new architecture.
Platform replacement becomes a serious option when demonstrable structural limitations materially restrict essential business requirements and reasonable extensions or adaptations cannot provide a sustainable long-term solution.
The economics of the change must also be considered. Migration costs, operational risks, existing investments, integration effort and the organisation's ability to maintain the new architecture all belong in the assessment.
The important question is therefore not whether another platform appears more modern.
It is whether a different architecture would deliver a defensible business advantage sufficient to justify its costs and risks.
Independence is part of the methodology
The System Deep Dives are produced without vendor affiliations, a preferred platform or an implementation agenda.
They draw on official product documentation, technical specifications, verifiable publications and, where available, independent sources and practical implementation experience.
Vendor statements are identified as such. Documented functionality is distinguished from capabilities that are actually available and from implementations demonstrated in practice. The author's own assessments are clearly differentiated from objective product characteristics.
The analyses are reviewed when substantive developments warrant it and updated where necessary. Relevant changes include new product capabilities, revised deployment or licensing arrangements, significant architectural developments and evidence that materially changes an earlier assessment.
Each article's update date refers to its most recent substantive editorial revision. Purely technical changes, layout adjustments or metadata-only edits do not alter that date and must not affect the order of articles on this overview page.
Independence does not mean presenting every platform as equally suitable. Documented structural limitations are as important to an informed assessment as genuine strengths.
From analysis to decision
The ten System Deep Dives provide different perspectives on architecture, integration, business processes and economic responsibility.
They help businesses assess existing platforms more realistically, distinguish documented capabilities from marketing claims and ask more useful questions before making investment or migration decisions.
Determining which architecture is suitable for an individual business, however, requires an examination of its actual circumstances. Business model, existing systems, organisational capabilities, economic constraints and longer-term strategic objectives all matter.
A structured, vendor-neutral platform selection process brings these perspectives together to establish a sound basis for decision-making.
Not to validate a platform already chosen, but to determine which architecture the business actually needs.