Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Issue 845] ADR for measurement dashboard architecture #936

Merged
merged 14 commits into from
Jan 26, 2024

Conversation

widal001
Copy link
Collaborator

@widal001 widal001 commented Dec 19, 2023

Summary

Creates an ADR that evaluates and recommends different architectural patterns we can use for our public measurement dashboard 30k deliverable (#65)

Fixes #845

Time to review: 10 mins

Changes proposed

What was added, updated, or removed in this PR.

Creates documentation/decisions/adr/2023-12-18-measurement-dashboard-architecture.md

Context for reviewers

Testing instructions, background context, more in-depth details of the implementation, and anything else you'd like to call out or ask reviewers. Explain how the changes were verified.

Updated the recommendation to the following:

  • Short-term: ETL pipeline that writes metrics and data to S3 bucket + static dashboard UI that is refreshed daily (e.g. Jupyter notebook, static site, etc.)
  • Long-term: Combine open source dashboard tool and analytics API + dashboard UI to form a pipeline for testing and "promoting" metrics to the public dashboard:
    1. ETL: Write the data needed to calculate operational and program metrics to a data warehouse via an ETL pipeline.
    2. Ad hoc report: Prototype a new metric by building an ad hoc SQL report in an open source dashboard solution (e.g. Metabase or Redash) connected to that data warehouse.
    3. Temporary dashboard: If that ad hoc report is useful to stakeholders, then incorporate it into a temporary dashboard within the open source dashboard tool.
    4. Public dashboard and endpoint: Once we get feedback on this temporary dashboard, formalize the metric in a new (or modified) API endpoint that is consumed by a new (or modified) page in the public-facing dashboard application.

Additional information

Screenshots, GIF demos, code examples or output to help show the changes working as expected.

Copy link
Collaborator

@lucasmbrown-usds lucasmbrown-usds left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very thoughtful! I look forward to discussing.

@github-actions github-actions bot added the documentation Improvements or additions to documentation label Jan 16, 2024
@widal001 widal001 marked this pull request as ready for review January 17, 2024 18:11
Copy link
Collaborator

@lucasmbrown-usds lucasmbrown-usds left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Thanks for thinking this through so carefully!


## Pros and Cons of the Options <!-- OPTIONAL -->

### S3 bucket + user interface
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To clarify: would this used the component-based dashboard UI you were demo-ing the other day?

@sarahknoppA6
Copy link
Collaborator

I don't really have any feedback here, looks good to me.

Copy link
Collaborator

@coilysiren coilysiren left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is such great work!!! My high level POV is that I think we should go straight for the "custom dashboard app" (eg. plotly-dash) or "open source dashboard" long term solution. Especially now that we have more infrastructure engineers.

@widal001
Copy link
Collaborator Author

This is such great work!!! My high level POV is that I think we should go straight for the "custom dashboard app" (eg. plotly-dash) or "open source dashboard" long term solution. Especially now that we have more infrastructure engineers.

@coilysiren Thanks for suggesting this! It's super helpful to know that y'all feel like you have a bit more capacity on the infra side to take on setting up a more robust data platform.

Maybe the recommendation should be more of a parallel than a sequential approach?

As described in the long-term recommendation, eventually we want both:

  1. An open source BI tool for ad hoc reporting / PoC dashboards
  2. An analytics API + custom-built dashboard UI that's intended for public consumption of well-tested metrics

I see the s3 bucket + dashboard UI as a stepping stone to 2) with minimal up-front infra investment, so would love to work on that now. But if y'all have capacity, maybe we could also have you start building out the infrastructure for 1), which would involve a couple of decisions and outputs:

  1. ETL pipeline + orchestrator -- hopefully building on the work in this 10k [10k]: Search API - Data transformation #990
  2. Data warehouse
  3. Open source BI tool (connected to data warehouse and other data sources)

@widal001 widal001 merged commit 0cde899 into main Jan 26, 2024
1 check passed
@widal001 widal001 deleted the issue-845-adr-measurement-dashboard-architecture branch January 26, 2024 16:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[ADR]: Public metric dashboard architecture
5 participants