Scope of discussions here

[Eric Hilman]

It might be helpful for the community organizers to let us know what kinds of discussions are "in scope" and what we should kind of avoid. Maybe set a structure of sub discussions? Some things I would like to see discussed include:

• "in depth" understanding of the data.  What exactly is being presented and how do we interpret it? What are the "footnotes".  For example, when looking at cost\savings reports, there are data blocks labeled " EC2 Savings" and "EC2 Savings from SPs". And there is "RDS Savings"  One of these is really usage that is covered by SP/RI, at list price (on-demand).   The other is difference between list and net.  I guess the question is how does it work in the classic view?  In the NX? I think I have figured it out.  It would be nice to have clear documentation in place - I worry that there might be edge cases that I have not encountered and if we do, I will have to spend a lot of time to figure it out. Document the as-is
• Requests for changes, in this case to simply change the labeling to reflect a concept of list price and net price.  I don't know if Focus labels concepts like this more clearly than what we have in place today. Presumably any labeling change should be consistent with Focus. 
• Discussion of future direction and features. For example,  I have heard that the OLAP reporting and API will be retiring "soon" in favor of all Flex reporting. A clear statement about this from CH would be helpful. If the traditional OLAP is indeed retiring, then mapping of the OLAP services to Flex/Cur identification of the same costs would be helpful. 
• Discussion of various aspects of the OLAP API. For example, when I first started with CH several years ago, I discovered that the data returned by the API calls was much higher than that observed in the UI.  I discovered that the API returned rows that are subtotals of other rows in the data set.  I figured out how to interpret the data and handle it properly. Took a while.  I am willing to look this up and document it here if a) the OLAP API is going to continue to be around, b) that sort of thing is "in scope" for this community, and c) people care.  Better than me documenting what I discovered, it would be helpful for this to be documented by the CH folks so we are sure that we are covering all scenarios, not just one ones I have encountered in my travels. Which may or may not be all of them.
• Discussion of various aspects of capturing flex report data using SQL.  I just recently discovered the "ELEMENT_AT " syntax to grab billing tags in the Flex implementation of the CUR.  I would be willing to post my discovery here if it is the kind of thing that would be in scope for this community and if people care. I have not seen this documented in the official documentation (I have looked but have not studied it and looked repeatedly as the official documentation does appear to be changing). AI - Copilot helped with that discovery. I would like to see others post questions, discoveries, tips, caveats, questions etc re the use of flex report data. Is that the intent of this community? 
• Focus?  I am personally not focused on Focus right now since we are not a multi-CSP environment yet.  I would like to see discussions about Focus and how regular CUR/Flex data maps to Focus and how the data concepts relate. How can we get Focus data from CH to play with and understand how to reconcile Focus data with traditional data?
• Reconciliation of NX data with Classic data.  I think I understand, more or less. I would like to understand precisely, either by seeing precise documentation (with pointers here) or by having the ability to ask questions
• Recommendations.  "Deep understanding" of what drives the recommendations.  My organization is very risk adverse.  Suggesting to an app team that they can downsize a 50K/year instance to something less based on a recommendation from CH does not work really well, without explaining why CH "thinks" that is a low risk thing to do.  I have had more success showing underlying data and visualizations about utilization and showing that the instance in question never has high CPU or Memory usage and that downsizing will not put performance at risk, especially during peak busy hour.  I would like to see some clarity re how the recommendations are formulated now, and then depending on how it currently works, perhaps the opportunity to request some additional approaches to recommendations.

 

Enough for now.  Any other ideas of what we would like to see? Do we want this to be a very detailed discussion of things like these or more general kinds of topics? Should we set up some separate threads for some of the areas noted above? 

------------------------------
Eric Hilman
------------------------------

[TJ March]

Hey Eric! Thank you for your discussion starter!

Our Community Leadership team will be sharing some Guidelines, FAQs, and topic starters in the coming days.

In my opinion, I think many of these are great topics, and good see several of these becoming a good discussion threads. FOCUS is definitely a topic I would like to see discussed. How people are adopting it, using it, etc.  

Some topics (future roadmap) might be best left for 1:1 discussions with Product and Customer Success. 

-------------------------------------------

[Allan Solomon Mejia]

Hi Eric,

I think you've raised some excellent points. As CloudHealth continues to evolve, I believe one of the biggest opportunities is improving transparency around the underlying data model not just the dashboards. In enterprise environments, teams need confidence that metrics, recommendations, and cost calculations are fully explainable. That means clear documentation around data lineage, API behavior, Flex/Focus mappings, recommendation logic, and reconciliation between legacy and new reporting models.

I'd also encourage this community to become a place where practitioners share real-world examples: SQL queries, tagging strategies, CUR/Flex report mappings, governance practices, FinOps workflows, and lessons learned. Those practical discussions often provide as much value as the official documentation.

Perhaps separate discussion categories (Documentation, APIs, FinOps, Focus/Flex, Recommendations, Best Practices, and Feature Requests) would make it easier for members to find relevant content while keeping conversations organized.