It always amazes me how confusing enterprise IT can get without collaboration. I'm not just talking about the connection of people in social interaction, but about a proper workflow - that co-ordinates activities of different teams and tools. Without co-ordination, nobody is sure of roles and responsibilities, who is doing what -- and when processes are started, it's impossible to track whether they've been completed.
I reflect on these challenges when considering the multiple teams involved in capacity management. There are actually a good number of teams who will carry out some form of capacity management - even if they don't know they're doing it. However, the co-ordination of activity between these IT functional teams is so often neglected. I was sitting through a Trevor Bunker (
@tbunker01) keynote at the CA event in Brussels this week - considering how the DevOps trend is impacting enterprises. Interestingly, the #1 recognised benefit of DevOps is in collaboration.
So, is DevOps successful because it focuses on collaboration, or is collaboration a side-effect of focusing on a workflow between two distinct functional units in IT? And if the latter, what greater benefits could we expect when applying workflow between other distinct teams?
In Capacity Management, there are often 3 operational teams who have responsibility for right-sizing analysis. Firstly, at the application layer - whose responsibility lies in requesting the right amount of IT capacity according to current and projected workloads. This team are well skilled in the arts of demand management and forecasting. The second tier of capacity management happens at the shared-infrastructure level. This team are anticipating demand from a wide number of applications with varying workloads, and ensuring that the infrastructure is right-sized to provide a resilient and cost-effective service. The final tier is at the data-center level, where management of physical, electrical and environmental factors is dependent on the amount of capacity specified or requested from the IT team.
These 3 teams always carry out a level of capacity management. Every time a change request is submitted for more capacity - an element of sizing is done. This inter-dependent structure ultimately provides an indirect connection between the needs of the business and the data-center capacity provided. Ironically, it is the tiered nature of the delivery mechanism that allows for the maximum cost-efficient and resilient operations whilst also being the area of greatest inefficiency.
Are we not missing a trick, by declining to add a workflow to connect these tiers? And what role does service management have to play in facilitating this workflow, beyond the range of managing tickets? What level of automation is desired or accepted, particularly in the realms of elastic compute - can and should this be provisioned automatically when certain triggers are made?
In the greater adoption of capacity management in a tiered delivery model, the answers to these questions can make the difference between successful implementation or not.
I reflect on these challenges when considering the multiple teams involved in capacity management. There are actually a good number of teams who will carry out some form of capacity management - even if they don't know they're doing it. However, the co-ordination of activity between these IT functional teams is so often neglected. I was sitting through a Trevor Bunker (
@tbunker01) keynote at the CA event in Brussels this week - considering how the DevOps trend is impacting enterprises. Interestingly, the #1 recognised benefit of DevOps is in collaboration.
So, is DevOps successful because it focuses on collaboration, or is collaboration a side-effect of focusing on a workflow between two distinct functional units in IT? And if the latter, what greater benefits could we expect when applying workflow between other distinct teams?
In Capacity Management, there are often 3 operational teams who have responsibility for right-sizing analysis. Firstly, at the application layer - whose responsibility lies in requesting the right amount of IT capacity according to current and projected workloads. This team are well skilled in the arts of demand management and forecasting. The second tier of capacity management happens at the shared-infrastructure level. This team are anticipating demand from a wide number of applications with varying workloads, and ensuring that the infrastructure is right-sized to provide a resilient and cost-effective service. The final tier is at the data-center level, where management of physical, electrical and environmental factors is dependent on the amount of capacity specified or requested from the IT team.
These 3 teams always carry out a level of capacity management. Every time a change request is submitted for more capacity - an element of sizing is done. This inter-dependent structure ultimately provides an indirect connection between the needs of the business and the data-center capacity provided. Ironically, it is the tiered nature of the delivery mechanism that allows for the maximum cost-efficient and resilient operations whilst also being the area of greatest inefficiency.
Are we not missing a trick, by declining to add a workflow to connect these tiers? And what role does service management have to play in facilitating this workflow, beyond the range of managing tickets? What level of automation is desired or accepted, particularly in the realms of elastic compute - can and should this be provisioned automatically when certain triggers are made?
In the greater adoption of capacity management in a tiered delivery model, the answers to these questions can make the difference between successful implementation or not.
