I Built an Enterprise Workflow Engine Like a Game Engine — And It Was the Right Call

Matthew Burrows — Sat, 16 May 2026 08:14:40 +0000

Some of the best engineering decisions I’ve made weren’t inspired by architecture books, design pattern catalogues, or conference talks. They came from somewhere else entirely.

I’ve been fascinated by game development since I was a boy — over thirty years ago. Not just playing games, but understanding how they work underneath. In my spare time, over the years, I built two game engines from scratch: a 2D tile-based engine and a 3D voxel engine. No tutorials, no frameworks. Just research, curiosity, and a lot of iteration.

That might sound unrelated to enterprise patch governance software. It isn’t.

When I sat down to design the workflow engine at the heart of OPUS — an orchestration platform built on .NET 10, Blazor Server, and Azure Update Manager — I needed something flexible enough to reshape itself at runtime, extensible enough that adding new capabilities wouldn’t require touching the core, and clean enough that any feature could exist inside the workflow or as a standalone tool without knowing the difference.

I’d solved that problem before. Not in enterprise software. In a game engine.

ECS Isn’t a Game Pattern. It’s a Composition Pattern.

Entity Component System — ECS — is the architectural pattern that powers most modern game engines. If you’ve used Unity, you’ve used it. The idea is straightforward:

Entities are pure identity containers. They hold no behaviour and no logic. They are, essentially, a name and a bag of metadata.
Components are where all state and behaviour live. You attach them to entities to give those entities capabilities.
Systems act on entities by querying for the components they care about, at runtime.

The result is an architecture built entirely on composition rather than inheritance. There are no deep class hierarchies. There’s no brittle base class trying to anticipate every future requirement. You add a new capability by writing a new component and attaching it — the rest of the engine doesn’t need to know.

Games discovered ECS because they had brutal requirements: hundreds of entity types, runtime flexibility, the ability to combine behaviours in ways the original designer never anticipated. Those aren’t uniquely game requirements. They’re just requirements that games hit first.

Enterprise software hits them too. It usually just reaches for the wrong tools when it does.

The Problem I Was Solving

OPUS needed a wizard-style workflow — a guided, multi-step process that walks a patch governance team through an entire patching cycle. Assessment scans, runbook scheduling, device discovery, OS patching, SQL remediation. Each of those is a distinct phase, and each phase is a sequence of steps.

Simple enough on paper. But the requirements made a static approach unworkable.

The workflow needed to change shape based on how the platform was configured. A tenant with only lower-tier environments gets a different workflow to one with both tiers. Automatic assessments enabled? Remove those phases entirely. SQL offset patching switched on? Inject those stages. Runbooks configured for an environment? Add those steps. No runbooks? Skip them. The number of phases, the steps inside each phase, the dates attached to them — all of it needed to emerge from configuration, not be hardcoded.

On top of that, individual capabilities needed to exist outside the workflow entirely. A device exemption manager, an operation history viewer, a KB install tool — these aren’t workflow steps, they’re tools. But they’re built from the same components as the workflow phases. Writing them twice, or creating a parallel architecture just for tools, wasn’t acceptable.

What I needed was a core engine that had no opinion about what the workflow looked like. Something where composition was the mechanism, not inheritance. Where adding a new capability meant writing the capability — not modifying the engine to accommodate it.

That’s when I stopped thinking about enterprise architecture patterns and started thinking about game engines.

The Mapping

Here’s how ECS maps directly onto the OPUS engine. These aren’t analogies — they’re the actual types.

Phase is the Entity.

public class Phase
{
    public string Name { get; }
    public List<Step> Steps { get; } = new List<Step>();
    public Dictionary<string, object> Metadata { get; } =
        new Dictionary<string, object>(StringComparer.OrdinalIgnoreCase);
}

A Phase knows its name, holds a list of navigation steps, and carries a metadata dictionary. That’s it. No behaviour, no business logic, no Azure calls. It has no idea what it represents operationally. It’s a container — exactly what an entity should be.

BaseFeature is the Component.

Every capability in OPUS — runbook scheduling, device discovery, patch assessment, KB management — is a class that inherits from BaseFeature. All the state lives there. All the logic lives there. The feature knows everything about its own domain and nothing about the workflow it might be hosted in.

public abstract class BaseFeature : INotifyPropertyChanged
{
    public abstract void Reset();
    // State, logic, and decorated properties on every subclass
}

WorkflowShellService is the System.

This is where it gets interesting. When the user navigates to a step, the shell service resolves which feature that step belongs to — at runtime, by type — and activates it:

var featureType = step.GetMetadata<Type>("HostTypeObject");
var feature = _currentPhaseEntity.GetFeature(featureType) as BaseFeature;

That’s it. Two lines. The system queries the entity for the component it needs, by type, at runtime. If you’ve worked with ECS before, that pattern is immediately familiar. The shell service has no hardcoded knowledge of any specific feature. It just knows how to ask an entity what it’s carrying.

The metadata dictionary is the tag store.

Every step declares which feature owns it and what UI control to render, purely through metadata entries. The engine reads those at navigation time. No switch statements, no feature-specific branching in the core — just a generic lookup that works identically for every feature that has ever been added or ever will be.

