Digital Enterprise Architecture for DTC, B2B & Wholesale (2026)

Many enterprise commerce brands are having two ongoing conversations that rarely intersect. On the one hand, the enterprise architecture (EA) team is focused on capability models, governance frameworks, and multi-year roadmaps aligned with frameworks such as The Open Group Architecture Framework (TOGAF). On the other hand, the commerce team’s focus is optimizing channel conversion, B2B pricing strategy, and buyer experience. 

Both teams are doing their jobs competently, but their decisions don’t always align, and sometimes work against each other. The EA roadmap can constrain the channels commerce needs to run, and the commerce team's tactical workarounds can create integration debt that the EA team eventually has to absorb. The result is an architecture that doesn’t truly suit either team.

This guide maps TOGAF's four EA domains—Business, Data, Application, and Technology—to the specific commerce decisions enterprise brands actually face. It covers the structural gap between EA governance and commerce agility; three architecture models for the most common enterprise patterns; a step-by-step approach to building a migration business case that survives an enterprise resource planning (ERP) steering committee; and the data and application-layer decisions that determine whether agentic AI can operate across your commerce stack.

Why the EA–commerce gap is costing enterprise brands revenue right now

Most EA governance processes were designed for infrastructure programs that operate on 18- to 24-month cycles. Commerce teams, however, often need to ship new checkout flows, B2B account features, and channel integrations on a much faster timeline. By the time a commerce initiative goes through the governance process designed for ERP upgrades, it can be rendered irrelevant by either committee changes or time delays; and in the absence of a timely and effective solution, shadow IT has snuck in a workaround that creates new integration debt. Both outcomes cost revenue; they just show up in different line items.

What channel fragmentation actually costs

Businesses frequently refer to the consequences of channel fragmentation as “technical debt,” but for a commerce business, the term understates the true cost. 

When you run direct-to-consumer (DTC) and business-to-business (B2B) in two separate systems, friction can become a near-invisible norm. Channel fragmentation creates a specific kind of drag: each channel operating on its own codebase and data schema requires its own release cycle, its own integration contracts, and maintenance burden on every shared service.

A price change that should propagate to both DTC and wholesale within minutes can take days when it must pass through four separate integration contracts. A promotional campaign that combines DTC flash pricing with B2B volume-discount logic can become a two-sprint project. A purchase order that needs to commit inventory across both channels requires a manual reconciliation step that sits between the buyer and the confirmation email.

Fragmented tech stacks impose a tax that creates cost and drag across every decision. Worse, the tax compounds over time: Each new channel added to a siloed stack incurs maintenance costs without proportionate revenue gains.

How architecture decisions govern GMV, not just IT budgets

The architecture decisions enterprises make today directly govern conversion rates, channel availability, and order throughput. In other words, architecture affects gross merchandise value (GMV) variables just as much as IT variables.

Research from McKinsey found that ecommerce is the top revenue-driving channel for B2B businesses that have it, outpacing in-person sales. And according to research from Sana Commerce, 79% of B2B buyers say they'd prefer to place repeat orders online. The architecture that lets buyers self-serve and manage orders is therefore a revenue architecture.

The four EA domains mapped to commerce

TOGAF's four architecture domains—Business, Data, Application, and Technology—are well understood by EA practitioners. What the standard framework literature sometimes fails to do is translate them into the specific commerce decisions these domains actually govern. Below we will make some connections to close that gap.

Business architecture

Business architecture defines the organization's revenue model, business processes, governance structure, and capability map. In a commerce context, this is where some of the hardest channel design questions get resolved: 

• Can DTC and wholesale buyers see each other's pricing? 
• Who approves a B2B account above a certain credit threshold? Sales, credit operations, or the commerce platform automatically? 
• Does the self-serve portal replace the relationship with large accounts, or sit alongside it?

Getting business architecture wrong is how brands end up with a self-serve wholesale portal that requires a sales rep to manually approve every order above $5,000; in other words, the type of problem that eliminates the self-serve efficiency for which the portal was built. 

Bedding brand Brooklinen resolved this challenge at the business architecture layer before any technology work began. After migrating to Shopify B2B, their team now spends 80% of their time working directly with customers rather than processing orders. They’re now able to offer B2B and DTC customers the same intuitive, branded buying experience. 

