Building vs Buying an OMS Part Three: Extensibility and Configuration

An order management system (OMS) oversees the order fulfillment and inventory management processes for an e-commerce business. It orchestrates the movement of items from the beginning of your supply chain all the way through delivery. They are crucial to business operations but can be easily outgrown as business demands increase.

If you’ve outgrown your current OMS, you need to decide if you should build your own solution or buy another larger scale option. However, there are a lot of factors that will impact this decision.

This is part three of an article series for building vs buying an OMS. In part one, you learned how an OMS facilitates the order fulfillment process and reasoned out whether you should build your own OMS or leverage a third-party solution. In part two, you looked specifically at inventory management as it pertains to OMS.

In the final part of this series, you’ll focus on how to manage changing and growing e-commerce systems. You’ll look specifically at an extensible API-based OMS as a possible solution to your growing business.

How Growth Affects Your OMS

Many built-in OMS solutions are good for starting an online store quickly without much technical know-how. Unfortunately, it’s not meant for larger enterprise solutions. As your e-commerce business grows, it becomes more difficult to manage certain aspects of your business including product inventory, integration of multiple product sources and channels, and managing unforeseen events.

Adding and removing products

In a growing e-commerce business, it’s common to add and remove products frequently. If you’re using an out-of-the-box OMS solution like Shopify, you’ll have difficulties adding new products with specific tags and categories. For instance, Shopify doesn’t support product category levels (like Fashion > Men’s Fashion > Wristwatch) which can affect product discoverability, especially if you have a wide range of products in your store.

Additionally, if you want to add more products, it’s likely that one or more of your products has an array of variants and Shopify limits the number of variants allowed for each product. A variant refers to an attribute that describes the product like the color, size, weight, or length. Using a customizable OMS solution gives you the flexibility to add as many products and corresponding variants as you would like.

Integration of multiple product sources and channels

As your business grows, integrating multiple product sources and channels can become complicated and time-consuming. It also gets increasingly challenging for out-of-the-box solutions to support this level of complexity.

For example, the enterprise solution of Shopify called Shopify Plus, doesn’t support central management of storefronts or sales channels with multiple warehouses. If you have multiple brands in your store and/or catalogs of different products, managing your inventory is incredibly difficult.

fabric OMS helps you connect demand and inventory across multiple stores, sales channels, and online marketplaces, enabling a true multichannel OMS experience.

Managing unexpected growth or events

There are certain events that trigger unexpected growth in your business, like trends, seasons, and virality. Because of this, your business can experience a sudden sales boom, which is inherently good for your business, but the sudden growth can cause your backend infrastructure to falter.

When using a monolithic OMS, if one part of your system experiences a traffic surge, you’ll be forced to scale your backend to accommodate it. When every part of a monolithic system is scaled, parts of your system that are under-utilized may be allocated more resources than they need, making them inefficient.

Microservices solve this problem through modularization, or the breaking down of monolithic software into separate software units based on their function. You may have one module that can handle payment processes, while another handles authentication, cart management, or checkout. The different units of your application can then be connected via API.

An OMS solution like fabric, for instance, lets you implement a microservices-based approach, which gives you room to scale only the parts of your system that need scaling up.

Designing an OMS for Extensibility and Configurability

