Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 2 of 5

Monitoring design: from business services to signals

9 min

Listen to this lesson

0:00 / 7:40

A monitoring design that starts from tools ends with thousands of metrics nobody reads. A design that starts from the business ends with a few signals that matter. Work outside-in: which business services must work, which process steps carry them, which technical components support those steps, and which signal would show first that something is wrong.

  1. Business serviceOrder to cash for sales area 1710 / 10 / 00
  2. Critical stepsEDI order in, order created, delivery, goods issue, billing, EDI invoice out
  3. ComponentsCMP, Integration Suite, output management, nightly billing job
  4. SignalsIDoc errors, job status and runtime, open orders without delivery, app response time
  5. Use casesIntegration and exception, job and automation, business process, real user monitoring
Designing from the business outward. Each signal earns its place by protecting a step.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-401

The SAP Cloud ALM use cases

Use caseWhat it watchesGood for
Health MonitoringMetrics of cloud services and technical systems, with an overall health score and historyTechnical health that SAP ECS does not report to Contoso directly; trends
Integration and Exception MonitoringMessages correlated into end-to-end flows, integration exceptions, search by business attributesIDocs, web service messages and Cloud Integration flows; ABAP exceptions
Job and Automation MonitoringExecution status, application status, start delay and run time of jobsNightly billing, MRP and payment runs
Business Process MonitoringProcess health and key figures across the landscapeBacklogs such as orders without delivery
Real User MonitoringPerformance as users experience it, linking client and server dataSlow apps after a release
Synthetic User MonitoringScripted user scenarios run at regular intervalsAvailability of critical web front ends around the clock
Configuration and Security AnalysisConfiguration changes over time; compliance checks against SAP security recommendationsDrift detection; SAP's deck notes the area is still evolving

SAP Cloud ALM for operations use cases, as described on SAP's support portal.

Thresholds from evidence

Thresholds decide whether monitoring helps or annoys. Set them from measured behavior, not from defaults. Contoso's nightly billing job ran between 38 and 52 minutes in mock conversions and the first weeks of production, so its runtime threshold sits at 75 minutes and its start-delay threshold at 15 minutes. Job and Automation Monitoring evaluates job data every five minutes and, by default, notifies when the rating turns yellow or red. SAP's expert portal also describes a newer 'notify on anomaly' option for favorite job lists that detects runtime deterioration and rising failure rates without manual thresholds; check what your tenant offers before designing around it.

Thresholds from evidence: the billing job's measured runtimes sit well inside the 75-minute threshold, and a start more than 15 minutes late is its own signal.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-401
Watch in dashboardsLow impact, rarely fails: trend review only
Alert to the ownerHigh impact, rarely fails: alert with a clear runbook, for example the payment run
Fix the causeLow impact, fails often: noise; fix the job or interface instead of alerting
Alert and automateHigh impact, fails often: alert, automate diagnostics, and fund a permanent fix
Which signals deserve alerts. Not every metric needs one.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-401

Group technical services into business services with SAP Cloud ALM's Business Service Management. It shows SAP cloud service events from SAP for Me (disruptions, degradations, maintenance) and, for private cloud systems, planned downtime and non-service hours mapped to each business service. It can measure availability against a service level objective per month, quarter or year. Customer-defined events, such as planned maintenance of an on-premise system, can be added. And it forwards upcoming and ongoing events to the monitoring apps, which suppress alerts and actions during maintenance and disruptions.

Business Service Management knows about planned downtime and SAP events, and tells the monitoring apps to stay quiet while they last.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-401

What would you do?

The integration specialist proposes enabling every available metric and alert for CMP and Integration Suite 'so nothing is missed'. Two weeks later, the team receives 400 alerts a day. What should Sam do?

Key points
  • Design outside-in: business service, critical steps, components, signals, use cases.
  • Use the Cloud ALM use cases for what they do best: health, integration and exception, jobs, process, real and synthetic users.
  • Set thresholds from measured behavior; alert only where business impact justifies it.
  • Business Service Management groups components, measures availability and suppresses alerts during maintenance.

Check your understanding · not graded

Lesson check

  1. 1. How often does Job and Automation Monitoring evaluate job data, per SAP's expert portal?

  2. 2. Which use case runs scripted user scenarios at regular intervals?

  3. 3. What does Business Service Management do with upcoming and ongoing maintenance events?

  4. 4. A low-impact interface fails several times a day. What does the impact-likelihood matrix suggest?