Mathematical optimization

Mathematical optimization finds the best decision among all the decisions that are possible. You state what is being decided, what restricts those decisions, and what best means; a solver then searches that space and returns a solution it can prove is optimal, or tells you that no valid solution exists.

Getting to that point requires a model: a precise description of the decisions, the restrictions and the goal. Writing one has traditionally been specialist work, which is the step Modeler is there to take on. This page covers what a model is, what it is used for, and which part of the job remains yours.

Prescriptive, not predictive

Optimization is most often confused with machine learning, and the distinction is the fastest way to see what it is for.

Machine learning is predictive: trained on historical data, it tells you what is likely to happen next. Optimization is prescriptive: given a goal and a set of restrictions that describe your situation, it tells you what to do about it. Knowing that demand will rise 8% next quarter is a prediction; deciding which plants produce which products, and in what quantities, in response is an optimization problem.

Three practical consequences follow:

  • You declare rather than implement. In machine learning you define a process and the data drives what the model learns. In optimization you declare the decisions, the constraints and the objective, and the solver finds the solution.

  • Data is used differently. Machine learning needs large volumes of it to find patterns. Optimization uses data as the values inside a model whose structure you have already defined — a shipping cost, a plant capacity, a demand forecast.

  • They compose. A prediction is a natural input to a decision. Forecast demand with machine learning, then optimize production against that forecast.

Where it applies

Optimization applies wherever a limited resource has to be allocated and there are too many possible allocations to compare by hand. Logistics, production planning, scheduling, supply chains and portfolio selection are the established fields; see Gurobi’s industry pages for how it is used in each.

The same problems occur in software engineering, which is why the examples in this guide are grouped that way:

  • Classic OR problems — facility location, workforce scheduling, the diet problem, portfolio selection. The textbook formulations, worked through the Intelligence Hub.

  • DevOps — scheduling deployments for minimum user impact, assigning workloads across heterogeneous machines, prioritising machines during incident response, selecting test configurations for maximum coverage.

  • Backend — routing traffic across a microservice topology for latency and cost, selecting ads against a revenue and user-experience trade-off, scheduling A/B tests, dynamic pricing.

  • Data engineering — Kafka partition assignment, Snowflake clustering keys, storage allocation across warehouses.

Note

Gurobi runs on this internally too: our own CI/CD uses optimization to select which machines tests run on and which environments to build. That problem is worked through in Testing strategy optimization.

What a model is made of

Four components, and every optimization model has all four. They are worth knowing by name because they are the vocabulary of the specification Modeler builds with you.

  • Decision variables — what you are choosing. A production rate, a machine’s on/off status, how many units ship along a route. A variable’s domain can be continuous (1.034), integer (34) or binary (0/1); which one you pick matters, since a model that lets you build 2.4 warehouses answers a different question than the one you asked.

  • Constraints — what makes a set of decisions valid. No more than three engineers on any shift, at least 100 units in inventory at all times, each warehouse is served by exactly one plant.

  • The objective — what best means, as a single quantity to minimise or maximise. Minimise total cost, maximise service level.

  • Parameters and data — the values that make the model describe your situation rather than a generic one: costs, capacities, demands, distances.

The data belongs outside the model

The structure of a model and the numbers it runs on are separate things, and keeping them separate is what makes a model reusable.

State the problem in general terms — determine how much of each product is produced at each facility — and the constraints describe a pattern that holds for any number of facilities and products. The specific list of facilities, the capacity of each and the demand per product are input: a spreadsheet, a database query, a CSV. Open a new quarter with new figures and you change the data, not the model.

The alternative hard-codes values into the logic, and the cost shows up on the first change: a new facility means editing constraints, and every edit has to be re-tested. This is the difference between a model and a script.

Modeling is the step that takes the expertise

Building an optimization model by hand draws on three distinct skills:

  1. Domain knowledge, to turn a business problem into an objective and a set of constraints.

  2. Mathematics, to express those as a formulation.

  3. API fluency, to implement the formulation in code and extract the results.

The second and third are what keep optimization out of reach for most teams that would benefit from it — they take years of training, and the people who have that training are rarely the people who own the business problem. But all three are translation steps, and translation is something a capable agent can do.

That is the role of Modeler. You supply the domain knowledge; Modeler asks what it needs to know, records the answers as a specification in business language, and derives the gurobipy implementation and the tests from it. The mathematical formulation is produced only if you ask for one — nothing in the workflow requires you to read it.

What remains yours

One thing does not transfer, whoever or whatever builds the model: deciding whether it is the right model.

A correct implementation of a misstated problem still returns a confident, wrong answer. So the model has to be reviewed against intent — do the variables cover every decision that is actually being made, is every restriction in the problem represented, do the results make sense for the business. Structural assumptions that are obvious to a person are the usual omission: a machine cannot process two jobs at once, a worker has to reach the site before starting. Left unstated, they get guessed.

Expect this to take more than one pass.

Note

Knowledge of a business process is rarely held by one person. It is normal for new constraints to surface each time another stakeholder reviews the model — and for the problem statement to keep growing as they do.

The methodology is built around that: the specification is written in business language precisely so that the person who owns the problem can check it, and the workflow is a loop that stays open for the constraint nobody mentioned in the first conversation.

Learn more

Background reading, for going deeper on optimization itself rather than on the Intelligence Hub:

Next

The methodology covers the workflow behind every example in this guide.