Creating Modern, Open Enterprise Architectures in the IIoT Age

By Craig Resnick


The concept of an 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 oea1.JPGthat lack huge IT staffs or budgets. emerging Industrial Internet of Things (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.

Before terms such as “Industrie 4.0” or “IIoT” entered the popular vernacular, most industrial organizations had different data, hardware, and software at each of their plants, with no elegant way to get plant data to the corporate level.

As IIoT awareness spread, demand has grown at the corporate level to acquire, view, and analyze more data from the plant operations and turn it into actionable information. This could save companies millions of dollars, improve decision-making, enable centralized management, and pave the way for new technologies like machine learning and predictive analytics. However, successfully transitioning to an enterprise system architecture is no small task. To meet these new demands, industrial organizations need an automated process for delivering plant information to the corporate level in an accurate, standardized, efficient, and secure fashion.

Consider the Whole Enterprise
For most organizations, the first step toward an effective enterprise architecture will be to shift away from thinking of operational technologies (OT) and information technologies (IT) as separate worlds. Instead, they should align OT and IT so that operational data can be shared effectively with business applications.

Also, the challenges of building an enterprise architecture shouldn’t be addressed with top-down thinking. Although it may sound paradoxical, the demand for a centralized enterprise architecture comes from the top, but should be built from the bottom up, starting right at the sensor level in the plant, and always with an eye toward business objectives.

oea2.JPGFurthermore, companies should stop thinking of each plant as an island and, instead, look at it as part of the larger corporate system with common standards and data transport mechanisms. Companies must ask themselves: What do we need to do at the plant level to support the enterprise? This almost always requires secure connectivity.

Organizations need to work on balancing the basic need for security with the need for data. Fortunately, existing technologies can be used to get data up to the central system in an open format without compromising operations. While “air gapping” was often employed in the past as a security measure, this approach isolates OT from IT and thus won’t serve the enterprise’s data needs going forward. To ensure proper security, data should be encrypted when shared across sites. For those plants that use PLCs, it’s also often helpful to place an edge gateway next to each PLC, so you can get PLC data into an open format while keeping it secure.

To Ensure Proper Security, Data Should Be Encrypted When
Shared Across Sites (Source: Inductive Automation)

Use Open Standards
To build a system with central visualization and administration, it is essential to start developing standards across the entire enterprise. To bring different plants that have different PLCs, tags, addressing schemes, and so on, into a standardized system, it’s often helpful to employ an open source protocol, supported by many applications.

Some common open standards are: OPC UA and MQTT, both primarily used to get data from devices; SQL for working with SQL databases; and APIs (either OPC UA, SOAP or REST) for integrating with other systems.

Once your organization chooses an open standard, you can then standardize your data models so data from all plants will look the same when sent up to corporate. This is often a more practical approach than gathering different-looking data from different sites and translating it at the top.

The protocol you choose as your model should have built-in encryption, as well as “stateful awareness,” in other words, tells you if you’re connected to a specific device. This combination of encryption and stateful awareness provides one approach for getting operational data to the business side in a standardized way without compromising operational security. OPC UA and MQTT protocols both offer built-in security and stateful awareness.

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 the example below, a coupled architecture using a poll-response protocol is shown on the left; and a decoupled architecture using a publish-subscribe protocol on the right.

Coupled Architecture Using Poll-Response Protocol vs.
Decoupled Architecture Using Publish-Subscribe Protocol
(Source: Inductive Automation)

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 oea3a.JPGSCADA 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 oea3b.JPGa 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.

As we learned in a recent interview with Steve Hechtman, president and CEO of Inductive Automation, developer of the Ignition industrial application platform and a strong proponent of MQTT, "When you peel away all the hype, IIoT is just a new architecture based on the practice of oea4.JPGdecoupling applications from edge-of-network devices.” Mr. Hechtman elaborated: “By contrast, in a conventional architecture, you’ve got all these applications connected with all these edge-of-network devices. That leads to lots of resource problems, network problems, security problems, data redundancy, poor documentation and maintainability, and data getting stranded in the field.”

"In this new [open, MQTT-enabled] architecture, you're decoupling applications from endpoint devices, with a broker in the middle,” said Hechtman. “When you set up this type of architecture in Ignition, you now have single comm channels and you can manage everything in the broker. Data is bi-directional and state is maintained, which is really important in our business because you need to know if you can trust the data that you're looking at. From this architecture, we get better security and network utilization, and a whole host of other benefits."

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, IoT, 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. oea5.JPGYou'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.

ARC Advisory Group clients can view the complete report at ARC Client Portal on Office 365 or or New Client Portal on this website

If you would like to buy this report or obtain information about how to become a client, please Contact Us


Keywords: Enterprise Architecture, IIoT, Industrie 4.0, Information Technology (IT), Operational Technology (OT), MQTT, ARC Advisory Group.

Engage with ARC Advisory Group