The business architecture layer also governs how pricing logic is structured across channels. Net-30 terms for wholesale buyers, instant checkout for DTC, tiered volume discounts for mid-market accounts—each rule needs to be defined and documented at the business layer before the application layer can implement it cleanly. When these rules aren't governed at the EA level, they end up embedded in custom code that accumulates across releases, resulting in migration liabilities and technical debt.

Data architecture

Data architecture describes how an organization's data assets are structured, governed, and shared across systems. For commerce, the critical design question is whether customer and order data are unified across channels or fragmented.

A brand running direct-to-consumer sales separately from in-store sales typically has two distinct sets of customer data, including purchase histories. A sales rep checking an in-store customer’s purchasing history might not even be able to see what they’ve purchased online. Similarly, a personalization engine that tries to serve a customer a relevant experience on either channel works with incomplete data by design.

The practical consequence is that data architecture decisions made at the platform selection stage determine which AI-driven capabilities are feasible and at what cost. A unified data architecture is the prerequisite for most advanced commerce capabilities. Brands that treat data architecture as a post-migration cleanup task often discover, after go-live, that the AI roadmap they planned requires an additional data-integration project to execute.

Application architecture

Application architecture covers the blueprint for individual systems, their interactions, and their relationship to business processes. For commerce, this is where the composable-versus-monolithic trade-off lies, and where the consequences are often most commercially direct.

A monolithic platform ships all capabilities in a single release cycle. Changes are slow, upgrades carry risk, and integrating new capabilities often requires modifying core commerce logic rather than connecting an independent service. A composable or headless architecture decouples the front end from back-end services, separates checkout and catalog logic from presentation, and lets teams deploy and iterate independently across services.

But there is a trade-off. Composable architectures require mature API governance, disciplined integration testing, and engineering teams with experience managing service dependencies under load. For brands without that operational maturity, composable approaches can create a new category of integration maintenance. 

The right application architecture decision depends on team capabilities, timeline constraints, and the specific channel combinations the business needs to run simultaneously.

Technology architecture

Technology architecture describes the infrastructure, including hardware, software, and network, that supports application deployment. In enterprise commerce, this includes content delivery network (CDN) configuration, API gateway design, cloud infrastructure contracts, and ERP integration patterns.

The ERP-integration layer is where many enterprise commerce projects stall. A platform implementation plan that doesn't account for how the new commerce layer integrates with the existing ERP—whether through maintained connectors, middleware, or direct API contracts—creates a second project that can double implementation timelines. ERP-integration complexity is frequently underscoped in the discovery phase, too, because it sits at the boundary between the commerce team's accountability and the IT team's accountability, and each team often assumes the other owns it.

The right technology architecture for enterprise commerce establishes stable API contracts at the ERP boundary, so commerce-layer changes don't cascade into ERP reconfigurations. This pattern also future-proofs the stack: new channels, storefronts, and AI integrations can connect to the commerce platform without renegotiating the ERP integration contract for every deployment. That stability is what lets the commerce layer move at commerce speed while the ERP moves at ERP speed.

Commerce architecture in practice

The three models below map the four EA domains to the actual decisions that can define success or failure for the most common enterprise architecture transitions. Each follows the same logic: Start with the business architecture decisions, work down to the data and application layers, and establish the technology architecture—particularly the ERP integration layer—before any storefront goes live.

DTC-first brand adding B2B self-serve

When a business with an established DTC channel wants to open a wholesale self-serve portal without fragmenting the tech stack or creating a second customer data model, the temptation may be to treat the B2B portal as a separate project with its own codebase; but that decision creates the fragmentation tax described above from day one.

Each EA domain contributes distinct decisions to this model:

• Business architecture: Define the account model before touching any technology. Resolve price visibility by explicitly including catalog-level price lists for wholesale and DTC promotional pricing, both of which need to be isolated by channel without manual intervention. Decide whether the portal complements or replaces rep-assisted ordering, and what approval thresholds trigger human review.
• Data architecture: Ensure wholesale account data writes to the same customer data platform as DTC. Order history, inventory commitments, and account-level payment terms must be accessible from a unified administrative interface, or the self-serve efficiency gains will be offset by manual reconciliation on the back end.
• Application architecture: Run both channels from a single commerce platform with channel-specific storefronts that share catalog, inventory, and pricing services but operate separate checkout logic. This prevents two independent catalogs from diverging over time.
• Technology architecture: Map the ERP integration changes before go-live. B2B adds net-term invoicing, purchase order handling, and more. These integration contracts need to be designed and tested at the technology architecture layer before the storefront launches.

