“Can you help package up my decision model to get it running in a business process? Here is my ZIP file.” The inquirer is an operations researcher or a decision scientist. The recipient is you, the software engineer. If you haven’t participated in a conversation like this, it may be in your future.
Mathematical optimization and decision science are growing disciplines that power applications for anything from sustainable package delivery to product manufacturing, worker assignment, course timetabling, and more. This means more and more technical teams are faced with integrating decision models into their software stacks — and doing so is not usually a straightforward process. Ask me how I know!
While I spent more time than I like to admit in grad school in operations research, I started my career as a software engineer. I have seen and lived both sides of this story. Today, I spend a lot of time interacting with decision modelers and software engineers on how to improve the way they integrate models into business processes and collaborate with Nextmv. As a result, a decent list of good-to-know items about decision science < > software engineer interfaces has emerged. In this post, I’ll do a quick flyby of OR as a discipline and then dive into a handful of our listicle items. Here goes.
What is OR? Engineering’s version.
Were we in person or on a video call, this would be the moment I’d reach for my shelf to show you several hardcover books about operations research. (Insert sound of the book spine crinkling open.) Unfortunately, this isn’t the case. Instead, I will give you a few basics to get you familiar with this decision modeling business.
Operations research (or “OR” for short) is a form of applied mathematics dating back to the 1940s. As you’ve probably noticed, it can go by other names: mathematical optimization, ops research, operational research (in the UK), optimization, decision science, decision modeling, industrial engineering, etc. I typically default to using a combination of optimization, ops research, and decision science.
Optimization is the search for the best plan given an objective (business KPI) and a set of rules to adhere to. The result is the plan or a decision for the operation to enact in real life. For example, find the best routes for drivers to deliver all packages while keeping travel distance as low as possible. This extends to a whole host of applications: power grid management, compute resource allocation, battery swapping, mobile healthcare scheduling, and pet food formulation.
That should be enough to get you started. Now, let’s look at some of the concepts worth knowing when OR starts appearing in your world.
1. A model formulation is not an API
Decision models are solved using sophisticated algorithms that are usually built into an engine known as a solver. That solver has some form of an API. The solver needs the model formulation and data in order to operate. To put it in even simpler terms: The model formulation tells the solver what space to search. It doesn’t define an API or help with other types of interoperability.
From a software perspective, you’ll need to address this interoperability with your systems. This means figuring out how to pass data into this model (e.g., data format and frequency), getting data out of the model, and exposing options such as turning on and off constraints or managing coefficients for the model. You’ll also need to expose options (and likely logging) for the solver.
Note that none of this is “set it and forget it.” Models change over time due to changes in the real world and data drift. Solvers often get swapped out and exposing options will look different depending on which solver gets used.
Takeaway: You’ll likely be responsible for building out and maintaining a bespoke API layer for decision models. This helps with basic integration into your software systems, but also supports model monitoring and observability, and sets the modeler up to manage the modeling details (as they should — you don’t want to do that!).
2. Time is not linear for decision models
Many things in software engineering have a rhyme and reason to them. That doesn’t mean they are simple. That doesn’t mean they always behave. (Often they do not because computers.) Take a database, for example. Querying 10 records, 100 records, or even 1 million records is a predictable process. You can look at the structure or the plan of a query and understand how complex a problem is.
This pattern is not guaranteed with a decision model. There may not be a direct correlation between input file size and runtime. For example, going from a small routing problem with 100 stops to a larger routing problem with 500 stops may have an exponential effect on run time. Sometimes very small problems are extremely hard to solve. You can’t easily see the complexity that’s causing seemingly weird or unpredictable behaviors like you can with most standard software applications.
With this in mind, you also have to be aware of how urgent a decision is. What’s the SLA for how fast the business process needs the decision to operate and how long does the model need to produce a decision? For example, if you are scheduling workers for your business on a weekly basis, an hour-long optimization is probably suitable. But if you’re assigning meal deliveries to drivers, you probably need a solution in under a minute. Similarly, you’ll have to think about your infrastructure’s limitations. For example, you can’t run a decision model that takes 20 minutes to find a solution on a Lambda that times out at 15 minutes. This results in a no-decision-made situation, and now your pipeline is backed up with piles of indecision.
Takeaway: Ask lots of questions about time: model formulation time, solve time, business SLAs, infrastructure SLAs, etc. Map out the timing of other systems upstream and downstream of the model such as machine learning models producing forecasts.
3. You need a model “preview mode”
Testing is important. You write code, you test it, find a bug, fix it, and move forward. Now that’s not to say big mistakes aren’t possible. They are. But, in the optimization world, small changes to a decision model constraint or solver option can have unexpectedly dramatic consequences. Having robust ways to preview how a model might behave, especially when it’s making important operational decisions, is critical.
This often means software teams get tasked with standing up and maintaining testing infrastructure in addition to the production infrastructure that underpins everyday business processes. There are several types of testing, each with different execution profiles. An acceptance test might be run with every PR, whereas scenario tests might involve 10s or 100s of simultaneous runs. Online tests like shadow and switchback run alongside or within real-time processes on production hardware. This requires a whole other setup with different requirements, run cadences, etc.
And it’s not just the execution hardware you’ll have to consider. Testing involves other building blocks that your ops researchers will ask for support in building out, such as features to manage input sets, handle test randomization, results visualization, and more.
Takeaway: Identify the testing types the modeling team wants to conduct and how. How do tests integrate with CI/CD workflows? Does the team want a separate test bench? Who needs to review tests — business users and technical users? Testing infrastructure allows your team to launch and iterate quickly across domains with lower risk. It’s worth considering how you’ll make decisions reproducible and how test datasets get shared across the team for consistency.
4. Not all ops researchers are Git-familiar
Just as you are trained in system-level tools like Git, Unix, and AWS, folks in OR have their own discipline-specific tooling — and it likely doesn’t include Git. Similar to how data scientists apply statistics principles to data for predictions, ops researchers have learned to use things like Gurobi, CPLEX, and simulation software, which are tools oriented toward what they’re specialized in: translating real-world requirements into math expressions.
As a result, it’s not uncommon for an ops researcher to be used to handing over ZIP files with their scripts and model formulations for you to operationalize. Git-based flows are a powerful pathway for streamlining how you share and collaborate on code specific to OR. Just know this may not be common among ops researchers.
Takeaway: Take some time to work with your ops researchers to identify ways to integrate them into Git-based flows to get all the benefits of CI/CD, model versioning, and more. Even if a model is strategic and only runs every 6 months, having a system of record matters! Similarly, take some time to learn about the tools they’re familiar with. Meet in the middle — the weather’s nice there just about any time of year.
5. Prepare to support multiple solver packages
The field of operations research includes a variety of solver packages: a rainbow of mixed integer programming (MIP) solvers, a potpourri of heuristics solvers, some are commercial, some are open source, etc. Each of these solutions come with their own special license structure and mechanism. Among OR practitioners, it's common to prototype with an open source solution and then graduate to a commercial one — and then apply or try multiple options from there.
Takeaway: From a software perspective, you'll need to embrace and manage the OR team’s multifaceted approach. This means you need a way to support multiple runtimes, various input formats (MPS, CSV, JSON), different operating systems and architectures, license types and managers.
Where to go from here
I write this post not to overwhelm folks, but to inform and share a bit of background on what it takes to get these models up and running. I've seen how the struggle to collaborate across teams keeps projects from making it off the ground — and it's easy to understand why. Software teams typically are tasked with juggling multiple priorities and supporting multiple teams. While that sounds painfully generic, it’s true. Adding optimization into any business process can yield meaningful outcomes in terms of time saved, productivity, safety and quality, and customer satisfaction that can’t reasonably be achieved through other means. Efficiently integrating optimization into modern technology stacks is challenging. But it doesn’t have to be.
This is why we built Nextmv. We’re helping teams build more decision models, not more decision tools. That means decision modelers can create, expand, iterate, and improve on their modeling. Software teams can easily integrate and monitor decision models without diverting valuable resources to building out and maintaining bespoke infrastructure. Nextmv has all the pieces teams need to optimize investments in optimization. It’s the GitHub-meets-Segment-meets-Huggingface for decision models.
If you’d like to try it out, you can create a free account. If you’d like to hear more, check out this talk from my cofounder. May your solutions be ever improving 🖖
