An RTU was supposed to solve this. Then an IoT platform. Then new NMS software, a new element management software, a next-generation DCIM, or newer smarter controllers on new site equipment. Each arrived with the same promise: get visibility across the network of power, security, and environmental issues in sites, and give operators a coherent picture of this distributed infrastructure.

None of them solved it — because every attempted solution was proprietary hardware, proprietary software, or both, and didn't solve a fundamental underlying problem. Proprietary solutions can't be deployed retroactively across 100% of a mixed brownfield network. Each one became another silo. Most networks today are the accumulated result: a mishmash of monitoring approaches.

We know this from the inside. Before ClaritechIO, we spent years trying to get operators to standardize on RTU equipment. We believed in what we were selling and we succeeded where our equipment was built in to 100% of the network from the start, but you can't make a heterogeneous brownfield network homogeneous by adding more hardware to it, and new proprietary software is itself just a new data silo.

The answer isn't hardware or software — a fundamental first issue that must be addressed is standardized data as an architectural layer that lives between the two. Standardized data is possible from whatever hardware you already have and is compatible in addition to, or as a feed into whatever software you already use.

Here is what changes when you fix the foundation.

1. Reliability Improves Immediately

Most operators are still working from small bits of passive infrastructure data from their sites. Basically contact alarms or other equivalent SNMP alarms. A tool that allows better visibility, like better dashboarding, ISN'T what actually gets to the fundamental problem. What you see in any interface is a function of what data exists upstream of it. A better dashboard just shows you the same sparse data picture more attractively.  We often include dashboards, but what we are doing isn't just dashboards on data you already have.

What improves reliability comes BEFORE the software visibility layer: standardized telemetry from every piece of equipment, regardless of vendor. The largest reliability gains come from switching from the occasional alarming of your existing alarm scheme, to continual standardized telemetry data on TOP of your existing alarm scheme. You can view this new additional data in Grafana, push it through an AI pipeline, normalize output to include this data within your existing NMS, or use it to create new data and metrics. Without standardized data, no software choice fundamentally improves this situation.

During a natural disaster, an operator needs a triage picture across every affected site — which are on generator, what fuel levels, battery states, grid power, and runtimes are, which sites are trending toward failure. That requires 50–100 variables per cell site per minute, as well as possibly creating new data and metrics, not the threshold alarms you currently have.

2. You Can See Your Entire Network at Once

A single coherent view of distributed energy, cooling, and security infrastructure doesn't exist for most operators — not because site equipment doesn't produce the needed data, but because this data is inconsistent between vendors.

A data layer that normalizes energy, cooling, and security telemetry across every equipment type and vendor produces a single comparable dataset for the first time.  25,000+ data points per minute from a data center, 50–100 standardized variables per cell site — across thousands of sites, easily visible in open-source dashboarding tools like Grafana, and creating massive growing data sets for future AI use.

This same data method applies to every site in your network, no matter its size. It can be applied across all your sites, no matter what type of network you are operating.

3. The Economics Are Better from Day One

By stopping the cycle of proprietary hardware and software initiatives, most operators will find more than enough budget to fund a data strategy network-wide — and likely spend LESS overall than they're spending now.

Legacy RTU monitoring initiatives costs $500–$1,500 in hardware, $500–$1,000 to install, plus annual software licensing and support — over $2,500 per site before even beginning to address the data these devices produce. There are similar costs to vendor element management software with hardware lock-in, IoT solutions, etc.

A managed data layer costs approximately $250 per cell site to implement, depending on how much data is available — integration, standardization, pipeline, and dashboarding included. Data center efforts are priced differently, but still more favorably than chasing retroactive hardware standardization or migrating to new DCIM software. Your existing equipment is the data source, and in a brownfield network there is no choice but to work with what you have. Your existing equipment starts delivering what it was always theoretically capable of.

4. Vendor Lock-In Breaks in Both Directions

There's an organizational benefit here too. Purchasing wants to put forward a basic spec that any vendor can meet for equipment like cabinets, RTUs, rectifiers, batteries, cooling, and back-up power and let them compete on quality, service, and price. That's the correct instinct. Operations agrees — but is faced with vendor lock-in to try and minimize the number of management interfaces it has to work with. A device that meets every technical spec but uses different management naming conventions creates a new data silo that Operations then has to manage to get even today's minimal visibility into the network.

The result is predictable: either Operations lobbies to buy incumbent vendors again despite better or cheaper alternatives, or Purchasing goes with the more competitive equipment and hands Operations another seemingly unsolvable integration problem.

