Representative End User Clients
Representative Automation Clients
Representative Software Clients
Executive Overview
A wave of digital transformation is sweeping through the industrial sector. Driven by innovative and potentially disruptive technologies, and by an emerging understanding of possible new ways of serving customers and competing in the marketplace, industrial companies are modernizing their IT and OT software. Companies have recognized that 
the automation and software platforms they relied upon for years will not be sufficient to carry them into the future. Expectations and norms developed at the end of last century will, at times begrudgingly, be re-placed by 21st century ideas.
How will the arrival of cloud and Industrial IoT architectures, edge connectivity and platforms, and containerization impact plant software? Once upon a time, the state-of-the-art solution for optimizing production operations were termed manufacturing execution system (MES) or manufacturing operations management (MOM). While we use these two terms interchangeably in this report, readers familiar with the AN-SI/ISA-95 (IEC 62264) standard will be more comfortable with the latter term.
But with the advent of modern software platforms and machine learning, does using a monolithic MES/MOM application still make sense? Increasingly, companies are discovering that the new software architecture not only alleviates some longstanding problems, but also enables better business performance. It allows for more innovation, responsiveness, and adaptability at a time when the competitive environment demands it. And it empowers companies to reclaim the control of their software systems that they had previously relinquished to third-party partners.
MES Misconceptions
As ARC engages with our clients and others in the industrial community, we often encounter misconceptions or common “myths” about the future role of MES.
Myth 1: New technology platforms cannot replace MES functions.
Of course, they can and are being replaced. There are many examples of microservices that execute operations management functions that can be deployed in the cloud or on premise. One need only look for them.
Myth 2: MES will no longer be required.
Many enterprise applications suppliers and some independent experts have been insisting that MES functions are no longer required in today’s application environment. Let’s give proponents of this fallacy the benefit of the doubt; it’s likely they have misunderstood the arguments. The functionality of MES will still be needed – and then some. But monolithic, n-tier applications may indeed disappear over time to be replaced by modern software architectures.
Myth 3: IoT platforms will eliminate the need for industry-specific MES solutions.
It’s not IoT per se, but the advent of a new approach to software that will disrupt the current model. Rather than eliminating the need for different functionality for varied and evolving manufacturing models, the 21st century approach to software facilitates creating far more tailored and flexible solutions. Industry-specific functionality will continue to be required, but will likely be provided via microservices.
Myth 4: Today’s monolithic, n-tier MES solutions will be enablers of digital transformation.
While many industrial companies still use paper or other means to manage their production operations, large, complex MES solutions are in common use today. But these have limitations and drawbacks. These include the lag time between the need for new or different functionality and the availability of said functionality in a future release – if at all. Unfortunately, complex monolithic MES applications tend to be part of the problem, rather than part of the solution. But in a transition period, legacy MES applications can be used in parallel with microservice-based apps to complement the solution at lower cost than customizing it.
Myth 5: The long time it typically takes to implement and fine-tune an MES system is a necessary evil.
While it is important to get any software implementation to a state of maturity in which all processes and organizational issues are worked out and well-understood, the expectation that this has to take a long time is worth challenging. It stems, at least in part, from the complexities of last-century software applications, together with the mindset that a large, expensive system would need to remain in place for many years to justify its use. With a modern approach, it may be possible to reduce those long startup or upgrade cycles.
Myth 6: MES is ideal for enabling responsiveness in production and in business models.
This myth smacks of wishful thinking from status quo proponents. Without a 21st century approach to software, there is little hope that any monolithic software application can add all of the functionality that today’s industrial company needs in a timely manner. The wishlist is simply too diverse, and it varies according to the needs of each user.
Characteristics of Last Century Software
Last century, software evolved to fit business organizations. MES/MOM systems provided functionality such as production execution, detailed scheduling, compliance assurance, quality enforcement, resource management, WIP tracking, track & trace, production efficiency, energy, water, & waste management, asset energy monitoring & maintenance, workflow, and work instructions. The best solutions fit specific industry and manufacturing models very well, but over time several expanded to be able to support multiple industries, often using an industry libraries 
approach. Over time, the software was updated with new releases to provide new features and fix bugs. As it evolved, the software tended to become more complex. Software suppliers responded to customer requests for new features or functions by placing them on a roadmap to be eventually incorporated into a future release. Sometimes, tradeoffs had to be made: should the next release include a necessary feature for a new sector the supplier wants to target? Or should a feature that existing customers are clamoring for take priority?
From the user’s standpoint, the off-the-shelf software was rarely, if ever, a perfect fit for their operations. Some provided unneeded functionality, while needed functionality was missing. Workarounds, custom software, and other schemes were developed to adapt the software to each situation. This all consumed time, money, and resources.
Industrial software users found that when they did need to provide supplemental functionality – via coding or some other technique – they also had to support it over time, even as new releases of the commercial software introduced subtle changes. For the suppliers, more and more functionality had to be supported and quality checked for each release, even when features were only needed by a few customers. Still, for most users, a functionality gap developed and increased over time, as the functionality needed or desired by individual industrial companies diverged from the functionality included in a series of releases.
It was the price that had to be paid. Companies understood that these were the inherent limitations of commercial software applications and that software suppliers could not always respond quickly. For a long time, this worked pretty well, because market dynamics played out rather slowly, and competitors typically all faced similar constraints.
21st Century Software
Today it’s different. The industrial sector has entered a period of more rapid change brought on by disruptive new technologies, new customer expectations, and potential new business models. How can modern software models help industrial companies respond?
Modern Platforms
It’s no longer news that software, including industrial software, is moving to the cloud. But what may be 
underappreciated is the fact that the cloud application platform as a service (aPaaS) is the new standard for rapid, efficient, responsive application development and runtime support. These modern platforms support a variety of development languages and can be deployed on different cloud infrastructure platforms such as Amazon AWS, Microsoft Azure, and Google Cloud Platform.
IT Evolution
It’s also important to note that other significant changes are under way. In recent years we have seen the application development process evolve from the Waterfall model, to Agile methodology, and now to the DevOps model, where developers use continuous integration and continuous delivery (CI/CD) services to rapidly build, test, release, and maintain applications.
We have also seen the application architecture itself evolve from monolithic applications on a single server, to n-tier architectures (e.g. Data, Processing, and Visualization Tiers), to Microservices. Deployment moved from physical devices, to virtual machines, and then to containers. And the underlying compute infrastructure moved from the datacenter to a hosted model and then onto the cloud.
Not every company has completely moved its infrastructure to the cloud, deployment to containers, application architecture to microservices, and development process to DevOps. No company is fully there yet. But the trends are clear, and the industry is going to move – probably faster than you expect.
Low-code Application Development
Modern low-code application development platforms provide development teams with tools to create and deploy complex, scalable, maintainable, high-performance industrial applications. They feature capabilities such as model-driven development, microservices, containers, and deployment standardization, and openness and extensibility. They also support cloud-native application development using twelve-factor application principles and DevOps tools for continuous integration and continuous delivery (CI/CD).
IT, OT, and Modern Software Platforms
In some industrial companies, OT systems may be leading the way in moving to the cloud – but this is the exception. In most companies, IT has taken more than a few steps down the path to the cloud. They likely started by experimenting with cloud infrastructure, then tried out PaaS. They probably used these platforms to build some small but helpful apps that run alongside their enterprise applications. Perhaps they even explored the possibility of replacing certain apps with ones they built or commissioned themselves. The key point is, IT has cloud experience, and there is no reason for OT not to benefit from it.
Platform and Services Software Model
Let’s consider the example of MES. What would a 21st century implementation of MES functionality look like? There would be a cloud platform that provides all the core services for connecting to edge devices and other systems. It would have business process modeling (BPM) or workflow services as well as data services. In this environment, a collection of microservice-based apps would work together to provide all required MES functionality.
New Technology, New Requirements, New Possibilities: Time to Re-think MES?
Last century, for efficient plant operations it made sense to utilize a big, expensive, closed, one-size-fits-all, periodically updated production application, as well as a big, expensive, closed, one-size-fits-all, periodically updated maintenance application - and probably several others. Today, with the proliferation of potentially connected devices, machines, and systems and machine learning-driven optimization strategies, it is difficult to see how any large application provider can possibly incorporate all the needed solutions into their monolithic applications, even by extensively interfacing with other applications to handle all interactions.
The functionality gap (discussed earlier in this report) is therefore growing faster than ever and will only get exponentially worse over time. But with a 21st century approach to the problem, there’s a way forward. Instead of conceptualizing the solution as “an MES (or MOM) application and a Maintenance (EAM or CMMS) application,” a better way is to think in terms of needed functionality. We can talk about asset performance management (APM) and operations performance management (OPM) functionalities without having to create bounded APM and OPM applications. APM operates in the operations space related to physical assets and facilities and seeks to improve asset reliability and availability while minimizing risk and cost. Operations performance management operates in the operations space related to plant operations and its interaction with business operations including planning, policymaking, and programs. It seeks to improve responsiveness, throughput, quality, agility, efficiency, and cost effectiveness. APM and OPM are complementary and interdependent.
The fact that APM and OPM represent complementary sets of functionalities doesn’t mean that they don’t share some common elements. If implemented as separate applications, both would need to include (and support) functionality for dashboards, business integration, scheduling, data management, device connectivity, and more. But if APM and OPM functionalities are assembled from small microservice-based apps on a software platform, then some of that functionality likely will serve both purposes. In the 21st century environment, it should be easy enough for a supplier, a third party, or a user to build a compatible set of micro-apps to fill the existing functionality gaps.
Another important benefit of the 21st century platform-and-microservices approach derives from the relative ease in which new functionality – such as Big Data and machine learning capabilities - can be added to the platform and then deployed effectively as needed together with other functional apps. It is quite difficult to get this right in a monolithic app. It’s also especially difficult to support it as needs and expectations for using machine learning rapidly evolve. But with a micro-MES (µMES) solution, it’s relatively quick and easy to add a new microservice, or update or replace existing microservices.
In some cases, MES functionality may have to be executed close to the process – not just because of latency, but for safety and other reasons. A cloud architecture deployed on-premise or a hybrid cloud architecture could address this requirement. Some applications may still require a tightly-integrated, monolithic solution. But, in many cases, a modern architecture will accomplish all that’s needed. As the industry transitions, it is expected that a common approach will be to use a mixed approach – supplementing the monolithic MES with micro-apps, and gradually phasing out the monolithic application.
Containerization
Containers allow software to run reliably when moved between computing environments. Without containers, problems can arise when the underlying environment is not identical. Different software, different network topology, different security policies, or different storage could affect the way a given application performs. A container packages up an entire runtime environment: an application, its dependencies, libraries and other binaries, and any configuration files needed to run it. Container tooling manages these dependencies and differences, making them irrelevant to the developer.
Reasons to Employ a 21st Century Software Approach
Modern software platforms and tools are inherently more flexible and resilient than conventional monolithic n-tier software models developed during the last century. The speed of change in the industrial sector is accelerating, software is becoming a bigger factor in all aspects of industrial life, and - sooner or later - every company will be forced to modernize its systems to compete and survive. Though we have come to see the limitations as normal, legacy software is often quite costly. It can require companies to purchase and support expensive hardware that must be updated every couple of years. While offered as an off-the-shelf, one-size-fits-all solution, in reality, monolithic solutions must often be customized with additional code or workarounds. The cost of this is booked as OpEx, and rarely accounted for in the total lifecycle cost. Initial installation can be quite lengthy and difficult, as can software upgrades when they eventually are available.
21st century software, on the other hand, can be a much better fit for each company’s needs since it enables them to build apps tailored to their needs and rely mostly on standard services. It supports rapid development and deployment, enabling innovation and the ability to adapt quickly when conditions change. Apps can be purchased from one or more suppliers or commissioned from third parties developed in-house.
Recommendations
Though we are all comfortable with the legacy software model, we often don’t consider the significant drawbacks. Change is coming. The new approach to software is already in common use in IT shops and elsewhere. Many users are beginning to comprehend the possibilities and we can also do several important things today to prepare. Users need to think through the new organizational/software support requirements they will need as software models and architectures begin to shift. They should press their current suppliers for roadmap plans to get a better sense of the direction and timing of the change. They should be on the lookout for innovative solutions/suppliers that might be a better fit for their evolving needs than what their current suppliers are planning. And, recognizing that they will be much nimbler and more agile after transition, they should lobby software suppliers to move quickly.
At this point in time, transitioning to a 21st century software model is a real challenge for some suppliers. A few may not yet recognize the need for change – but most do. In any case, the suppliers need to continue to maintain and support their existing customers while they prepare to introduce the changes. The leaders have figured out how to proceed and are working on re-implementing their applications to be modular and microservice-based. But many will be uncomfortable talking about the activity publicly, for fear of freezing sales until the new products are ready. Perhaps the biggest challenge for suppliers is figuring out how to position, price, and market the new software. That’s because consumption and revenue norms of the last century probably won’t apply and users have become more sophisticated and increasingly demand interoperability, configurability, and portability.
An Invitation to Join the Digital Transformation Council
Much of the content in this report was initially developed for presentation to the Digital Transformation Council. Readers who belong to organizations that use software, hardware, or automation systems - such as chemical companies, food & beverage companies, municipalities, utilities, oil and gas companies, automotive companies, mining companies, metals companies, machine builders, and other similar organizations - may wish to join the Digital Transformation Council. The Council, initially created at the request of ARC’s end user clients, is a member-driven community for professionals who want to keep abreast of the many emerging technologies and business trends, learning from others on similar journeys, and leveraging trends and technologies to achieve transformational growth. There is no fee to participate. Join at DigitalTransformationCouncil.com .
Table of Contents
- Executive Overview
- Characteristics of Last-century Software
- 21st Century Software
- Recommendations
If you would like to buy this report or obtain information about how to become a client, please Contact Us