More sites shouldn’t mean more systems
I spend a lot of time with operations teams running more than one site, and the conversation nearly always lands in the same place. Every site has data. Every site has someone clever who has built something useful with it: a Power BI screen that falls over whenever a tag gets renamed, or a spreadsheet older than the graduates we hired this year, still passed around with the original author’s initials in the filename.
Somebody at each site usually knows how to work around it, which is the only reason it’s held together this long. That workaround stops helping the moment head office needs to compare sites rather than look at one. Ask which site had the worst alarm performance last month and nobody can just pull that up, because the data lives in different systems, often in different time zones, so someone has to go and chase it all down by hand before anyone can say anything with real confidence.
Why the usual fixes stall
Two common approaches are centralisation and deployment at the edge. Both can work well, but each introduces trade-offs that need to be managed.
Centralisation creates consistency by bringing operational data into an enterprise platform that can support shared governance, analytics and applications. The challenge is that, in complex industrial environments, moving every source system can become a lengthy migration programme. A more practical approach is often to connect existing systems of record while centralising the context and capabilities that deliver value across the organisation.
Deployment at the edge can deliver value quickly and meet the specific needs of individual sites. The challenge emerges when deployments evolve independently – creating inconsistent definitions, duplicated maintenance and uneven security or upgrade cycles. Enterprise standards and shared governance can preserve the flexibility of edge deployments while keeping the wider estate aligned.
What changes when the platform is a service?
Consider a group with eleven plants, three historian platforms and locally defined alarm reports. The conventional approach produces eleven integration projects. The alternative is to standardize the connection and context once, then reuse the application layer. This is where Asset Intellect Cloud actually changes the shape of the problem, and it’s worth walking through properly.
Asset Intellect Cloud reads data where it lives. A small connector service sits beside the sources (like AVEVA PI, SQL Server, Canary, AVEVA Connect, InfluxDB, etc.) and exposes it through the Asset Intellect Gateway over outbound HTTPS. There’s no inbound firewall port to open, and the capture itself is read-only, so nothing ever gets bulk-copied anywhere it shouldn’t be.
That distinction shapes the security conversation. Asset Intellect Cloud receives replicated data for analytics and reporting, but it sits outside the control loop entirely. Production doesn’t depend on that connection at all. The plant keeps running exactly as it always has, whether the internet’s up or not, and a dashboard is the only thing that would ever notice the difference. Once people sit with that, the Purdue objection usually resolves itself into a firewall rule.
The multi-site economics change too. Adding a site becomes a subscription change rather than another server deployment and patching obligation. For example, you can deploy our alarm module for every site, including plants running different historians, because the connector layer gives the application above them a consistent interface. That is the standardization prize, and it is the part the executive team cares about. Downtime stops meaning twenty different things depending who you ask, the alarm metrics follow ISA-18.2 across the board, and there’s finally one place to look instead of eleven.
Where AI earns it’s place
Xora, our AI layer, shows why the plumbing matters. It answers natural-language questions across any Asset Intellect Cloud data source, including asset hierarchies, process data, alarms and maintenance records, scoped to what each user is already permitted to see, and it runs inside the customer’s own AWS environment in their chosen region.
None of that works without the connector layer underneath. An AI assistant pointed at eleven disconnected systems is a chatbot with opinions. Pointed at a consistent data surface, it can take “which assets had the most alarms in the last 24 hours, and what was their maintenance history” in a single pass. The model gets the attention, but the joins underneath are doing the actual work.
What actually closes the gap
I have largely stopped describing this as bridging IT and OT, because it makes the answer sound like middleware you buy once. What’s actually going on is more like an agreement, both sides working off the same surface, on an ongoing basis, rather than one team handing something over to the other.
Security is independently verified too. Dimension Software is ISO 27001 certified, with our information security practices regularly assessed by an accredited independent auditor.
What ties all of this together financially is cloud. It’s what makes this whole approach affordable once you’re managing more than a handful of sites, and connecting the twenty-first site ends up costing less than connecting the first one did.
