The first 90 days of an energy UNS

TL;DR

Most energy UNS programs stall because of scope, not technology. This 90-day UNS implementation plan starts with the operational number your teams argue about most and turns it into one governed, reusable pattern before you scale to the next site.

• The KPI people dispute in operational reviews (usually capacity factor, availability or curtailment) points to a data-trust problem that already has a business owner. That owner is your sponsor.
• Governance starts when you design the namespace slice, not after the pilot. Set topic naming, payload structure, units, timestamps and branch ownership by day 30 to avoid failing at the second site.
• At day 90, success means one trusted KPI computed upstream, one real consumer connected and a documented pattern the next asset or site can reuse faster and at lower cost.

Who this blog is for: IT/OT architects, solution architects and platform owners in energy and utilities who are scoping a first unified namespace (UNS) program, plus the operations leaders who will sponsor it. If you're new to the series, start here, then go back to the posts on namespace design, MQTT and governance to see why each step is built the way it is.

Unified Namespace programs rarely fail because of a technical issue, nine times out of 10 it comes down to scope.

A team looks at the full estate, wind farms, solar plants, BESS sites, substations, feeders, meters, wells, pipelines, compressor stations, refineries, historians, SCADA, OEM portals, enterprise platforms, and concludes it has to design the perfect enterprise model before connecting a single thing. Then months pass and nothing ships, so the program quietly loses its sponsor.

In the first 90 days the goal is not coverage or perfection, it's momentum: prove the pattern on something that matters, then make it repeatable. The fastest way to pick that first use case is to find the operational argument your teams are most tired of having because a recurring argument is a data-trust problem with a business owner already attached. That last point is the practical shortcut most playbooks miss.

This is the final post in the From fragmented data to agentic operations blog series. The earlier posts in this series made the case and explained the pieces, why a UNS, how to design it, how to move data over it, how to govern it, how to make KPIs comparable, and how it becomes the foundation for AI and agentic operations. This post is about how to actually start without drowning in scope.

The 90-day UNS playbook for energy: momentum not perfection

The first 90 days should answer five questions:

• Can we connect live operational data from one high-value asset group?
• Can we structure it in a namespace the business understands?
• Can we govern the model instead of creating another topic tree?
• Can we compute or normalize a KPI the business trusts?
• Can we reuse the pattern for the next asset, site, or acquisition?

Five yeses and you have a program. The point is not that everything is connected, it's that the operating model is proven. So what do those first 90 days look like in practice?

Day 0: choose the business outcome or the energy KPI (start with the argument)

The first decision is business, not technical. Pick one use case where the pain is visible and the value is measurable in weeks. Good candidates for this include wind availability and capacity factor, solar underperformance detection, BESS state of charge and health, pipeline methane triage, upstream well predictive maintenance, compressor reliability, substation event visibility, CCGT heat-rate optimization, or cross-site comparability after an acquisition.

The strongest first use case has three traits: the data exists, the business cares, and the result can be measured in weeks not years. My shortcut for finding it is to ask which number people argue about in operational reviews. The recurring argument (usually capacity factor, availability or curtailment) is where trust is missing and where a business stakeholder already feels the pain. That stakeholder is your sponsor. Resist the opposite instinct to start with the most complex enterprise-wide scope; start with the use case that proves the pattern.

Days 1 to 15: assess your existing energy data architecture

The first two weeks are to create clarity. The priority here is to document which assets are in scope, which systems produce the data, which protocols are used, which signals matter, which dashboards consume the data today, which KPI definitions are already in use, who owns the source systems, which security boundaries apply, and what is blocking trust right now.

This is where teams inevitably discover the real issue isn't missing data, it's inconsistent data. One site publishes availability as a string, another as a percentage, a third has no availability KPI at all. One system uses kilowatts, another watts. One historian stores local time, another UTC. One OEM portal has the KPI but only via manual export. You get the picture. The current-state map exists to make these visible before you build on top of them.

This is also when you name the personas and pair each with a pain point and an outcome: OT/SCADA engineer, IT/OT architect, asset-performance engineer, data-platform owner, trading or dispatch stakeholder, compliance stakeholder, AI/analytics lead.

Days 16 to 30: design the namespace slice

Design the part of the namespace the first use case needs, not the enterprise. A practical starting pattern:

{enterprise}/{business_unit}/{region}/{site_type}/{site_id}/{area_or_system}/{asset_class}/{asset_id}/{datapoint}

For example:

ecorp/generation/us-gulf/wind-offshore/wf-galveston-01/string-a/turbine/wtg-t001/active_power_kw
ecorp/generation/us-gulf/wind-offshore/wf-galveston-01/string-a/turbine/wtg-t001/availability_state

with governed KPI topics alongside:

ecorp/generation/us-gulf/wind-offshore/wf-galveston-01/wtg-t001/metric/availability
ecorp/generation/us-gulf/wind-offshore/wf-galveston-01/wtg-t001/metric/capacity_factor

Define topic naming rules, payload structure, units, timestamp format, quality codes, required metadata, security model, retained-message strategy, change control and branch ownership. Governance starts here, when the slice is designed, not after the data is already flowing.

Days 31 to 45: connect the live energy asset data using MQTT

