Adobe Commerce x CWS Platform: isso deixa o CEO refém de quem?

Nota editorial: comparativo de arquitetura entre Adobe Commerce e a CWS Platform, escrito para quem responde como CEO. Todo fato sobre Adobe Commerce vem da documentação pública dele, com o endereço ao lado.

Ao comparar Adobe Commerce e CWS Platform, a pergunta do CEO não deveria ser apenas qual tecnologia atende ao projeto atual. A decisão estrutural é outra: quando preço, crédito, catálogo, estoque ou processo comercial mudarem, quem terá autoridade e meios para adaptar a operação, o time interno, um implementador, um ecossistema de extensões ou o próprio fornecedor?

Dependência não desaparece com uma escolha de plataforma. Ela apenas muda de lugar. Pode residir no código customizado, na infraestrutura, nas integrações, no conhecimento de especialistas ou na configuração de regras comerciais. O ponto executivo é identificar qual dependência combina com a capacidade operacional da empresa e qual delas transforma cada mudança de negócio em projeto técnico.

A frase de campo “Meus vendedores dizem que o portal vai matar a comissão deles.” revela uma decisão que não é apenas tecnológica: definir se o canal digital será uma loja paralela ou parte da operação comercial. Quando a arquitetura separa portal, vendedor e regras de negociação, a empresa pode depender de adaptações manuais para reconciliar esses canais. Quando os conecta, a mudança passa a ser tratada dentro do próprio fluxo de venda.

O que o Adobe Commerce resolve bem

A oferta documenta alternativas distintas de operação. A modalidade SaaS é multilocatária e recebe atualizações automáticas, enquanto a modalidade PaaS usa infraestrutura dedicada de locatário único. O núcleo concentra transações de comércio e pode ser conectado a outros sistemas por APIs, eventos, webhooks e ferramentas de extensão. Isso coloca parte importante da decisão de dependência na escolha da modalidade e do desenho de integração adotado pela empresa. Veja a descrição das ofertas.

Para empresas cuja autonomia significa acesso ao código, o ecossistema associado oferece uma rota baseada em código aberto, pacotes gerenciados por Composer e contribuições no núcleo. O framework de APIs também expõe serviços por GraphQL, REST e SOAP, com autorização por recurso e declaração explícita dos serviços publicados. Nesse desenho, a liberdade para alterar e integrar vem acompanhada da responsabilidade de manter código, dependências e extensões. Consulte o mecanismo de código aberto.

A arquitetura de múltiplos sites organiza a instância em website, store e store view. Esses níveis determinam o que pode ser compartilhado ou separado, incluindo catálogo, carrinho, checkout, apresentação, idioma e moeda. Para um grupo que opera marcas ou destinos regionais, essa hierarquia oferece um modelo nativo de administração do storefront, mas também faz com que mudanças estruturais dependam do desenho desses escopos. Entenda a hierarquia de sites e lojas.

Na personalização, a entrada pode combinar eventos de navegação, ações de checkout, histórico de pedidos, dados de perfil e informações de back office. O Data Connection envia esses dados para a edge network da Adobe Experience Platform, e integrações com outros produtos da suíte podem formar segmentos e jornadas. O peso arquitetural fica na captura e unificação de sinais para adaptar conteúdo, comunicação, descoberta e oferta. Veja como os dados entram na personalização.

Onde a arquitetura diverge

A divergência começa no significado de autonomia. No modelo extensível por código, serviços são expostos por configuração técnica e mudanças podem envolver pacotes, APIs e componentes de terceiros. Essa abordagem atende organizações que desejam controlar o código e sustentar uma engenharia de plataforma, mas transfere para elas a responsabilidade sobre a evolução das customizações. Leia como os serviços são expostos por API.

Na CWS, o centro de mudança comercial é o Commerce Rules Engine (CDL Workspace). Preço contextual entra pelo Contextual Pricing (Pricing Engine), a negociação assistida passa pela Assisted Selling Platform (Sales Hub) e crédito e aprovações chegam à transação pelo Credit-First B2B Checkout (Checkout & Payments). A CWS Platform tem 11 módulos, 6 AI Agents e 1.029 parâmetros configuráveis. O objetivo desse desenho é permitir que uma alteração de política seja expressa como regra rastreável, com motivo e comentário, em vez de começar necessariamente por uma alteração de código.

A diferença também aparece no escopo operacional. A hierarquia de website, store e store view organiza storefronts e define compartilhamentos dentro da instância, enquanto o inventário permanece associado aos escopos documentados da plataforma. Veja como os escopos são separados. Na CWS, Distributed Inventory (Inventory Hub) coloca o peso no depósito e no SKU, Shipping & Fulfillment (Logistics Engine) calcula alternativas de entrega e Order Management System (OMS / Seller Center) governa o avanço do pedido por regra.

Há ainda uma fronteira clara na personalização. O mecanismo documentado reúne sinais comportamentais e de perfil para alimentar experiências e jornadas, inclusive com dados enviados à plataforma de experiência. Consulte as fontes de dados usadas na personalização. A CWS concentra sua proposta comprovada na personalização comercial transacional: preço acordado, crédito, disponibilidade, entrega e aprovação. Product Catalog & MDM (Catalog Engine) governa os dados de produto.

