Inside the Machine: Architecture That Earns Its Simplicity

Every time I walk a customer's technical team through a CCv2 architecture diagram, the same question comes up around hour two: "So who owns the integration runtime in production?" The honest answer is: you do. That's not a criticism — it's a design choice that enables maximum flexibility. But it comes with a long tail of operational responsibility that CCE deliberately eliminates.

In CCE, the integration is the product. Let me walk you through what that actually means in the architecture, because this is where I see the most misunderstanding in the market right now.

The Sealed Core: Understanding What's Protected

The defining architectural concept in CCE is the sealed core. Unlike CCv2, where the platform's Java codebase is available for modification, CCE's core commerce services — cart, checkout, content management, product catalog, customer management — are sealed. SAP manages them, patches them, and evolves them continuously.

When I first encountered this model, my instinct — shaped by years of CCv2 implementations — was concern. Where does customer-specific logic live? What happens to the 40 custom extensions a typical CCv2 project carries? The answer is an extensibility framework that's more sophisticated than the "sealed" label implies.

The Extensibility Model: Two Dimensions, Infinite Combinations

What SAP has built in CCE is a dual-axis extensibility model. One axis is depth — from low-code configuration through pro-code JavaScript functions. The other is placement — from on-stack execution (inside the commerce runtime, with high throughput and direct data access) to side-by-side execution (on your own infrastructure or BTP, with maximum freedom of technology choice).

The practical implication for implementation teams: the old mental model of "building a CCv2 extension" needs to be replaced with three new questions. Is this logic changing how a core API call behaves? Use a synchronous extension point. Is this logic reacting to something that happened? Use an async event. Is this a reusable package of functionality? Bundle it as a Plugin.

Commerce Serverless Functions: The Unsung Hero

Of all the technical capabilities in CCE, Commerce Serverless Functions are the one I think is most underappreciated in early partner conversations. These are custom JavaScript functions that run inside CCE's sandboxed runtime, called at defined extension points within core API flows — add-to-cart, checkout, order submission, price calculation.

The elegance here is that this logic runs in-process, with sub-millisecond overhead, and can access the full context of the current operation — the cart, the customer's account data, the pricing conditions — without a network hop to an external service. For the kinds of custom validation and enrichment logic that previously lived in CCv2 Spring beans, this is the successor pattern.

The Plugin System: Packaging for the Long Term

CCE introduces a Plugin concept that I expect will become increasingly important as the partner ecosystem matures. A Plugin bundles one or more extension configurations and serverless functions into a single deployable unit. This means that the accelerator and best-practice logic a partner develops across multiple CCE implementations can be packaged, versioned, and deployed consistently across projects — and even distributed through SAP's Plugin Store.

For our practice, this is a genuine shift in how we think about our IP. Instead of project-specific customization code that lives in a customer's repository and has to be maintained project-by-project, we can build domain-specific Plugins — tax logic, address validation integration, custom pricing rules — that deploy in minutes and travel from implementation to implementation.

Business Data Cloud: The Integration You Don't Have to Build

I want to be transparent about something: for a solution architect trained on integration patterns, the BDC-powered connectivity in CCE initially felt too simple. Where's the middleware? Where's the error queue? Who manages the retry logic?

After working through the technical foundations in depth, the answer is: SAP does. Business Data Cloud handles the replication of all Sales Area configurations from S/4HANA, product master data, customer and business partner data, pricing condition records, and stock and availability — all based on customer-defined filter criteria. This is not an IDoc-based integration you configure; it's a managed data pipeline that SAP operates as part of the product.

The architectural implication is significant: the CCE commerce team does not need to be S/4HANA integration specialists. They need to understand data flow and be able to configure filter criteria — a task that's closer to business configuration than middleware development.

Where We Draw the Line: Honest Limitations

A thought-leadership perspective that only presents the positive side isn't leadership — it's marketing. So let me be direct about where CCE's architecture currently has boundaries that customers need to understand before committing.

CCE is designed for S/4HANA Public Cloud. It is not a fit for on-premise or private cloud ERP customers today. The BDC integration pipeline is built specifically for the public cloud edition, and there is no supported path to connect it to an on-premise SAP ECC or S/4HANA on-premise system. For customers on those platforms, CCv2 with SAP Integration Suite remains the architecture.

Complex pricing and configuration scenarios — variant configuration, highly conditional pricing hierarchies — are on the CCE roadmap (with VCP integration planned for H2 2026) but are not fully available at GA. Customers with extremely complex CPQ requirements may need to evaluate whether CCE's current pricing capabilities meet their needs, or plan for a phased approach.