[Issue #1507] BI Tool ADR

[coilysiren]

Summary

Fixes #1507

[sumiat]

Was there more you wanted to add here?
It seems like metabase will allow for our open source contributors to replicate? That’s great that we can do that with metabase. I’m curious what that looks like. For example, would users outside of the project getting access slow down the querying at all? Do we need to set anything up to protect that from happening? You don’t necessarily have to add it to the ADR, but I’m just curious about it.

[coilysiren]

Was there more you wanted to add here?

Yes I just finished the sentence 👍🏼

I’m curious what that looks like.

For the record, I don't think we should invest in doing this at all. It seems like a non-ideal use of time. Specifically, the time cost to setup / accidental risk of data leakage -versus- benefit is poor.

That said, if we were to support people outside the project replicating our Metabase data, we shouldn't do it via giving them direct access to the database. That creates a massive security risk. We should do it via giving them a pre-cleaned database dump of our analytics SQL database.

[ebuwa-evbuoma-fike]

The mental model I'm working with is Tableau. You can share the underlying data and allow users duplicate a visualization. Can you say more about what we're trying to achieve by giving external users access to a copy of our analytics database? Do we want external users to be able to:

• duplicate the viz,
• use the viz's data source to make their own unique vizzes, share, collaborate, discuss etc
• use all data sources (index viz and others, including for instance, data we haven't visualized yet) to make their own unique vizzes, share, collaborate, discuss etc

[coilysiren]

@ebuwa-evbuoma-fike it seems you may have missed the comment I made to Sumi about this same subject? It's here: #1677 (comment)

I personally don't think we should be investing time in allowing external users to duplicate our visualizations. I was not the one who wrote that requirement, so I don't understand its motivations.

@acouch or @widal001 might know more.

[ebuwa-evbuoma-fike]

Thanks for linking the thread with @sumiat , @coilysiren.

Duplicating visualizations is a very common practice - it encourages users explore, learn, critique and collaborate, which is germane to the open-source community we're trying to build. I do agree that it does not need to be the primary motivation of a BI tool. Granting users access to an approved copy of the data to explore (and ?share) seems more important.

[widal001]

@ebuwa-evbuoma-fike I can add some more context to this question:

Can you say more about what we're trying to achieve by giving external users access to a copy of our analytics database? Do we want external users to be able to:

• duplicate the viz,
• use the viz's data source to make their own unique vizzes, share, collaborate, discuss etc
• use all data sources (index viz and others, including for instance, data we haven't visualized yet) to make their own unique vizzes, share, collaborate, discuss etc

Yeah these use cases definitely touch on the core goals related to this!

To provide an example of why an open source tool paired with open data is super helpful is that the current grants.gov project uses Tableau, and right now there isn't an way for other project collaborators to understand how some of the current metrics are calculated, and the project has a fixed set of licenses for Tableau making it difficult give access even to internal maintainers.

Using an open source tool and making the underlying datasets available via API or csv files in a public S3 bucket would enable us to say to open source contributors:

1. Access or download this data via API/S3
2. Run this command to start up the same BI tool we use via Docker
3. Run these queries (ideally committed to our repo) to reproduce the same charts/reports
4. Experiment with some new metrics or analysis and then open up a PR with your SQL queries to reproduce them.

[jamesbursa]

Suggest mentioning that it's not a managed service, so we would need to manage deployment (upgrades, security patches, etc.)

In comparison AWS manages those aspects for QuickSight.

[coilysiren]

Since its dockerized, I would recommend we use the container as-is, without trying to apply security patches to it.

That means we just need to manage upgrades to the image version

[coilysiren]

Updated: 9290916

[sumiat]

Left comments, thanks for responding kai! Metabase seems like the right approach for us right now. Others, like @widal001 and @acouch, may have more thoughts though! Thanks for putting this together.