A data strategy resolves both sides of this. When standardized telemetry exists independent of any vendor's management layer, Purchasing's hardware decisions can be made purely on merit — quality, price, performance. If something better comes along, you move to it. The best equipment is usually the one that is best at performing its role (cooling, rectification, etc.), outside of what its management interface is.  Operations utilizes the data layer to integrate the new equipment to standards.  The data layer solves both the problems of the inconsistent existing brownfield networks, as well as the going forward purchasing decisions.

We apply this logic when recommending various equipment to add functionality to the network as well: cameras, AC meters, PDUs, modems, RTUs and switches. Just choose the best available hardware from a price vs. performance basis, because the data layer removes the vendor dependency that made those decisions complicated.

5. You Own the Data

Proprietary monitoring tools give you access to what the vendor built, on the vendor's terms. When a better analytical capability emerges, or when AI systems need access to that data, you're stuck.   

A data layer built on open standards is different. That dataset feeds Grafana, Snowflake, an AI model, a billing system, existing NMS/DCIM, or new AIops tools. No permission required. In our opinion, what is coming next is inevitable, and owning your own data free and clear is going to be fundamentally important.  Unlike adding new hardware or software, data never becomes obsolete. 

6. Energy Efficiency Becomes Measurable

Networks are not operating efficiently right now and operators don't know it, because the data to see it doesn't exist. Every network we've worked on using these methods initially show large numbers of sites operating significantly outside normal parameters.

Simply comparing site energy usage using data visualization tools points out significant problems immediately. Human directed correction of issues made obvious in an open-source tool like Grafana can save 1–2% of total energy spend. This isn't some advanced AI method, this is simply viewing sites that are far out of range on power consumption, cooling ranges, and other variables.

7. AI Readiness Starts Now — We're Already There

We started almost 10 years ago augmenting more traditional hardware monitoring tools with open-source data streaming tools — Kafka, InfluxDB, Kubernetes, Grafana and others — tools that are now standard in every industry. These tools solve so many problems related to network-wide visibility, security, scaling. We keep finding benefits from using them. One large benefit to adopting such widely used tools, is that it has led us directly to AI use cases.

We have production AI deployments running today on telecom data center cooling infrastructure — Google TimesFM 2.5 models with 14 months of backtested energy telemetry (currently), 50+ walk-forward simulations, with projected HVAC savings of up to 21,693 kWh per year.

The opportunities in data center management are substantial: cooling optimization, load prediction, predictive maintenance, and capacity planning.

The opportunities in cell networks are also substantial: RRU power-saving features, HVAC optimization, battery cycling, diesel scheduling.

All require the same data foundation. Energy efficiency and AI operations capability have nearly identical prerequisites.

The worry about taking the wrong fork in the road on AI strategy is legitimate. This data foundation is the correct fork. Every AI application in infrastructure operations builds on top of it — and nothing useful can be built without it.

8. Deployment Is Fast and Non-Disruptive

FOCUS runs as a network overlay — it doesn't replace the NMS or displace the DCIM. Existing alarm schemes stay intact. Nobody retrains. Hundreds of sites in weeks, not years, without site-by-site hardware deployment.  It isn't a choice to move away from what you are doing now, it is added to it.

9. New Business Models Become Possible

Standardized telemetry unlocks capabilities — and partnering opportunities — that don't exist before the foundation is in place. For towercos and data center operators, energy billing becomes a direct revenue application: accurate, automated, audit-ready. ESG reporting, GSMA benchmarking, ISO 50001, and carbon accounting all run on the same continuous data that feeds operations.

The data also becomes combinable. Vendor partners, application developers, and AI platforms can layer capabilities onto a standardized stream without custom integration at every site.  This data can be paired with AIOps initiatives, RRU PSF efforts, combined with billing or weather data.

Why We Built This

We started ClaritechIO because we believe this architectural shift is inevitable. Open-source data tools are mature, already far better than existing solutions, and constantly improving. AI is going to require this standardized infrastructure data. The economics of proprietary hardware and software keep getting harder to justify. Operators who move now spend less, fix the reliability problem, and arrive at AI readiness ahead of everyone who waited, AND the solutions that can be created quickly and generate immediate reliability and efficiency returns.   It doesn't just fit certain networks, it fits every network.

A 5 site trial is the technical foundation for a 5000 site or 50000 site network. The data starts being useful immediately.

The Math Nobody Wants to Do

