A Reference Architecture for Manufacturing Intelligence

Manufacturing software tends to grow by accretion: an ERP here, a quality system there, a maintenance app, a few hundred spreadsheets, and recently a dashboard or two. Each made sense when it was bought. Together they make every new question hard to answer.

This article describes the seven-layer reference architecture we use when designing platforms for multi-plant manufacturers, and the reasoning behind each layer.

Layer 1: Edge and OT

PLCs, SCADA systems, sensors, weighbridges and scanners live here. An edge gateway at each plant reads data through industrial protocols, buffers it during outages and forwards it outbound to the cloud. Nothing on the internet initiates a connection into the plant.

Read-only access is the default. Writing back to machines — changing set points, for example — is a separate decision taken signal by signal with plant engineering.

Layer 2: Integration

Connectors to the ERP, statutory portals, identity providers, BI tools and partner systems. Integration uses versioned APIs and events, with queues and retries so a temporary outage does not lose transactions. Each integration has a written contract: which system owns which object, what triggers a sync and how errors are handled.

Layer 3: Data

Transactional data (orders, stock, batches) sits in a relational database. Machine signals go to a time-series store, documents and drawings to object storage, and curated data to an analytics store. Each tenant’s data is isolated, encrypted and backed up.

The data model is where multi-plant and multi-entity requirements are won or lost. Companies, plants, warehouses, currencies and common masters must be designed in from the start.

Layer 4: Domain services

Supply chain, production, quality, maintenance, finance, people and field operations as separate, modular services. Modularity lets customers start with one domain and add others, and lets teams change one area without breaking the rest.

Layer 5: Intelligence

Language models, vision models, forecasting and agents. This layer reads from the data and domain layers through the same permission checks as a human user, produces drafts and predictions, and hands them to people for approval. Every interaction is logged.

Layer 6: Identity and access

Single sign-on with the customer’s identity provider, roles scoped by company, plant, warehouse or territory, maker-checker approvals for sensitive actions, and an API gateway for machine-to-machine access.

Layer 7: Experience

Web applications for offices, tablets for the shop floor, offline-first mobile apps for the field, portals for customers and vendors, and dashboards for leadership. Each is designed for its setting: large touch targets and local language on the floor, offline maps in the field, drill-down for CXOs.

Cross-cutting concerns

How the layers talk to each other

The architecture works because the layers communicate in predictable ways. The edge layer publishes machine readings to the integration layer. The integration layer writes into the data layer and raises events — ‘batch closed’, ‘machine stopped’, ‘stock below minimum’. Domain services react to those events and to user actions, and the intelligence layer reads from both, always through the same permission checks as a person.

This event-driven style matters in manufacturing because many things happen at once and out of order. A dispatch can be recorded before its invoice; a quality result can arrive hours after the batch closed. Designing for events rather than strict sequences keeps the system tolerant of the real world.

Scaling from one plant to twenty

The first plant is always the hardest, because every decision is being made for the first time. The architecture should make the second plant a configuration exercise: new plant record, local warehouses and machines, local approval rules, connection of an edge gateway, and mapping of local item codes to group masters.

Two design choices make or break this. First, plant-specific behaviour must live in configuration, not code. Second, group-level masters (items, customers, vendors) must be governed centrally, with a clear process for plants to request new entries.

Where to compromise, and where not to

Decisions that are expensive to change later

We record each of these as an architecture decision record: context, options, decision and consequences. It makes reviews easier and protects the design when people change.

• How companies, plants and warehouses are modelled.
• Which system owns items, customers, vendors and ledgers.
• How machine data reaches the cloud.
• How permissions are scoped.
• Where AI is allowed to act versus only suggest.