A movement is taking place in the field of eCommerce. Something that we at Product League call “the road to composable”. While running, building and scaling your digital business, you might not even have known you were on this road. You might think that all the problems that arise with every new eCommerce opportunity are yours and yours alone. Rest assured - we are all on this road together.
Today’s topic: Composable Freedom…
This is the third and final of our blog series where we discover the different stages on the road to composable. In the last article, we looked at the prospect of going headless, the reasons to consider it and the value it will bring. In summary, by liberating your frontend from the backend concerns, you start to align your systems with the pace of change. Valuable in itself, and also the first step towards true composability.
Read the previous articles in our series:
On the road to composable – The monolith
On the road to composable – Going Headless
Composable
During your move to headless, or maybe even before, you will experiment with the first microservices. A dedicated onsite search engine for example, or a modern content management system that is headless by design. Truly, now you’re heading towards composable, a landscape that is no longer limited by the question “what still fits?” within the monolithic platforms, but instead is being determined by the question “what is the right fit for me?”.
Within a composable landscape, your custom user experience remains decoupled from the backend (headless). However, instead of the backend being one large, still rather monolithic eCommerce engine, you start thinking of microservices. Which system/process/service is the right fit for my business needs? Investing in a dedicated pricing and promotion engine starts to make sense if your business relies heavily on pricing and promotion logic to offer the best deals to customers at any moment. An app that leverages the backend customer data in exciting ways to show them benefits, can be the way to set your business apart if you have a custom, multi-tiered membership program.
The revolution starts when you no longer think of your technology as 1 large backend system, but instead as a versatile landscape of headless microservices, designed specifically for the purpose they need to fulfill.
In recent years, a movement was started by some of the vendors of these types of applications, called the MACH Alliance. MACH stands for:
- M icroservices
- A PI-driven
- C loud native
- H eadless
These companies realized that their products were very good at solving a particular subset of problems. They did not want to branch out and dilute their solutions until the products would become one-size-fits-all platforms as well. Instead, they doubled down on becoming the best of breed in their niche. They chose to partner themselves with other companies solving other relevant problems and dedicate themselves to the principles of the MACH architecture, to ensure the best mutual integrations. This way, any (eCommerce) problem could be solved, simply by connecting the right puzzle pieces. MACH landscapes are no longer comprised of large monolithic platforms, but instead of multiple dedicated services by SaaS vendors working seamlessly together.
An example of MACH – decoupling a CMS
A classic example of the MACH mindset shift is a dedicated content management system (CMS). An older CMS would be responsible for both the creation of content, and the display of this content on the site. Often this type of CMS is still part of a monolithic eCommerce application. It will push the content out and generate the site according to the rules that are set up. This often creates conflicts between the HTML inside the CMS and the rest of the site. Furthermore, it is hard to scale, because for each component you must describe exactly how it should behave, whilst taking the rest of the monolithic platform into account.
This is the MACH way of working: you only speak to these systems through API’s. Imagine the relief to your teams: the content editors can now create their content without having to worry about embedding HTML, they know the rules for the end product, and they can “fire and forget”. And the frontend development teams are no longer worried, since their carefully crafted pages can no longer be destroyed by a careless or incorrect content update. They remain firmly in control of the display.
A new catch-all solution?
Moving from a monolithic and/or headless eCommerce engine into a composable eCommerce landscape certainly brings many benefits. Automatic scaling, so you are never caught unaware of the Black Friday peak anymore. High performance, since every tool is only doing what it is supposed to do. And dramatically improved time to market: Gartner predicted that by 2023, organizations that have adopted a composable approach will outpace the competition by 80% in the speed of new feature implementation.
Instead of one big decision every 5 years (do we continue/upgrade our monolith, or do we do something different?), you are now making many small decisions (is this tool still the best fit for this particular problem?). This means total cost of ownership (TCO) is not in the way of innovation anymore. It is much easier and cheaper to swap out a single microservice than it is to change your entire eCommerce landscape!
However, there are certainly challenges on the road to composable. For example, your vendor landscape becomes more complex. Dealing with all these contracts and vendors can be quite a hassle. Also important: is your organization capable of orchestrating such a digital transformation? It requires strict governance of architecture principles, much higher demand on teams to break up siloes and a brand new organizational mindset. And let’s not forget that the technical skills of building and running this new landscape, with its new data demands, API orchestration and custom frontend flows, are nothing to sneeze at.
There are two directions to approach this complexity:- You try to buy your way out of this problem by getting as many SaaS solutions as you can, with implementation partners for all of them. The problem is that this still requires much coordination between all these different partners. And the SaaS solutions out there, especially on the frontend side, offer many features out of the box, but are limited in their customizations and have code that is hard to re-use.
- You try to build your way out of this problem by getting many teams of engineers that custom-build solutions using high code. While this certainly is the most flexible and the most performant for the resulting applications, it requires an organization to become an IT company, which is a very far-off goal for many retailers. Also, this route might become the most expensive, if you try to rebuild all the solutions that other companies have already figured out for you.
Build better experiences with composable commerce + low code
In practice, most organizations will choose a combination of the two tactics, trying to buy solutions to “solved” problems (think commercetools for the eCommerce engine, or Contentful as CMS), while investing in custom solutions where the most benefit can be gained. The custom development will either be done in-house, or through partnerships with development firms.
We can also see that most growth in the eCommerce solution market sits between these Buy or Build tactics. On the Buy side, the SaaS solutions are becoming more flexible and more tailored towards composable. This is true for many modern, headless SaaS solutions, but also for the old monoliths, which are moving towards the cloud in an attempt to catch up with younger competitors (although only time will tell if these are viable solutions or just “cloud washing”). One serious downside to these SaaS solutions remains their lack of flexibility. What if you need a custom frontend for a specific business use case? Or an orchestration service for data between a few systems that are not often used, but are crucial to your digital experiences? These use cases are common in an eCommerce landscape, but without investing in custom development, they might die a slow death at the bottom of your backlog.On the Build side, the platforms that are doing low code are on the rise. Low code aims at making custom development more accessible by lowering the cost. Either fewer developers are needed for the same result, or the same number of developers deliver more. Some eCommerce frontend SaaS's, like commercetools frontend are moving in this direction, allowing for citizen development. Even Salesforce is offering a very limited low-code drag-and-drop eCommerce starter package. There are also pure low-code platforms entering this space.
At Product League we choose for the high-performance low-code platform OutSystems to develop our eCommerce solutions. We chose OutSystems because it embraces the concept of reusability. For example, it allows you to build once and publish it both as a reactive website and a hybrid app. You can build integration modules that allow you to speed up integration delivery, which is increasingly important as your landscape shifts to composable. What it also allows you to do is quickly build multiple frontends for specific backend users. Since eCommerce sits squarely in your business process, the many users that need access to eCommerce systems need specific functionalities, that are not easily served with one generic “backend portal”. With OutSystems we can build both the customer frontends and specific frontends on top of the same backend which cater to the eCommerce managing employees.
The downside of the build approach remains the lack of reusable solutions. You don’t want to rebuild the wheel, so to speak. Unfortunately, you spend the first months rebuilding what SaaS solutions already built before, only to then start your custom work afterward. This is where the exciting concept of Accelerators comes into play. An accelerator aims at kickstarting your custom development with out-of-the-box components. This can leverage the work that has been done before, making a project start at 60% instead of at 0. At Product League we chose this approach since that is exactly the low code mindset as well - keeping reusability in mind when it comes to designing and building every component. When keeping reusability and accelerator-style development in mind, the benefit is that you think early on about where to buy and where to build, incorporating “solved” solutions in your architecture while focusing your development efforts only on the truly differentiating use cases.
A journey, not a destination
Where is your company on the road towards composable? We've been through many peaks, valleys, and potholes in our 3-part blog. Here is a list of the questions we have asked ourselves over the course of this series:
- Is my eCommerce technology meeting the customer's demand, without scaling issues?
- Is my technology stack holding me back?
- Which business problems make my business unique?
- What unique value am I providing customers?
- Am I trying to solve new problems or am I encountering solved problems?
As you answer these questions yourself, we hope that you are leaving this series with a sense of direction and a sense of purpose, to adopt the principles of composable where they make sense and ignore them when they are not (yet) a right fit.
Crafting a New eCommerce Legacy:
Our 'Road to Composable' series may have reached its end, but your adventure towards eCommerce excellence may just be beginning. It's time to turn insights into action and theories into tangible results and partnering with Product League will help you navigate the exciting realm of composable eCommerce. Don't just adapt to change – be the frontrunner of change. Reach out now, and together, let's craft a new legacy down in eCommerce by building systems that are as unique and dynamic as your business vision!