Skip to content

IIMS – Core Domain Model

Purpose

This document describes the core business concepts of IIMS as implemented in Current.

It explains how infrastructure, monitoring configuration, alerts, incidents, tickets, maintenance, and activity are modeled inside the current platform, and clearly distinguishes between:

  • What is implemented in Current
  • What is planned for Planned and beyond

The goal is to provide a shared and accurate understanding for product owners, architects, and engineers before looking at technical implementation.

Overview of the Domain Model

At a high level, Current IIMS models five major areas:

  • Infrastructure structure (Sites, Assets, Topology Links)
  • Monitoring configuration (Targets, Collectors, Packs, Profiles)
  • Operational signals (Alerts)
  • Human workflows (Incidents, Tickets, Activity)
  • Operational control (Maintenance windows)

These concepts form the foundation of all Current features and user workflows.

End-to-End Monitoring Flow (Conceptual Model)

Site
  └── Asset
        └── monitored by → Monitoring Profile
                 └── built from → Monitoring Pack
                 └── using → Monitoring Target
                          └── via → Collector
                                   ↓
                          Monitoring Backend
                       (Zabbix / Prometheus / …)
                                   ↓
                                Alerts
                                   ↓
                               Incidents
                                   ↓
                                Tickets

1. Site and Asset Hierarchy

1.1 Site

A Site represents a physical or logical location where infrastructure exists.

Examples:

  • Data center
  • Branch office
  • Cloud region

Role in Current:

  • Groups assets by location
  • Defines hierarchy between locations
  • Provides default monitoring routing and policy context

Important characteristics:

  • Sites are hierarchical (region → country → city → building)
  • Sites may define default monitoring targets and collectors
  • Sites may define default maintenance and routing behavior
  • Site answers the question: Where is the infrastructure?

Notes (Current scope):

  • Sites provide geo‑location mainly for asset inheritance and map rendering
  • Sites are not primary monitoring objects; assets are the primary monitored entities

Planned Planned:

  • Site‑level health scoring and direct site markers on GeoMap
  • Service / business grouping at site level

1.2 Asset

An Asset is a real object being monitored.

Examples:

  • Router, switch, firewall
  • Server or virtual machine
  • Application or service

Role in Current:

  • Main monitored entity in the system
  • Always belongs to exactly one site
  • Primary unit for alerts, incidents, telemetry, and topology

Important characteristics:

  • Each asset has a type (network device, server, service, etc.)
  • Each asset may have one or more monitoring profiles
  • Assets inherit geo‑location and defaults from their site if not explicitly set
  • Assets participate in topology links and geo‑visualization

Asset answers the question: What are we monitoring?

Planned Planned:

  • Interface‑level inventory as first‑class objects
  • Asset lifecycle states (planned, active, retired)
  • CMDB synchronization and asset templates

1.3 Site–Asset Hierarchy

The hierarchy model provides in Current:

  • Location‑based navigation (tree view)
  • Roll‑up alert and severity summaries
  • Policy inheritance (monitoring routing, maintenance defaults)

Typical structure: 

Region
└── Data Center
    └── Zone
        └── Assets
This hierarchy allows operators to:

  • Navigate infrastructure by location
  • See aggregated alert counts by site
  • Drill down from site → asset → alerts / incidents

Notes:

  • Current roll‑ups focus on alert counts and worst severity
  • Full health scoring and SLA roll‑ups are planned for Planned

2. Topology Model

A Link represents a physical or logical connection between two endpoints.

Endpoints supported in Current:

  • Asset ↔ Asset
  • Site ↔ Site
  • Asset ↔ Site

Examples:

  • Fiber connection between routers
  • Logical tunnel between services

Role in Current:

  • Models connectivity for visualization
  • Provides manual status binding and policy‑based link status
  • Enables GeoMap and topology views

Link answers the question: How are assets connected?

2.2 Topology Impact Model

Current behavior:

  • Links and assets expose individual status and severity
  • Operators visually inspect topology and maps
  • Impact analysis is primarily manual and operator‑driven

Implemented in Current:

  • Manual status binding (alerts / availability / interface status)
  • Policy‑based link status evaluation (worst‑of rules)
  • Geo visualization of links and affected assets