The result is that adding a new capability to OPUS means writing a new BaseFeature subclass and registering it. The engine doesn’t change. It never needs to.

The Proof — The Workflow Builds Itself

Elegant architecture is one thing. Architecture that earns its complexity under real-world requirements is another. This is where ECS stopped being an interesting design choice and became the only reasonable one.

OPUS tenants configure their patch governance — which Azure subscriptions they manage, which environments exist, whether automatic assessments are enabled, whether SQL offset patching is required, whether runbooks are configured. That configuration is live. It can change. And when it does, the workflow needs to reflect it immediately.

There are no JSON workflow definition files in OPUS. There is no hardcoded phase list. Instead, there’s a WorkflowDefinitionBuilder that reads governance configuration and derives the entire workflow from it:

public WorkflowDefinitionDto Build(string tenantId)
{
    var lowerEnvs = GetConfiguredEnvironments(upperTier: false);
    var upperEnvs = GetConfiguredEnvironments(upperTier: true);

    var plan = BuildPhasePlan(
        lowerEnvs.Any(), upperEnvs.Any(),
        TierHasRunbooks(lowerEnvs), TierHasRunbooks(upperEnvs));

    var phases = new List<PhaseDefinitionDto>();
    foreach (var p in plan)
        phases.Add(BuildPhase(p));

    return new WorkflowDefinitionDto { Phases = phases };
}

The builder interrogates governance and constructs a phase plan — a description of which phases should exist and what they should contain. That plan is then materialised into a full workflow definition: phases, steps, metadata, due dates, reminder targets, all wired together.

When a tenant enables SQL offset patching, those phases appear. When automatic assessments are switched on, assessment phases are removed — they’re no longer needed. When runbooks aren’t configured for an environment, those steps are simply not injected. The workflow that emerges is always correct for that tenant’s configuration, and the engine that runs it never changed at all.

This is the part that a static approach cannot survive. A hardcoded workflow either gives every tenant every phase regardless of relevance, or it requires conditional rendering logic scattered throughout the navigation layer. Neither is acceptable in a governance platform where what you show carries compliance weight.

Because the engine operates purely on composition — phases as containers, features as components, the system resolving everything at runtime — the workflow definition is just data. The builder produces it, the engine consumes it, and the two have no direct knowledge of each other.

The engine doesn’t know what a runbook is. It doesn’t know what SQL offset patching means. It just knows how to navigate a phase that contains whatever components were attached to it.

That separation is what makes the whole thing work. And it came directly from thinking about how a game engine handles a level it’s never seen before.

Features Don’t Need the Workflow

One of the quieter benefits of this architecture only becomes obvious once you’ve lived with it for a while.

Because a BaseFeature subclass is just a component — self-contained, with no dependency on the workflow that might host it — it can be instantiated and driven from anywhere. The workflow doesn’t own features. It just happens to be one place they can run.

In OPUS, this means the same feature that appears as a step inside a patch cycle phase can also be surfaced as an appbar tool, an ad-hoc utility page, or a background operation. The device exemption manager, the operation history viewer, the KB install and uninstall tools — none of those are workflow steps. But they’re built from exactly the same components as everything inside the workflow.

There’s no parallel architecture for tools. There’s no “workflow version” and “standalone version” of the same capability. You write the feature once. Where it runs is just a matter of where you choose to surface it.

This is the same reason a component in Unity works outside of a scene. The component doesn’t know or care whether it’s inside a scene graph or being driven directly. It just does its job when something tells it to.

In practice this means OPUS can grow in any direction without the core engine becoming a bottleneck. New workflow phase? New tool? New appbar shortcut? It’s all the same mechanism. The engine has no opinion about any of it.

That flexibility wasn’t planned as a feature. It was a consequence of getting the composition right.

The Takeaway

ECS didn’t come from an enterprise architecture book. It didn’t come from a .NET design patterns course or a conference talk about clean code. It came from thirty years of being genuinely curious about how games work under the hood — and eventually building a couple of engines to find out.

When I sat down to design OPUS, I wasn’t thinking “what enterprise pattern fits here?” I was thinking “I’ve solved this problem before.” A system that needs to compose behaviour flexibly, reshape itself at runtime, and let components exist independently of the structure that hosts them — that’s not a new problem. It’s just usually described in a different vocabulary.

The lesson I’d take from this isn’t “use ECS in your enterprise software.” It’s narrower and more useful than that.

The patterns worth reaching for aren’t always the ones in the book you’re supposed to have read. Sometimes the right mental model is sitting in a completely different domain, waiting for you to notice that the problems are the same shape. You only notice that if you’ve spent time in both places.

Years of experimenting writing game engines in my spare time from scratch didn’t make me a game developer. But it quietly shaped how I think about composition, flexibility, and what an engine should and shouldn’t know about the things it runs.

That turned out to matter quite a lot.

If you’re building something and the standard patterns feel like they’re fighting the problem rather than solving it — look sideways. The right idea might be somewhere you wouldn’t expect to find it.

And keep your side interests. You genuinely never know when they become load-bearing.

Matthew Burrows • Cloudframe Solutions Limited • opus-orchestrator.co.uk

DEV Community: Matthew Burrows