Why should an industrial enterprise need an IIoT platform alongside its SCADA, MES, and enterprise asset management systems? If those operational applications already contain the relevant data and are flexible enough to support new requirements, what responsibility remains for another general-purpose platform?
My view is that this question will become increasingly difficult to answer. The standalone IIoT platform will either lose its identity as a separate software category or become the common foundation for the operational applications themselves. SCADA, MES, EAM, predictive maintenance, and other applications will retain their purposes, but fewer of them will need independently engineered technology stacks.
This is a prediction about the direction of industrial software, not an argument that every existing IIoT deployment is unnecessary. A platform that solves a difficult integration or analytical problem today can deliver substantial value. The longer-term question is whether delivering that value will continue to require a separate platform running in parallel with the systems that operate the enterprise.
The Operational Stack Already Has the Data
The starting point is broader than machine telemetry. Industrial operations involve measurements, equipment states, alarms, production orders, recipes, material records, operator inputs, and maintenance information. Manufacturing information models already encompass the connection between these worlds: the OPC UA companion specification for ISA-95 job control, for example, describes orders containing workflow, material, equipment, personnel, and physical-asset requirements, with orders originating from ERP or MES environments.
Consider an enterprise where the SCADA, MES, and EAM landscape already holds the information required for a proposed IIoT application. Its measurements come from machines, its production context comes from manufacturing operations, and its commercial requirements arrive from ERP. In that situation, the parallel IIoT platform is primarily another consumer of information already available within the operational landscape. Installing it does not, by itself, create a new source of knowledge about the factory.
That does not mean it cannot create value. A scheduling engine can produce a better production sequence from existing orders and constraints. An analytical model can identify a useful relationship in previously collected measurements. The distinction is that additional value does not necessarily require an additional platform. The application may be valuable while the separate infrastructure supporting it becomes increasingly difficult to justify.
The critical condition is flexibility. Simply storing the data is not enough; the operational foundation must also support the models, analytics, workflows, and interfaces needed to act on it. But once those capabilities are available, the question changes. Instead of asking why an enterprise needs advanced analytics, we should ask why those analytics need another general-purpose industrial software environment.
The Real Pressure Is Lifecycle Complexity
The strongest argument for convergence is not the overlap between feature lists. It is the work created when related applications develop and operate independently. Consider a fragmented installation in which each product maintains its own equipment representation, data storage, access rules, configuration, and deployment procedures. Every additional application introduces another environment that somebody must understand, secure, maintain, and connect to the others.
Data duplication is only one part of that burden. The same machine may need identifiers and relationships mapped across several systems. The same employee may require access configured in multiple applications, even where authentication is centralized. A change to the production model may require adjustments to interfaces, reports, permissions, and application logic in several places. Each change then needs testing across the boundaries between those products.
The SCADA-to-MES boundary illustrates the problem. Moving a machine value across an interface is only the beginning. The applications must agree on what the value means, which equipment and production activity it belongs to, how changes are communicated, and what happens when communication fails. Add maintenance and predictive analytics as independently engineered environments, and there are more places where those meanings and responsibilities must be reconciled.
The cost also extends to people. Separate technologies require separate competencies, and failures crossing product boundaries require coordination among support teams. Multiple vendors are not inherently a problem; multiple unrelated foundations are. There is a significant difference between several specialists contributing applications to a coherent ecosystem and several suppliers each bringing an independent environment that the customer must assemble.
My expectation is that enterprises will increasingly question this recurring overhead. The economic attraction of a common foundation is not simply a cheaper initial integration. It is making the next equipment addition, workflow change, application rollout, or security revision less complicated.
Two Futures for the IIoT Platform
One possible outcome is that operational products absorb the capabilities used to justify a parallel IIoT platform. A sufficiently extensible SCADA, MES, or broader operational platform can support additional analytics, optimization, and application development. The functionality survives, but the separate product category becomes less meaningful. In this scenario, IIoT becomes a set of capabilities rather than another system the enterprise must buy and maintain.
The other outcome is that the IIoT platform becomes the foundation on which those operational applications run. It provides the shared infrastructure and engineering environment, while SCADA, MES, EAM, and predictive maintenance become substantial applications within that environment. The platform is no longer competing for a position beside the operational stack. It is supporting the stack itself.
These routes can converge on a similar architecture from different starting points. A product originally associated with SCADA may become a broader application platform. An IIoT platform may acquire the operational depth necessary to host manufacturing and maintenance applications. The category name matters less than whether the resulting architecture reduces duplicated infrastructure while preserving functional depth.
The role I expect to become less defensible is the permanent parallel platform: another general-purpose environment consuming the same operational information, recreating its context, and delivering functionality that the operational foundation could increasingly provide itself.
SCADA + MES Inside IIoT Platforms
A common foundation must mean more than common ownership, a shared login screen, or several products running on the same cloud. Applications need reusable services and coherent ways to work with equipment, information, events, permissions, and application lifecycle management. Otherwise, the complexity remains underneath a more unified-looking interface.
This is the architectural approach behind Iotellect. Our platform supplies capabilities such as connectivity, HMI development, historical storage, alarming, and reporting. The manufacturing layer adds its domain model and application logic rather than rebuilding that infrastructure. Iotellect MES provides manufacturing modules for functions including scheduling, performance, and traceability, while inheriting reporting, historian, and HMI capabilities from the underlying platform.
The manufacturing model remains essential. Orders, recipes, products, materials, and their relationships are not interchangeable with a collection of tags. Traceability, scheduling, and overall equipment effectiveness require manufacturing-specific behavior. A historian and a dashboard builder do not become an MES merely because someone places them under an IIoT label. The common foundation must support real applications, not leave every partner to reconstruct them from a blank toolkit.
The practical objective is to develop specialized functionality around an existing operational model. Imagine adding a quality application that can reuse equipment identities, production context, access controls, and visualization components already available in the environment. The quality logic still requires engineering and domain expertise, but the supporting infrastructure does not need to be invented again.
This approach already has a concrete industry counterpart. Sepasoft’s MES modules are built using Ignition’s module SDK and extend the Ignition platform, with modules covering functions such as OEE, traceability, batch procedures, and statistical process control. That does not prove that all industrial applications will converge on this model, but it demonstrates the distinction between applications sharing a foundation and independent products merely exchanging data.
A Common Foundation, Not a Single-Vendor Suite
The platform I envision is not an attempt by one vendor to become the world’s expert in every manufacturing process. Its strength would come from the ecosystem. The platform supplies shared infrastructure and substantial standard applications; partners contribute the specialized knowledge needed for particular factories, machines, processes, and operational objectives.
Mobile platforms offer a useful analogy. Android provides core applications and reusable system services, while independent developers build applications through the platform’s framework APIs. Those developers do not each need to create another operating system before addressing their particular use case. The analogy is about the division of engineering responsibility, not an assumption that industrial applications should inherit a mobile platform’s deployment or operational model.
Atlassian illustrates a related pattern around established business applications. Its Forge platform lets developers extend products such as Jira and Confluence while using services including hosted compute, storage, authentication, and deployment environments. The application developer can concentrate more effort on the additional functionality rather than independently operating all the infrastructure underneath it.
For industrial software, the standard applications must be considerably more than demonstration projects. A prospective partner should be able to begin with meaningful SCADA, manufacturing, or asset-management functionality and then specialize it. A company with deep knowledge of food processing could develop process-specific applications. Another could focus on a particular class of machines, maintenance methods, or production constraints. Their expertise remains essential even when their applications share a technical foundation.
Integration does not disappear in this model. Two applications can still represent a business concept differently, and sharing storage alone does not reconcile those meanings. The platform and its ecosystem must establish usable models, interfaces, and extension conventions. The objective is to make integration more standardized and less repetitive, not pretend that every industrial application becomes interchangeable.
The Opportunity for Integrators and Application Vendors
For system integrators, engineering companies, and ISVs, this vision changes where it makes sense to invest expertise. The more reliable functionality the common platform provides, the more effort a partner can devote to the industrial problem itself: how a factory schedules work, how a process maintains quality, how a machine should be serviced, or how a production constraint should be represented.
Consider a partner developing a specialized maintenance application for a family of industrial machines. Its distinctive contribution could be the failure models, diagnostic procedures, service workflows, and understanding of operating conditions. In the proposed ecosystem, it would not also need to create a separate permissions framework, historian, reporting engine, and application-distribution mechanism to deliver those capabilities.
This creates an opportunity for specialization without requiring a separate platform business. It could also let an integrator address more requirements within an existing customer relationship, reusing both technical foundations and accumulated operational knowledge. Neither outcome guarantees higher margins or easier delivery; domain modeling, validation, customization, and support remain substantial responsibilities. The intended improvement is that more engineering effort contributes directly to the customer’s process instead of maintaining duplicate infrastructure.
The same distinction applies to competence. A common environment could reduce the number of unrelated technologies a team needs to master, but it does not make SCADA expertise equivalent to manufacturing or maintenance expertise. The ecosystem succeeds when it makes those specialties easier to combine, not when it assumes they are unnecessary.
An Operational Counterpart to the ERP Foundation
The organizing analogy is ERP: a common environment around related enterprise business responsibilities. I expect a comparable role to emerge more clearly for machine-facing and operational applications. Production, equipment, maintenance, quality, and analysis would have a shared foundation, with specialized applications supplying the required depth.
This does not imply a single server, database, or runtime for an entire enterprise. A common platform can support distributed deployments and different operational boundaries. In the architecture I am describing, local functions should retain the autonomy their requirements demand, and security or availability boundaries should not be removed merely to make a diagram simpler. Consolidating engineering foundations is a different decision from placing every workload in one failure domain.
Nor does this require an immediate replacement of every existing application. An enterprise could adopt a common foundation for new requirements, coexist with installed systems, and expand its role over time. Some specialized products may remain separate where their capabilities or operating constraints justify that choice. My prediction concerns the preferred direction of platform development, not a universal migration deadline.
The important question is what each new project leaves behind. Does it create another independently maintained environment, or does it add a useful capability to a foundation the enterprise can reuse? Over time, that difference determines whether the operational landscape becomes easier or harder to change.
Platform Dependency Is a Real Trade-Off
A common foundation creates a significant dependency, and an ecosystem does not make that dependency disappear. Multiple application vendors may provide alternatives at the application or implementation level, but they still rely on the underlying platform. A serious assessment must consider the platform’s continuity, the customer’s access to its information and application definitions, and the practical ability to maintain the installation if a supplier’s priorities change.
Source-access arrangements and software escrow can form part of that protection. Their usefulness depends on agreed release conditions, appropriate rights, and access to the materials needed to rebuild and maintain the software—not source files alone. Build instructions, dependencies, configuration, documentation, and verification all affect whether the proposed continuity path is workable. These arrangements can support recovery; they do not guarantee inexpensive maintenance or continued innovation.
I do not see this risk as an argument against common platforms in principle. It is a trade-off to evaluate against the dependencies and lifecycle burden of several independent systems. The case for consolidation must be strong enough to justify the dependency, and the continuity provisions must be strong enough to make that choice responsible.
The Future Is About Foundations, Not Labels
I do not expect the need for SCADA, MES, EAM, or predictive maintenance to disappear. Their operational responsibilities remain distinct and important. What I expect to weaken is the assumption that each responsibility needs its own complete technical environment. And that another IIoT platform must then sit beside those environments to make them more intelligent.
The standalone IIoT platform therefore faces a strategic choice. It can become the shared foundation for industrial applications, with substantial standard functionality and an ecosystem of specialist vendors. Or it can remain a parallel layer while increasingly capable operational platforms absorb the reasons customers once needed it.
The eventual name may be IIoT, an industrial application platform, or something else. For customers and partners, the more consequential distinction is whether adding functionality requires adding another stack. My vision is a future in which industrial applications become more specialized while their foundations become more shared. The platform’s value will be measured not by how much additional infrastructure it introduces, but by how much repeated engineering and operational complexity it removes.