In 2020, Gartner coined the term composable commerce. Since then, it has become the desired architecture for businesses that want to scale and adapt their eCommerce business at their own pace. It is seen as being free from vendor lock-in and the forced obsolescence of monolithic platforms.
Composable architecture gives capable businesses the freedom to ‘compose’ their own solution. It means selecting best-of-breed features from the market as they scale instead of being limited by whatever static third-party platform they invested in.
But if it’s so good, why are we only now beginning to take advantage?
Putting the cart before the horse
Believe it or not, the first electric car was built back in 1884. Thomas Parker designed a car that used his own high-capacity rechargeable batteries, completely eliminating the need for good old-fashioned horsepower or locomotion.
A decade later, William Morrison built on the idea and devised an electric-powered wagon to shift goods back and forth. Strange to think that electric vehicles were mainstream more than a century ago. Between 1900 and 1912, they made up a third of all vehicles on US roads.
So why haven’t we been traveling around in electric cars ever since?
The simple answer is that while the invention was great, the technology at the time simply wasn’t ready for mass production and mainstream use. Having the full-scale infrastructure in place to keep these cars maintained and charged simply wasn’t viable a hundred years ago. Not to mention extremely costly. So, we replaced electric vehicles with the more mass market-friendly petrol ones.
Electrical technology has caught up. From national electricity grids to wireless charging capabilities. The climate crisis has given us more of an imperative to make it work. As a result, electric vehicles are on track to become the new default way of getting around.
It’s the same with composable commerce. The blueprint was always there, but crucial technologies such as microservices, APIs and cloud-native development could not be fully realized due to lack of bandwidth, as well as insufficient processing power and storage capabilities.
In other words, we’ve been waiting for technology to catch up with our thinking.
The eventual disruption caused by microservice architecture
Once our connectivity caught up with our thinking, and high bandwidth connections became the norm, microservice architecture was able to thrive.
With a microservice approach to development, everything is modular. It replaces the idea of having one, static platform to perform all functions. Now, a business can build its platform by weaving together a broad selection of applications that can exchange data and communicate seamlessly with one another.
If a traditional monolithic platform was a stone wall, microservice architecture was more a brick wall that businesses could piece together. If one of those bricks needed to be removed, either for maintenance or to be upgraded, the wall would still stand and the business would still function. A stone wall, however, would need to be rebuilt from the ground up every time.
This was the initial idea behind microservice architecture – to allow businesses the freedom and flexibility to upgrade, patch and maintain their services without needing to inconvenience their staff or customers with downtime. Composable commerce has simply run with that principle, but applied it to an entire organization’s architecture.
As Gartner put it in its 2020 keynote The Future Of Business Is Composable, “Composable business means creating an organization made from interchangeable building blocks.”
From APIs to API-first development
An API or ‘Application Programming Interface’ is how one microservice talks to another. Without APIs, microservice architecture – and consequently, composable architecture – would not exist today.
All of our web experiences are connected by APIs that safely and securely transmit data. This allows potentially hundreds of microservices to work together thanks to the increased bandwidth we now enjoy. From customer checkout functions to online product catalogues, APIs have been around for more than a decade. However, ‘API-first’ is a relatively new term and has become a critical component of composable architecture.
API-first is less of a function and more of a developer mindset. Traditionally, APIs were an afterthought, something that was tacked on at the end of developing a service that would make it “talk” with other services. This, however, can be quite limiting in terms of compatibility and longevity. It can very quickly lead to a tangled web of interconnected services that can be hard to unpick.
API-first puts API development higher up the priority list. It means that compatibility and flexibility are put above all else. This has changed the balance of the app ecosystem. It has given rise to countless applications and services that are specifically designed to slot into any organization’s architecture with relative ease.
Both microservice architecture and API-first development are important innovations that paved the way for composable commerce. But it’s important to note that these innovations were only made possible thanks to our increased capacity for transmitting and storing data. Yet while technology might have been the facilitator, competition and evolving consumer trends were the imperatives.
The need for composable architecture
To try and make a composable solution work in the ‘80s or ‘90s, when the internet was in its infancy, would have been putting the cart before the horse.
It made sense then for businesses to partner with monolith vendors as part of a packaged solution to get their services online. Things were basic enough and customers’ expectations at the time were relatively low. The very act of doing business online was a novelty in and of itself. All businesses needed at that time – whether B2B or B2C – was the means to facilitate it.
Today’s landscape is very different. It’s customer-centric, shaped by trends and behaviours rather than need or necessity. Interacting with a business today is regarded as an experience rather than a function. That experience needs to be fast, responsive and in-tune with what customers are expecting.
For B2C businesses, that might mean quickly rolling out a live chat function, or offering a new trending payment method at checkout. For B2B commerce, it might mean being able to automatically raise invoices or add in a function to provide customers with real-time stock updates. With composable, businesses can seek the best-of-breed providers of these services and simply incorporate those solutions into their overall architecture.
So instead of waiting for their legacy platform to roll out piecemeal updates, businesses can take control and put themselves in a state of continuous improvement.
In 2019, Forrester research pointed out that 74% of businesses were concerned that their current platforms wouldn’t allow them to scale properly. 78% said their legacy solution couldn’t adequately support cross-channel order management.
With a composable solution, these businesses would not be held back and would be free to explore a competitive range of off-the-shelf cross-channel order management services that could slot seamlessly into their architecture. Either that, or they could build one themselves or commission a third-party development team to build one for them. The crucial thing is that these businesses would not be held back by vendor lock-in and legacy platforms.
If monolithic platforms are the petrol vehicles businesses have been cruising around in for the past few decades, then composable architecture represents the electric vehicles of the future. They’ve always been there, but now the environment is just right for them to reach their full potential and drive us into the future.
Emporix is the only truly composable, enterprise-grade digital commerce platform that manages advanced commerce in B2B and B2C. Retailers, wholesalers, manufacturers, and brands can innovate their business models and differentiate themselves through technology. Emporix provides this by a true-cloud architecture based on headless microservices and an API-first approach. Its multi-tenancy concept is extensible on all levels and continuously delivers new features.
