- 6 minutes to read

What's the difference between BPM and Monitor Views?

Understand when to use Nodinite BPM for business process visibility versus Monitor Views for technical operational monitoring. This page explains:

  • Side-by-side comparison of purpose, audience, and organization
  • Visual architecture showing complementary usage
  • Real-world scenarios demonstrating when to use each
  • Shared capabilities built on the same monitoring foundation
  • Decision guide for choosing the right view

BPM is for business process visibility (organized by workflow, domains, and business steps), while Monitor Views are for technical operational monitoring (organized by technology, application, and system health).

Quick Answer

Use BPM when stakeholders need to track business outcomes (order fulfillment, invoice processing, customer onboarding). Use Monitor Views when IT teams need to monitor technical health (service uptime, API response times, system alerts).

Key Differences

Aspect BPM Monitor Views
Audience Business analysts, process owners, executives IT operations, DevOps, system administrators
Organization Business workflows with domain swimlanes (rows) and process steps (columns) Hierarchical tree of applications, categories, and resources
Focus End-to-end business process flow and milestones Service health, performance metrics, alerts, availability
View Type Horizontal swimlanes showing process steps with milestone-based logging Hierarchical tree structure with resource states
Time Perspective Process execution timeline (start to finish) Current operational state (up/down, healthy/unhealthy)
Data Source Log Events with business correlation Resources with monitoring agent data
Use Case Example "Where is Order 12345 in the fulfillment process?" "Is the Inventory API service healthy?"
Color Coding Automatic from Log Status Codes (green/yellow/red) Manual state configuration (OK/Warning/Error)
License Requirement Requires Nodinite BPM Module license — see BPM Licensing Included in base Nodinite license

Architecture: Complementary Views

graph TB subgraph "Your Systems & Services" Services[fa:fa-gear Services
APIs · Databases · Queues] end subgraph "Nodinite Monitoring Foundation" Resources[fa:fa-server Resources
Health Checks] LogEvents[fa:fa-database Log Events
Business Transactions] end subgraph "View Layer - Different Perspectives" BPM[fa:fa-project-diagram BPM
Business Process View] MonitorView[fa:fa-display Monitor Views
Technical Health View] end Services -->|"Monitoring Agents"| Resources Services -->|"Logging Agents"| LogEvents Resources --> MonitorView Resources --> BPM LogEvents --> BPM style Services fill:#e8f5e9,stroke:#4caf50,stroke-width:2px style Resources fill:#fff3e0,stroke:#ff9800,stroke-width:2px style LogEvents fill:#e3f2fd,stroke:#2196f3,stroke-width:2px style BPM fill:#f3e5f5,stroke:#9c27b0,stroke-width:3px style MonitorView fill:#fce4ec,stroke:#e91e63,stroke-width:3px

BPM and Monitor Views provide complementary perspectives over the same monitoring and logging foundation.

When to Use Each View

Use BPM When You Need To

  • Track end-to-end business processes across multiple systems and departments
  • Find specific transactions using business identifiers (Order ID, Invoice Number)
  • Visualize process timelines from initiation to completion
  • Show process ownership using domain swimlanes (Finance, Logistics, IT)
  • Measure process performance (cycle time, throughput, bottlenecks)
  • Prove compliance with complete audit trails and milestone tracking
  • Present to business stakeholders who don't care about technical details

Example scenario: Executive asks "Why are customer orders taking 3 days to ship?" → BPM shows bottleneck in "Warehouse Picking" step.

Use Monitor Views When You Need To

  • Monitor service health and availability in real-time
  • ⚠️ Respond to technical alerts (service down, high CPU, queue overflow)
  • Organize by technical architecture (applications, infrastructure, middleware)
  • Execute remote actions (restart service, clear queue, run health check)
  • Track SLAs and technical performance metrics
  • Troubleshoot infrastructure issues (network, database, API)
  • Support IT operations teams who manage technical resources

Example scenario: DevOps receives PagerDuty alert "Inventory API Down" → Monitor View shows resource state, last check time, enables remote restart action.

What They Share

Both features provide:

Resource Monitoring

  • Monitor the same Resources for service health
  • Display real-time operational status (OK, Warning, Error)
  • Navigate from view to resource details
  • Access monitoring history and metrics

Remote Actions

  • Execute Remote Actions on monitored resources
  • Restart services, clear queues, run health checks
  • Perform actions directly from the view interface
  • Track action execution history

Alerting Integration

  • Trigger alerts and notifications via Alarm Plugins
  • Email, Slack, PagerDuty, Microsoft Teams integration
  • Customizable alert thresholds and conditions
  • Alert routing based on severity and context

Drill-Down Capabilities

  • Provide drill-down to detailed log data
  • Navigate to related Log Views for transaction details
  • Access full message payloads and context
  • Correlate business and technical events

Real-World Usage Patterns

Pattern 1: Complementary Monitoring

Scenario: E-commerce platform with Order Processing workflow.

  • Monitor Views: IT ops team watches "Order API" resource health 24/7
  • BPM: Business analysts track order fulfillment process from cart to delivery
  • Integration: When API goes down (Monitor View alert), business sees orders stuck in "Payment Processing" step (BPM view)

Value: Technical and business teams have their own perspectives but can correlate issues quickly.

Pattern 2: Escalation Path

Scenario: Payment processing delays.

  1. Executive dashboard (BPM): Shows 200 orders stuck in "Payment Authorization" step
  2. Escalate to IT: Operations team checks Monitor View for "Payment Gateway API" resource
  3. Root cause: Monitor View shows intermittent connectivity (Warning state)
  4. Action: IT executes remote action to restart payment gateway connection pool
  5. Resolution: BPM shows orders progressing through payment step again

Value: Clear handoff between business monitoring and technical troubleshooting.

Pattern 3: Proactive vs Reactive

Scenario: Healthcare HL7 message processing.

  • Monitor Views (Proactive): Alert when "HL7 Listener" resource CPU > 80%
  • BPM (Reactive): Business discovers patient admissions not appearing in EMR system
  • Investigation: Monitor View shows listener healthy but "Database Writer" resource in error state
  • Resolution: Database connection pool exhausted; increase pool size; BPM shows messages processing again

Value: Technical monitoring prevents issues before business impact; BPM validates resolution from business perspective.

Decision Guide: Which View Should I Use?

Ask yourself these questions:

Question BPM or Monitor Views?
Who is the audience? Business stakeholders → BPM • IT operations → Monitor Views
What are they tracking? Business outcomes → BPM • Technical health → Monitor Views
What's the question? "Where's my order?" → BPM • "Is the API up?" → Monitor Views
What's the time perspective? Process lifecycle → BPM • Current state → Monitor Views
What's the organization? By business domain → BPM • By technical architecture → Monitor Views
What's the action? Analyze process flow → BPM • Restart service → Monitor Views

Pro tip: Use both together. BPM for business visibility, Monitor Views for technical operations. They complement each other perfectly.

Common Misconceptions

Misconception: "BPM replaces Monitor Views"

Reality: BPM and Monitor Views serve different audiences and purposes. BPM focuses on business process visibility; Monitor Views focus on technical operational monitoring. Most organizations need both.

Misconception: "Monitor Views can't track business processes"

Reality: Monitor Views excel at technical monitoring but don't provide business process context, milestone tracking, or domain-based organization that BPM offers.

Misconception: "I need to choose one or the other"

Reality: BPM and Monitor Views complement each other. They can reference the same resources and services, providing different perspectives for different stakeholders.

Next Step

Explore Business Process Model (BPM) for process-centric views or Monitor Views for technical monitoring. Check the Troubleshooting Overview for more FAQs.