📈 #96 DecisionOps: engineering the way the world decides

What DevOps did for code and MLOps did for models, DecisionOps will do for decisions.

Just five months ago, there was a talk at EURO Practitioners’ Forum about a mindset shift.

I attended it carefully, as the concepts were meaningful. Not only to me, but to the whole field of Operations Research.

The talk was given by Matthias Als, Lead Data Scientist at ECCO, and it was brilliantly articulated around DecisionOps.

Matthias came to say that OR models are mathematically sound but operationally fragile, for many reasons. And that new discipline is here to help.

It might sound that DecisionOps is to OR what MLOps is to ML, but it’s not just renaming.

That’s why today in Feasible, we’ll see:

• ⏲️ The time for DecisionOps has come

• ♻️ The DecisionOps lifecycle

• ⏭️ The path forward

Are you ready? Let’s dive in… 🪂

⏲️ The time for DecisionOps has come

Optimization used to end when the solver returned a solution.

That’s what we were told at university.

But that’s not real-life Operations Research. And if we’re looking at an agentic world -where AI systems and humans make decisions continuously- optimization is no longer a one-off event. It’s continuous infrastructure. And when infrastructure fails, businesses break.

Every decision becomes a production event.

That demands something new: a discipline that treats decisions like systems. Versioned, tested, monitored, explained.

That discipline is DecisionOps.

It’s not a buzzword, it’s the next layer of decision reliability in Operations Research.

The term is gaining traction, and the practices are real.

But there are at least three points that highlights its importance.

🏔️ The deployment chasm

For decades, there has been a lot of manual workflows when deploying OR solutions.

Testing in Excel. Sending the code by email. No monitoring.

This erodes trust as algorithms are seen as opaque decisions instead of tools to rely on and help speed up decision-making processes.

There hasn’t been a systematic deployment methodology as academia was more interested on teaching algorithms and getting to mathematical perfection rather than operationalizing what’s really useful for the industry.

And when we try to mirror Machine Learning workflows, we see the difference.

Lots of tools there, just a couple here.

Lots of tutorials there, one or two here.

Practitioners preaching about good practices there, almost no one here.

I know, I know. ML and OR are different disciplines. Does that mean we need to treat OR differently in this aspect too?

🤏🏻 What makes OR different from ML

One thing that ML and OR have in common, especially in the late months/years, is explainability.

While ML explainability asks ‘what did the model learn?’, OR explainability asks ‘why is this optimal and why not that alternative?’.

Machine learning models need tools like SHAP to reverse-engineer learned patterns. Optimization models have explicit logic embedded in constraints and objectives, but that transparency only helps if you can communicate it.

Hard constraints cannot be violated (there’s no 95% feasible solution concept), and sometimes that’s difficult to explain to stakeholders.

Apart from that, ML and OR differ in several ways.

I’ve never heard “why this model predicted this class with that accuracy?”, but you face similar situations in OR every-single-day: “Why did my driver get this route?”, “Why can’t we squeeze in one more delivery?”, “Why is the solver saying this is impossible?”.

That explainability is business-critical as you need to justify why the model took some decisions to stakeholders.

So instead of monitoring model drift (when your production data distribution changes from your training data, causing prediction accuracy to degrade over time), you need to monitor problem characteristics through scenario testing.

Your routing model might historically have handled 100-200 orders, now it gets 500.

Your scheduling model assumed 8-hour shifts, now you have 12-hour shifts in the new market the business is operating on.

Your pricing optimization model was tuned for stable costs, now costs are volatile, producing solutions that make no sense to the business.

💸 The cost of inaction

There was a conversation between Hexaly’s CEO, Fred Gardi, and Nextmv’s CTO and co-founder, Ryan O’Neil, where Fred argued that:

During the past decades, OR has suffered to be taught as a mathematical discipline in my opinion. Too much emphasis on math, algorithms, and not enough on IT, software engineering, and project management best practices.

