Optimisation tools come and go. The layer connecting them can outlast them all. In refining, integration backbones with 25 years of continuous service exist - layers that have survived several generations of the systems around them. That longevity is never an accident of good maintenance. It is the result of an architectural decision, and it holds a lesson for anyone running planning, scheduling and mass balance today.
In Brief
- In refining, integration backbones with 25 years of continuous service exist - outlasting several generations of the systems around them.
- They survive because they are built as a business data model (definitions, identifiers, mappings), not as point-to-point wiring.
- Data stays live in its source systems and is linked, not copied - so individual tools can be replaced without the others noticing.
- The modernisation lesson: replace the platform, but migrate the model - rebuilding a quarter-century of harmonisation is the expensive part.
Part of the series , The refinery optimisation triad
- Scheduling in the process industry, explained
- Why refineries count in tonnes: the mass balance, explained
- One data backbone, 25 years (series centrepiece) - you are here
- When the crude tanker doesn’t arrive: how fast can a refinery replan?
The triad
Three refinery applications, one nervous system
Refinery optimisation runs on a triad: planning sets the economic targets, scheduling turns them into an executable sequence, and the mass balance reconciles what actually flowed. None of the three works alone - and all three feed on the same sources: laboratory analyses and process sensor data. Wire these applications point-to-point and every pair needs its own connection, its own mappings, its own maintenance. Put one integration layer beneath them and each system connects exactly once - the classic n×m problem collapses into n.
What flows across the backbone - and who needs it
| Planning needs | Reconciled actuals from the mass balance; capacities and constraints from scheduling |
| Scheduling needs | Targets from planning; tank levels and unit states from the process; qualities from the lab |
| Mass balance needs | Movements and meter data from the process; lab analyses; the plan as reference |
| All three need | One shared definition of every material, tank, unit and quality |
The last row is the decisive one. Without a shared definition, the triad exchanges numbers that do not mean the same thing - and the loop quietly falls apart.
And the shared definition is harder than it sounds, because the views rarely map one to one. In simple cases, the same stream is represented identically in planning, scheduling and the mass balance. In real plants, aggregation and decomposition are the norm: one stream in scheduling corresponds to several streams in planning, or several movements roll up into one balanced flow. Where the connecting layer does not model these correspondences natively, people bridge the gap the only way they can - spreadsheet extractions and manual matching - and traceability quietly dies.
Why it lasts
Why does a refinery data backbone survive 25 years?
Because it is built as a data model, not as wiring. Such a layer does not merely move values from A to B; it holds a business-centric model of the refinery - materials, tanks, units, streams, qualities, movements - to which every application maps, including the awkward many-to-one cases. The model holds the definitions, identifiers and relationships; the heavy operational values, such as time series from the historians, stay in the engines built for them and are referenced, not duplicated. Data stays live in its source systems and is linked, not copied, so nothing ages between transfers. And because the applications depend on the model rather than on each other, individual systems can be replaced over the years without the others noticing. Around a layer like this, the tools get swapped several times in a quarter of a century. The model stays.
The tools get replaced. The model remains. That is what decoupling business processes from systems actually means.
The lesson
What 25 years teach about modernising a refinery data platform
Sooner or later, every backbone faces its own renewal - new platforms, cloud infrastructure, new solvers, AI on top. The instinct is to treat this as a software replacement. The 25-year lesson says otherwise: the asset worth carrying over is not the code. It is the accumulated data model - the shared definitions, the identifiers, the mappings between systems, the historised values, the operational knowledge that long-serving engineers encoded into it over the years. Modernise the platform by all means; but migrate the model, because rebuilding a quarter-century of harmonisation from scratch is the truly expensive part.
A simple test separates good modernisation proposals from expensive ones: can the existing model semantics - identifiers, classes, properties, mappings and their history - be imported and extended without disruption? If the answer amounts to rebuilding the vocabulary, the most valuable asset of those years is being thrown away together with the code.
A related worry deserves a direct answer: does depending on one backbone create vendor lock-in? If it is built properly, the opposite is true. A good layer lets you export both your data and your data model at any time, and stays neutral towards the BI, optimisation and AI tools you run on top. You already depend on every system you operate; a backbone reduces how painfully those dependencies bite when something changes.
The same logic applies to the AI ambitions driving many of these modernisations. Advanced analytics on planning, scheduling and mass balance data is only as good as the harmonised foundation beneath it. The sequence does not change with the technology: data maturity first, then optimisation, then AI.
The lesson travels
Four signs your refinery’s optimisation landscape lacks a backbone
- Every application keeps its own master data. Materials, tanks and units are defined separately in planning, scheduling and the balance - and drift apart.
- Mappings and reconciliation happen in Excel. Plan, schedule and balance figures - and the correspondences between them - are matched by hand before every meeting.
- Replacing one tool means rewiring the others. Interfaces are pairwise, so every change ripples through the landscape.
- History breaks on every change. Plan-versus-actual comparisons stop working whenever tags, units or structures are renamed.
Any one of these is a warning sign. All four together mean the optimisation triad is standing on wiring, not on a foundation. What such a foundation looks like - one layer above the systems, connecting each of them once, holding the shared definitions and mappings, linking data at its source and outliving the tools on top - is exactly what the boTec DataBridge is built to be.