Wanted to start a discussion on this to see what others thought and what others are doing in their respective models.  We do not yet have a DCIM (Data Center Infrastructure Management) tool, but are demoing.  Right now we're allocating data center costs to the network, servers, storage, and mainframe objects using square footage times percent of space used to support those towers.  Recently got our hands on a power reading per data center, but that shifts things a lot at the app level.  Been chatting with @Chris Davidson about it and there's two sides that you could view.  One is to weight costs by power, but that pays little regard to the footprint; and the other is to weight costs by footprint (square footage), but that pays little regard to power.  I guess you could multiply the two as well, given our current methodology.  I'm halfway leaning towards sticking w/square footage only due to our unique setup.  We (Services) do not pay for power, but we do pay for expansions; Express pays for power.  So why not stick w/the method that is near and dear to our hearts and bottom line?  But the other argument is using consumption data vs a guesstimate on percent of area supported.  Either way, wanted to put this out here and get your feedback. Thanks much!

A few thoughts.

In an ideal world you would take the cost per sq ft, and the cost per kwh, and then work out some metric of the two when allocating from Data Centers to the infrastructure element. e.g. 0.6 x costs per sq ft + 0.4 x cost per kwh.

However, you are then going down quite a risky strategy as you are then reliant on having power consumption and U count for every bit of infrastructure you are allocating to. I would therefore use the thing that you are sure you are going to have the data for.

In most instances this seems to come back to U count.

That being said an alternative for the perfect data would be to use cpu cores and internal disk size as proxy for power usage and size.

The power consumption and size of the DC is still interesting for allocating from ITRT to the DC, if the specific DC is not in your finance data.

Michael

We have an allocation table sat behind the DC object with a very basic split between Network, Storage and Servers (20%, 30% and 50% respectively). Our allocation out of DC upwards is based on the CPU Cores of the servers - we found that this allowed us to provide a better allocation of the costs to servers - basically the bigger the server the more DC costs it's consuming. Network and Storage ends up going back in to Servers at certain points on the model.

The more complicated part of our DC allocations is done further down the model at Vendor level. We take the monthly bill from our DC vendors and then allocate each line to a tower combination (not all the costs are DC therefore we're allocating some costs direct to Compute-Servers).

As we have 2 DC locations we allocate the location costs directly to the servers within that DC location - helped by the location naming convention set up by our CIMS team. DC Location 1 costs go to the servers with Location 1 in their name, we're found that although we are spreading the costs it's localized and therefore slightly more accurate.

Thank you both very much - very helpful!!!!

We allocate much like @Julie Batty an agreed % split to mainframe, server and storage.  For networks, we allocate direct to this and then into datacentre or end user as a service.

Thank you, Sasha!

We're about to transition our data center metric from cost per sq ft (from a dated and manually gathered 2012 survey) to cost per kwh, so it's been useful to hear how others tackle it.  Thanks!

Sounds like us (same year, too!) - but now they want to use white space instead of power now.  Was told a) IT doesn't pay the bill and b) data centers are always built to run at full capacity and are typically under-utilized.  So we may be keeping the way we did it before, but instead of consulting w/the Facilities team, we'll get with our white space guru to validate that the support percentages per tower that we have are in line with how the white space is used.  Back and forth.  Keeps the gray matter from hardening, tho.. lol.