It resulted in a poor execution in OR projects, with very expensive projects, if not project failures. Despite progress in the last decade, OR lacks an established, practical methodology and tools which implement such a methodology.

Nextmv fills this gap. Nextmv helps developers to execute their OR projects better and faster.

Cannot be more accurate.

There’s an academia-industry divide I’ve written about before several times. The last one, in this open letter I made.

Academia focuses on theoretical soundness while industry needs maintainable solutions that work with messy data, accurately, and over time.

But there’s a new elephant in the room. It’s going to come sooner or later, and we need to be ready for that.

Yes, AI agents.

AI agents are increasingly deciding, not just predicting.

Optimization engines are being embedded into workflows and systems that run without human supervision.

That means:

• Failures propagate instantly.

• Trust becomes infrastructure.

• DecisionOps becomes indispensable.

The future of OR isn’t just better models, it’s better operations around those models.

We won’t just build optimization models anymore.

We’ll operate decision systems.

♻️ The DecisionOps lifecycle

DecisionOps formalizes the continuous loop that connects model outputs to business outcomes.

It makes decision systems iterative and auditable, rather than episodic and opaque.

It’s the set of processes, tools, and principles that allow organizations to build, deploy, test, and monitor decision models reliably and continuously.

If DevOps brought agility to code, and MLOps to machine learning models, DecisionOps brings it to optimization and decision intelligence.

As stated by Matthias in that ECCO talk, it’s not just a specific technology stack. It’s about how we manage the lifecycle of decisions, not which technology produces them.

It sits at the intersection of:

• Operations Research, which defines how to make good decisions,

• Software Engineering, which ensures they run reliably, and

• Decision Intelligence, which ensures they make sense in context.

It’s a mindset shift where you…

1. 🧪 Experiment and version-control every change to make it traceable. You must track configurations, datasets and outputs so you can reproduce every possible run. It also enables side-by-side comparison of results.

2. 💉 Test. If code can be tested, constraints and objective functions can too. Testing decisions means verifying that every rule behaves as intended.

3. 🚢 Deploy. Models are only valuable when they can act. Deployment in DecisionOps means moving from “runs on my laptop” to “runs reliably for the business”. APIs, containers, and automated pipelines are the ones governing this part.

4. 💻 Monitor. A decision doesn’t end when it’s made. Monitoring closes the feedback loop: track solutions (quality, time, violations) and visualize KPIs for non-technical stakeholders.

In practice, this creates a continuous workflow:

0. LOCAL DEVELOPMENT
├─ Write model formulation
├─ Test locally with sample data
└─ Version control

1. EXPERIMENTATION & VALIDATION
├─ Run scenario tests (different inputs, params)
├─ Compare solutions side-by-side
├─ Track experiments
└─ Validate with stakeholders

2. QUALITY ASSURANCE
├─ Push code to Git repository
├─ CI pipeline triggers
├─ Automated tests run
└─ Build passes ✓ or fails ✗

3. DEPLOYMENT
├─ Package model
├─ Deploy to production environment
└─ API endpoint becomes available

4. PRODUCTION & MONITORING
├─ Applications call API with real data
├─ Solutions returned to business systems
├─ Logs track performance (solve time, quality)
└─ Alerts trigger if anomalies detected

5. ITERATE
└─ Feedback loop: monitor → analyze → improve → repeat

Whether you’re using open-source tools, a dedicated platform, or something in between, the pattern remains the same: develop locally → test systematically → deploy automatically → monitor continuously.

⏭️ The path forward

Up until this point, we’ve discussed why DecisionOps is important and what exactly it is.

We’ve seen that DecisionOps ultimately is a mindset shift.

But if it mainly is a mindset shift, are there any tools that make your life easier?

Yes, and the good news is most of them already exist.

You don’t need to wait for a perfect ‘DecisionOps platform’ to appear. You can start today with adapted tools from MLOps and DevOps, plus a few OR-specific additions. Here’s the minimum viable stack for each of the four tasks: