Describe the workload in separate dimensions
Collect concurrent sessions, login bursts, active instruments, quote activity, integration requests, reporting jobs and retained data. For an existing environment, use observed peak windows and incident records. For a new deployment, document assumptions and how they will be validated.
Separate application roles and scheduled work. A platform service, an export task and a connectivity adapter can place different demands on CPU, storage and network resources even when they share the same host.
Turn the profile into a testable specification
| Dimension | Record | Validation approach |
|---|---|---|
| Compute | Busy processes, concurrency and overlapping jobs | Observe the representative workload rather than idle utilisation |
| Storage | Growth, latency-sensitive operations and backup activity | Check response during routine and maintenance work |
| Network | Client regions and critical service endpoints | Measure paths to dependencies as well as bandwidth |
| Continuity | Maintenance, component loss and recovery requirements | Review whether the remaining capacity supports the agreed workflow |
Hardware sizing follows the reviewed platform version and workload. Avoid translating a single account-count figure into a guaranteed CPU or memory specification.
Prepare the handover measurements
Illustrative workload: a broker has moderate daytime activity but a concentrated login burst after a maintenance window. The design review includes that burst, the resulting connection pattern and any overlapping startup jobs instead of sizing only from a daily average.
Agree the baseline metrics and the triggers for a new capacity review before accepting the environment. Keep the initial assumptions beside the measured results. The capacity planning tool can structure the discussion, while the final specification requires a project-specific review and validation.