I talk to a lot of teams about decision automation and how it fits into their decision technology stacks for vehicle routing, staff scheduling, budget allocation, and more. Central to those conversations are optimization solvers, the underlying tech for generating decisions and searching through them for optimized solutions to these complicated problems.
Over time, it’s struck me how often it seems that not everyone within a team truly understands the nature of the solver technology they’re using. A typical conversation may go like this:
“What optimization solver are you using?”
“We’ve built our own in-house solver!”
“Oh, cool! What kind of solver did you build?”
“It’s a combination of [insert open source or commercial solver here] and custom, in-house heuristics.”
To me, this person is actually building around and extending existing solver technology and not building a net new solver from the ground up. So while they are not building a solver, they are formulating a model. And with the work that entails, it's easy to see why it feels like they're starting from scratch. These conversations got me thinking about the general solver options available today and our experiences with them. So let’s have a look.
Option 1: Build around open source or commercial solvers
Most teams are doing what I described above: they’re leveraging a combination of open source or commercial solvers, perhaps with a little heuristics on the side. In many cases, they extend the capabilities of those solvers to meet their business needs, but they don’t actually build the underlying solver tech themselves.
One way I’ve seen this play out:
- An operations research (OR) specialist builds a decision model in Python to work with a mixed integer programming (MIP) solver
- The dev team sets up a microservice wrapped around said decision model
- The SRE team integrates the microservice into CI/CD using Jenkins (since model-level CI/CD doesn’t exist)
- The service gets deployed to production
- The model (and decision automation logic) remains unchanged indefinitely since the devs likely don’t understand how to work with the model logic
- The rest of their software infrastructure adapts to support changes in their business and the model remains static
As a result, operational decisions start to fall out of line with business objectives until the teams decide to restart the multi-month (often 4 to 6 months, actually) process all over again.
This works for the short term. Many of us at Nextmv have direct experience with this process. We’ve seen how fast and powerful these open source and commercial solvers can be. The downside is that they often come with an incredibly steep learning curve, require a great time investment for the business-logic-to-math translation, and lack the testing and deployment capabilities needed to quickly ship decision automation for today’s operations.
Option 2: Piece together decision-specific APIs
Decision-specific APIs focus on making decisions in a specific domain, such as vehicle routing or scheduling. So If you have a vehicle routing problem, you have one set of options. If you have a workforce scheduling problem, there is another set of options. If you have a binning problem, there are options for that. But if you have a combination of all three or more, what then?
Some teams glue together different tooling as best they can. That comes with a cost of added effort of semi-integration and context switching between tools. It’s not unlike the challenge the observability and DevSecOps spaces faced before the industry decided that logs, metrics, and traces were better collected and analyzed together rather than apart.
At first, it may make sense to choose specific tools for individual decisions. But as a business grows and gets more complex, that’s where managing multiple decision-specific APIs becomes less efficient for your business overall.
Option 3: Build a home-grown solver
Almost no one builds their own solver from scratch. It requires extensive knowledge of solving paradigms. It also, quite frankly, requires a lot of work. MIP and constraint programming (CP) solvers have code bases that range from 300,000 to 1,000,000 lines or more. Like search engines and databases, it’s much easier and more pragmatic to pick up something existing rather than starting from a blank canvas.
That said, there are reasons for why you might want to try your hand at solver building. It often comes down to having an incredibly custom and complex problem and having the talent, teams, time, and resources to tackle it. There are only a handful of companies in the world this applies to, and even most of them don’t go this path.
A new option: Work with decisions as code
Having worked with tooling from each of the options up above, we at Nextmv, wanted another choice. We wanted a platform with a solver core that worked better with modern technology stacks, was multi-paradigm and multi-decision, and felt more like regular software than math so that any developer could become a decision engineer.
That’s why we built a decision automation platform (with our own hybrid solver core) that allows developers to quickly build, test, and deploy decision engines in modern tech stacks at speed and scale. Nextmv is not a decision-specific API. Instead, it works across decision domains, allowing for multi-decision flows within a single solution. Nextmv is not math-based and limited to hyper-specialized talent. Instead, it exposes decision models and solving techniques through code and in a developer-friendly way.
The key is in enabling developers to work with decisions as code. In doing so, Nextmv gives teams the ability to own and customize their operational decisions because they’re building on top of Nextmv’s decision infrastructure.
We believe that in knowing your solver, you can better understand what opportunities and limitations are ahead of you as you grow and operate your business. Does it allow you to adapt to changes quickly? Does it scale with your demand and diversity of decisions? Does it give you ownership over your decisions?
With Nextmv, we’re building a decision automation platform that is easier to use, understand, customize, test, and deploy. This not only increases the ability of teams to build and scale decision-based solutions, but it also opens up a new landscape of decision engineering creativity and opportunity.