Connect the signals the first use case needs and only those. The pattern is consistent even when the sites aren't: an edge layer close to the OT systems, protocol adapters to SCADA, PLCs, RTUs, IEDs, historians or OEM systems, the broker as MQTT backbone, the first topics published into the namespace, and enterprise consumers subscribing to the governed structure.

For a wind KPI use case that might be active power, wind speed, availability state, curtailment setpoint, fault code, nameplate capacity, turbine ID, site ID. For methane triage: concentration, pressure drop, flow anomaly, segment, valve state, geo context, severity threshold. Keep the first connection narrow. Breadth is for later.

Days 46 to 60: discover, govern and normalize energy data

This is where a topic tree becomes a trusted foundation. Discover live topics and payload fields, catalog the sources, approve the relevant streams into the namespace, apply reusable data models, validate types, normalize values, compute missing KPIs, detect deviations, and publish governed outputs back into the namespace.

Concretely: if a source publishes {"active_power_kw": 6850, "wind_speed_ms": 11.2, "availability_state": "available"}, normalize availability into a numeric value (available/curtailed → 1.0, fault/offline → 0.0) and compute capacity factor as active_power_kw / nameplate_capacity_kw. Define the KPI once in the data layer and publish it back for every approved consumer. The discipline that pays off later: compute it upstream, never inside each dashboard.

Days 61 to 75: connect data consumers and prove business value

Now connect the consumers, Grafana or Power BI, asset-performance systems, data lakes, trading and dispatch tools, maintenance systems, compliance reporting, AI pipelines, digital twins, starting with the day-0 outcome.

The key here is not to build a generic dashboard, but to build a decision view that answers the specific question: which turbines underperform against expected output, which solar strings sit below fleet performance ratio, which BESS racks are dispatch-ready, which pipeline segments show high leak severity, which compressors trend toward failure.

In doing so, you need to make the value proof specific and measured: time to onboard the asset, time to discover streams, time to create trusted KPIs, reduction in manual mapping and KPI reconciliation, faster root-cause analysis, earlier anomaly detection. Numbers, not adjectives.

Days 76 to 90: document the pattern and choose the next one

The final two weeks convert one success into a repeatable pattern. Document the namespace slice, source systems, approved topic structure, payload schema, KPI definitions, the data model, governance rules, security model, consumer architecture, lessons learned and the next use case.

Then pick the scale path: horizontally to the next site with the same asset class, vertically to more signals and KPIs on the same site, or across domains from wind to solar, BESS, substations, or oil and gas. The best second use case is adjacent to the first, wind capacity factor leads naturally to solar performance ratio or BESS dispatch readiness; methane monitoring leads to compressor health or pressure-anomaly detection. The goal is to prove that every new asset gets cheaper and faster to onboard.

A 90-day operating model for a successful UNS implementation

A workable team: an executive sponsor owning outcome and funding; a UNS owner owning structure and governance; an OT owner owning source systems and operational constraints; an IT/platform owner owning infrastructure, security, and deployment; a data owner owning models, metadata, and KPI definitions; a consumer owner owning dashboards, apps or models; and a delivery team supporting architecture and enablement.

A workable cadence: discovery and mapping (weeks 1 to 2), namespace and governance design (3 to 4), edge and MQTT connection (5 to 6), discovery, modeling, validation and KPI normalization (7 to 8), consumer integration and value proof (9 to 10), documentation, handover, and scale plan (11 to 12). Keep the governance meeting short and practical: its job is to unblock implementation, not to become a committee that outlives the work.

Mistakes to avoid in the first 90 days of a UNS program

The failure modes are predictable enough to list:

• Don't start with a universal enterprise model.
• Don't let every site invent its own topic structure.
• Don't calculate official KPIs inside dashboards.
• Don't treat metadata as an afterthought.
• Don't rely on manual tag dictionaries as the source of truth.
• Don't postpone governance until after the pilot, that's the second-site failure waiting to happen.
• Don't connect data without defining consumers.
• Don't call the pilot a success unless the pattern can be reused.
• And don't position AI before the foundation is trusted.

The honest test underneath all of them: a UNS should simplify your architecture. If 90 days in it has added complexity instead, your scope was too broad or your governance wasn't clear enough, and the right move is to narrow, not to push on.

The UNS 90-day success criteria

By day 90 the team should be able to say, plainly: we connected live data from a priority asset group; structured it in a governed namespace; enforced topic and payload rules; built reusable models; normalized or computed at least one trusted KPI; detected deviations at the source; published governed outputs; connected at least one real consumer; proved a measurable outcome; and documented a pattern the next site can reuse. Not every asset connected, the operating model proven. That's a successful first phase, and it's the only foundation on which the rest of this series' ambitions (comparable KPIs, AI readiness, eventually agentic operations) can actually be built.

How to get started with the UNS playbook

Sit in your next operational review and write down the number people argue about. That argument is your day-0 use case, its frustrated owner is your sponsor, and the 90-day arc above is how you turn it from a recurring meeting into a governed, trusted, reusable pattern. Prove it once. Then scale the pattern, not the pilot.

And that closes the loop the series opened with. We started with three versions of capacity factor that nobody trusted; we ended with a 90-day plan to retire that argument for good and build the foundation everything else (comparable KPIs, AI readiness, eventually agentic operations) depends on. The order matters, but the starting point is small: one argument, one slice, one proven pattern.

Explore how HiveMQ supports your Unified Namespace journey or speak to the team today.

Frequently asked questions