OMS systems can be designed to effectively handle change and extensibility. There are also some pre-built OMS systems that already offer these design features like fabric, Quickbooks Commerce, and [BrightPearl] (https://www.brightpearl.com).

In this section, you’ll learn about some of the strategies and use cases to plan for when handling changes in an OMS.

API based strategy and microservices approach

A microservices approach is a modern web development solution for the modularized backend. This architecture structures a backend application as a collection of services that are independent, loosely coupled, highly maintainable, and testable. With microservices, you can break down each subsystem of your OMS like inventory management, cart checkout, and order management as well as assign each module to independent teams.

Each service is independent of the others but they can communicate and integrate through an API, passing data payload to each other. These services are then abstracted from the frontend via an API interface so that the frontend can easily communicate with the modularized backend.

If you’re planning to build your own OMS, specialized development teams are needed for each module. This means, the inventory management module is only handled by the inventory management team, while the order fulfillment module is only handled by the order fulfillment team. Each service then exposes API endpoints for other services to connect to, and the collection of these services forms your OMS.

Building your own OMS involves a lot of manpower, additional resources, and development time, and takes a long time to build out. This approach may not be ideal for an industry where speed and agility is crucial to your success. If you want a solution to your OMS quickly, you’ll need to opt in to a third-party solution like fabric, where the development has already been done for you.

With fabric, the independent modules for your OMS are ready to use. You can then access these services through your API and connect to your frontend. fabric kick-starts your development time and saves you operational costs in the process. It has several headless solutions for enterprise-level e-commerce, including an OMS, which is made up of several modules including the Orders API, Inventory API, and Cart API.

Before you switch to a new OMS system, you need to prepare for the changes that come along with switching management systems, including planning for technical flexibility and consistent data sanitization.

Adherence to best practices and legal compliance

Legal compliance is a very key part of building a platform. You need to be able to adhere to data and security laws like GDPR and PCI-DSS compliance. There are also best practices for security like the OWASP application security checklist. If you’ve used a tool like fabric to build your OMS, this stumbling block is automatically taken care of for you.

Planning for technical flexibility

A growing e-commerce business needs a highly configurable and flexible OMS that can scale on-demand. However if you have a built-in solution, this isn’t an option since you can’t configure the backend.

If you build your own OMS, it’s ideal that you design your backend with a microservices architecture that was discussed above. This approach is easy to test, manage, and scale.

The beauty of microservices is that when one service of your system suddenly requires additional computing power and resources, you can specifically scale only that module, without affecting other services. This is more efficient than a monolithic approach where you have to scale everything, even the services that don’t need it.

Strong validation of data

Security is a crucial part of any e-commerce business. Data validation on the backend is one of the security measures you need to think about before changing your OMS. You’ve probably heard the phrase, “never trust your users” or, in other words, “don’t trust the data sent by the frontend.” Once your frontend has been loaded into your user’s devices, you have no control over what they do and malicious users often take advantage of this.

The backend must perform repeated authentication checks before it accepts the data and the client request. If you’re building out your OMS, you should include a security team and adopt the DevSecOps development strategy, so that important security measures are added early on in the DevOps process. And for that, you must have in-house penetration testers to secure your OMS. This will take additional time to develop, in addition to running multiple security checks and patches prior to release.

If you purchase an OMS solution like fabric, it manages these security measures for you so you don’t have to worry about your backend being compromised.

Consistent data sanitization

Data sanitization must be included in your OMS to protect your users’ data and prevent identity theft. It wipes out and completely removes data (especially sensitive data) that was unrecoverable by forensic tools.

If you’re building your own OMS, you need to consider this process so that you don’t compromise the safety and security of your users. With a tool like fabric, data sanitization is already built-in to prevent injection flaws, broken authentication, and sensitive data exposure.

Managing and formalizing a change request process

As your business continues to grow, your OMS will need to grow with it. If you choose to build your own solution, you’ll need to constantly change and update your OMS to adapt to your growth.

Change requests are often complicated and can involve the following steps:

1. Understanding the scope of the change: you must clearly understand the exact changes and the related data needed for the change.

2. Understanding the impact of the change: the requesting party and other stakeholders must understand how the change will affect the existing OMS to prevent unexpected side effects and notify all parties of the intended changes.

3. Approval/disapproval request: once a request has been identified and changes have been clarified, it must be approved before being developed.

4. Communicating the request and implementing the change: once everything is clarified and approved, then the developers are notified and the change process begins.

The project manager or owner may manage or facilitate this process, and communicate it to each stakeholder.

Access management

To ensure employees only have access to items pertaining to their job, it’s important that your OMS supports role-based authentication. When your staff logs in to your OMS, their access must depend on their role.

When building your own OMS, you need to consider having a staff policy to define what each employee can and can not do. If you choose to integrate a solution like fabric into your OMS, you get access to an Identity API for user creation, logins, password changes, etc. Within your own app, you can leverage this to create roles for employee access.

Accommodating customer feedback

It’s common for e-commerce businesses to have a reviews section, as it builds trust with your customers, and helps them through their decision process.

If you’re planning to build your own OMS, you must dedicate an entire development team to develop your reviews module and integrate it into your OMS. You would need to build in the functionality for users to upload pictures and videos for their review and let them write a review of a product. Also, it’s ideal to add a rating system, commonly through stars, where one star is the lowest rating, and five is the best. In addition, it’s nice to display the verified purchase badge to filter out spam reviews.

Creating reliable documentation

Providing documentation is a common practice in software development, and API documentation is crucial to building an API. On the backend of a modularized OMS, the services are abstracted with an API interface. Documentation of this interface helps your development team understand how to communicate it to your services.

fabric provides organized API documentation for its services. For their OMS services, each API module documentation groups every related endpoint with details like how to use them, an example HTTP request, and the different responses sent by a particular endpoint.

Enabling autonomous change by business units

A monolithic software is composed of an interconnected and highly-coupled system that makes up the entire software system. If you need to configure one part of your software, there’s a chance that it can affect other parts of the software. If you wanted to test it you’d have to test the entire system, making it hard to do so and risky to configure.

Microservices architecture is a great solution to this problem, especially for large software systems. Since the microservices architecture breaks down a software system into different independent modules, if one part of your OMS system needs to be configured, you can easily do so without the risk of impacting other systems, and you can test them all independently.

Implementing incremental change

Growing your e-commerce system involves continuous and incremental changes to your OMS. If you’re working with monolithic software, you’d have to test the entire software and ensure it wouldn’t affect other areas of your service.

With a microservices approach, an incremental change is easier since you can independently configure each module of your OMS, and then test them independently. For example, you can easily add new products, categories, variants and inventory. The APIs also let you test different units of your OMS separately after you’ve added a change. You can decide to test using the Inventory APIs as a standalone without touching the Orders API.

Testing procedures

As previously stated, testing in a microservices architecture is easier because the modules are independent of one another. When testing, you can approach with a test-and-learn philosophy which lets you pilot some features with real users, analyze the results, and use those insights for the next iteration of your development. fabric offers a sandbox environment that can be used to test your application in a non-live environment safely before launch or when adding a new feature.

Modular commerce

Modular commerce is the modularization of the e-commerce system by breaking down the monolithic software. This is exactly what a microservice architecture achieves by isolating each system and process of your e-commerce, giving you more flexibility in development and testing. It also makes your e-commerce system more secure since each system is isolated from the others.

fabric also implements this modular approach and gives you an API interface for all your backend needs. For example, fabric OMS is composed of individual API modules which interface with the different OMS systems so that you can easily communicate to your modularized backend, making your OMS modularized and flexible.

If you were building your own solution, modularizing your e-commerce system could take months or even years.

---