How to Move from a Monolithic OMS to Fulfillment Microservices to Build Business Value

Much has been written about the advantages of microservices vs. monolith applications. But we find many retailers are struggling with how to take an OMS (Order Management System) application that is responsible for many upstream and downstream processes and transform it into a set of microservices working in concert is a question.

In this post, we’d like to offer a perspective on doing just that. This is the first in a series of posts on this topic.

The Challenge

The OMS has often been described as the “conductor” in a retailer’s ecommerce ecosystem. While the benefits of a centralized view of inventory and orders are what made OMS software appealing in the first place, it has also made them very hard to break up. So how do you switch the conductor while keeping the band playing?

Migration Planning Roadmap

Everyone should develop a unique roadmap for the organization when planning a migration based on three factors. Those are business value, risk analysis, and team composition. Each of these will play a part in how you decide to execute your transition.

1. What is the business value of these microservices? Are there conversion, cost, or experience drivers that your microservices are enabling? Where do you need speed to market? Many miss the lost opportunity cost when looking at the ROI of Microservices. We typically see the promising microservice as a first step many are taking, given the conversion improvements that come with a specific and accurate estimated delivery date & time, for example. Some of your microservices will have more foundational value, and it is important that your roadmap is delivering a mixture of both across time. Your business value may be tied to exiting SaaS agreements or other costs of ownership considerations. Starting a modernization journey will need a technical AND business vision. Ensure you prioritize your journey against both.

2. The other component is a risk assessment. You may decide that while promising has large benefits, it comes with more risk. Moving to a microservices architecture has many benefits but depending on where you are in your journey, practicing the deployment, and continuous improvement of these services should be done on lower risk noncustomer facing microservices first.

3. Consider your team’s maturity with microservices architecture. We’ve seen retailers jump to create business value but find they have not stopped to build the knowledge and infrastructure base that these services will require to be successful. This may be the first step you need to take as you build your roadmap.

4. Lastly, foundational data is another factor you need to consider. Moving from a monolith with one data model to microservices with multiple data models has implications for your data and analytics teams, shaping the order in which you execute the transformation.

The end state will be different for everyone. You may decide that certain processes should continue to be owned by your legacy OMS. Use this framework as one input to your decision-making.

New Approaches to Modernization

As a general guideline, we encourage the development of abstraction layers between your current OMS and its upstream and downstream systems. This will make the transition to new services easier because you will already have standard signatures for your new services that replace existing functions within your OMS.

We look at the OMS owning three main domains today. Inventory/Promising, Order Orchestration, and Fulfillment. In some cases, OMS may also own the payment and returns domains. Our approach at a high level is to work from the outside in, with the order domain being that center. Imagine if the core “guts'' of the OMS is that conductor function - guiding an order through its lifecycle. That could be a sales order, fulfillment, or return order. You would leave the “guts'' of your OMS intact until the end.

An alternate approach could be looking at an end-to-end business process (such as BOPIS) and moving that alone off the monolith. We disagree with this approach as it leaves end users likely managing their piece of the business process in two different ways for a period of time. Also, from a technical perspective, this is inefficient as it would cause some of the shared services to be refactored multiple times as each business process came into scope.

Our approach looks at the front-end commerce systems and downstream enterprise applications that the OMS provides data such as inventory availability, promising, order status, and sales posting, and builds microservices that can, over time, start servicing those upstream and downstream systems. In other words, make these OMS-dependent services rely on your new microservice.

Wrap-Up

There is no right answer to planning your move off an OMS monolith application. The good news is that many of the upstream services, such as sourcing and promising, have large business value but don’t sit deep in the core of the OMS. Starting there creates early wins that will build organizational momentum. We believe working “outside in'' will give you the benefits, experience, and confidence to make the full transition off of your monolith.

Our next post will discuss specific strategies within each order, inventory, and order domain.

At Nextuple, we can provide specific recommendations based on your situation that allow you to maximize business value and minimize technical disruption. Check back here for more insights on your OMNI Fulfillment modernization journey!