Your Best Engineers Have Better Problems to Solve

Operations and Maintenance (O&M) teams are not short on engineering talent, but they are short on engineering capacity. A lot of that talent goes toward things like diagnosing why a piece of critical equipment at a customer site has stopped reporting, manually onboarding a new inverter model the platform has never connected, or patching edge devices across forty remote sites to address a finding from a security audit. Each one of these tasks gets done by capable engineers, but none of it sets the business apart from any competitor doing the same thing. 

The engineers responsible for the monitoring system are stuck building and maintaining the same basic data infrastructure that every other O&M is also running, when they could be building competitive advantage. 

 

What “building it yourself” costs 

The case for a home-grown data collection stack always looks clean on paper. Avoid recurring vendor fees, use open-source components, keep the line item off the operating budget. The logic is straightforward enough that a lot of O&M engineering teams have made exactly this decision, and most of them are still paying for it. 

Here’s what the day-to-day looks like once you own a home-grown stack across a distributed portfolio: 

Data quality is harder to maintain than it looks. Connectivity interruptions, slow device response times, and polling failures create gaps in the data record every day. Most teams don’t have visibility into how much data they’re missing — the gaps are silent, and the operators relying on that data don’t know what they’re not seeing — until their end customer does. Identifying the root cause and fixing it is exactly the kind of sustaining work that makes maintenance expensive. 

Distributed edge devices are a management burden. Low-cost protocol converters at each site solve the local connectivity problem and create a dozen new ones: remote patching, backup, disaster recovery, configuration drift, security exposure. Without centralised orchestration, each site quietly becomes a unique implementation. When something fails at 2am, someone has to deal with it. 

Security and compliance requirements keep moving. Regulatory compliance obligations aren’t static, and most O&M engineering teams aren’t cyber-security specialists. Keeping a home-grown stack compliant requires ongoing expertise that’s hard to retain in-house. 

New assets mean new work. Every time a new plant comes into your portfolio, each with a different manufacturer, naming convention, and data model—your platform doesn’t know what to do with it. Someone has to map it. That work isn’t glamorous, it isn’t fast, and it doesn’t get easier as the portfolio grows. 

Device integrations can break. Inverter and tracker manufacturers push firmware updates on their own schedules, and those updates don’t come with a courtesy call to your engineering team. When an integration breaks, and it will, someone on your team has to diagnose it, track down the root cause, and fix it. Multiply that across the equipment diversity in a real O&M portfolio and you’re not dealing with occasional maintenance, you’re dealing with a permanent queue. 

None of this is exceptional. It’s just what owning distributed data infrastructure looks like at scale. The engineers doing this work aren’t doing anything wrong. The question is whether they should be doing it at all. 

 

The part that should give you pause 

The capabilities O&M teams are maintaining in-house aren’t capabilities that differentiate their business. 

Every O&M needs device connectivity, data normalization, and remote monitoring. These are baseline requirements — the cost of operating, not a source of competitive advantage. When you build those things yourself, you’re investing significant engineering resources to arrive at roughly the same place as every other O&M that built the same thing. The competitive landscape doesn’t change. The margin doesn’t improve. The only thing that changes is how much of your team’s attention is absorbed by keeping it running. 

Our existing Buy vs Build post makes the broader strategic case for why building in-house costs more than it first appears. The time spent on routine infrastructure upkeep is time not spent developing capabilities that set you apart. An engineering team freed from that work could be building compound alerting rules that surface the faults that matter, rather than manually wrangling raw alarm codes into something readable. 

 

What the platform already handles 

The reason to buy rather than build isn’t just cost. A purpose-built platform has already encountered, and solved, the integration failures, firmware breaks, and edge cases your team would otherwise hit for the first time. That shows up in a few specific ways:

Pre-built equipment plugins. Hundreds of connectors for inverters, trackers, BESS systems, weather stations, meters, and substation equipment — all maintained centrally as firmware evolves. When a new equipment model arrives at a site — whether a new build or a repower — you’re downloading a plugin, not writing one. New plants can be live and collecting data within 48 hours of having network access and documentation. 

Standardised data at the edge. Data is normalised at the point of collection — consistent tag names, units of measure, and data structures regardless of equipment manufacturer. That means the moment a new plant is connected, its data is already in the same format as every other plant in the portfolio. No translation layer to build and maintain. 

Centralised edge management. Software updates, security patches, configuration changes — all managed from a central hub across the entire distributed fleet. No manual patching across remote sites. No configuration drift. When a security advisory comes out on a Friday, it doesn’t become a weekend project. 

Zero-gap data collection. Cloud-native messaging with guaranteed delivery means data gaps don’t occur even during connectivity outages. Automatic backfill handles restoration. Local historian storage at each site covers weeks of offline operation if needed. 

Secure remote access without the architecture headache. Outbound-only connections via TLS 1.3, MFA, digital certificate authentication, and a security gateway that blocks all external access to plant networks. Regulatory compliance alignment is built into the architecture, not retrofitted onto it. 

 

What could your team be doing instead? 

The answer varies by team, which is the point. 

Some O&M engineering teams have a list of customer-facing capabilities they’ve wanted to build for years — custom KPI sets tailored to specific IPP customers, performance dashboards that feed directly into renewal conversations, sophisticated alerting rules that surface the kind of early-warning signals that justify the O&M relationship on its own. That work keeps getting pushed because the maintenance queue doesn’t empty. 

Others want to do more with the equipment integration layer itself — building plugins for less common assets — substation equipment, for instance, or pulling additional tags from equipment that specific customers are asking for. That work builds truly differentiating capability: capability that belongs to the O&M, not the platform. 

The point isn’t that every engineering team has the same priorities. It’s that most teams have a clear sense of where they’d rather be spending their time — and the gap between that and where they’re spending it is largely filled by infrastructure maintenance that doesn’t have to be theirs. 

 

The platform is a foundation, not a constraint 

A common concern with moving to a commercial platform is flexibility. If you replace the home-grown stack, do you lose the ability to customise? 

It’s a fair question, a platform that trades one form of lock-in for another isn’t solving the problem. 

The Ardexa architecture is designed specifically to avoid this. Plugins are extensible, if the base plugin is missing a tag unique to a particular device, you can add it yourself in seconds. KPIs are configurable at the portfolio level, the plant level, or down to the individual asset. Widgets and dashboards are adjustable to the observability requirements of specific customers. Compound condition alerting lets teams build rules based on any combination of data points — if you can define the condition and the data exists, you can build the rule. 

What you’re not doing is maintaining the underlying infrastructure — the data acquisition, data normalisation, connectivity, the edge management, the security layer, the cloud transport. That part is handled. Everything above it is yours to build. 

 

The practical upshot 

The infrastructure problems that consume O&M engineering attention have been solved before across thousands of plants and dozens of equipment types. Building them again internally doesn’t produce a better outcome. All it does is produce a similar outcome at higher true cost, with lower reliability, and with your best people tied to maintenance work instead of building the capabilities that would differentiate your service. 

If that sounds like a gap worth closing, get in touch and we can walk through how it fits your specific environment. 

 

There’s a better way to build this. See how it works. ›