A documentação da própria Adobe registra dois pontos que pesam nessa dependência:

• limitação registrada na documentação do fornecedor em 18/09/2026: o período transitório só de correções de segurança das versões 2.4.4, 2.4.5 e 2.4.6 é uma exceção única e não será estendido além das datas publicadas ("The security-only transitional period is a one-time exception.", https://experienceleague.adobe.com/en/docs/commerce-operations/release/planning/lifecycle-policy).
• limitação registrada na documentação do fornecedor em 24/09/2026: no Adobe Commerce as a Cloud Service as customizações rodam como aplicações App Builder fora do processo, e refazê-las costuma ser o maior esforço de engenharia da migração ("typically the most significant engineering effort", https://experienceleague.adobe.com/en/docs/commerce/cloud-service/migration/overview).

Para o CEO, portanto, a comparação não produz uma resposta universal sobre dependência. Ela revela dependências diferentes. Uma arquitetura privilegia storefront, ecossistema técnico e extensibilidade por código. A outra privilegia atendimento, negociação e execução de regras comerciais entre módulos. A escolha depende de qual mudança precisa ficar sob controle cotidiano da empresa.

O que muda na operação, pela lente de CEO

Velocidade de mudança não significa publicar código depressa. Significa reduzir a distância entre uma decisão comercial e sua execução segura. Na CWS, o motor de regras pode alterar permissões, aprovações, restrições e critérios comerciais sem transformar cada variação em uma nova customização do ERP. Tirar a regra do código muda a escala do tempo de revisão. Como referência de mercado, a McKinsey documentou um distribuidor de equipamentos pesados em que planos de conta que levavam mais de 10 horas passaram a minutos, e a resolução caiu de 15 minutos para menos de 1 (Five ways B2B sales leaders can win with tech and AI, 2024). O agente de auditoria de regras atua sobre essa camada configurada, enquanto a decisão transacional continua submetida a mecanismos determinísticos.

Essa separação preserva papéis arquiteturais. O ERP pode continuar como fonte de dados financeiros e cadastrais, sem ser forçado a controlar cada interação do vendedor ou do comprador. O motor de preço calcula a condição contextual, o inventário informa disponibilidade por depósito, o checkout aplica crédito e o sistema de pedidos controla transições. A IA pode orquestrar tarefas, mas a plataforma executa preço, estoque, crédito e pedido com dados transacionais, em vez de deixar essas decisões dependerem apenas de um prompt.

A mesma lógica alcança a adoção comercial. O carrinho compartilhado da plataforma de venda assistida coloca vendedor e comprador no mesmo contexto, enquanto Commerce Marketing & Promotions (Marketing Suite) conecta campanhas à condição operacional. No-Code Storefront Builder (CMS Builder) permite trabalhar a apresentação sem deslocar a regra comercial para a camada visual. Assim, a empresa pode tratar o canal digital como plataforma de atendimento e negociação, não como uma loja isolada que precisa ser reconciliada posteriormente.

Esse modelo não elimina a necessidade de fornecedor ou integração. A dependência passa a ser governada por perguntas concretas: quem configura a regra, quem aprova a exceção, onde a alteração fica registrada, quais dados vêm do ERP e qual serviço executa a transação. Para o CEO, essa visibilidade é mais útil do que uma promessa abstrata de independência, porque permite antecipar o custo organizacional de cada mudança.

Quando escolher o Adobe Commerce

A outra arquitetura deve ser escolhida quando a dependência aceita pela empresa estiver alinhada ao seu modelo de engenharia, storefront e operação de infraestrutura.

Quando o requisito central é uma arquitetura nativa de múltiplos sites. Escolha esse caminho quando marcas, idiomas, moedas, domínios e storefronts precisarem ser organizados pela hierarquia de website, store e store view. A documentação mostra como esses escopos compartilham ou separam recursos.

Quando autonomia significa possuir e alterar o código. Esse cenário favorece uma operação que deseja acessar o repositório, trabalhar com Composer, modificar componentes e assumir a manutenção das dependências. O modelo aberto permite contribuições diretas no núcleo.

Quando personalização comportamental é o centro do investimento. Se a prioridade for usar navegação, perfil, pedidos e eventos de checkout para personalizar conteúdo, descoberta e jornadas, a camada documentada de dados oferece um mecanismo específico. Esses sinais podem ser enviados para a Adobe Experience Platform.

Quando infraestrutura gerenciada é requisito de compra. A modalidade gerenciada atribui ao fornecedor responsabilidades de infraestrutura, monitoramento, manutenção, escalabilidade, recuperação e segurança, enquanto preserva responsabilidades do cliente sobre partes customizadas. A matriz operacional está descrita na documentação do serviço.

Por onde continuar

Se a sua pergunta ainda é qual arquitetura serve à sua operação, e não qual fornecedor escolher, o caminho é as sete perguntas que separam as arquiteturas de comércio B2B.

Se o que trava hoje é a dor por trás deste cenário, a página Quando os Canais Brigam Entre Si trata disso em profundidade, sem falar de fornecedor nenhum.