Five considerations for Custom Versus Off-The-Shelf SaaS eCommerce Middleware

So you’ve decided to deploy or migrate to a leading, true SaaS eCommerce platform (of which there are really just two: Shopify Plus or BigCommerce) and you find yourself having to decide how to approach the custom integration data flows that will inevitably be needed to support certain components of your commerce experience. And someone says “Should we use middleware?”

Middleware, sometimes called electronic data interchange solutions or platform integration solutions, is either a custom or pre-built solution to standardize the exchange of data between two disparate digital systems. A typical example would be moving order information from your eCommerce platform to an ERP solution, to support downstream use cases of that data like inventory aging, fulfillment, reverse logistics, forecasting, and accounting.

There are many off-the-shelf (OTS) solutions available: Capterra tracks 124, with the market leaders being MuleSoft’s Anypoint, Cin7, SPS Commerce Fulfillment, Dell Boomi, and TrueCommerce. And just as many organizations that use OTS middleware use custom solutions.

First, it’s important to understand what the pros and cons are of both off-the-shelf middleware and custom approaches. Neither is a better approach, both work better than the other depending on the use case. You need to start by identifying your strategic priorities, institutional strengths and weaknesses, and critical use cases.

The high-level pros and cons for off-the-shelf middleware are: 

Pros:

• Works great to distribute one data source to many known channels
• Offers pre-built functionality
• Provides a framework
• Throws the best vendor parties  

Cons:

• Strong guardrails (assumptions)
• You end up removing more than you add
• You have custom needs, you will end up having to write custom integration code
• Vendor lock-in

Alternatively, for a custom middleware you have the following breakdown:

Pros:

• Highly performant
• Easier to troubleshoot, lightweight codebase
• The high degree of flexibility
• Code framework
• Control hosting, and host anywhere

Cons:

• Less defined framework than off-the-shelf solutions
• More knowledge transfer for hand-off if an internal team already has expertise in an
• OTS middleware Requires self-hosting

You need to evaluate the pros and cons of OTS versus custom for eCommerce middleware and work through five crucial considerations.

Consideration #1: What would be the size of your custom middleware footprint?

Forget what kind of integration layer you have today.

Your decision to move to a modern, leading SaaS eCommerce platform means that you are going to be replacing every component of your existing stack with a decision between configuration or custom. If you can work with the inevitable limitations built into a given app at the SaaS eCommerce layer (say, for your email service provider), go configuration. You will save hours on the build and with ongoing support.

But if you genuinely need more complete control, and having that control allows you to extract greater value in the commerce experience (CX) than the cost to build and maintain the custom integration, go custom.

Now that you have an estimate at the size of the custom footprint, how large is it? Remember: The cost of supporting a custom middleware grows exponentially with its footprint. A small middleware requires a modest level of support. A larger one takes far more effort.

Consideration #2: Consider the cost of vendor lock-in 

Every OTS middleware platform has a cost for vendor lock-in. That isn’t inherently good or bad. You have plenty of hosting solutions you pay for and are happy to pay for because they add value to your ability to execute as a business.

This consideration is more about the reputation of the vendor cost over time, and the perception of the value obtained. To determine this you need to talk to some customers of the technologies, but more importantly, read reviews of the solution online.

Why bother with this? Well, don’t forget that joke about Salesforce (which owns MuleSoft): That the only people in an organization happy with their Salesforce bills are the people that don’t see them.

Consideration #3: You can’t have guardrails everywhere

If someone tells you a system or custom solution doesn’t have trade-offs they aren’t a disciplined thinker. Harsh, but true. Every system has trade-offs. The trick is to optimize for the ones that are least important to your business objectives.

A SaaS eCommerce platform offers tremendous value to merchants by making some assumptions and making some things about the platform unalterable. This is why you can do in Shopify Plus or BigCommerce for $150k what takes $350k in Magento and $500k in Salesforce Commerce Cloud. You save money, but you have to accept guardrails.

Every OTS middleware solution has guardrails because that is what they do to offer built-in functionality that can, in certain use cases, save you considerable effort. A SaaS eCommerce platform is going to interact heavily with your middleware layer, and if both have strong guardrails you may not have the flexibility you need somewhere in the stack to build an effective technology solution.

Think about it this way: The Monkees and The Beatles had the same guardrails in the same era: music (there are set scales and notes) and instruments. But The Monkees were the creation of a corporate marketing team, layering on the second level of guardrails that The Beatles never had. Now, don’t get me wrong I love the class Monkees hits but, the question for every merchant is, do you want to be The Monkees or do you want to be immortal?

Consideration #4: You aren’t alone

To protect their confidentiality we can’t identify merchants in this post that use OTS middleware and those that use custom. But be assured we can fill a page of terrific merchant brand logos that use custom middleware and just as many that use OTS middleware.

You aren’t alone.

Consideration #5: Middleware is a company-wide decision, not just eCommerce

An eCommerce migration or deployment is often the first time an organization considers a middleware layer. It makes sense, given how much data flows between a commerce experience layer and a variety of backend systems. And it is easy to focus your middleware evaluation and decision matrix only around eCommerce.

But we feel this is a strategic mistake. Organizations looking to adopt OTS middleware ought to select a single solution to be used across the organization, for all data flow use cases, eCommerce or otherwise. This standardization is crucial because this becomes foundational technology to support and serve disparate parts of the business and data needs.

Think of this like selecting a telephony solution: Yes, you need one solution, but that doesn’t preclude some folks from using their personal cell phones, deploying special handsets for your customer service reps, offering desk phones for in-office workers, and using special routing for your on-call field services team.

If you focus your evaluation on eCommerce alone you will miss crucial considerations that will come up later as the OTS middleware inevitably grows to include more integrations.

What if you settle on a small custom middleware in the first phase of your SaaS eCommerce rollout? Simple! Defer the decision. A lightweight custom middleware can be replaced or wrapped easily, later, by an off-the-shelf middleware solution.