A very very simple dashboard

[pritikin]

best for it to be layered on the example API this might just be a simple script or jupyter notebook exposed as a web page

that way a new person could see something happens from this work

[pritikin]

Willy's feedback: focus on current states and trends (compliance first and improvements second)

[JonathanChristopherson]

I didn't immediately like the idea of building a dashboard for an API, typically I would expect that an API emits data and then the consumer would need to assemble a dashboard, however, I think there is some merit to your issue, especially if we take advantage of your suggestion to do a Jupyter notebook.

Thought:

For compliance-based APIs I like to have teams build a Notebook that walks an auditor through the intent of an API and enough of it's use and design that the auditor can use that information to audit the API. What if we did a similar thing here, and met the need both of creating a dashboard and the need of explaining how to use this at the same time.

Suggestion: What if we write up a notebook that describes the API and it's use at the same time that it provides a dashboard for mocked data?

Second Thought: Since we don't have tests defined for "test driven development" yet, we could go the alternative route and use this notebook as a "Documentation driven design" artifact and use the description of how we intend the API to be used as a design guide. The document itself becomes the roadmap for the value outcome of the different features and data fields.

[pritikin]

I like Jon's suggestions.

This issue isn't that we need a "dashboard" so much as that we need a working description of how the API will be used that is paired with a sufficiently documented use case and design guide that we can tell if we're succeeding. Its additionally important that a new party, the assessor in Jon's example, can determine if the system is working.

By implementing a jupyter notebook we achieve these goals in a streamlined way that de-emphasizes "ui dashboard stuff" which we do not want to be distracted by.

[pritikin]

Discussion 1/7/2021 This initial "dashboard" provides a visualization AND how an auditor uses the visualization to perform the audit. The goal is to help a (continuous) audit... so spend time explaining this now as the goal of the dashboard.

"here is the way to think about metrics" "here is the way an API could use the metrics" (presumably integrating into GRC tooling).

[pritikin]

We need this output to "jive" with CSA expectations so the broader CSA leadership can get excited. Perhaps:

• CSA star flow
• extension to audit guidelines (perhaps create a new issue to work with that working group)

Dates need to be determined?

This should be tracked in #26

[pritikin]

The goals of a simple dashboard were met with the prometheus/gafana integration. There is a ton of room for innovations. Closing this thread so that (issues regarding those) innovations can gain visibility.