Manufacturing is a domain full of specialized problems, so it naturally follows that the digital landscape of manufacturing is full of specialized software. While novel solutions to hard problems are sure to delight domain experts, solutions architects must view new systems more cautiously.
The architect must judge each new system not only by its specific functionality but also by how well it can be maintained in the firm’s wider digital ecosystem. It is a hard problem. The wrong architectural decision can affect both the present operation and the firm’s future ability to innovate.
There is a way around this tradeoff: the Manufacturing Data Hub. The Manufacturing Data Hub centralizes business logic in a semantic layer, and persists the operational data in a standardized schema. This flexible, well-governed approach provides a way to manage complexity without curbing experimentation and innovation. Some key benefits include:
- Managing integrations becomes simpler, as business logic is centralized in an orchestration hub.
- Applications are built in less time. This is true for both ad-hoc projects and long-term, mission critical functions.
- New applications can be built and old applications can be replaced with less risk.
- As a source of analytics, the database is already highly contextualized and normalized, so you’ll save time and computation for downstream analytics.
Read on to learn how the Manufacturing Data Hub does these things!
What is a Manufacturing Data Hub?
Though we have other blogs and docs describing what a Manufacturing Data Hub is and does, let’s recap the broad features of its design.
A Manufacturing Data Hub is a new approach to integration middleware, one that stores the messages persistently in a harmonized, ACID-compliant graph. The data store has the right level of consistency guarantees to enable new applications to be built directly on the graph. Altogether, this creates a design that centralizes business logic, orchestrates systems communication, decouples communication, and stores operational data that is ready for analytical queries.
The integration problem: why point-to-point doesn’t scale
First, let’s discuss how integration looks without a digital integration hub. For one system to communicate with another, the developers need to manage the integration in a point-to-point manner. Managing an integration requires understanding how one system’s data fits with another. Even ignoring the fact that there’s no persistent store to build applications, this is brittle and expensive to maintain.
What’s more, not having a persistent store majorly limits the value of the application. If middleware is simply a hub-and-spoke pattern of message exchange, developers cannot use it for rapid app development or downstream analytics. This is why the standardized database is the foundational component of the manufacturing data hub.
A hub for business logic and communication
Conversely, the manufacturing data hub moves the business logic to a centralized place. The workflows can optionally persist the integration data into a well-modeled database, making it easy to develop new apps and strategically replace others through the strangler-fig pattern.
This architecture also decouples integration. Now, one specific system, say the ERP, no longer needs to be specifically aware of any systems that it integrates with (such as the LIMS, MES, and WMS). Rather, integrators can use the hub to maintain all integrations in the same place.
High-quality data for downstream analytics
Now let’s turn to the analytical benefits of the manufacturing data hub.
The master data that you model and the events that you ingest get stored in a knowledge graph. This data is highly contextualized, non-redundant, and it contains the models of resources and processes to contextualize all scheduling and execution events (in the terminology of your data engineers, these resources might be called the dimensions and the events make the facts).
Now let’s look at the conventional medallion architecture for ELT in a data lake. In this architecture, raw data is exported to the bronze layer of the data lake, cleaned up and normalized in a silver layer, then finally exported and joined in purpose-built marts in the gold layer.
Without the data hub, each source database needs to be exported to the bronze layer, then cleaned and transformed in the silver layer. Notice how the Manufacturing Data Hub bypasses this initial step: you can export directly to the silver layer. This saves all the cleaning and validation work necessary of your data engineers and data operations.
What’s more, the data exists in the ISA-95 semantics, which is a universal language for manufacturing, whose use can be adopted by the entire organization. Thus, by training your organization in ISA-95, your team can self-service data about material, scheduling, events, and whatever else relates to the operation.
The convergence of operational and analytical data
No one can predict the future, and technological innovation is especially hard to predict. In addition to scalability, maintainability, and efficiency, enterprise architects also need to worry about future proofing. The ideal manufacturing architecture must limit complexity while meeting present and future needs for operations and analytics.
The Manufacturing Data Hub has a unique approach that protects data quality on both sides. By shifting all the translation, semantics, and integration into the hub, your business logic can live in one place. This data is also highly-contextualized, AI-grade data to export for downstream analytics. Good architecture creates a flywheel of innovation. Your analytics teams have high quality data, which uncovers more places to improve operational efficiency.
The Manufacturing Data Hub doesn’t just solve integration problems, it provides an architecture that grows with your firm and adapts to continuous improvement.
ℹ️ The Manufacturing Data Hub is a specific architecture to manufacturing. For a more general purpose example, you’ll find much overlap with the Digital Integration Hub.