The asset framework demo is the most persuasive part of any historian evaluation. Somebody drags a template onto a well, and suddenly there is a structured object with named attributes, inherited properties, and every relevant tag hanging off it in the right place. Compared to a flat tag list it looks like order arriving.
It is order arriving. The question is whose order, and where it lives when you want to leave.
What an asset framework actually gives you
Stripped of the marketing, an asset model inside a historian is a naming and hierarchy layer. You define a template for a class of equipment, say a rod-pumped well, with named attributes: tubing pressure, casing pressure, runtime, strokes per minute. Then you instantiate that template per well and bind each attribute to the underlying tag on that well.
The payoff is real. A query can now ask for tubing pressure on any well without knowing what the tag is called on that well, which is exactly the abstraction a heterogeneous estate needs. Templates make onboarding a new well faster. Inheritance keeps definitions consistent. Engineers stop memorizing tag names.
This is a genuinely good feature and the reason asset frameworks sell. It is also, precisely, the normalization layer. The mapping from vendor-specific tag names to a canonical concept, which is the hardest and most valuable work in an operational data program, is what the template is doing.
The second canonical model
Here is where it goes wrong on an estate that also has a warehouse.
You are already building a canonical model. The silver layer maps tags to concepts, normalizes units, resolves asset hierarchy, and defines what “tubing pressure on well X” means for every consumer downstream. That model has to exist regardless, because the assets that are not in the historian still need to be normalized, and because the analytical consumers live in the warehouse.
If the historian’s asset framework is also doing that job, you now have two canonical models describing overlapping subsets of the same estate, maintained by different teams, in different tools, with no mechanism to keep them consistent.
They will diverge. A new well gets added to the template in the historian and not to the warehouse mapping, or the other way round. An attribute gets given a new meaning in one place. Somebody fixes a unit conversion on one side. Six months later two dashboards disagree about the same well, and the reconciliation exercise is somebody’s whole quarter.
Two sources of truth is the failure mode. It does not matter that both are individually well built.
Normalization you cannot take with you
The sharper version of the problem is portability, and there is a simple test for it.
Ask what happens to the asset model if the historian goes away.
The tag history is portable, more or less. It is timestamps and values, and every historian has an export path, even if it is slow and unpleasant. That part you can get back.
The model is a different matter. Template definitions, attribute bindings, inherited hierarchy, calculated attributes defined inside the framework: that is the accumulated interpretive work of however many years, expressed in a vendor’s structures. Most products will export it, frequently as XML, and that export is complete in the sense that it round-trips back into the same product. It is not portable in the sense that matters, because the calculations are written in the vendor’s own expression language and the structure assumes the vendor’s own object model. Rebuilding it elsewhere means redoing the mapping work from the underlying tags, which is the expensive part you thought you had finished.
Normalization performed inside a vendor’s framework is normalization handed to that vendor. That is not a claim about anyone’s integrity. It is a claim about where the artifact lives and what format it is in.
The contrast is worth being concrete about. The same mapping expressed as warehouse transformation code sits in your repository, in version control, reviewable in a pull request, testable, and readable by anyone who knows SQL. If you change warehouse vendors, the logic ports with modest effort because the logic is text you own. That difference in medium is the whole argument. It is the same reasoning behind treating interfaces as data contracts rather than as whatever the source system happens to expose this year.
The direction licensing has been traveling
One commercial note, stated carefully because licensing terms change and a stale pricing claim is worse than none.
Industrial software has been moving from perpetual licenses toward subscription and consumption models. That is not unique to historians and not predatory; it is where enterprise software went. What it changes here is the link between instrumenting more equipment and paying more, and how predictable that is over five years.
Read your own agreement rather than anything written here. One question: if your tag count doubles in three years, what happens to this line, and do you control the answer?
Then ask it about the model. If the canonical definitions live inside the product, “can we move” and “what will this cost” stop being separable decisions.
Where the model should live
The recommendation is not to avoid asset frameworks. It is to be deliberate about which system owns the canonical definition.
Let the historian hold history and serve the engineers who work in it. Use its asset model for what it is good at: making the trend client usable, giving process engineers a structured view, supporting the workflows built into the product.
Own the canonical model in your own layer. Tag-to-concept mapping, unit normalization, asset hierarchy, and the definitions every downstream consumer inherits belong in versioned transformation code against your own storage. When the historian’s asset model and yours disagree, yours is the one that is correct by definition, because it is the one every analytical consumer reads.
If you want the two to stay aligned, generate the historian’s templates from your canonical model rather than maintaining both by hand. One direction, one source, mechanical propagation, usually through the product’s own configuration API. That is more work up front than clicking through the template editor, and it is the only arrangement with a mechanism holding it together. Anything maintained in two places by hand stays consistent exactly as long as someone is paying attention.
The related argument about well data not being a data product applies directly here. A model is only a product if somebody owns it, versions it, and is accountable for it. An asset framework maintained by whoever was on shift is a configuration, not a product, no matter how structured it looks.
The test worth running this week
Open your historian’s asset framework and ask two questions.
Does anything in here define a business concept the warehouse also defines? If so, which one wins, and does everybody know which?
If we replaced this product in three years, what would we rebuild from scratch? Whatever is on that list is what you have lent out.
The framework is doing useful work. The trouble is that it is quietly doing your work too, in a format you cannot take with you, and nobody made that decision on purpose.