We have some line items that come through that are tagged as 'public cloud' based on the vendor name and if there's a Project ID associated, we route it to the Project object; if there's not a Project ID, but there's an App ID via tagging, it goes via the tower objects to the applications (bypasses the Project object). 

By doing that, though, we're not seeing a lot of the cost that should hit an app.  People expect it to due to the app tagging, but since there's a Project ID, it sees that first, and routes accordingly.

Therein lies the rub: folks want to see it both ways.  They want to see the expense hitting the apps based on tagging, but then again, we have folks budgeting/forecasting against certain projects, and they want to see that, too.  And we don't want to over-allocate or double-count in these situations, either. 

How do you handle your cloud expenses?  Inquiring minds want to know...  Dating myself a bit lol...

(Not in the context of Cloud costs for our model but I'm sure the same idea can apply here)

We have all project costs going from Towers to Projects and if it also has an App ID it will then go from Projects to Apps. 

Jenny,

We aren't allocating AWS to projects just yet, but our AWS has one column used for tagging that could either be an application or a project and sometimes the tagging isn't clean, there could be a typo or something. I am having to set up a mapping table of these different taggings to the right applications as new tags get setup. I guess you could build a mapping table of tags to both applications and projects and create 2 allocations lines based on that data. One to applications and one to projects. 

Follow up question. Could you allocate to projects first, then from projects to Applications? I have allocations from projects to the application tower then to applications.

That's one of our issues.  All tagged apps may not be associated with the project, but they still want to see total project cost and total app cost for AWS.  Not sure how to swing that without double-counting.  May just have to maintain a separate mapping file and associate those tagged apps with the effort.  ¯\_(ツ)_/¯

I don't know if it is possible to route through projects and have a project called "non-project apps" or something like that, then route to apps. Or maybe you can change the tagging rules to help distinguish between project apps and non-project apps. Just grasping at straws here.

Very interesting!  May give that a whirl - thank you, @Jason Tucker!!

I route through projects first and then to applications. I do that with any spend that hits a project. Cost>Projects>Apps. My next iteration, I need to add 2 more hops: Cost>Projects>Neighborhoods>Towns>Applications.

We only use the ITRT for "peanut butter" costs though. So a difference there. The Towers/Sub-towers view doesn't add a lot of value for us. It makes things more confusing because our CIO-1s are referred to as "towers". So any costs that can be aligned by an identifiable direct relationship are aligned and anything that requires an equitable and defensible allocation strategy goes through the ITRT object.

The strategy means to correct bad behavior type items. I.e. if you had tags, or the correct fields in the source, the costs wouldn't be "peanut butter". Also, it provides people a way to see which costs are directly related compared to what's simply being absorbed to achieve a full absorption costing.

I love strategies that help correct bad behavior!  Going to look into this as well!  Thank you, @Stephanie Geltrude!

Our model first looks for an application tag in the workload though our coverage isn't very thorough yet.  To bolster that, we recently forced people to assign a default application at the account level.  Untagged workloads are assigned to that default application.  It's not perfect, but it at least puts it in the right pocket rather than having a big pool of unallocated spend that winds up getting spread less scientifically.   We hope that those default app owners will protest and push the other app owners that share the same cloud account to tag their workloads appropriately.  

This sounds like a great idea, @George McElfresh - thank you! 

That would take care of a lot of the overhead that's falling out right now, too.

@Jenny Franklin   As a bonus AWS worked with us to create an api that lets us pull this information straight from them allowing us to avoid worrying about maintaining/loading the table outside of that environment.  

@George McElfresh, Nice!!

Yes, @George McElfresh and @Jenny Franklin, we're waiting for tagging to become usable. For now we also have a default allocation at the Cloud tenant level. Works for now. Trying to put together some notes on our method, but awfully busy these days... writing tagging coverage reports :O