Yi Zhuang is part of Commercetools which has an API, microservices style, and headless commerce platform. She is passionate about enabling the tech community and understanding the benefits of a headless API-driven approach. In this article, she will talk about composing a headless and composable commerce architecture. She will be sharing some of the key trends you might see in commerce architectures – Composable commerce, Headless commerce, and MACH principles.
Composable Commerce
In the 1990s, when dotcom first started, everybody just wanted to sell online. It didn’t matter how they did it. They just wanted to have a website to allow them to sell online. Then, everyone started creating these types of platforms, which do everything you might need to sell online. You might have your web front, comments, payments, content, and any other servicing tools packaged into one solution. And then, on the back end, you might have data and infrastructure. It worked because, in the 1990s, the thing to do was just to get onto the marketplace and be able to sell online.
But about 10 years later, the Omnichannel came about, and the issue of synching offline and online came to the forefront. Then mobile apps also became a big thing. You needed to have native mobile apps along with a web storefront. The industry was then exposing APIs in the middle to connect all these different digital touchpoints. We started having accounting systems and ERPs, which were also connected by APIs.
Since the 2000s, we have had technologies coming up almost daily on new technology platforms. People have started seeing that tools are working very well in the organization. There was no need to have everything bundled into a single platform. Every team managing its own set of functionalities can actually have its own systems, and each enterprise’s digital landscape becomes a bit more complex. Thus, there are multiple platforms, one for marketing activities and campaigns, one for eCommerce, etc. All these different technologies within the landscape need to come together to form the entire experience for the customer.
Composable is not trying to have one single platform do everything for you. Instead, composing this out of everything that has been working well. Composing individual pieces of the architecture serves up the entire digital landscape. That’s where Composable came about. This allows you to innovate a lot faster.
Composable Architecture
Composable architecture is mainly made up of two components.
First are the digital touchpoints. This can be any digital touchpoint; the more traditional one would be the web store. There are IoT devices that you can connect to your e-commerce center. These are individual pillars that serve up different functionalities or business capabilities to help you serve up the entire experience. You may wonder about the benefits of this, as you need to manage multiple items instead of one stack.
The first benefit would be because it is decoupled, you’ll see that all the business capabilities can be reused regardless of which touchpoints I’m currently assessing it from. From a customer perspective, regardless of whether I am inside a physical store or selling online, the salesperson should be able to intelligently know my purchasing history and style. So that allows you to do that, regardless of the channels you’re accessing it from.
The second benefit is your backend teams can also be segregated; you don’t need one entire team managing the entire solution anymore. I can have individual teams managing different pieces of the business and need not involve everyone in all jobs. These teams become individual vertical pillars. They may be lightly coupled, and they might interact with each other, but they are not interdependent to move forward. This allows you to innovate at a fast speed.
Headless
Our next concept is Headless. It gives us the freedom to create anything we want on the front end. When I am restricted by the backend to create a front end, it does not lead to a good user experience. But by decoupling it, I get the freedom to connect any kind of digital touchpoints to it. So Headless was really driven by the proliferation of touchpoints.
A customer wants a good buying experience. The lines between buying online and offline are kind of blurred. Basically, you just want one single stack to help you manage that. And regardless of where your customer is purchasing this from, we have interesting use cases.
A customer built a car interface within an electronic car. I can purchase extra horsepower within the car interface just for the weekend where the engine is now connected to the Commerce setup itself. So when I make that purchase, I can get extra horsepower for the weekend. I can also have partnerships for additional parking and oil and gas services to allow purchasing from the car interface itself. So that’s one very cool use case.
The core is to have that experience made available to everyone, regardless of where they are shopping from. Of late, customer and user experience have been talked about a lot. The ability of your internal staff to manage different things like your catalog, your pricing, and your segments has also become essential for the business. Hence, API is the way to connect this together; on both sides, the customers and the users. It’s essential to create the right experience for both the customers and the users. For example, in the past, especially when we talked about the dotcom era, the platforms were standard. You had a cookie-cutter template that you followed to list and sell your products.
These days, they’re creating that whole experience, the journey of how the bag is being delivered into the customer’s hands. It goes through the entire process of designing the bag up to the customer receiving it. Instead of using a cookie-cutter approach, they used the Headless approach to build their website and completely decoupled it. So they had the freedom to innovate on anything they wanted on the front end. And this is just one example. To create the right experience, you have to start building that UI of your own. That’s when the Headless approach was invented by Dirk Hoerig, the CEO of Computertools. He believed that APIs can and forever be consumed by any customer device, front end, or any other application. That’s the only way to connect any touchpoints to your engine. He also advocated for a few other concepts: the microservices-based approach, API first approach, and a cloud-native approach.
MACH
MACH is a unit for measuring very fast speeds. It stands for –
- Microservices-based – Individual pieces of business functionalities that are independently developed, deployed, and managed. Even within commerce as an engine, you should have your different services within it. Product management, promotion management, cost management, etc., should be decoupled enough to make individual changes to the platform without affecting the other parts.
- API-First – All functionality and data exposed through an API. When you’re building APIs, they should be developer-friendly as they are the ones using the APIs.
- APIs should be scalable so that it doesn’t affect any parts when you actually start seeing spikes in traffic.
- Cloud-Native – Real SaaS that leverages the cloud beyond storage and hosting, including elastic scaling and automatic updates.
- Headless– Front-end presentation is decoupled from backend logic and is a framework, channel, and language agnostic.
MACH Alliance
MACH Alliance is a group of independent, future-thinking tech companies advocating for open, best-of-breed technology ecosystems that have the capacity to propel current and future digital experiences.
In the past, when we talked about digital transformations, it became a tens or hundreds of millions project where you need to start spending a couple of years on building this entire platform. The functionalities are limited by what this platform provides. But within a few years, while you’re implementing it, what you’ll notice is the business needs have probably changed drastically. And the technology might have already become outdated in the process. But then, it’s too late for you to make changes because you have already put many resources into building this entire stack. So making changes to the platform is risky.
A MACH approach advocates a composable approach, which is pluggable, scalable, and replaceable. Because it is made up of individual pillars, if there are changes even during the implementation phase, you can actually make those changes.
For example, these days, cryptocurrencies are becoming a big thing. For example, I want to start exposing cryptocurrency as a payment. In the past, I might have needed to wait for plugins of this platform or some ways where I can really customize it to enable that payment service. But these days, if I have a cryptocurrency wallet providing me the right APIs, I can easily add another service to enable us to use the new feature.
MACH allows you to modularly introduce different products and features into the platform faster. Making changes or replacing certain pieces is more straightforward with his approach. MACH Alliance comprises a group of technologies that believe in this. So we have to keep innovating to keep up with the competition because we have made it easy for you to plug and play these different pieces of the technology.
Composing a modern commerce architecture
This is what modern commerce architecture should look like.
You might have a single or multiple front-ends based on the number of channels.
The next piece is the API management layer. As there are a lot of different components in the stack, it acts as a back-end for the front-end layer as well. Lots of people are also starting the integration platform as a service approach. But then you have lots of connectors, and other systems within the architecture, mapping to each other. This makes an API management layer very important.
The back-end is all kinds of different microservices serving different business capabilities. So you might have one for commerce, one for content, one for payments, etc.
It is not mandatory to have every single item here within the stack. The key thing about composable is being able to add all this in wherever the business is ready and when the business needs it. So I don’t need to buy every single piece of these components right from day one. In fact, what is recommended is to do it in a strangulation approach, where I bring in the pieces I actually need for my business.
Picking the technologies
The next question will be then, how do I start piecing all those pieces together? We have multiple options.
Custom build approach – There are many different frameworks and hosting capabilities to choose from. These are like different Lego blocks, and it does make sense to see if I have the technical capability to piece them together. It may be costly, but it gives me flexibility because I can build without any limitations on my end.
All-in-1 Solution – The all-in-one monolithic solution provides you with an entire suite of services. I get all functionalities right out of the box. It is not very complex for me to set it up. I probably have specific instructions on the Lego set itself to tell me how to put the pieces together. But what’s difficult then is when I start realizing that my business is not really what this setup can provide me. Maybe I want to change the colors. It becomes a little bit more complex to do that. And I might face limitations when I’m going down this path itself.
MACH Technologies: The MACH technologies are in between the all-in-1 solution and the custom build. They are composable and APIs and microservices-based.
There are many different components and small local tools that can be used to do anything you want. I am no longer restricted in what I can build.
To conclude, it’s not an either-or selection between these three; it’s a mixture. For certain parts of the business where it’s highly complex, maybe I should go down the custom build approach. But for something generic, maybe I could use the MACH approach or even a more microservices-based approach.
