Oracle Retail Blog helps retailers stay current on customer successes, hot retail trends and industry best practices.

Demystify the Business Value of the Complete Commerce Platform

Ananda Chakravarty
Director, Retail Omnichannel Strategy

Retailers are being pressed towards modular, piecemeal solutions, such as microservices, headless, and best of breed solutions for enterprise commerce. Why? Because they seem cheaper to buy, smaller to implement, faster to roll out, and have less dependency on a single vendor. The retail customer experience, however, doesn’t match this technology trend as the customer seeks a holistic experience and could care less about the retailer’s infrastructure. 

Myth vs. Reality

Integration and weak links in design show that insulated modular components cost more. Smaller implementations must scale across enterprise applications, but don’t have the flexibility to do so holistically. Speed comes to a standstill as integration must be mapped by system architects with exponential system complexity proportional to the number of services. Dependency on a key vendor becomes a lifeline rather than an encumbrance.

However, vendors of modular tools continue to propagate a series of myths that undermine the value of the Complete Commerce platform, End-to-End (E2E) Commerce platform, Unified Commerce platform, or All-In-One Commerce platform. The concept of headless commerce is not exclusive and the best modern commerce platforms offer hybrid headless capabilities where you can select a fully headless model or use the fully functional incumbent front-end. There’s a place for microservices and headless as part of robust, expansive engineering teams where the business is optimizing IT, but usually retail doesn’t have the resources or the need to push such dramatic organizational change and dependency on IT teams. 

Let’s take a deeper dive into each of the top myths:

Myth # 1 – The Complete Commerce Platform is inflexible because it’s dependent on native, deeply integrated application components. 

Complete Commerce Platforms provide enormous flexibility. Why? Because the best commerce platforms use API-first technologies. API-first, cloud computing, and customer journey mapping are not exclusive to microservices and headless. Complete Commerce goes further by providing a complete solution – major gaps are covered by the commerce platform, whereas headless systems need additional support pieces and front-ends to fill in these gaps.

Complete Commerce maps to the customer need across the entire customer journey, not only the functionality of the applications. There’s a reason why all the major commerce vendors are in acquisition sprees picking up pieces of software to flush out their solutions.

Myth # 2 – Headless Commerce offers more flexibility because it decouples the commerce engine front and back ends

The concept of completely decoupling different parts of a commerce system is patently false. To transfer data and information, all applications must have some sort of coupling or handling of data – either in the front-end, back-end or some sort of middleware. Even the API is an Application Programming Interface – across multiple system parts. API’s are part of the coupling process and enable disparate parts of a software system to communicate with each other. The more you limit application functionality, the more applications you will need. These applications must connect to perform the broader functionality, increasing complexity. This means more testing, more training, more development, and higher costs to make changes.

The customer doesn’t care about the design, architecture, infrastructure, or elegance. They care about performance and functionality. It’s called integration and it doesn’t just vanish because you break apps into smaller functional pieces.

Myth # 3 – Complete Commerce Platforms can’t scale. 
Only holistic Complete Commerce Platforms can scale, they’re not slowed down by the weakest services or weakest link. Most of the retail world is already shifting to cloud services and the challenge of versions has already been addressed. According to Gartner, “Demand for on-premises (traditional hosting) has almost disappeared… new implementations are almost always in the cloud”. This means updates and continuous improvement in software products are built into the cost of smart Complete Commerce cloud services. Commerce platforms reduce costs further by having full-service options be part of the continuous updates instead of on a per function, feature, or specialized application basis.

Headless-only and microservice-based commerce applications are operating on their own roadmaps causing the weakest link to define the progress of the entire system. An upgraded front end buy-online-pickup-instore (BOPIS) interface will be useless until the back end is also upgraded to handle fulfillment of the customer journey.

Myth # 4 – Complete Commerce Platforms are more expensive. 
Complete Commerce spreads cost over the complexity of enterprise-grade commerce delivery. The fact is that Complete Commerce has already built-in the contingencies and integration issues retailers need to address anyway. Complete Commerce provides retailers with more than just the pieces, but also the complexities of the dozens of customer journeys that the average consumer can execute when engaged on retailer sites.

Innovation for Oracle’s Commerce Cloud, for instance, is tied in with regular releases multiple times per year, with strong backward compatibility with previous versions. Retailers are able to stay current with the most modern architecture across all of their end-to-end applications, not just select ones purchased. All the new features and functionality are automatically uploaded into deployments which can be as little as a few hours for new updates to go live. Headless vendors encounter disconnects, operational gaps, learning issues by admins, and a learning curve for end users for new functionality or new apps that are mapped in.

Myth # 5 – Retailers are paying for unnecessary commerce tools. 
Retailers must think differently about cloud services than the old on-premises model. Retailers are purchasing a subscription to use what they need when they need it. It’s the difference between taking a Lyft or buying a car that sits in a parking lot. The marginal cost for the retailer implementing new services is tied to support and usage, not maintenance or product IP. The cost of the service doesn’t change regardless of the decision to use any or all of the commerce platform functionality.

A key advantage of the modern Complete Commerce Platform is the design towards growth. Retailers start with full but flexible functionality, allowing new feature adoption at their own pace. Complete Commerce enables a migration path as retailers build, buy, partner or use the incumbent tools so planning becomes a matter of priority, not of constraints. Retailers can start with inherent features like A/B testing, search, or a BOPIS interface and swap them in with API-based solutions on their priority schedule. The service remains a usage-based cost.

The headless/microservices model for architectures will be valuable to retailers that are looking to build solutions from scratch or piecemeal replacement where complexity is already part of the problem. This narrows the market significantly and drives microservices out of larger retail markets. In one example where a Complete Commerce Platform was migrated to a microservices model, the implementer saw an almost 2x increase in costs and an entire shift in their infrastructure, staff, and culture within IT. It’s a substantially different model that may or may not bring the advantages to allow the promised flexibility, scalability, and cost savings idealized. Think of Complete Commerce Platforms like Oracle Commerce Cloud for next-generation capabilities.

Additional Resources:

See why Oracle is named a Leader in the Gartner Magic Quadrant for Digital Commerce Report


Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.