Monolithic Commerce Platforms: Too Big to Succeed?

In today’s digital commerce age where new customer journeys, routes to market, digital touchpoints, business models and technologies rule, there remains a chasm between customer expectations and what an enterprise can deliver with legacy systems.

Customers don’t care that something’s difficult, costly or risky to build and deliver. They don’t appreciate that your IT group works on quarterly release cycles. They don’t understand how much technical debt you’re drowning in, or how much refactoring and regression testing your organization is not willing to do. They just feel the pain of their experience gap (that company B seems to handle just fine).

Monolithic commerce platforms can’t stay afloat

The enterprise architecture approaches in most large companies today reflect a bygone era, a time in which it was not necessary for companies to rapidly shift their strategies, continually evolve their products and services, and constantly improve their business processes.

McKinsey & Company, Rethinking the technology foundation for digital transformations

There was a time when monolithic commerce platforms with services like the catalog, pricing, search, user accounts, checkout and order management all packaged in one application were perfectly suited to their IT environments. Commerce requirements were simple. The desktop was the only screen that mattered. If you simply had a transactional website, you were leading edge.

From the late ‘90s to around 2004, monolithic commerce platforms got the job done and were relatively lightweight compared to today.

light monolith

Then things started to heat up. Retailers and online shoppers wanted more features. They needed SEO-friendly platforms that supported rich images, customer reviews, filtered navigation, fuzzy search matching, product recommendations, wishlists and discount codes.

Monoliths got bigger.

monolith bigger

Then, retailers’ RFPs exploded. They wanted multi-site, multi-language, and multi-currency. They needed to personalize their stores and manage content. They needed to support bundling, product configuration, subscriptions and complex pricing.

Monoliths got even bigger, heavier and slower.

monolith heavier

In 2007, a little something called the iPhone dropped. Retailers scrambled to get mobile-friendly, but their monoliths couldn’t do the job. An entire industry of mobile commerce platforms emerged to fill the gaps in legacy platforms, running alongside them until vendors could build the mobile capabilities their customers required.

Then came tablets. And omnichannel. And in-store digital. Oh, my!

Today, monolithic commerce platforms have reached their tipping point.

monolith sink.jpg

To add capabilities, integrate with best-of-breed technologies and extend to new touchpoints with a monolith requires messing with millions of lines of code, hooking into tightly coupled services and working with a network of APIs. Or, it requires building solutions that live alongside the monolith, sacrificing seamless integration with core systems, customer accounts, analytics and more. (And nevermind your technical debt).

APIs to the rescue?

Certainly, APIs help an enterprise extend a monolith. And monolithic commerce vendors want you to believe they’re all you need.

But the problem is, underneath the APIs still lies a monolith — complete with all the headaches hacking a monolith carries.

monolith api.png

With an API strategy:

  • You’re still working with millions of lines of (aging) code and tightly coupled services
  • Development is still painfully complex and slow
  • Developers still must be very familiar with the code base (thus developers are more costly)
  • If you swap in a better-breed service (like Search or PIM), the monolith still retains copies of data
  • The monolith still requires heavy regression testing, as changing one thing can affect many others
  • You still have to redeploy the entire application after a change is made
  • Extensions still introduce fragility to the system
  • Services still can’t scale independently, causing performance issues and potentially requiring more licenses and hardware

And so on…

Microservices: the anti-monolith

Unlike big, heavy monolithic applications, microservices are essentially free-running vessels.

microservices vessels

Microservices are decentralized and decoupled. Running independent of each other, microservices can be steered in their own directions, at their own pace. Developers can extend individual (or combination) of services to new touchpoints much faster and nimbly than when working with a tightly-coupled system, and without these touchpoints needing to consume the entire application.

Microservices are more lightweight. They don’t rely on a matrix business logic coded into enterprise service buses which are heavy, increase latency and page load speed. They’re also easier to debug, maintain and iterate over time.

Microservices are resilient. Their decoupled nature means if there’s problems with code or a service needs downtime, it doesn’t have to take down your entire system.

Microservices scale independently to maximize performance without impacting other services, and without requiring more hardware and bandwidth.

You can deploy changes faster. Rather than weeks or months, you can roll out projects in hours or days (and without a full application reboot).

You can fail faster. Not all innovations bear fruit and ROI. If your project underperforms, you haven’t interrupted as much code, spent as much time or money. And likewise, rollbacks are much smoother.

The modern enterprise needs microservices

It’s been said that with enough time, money, people and patience you can make software do (almost) anything. In today’s competitive market, few companies have any of these in abundance.

Overhead aside, any time-lag-to-market carries a missed opportunity cost for satisfying the customer, driving revenue and staying competitive.

Even for simple changes, marketers and merchandisers want the speed, flexibility and control to be able to update front-end experiences without affecting any of the other parts of the system — and so does IT.

And with the trend towards decoupled front-end content management and digital experience capabilities, it doesn’t make sense for your front end to be highly flexible, but your backend to remain a nightmare to change.

To win today and be future-proof in the next 5, 10, 20 years, your front and back end architecture must be flexible enough to incorporate emerging, end-to-end customer journeys and best-of-breed experience technologies and touchpoints. Unencumbered by legacy baggage, microservices are the way forward for the modern enterprise.

Want to learn more about microservices? Check out our latest webinar: Innovate in today’s digital commerce world with microservices architecture.