Hardware and installation costs vary significantly across the market.  A basic remote terminal unit (RTU) unit from a vendor who is primarily interested in selling software could be around $500. A more capable RTU from a hardware specialist can run well over $1,000 — plus installation, plus a configuration service just to take the unit from a factory default to something reasonable for a specific site type.  The configuration cost alone is in the range of what a managed data layer costs in its entirety.

Whatever you paid for the unit, that is before you've even started to address the actual problem — standardizing the available data from your sites, delivering it consistently across a heterogeneous network, making it comparable and useful at scale. That work still has to happen. Someone still has to figure out how to normalize what the RTU produces alongside everything else in the network, how to deliver and store it, and how to make it comparable and useful across thousands of sites built on equipment from dozens of vendors over several decades.

That problem — the real problem — is where the value of most RTU deployments typically stall. The hardware gets deployed. A simpler alarm scheme gets configured, but the deeper work of turning raw device output into something genuinely valuable never fully materializes.

Whether hardware costs $500 or $2,000, the scope of the data work that follows is basically the same. An RTU is just a tool, someone still needs to know how to utilize it.  Across thousands of sites, that hardware sunk cost is an enormous number. What operators are now asking — with some urgency — is what operational improvement that investment actually delivered.

What Contact Closures Were Actually Solving

To understand why this has occured, it helps to understand a bit of history and what contact closures were designed to do. Historically, networks were built across equipment from dozens of vendors over decades, with no common data standard. Getting any consistent status picture across a heterogeneous network was nearly impossible.

Contact closures solved that by reducing everything to the same language: a major power alarm, a minor power alarm, a high temperature alert. Binary signals any piece of equipment could produce and any monitoring system could interpret. The standardization was real and had genuine operational value — something broke, you knew it at every site, regardless of who made the equipment.

RTUs extended that model and could do more. Many were sophisticated machines capable of reporting far richer data. The problem was that without a real data layer above them, there was nowhere useful for that richer data to go. The telemetry got discarded. What survived upstream was again a set of SNMP traps — a more expensive version of what contact closures had always produced. The industry settled for alarms, because alarms were what the rest of the system could handle.

The result: most RTU deployments are dealing in alarms, not telemetry. Equipment efficiency, trend analysis, site comparisons, the early signatures of a component approaching failure, many measures it would seem you should be able to get from your network, none of that survived the translation.

New Hardware Doesn't Fix This

The natural industry response from equipment vendors is new hardware or hardware features. Smarter controllers from power equipment vendors. Next-generation RTU-like devices with better connectivity and modern interfaces. New software platforms to support specific hardware.

The structural problem is unchanged. Adding more non-standard devices, no matter how smart or featured they are, alongside the tens of thousands already deployed devices doesn't reduce fragmentation — it adds to it.  Even if the new device is genuinely better, the overwhelming majority of the network is not going to get the new hardware in any reasonable timeframe.  

Some RTU vendors are beginning to adopt the modern data streaming methods we advocate — a positive development, but by definition it only extends to their own equipment. It's a difficult position when your business depends on hardware sales: advocating for an architecture that makes hardware interchangeable would undermine the core of what you sell. The implied solution remains: "Put our new solution in every site, and the problem will be solved."

When Hardware Is the Right Answer

This argument is not anti-hardware, and it's worth being precise about that.

Some functions require specific hardware and nothing else will do. If you need video, you need a camera. If you need AC metering, you need an AC meter. If a remote site needs out-of-band connectivity, you need a modem. If you need more ethernet ports, you need a switch. If you need contact closure inputs or output relay control — to exercise a generator, for example — some form of RTU may be the right answer. In each case the hardware is justified by a specific function it uniquely provides, and the value of that function is the test.

What hardware should no longer be considered is the monitoring platform itself. Not because site hardware doesn't work well in isolation — some of it works quite well — but because deploying it unevenly as the data layer across a heterogeneous network is the decision that has produced three decades of fragmentation and the economics conversation operators are having right now.

Software Platforms Are Better — But Still a Silo

What might seem like a reasonable solution to this problem is a hardware-agnostic, proprietary software platform. The pitch is reasonable: no hardware required, works with what you already have, modern interface.

The problem is subtler but structurally similar. These platforms may be hardware-agnostic on the input side, but they are not data-agnostic on the output side. Your data flows into their system in a proprietary format, queryable on their terms, subject to their pricing and their decisions about what you can and cannot do with information about your own network. That's before you factor in AI — if a more capable tool emerges, proprietary software becomes the thing standing between you and it.

