Machine monitoring solution architecture governance

Learn about when to centralize your machine monitoring solution and change management best practices.

When to centralize

Use centralized architecture (single app for a Machine Type) when:

• Standardized processes exist across all machines of same type
• Full-time development team manages applications
• Rapid iteration is needed - changes must propagate quickly
• Compliance requirements demand version-controlled, auditable app changes

Example: Pharmaceutical manufacturer with 20 identical tablet presses. FDA requires a validated process. A single app ensures all machines follow an identical, validated procedure.

When to decentralize

Use decentralized architecture (separate apps per machine) when:

• Custom workflows per machine instance
• Citizen developers in different departments own their machines
• Proof-of-concept or pilot projects with unclear requirements
• Low change frequency - apps rarely need updates

Example: Job shop with 5 different CNC mill models. Each has unique tool libraries, part programs, and operator workflows.

Change management best practices

Machine types and triggers are global

• Changes to a machine type immediately affect all machines of that type
• Machine types do not have a versioning system (unlike apps)
• Best practice: Test machine type changes in a development instance first

Version control strategy

1. Dev instance: Test new machine types and triggers
2. Staging instance (if available): Validate with production-like data
3. Production instance: Deploy only after validation
4. Document changes in release notes

Rollback plan

• You cannot roll back machine triggers - you must manually revert them
• As Machine configurations are not versioned, consider creating duplicates (e.g. of Machine Types and Machine Type Triggers) or offline documentation before making high-impact changes.