The only thing that is worse than an expensive product, is one that has unpredictable pricing.
While Tableau performance is a thing that people debate, its a non-issue. Generally, the data analyst produces a report that is consumed by 1-10 people and if that consumption grows >10, then the organization will "productize" the report by putting engineering resources on it and build something custom with HighCharts or D3.
In my experience, the ones that don't often produce some really erroneous or nonsensical results. Or even if they do get some things right, they have no ability to drill deeper.
BI in large corporations is usually done by people having no clue about the data, producing bullshit results, leading to "insights" to management (who at that point have have no clue that all the cost columns were added up, regardless of currency), leading to a final "product strategy" that gets implemented over the next years, while in all the companies still producing innovation, this is usually done by a rogue team applying common sense and ignoring that strategy all day long.
BI is pure feel-good for upper echelon.
Certainly there are lots of bullshit metrics, there is often very little desire to audit data or even do a by hand sanity check once and a while.
That being said, there were _many_ engineers who actually gave a fuck about making sure we had telemetry in actionable, meaningful, and appropriate places, and unfrotunately the gap in analytics would take place far over their heads, when the upper management would produce documents with all the beautiful charts and graphs, communicating.... absolutely nothing.
Graphs with mixed axis scaling (log vs non log) graphs with mixed units, conclusions that are a total stretch from the data that's there and ignoring obvious conclusions that don't line up with what the managers want to say.
For there to be USEFUL BI (and such a thing certainly can exist) there needs to be a "this isn't bullshit" mindset up and down the whole stack, not just in engineer land.
I think a lot of things come together for this pattern, which definitely happens quite a lot. Best predictor for this scenario is a clear divide between product and BI people, usually exacerbated by the fact that non-technical people get hired for BI.
Group bias by backend engineers who see BI as "just some point and click" which isn't really that challenging (but usually much better paid, as they are catering sales/bizdev/C-level which is always closer to the money) also doesn't help.
Also, as you say, often times the value of BI doesn't trickle back down the chain and that way, tracking is at most a second thought for application engineers when going prod.
Having built two analytics stacks myself (and seen the perspectives from BI, backend, sales and marketing alike) these are exactly the drivers we tackled first at our current company.
Our recipes against this common failure are: Marketing directly working with product engineers for their tracking requirements (with just some coaching from tracking pros) - and dual-using our analytics stack (Snowplow -> Redshift) for both operations (user segmenting, push notifications) and business intelligence.
This is usually considered a big no-no in BI circles which all tend to duplicate data to be on the safe side, but it helps immensely to make sure product and engineering are just as interested in data quality as the BI guys, as they depend on the very same data.
It's certainly not for everyone, but for us, it works really well.
i've only ever worked at small companies, and i guess to avoid things like this is why, but i can't help but wonder how common this is, and if in fact no one has ever used BI effectively. i find that hard to believe but really i have no idea, and its an interesting thought, makes you want to chuckle or shake your head or both.
It's a surreal experience when you realize how executives are making decisions based on something that, after a moment of critical thought and common sense, clearly has no more relevance than some integers pulled out of rand(). Chuckle and shake your head is indeed about all you can do.
Just try not to visibly smirk if you're ever involved in acquisition talks. Play along.
Huh? Just write a view or a stored procedure and point Tableau at that. There's no need to compose a query in the Tableau interface.
Tableau isn't SAP, it just isn't. If they want to really get into businesses, then they need to be sensible and give people the opportunity to use it and then get it into the businesses they work in.
For instance, I used Tableau to learn it for the 15 days they gave me, and I learned quite a lot as they have great documentation, but then after the 15 days I got no more opportunities to go through their tutorials. Partially I got busy on other things and wanted to revisit it after a few days, but I also setup SQL Server SSAS which took me a bit of time. I got a maximum of about 5 days usage, after that there's no point having it on my workstation as it's far too expensive for me to justify buying a copy.
If I could have had more time with the product, I guess I'd know how good it is so I can recommend it to the business I work at. Unfortunately, I can't without cracking their trial limit code, which I'm just not prepared to do. For now, I guess I'll be recommending Qlikview which is a known quantity and very good also, though nowhere near as intuitive.
- order 1 license to test it out
- analyst gets order of magnitude work done more than co-workers
- team manager buys 10 licenses and a tableau serverIBM has chosen to display "Analytics" as a major piece of their company. Presumably they want investors to think this could generate billions of dollars in revenue yearly. Worst case scenario for me would be IBM to buy Tableau, but clearly for those of us who use it, Tableau is one of the best tools out there for what it does. Will it be able to keep its marketshare 5 years out? Who knows.
Funny to me: it took years for Heap to introduce that.
Edit: we use and help customers with IPython/zepellin etc, but that doesn't change that these things are 10 years behind as IDE/visual interfaces. Adding charting & drilldowns is much harder than a button to turn a table into a line graph, and analysts are wasting a lot of time due to this.
As a side note, I've been following your work for a while now (both Superconductor and Graphistry) - mind if I shoot you a few questions privately?
So what is cheaper?
All clients are already on Office 2013, so that's not a concern either.
The Sharepoint cluster probably is a concern, but that's about the only thing, I'm pretty sure it'll be cheaper than Tableau.
I wish they'd invite the CTO to a Windows 10 events and give us some giveaways :) . No local state laws, this is for an insurance company in South America btw :)
Edit: the opinions are strictly my own, I'm not involved in any decision making sadly (no Windows 10 giveaways for me :P ), etc.
What does Tableau offer that I can not quickly set up in either Mondrian coupled with a frontend like Saiku or Pentaho or eg. R and a Shiny server?
At the time, between the ETL and reporting layers, it acted more like a set of different open source apps simply branded together, and interop required more effort than what should have been necessary.
Debugging was a nightmare as well. Huge stack traces on simple errors made locating problems difficult, and there seemed to be little information in the community. The number of Java library layers spewing out on a simple JDBC driver error was mind-boggling. Pentaho of course has a interest in revenue from support contracts, and most inquiries into simple issues in the forums led down that path. It may have gotten better since, but there was a long way to go.
We switched to Tableau on the front end, and "old fashioned" ETL scripting in Python (now some Go) on the backend. At the same point today I would consider something like R/Shiny, but for speed of implementation Tableau would also be a contender.
Its a bit of a one-off but it does work well! One more step towards making R fit for production :)
I guess it depends what you're trying to do. What part(s) of what Tableau offers do you care most about? How big of an organization?
Chart.io is one product I evaluated that met our requirements. We cared most about collaborative querying and the ability to run templatized reports (including regenerating them via the API) so we ended up going with Mode Analytics
However, in the difference, the admin stack with ELK, Riemann, Graphite, InfluxDB, Airbrake, Icinga and whatever else assumes that 30% of the information right now is worth more than 100% of the information 3 weeks later. You know, my application port is closed, first level support is getting hell, I need any available information right now.
On the other hand, the full data warehouse/tableau stack assumes that 100% of the information is more valuable than anything else. Good DWH-Guys and their analysts can do very awesome data voodoo, predictions and analysis, and the admin stack won't be able to reproduce most of that. It just takes 2 month of data collection and 2 - 3 weeks of analysis to get the result of that grand voodoo. And Tableau can automate that voodoo after it's been done once.
I've been at large orgs where we evaluated all the cloud services like Mixpanel and the ilk, but they are very different use cases.
Tableau + Redshift (or Vertica but Redshift is way less expensive) is the typical BI tech stack. When I go a client or a new job and ask them what they use for analysis and if they say "Good Data" or "MicroStrategy", I know my job will be a pain in the ass to get done. Its as if you're interviewing for an engineering job and they say "oh we all use NotePad here". Its night and day in terms of productivity.
I don't know what this means in terms of the stock, but all I can say is that I vouch for the product and think it has a lot of room to grow (from a BI perspective).