Creating Enterprise Architectures That Are Modern and Open in the IIoT Age – Part Two

Part One, which was published in Industrial IoT/Industrie 4.0 Viewpoints on Thursday, October 12th, addressed considering the whole enterprise and using open standards.  Part Two will address “Why Open Architectures”, “Technology Migration and Integration”, and conclude with “Centralized System Administration Needed”. 

Open Enterprise Architecture

Machine Manufacturing

The concept of an open enterprise architecture that links plant floor operations with business operations across an entire corporate entity has been around for a while in many industrial sectors.  But making this concept a reality remains challenging.  This is particularly true for those companies that lack huge IT staffs or budgets.   IIoT, with its compelling promise of accessing, aggregating, and analyzing data from previously stranded assets and systems to improve decision support and thus business performance, represents a further disruption.  

Why Open Architectures?

How can you enable the enterprise to get the data it needs without stifling innovation or interrupting operations at the plants? Open architectures that decouple applications from devices provide one practical answer. 

In a conventional system architecture, intelligent devices such as PLCs are coupled to applications through proprietary protocols. Any application can interact with any connected device. Typically, in these architectures the SCADA software communicates with the PLCs and, while not it’s intended purpose, the software is often used as middleware because it has the protocols needed to do so. In a decoupled architecture, applications are not connected to devices, but rather, devices are connected to infrastructure so that applications can subscribe to the data they require.

Rather than using SCADA as middleware, decoupled architectures often use some type of message-oriented middleware, such as MQTT. In the example shown, devices publish data by exception up to a central MQTT broker (which can be on-premise or in the cloud). SCADA can subscribe to data, and other applications (ERP, MES, BI, etc.) can also access the same data. Think of it as a sort of “data buffet” in which various systems and tools can take advantage of the data they want. Instead of having to integrate programs with each other, the programs have direct access to data. This also offers plug-and-play interoperability for new devices or sensors.

By making the device the single source of truth for tag information, decoupled architectures save thousands of man-hours and allow everyone in the enterprise to have the same data on which to base their business decisions.

In short, this type of decoupled architecture can provide the functionality needed to realize many of the benefits of IIoT, including better and simplified connectivity between sensors and applications across an enterprise.

Technology Migration and Integration

Another important reason for using open standards and architecture is the vast number of companies with multiple, disparate brownfield plants. To integrate a brownfield facility into a real enterprise solution, you’ll need to standardize the data and data models. Realistically, this will require some financial investments to implement tools at the plant that can convert the data to a known, interoperable format. As mentioned earlier, edge gateways can be installed next to PLCs in the plants to poll the PLC data and get it into a decoupled, message-oriented middleware infrastructure. This can be developed in parallel with the existing SCADA systems that are directly communicating with the PLCs, and then eventually the organization can start transitioning everything over to the new architecture. This requires investing in some new hardware, but it’s an investment that offers excellent potential ROI. 

It’s also important to acknowledge that no one solution can do everything the organization needs. It’s vital to have a solution that can integrate with tools for business intelligence, machine learning, open-source software, IIoT, edge computing, business management, and more. Think about whether you could integrate the solutions and architecture in your plant now with these other tools. Going forward, invest in solutions that can integrate with other solutions; otherwise you’ll find yourself stuck on a data island.

Conclusion:  Centralized System Administration Needed

With an effective enterprise architecture, your organization will have a powerful “observatory” for central administration. Corporate could check on performance at the plants and manage overall business performance. Projects and templates could be centrally managed and pushed out to your sites. Backup and recovery, deployments, project synchronization, updates, and many administrative tasks could also be managed centrally. You’ll have an architecture that supports new tools like business intelligence and analytics.

Imagine what the ROI would be if you could gather all plant data in a standardized format at a central point, leverage new tools, increase efficiency, improve decision making, and quickly upgrade individual pieces of your architecture? It’s very likely that this could help save many thousands of hours and millions of dollars.

This goal is achievable, but only if you adopt solutions that can bridge the gap between OT and IT. Also, keep in mind that you’re not just building for today’s needs, but also for your future needs, so use software that is scalable not only in terms of technology but, ideally, also in terms of licensing.

Properly building a modern, IIoT-enabled enterprise architecture will take careful planning and investments of time and money, but once up and running, it would be likely to yield benefits that could help your organization thrive and stay ahead of the competition for many years to come.  



  1. I personally agree that the digital architecture has to be built on standards for all the building blocks at every level of the enterprise. The standards are already available. I also agree that one standard does not fit all. At the sensor level we will see one standard such as FOUNDATION fieldbus for networked sensors, for wireless sensors it will be WirelessHART, for software applications it will be OPC-UA etc. These standards have well defined information models which are missing in MQTT. Learn more about how other plants are doing it from this essay:

  2. Like Jonas, we agree that an open architecture is a worthwhile approach to IIoT. We also see the value in a middleware approach. But we don’t consider MQTT an adequate solution. For one thing, the data “buffet” envisioned, with plug-and-play interoperability, is not actually feasible with MQTT.

    This is because MQTT is a messaging protocol, not a data communications protocol. The data format is determined by each client that connects, which means there is no interoperability between applications. To make MQTT work you must either translate data protocols for each new connected device and client, or you need to source all devices, programs, HMIs, etc. from a single vendor.

    There are other serious drawbacks to MQTT, which to our minds make it ineligible for any serious Industrial IoT application. These are discussed here:

  3. There are several items that need to be addressed with this “data buffet” approach to automation.
    1. Rarely do manufacturing facilities get to “start over” and re-implement existing automation solutions. So any approach needs to reflect the reality of add-on and incremental design.
    2. While many would like to think otherwise, in today’s world the data is not free. It costs bandwidth and storage space (real $) to move and monitor each data point. Since not every application needs every data point, that seems like an opportunity for optimization. The traditional SCADA system does a good job at isolating the control needs from the business needs.
    3. Every application is a producer as well as a consumer of data. SCADA systems, Historians, MES, ERP, etc. all generate new data points which add to the overall bandwidth and cost. Emerging cloud and on-premise analytics will be voracious consumers and producers as well.
    4. The OT-vs.-IT responsibility conflict is very real, and can’t be dismissed without the entire team understanding who will be responsible for troubleshooting when the data is “missing.”