AMR Hair & Beauty, for example, followed a version of this pattern when they transitioned from WooCommerce to Shopify B2B. When they migrated, they fixed their search and filtering options in their added B2B arm, which led to a 77% rise in B2B average order value (AOV).

Wholesale-led business launching DTC on the same stack

In this case, a manufacturer or distributor with an established wholesale business wants to add a direct-to-consumer channel without rebuilding its existing infrastructure. 

The architectural challenge here runs in the other direction: the platform is optimized for bulk orders, account-based pricing, and sales relationships. Meanwhile, the DTC channel needs consumer UX, promotional pricing, and individual-order handling, which could disrupt wholesale operations if deployed without careful channel isolation.

Data architecture is the first domain to resolve. Wholesale and DTC inventory pools need defined governance rules. They should either be shared (operationally simpler but risky during peak demand periods) or segmented by channel (more complex to manage but lower risk of overselling committed wholesale inventory). 

Application architecture determines whether the DTC storefront shares wholesale checkout logic or runs a separate front end with shared back-end services. Separate front ends with shared services are often preferable because they allow independent UX optimization for each audience without coupling DTC and wholesale release schedules. That way, a DTC promotional feature doesn't require a regression test across the wholesale order flow.

For example, Russell Hendrix, a food service equipment supplier, built B2B capability on the same Shopify stack as their existing DTC operation after migrating from a custom-built platform. This move resulted in a 24% increase in revenue, a 43% increase in B2B online order volume, and a five times improvement in order processing speed for sales reps.

Multi-brand enterprise unifying disparate storefronts on a single platform

A brand portfolio running multiple storefronts on different platforms can run into issues when they decide to consolidate: each storefront has accumulated its own technical debt, its own integration contracts with different API versions, and its own data schema. Consolidating onto a single platform reduces total cost of ownership (TCO) and creates a shared services infrastructure, but the details of the migration determine whether the project delivers commercial value or adds more integration complexity than it removes.

The governing architecture principle for this model: migrate shared infrastructure first, brand-specific storefronts second. Shared services, including payment processing, tax calculation, and CDN, should be fully operational on the new platform before the first brand storefront goes live. Each brand migration then lands on a proven foundation rather than a work-in-progress integration layer that may still be developing when the next brand cuts over.

For example, Carrier, a building and cold-chain solutions provider, adopted this discipline after migrating to Shopify. They cut the time to launch new ecommerce experiences from 9–12 months on the previous platform to 30 days on Shopify, and reduced the per-website cost from up to $2 million to $100,000. 

Building the internal business case for replatforming

Replatforming is not always an easy sell to the C-suite. It’s often expensive and difficult, and stakeholders often prefer to stick with what’s familiar. The key is to frame replatforming as a digital enterprise architecture decision rather than a website project. This framing starts a fundamentally different conversation with a finance committee than one that just focuses on a features comparison table. 

Quantifying the inaction tax

The inaction tax is the compounding cost of maintaining the current architecture—combined with the cost of missing out on the opportunities that an upgrade can deliver. Quantifying it requires working through four cost categories that together tell the full story.

• Integration maintenance: A team routing much of its engineering capacity through integration maintenance rather than feature development pays an inaction tax on every sprint. This cost is often invisible in project planning because it's absorbed into ongoing operational overhead rather than attributed to the legacy architecture that creates it. 
• Conversion gap: An independent consulting firm that studied the total cost of ownership across major commerce platforms found that Shopify's checkout conversion rate averages 18% higher than those of major competitors. On a $200 million revenue base, that gap represents roughly $36 million in recapturable revenue annually, a figure that belongs in the business case as a cost of inaction rather than a projected gain.
• Manual process cost: Composable commerce with integrated ERP pricing logic replaces the manual calculation and confirmation steps that create legacy drag, potentially recovering deals that currently stall in the quoting queue.
• AI deployment lag: Two-thirds of B2B buyers now use generative AI tools as much as or more than traditional search, according to Responsive research. A brand whose architecture can't support AI-driven content and pricing appears less frequently and with reduced relevance during that discovery phase. That's a cost that compounds quarterly as buyer behavior continues to shift.

