Thank you megan.

Agree!  always something new to learn!

Somewhat unexpected answer, which I did not see coming :-)

Ditto - love these - always learning something new! 

Drum roll, please ..................................................................................
@Steven Young and @Suresh Sawlani are going strong with all 3 pursuit pieces so far!  Awesome job, guys!

Ohh Reveal, reveal :-)

We have 2 people with all 3 game pieces so far!  Should I reveal their identities or keep the suspense? 

Nice twist. I love these challenges as I learn a lot and it provides opportunity for us to discuss different strategies.

I'm not a fan of #9 since 100% of Network Devices (eg firewalls, routers, switches, etc) are allocated directly to Applications rather than the infrastructure they likely or directly support. If a small amount of allocation were driven to Applications, I could warm up to #9 (given other allocation outputs took routes similar to #8).

Megan Beasley Do we have anyone with 3 game pieces?

Whoa @Chris Davidson coming out of left field with that one! Way to go, everyone!   You all have now been awarded the third Community Pursuit game piece.  Thanks for playing! 

Wow who knew the third question in the game would bring such drama and a sweeping win to everyone who responded! Congrats to all of you. It's going to take Megan Beasley a minute to get this many game pieces and pointe awarded but we'll make sure you're recognized by end of the week :-) 

Congratulations to myself for stumping all 22 responders:
Andrés Santín
Amy Liu
Axel Burkert
Banish Gupta
Catarina Caldeira
François Cellerier
Gordana Moore
Jaitabh Sharma
Jenny Franklin
Julie Batty
Juliet Orgain
Kalyanikumari Patra
Matt Temple
Meera Jose
Michelle McGuire
Mohit Soni
Oliver Smith
Phaneendra Sristi
Raymond Walls
Steven Young
Suresh Sawlani
Usha Shrestha
...with what turned out to be a trick question, so all 22 will receive award points and the pie piece.

Everyone selected a specific option (#8 and #9 were especially popular), but none of the nine options (based solely on their object and allocation configurations) is objectively better than the others.

Recall why we build cost models in the first place.

If we truly had all the data we wanted, then we'd somehow be able to calculate each data center's exact cost contribution to every individual category. No model needed. We could just use a spreadsheet. If we build a model anyway, it might look like this:

Notice the allocation percentages sum to 180%, not 100%.
This is fine. Cost overlaps because each application is just a conceptual entity combining one or more other cost categories, each of which receives cost from the Data Centers object. No need to draw an allocation line from Network Devices to Applications, for example. This model assumes we've somehow already figured out how much network-specific data center cost should be allocated to each application.

How would we actually obtain such perfect data, though?

For example, could we measure the heat output of each physical server, storage device, network device, and mainframe to determine its eventual effect on the building's HVAC system and how much extra cooling cost each one required? Yes. But unless your data center manager wants to go to such extremes, we could instead just assume each piece of equipment more or less generates the same heat and is equally responsible for the month's cooling bill (and other data center costs, such as lease, security, and rack space equipment). In this case, we might decide to unevenly weight data center cost across the component categories (server, storage, etc.) based on occupied rack units (RU) or just a device count.

Do you think Option #1 (100% Data Center cost allocated to Physical Servers) is a poor choice because it assumes storage devices get a free ride in the data center, incurring no cost? Actually, Option #1 seems fairly common.

Why is it acceptable to omit storage like this? Because usually we're more interested in estimating fully burdened Application cost than in fully burdened Storage cost. It therefore doesn't matter if we skip storage, mainframes, network devices--or even servers--as long as the full data center cost eventually makes its way to Applications object.

The choice of how to route cost between Data Centers object and Applications object is determined by:
1. What data we have available.
2. Which categories (apps, servers, etc.) we're trying to burden with which cost contributors.

If we're in charge of all storage in the data center, then we want a cost model which allocates a carefully selected proportion of Data Center cost directly to Storage Devices. We'd probably also like an estimate of how much network device cost contributed to our overall storage cost, so we'd add two allocation lines: from Data Center to Network Devices, and from Network Devices to Storage Devices (see Option #6). The more cost categories we can add (cables, cooling, rack equipment), the more fully burdened our storage cost estimates will grow, inching us closer to total cost of ownership (TCO) reports. But it's unlikely we're going to construct a cost model which provides 100% TCO at all object levels. Instead, we most often prioritize Application TCO over, say, Storage TCO or Server TCO or Mainframe TCO.

Why do we sometimes route Storage cost to Servers (or Physical Servers) instead of directly to Applications object? Often we know which server a particular storage volume is logically related to--but we may not know which application the storage supports--so we make do with the next best option: Allocate storage cost to its matching server. This produces more defensible per-application cost estimates than if we just spread the entire storage cost across all known applications. Again though, our decision of which model objects to include and how to connect them is driven by what data we have available.

If we have all the data we could possibly want, then all nine options above will produce identical results at the Applications object, because the allocations between all model objects will be exchanging perfect data (which includes how much cost should eventually go to each application). The nine options will produce different results at each of the intermediate objects, so we'll need to consider which categories we want to include other categories. For example: If we route storage cost into servers, we'll want to notify anyone viewing the server reports that the cost estimates include related storage.

Realistically though, perfect data will probably elude us. That's okay. This post discusses the importance of quantitatively estimating impact of model allocation decisions to help us decide whether our current cost model will suffice for our purposes.