Build or buy industrial analytics, written for an asset owner

The familiar framing for this decision is feature parity, time to market and engineering headcount. An asset owner is answering a different question, because what is being built is an internal capability rather than a product, and it has to survive a control system upgrade and a change of staff.

The relevant question is narrower: which parts of an analytics capability can this organisation own competently for ten years, and which parts will quietly rot when the person who built them moves on.

That reframing matters because it changes the answer. Most build decisions in this sector are made on capability at the start and regretted on ownership in year three.

Acquisition and storage. Getting data off the plant and into somewhere queryable. Buildable by a competent team, well-served by open tooling, and routinely underestimated by a factor most teams find uncomfortable once tag mapping starts.

Contextualisation. Knowing what each tag means, its units, its sign convention, which asset it belongs to and how those assets relate. Unglamorous, plant-specific, and a common place for a schedule to disappear.

Domain modelling. The physics, the degradation mechanisms, the attribution logic. This needs process and control engineering rather than software engineering, and it is where build decisions most often fail.

Presentation and workflow. Getting a finding to the person who acts on it, in a form they will act on. Deceptively hard, because the requirement is behavioural rather than technical, and dashboards are the graveyard of this layer.

The connection itself is a week. Making sense of what comes down it is not. A plant of any age has thousands of tags with inconsistent naming, missing or wrong units, undocumented sign conventions, and duplicates left by successive control system upgrades. Establishing what each signal actually represents is where the schedule goes.

Historian compression is the second surprise. Many historians discard points judged uninformative, and a signal stored as a five-minute average cannot be un-averaged. Discovering this after a year of collection is common and expensive.

Neither of those is a reason not to build this layer. They are reasons to scope it honestly, and to note that the work is a one-off asset the plant keeps regardless of what happens to any analytics vendor. That is the strongest argument for building here: the contextualised data model is the thing with lasting value, and it should not be locked inside somebody else's product.

The interface question comes first and is separate: what can be read, through which path, and what enforces it. That is covered in reading plant data without modifying the control system.

This is where a build either works or produces a dashboard nobody opens. Detecting that a value has changed is straightforward. Explaining why, in terms an engineer will accept, requires modelling the mechanism, and modelling the mechanism requires someone who knows it.

Plants that succeed here have a specific characteristic: a process or control engineer who understands both the equipment and the analysis, and who stays. Where that person exists, the build case is real. Where the plan is to hire data scientists and have them learn electrochemistry, it usually is not.

There is a middle failure mode worth naming. A team builds statistical anomaly detection, it works in testing, and it produces alerts nobody can interpret because there is no mechanism attached. The system is then blamed for false positives when the actual gap is attribution. The distinction is set out in physics-driven AI against generic industrial analytics.

Honest test for this layer: can the team say, today, what physical relationships they would encode and what would falsify each one. If the answer is that they would start with the data and see what emerges, the domain layer is not being built, it is being hoped for.

Plants change. Setpoints move, equipment is replaced, operating strategy shifts, control systems are upgraded and tag names change with them. Every one of those breaks something in an analytics stack, and someone has to fix it.

In year one the builder is present and fixes things in an afternoon. In year three the builder has moved to another role or another company, the documentation describes an earlier version, and the system produces output nobody quite trusts. This is a common ending for a built industrial analytics capability, and it is organisational rather than technical.

The cost to carry is not the build cost. It is a standing allocation of engineering time, indefinitely, plus a succession plan for the person who holds the knowledge. Costing that honestly at the start changes many build decisions, which is presumably why it is so often omitted.

A bought system has the mirror-image risk, which is worth stating fairly: the vendor changes direction, is acquired, or ends the product, and the plant is left with a dependency it did not choose. The mitigation is the same in both directions, which is owning the data layer and the contextualisation regardless.

The arrangement that holds up is a boundary drawn along the skills. The plant owns acquisition, storage and contextualisation, because that is data engineering and it is the asset with lasting value. The vendor owns the domain models and the attribution, because that is where specialised knowledge is amortised across more than one site.

This has a practical test attached: if the vendor relationship ended tomorrow, does the plant still have its data, its tag model and its history in a form another party could use. If yes, the dependency is manageable. If no, the split was not really made.

The arrangement that does not work is the plant building the domain layer while buying the data layer. It inverts the skills, puts the specialised work where the specialism is thinnest, and leaves the commodity work with a supplier.

Fleet size moves the line. One asset rarely justifies building the domain layer, because the modelling effort is amortised over nothing. Twenty similar assets might, because the same model is reused and the standing engineering cost is spread. Somewhere between those the calculation flips, and it is worth doing rather than assuming.

Who, by name, owns this in year three, and what happens when they leave.

What is the standing annual engineering allocation, and has it been agreed by whoever controls that budget.

Which physical relationships will the domain layer encode, and who knows them.

If the vendor relationship ended, or the internal builder left, what remains usable.

How many assets does this apply to now, and how many in five years.

And what decision is meant to change as a result. A capability that cannot name the decision it improves is a project looking for a justification, whichever way it is sourced.