Marketplacer and Composable Commerce
Composable commerce has been in-market for a few years now, mostly due to a publication by Gartner in 2020 referring to a modular digital commerce approach defined as a composable architecture. While some might say it is a rebranding of a concept called Service Oriented Architecture (SOA) popularized in the 2000s, there is no arguing that it has morphed into one of the hottest topics in the world of eCommerce solution strategy options. So let’s explore how Marketplacer fits into a Composable Commerce Strategy.
If we ask the all-knowing oracle called ChatGPT what composable commerce is, below are the first two paragraphs of the result:
Composable commerce refers to a modern approach to e-commerce architecture that allows businesses to customize their online commerce platform by integrating individual, best-of-breed components, services, and microservices. This approach enables businesses to create a personalized and flexible commerce experience that meets the specific needs of their customers rather than relying on a rigid, one-size-fits-all platform.
The components of a composable commerce architecture include various commerce-related functionalities, such as payment processing, order management, inventory management, product information management, customer service, and marketing automation. Businesses can select and integrate the components that best fit their requirements, and the components can be easily swapped or upgraded as business needs change over time. Interestingly, ChatGPT also took the words composable commerce and returned the answer in the context of a specific architecture, placing it as a technical consideration. In later blog articles, I will explore the business side of composable, but for now, we will stick with the technical side.
It is also interesting to see the references to “best-of-breed” and “components.” Marketplacer is a best-of-breed platform that can service a variety of the components or services that an organization needs to be effective at adding 3rd party product selling into their existing digital commerce experiences. This means that Marketplacer sits slightly below the choice of Composable Architecture, which is sometimes referred to as a “build” style solution,” versus a Monolithic Architecture, which is often thought of as a “buy” style solution. One can take our APIs and UI elements and use the services that make the most sense to their use cases/business processes regardless of an organization’s preferred approach.
The diagram above shows a set of functional core commerce areas serviced by more than one vendor or system in a Composable Architecture. In contrast, the Monolithic Architecture would put all those components inside their wrapper as a single holistic solution. The Composable Architecture approach means each service or component can be adjusted, modified, and scaled independently, while the Monolith needs to do these things as a group. In both cases, the Marketplacer offering would sit below the Core Commerce Architecture regardless of the chosen approach, acting as a set of accessible sub-components or services that the commerce core relies on to fully activate the desired user experience.
In most cases, there will also be some additional sub-systems that sit outside the core commerce architecture. Depending on the capabilities and purpose of each sub-system, they could be composed directly into the user experience, serving the core commerce architecture, or be accessed directly by another sub-system, such as Marketplacer.
When thinking of how these sub-systems interact with each other or the core commerce system, there are two primary integration strategies/methods. They are PUSH and PULL. Neither Composable nor Monolithic architecture explicitly declares that one is more preferred. This is a different discussion that is based on the relative merits of an event-driven architecture. Composable does expressly state that it is based on integrations with multiple vendors/services. Each organization likely needs a mix of integration patterns to allow the strategy to encompass all elements of a viable digital commerce user experience, their specific ecosystem, and each sub-system’s technical capabilities.
It is worth pointing out that Marketplacer supports PUSH and PULL data patterns. We offer a powerful webhooks event-driven PUSH module to augment the traditional PULL/POST-based API pattern. This becomes increasingly important as we expanded the illustration to include some of the other systems that would typically be part of the overall ecosystem and that Marketplacer would need to communicate with to provide our full value when selling and settling transactions that involve 3rd party products. For example, Marketplacer helps ensure that as soon as an order is placed, accepted, or shipped from a 3rd party seller, our event-driven webhooks can notify critical systems like customer service and email/sms platforms to ensure that all are in alignment and that the end customer receives a first-class experience. We aim to fit our solution into your overall ecosystem as it sits today.
Marketplacer also offers a variety of accelerators designed to help connect to Monolithic and Composable focused core commerce platforms as well as to a wide variety of other sub-systems and business partners. This help to lower the risk and speed up time to value when one or more of those systems are present in our customer’s technical ecosystem.
In summary, yes Marketplacer comfortably fits into a composable commerce strategy due to the fact that it is fundamentally a layer below the direct participants in the composition of specific user experiences. We also fit into a Monolithic strategy and all points in between. So chat with us (insert link) and see what we can do to help you grow regardless of your preference.
Established retailers exploring how a marketplace model would best fit into their business strategy have a common question – what’s the difference between dropship and marketplace fulfillment that utilizes third-party sellers, and how can it benefit their business?
The answer is quite a lot.
Dropshipping means different things to different businesses. There are nuances based on type of retailer, existing ecommerce strategy, and whether the products are first-party only, or also include third-party fulfillment.
One customer we worked with had been managing over a hundred third-party fulfillment relationships following a traditional dropship approach. At that volume a marketplace model is the most efficient way to scale through use of technology.
And the good news is dropshipping and a marketplace model are compatible, albeit requiring different approaches based on the needs of your business.
When examining the step-by-step process of traditional dropshipping versus running it through a marketplace technology platform, stark differences start to emerge.
Product Ownership Flips: In a traditional dropship model, legal custody of product ownership transfer happens between the retailer (or operator) and the consumer. In the marketplace model it flips with the product transfer happening between the seller and the consumer.
Seller-controlled pricing: In the traditional dropship supply path there are several manual processes that become automated through direct seller access when sharing a marketplace platform.
For example, with dropship, retailer’s buyers must pre-negotiate pricing with third-party sellers for most products. Doing this at scale can be cumbersome, especially when also having to manage the data entry on the brand’s site. In the marketplace model the pricing side is simplified.
Sellers are on boarded via a commission basis and the seller is responsible for determining product pricing and availability as it appears in the marketplace on the retailer’s website. For example, they can define a manufacturer’s suggested retail price (MSRP) visibility for buyers or shoppers or to indicate to the operator that they don’t want the operator to sell above that limit.
ERP Efficiencies: With dropship, a retailer’s ERP has to be made aware of seller products, inventory and sales. They also must record the cost of goods sold, which affects topline profitability. In the marketplace model, because the platform becomes a data center, it creates less of a need to issue purchase orders through ERP.
The ERP would no longer have to worry about issuing a purchase order and accounts payable wouldn’t have to worry about incoming invoices from suppliers since they no longer have to issue invoices now that operators control payouts via the commission, which is designated into the platform. Instead of supplier issued invoices, here the operator is telling the seller that I am paying you this amount.
Less burden on the retailer: The very nature of a marketplace platform caters to third-party sellers making it easy for them to onboard their products, content, pricing, promotion and discount parameters, and more. With traditional dropship the burden falls on the retailer’s merchandising team to manage product curation and dynamic information. In the marketplace model, third-party sellers take on more management of their inventory.
These are just a few compelling reasons we’ve seen for retailers to scale up third-party fulfillment partners through a marketplace model. Retailers often want to pick and choose which third-party products are being offered and how they are represented on their site, which gives them more control in protecting their brand name and increasing loyalty. It’s increasingly viewed to “test” a category with minimal effort and cost to do so.
Retailers who are exploring a marketplace model can expect a shift in automation and efficiency when connecting with sellers through a marketplace platform. It helps bring on price and inventory, with a faster turnaround that scales, all while delivering a customer experience your brand is proud of.
