Strategies for Transforming Production Operations With 21st Century Software

By Greg Gorbach

ARC Report Abstract

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 replaced 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 inter-changeably in this report, readers familiar with the ANSI/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 wish list 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 Last Century, There Was a Mismatch Between Packaged Software Functionality and Needed Functionality in production operations GGMES1.PNGinstructions.  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 soft-ware 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 soft-ware 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 micro-service-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 up-dated 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, policy making, 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 plat-form 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 ma-chine 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 ad-dress 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. 


Table of Contents

  • Executive Overview
  • Characteristics of Last-century Software
  • 21st Century Software
  • Recommendations

ARC Advisory Group clients can view the complete report at ARC Client Portal 

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


Engage with ARC Advisory Group