Why am are coded analytics solutions less pervasive?

[u/Thick_Accountant7260]

Am I the idiot here? AI is so good the RMDs and Shiny apps I used to struggle in writing can be generated in a few days. Now that I can offload the CSS/JS part of the dashboard to the AI I can go nuts with reactivity/styling.

Based on the discussions in Reddit pbi/tableau/looker remains popular as ever but those things are expensive and are limited by the platform. I can see use for cheap and lightweight services like metabase where I can write the sql query and generate the dashboard in less than an hour but what about pbi/tableau? These services are expensive yet they remain popular what are the upsides of these products over say hosting my own shiny server/react/streamlit dashboards?

Like if I want an app that allows the user to define the cohorts themselves, save that definition, then load that into other dashboards/for future reference I can do that in Shiny but no idea about PBI.

What really is a semantics model? Why not just write a package that calculates the kpis then document it? The documentation also serves both the technical and non technical viewers alike.

Never been in a pbi/tableu job I don't understand how these products remain popular.

[u/AutoModerator]

If this post doesn't follow the rules or isn't flaired correctly, please report it to the mods. Have more questions? Join our community Discord!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/BillEnough7863]

For starters, you’re not really paying for Power BI, Tableau, or Looker just because they can draw charts. You’re paying for the entire ecosystem around them.

Authentication, permissions, governance, scheduled refreshes, sharing, integrations, monitoring, deployment, auditability, documentation, support, and a large pool of people who already know how to use and maintain the platform are largely solved problems.

You absolutely can build something lighter and more flexible with Shiny, Streamlit, React, etc. For a small team or a narrow use case, that may even be the better solution. But as the number of users, dashboards, data sources, business rules, permissions, and developers grows, your “lightweight solution” gradually becomes a custom BI platform that somebody now has to own.

Then you have to maintain it, document it, secure it, onboard people to it, troubleshoot it, make sure the original developer isn’t the only person who understands it, and hire or train people with the appropriate skill set. You can still get all of that wrong after spending a significant amount of engineering time on it.

That employee time matters too. If maintaining your custom analytics stack consumes a meaningful portion of an engineer’s time, their salary can very quickly cost more than simply licensing an off-the-shelf product.

That’s basically why companies buy software in the first place. They’re paying someone else to solve a large collection of boring problems so their own employees can focus on the problems specific to their business.

And the semantic model is part of that. It isn’t merely documentation saying “here is how we calculate revenue.” It’s an executable, reusable definition of revenue that every dashboard and user can query consistently, along with relationships, dimensions, access rules, aggregation behaviour, etc. You could absolutely build that yourself in code, but then you’ve started building your own semantic layer too.

So yes, if you’re a small shop with relatively simple analytics needs, a coded solution can be great. But the more people, data, permissions, reports, and business logic you have, the more expensive the custom solution becomes to maintain. At some point paying for the boring, established platform is considerably cheaper than having your team become the platform team.

[u/shufflepoint → u/BillEnough7863]

We're a small data warehouse team in a big (Fortune 500) org. We do all the data analytics and reporting - including bespoke web reports. But we also support users who use Tableau and Power BI. So it's rarely one or the other in a large org.

[u/BillEnough7863 → u/shufflepoint]

Yeah, I don’t think that’s really in disagreement with what I’m saying. Building bespoke web reports for specific use cases is very different from replacing your general BI architecture with a custom-built solution.

The fact that you do bespoke reporting and still support Tableau/Power BI is kind of my point. There’s absolutely a place for custom solutions when the use case warrants them. That doesn’t mean you want to recreate everything an established BI platform provides and then own that architecture indefinitely.

[u/shufflepoint → u/BillEnough7863]

> replacing your general BI architecture with a custom-built solution

We replaced spreadsheets with a custom-built BI architecture. Those who have worked in the space know that many companies - even Fortune 500 companies - run their business on spreadsheets.

I can only see replacing an existing commercial BI stack if the company decided to increase its prices tenfold - which is the kind of thing that's happening these days.

[u/Thick_Accountant7260 → u/BillEnough7863]

Agree on most points but: 1.) Having worked in R shops maintenance, documentation and governance are not hard at all. Its mostly a matter of the analysts caring to write their own documentation and the manager ensuring that the processes are observed. Its not like I had an easy time inheriting a looker dashboard either. Low code dashboards are less prone to error with fewer moving parts than a markdown/web app but are not immune. Most of the time its a dw problem and can trip both pbi and shiny apps and I can cache data in coded solutions.

2.) Back in the day I stopped caring for tableau/pbi when it was apparent that customization would be harder than writing a few lines of ggplot/echarts/whatever plotting library. I dropped the course when I couldn't customize the legends/dynamically aggegregate bottom groupings the way it made sense.

3.) An industry can only have so many kpis, some industries may need to define 20 or more kpis but I haven't been in one. Having lots of kpis is often a product of office politics or clueless people, in my experience its mostly someone pushing for an easier but nonsense target. This is especially true when working in the public sector somehow someone will always hostage the projects with the whole SDG goals.

4.) What are 'relationships, dimensions, access rules, aggregation behaviour, etc' arent these mostly resolved at the dw/query level before the data comes into whatever visualization layer you have? You can only slice and dice data in a limited way, maybe its just me working only for 'simpler' firms but what is a scenario where these things get so complicated writing the logic programmatically is not feasible? Companies that are mostly B2B with custom contracts? For the most part cant you just make a table of stakeholders/teams/departments and their permissions then load that into the parameterized report? Wont you also need these when working with low code platforms?

Everywhere I look the sample pbi dashboards look very basic something that just reports numbers which can be done by basically in any other platform, like metabase.

How easy/hard it is to make with a regression/control chart?

[u/Skthewimp]

CIOs don’t like open source!

[u/jwk6 → u/Skthewimp]

Which is ironic, because LLMs are essentially just copying open source code on a massive scale. But I agree there are still orgs that find open source too risky. 🤔

[u/plotly]

On the semantic model question: a documented package answers the questions you anticipated. A semantic layer answers the ones you didn't, because the consumer can slice by any dimension without coming back to you. That difference stops mattering when three people use the dashboard and starts mattering a lot at three hundred.

The other half is the bus factor. A Shiny app is one person's codebase, and when that person leaves someone has to read it before they can change a filter. Finance can hire for the other thing. That is not a technical argument and it is usually the one that decides it.