Not yet implemented (Planned backlog):

  • Automatic impact propagation through topology graphs
  • Root cause inference from dependency chains
  • Service‑level impact modeling

3. Alert Lifecycle

3.1 Alert Definition

An Alert is a raw technical signal produced by a monitoring system.

Produced in Current by:

  • Zabbix (primary provider)

Role:

  • Machine‑level event
  • Frequent and noisy
  • Not directly a human workflow object

Alert represents a technical symptom, not a problem.

3.2 Alert States (Current)

Supported states:

  • Open / Active
  • Acknowledged
  • Resolved / Closed

Additional attributes:

  • Suppressed by maintenance
  • Linked to at most one active incident

Notes:

  • Advanced deduplication and automatic grouping are limited in Current

Planned Planned:

  • Advanced correlation rules
  • Automatic deduplication and merging
  • Alert classification and noise scoring

3.3 Alert Processing Flow (Current)

  • Monitoring provider generates an alert
  • Alert is ingested and normalized into IIMS
  • Maintenance suppression rules are applied
  • Operator or simple rules attach alert to an incident

Notes:

  • Correlation is mostly manual or rule‑light in Current
  • Full correlation engine is planned for Planned

4. Incident State Machine

4.1 Incident Definition

An Incident represents a real operational problem handled by humans.

Created from:

  • One or more related alerts

Role in Current:

  • Central operational object
  • Tracks lifecycle, ownership, alerts, and tickets

Incident represents the human workflow for handling a problem.

4.2 Incident States (Current)

Implemented states:

  • New
  • Investigating / Open
  • Resolved
  • Closed

Optional / limited:

  • Suppressed (maintenance)

Planned Planned:

  • Assigned / In Progress states
  • Incident merging and duplication handling
  • SLA‑driven state transitions

4.3 Incident Transitions

Supported transitions in Current:

  • New → Investigating
  • Investigating → Resolved
  • Resolved → Closed

During the lifecycle:

  • Alerts may be added or removed
  • Tickets may be created or linked
  • Comments and actions are recorded as activity events

4.4 Incident Ownership and Responsibility

Current tracks:

  • Current status
  • Related alerts
  • Linked ticket (optional)

Limited in Current:

  • Ownership and team assignment are basic
  • SLA timers are not enforced automatically

Planned Planned:

  • Full ownership and assignment model
  • SLA timers and breach detection
  • Escalation policies

5. Relationship Between Alerts and Incidents

Key rules in Current:

  • Many alerts can belong to one incident
  • One alert belongs to at most one active incident
  • Incidents represent aggregated human problems
  • Alerts remain raw technical symptoms

This separation enables:

  • Noise reduction
  • Clear human workflows
  • Ticket integration

Planned Planned:

  • Automatic incident creation and merging
  • Root cause candidate selection

6. Tickets, Maintenance, and Activity

Tickets

Current behavior:

  • Incidents may create tickets in Zammad
  • Ticket references are stored in incidents
  • Ticket status can be synchronized manually or periodically

Planned Planned:

  • Bi‑directional real‑time sync
  • Multi‑ticket per incident
  • Multi‑provider ticketing

Maintenance

Current behavior:

  • Maintenance windows suppress alerts and incidents
  • Suppression is matched by site, asset, or tags
  • Tickets may be blocked during maintenance

Planned Planned:

  • Provider‑side maintenance automation
  • Impact simulation during maintenance

Activity

Current behavior:

  • All important actions generate activity events
  • Activity provides audit trail and operational timeline

Planned Planned:

  • Cross‑object timelines
  • Post‑mortem and reporting tools

7. Summary

In Current, the core domain model of IIMS is built around:

  • Sites and Assets for infrastructure structure
  • Links for connectivity visualization and manual policy
  • Alerts for technical signals
  • Incidents for human workflows
  • Tickets, Maintenance, and Activity for operational control

This model provides a stable foundation for unified operations.

Future phases will add:

  • Automated correlation and RCA
  • Topology‑driven impact propagation
  • SLA and escalation engines
  • Service and business modeling

These extensions build on the Current foundation without breaking existing workflows.