What Sudoku Teaches Us About Enterprise Software

Why I Started Thinking About This

Every time a new problem hits: tariffs change, capacity tightens, labor gets constrained, enterprise software vendors show up with a "purpose-built solution."

Tariff optimizer. Rough-cut capacity planner. Labor scheduling engine.

Different names. Same math. New invoice.

At some point, I started wondering: are these actually different problems, or are we just changing the labels? That question led me to an experiment. Could a network optimization algorithm solve something completely unrelated to supply chains, like Sudoku?

It turns out, it can, and that changes everything.

A Technical Detour: Solving Sudoku with Network Optimization

Let me be explicit: a network optimization algorithm has no idea what Sudoku is.

It doesn't understand numbers, grids, or puzzles.

It understands decision variables, constraints, and objectives.

That's enough.

At a high level, a Sudoku puzzle can be modeled as:

• Decision variables representing whether a number is assigned to a cell
• Constraints ensuring each number appears exactly once in each row, column, and subgrid
• An objective that simply finds a feasible solution

There are no flows, plants, or warehouses here, just structure.

But the same Sudoku can also be expressed explicitly as a supply chain problem.

Allow me to be a bit technical.

There are 81 customers, representing the 81 cells in the puzzle: R1C1, R1C2, …, R9C9.

There are 9 vendors, V1 through V9, each representing a number from 1 to 9.

The decision is to determine which vendor supplies which customer, in other words, which number is assigned to which cell.

We then define customer groups corresponding to:

• Each row: R1, R2, … R9
• Each column: C1, C2, … C9
• Each 3×3 subgrid: SG1, SG2, … SG9

These groups enforce Sudoku rules through standard network constraints:

• Each customer (cell) must be supplied by exactly one vendor
• Each vendor can supply exactly 9 customers (each number appears nine times)
• Vendor n supplies n units to a customer (encoding the value)
• The total quantity flowing into each row, column, and subgrid must equal 45

What we've done is convert a Sudoku puzzle into a supply chain network so we can use a network optimization algorithm to solve it.

At that point, all that's left is to define an input data model that captures a specific Sudoku puzzle and wrap it in an application layer that lets users interact with it—instantly turning the same algorithm into a completely new solution.

Nothing about the algorithm changed. Only the data model and the constraints did.

That's the key point.

The Core Insight: Algorithms, Models, and Applications Are Orthogonal

Here's the realization: algorithms, data models, and applications are distinct layers and they shouldn't be glued together.

• The algorithm is a general-purpose problem solver
• The data model defines the structure and rules
• The application provides context and user interaction

What we call a "use case" is just the same algorithm with different wrapping.

Most enterprise software ignores this separation. The layers are tightly coupled: the algorithm is buried, the data model is rigid, the application dictates what you can solve.

This creates the illusion of specialization while quietly restricting flexibility. When a new problem emerges, you're told to buy another tool.

"When algorithms are treated as sacred and applications as rigid, organizations become dependent on vendors to define what problems they can solve."

Decouple these layers and everything changes. When the algorithm is reusable, the data model is configurable, and the application is lightweight, power shifts to the modeler. New problems can be expressed directly. Assumptions can change without vendor approval. Entire decision frameworks can be created without reinventing the math.

Translation: The math is reusable. The data model defines the problem. The application is just the interface. Separate these layers, and suddenly you don't need a new tool for every new question.

This is what enables real decision agility, not another "purpose-built" application.

"When the algorithm is reusable, the data model is configurable, and the application is lightweight, the power shifts to the modeler."

Business Implications: The Illusion of New Use Cases

This is where the Sudoku example stops being cute and starts being uncomfortable.

Take a few "distinct" enterprise problems:

Use Case: Tariff Optimization

When tariffs were introduced, organizations scrambled for tariff intelligence tools. Leaders needed to understand how sudden duty changes would impact landed cost, sourcing decisions, and network flows—often with little notice.

Business requirements included:

• Evaluating alternate sourcing countries and suppliers
• Recomputing landed costs under different tariff regimes
• Understanding exposure across products, lanes, and regions
• Responding quickly as trade policies evolved

What made this feel like a new use case was the conditional and policy-driven nature of costs. Tariffs depend on origin, destination, product classification, and regulatory rules—not just distance or volume.

But structurally, this is still a network optimization problem:

• Flows move from suppliers to demand points
• Costs are applied to those flows
• Constraints and penalties guide feasible solutions

Tariffs simply become conditional costs and constraints layered onto the network.

Same algorithm. Different data.

The Pattern Repeats

Rough-cut capacity planning? Flows through resources with capacity limits. Labor planning? Workers as resources, tasks as demand, assignments as flows.

Each looks different because the business semantics change:

• Policies instead of distances
• Capacity instead of locations
• People instead of machines

But the mathematical structure doesn't.

What changes is the data model and the user experience, not the algorithm. That distinction is where real flexibility comes from.

What This Means Going Forward

When algorithms are treated as sacred and applications as rigid, organizations become dependent on vendors to define what problems they can solve.

When data models and applications are flexible, the organization regains control.

This has profound implications:

• New business problems don't require new solvers
• Innovation happens at the modeling layer
• Decision intelligence becomes composable, not monolithic

The future doesn't belong to software that ships "use cases." It belongs to platforms that let you define problems.

The Takeaway

Solving Sudoku with a network optimization algorithm isn't the point.

The point is this: most business problems are variations of the same mathematical structures, disguised by different language and interfaces.

When we stop mistaking costumes for substance, we stop chasing tools—and start building decision systems that actually adapt.

"The real competitive advantage isn't owning more applications. It's owning the ability to model your world."

If you're curious to see how this works in practice, how a Sudoku solver (or tariff optimizer, or capacity planner) can be built by cleanly separating algorithms, data models, and applications, check out what's possible in Lyric Studio.