MACH. DXP. JAMstack. Composable architecture. PBCs.
In an industry that loves to drown you in acronyms – and doesn’t mind when meanings overlap – keeping up with everything can feel like wading through a pool of scrabble tiles.
In this trusty guide, we’ll be unpicking the technology and business contexts that fall under the broad umbrella of composable commerce.
So, lean in; it’s about to rain.
What we’ll learn (in the patented Just After Midnight ‘CAC’ format):
- What composable architecture is
- How it differs from composable DXP
- How MACH fits in
- What PBCs are
- How PBCs differ from microservices
- How JAMstack fits in
- Why composability is key
- Advantages of composable commerce
- How we can help
Concepts: what is composable commerce?
Composable commerce is more of a business-level term. That means it describes an outcome that can be reached via a few different technology approaches (which we’ll get to below).
This outcome is composability in a commerce stack, which means various business capabilities (e.g. payment gateway, product search, billing) can be selected and replaced easily from an array of third-party service providers.
Or, a traditional ‘monolithic’ commerce stack = soup; a composable commerce stack = tapas.
In the former, all the ingredients are irreversibly mixed up. In the latter, pick, swap and nibble at your leisure.
There are other advantages to composability, which we’ll get to later, but this core functionality is the bedrock.
How is this different from DXP/composable DXP
When people talk about DXPs, they mean non-composable monolithic experience platforms. Once these become composable (as in composable DXP) they’re very similar concepts to composable commerce, except composable DXP is the slightly more specific term, naming an actual platform rather than the more general idea of composability in commerce.
Architecture: MACH and JAMstack, the technologies behind composable commerce
The easiest way to think about MACH and JAMstack is that MACH enables composability on the backend while JAMstack does so on the front end.
They very much are two sides of the same coin.
So let’s start at tails (the backend).
How MACH fits in
MACH is a group of technologies which, used together, enable composable architectures.
- Cloud-native SaaS
Well, that’s one acronym down. Now let’s take a closer look…
Image source: fabric.inc
Microservices are small modular services that combine to form an application. Very similar to our soup and tapas example. Read here for more info on microservices architecture for eCommerce.
API-first is a development approach that centres on APIs (application program interface; another acronym bites the dust) which can be thought of as the shared language of various components of MACH.
Cloud-native SaaS is a software deployment pattern wherein users access a single cloud-native hosted version of the app that can be scaled and updated from a central point.
Headless means decoupling the front and back end so that content can be served via APIs to a variety of touchpoints and devices.
What PBCs are – one level deeper
PBC – the third acronym on our hitlist – stands for packaged business capabilities.
Image source: Sitecore.com
In composable commerce, microservices are generally aggregated into a single business function (like cart and checkout in the above example).
However, also as per the above example, these can be fulfilled by a single microservice.
A good way to think of it is that, in composable commerce, the architecture building blocks are grouped by purpose – but this purpose can be fulfilled by a single block, in which case it’s in a group of its own.
A bit like how you can have multiple people making up a party, but if you’re incredibly fun, a party of one is possible.
On to heads (the front end).
How JAMstack fits in
Like MACH, JAMstack is a development approach that focuses on composability.
But it’s also an acronym hidden in plain sight:
All combined in a stack – hence Jam…stack.
As explained, JAMstack is more focused on the front end. And each element has a role to play.
Image source: researchgate.net
In the above, we can see a JAMstack setup vs. a traditional webpage.
In JAMstack, the UI is decoupled from the backend services, and pre-rendered static sites are served via a CDN in markup.
This all happens client-side, as opposed to in a traditional set-up where the backend services are engaged to handle user requests.
This all means much less time and resources go into serving a webpage.
JAMstack vs. MACH…JAMstack + Mach?
JAMstack and MACH both enable composable commerce – and they can work together or separately.
When to use JAMstack and MACH together
It’s possible to apply a MACH approach to the back end of your composable commerce architecture and a JAMstack approach to the front end.
This could give you very fast-loading static web pages served by an array of lean, replaceable PCBs.
Why NOT use JAMstack and MACH together
If your composable commerce solution features dynamic pages, you won’t be able to use JAMstack. Static pages only – unless you want to do A LOT of extra work.
Content editor friendliness
The goal of some composable commerce platforms is to have non-technical users author experiences via intuitive UIs.
This is full composability.
In JAMstack, editors will need to interact with the markup, which goes against the ethos a little.
Pushing things client side can drain the battery
Seeing as many composable commerce solutions are going to be accessed by mobile, the drain on device resources caused by pushing everything client side can be an issue.
Context: why composability and how we can help
Why composability is key
As explained, the key functionality of these technologies is enabling composability: a component-driven, fast-adapting stack capable of pulling in the very best of third-party vendor services and dropping them just as quickly.
This is the trend throughout tech. To decompose, decouple and generally atomise (atomic content is a tech-ism we didn’t even get to) so that we get these lean mean orchestral sales-generating machines.
Which in practice means…
Key advantages of composable commerce
- A future-proof technology stack (since it can incorporate and shed services as and when)
- Faster time to market for new features
- Unparalleled scaling (each service can be scaled independently via cloud-native services)
- No vendor lock-in
- The ability to define and personalise customer experiences
- A business-focussed approach to architecture that can help align stakeholders
- Massively increased flexibility
And with Gartner predicting that companies adopting a composable approach will outpace the competition by 80% in 2023, it’s safe to say people are taking notice.
How we can help
Now we’ve put a word to a fair few anonymous letters, there might be something else we can help you with.
At Just After Midnight, we’ve made a name for ourselves supporting mission-critical apps via our pioneering 24/7 support system – be it fully composable, an old-school monolith – or something in between.
So to find out how we could help you – just get in touch.
While we’ve got you
If you want an even more in-depth understanding of composable commerce and how we got here, why not download our free report on the future of eCommerce.