These examples show how organizations can model the cost of staying on legacy architectures. You need to account for ongoing costs, as well as the costs of opportunities you can’t pursue. 

Navigating ERP-centric IT culture

In many enterprise organizations, the ERP is the system of record and the center of IT governance. Commerce platforms are funded and staffed as satellites around it. This positioning often creates a governance structure that applies ERP-level change-management processes to commerce initiatives that need to move at a different cadence.

Commerce is the revenue layer, not the website layer. The ERP manages inventory, financials, and logistics. The commerce platform manages buyer experience, conversion, and channel economics. Running both under the same governance process creates friction on the commerce side that shows up as slow feature delivery and integration-maintenance overhead.

Presenting the replatforming initiative as an EA project can address the core concern of ERP-centric IT stakeholders. Don’t make the argument that the ERP needs to change. Focus on the fact that the commerce layer needs to be architected to support the ERP integration patterns the organization already relies on, while giving commerce teams the autonomy to operate at commerce speed. If stakeholders still aren’t convinced, talk about the potential revenue your selling team can bring in when they aren’t hamstrung by self-limiting tech.

Sequencing the migration

The wrong migration sequence can put live revenue at risk and give stakeholders the impression that the migration is unstable. The right sequence protects revenue while creating early proof points that build confidence across governance committees.

The best sequence tends to follow EA domain logic in three phases:

• First, establish the technology architecture foundation. Stand up the new platform's infrastructure, configure and validate ERP integration contracts, and confirm payment processing and tax calculation work correctly before any storefront goes live. 
• Second, migrate the highest-volume, lowest-complexity storefront (often a DTC one). This stress-tests the infrastructure under real load with a well-understood traffic profile. A successful migration demonstrates that the integration layer works and provides IT stakeholders with a live reference point.
• Third, migrate B2B after DTC is stable. B2B carries more complex business logic and higher per-order revenue, making it a higher-risk channel to migrate to an unproven integration layer. 

By prioritizing the foundation and migrating a low-complexity storefront first, teams can confidently run a second migration and further prove the value of the migration as a whole.

Agentic AI as an architecture decision, not an afterthought 

Agentic AI systems can take autonomous, multi-step actions across tools and data sources. In recent years, the tech has moved from roadmap item to architecture decision with immediate commercial consequences. 

The data and application layer choices that enterprise brands make now determine whether AI agents can be deployed effectively across the commerce stack, or if each new AI capability requires a custom integration project to function. Organizations can position themselves well by working with platforms aligned with this urgency. 

Shopify invested $1.4 billion in R&D in 2024 alone, reflecting the platform's direction: AI capabilities are infrastructure-level investments, meaning the brands that benefit are those whose architecture is already prepared to consume them.

Where AI agent orchestration sits in the four-domain model

At the business architecture level, agent-governance boundaries must be defined before deployment. Which workflows should agents own autonomously, and which require human approval? These governance rules belong in business architecture documentation, not in agent configuration files that get updated ad hoc.

At the data architecture level, agents need access to unified, well-governed data to function. An agent reading DTC purchase history but blocked from B2B account order history can't generate a coherent recommendation for a buyer who purchases across both channels. 

At the application architecture level, composable architectures with well-defined APIs are significantly more AI-ready than monoliths. An agent that can call a pricing API, a catalog API, and an inventory API independently and compose those calls into a complex action without touching core commerce logic can automate workflows that would be impossible to orchestrate through a tightly coupled platform.

At the technology architecture level, agent deployment requires infrastructure that supports low-latency API calls, event-driven triggers, and reliable session state management. These aren't novel infrastructure requirements, but they need to be considered explicitly when designing the technology architecture layer.

Commerce use cases: Storefront personalization, B2B pricing engines, and order automation

Three use cases tend to produce clear commercial value for AI agents in enterprise commerce.

Storefront personalization: An AI agent can observe real-time browsing behavior, cross-reference purchase history, and update product recommendations and merchandising rules without human intervention. The technical prerequisite is unified customer data and a composable front end that can render personalized content without a full-page rebuild on every request, which is an application architecture requirement.

B2B pricing engines: An AI agent can automate pricing by applying contract-level rules, volume tiers, and promotional conditions in real time without requiring a sales rep to confirm the quote. This capability removes the primary barrier to self-serve at high order values, but it requires a data architecture that surfaces contract pricing and inventory together, not across two separate system calls.

