Let's say (because it's true) I've been programming for close to 40 years but in completely different domains, such that the concept of "dashboard" means almost nothing to me. Could someone explain what this project actually is, or what "BI" is or why I would want it? I mean, I assume that "BI" is the thing that "PowerBI" implements, but other than that I couldn't tell you anything.
Say you have an inventory - list of cloud database instances from all engineering teams in the org.
Is this list growing over time or shrinking or remains the mostly the same?
If the list is growing, is it growing evenly across all teams , or some teams stand out? Can I narrow down to a few teams and compare?
What about overall health of the inventory - how many instances list security or billing optimization findings, how many instances are on the version that would be out of support soon and would need to be upgraded?
A dashboard can answer all those questions immediately and make issues visible, as opposed to a long list in a form of a spreadsheet.
I'm not going to pretend to be an expert at it, but BI tools let you interrogate your data. This can be used for endless use cases for basically any department in an organization. But for instance, if you're a sales leader you might have some questions about all of the sales and marketing data in your company to focus your team's efforts for the next quarter. When you figure out which questions are actually returning useful findings, you then can take a set of these and build a dashboard which lets you easily re-examine those particular questions and their results with always up-to-date (or up-to-date-ish) data and can easily share it with the team.
well BI is I believe business intelligence, which is sort of like military intelligence, the set of practices and tools that have evolved around the need to present data to business people in such a way that they can make sensible decisions regarding their business.
on edit: So a dashboard is just one of those things were you see all the things you can do or interact with assembled together and from which you can navigate into any particular tool or view of data. Probably there would be meaningful data views on top. Like Number of Purchases versus people who started a purchase. And you could then drill down into the data that this chart represented to see how long purchases took, repeat customers, when people leave process or purchase etc. etc.
The dashboard is the entry point for how you will navigate your business data.
So they're trying to simplify what, the addition of new views to the dashboard?
(Anders here, on the dbt Charts team)
What drew me to the dbt project back in 2020 and what ultimately led me get a job at dbt Labs was this notion that when compared to software engineering teams, analytics teams had been vastly unserved by their tools.
In 2016 (and largely to this day), BI teams work in point-and-click interfaces without Software Development Lifecycle mainstays like source control, testing, and deployment environments.
There are BI engineers who do work like software engineers, but the gap b/w those who work like SWEs and those who don't is wide.
dbt Charts (like dbt before it did for data engineers) aims to empower data analysts to work with stakeholders in a more efficient and sustainable manner than was previously possible. The means to this end are: a succinct YAML DSL spec for defining charts, a powerful CLI that lets you validate, compile, and render the code into a dashboard spec the YAML.
Like data analysts being able to do PRs for changes to a dashboard is still rather unheard of especially if those PRs are in repos with other analytics code. Many BI vendors do ship some form of diffing and environment promotion, but virtually always these features fall short of what SWEs use every day.
Why go for a configuration based format over a library though? Something like Streamlit or Dash offers more control and lends itself better to interactive exploration.