Asset hierarchy vs. asset relationships

Three questions that get mixed together

People say “the hierarchy” and mean three different things. Pull them apart and each one is easier to build and to keep right.

The hierarchy: what a thing is

A hierarchy is a tree. Every class has one parent, and the parent-and-child link means “is a kind of” or “is a part of”. A Plastic main is a kind of Mains. It says nothing about which street the pipe is under or what it is joined to. That restraint is the point. The tree stays small and stable, and any roll-up over it adds up. The pillar guide covers how to build one.

Relationships: what it is attached to

Relationships are the connections between particular assets: what feeds what, what isolates what, what sits upstream or downstream. In the Gas distribution template the classes Gate station, District regulator station, Mains, Services and Customer meter sets are in a chain: gas flows from the first toward the last. But that chain is a flow, not a tree. One main feeds many services. Mains are joined in loops. A tree cannot hold a loop, and a branch cannot have two parents.

That is why connections are usually kept in a network model, often in a GIS, and not forced into the hierarchy. Trying to do both in one structure ends with a tree that is neither a clean classification nor an accurate network.

Words can fool you here. In the Oil and Gas template the top-level classes are Upstream, Midstream and Downstream. Those names come from the direction of flow, but in the template they are a classification. A well belongs in Upstream because of what it is, a producing asset, and not because of a connection to any particular pipeline.

Decision governance: what each class answers to

Most hierarchies skip the third question: which business decisions does each kind of asset support? Without an answer, nobody can say which data is worth collecting or who relies on it.

Strata answers it with a chain. A class defines data points, each data point feeds the decisions that use it, and each decision sits in one or more lifecycle stages. In the gas template, the class Cathodic protection defines Pipe-to-soil potential, and it feeds:

• Corrosion remediation, which happens in Maintain › Corrective
• Inspection frequency, which happens in Operate › Inspect

Each decision can also record how often it is made, how much it matters and who makes it. So “who relies on this data?” gets a list, not a guess. The stages are explained in the guide on lifecycle stages and PCOAR.

One asset class, three questions

Take the District regulator station class from the gas template and ask all three.

• What is it? A kind of Regulator and metering stations, in a system of mains, services and valves, with Regulator run and Overpressure protection as parts of it. That is the hierarchy.
• What is it connected to? It reduces pressure between parts of the network, so it sits downstream of a gate station and upstream of the mains it supplies. That is a relationship, and it differs for every station.
• What decisions does it answer to? Its pressure data points, such as Outlet set pressure (set on Regulator and metering stations and inherited from there), feed Pressure monitoring and Design standards. That is governance.

The same asset shows up in all three answers. Each answer lives somewhere different, and none needs the others to be right.

A quick test, and three ways the three get tangled

When something is about to be added to a model, ask whether it describes what the asset is, what it connects to, or what you do with it. If the honest answer is “it depends on the particular one”, it is not a class. It is a data point or a relationship.

• A class named for a connection. A branch called “fed from the north gate station” turns a relationship into a classification, and it is wrong the day the network is reconfigured.
• A data point that hides a connection. A free-text field holding the ID of the upstream asset is a relationship written as text. It cannot be checked, and it cannot be followed.
• A class named for a decision. “Priority 1 pipes” is the result of a ranking, not a kind of pipe. The ranking changes next year and the class is wrong.

Why keep them apart

• They change at different speeds. The hierarchy rarely moves. Connections change with every project, and decisions change with policy and budget.
• Different people own them. A data steward looks after the classification, a network engineer the connectivity, and an asset manager the decisions.
• Mixing them hides errors. When the numbers do not add up, a branch named after a flow, or a data point that quietly encodes a connection, makes it hard to tell which of the three is wrong.

Strata covers the first and the third and leaves the second where it already lives. To see the third in action, open the gas distribution template, pick a data point and look at the decisions it feeds. The guide on taking a hierarchy into your systems explains where connections usually end up.