Order automation: AI agents can monitor open orders, flag exceptions, and trigger reorder workflows based on inventory thresholds. Businesses that transition to Shopify B2B see up to a 33% increase in self-serve orders within six months of onboarding, according to Shopify platform data, and up to a 4.1-times increase in reorder frequency compared to DTC orders. Those figures reflect the structural advantage that composable architecture with automated reorder triggers creates for B2B revenue consistency, independent of AI. Adding agent intelligence to the same foundation further extends the advantage.

Why data and application architecture decisions made today determine your AI readiness tomorrow

A brand with different schemas across DTC and B2B, inconsistent product identifiers across the product information management system (PIM) and the commerce platform, and order history distributed across three systems cannot deploy AI agents without first remediating the data architecture underneath them. That remediation becomes the first phase of every AI initiative, adding 6 to 12 months of infrastructure work before the AI product work itself can begin.

A Lucidworks study found that only 31% of B2B organizations have deployed both core and advanced AI capabilities that measurably improve customer experiences, compared to 41% of B2C companies. Especially as models commoditize, the gap is more the result of infrastructure than sheer model capability. B2B commerce architectures tend to be more fragmented, with greater legacy ERP dependencies and older integration contracts, making AI deployment harder even when the business case is clear.

Choosing a composable commerce platform: The EA selection criteria

Platform selection is an EA decision with commerce consequences that play out over a long time horizon. A platform that scores well against a features checklist but doesn't map cleanly to the organization's four domain requirements will generate new architecture debt rather than retiring old debt. 

Evaluating platforms against all four EA domains simultaneously

The most common platform evaluation mistake is treating application architecture as the primary selection criterion while treating data, business, and technology architectures as implementation details to be resolved after the decision is made. By the time those domain gaps surface, the contract is signed, and the implementation has started.

A rigorous evaluation scores each platform against all four domains at selection time:

• Business architecture fit: Can the platform support the required revenue model complexity out of the box, or does it require custom development to support net-term invoicing, tiered pricing, and multi-user B2B accounts with role-based access? 
• Data architecture fit: Does the platform provide a unified data model for customer, order, and inventory data across DTC and B2B channels natively, or does operating both channels requires a separate data-integration project to maintain consistency?
• Application architecture fit: What does API governance look like, and how are changes managed across versions? An unstable API surface creates integration maintenance that the composable migration was supposed to eliminate.
• Technology architecture fit: What does the ERP integration story look like for the ERP the organization currently runs? A platform with maintained, tested integrations for the existing ERP is structurally lower-risk than one that requires custom middleware at the most critical boundary in the stack. 

Some dimensions are often underweighted in evaluation processes because they require input from IT rather than commerce, or vice versa, and the two teams rarely sit in the same evaluation sessions. Bring them together to ensure you’re making the right decisions. 

The implementation reliability dimension

Platform capability evaluations sometimes overlook implementation reliability—the likelihood that the project will land on time and on budget, without disrupting live revenue. 

An independent consulting firm's research found that Shopify's total cost of ownership is, on average, 33% better than major competitor platforms, driven by lower platform costs, lower operating costs from reduced integration complexity, and a higher-converting checkout that offsets ongoing cost comparisons.

The implementation timeline data tells a consistent story across case studies. Carrier launched new ecommerce experiences in 30 days after moving to Shopify, compared to the 9–12 months required on their previous platform. And home brand Industry West recorded a 90% lift in B2B web order revenue and a 20% lift in average order value after implementation.

Every month a brand stays with constrained legacy architecture compounds the inaction tax. Conversion gaps accumulate, manual process costs continue, and AI capabilities that could be deployed on a composable stack remain out of reach. An implementation that completes three months faster is one that earns three months of recovered revenue momentum and three months less inaction tax.

From architecture diagram to commercial outcome

Digital enterprise architecture, applied to commerce, provides the opportunity to connect an architectural decision to a commercial outcome with a measurable value. That connection is what turns a replatforming proposal from a technology project into an investment plan.

The architecture conversation and the revenue conversation are the same conversation. The EA framework just makes that connection visible. For commerce organizations, translating that conversation into specific platform decisions and migration priorities is what distinguishes an IT project from a growth-enabling digital transformation.