26/08/2022 | By Damien Pasquinelli, Digital Commerce Director, Hardis Group
Monolithic e-commerce platforms involve deploying a single, fully integrated application for selling online. By contrast, MACH (Microservices, API-first, Cloud-native, Headless) composable architectures allow best-of-breed applications targeting specific requirements to be assembled and added on the fly. Yet this approach has so far gained little traction among organizations. In this article, we clear up misunderstandings and dispel myths around this new type of distributed e-commerce architecture.
Composable commerce is more a concept than anything else
True and false—Composable commerce is underpinned by a concept in the form of MACH, a recently coined acronym that refers to distributed e-commerce architectures comprising now-mature and easily interoperable technology components. MACH stands for:
- Microservices: Each component (or “service”) covers a specific, best-of-breed function—technically and functionally delimited—and is capable of standalone deployment.
- API-first: Each application, component, or service exposes its own APIs and uses the APIs exposed by other applications, components, or services.
- Cloud-native: The components are natively designed for deployment in a cloud (public or private).
- Headless: The “visible” part of the architecture (the front end) is entirely separate from the components that expose the services and data.
MACH is diametrically opposed to the monolithic system architectures traditionally employed in e-commerce. But composable commerce cannot be reduced to a mere concept: organizations looking to innovate and gain agility—functionally and technically—need to develop a strategy, select the right technologies, and interface them.
E-commerce applications are a replacement market with no need for innovation
False—In fact, when it comes to customer experience (and, therefore, the front end), this couldn’t be further from the truth: e-commerce may be a mature market, but innovation around the customer value proposition remains a key differentiating factor.
And innovation is just as important in the back-office (and, therefore, the back end). Existing monolithic architectures can present scalability challenges, in terms of both infrastructure replication and the deployment and ongoing maintenance costs this represents. What’s more, having commerce and logistics platforms that are interoperable is essential to meeting customer expectations.
Composable commerce requires a clear, predefined vision and strategy
True—For monolithic architectures, the strategy is relatively straightforward: the organization buys a package of features—often too many—to cover every eventuality. Obvious cost overruns aside, this approach has another drawback: some requirements can emerge too late in the day, meaning they aren’t covered by the application as initially chosen.
Conversely, composable commerce follows a LEGO® style approach in which only the features necessary at a given point in time are deployed. More components are then added iteratively, according to the organization’s custom-defined roadmap. Each component is invoiced separately and interfaced with the rest of the system as requirements evolve. Obtaining support from an integrator with a clear technological and functional vision will also prove beneficial in helping reduce complexity and avoiding the risk that the system could become compartmentalized into silos.
With so many different suppliers, the IT department’s role is reduced to that of a buyer
False—Again, in fact, the opposite is true: by its very nature, composable commerce allows organizations to build platforms that cater precisely to their requirements. And because the IT roadmap is more important than ever, the IT department (or the digital department) becomes an essential link in both the business and IT value chain.
Consequently, reducing the IT department’s role to that of a buyer would be a mistake, not least because it takes specific skills and expertise to design and integrate this type of platform, and to maintain and upgrade it over time—from setting the strategy and changing practices, to developing the technical roadmap, deploying the components (FinOps, DevSecOps, and urbanization), doing the financial engineering work (acquisition cost, component integration and ongoing maintenance, ROI), negotiating prices with partners, and more.
With composable commerce, the IT department has a key role to play in supporting every other department—and in ensuring that the organization as a whole is as agile as it needs to be. Moreover, deploying best-of-breed, user-friendly applications enables business-line teams and units to focus on their core roles and gain autonomy (e.g., the sales department can manage promotions without outside support).
Using multiple applications makes the IT system more complex and costly
True and false—Although the features in monolithic systems come as a package, and are therefore cheaper individually, very few organizations use them all. Consequently, the features they do use become more expensive per unit. With composable commerce, the opposite is true: the components may be more expensive individually, but organizations only deploy the features they actually need. Likewise, integration and ongoing maintenance (whether handled internally or externally) for these components can cost more, covering everything from architecture and integration, to functional and technical mapping, and more.
So with composable commerce, financial engineering has an essential part to play, in the same way as FinOps for the cloud. Integrators can make an important contribution in this regard, since they have greater scope for negotiating with vendors.
Composable commerce facilitates data-driven management
True—A composable commerce approach leads to a back end environment that’s adaptable and consistent with the organization’s overall strategy. What’s more, the organization can deploy multiple front ends (to meet evolving market needs) without the risk of creating data silos, and without having to customize monolithic applications—or even produce specific developments around these applications.
With the composable model, organizations are better able to monitor their systems, with a clearer picture of which components are sharing all their data, in real time. This, in turn, drives up technical and financial performance, as well as better equipping the organization to identify opportunities, risks, and areas for improvement.