There's an economic problem too. Hardware and software vendors both carry significant overhead that has nothing to do with your operational problem — manufacturing, firmware, proprietary development, support infrastructure. Those costs are embedded in what you pay. A company focused purely on the end goal of standardized site data and how to use it avoids that overhead entirely.

What ClaritechIO provides is closer to what a telecom operator would build for themselves — if they had the time, the tolerance for trial and error, and the accumulated expertise. We aren't trying to shoehorn in proprietary tools to create vendor stickiness. The question we asked when founding this company was simple: what would we do if it was our own network? FOCUS is that answer. The goal isn't to make operators dependent on us — it's to impart the method and build something WITH the operator that is genuinely and lastingly valuable.

The Distinction That Actually Matters

The right question isn't hardware versus software. It's whether you end up with a proprietary product or a dataset you own.

A proprietary product — hardware or software — gives you access to what the vendor built, on the vendor's terms. When a better tool comes along, or when AI systems need access to that data, you negotiate with the vendor. Or you don't get access at all.

A dataset you own is different in kind, not just degree. That dataset can feed Grafana dashboards, Snowflake, an AI optimization model, a billing system, a digital twin — anything that exists today, and anything built tomorrow. No permission required. No renegotiation. The data is yours and it goes where you decide.

This is what hardware and software agnostic actually means when it's real: not just flexibility in what the system ingests, but full ownership and portability of what it produces. The value of that portability compounds over time. Every new analytical capability, every new AI tool, every new application can be applied to the same dataset — without starting over.

What Different Economics Look Like

FOCUS is a managed energy data layer — not a software license you configure yourself. ClaritechIO integrates with your existing equipment, standardizes data across every vendor format and protocol in your network, and delivers per-site and network-level dashboards, all maintained on an ongoing basis.  If you have all this intelligent equipment creating data, what is your plan for how that data will be used? Unlike an NMS tool that hands you a configuration problem, FOCUS delivers a working data layer from day one. 

For a network of 1,000 sites, FOCUS can be implemented for several hundred dollars per site — integration, standardization, pipeline, and dashboarding included, deployed rapidly without disrupting current alarm systems or processes. That figure comes down further as site types get templated. More importantly, it replaces two expenditures operators have historically made sequentially: the hardware entry fee, and the data work that always had to follow.  FOCUS skips the first by working with equipment already in your network without needing an RTU as an intermediary device, and delivers the second.   

Existing RTUs and legacy equipment are simply data sources. FOCUS normalizes what they produce alongside everything else in the network.  Your installed base of site monitoring tools finally starts delivering something closer to what it was always theoretically capable of.  

Unlike RTU-based approaches, where partial coverage collapses much of the value, FOCUS delivers meaningful data at any coverage level and improves as coverage expands. New sites and existing sites are addressed by the same layer simultaneously.

An Approach That Works for Both New Sites and Legacy Sites

Designing the data layer for new cabinet specs is one problem. Bringing thousands of existing sites — already deployed, already heterogeneous, already paid for — into the same data standard is a different and larger one. Most new site architectures answer the first and ignore the second.

The only architecture that answers both simultaneously is one that sits above the hardware entirely — normalizing data regardless of what's underneath it, feeding it to whatever tools the operator chooses, owned by the operator rather than the vendor.

The economics align. The AI strategy aligns. The vendor lock-in question resolves. New builds and the legacy network are addressed at the same time.  Unlike hardware-based approaches that can't be cost-effectively scaled across every site type, the same data layer applies equally to your smallest edge sites and your largest data centers.

It is not a complicated argument, but it is one that you may not have heard because it works against existing voices in the industry, because it works directly against their current business models.

The Point Solution Trap

A towerco identifies a specific operational need. Maybe it is AC metering — they need to understand power consumption at their sites to manage energy costs. So they deploy an AC metering solution, likely with its own modem connection. 

A year later, the same towerco needs IP cameras at some remote sites for security, or a diesel fuel probe for accurate diesel fuel measurements, or rectifier information.   They might get a camera solution from a security vendor, an IoT solution for fuel monitoriing, and an element management software from a particular rectifier vendor.

A year after that, a major tenant negotiates for energy billing — they want to pay for what they consume rather than a flat rate. The towerco works to deploy a billing method.

Maybe the towerco recognizes the downsides to using single point solutions, and an attempt is made to consolidate point solutions using hardware-based RMS (Remote Monitoring Systems), RTU, or other broad-based software solutions.   These might be better, at least an intermediate step at reducing the number of modem connections to the site, but have various problems, fundamentally in what they don't solve.

