Your CIO has mandated integration with a new CRM system, but your current commerce platform treats external connections like unwelcome intruders. Your sales team is frustrated by an e-commerce system that takes weeks to implement simple pricing changes. Your team manually places orders over the phone because your checkout process feels like navigating a maze from the 1800s. When they push your customers to try it, the cart abandonment rate is so high it can dance with the clouds.
If any of these problems sound familiar, take heart. Modern e-commerce for the enterprise, especially for B2B applications, has evolved to meet your customers’ rising expectations.
You don’t have to do things the old way anymore. Just because you’re stuck using a legacy ERP system doesn’t mean you have to stick with a rigid shopping cart solution designed in 2004.
The Evolution of Enterprise Commerce Architecture
We've witnessed a fundamental shift in how enterprises approach commerce technology.
The monolithic era
The prevailing wisdom was simple: find a platform that promises to do everything and commit fully to it. Platforms like Oracle Commerce, Hybris (now SAP Commerce), and even early versions of Magento Enterprise positioned themselves as complete solutions. One vendor relationship. One support contract. One system to train your team on. The appeal was obvious.
But "complete solutions" often mean complete compromises. Want to integrate with your existing ERP? That'll require expensive middleware. Need custom order and fulfillment workflows? Hope you're comfortable with the vendor's interpretation of how your business should operate.
As business strategist Michael Girdley put it, 85% of any business “tastes like chicken.” Their processes look similar, and they have straightforward requirements. A monolithic system (if the right one was chosen) could work fine.
But for businesses digitizing complex B2B processes for the first time, or those with unique industry requirements, the constraints quickly become suffocating.
Headless and decoupling for flexibility
The rise of JavaScript frameworks and API-first thinking sparked a wave of decoupling. This push was inspired by the question: Why force your customer-facing experience to be constrained by your backend commerce logic?
Headless architecture allowed companies to build beautiful, fast front-end experiences while maintaining the business logic and integrations they needed on the backend. The same commerce engine could serve multiple use cases and/or front-ends. The customer experience could be modernized without doing a complete overhaul.
The headless movement did something else crucial: it forced platform developers to think API-first. We worked on improving Drupal Commerce's headless capabilities, and the process of making our APIs more robust actually strengthened the platform for everyone. Even those who didn’t need to use the APIs. When you design systems to be consumed by external applications, you naturally create more modular, testable, and reliable architecture.
Composable commerce
Today's composable commerce represents the maturation of both monolithic and headless thinking. It allows you to assemble the best tool for each job while maintaining seamless integration between components. You compose your own commerce solution. For example, you might combine a commerce engine like Drupal Commerce with a specialized search service like Elasticsearch, a dedicated PIM system to power the product catalog, and a marketing automation platform.
All selected based on your unique set of requirements. Rather than squeezing your proven workflows into someone else's software mold, composable architecture adapts the technology to your processes.
The technical debt of legacy B2B commerce systems
If your commerce platform was implemented more than ten years ago, you're likely experiencing some combination of these pain points:
Integration nightmares and data silos
Legacy platforms often treat integration as an afterthought. We've seen too many implementations where the "solution" to ERP integration involves nightly batch files, manual data entry, or expensive middleware that breaks every time either system updates. The whole tangle is a business continuity risk.
Modern B2B buyers expect real-time inventory information and instant pricing based on their contract terms. They want to trust that the item they are buying is available and that the price they are seeing on the screen is correct.
The customization trap
We’ve seen companies implement a "standard" B2B platform, then spend months customizing it. Pricing rules, order approval workflows, product configurations, CRM syncs, and more. Two years later, a major platform upgrade breaks half of their customizations.
This happens because many platforms weren't designed with deep customization in mind. They have APIs, but those APIs weren't built to support the complex data relationships that B2B businesses require. Middleware must be created. Or applications that drape over a platform and clumsily insert data into existing data structures. All of this makes for brittle features that are expensive to maintain.
Performance Under Pressure
B2B commerce puts unique demands on system performance. Not necessarily traffic volumes (though that does happen), but things like:
- Complex searches across millions of SKUs
- Real-time pricing calculations involving multiple contract terms and volume discounts
- Checkout processes that handle re-orders, multi-line quotes, and branching logic.
Many legacy systems aren’t architected for this complexity. The process has to live in a series of spreadsheets, increasing the risk of user error.
Adding more servers doesn't help when the fundamental database queries are inefficient, or when the platform's caching strategy wasn't designed for the dynamic content that B2B sites require.
A penalty for innovation
Perhaps the most frustrating limitation of legacy systems is how they penalize innovation.
Want to add a new payment method? That's a major integration project.
Need to support a new product type with different attributes? Maybe that’s a hard “no” because the platform’s data model is too rigid.
Want to experiment with personalized product recommendations? You'll need to evaluate whether the platform can even expose the data your recommendation engine needs.
Iterating quickly and with a reasonable budget is a competitive necessity. Companies that can't adapt their digital experiences fast enough will find themselves outmaneuvered by more agile competitors. Gartner predicts organizations reusing composable modules will increase digital innovation speed by 60% by 2026.
Why composable commerce makes sense for B2B
Composable commerce isn’t a trend, though the name itself might be. Rather, it’s a strategic response to the realities of modern B2B commerce. Here’s why it works so well:
- Deploy components independently. Need better search? Swap in Elasticsearch without touching your checkout. Want to test a new pricing engine? Build it as a microservice. Each component can be implemented and updated on its own timeline, reducing risk and accelerating value delivery.
- Integration-first design. Every component communicates through APIs, enabling real-time data flow between your commerce platform, ERP, CRM, and other systems. No more batch files or manual synchronization.
- Future-proof flexibility. When new requirements emerge, you add or swap components rather than replacing your entire platform. Your architecture evolves with your business.
- Transparent cost structure: Pay for what you use, upgrade on your timeline, and avoid vendor lock-in. If you use open-source components, even better. You have options when providers change pricing or discontinue features.
We've seen this work firsthand when building a headless Drupal Commerce solution for a Fortune 50 company. They could deploy our custom JavaScript library across multiple brand websites in weeks, all powered by disparate website platforms and content management systems.
What a modern B2B commerce stack looks like
Let’s walk through some typical components of a composable B2B commerce stack.
The commerce engine
The heart of a composable stack, it handles the core commerce logic like cart management, orders, and customer accounts. Think beyond just a shopping cart. It’s an orchestration layer between other systems.
Drupal Commerce excels in this role because it was built modular from day one. Unlike platforms that bolted on APIs as an afterthought, every piece of commerce functionality in Drupal is exposed through APIs and can be extended or replaced without touching core code. While platforms like Shopify offer an API, you can't actually modify the core data architecture.
Content management
B2B buyers need rich content alongside commerce, including technical specs, compatibility guides, and implementation documentation. Marketing teams need agility to create landing pages and supporting content. Some platforms require you to bolt on a separate CMS for basic functionality, and even then, there’s no easy two-way communication.
Drupal's native content-commerce integration means your product catalog can seamlessly include everything from basic specifications to detailed case studies, all managed in one system with consistent data relationships.
Search and discovery
B2B catalogs require complex search. Customers need to search by part number, application, specification, compatibility or by some other attribute unique to your business. A composable approach lets you use specialized search services while maintaining integration with your commerce engine.
ERP and CRM integration
Your website needs real-time connection to back-office systems for inventory, pricing, and account management. When your ERP integration requires custom data structures and relationships, you need a platform that can adapt rather than force workarounds.
Front-end flexibility
Your field sales team needs mobile quick-order interfaces, while customers need self-service portals with integrated documentation. Shopify's themes and apps provide some customization, but you're ultimately constrained by their platform decisions.
And do you really want the Shop Pay app to automatically cross-sell your competitors' products to your customers?
Authentication and identity
Some B2B commerce requires complex authentication. Not just "who is this person," but "what accounts do they access," and "what approval workflows apply." Drupal’s user entities and permissions are flexible enough to handle the most complex requirements, and they can be swapped out with other identity providers.
You might also already have a single sign-on solution and want your commerce platform to use the same. Composable commerce helps make this a reality.
How Drupal Commerce aligns with modern architecture
We built Drupal Commerce to slide into the composable commerce paradigm. To meet the needs of modern B2B commerce architecture. Modular by design, it can be made to fit any scenario. If you’re missing a piece of the puzzle, Drupal Commerce is ready to align so well with your business goals that it clicks into place without any major contortions.
- API-First from Day One - Every entity, workflow, and piece of business logic is accessible through APIs and can be extended without touching core code. Use it as a complete solution, a headless backend, or an integrated component in larger stacks.
- Native B2B Complexity - Account hierarchies, role-based permissions, complex pricing rules, and approval workflows aren't expensive add-ons. They're part of the core architecture. Built for the organizational complexity that makes B2B different.
- Content and Commerce Integration - While other composable approaches require separate CMS and commerce systems, Drupal natively combines rich content management with commerce functionality. Your product catalog seamlessly includes specifications, case studies, and educational content.
- Open-source Flexibility - When requirements change, you can customize, extend, or even fork components. No transaction fees, no competitor cross-selling, no artificial constraints on your data architecture.
Plan for the Long Term
Composable architecture is particularly powerful for companies that can think strategically. Rather than asking "what platform will solve all our current problems," the better question is "what architecture will let us solve problems we don't even know we have yet?"
What can help us develop emergent features and improve processes that we didn’t even know could be improved? You want business agility, not just technology.
Long-term thinking will also influence your team structure and vendor relationships. Companies that embrace composable architecture tend to invest more in their internal technical capabilities and eventually become less reliant on a single vendor's roadmap.
An agency partner still brings value by training your team, providing best practices consultations, and helping you solve the thornier problems. When technology adapts to your business instead of the other way around, everything changes. Your team moves faster, your customers get better experiences, and your business becomes more resilient to whatever comes next.
Add new comment