Let me provide the complete implementation details addressing all three critical integration aspects.
Event Forwarding Setup and Architecture:
Our integration runs as a microservice deployed on IBM Cloud Functions (serverless) to minimize operational overhead. The service subscribes to Watson IoT alert events using MQTT and processes them in real-time. Here’s the complete flow:
- Watson IoT generates alert → Published to MQTT topic /iot/alerts/{deviceType}
- Integration service receives alert event via MQTT subscription
- Service enriches alert with device metadata from Watson IoT Device Management API
- Service queries mapping database to resolve device → asset relationship
- Service transforms alert to Maximo work order format
- Service posts to Maximo REST API endpoint /maximo/oslc/os/mxwo
For the deduplication concern jen raised, we implemented a 15-minute correlation window. The integration service maintains a cache of recent alerts per asset. When a new alert arrives, it checks if there’s an open work order for that asset created within the last 15 minutes. If yes, it adds the alert details as a note to the existing work order rather than creating a duplicate. This logic is in our correlation engine:
if (recentWorkOrders[assetNum] &&
(now - recentWorkOrders[assetNum].created) < 900000) {
maximoAPI.addNote(recentWorkOrders[assetNum].wonum,
alertDetails);
} else {
createNewWorkOrder(alertDetails);
}
Alert Mapping and Severity Translation:
This was one of the more complex aspects. Watson IoT uses severity levels 1-5 (1=critical, 5=informational), while Maximo uses priority codes (A=critical, B=high, C=medium, D=low). We created a comprehensive mapping framework:
Watson IoT Severity 1 → Maximo Priority A + Immediate response required
Watson IoT Severity 2 → Maximo Priority B + 4-hour response SLA
Watson IoT Severity 3 → Maximo Priority C + 24-hour response SLA
Watson IoT Severity 4-5 → Maximo Priority D + Scheduled maintenance
Beyond simple severity mapping, we implemented context-aware priority escalation. Certain device types or asset classes automatically escalate priority regardless of alert severity. For example, alerts from critical infrastructure assets (power systems, safety equipment) always map to Priority A even if Watson IoT severity is 2 or 3.
We also map Watson IoT alert types to Maximo work order types and failure classes. This ensures the right maintenance procedures and checklists are automatically associated with each work order:
Temperature alerts → Work Type: INSPECTION, Failure Class: THERMAL
Vibration alerts → Work Type: PREVENTIVE, Failure Class: MECHANICAL
Connectivity alerts → Work Type: CORRECTIVE, Failure Class: COMMUNICATION
The mapping configuration is externalized in a JSON configuration file that operations can modify without code changes:
{
"alertType": "TEMP_HIGH",
"maximoWorkType": "INSPECTION",
"failureClass": "THERMAL",
"priorityOverride": "B",
"autoAssign": true,
"assignmentGroup": "FACILITIES"
}
Automatic Incident Creation and Bidirectional Sync:
Addressing sarah’s question about bidirectional flow - yes, we implemented full lifecycle synchronization. When a work order status changes in Maximo, we update the corresponding alert status in Watson IoT. This provides complete visibility in both systems.
The Maximo-to-Watson direction uses Maximo’s Object Structure webhooks. We configured Maximo to call our integration service whenever work order status changes:
Maximo Work Order Status: INPROG → Watson IoT Alert Status: ACKNOWLEDGED
Maximo Work Order Status: COMP → Watson IoT Alert Status: RESOLVED
Maximo Work Order Status: CLOSE → Watson IoT Alert Status: CLOSED
We also sync work order notes back to Watson IoT as alert comments, so device history in Watson IoT shows the complete maintenance story:
maximoWebhook.on('workorder.update', (wo) => {
if (wo.statusChange) {
watsonIoT.updateAlertStatus(wo.relatedAlert,
mapStatus(wo.status));
}
if (wo.newNote) {
watsonIoT.addAlertComment(wo.relatedAlert, wo.newNote);
}
});
For the device-to-asset mapping complexity carlos mentioned, we built a mapping management UI that allows operations staff to maintain relationships without IT involvement. The UI shows unmapped devices and suggests asset matches based on naming conventions, location data, and device type. Administrators can approve suggestions or manually specify mappings. This solved the scaling problem - we now have 2,400+ devices mapped to 650 assets with minimal ongoing maintenance.
Implementation Results and Recommendations:
The 35% MTTR improvement came from several factors: eliminated context switching between systems (technicians work entirely in Maximo), automatic work order creation means no alerts are missed, and enriched work orders include device telemetry trends that help diagnose issues faster.
Key recommendations for anyone implementing similar integration:
- Start with read-only integration (Watson IoT → Maximo only) to validate mapping and workflows before adding bidirectional sync
- Implement comprehensive logging and monitoring - our integration service logs every alert processed, every API call, and every mapping decision for troubleshooting
- Build admin tools for mapping management - don’t hardcode mappings or require code changes for configuration updates
- Plan for error handling - network issues, API timeouts, and invalid data will happen; our service includes retry logic, dead letter queues, and alerting for integration failures
- Test thoroughly with production-like alert volumes - we discovered performance bottlenecks only after deploying to production with full alert load
The integration has been running for 8 months now, processing an average of 1,200 alerts per day with 99.7% success rate. We’re now expanding it to include predictive maintenance alerts from Maximo Monitor’s AI models flowing back to Watson IoT for device-level insights.