Our journey through the Analytics That Matter series has shown that the Operational Architecture is a critical factor in building an analytics environment that can deliver value at all levels (descriptive, diagnostic, predictive and prescriptive). It’s also clear that where Operational Architecture is concerned, one size does not fit all. Operational Architecture is one piece of the operational and data model puzzle manufacturers need to ensure success. Many industrial organizations ask, “Why doesn’t one size fit all?” Let’s explore that statement and explain why right-sizing each element is key for success.

Click here to speak with Andrew Hughes

ISA-95 and Manufacturing Operations

Many manufacturers have little or no computing architecture in their plants. As a result, the dream of shop floor to top floor integration remains just that, a dream. However, many companies have developed manufacturing operations management (MOM) systems and implemented a control hierarchy that roughly follows the ISA-95 model.

This approach has proven valuable for managing the control hierarchy and its connection to business systems (especially ERP). As manufacturers make plans for Industrial Transformation, they will discover that the vertical ISA-95 architecture is useful but not sufficient. Industrial Transformation requires a far wider view of data and applications than a typical ISA-95 hierarchy. At the communication level, for example, modern architectures are starting to move towards distributed data management supported by comprehensive Internet protocol (IP) networks.

Expanding the Architecture

Data is similarly moving from a manufacturing focus to the concept of Big Data (structured, unstructured and time series) that can reside anywhere from device and edge storage to the public cloud. Each part of a digital enterprise will use different data, but the concept of free (yet secure) access is a prerequisite for Smart Manufacturing and the Industrial Internet of things (IIoT). The starting point for an overall architecture, from an operational viewpoint, is understanding how the elements support and interact with each other.

An enterprise must address each of the four layers to complete the Operational Architecture but there is potentially much more to be done than just that. As a company shifts to pure IIoT and transforms itself at the enterprise level, it must expand the architecture to fully support the broad IoT program. One example of close cooperation between Operational Architecture and other transformative programs is product lifecycle management (PLM) and the Digital Twin. The development cycle supported by PLM goes from ideation, through CAD, simulation, process design, manufacturing, and service. The applications that support these processes traditionally use a PLM platform for communications and management. The march to “digital enterprise” is often led by PLM activities in discrete manufacturers who want to keep the PLM capability. This requirement will involve the marriage of Operational Architecture with PLM architecture to support the integrated enterprise.

In this case, the crossroads of PLM and operations will usually be in manufacturing operations management (MOM), where design meets build. Data such as manufacturing bills of material (mBOM) will often reside in the PLM platform, even though many companies prefer to handle them in the business system since they are required, for example in purchasing and planning.

Just this one example confirms that the data architecture must be fully and properly integrated and that applications that exist in different parts of the enterprise have access to the required information. It shouldn’t matter where a company stores mBOMs if the applications that create and use them have the access they require.

No “Right Answer”

As research analysts, we are in the habit of being prescriptive about complex subjects like Industrial Transformation. Where enterprise and operational architectures are concerned we believe just the opposite – each company must forge its own path.

Many factors dictate the “best” architecture for a manufacturer, with one of the primary ones being what it looks like today. LNS Research strongly believes that evaluating the as-is state is the essential first step to establish a successful Operational Architecture. The same holds true for the business and product architectures.

When documenting as-is, aim for as much detail as possible. Just as important is to concentrate on actual current state and avoid the “as we meant to build it but...” result. There is much more freedom and flexibility with designing the to-be architecture—that is the time to express systems the organization doesn’t want to replace, and make sure they support or properly engage with the four levels of architecture: application, data, compute, and operations. Many industrial organizations find that documenting an “I wish I could do this or that, but let’s be pragmatic” state is much more valuable in the long term.

Ultimately, success will depend on the process the organization uses to document current state and define future state Operational Architecture. The right process will take into consideration the as-is state and enterprise Strategic Objectives, and address current and future needs where people and processes are concerned.