ITIL Capacity Management encourages us to carry out capacity management at three levels, business, service and component. This is sound advice and I've carried it out regularly and found that the amount of effort required to model and capacity plan a service can be defined by the number of individual entities in each of these ‘layers’ of capacity management.
The purpose behind this layering is that capacity management should be done across the enterprise; from the business (who represent the user community and drive changes) to the technical staff who ensure that there is sufficient hardware in place. It is a sign of process maturity to be able to discuss capacity management in business terms (to include users) but also necessary to do so in technical terms (because it is necessary to have the right amount of hardware).
So what about the service layer? If there is a direct relationship between business volumes and component consumption then considering the service layer just becomes an overhead. If there is no such relationship then considering the service layer may provide the appropriate workload characterisation in order to model effectively. When this is true then I have found that the terminology in the service layer is typically understood by the business and therefore there is no need to consider the business layer.
If a direct relationship exists between the business layer and the component layer then use it. If there is a direct relationship between the service layer and the component layer that is also understood by the business then use that. It can reduce the workload by a considerable amount.
About the author
Team Capacitas
FinOps and AI: Building the Financial Discipline for the Next Wave of Enterprise Intelligence
AI FinOps represents an evolution rather than a replacement of traditional FinOps. It extends the model into a domain where financial, technical, and product decisions are tightly interconnected.
Confidence Under Load: How We Verified AKS Readiness for Peak
How Capacitas verified AKS readiness for peak demand by validating workload performance, autoscaling, cluster capacity, monitoring, and incident response.
Building Cloud Resilience: Lessons from the AWS Outage
Learning from the Latest Outage. Events like this week’s AWS disruption highlight one clear truth: resilience must be designed, not assumed.
Bringing Order to Chaos: A Practical Guide to Chaos Testing in the Cloud
In today’s cloud-native environments, resilience is not optional—it’s critical. Chaos testing has emerged as a key practice for validating system behaviour under failure conditions.