Microservices architecture: why the business should care

Skava Commerce is built from the ground up on a microservices architecture, with a rich set of APIs to provide access to the individual services. Sounds great. If you’re in the IT organization, the benefits are music to your ears: more scalable, more maintainable, and lower total cost of ownership.  But why should the business care?

In my time as a product manager and as a consultant to retailers, I’ve been involved in digital commerce for over two decades and have had the opportunity to see a wide variety of ecommerce platforms in action. Being in a role that sits between the development organization and the business, I’ve formed a perspective on what matters to both groups. When you are not on the IT side, it’s easy to get lost in discussions about architecture and database choices, SLAs and uptimes, and lose the plot on how software platform choices impact your ability to drive the business forward. But the capabilities (and sadly all too often, the limitations) of your platform define the digital playing field for your business and it is critical that you consider the implications of your technology choices.

There are a number of related reasons why Skava’s microservices architecture is a big deal to the business. The simple, if somewhat boring reason, is that what’s good for IT is good for the business as a whole. Lower TCO means a healthier bottom line for the company.  But it goes beyond that. By reducing IT’s maintenance burden, development resources are freed up to focus on actual business projects. In my prior lives, our annual tech portfolios were often dominated by “keep the lights on” work, meaning many of our great ideas to enhance the customer experience or make our business tools better fell far down the list and we inevitably had to make the hard decisions to drop stuff we really wanted.  Even the overhead of that portfolio process was exhausting. And it was demoralizing when good initiatives got put off to next year due to capacity constraints. An IT organization that spends less time focusing on maintenance and troubleshooting can spend more time delivering new functionality.

Monolithic vs Microservice architecture

The microservices architecture also permits an organization to adopt just the pieces it needs, when it needs them, transitioning at its own pace. Anybody on the business side who has experienced a “big bang” platform deployment knows the benefits here. While it clearly makes the lives of your IT team easier, it also gives the business more predictable dates to plan around.  Marketing campaigns, inventory buys, even business user training become more manageable compared to rolling out a monolith.

But to me, the most exciting reason why Skava Commerce’s microservices architecture is a big deal for the business is its rich API platform.  Modern digital commerce is defined by constant change. In the past, it was enough to have a good experience on the desktop. Today, retailers need to be great across a multitude of devices.  New front-ends such as voice and augmented reality are emerging. And in-store experiences tied into the digital commerce back end, such as associate devices, price/inventory checkers, and smart fitting rooms, are increasingly critical.  Key to success in this dynamic environment is the ability to test and learn, experiment with prototypes, and quickly extend the experience when new opportunities arise.

I’ve seen amazing things done with the available services of legacy platforms – prototypes, experiments, and new customer features built and deployed quickly and inexpensively. But I’ve also seen the constraints that come from a platform with a limited or immature set of APIs. On several occasions, I had to tell the business that a particular experience was just not possible with our current capabilities, or that integrating some third-party extension would cost an inordinate amount. Because they would require deep surgery to modify the monolith, simple tests sometimes came with six and even seven-figure price tags and months-long delivery schedules, making them difficult and even impossible to justify.

A platform lacking a robust and mature set of service APIs puts the business in an impossible spot: in order to prioritize the development of a new feature, you want to experiment so that you can better understand its value before making the big investment. But the cost of testing is often prohibitive, so either you don’t build the new feature, or you gamble and build it even with incomplete information. I’ve experienced this first-hand several times. Sometimes we would just have to say “no” to the business request, other times we would prototype and test as best we could, and still other times we’d just bite the bullet and spend the money.  In one particular case, we were excited to deliver an exciting new customer-facing feature. Our platform lacked the APIs to allow us to perform a lightweight test, but our belief was that this was a good feature, so we decided to proceed with the development work, using the best-supporting data we had. Once we finally put the feature into production, extensive testing showed that it negatively impacted sales. We had no choice but to mothball the feature. It was a tough pill to swallow and an expensive learning process.

By providing access to a broad range of functionality via its modern API platform and microservices architecture, Skava Commerce gives retailers agility and flexibility: to respond to trends, prototype, experiment, and deliver new experiences.  The business can move more quickly, test and learn to make better investment decisions, and ultimately drive more successful outcomes. And when asking for new functionality, rather than “no” the business will increasingly hear “yes.”