“I wish we could just burn this down and start over.”
― System Architect
“Please don’t touch that.”
― Same Architect
Legacy systems are a symptom of success. You have to last a long time to get saddled with old software. And there’s wisdom in the saying “If it ain’t broke, don’t fix it.”
Yet, legacy systems are also a liability. While technology advances, old systems become increasingly brittle and isolated. As use cases build and limitations reveal themselves, firms often end up cobbling together a Frankenstein architecture, connecting multiple MES, SCADA, and ERP systems upon piles of confusing logic. The result is an application stack with inflexible codebases and network topologies of overwhelming complexity. And the problem only gets worse with time.
Such is the paradox of legacy systems: things that last the longest are usually the best candidates to modernize―and the riskiest components to replace.
So how do you remove legacy systems without starting from scratch or waiting until the hardware fails beyond repair? The answer is through integration and incremental change. This is the approach of the Rhize Manufacturing Data Hub. In small pieces you can decouple communication, coordinate tasks, and integrate information flows into a standard model. But before we discuss how Rhize works as a legacy integrator, let’s quickly go over why rip and replace is a terrible idea.
The False Allure of a Fresh Start
People who work with old systems often dream of starting over. This is a natural thought: creating is generally easier than maintaining, and only hindsight can fully reveal the consequences of bad architectural choices. Even the reason these choices were made becomes lost as people inevitably leave and retire. Back in the year 2000, Joel Spolsky made similar arguments about the appeal of rewriting old software systems in his post Things You Should Never Do. But, as Spolsky writes, this appeal also comes with much risk.
Firms dread the “rip and replace” strategy for a reason: it’s the worst decision in almost all cases. Legacy systems are often of show-stopping importance. Outages stop production. The systems also likely have numerous interfaces built on top of them, which all take time to build and to learn how to use. Communication between legacy systems and other applications is likely tightly coupled, so each replacement must be carefully evaluated for downstream effects on linked systems.
And no one-size-fits-all solution really exists. Even if every part of the stack comes from the same vendor―something that occasionally happens after a vendor offers manufacturers a sweetheart “package deal”―integrators still find places of painful interaction and interoperability. After all, vendors with large product offerings often reach this position through acquisitions and mergers. The complexity and variety of manufacturing means that no one size ever fits all, so firms must either force themselves to fit within the tool’s constraints, or use the tool in conjunction with others, which brings them back to the heterogenous application stack they tried to avoid.
How a manufacturing data hub integrates systems
The architecture of Rhize is fluid and flexible. It takes the shape of whatever manufacturing operation you pour it into. Customers who have many legacy systems use Rhize’s flexibility to integrate their disparate components. And this integration also brings all the normal benefits of a Manufacturing Data Hub, with greater standardization, better performance, and more visibility into the each aspect of the manufacturing process.
Here are the central ways that Rhize makes this legacy integration possible.
Decoupled messaging
The first challenge of integrating two systems is obvious: the two must be able to communicate with each other. You also want to avoid coupling communication directly.
Rhize’s messaging infrastructure supports multiple protocols and is agnostic about where you publish or subscribe to. You can use Rhize as a broker or publish to your own broker. Either way, the effect is that the systems communicate through Rhize, even if they work through different communication devices (for example, MQTT to REST, or OPC UA to NATS).
Process orchestration
To decouple the interaction of two systems, you also must have a way to coordinate their tasks and normalize their data. This is the job of the Rhize BPMN engine, which orchestrates processes between disparate systems. For example, interaction in a legacy system might involve tricky point-to-point communication between an ERP, a scheduling system, a database, and a cloud-based dashboard.
Rhize’s approach removes the need to configure such direct communication. Rather, customers use the graphical editor to write composable workflows that perform all the necessary transformation logic and coordinate communication between services. For the details of how this works, read the Rhize guides.
Standards-enforced database
All the data ingested into the Rhize DB gets normalized into an ISA-95-based schema. This schema creates a common language that makes each event intelligible from different perspectives of the system.
For example, from the perspective of an ERP system, only the high-level details about an order and its execution are relevant. Level-three systems responsible for overseeing the execution of this order require far more granular detail, tracking the specific equipment, personnel, and measurements for material consumed and produced at each stage of production.
When data is exchanged and stored through Rhize, the hub works as a translator for these services. Combined with the precision of the GraphQL API, the model provides exactly the correct granularity of data needed for the job. And if you’re wondering how Rhize’s architecture works so harmoniously with ISA-95, read our blog on reframing perspectives on ISA-95.
Extensible
Rhize’s microservice architecture is also explicitly designed to be able to extend for unique use cases and integrated applications.
For example, some of our customers use a particular messaging protocol that is unique to their internal operation. To accommodate this use case, the customer does not need to build its own messy integration layer, and Rhize does not need to add features to the generally available application that apply to only a highly particular use case. Rather, Rhize uses a microservice to extend Rhize only within this customer’s particular deployment. This modularity means that Rhize can extend to accommodate information flows from legacy systems on an as-needed basis.
A backend for custom MES systems
With its messaging, workflow engine, and ISA-95 database, Rhize also provides the backend to create custom applications. So, rather than ripping out old systems and replacing all interfaces at once, you can gradually introduce more screens over time, thus replacing the old systems in morsels instead of gulps.
You can also keep your old screens and use Rhize to replace the backend. Many manufacturers have screens that are tied to not only the legacy system but also to critical components of business logic. With Rhize’s headless approach, you can move the underlying logic to Rhize’s backend, keeping the screens that already work as the functional interface, or “head.” While end users may not notice the difference, the same logic will now be incorporated into the contextualized, standardized whole, with all the features and performance benefits of a Manufacturing Data Hub.
Coexist then replace
Don’t get us wrong: at some point, legacy systems should be replaced. No large bank would start a new project using COBOL; they only continue to maintain COBOL systems because they are so deeply embedded in their business logic.
But the data-hub approach invites layered replacement and iterative modernization. If you ask us, “To use Rhize, do I need to replace…”―the answer is almost surely no. And why would it be? Violent overhauls of working components are rarely the correct strategic decision.
Instead, Rhize provides an architecture that is built on open standards and designed for data governance, multi-system coordination, and high-performance execution. It serves as a backend to replace old MES functions, and you can replace one screen or one hundred―Rhize fits with what you need. And with each successive use of Rhize to integrate a legacy component, you make that component increasingly less critical. Gradually, it’s not needed at all.