November 22nd, 2022 | 4 MIN READ

Breaking Up With Your Commerce Monolith: Part 1 (Fighting the Status Quo)

Written by author_profile_images Bryan House

Bryan is the SVP of Product and Customer Success at Elastic Path. Previously, Bryan was the Chief Commercial Officer at Neural Magic, a deep learning software startup where he ran Product, GTM, and Customer Success. An Acquia founding team member, he helped lead the company to $170+M in revenue. His expertise spans machine learning, digital experience platforms, and open source technology. 

ecommerce_monolith


When you’re looking for a commerce platform, what’s better? Endless arrays of features available natively, or composability? 

Looking at the typical analyst market survey, you might think that more features are better. Otherwise, why would they ask more than 300 feature-specific questions in the vendor evaluation? Their logic: Monoliths, by definition, have more features. Ergo, monoliths are good. 

However, if you’re currently stuck with a monolith, you know better than that. Monoliths are slow, hard to update, and tough to use. They hinder you from adopting the latest, best-in-class technologies, don’t support the ability to move quickly in response to market changes, and squash any ambitions of experimenting with new channels. That just won’t work if you’re trying to adapt to the latest consumer trends.

Embracing a true omnichannel, digital-first strategy like McKinsey suggests requires a fundamental change in approach. Let’s look at why market pundits view more as better, and a more modern way to assemble your digital commerce experience.

Why Digital Commerce Analyst Reports Fall Short

Even though analyst reports have been considered the de facto standard for technology vendor evaluation for the past few decades, they’re increasingly out of step with what buyers expect today. The reports themselves were structured to reward monoliths and legacy technologies from big firms. By definition, these technologies check all the boxes when it comes to features. On composability, monoliths don’t fare as well. From microservices, to integrations, to APIs – if it were up to analyst reports, you couldn’t have both a full-featured platform and one that supports modern approaches to composability and “best for me” architectures. 

Don’t be distracted by this red herring. The “more is better” logic is ultimately flawed, and suggests that you’re making some sort of sacrifice if you choose the composable path. The truth is, you don’t necessarily need every feature available to you natively if you can select the best features for you. 

While that might seem intuitive, it’s a fundamental pivot in the way many people in the commerce world think. Analyst reports tend to be lagging indicators. If you’re using them to make a commerce decision, you’re doing it wrong.

 

Get Some Real Answers to Make a Commerce Decision

Connect with an Elastic Path Expert to Answer Your Commerce Questions

Contact Elastic Path

Key Questions to Ask About Composable Commerce

If you’re not using analyst reports, how should you navigate a commerce technology decision? There are a couple of important questions to ask the vendors you’re evaluating. 

Instead of: “Do you have it native?” Try: “Is this a best in class feature?”

As I’ve covered in the past, API-first beats native in the new world of digital commerce. Here’s why: APIs are lightweight and can be designed to be easily extended to serve a variety of specific use cases. For complex use cases, it’s possible for developers to design these APIs to communicate with one another and streamline requests that pull related data in. 

If you select an API-first commerce platform, you can expect to get the best-in-class features you need, while avoiding the typical bloat and slowdowns associated with monoliths. In addition, it allows your developers to work with the technologies they trust most.

Instead of: “Aren’t composable architectures too complicated?” Try: “How can you make composability simpler for me?”

Look for tools that shorten implementation timelines and reduce some of the complexity that’s traditionally associated with composable architectures. That might include the following features: 

  • Starter kits: Give your developers a point from which to start with reference implementations of APIs and front-end components to kickstart your composable commerce application development. Check out the D2C Starter Kit we just launched. 
  • Pre-built integrations: Instead of having to choose from nearly endless options of possible API-first commerce components, look for a platform that has pre-built integrations (e.g. a marketplace) to help you quickly find, install and configure best-of-breed software.
  • Pre-configured payment gateways: Payments are perhaps one of the more complex parts of digital commerce, but it doesn’t have to be. Pre-configured payment gateways can get you set up to accept payments right away.
  • Pre-Composed Solutions: Benefit from the use case-specific expertise and best practices of systems integrators to launch faster and customize on-demand.

Hedging Your Bets with Composable Commerce

While analysts and other industry pundits might proclaim that monoliths have a higher ability to execute, hedging your bets with a best-of-breed approach is actually far less risky. There’s no single point of failure. Components in a composable architecture can be easily changed if they’re not working, or as your requirements evolve – which allows for a cycle of continuous improvement.

Today’s commerce leaders are expected to innovate, which doesn’t necessarily mean going with yesterday’s “sure bet.”  Those that want to embrace flexible, digital-first commerce know that composability is the way to go. Next up in this series, I’ll explore how to break up a monolith by covering the two typical patterns companies follow to make it happen. 
 

Share on

evaluation tool

Thanks for signing up!

You'll receive a welcome email shortly.

By submitting this you agree with our privacy policy.