Division of responsibilities

What you bring

• An on-site MQTT client, correctly configured, publishing every device that reports.
• Data formatted to the data model agreed for that machine type: field mapping, type conversion, mandatory-field population, and validation. Data models covers what each of those demands.
• Outbound internet from the infrastructure the client runs on.
• A collection hub on site. Ignition is the recommended one, reaching floor equipment over OPC UA, Modbus, or BACnet.

A platform decision made without them is a decision made without a schedule. Connecting a site walks the path all four sit on.

What you define

Where the readiness gate finds gaps, implementation runs a data-backbone phase. Part of that phase asks the customer to define, in writing, governance decisions about your operation rather than settings in the platform:

• Your own role definitions.
• Your data retention policy.
• Your purge policy.
• Your escalation workflows.
• Your firewall and VLAN posture.
• Your MQTT topic access rules.

They are the items most often deferred, because none of them is urgent until the day it blocks something. Retention and purge in particular tend to surface late, and they are policy questions that usually need someone outside the project to answer.

Firewall and VLAN posture decides where the MQTT client can run and what it can reach. Topic access rules decide what it is permitted to publish.

The middleware choice

Between a business system such as an ERP and the platform there is usually a bridge to build. You choose who builds it.

Build it yourself. Your team owns the bridge and the knowledge stays in-house, and your team carries the maintenance when the source system changes.

Buy it from mode40. It is available as a custom development service, at additional cost. It is not part of the platform licence, and it is scoped and priced separately.

Make this choice early. It moves both cost and schedule, and it is the most common late surprise in an implementation because it is easy to assume a platform purchase includes it. Integration implementation is where that scoping happens.

What mode40 brings

• The cloud platform itself, running on AWS, multi-tenant, delivered in the browser.
• The licensed modules.
• Configuration and onboarding support.
• Secure hosting and application monitoring.
• Credentials and certificates.
• Standard software updates.

Credentials are issued during onboarding, which means provisioning goes through mode40 rather than through a self-service screen. The agreement commits to standard software updates without attaching a published cadence to them. Security and governance states both, along with what else is undefined today.

Where the gates are

An implementation is a sequence with real go/no-go points in it, and knowing where they fall makes the responsibilities above easier to schedule.

1. Initiation and pre-implementation design.
2. A network and machine connectivity assessment.
3. An AI and data infrastructure readiness gate, which produces a readiness score and a site tier. This is a genuine go/no-go.
4. A data-backbone phase, run only where the readiness gate finds gaps: architecture for the unified namespace, asset modelling, an integration blueprint, and governance.
5. Module implementation and configuration per site, with a hard integration-validation gate.
6. Data validation, pilot, rollout, and sustainability.

Both gates are worth planning around. The readiness gate decides whether a site is ready to start. The integration-validation gate decides whether the data going into a module is good enough to configure on top of.

Connectivity is the longest item

The longest item in an implementation is connectivity, and the work is physical rather than software. This is the part that is consistently underestimated.

• A legacy controller sitting behind NAT, waiting on a firewall change that has its own approval queue.
• A serial-only machine whose protocol has to be reverse-engineered before it can report anything at all.
• An OPC UA server not yet installed on a PLC that could otherwise report today.

None of those is fixed by the platform. Each one needs site time, site access, and frequently a change window on equipment that is running production. A plan that assumes every machine in scope can report on day one is a plan that will move.

Settle this early

The questions below decide fit, and they are cheaper to answer before a signature than in month three.

• Does cloud work for your mandate? There is no on-premise, air-gapped, or customer-controlled-cloud deployment. See Architecture and deployment.
• How do people sign in? Identity runs on mode40’s own provider today rather than federating into your directory. See Security and governance.
• What is the certification status? Stated in full, without hedging, on the same page.
• Who builds the middleware? Build or buy, and buying is priced separately.
• Can every machine in scope actually report today? The connectivity assessment answers this, and the answer usually reshapes the schedule.

Site readiness covers how the readiness gate scores a site.