Blog
How to expand your Dynamics 365 commerce footprint
and make it easy for your business
Although Dynamics 365 Commerce offers one of the most comprehensive retail solutions on the market, replacing a number of business-critical workloads at once might not be the best option for your business. However, using the built-in headless commerce capabilities, it is possible to expand your Dynamics 365 Commerce footprint at your own pace. In this article, we will showcase proven patterns on how Dynamics 365 Commerce could co-exist with your existing system landscape, providing flexibility through a composable architecture
Dynamics 365 Commerce – Architecture scenario’s
Using the headless commerce capability provided by Dynamics 365 Commerce, we can expose business logic and data across available sales channels providing a seamless omni-channel experience, while still leveraging a single-source-of-truth. Below are four proven patterns demonstrating various degrees of Dynamics 365 Commerce utilization:
Option 1 - Commerce all-up
In option 1, we utilize the entire stack of capabilities provided by Dynamics 365 Commerce. We offer an end-to-end solution across customer touch points and back-end processes, limiting the need for custom development- or integration requirements towards legacy systems.
Example: Sales channels and corresponding assortments, pricing, and promotions are configured using the Headquarters- module. Relevant master data is distributed across available sales channels. Sales- and marketing-related content is managed by the Site Manager (CMS) and then exposed to the Storefront (Ecom front-end) and physical stores (Store Commerce App). Payments are reserved and captured using a standard Adyen connector (PSP). D365 SCM processes retail transactions for order fulfillment, which D365 Finance then manages for general ledger posting.
Using this option, we maximize the utilization of the Dynamics 365 Commerce investment. At the same time adopting a large number of new system components at once consequently drives training- and change management efforts.
Option 2 – Third party CMS
In option 2, we decided to keep our existing content management system to enrich products with marketing- and sales-related attributes. One could imagine that significant investments have been poured into the current solution, such as licensing, training, and application maintenance plans, which justify the selected pattern.
Example: Product-based data such as ID, name, and description are created in Dynamics 365 SCM/Commerce and then published to CMS. Product enrichment activities such as translations, text, and graphical images are added using the CMS interface. Once product readiness is completed, the products are published towards applicable sales channels.
Using this option, we leverage the headless commerce capabilities of Dynamics 365 Commerce through available Retail Server APIs: s to communicate with an external CMS. Still, we maintain a consistent approach to maintaining product-related master data.
Option 3 – Third party Storefront and CMS
In option 3 we keep our existing tools for providing a rich customer experience across our digital channels using a third-party Storefront- and CMS solution. Key drivers for this option could be significant prior investments in the current technology stack but with the need to simplify maintenance- and to improve data quality.
Example: Master data and business logic are exposed by Dynamics 365 Commerce towards third-party CMS- and Storefront solutions. The customer journey is managed using external tools, although the entire checkout and cart control are managed by Dynamics 365 Commerce, providing a single-source-of-truth.
Using this option, we cater to a best-of-suite approach providing a flexible solution across Dynamics 365 Commerce and legacy workloads, still ensuring consistent data and business logic.
Option 4 – Third party Ecom platform
In option 4, we adopted a best-of-breed approach where an existing Ecom platform had already been implemented, providing a rich set of capabilities across both back-end and front-end touchpoints. Common for this approach is a global strategy where an e-commerce platform has already been selected for the entire organization and should now be implemented across all markets. Pursuing this option, we are mainly interested in integration patterns using Dynamics 365 Commerce.
Example: Master- and Transactional data are synchronized between Dynamics 365 Commerce and third-party Ecom solution. Business logic and data are duplicated across both systems, increasing development- and test efforts when introducing new features.
Using this option, we provide a standardized mechanism for scaling and exposing Dynamics 365 Commerce data using the Retail Server API. All data and business logic are then duplicated across both systems.
Summary
Adopting Dynamics 365 Commerce could be performed gradually, limiting the impact on the business and still ensuring legacy applications are utilized efficiently. In this article, we have explored a number of “Architecture Scenarios,” showcasing different levels of Dynamics 365 Commerce’s “footprint.” Each option provides different pros- and cons and hence needs to be put into a customer context to support any business decision process.
Contact us for advisory
Are you in need of advisory for determining whether Dynamics 365 Commerce provides a good fit for your organization? We have a vast experience on the topic. Don’t hesitate to contact us at contact@engagenow.com for further information.
Written by:
Tobias Lång
CTO
Head of Advisory services