These solutions are how data silos are built, not through bad decisions, but through a series of locally reasonable ones. Maybe each of the systems described above solved a real problem, but the collective result is fragmentation that makes every subsequent problem harder to solve, because each new need now has to navigate around the silos that already exist.   Every tower company and telecom operator without the luxury of building a network from scratch suffers from this problem.

It is like accumulated debt.  Ultimately the goal is standardization, and this debt will have to be paid sooner or later if operators really want to solve the operational problems in their networks.  

What a Data Strategy Changes

Unlike point solutions, a towerco data strategy doesn't start with an immediate operational problem. It starts with different questions: what mix of equipment and data is already available in my network, what point solutions have I tried, and do I have site network connectivity?

For a grass-and-steel towerco, this data strategy might initially need to answer only a handful of questions: grid power status, basic site availability, anomalies that warrant attention. Simple obligations, simple data needs, but the foundation should still be built to expand, because the obligations won't stay simple forever.

For a managed infrastructure towerco, the data foundation needs to support more: power delivery metrics, backup performance tracking, cooling status, potentially renewable energy contribution and management. These are the inputs to the KPI calculations — Power Availability, Power Backup, Cooling Availability — that define SLA compliance in this model. The specific KPIs that matter depend on what the towerco has committed to its tenants. The data foundation that makes them measurable is the same regardless.

The point solutions a towerco would otherwise purchase to address each of these needs individually become applications of the data foundation rather than separate systems creating separate datasets.  Standardized site data can be combined together in different ways or with external data like energy tariffs to deliver many additional functions, like energy billing.  Each additional use is made possible by the SAME underlying data created as part of your overall site data strategy.

Why It Matters Now

The argument for a data strategy over point solutions has always been sound. What has changed in 2026 is the availability of open-source tools that can create standardized data cost effectively, and the arrival of AI that will only operate on standardized data.

Every point solution deployed today creates a data silo that is, by design, inaccessible to AI systems that were not part of that vendor's ecosystem. An AC metering platform that does not expose its data in a standardized format is not just a monitoring limitation, it is a barrier to every future optimization algorithm, anomaly detection model, and predictive maintenance system that will want to consume that data.

Towercos purchasing point solutions today are not just creating integration debt for their current operations. They are making a bet about the future of their data: either that they will never want AI systems to have access to it, or that their current vendors are more suited to manage any AI usage on their data than they are themselves. That is an increasingly difficult bet to justify.

A data strategy built on open, normalized, vendor-agnostic telemetry that is owned by the customer has essentially unlimited upside as AI tooling matures. You could expect to gather 50-100 energy and other parameters per minute from every tower location in your network, and this data has value.   A massive, standardized, growing, historical dataset grows more valuable over time, not less, and if you have a large head start on your competitors, the value is even larger.

The Practical Path Forward

The data strategy approach does not require replacing equipment that already exists in your network. In most towerco environments, the equipment that can supply the right data is already deployed, including all the point solutions mentioned above, as well as modern rectifiers, battery management systems, environmental sensors, and power distribution equipment that has been capable of producing granular telemetry for years.  New open-source tools (and knowledge of how to use them) standardize that data without asking the towerco to rip out and replace anything.

A proper data strategy is additive, not disruptive. Whatever alarm and monitoring infrastructure a towerco has invested in, whatever NOC processes and ticketing workflows have been built around existing systems that are working well, those stay in place. The data layer operates alongside them, providing the foundation that existing systems were never designed to deliver, and could even supply data back into these same systems.  Personnel in your organization are able to help work with this data.  It is a path to your organization and personnel building AI-related skills and advantages.  A provider of a data strategy and standardized data, like ClaritechIO, is not a gatekeeper to the use of the data.   The data is ultimately yours.   

You benefit from the ability to answer new questions from a single, expanding foundation, without deploying a new silo every time a new question arises.  If you want to deploy cameras, then the answer is to just examine how video fits into this data strategy.  If you want to buy PV gear, generators, rectifiers, or cooling equipment, you can purchase the equipment from whatever vendor you believe gives you the best value, as you aren't tied to any particular equipment's management interface.   The data strategy is fundamentally built on an ability to work with any equipment. 

You don't cede control of key elements of managing your network to vendors who benefit from the siloing of your data as a form of vendor lock-in. 

That is the practical difference between a data strategy and another proprietary monitoring purchase.  These benefits will compound in favor of the operators who make it early, and it is somewhat ironic that pursuing this data strategy path will cost less than continuing to buy point solutions that are never going to deliver what you're hoping for due to the data silo problems mentioned above.   It is a much better solution at a lower cost.