...
Top Level Navigation: Admin App users in prior releases first select "Settings" (features against their single ODS instance such as Applications, Descriptors, Reports) or "Global" (Vendors and Claim Sets). The Vendors page already suggests, even, the natural workflow: define Vendors, define Applications within those Vendors, obtains Keys. Given the natural order of that workflow, we recommend swapping the order of the "Settings" and "Global" navigation items, and then renaming "Settings" to "ODS Instances":
Consider the current tabs within the present-day Settings screen:
- Applications - Because Applications are instance specific, this page's contents would be limited to show only those Applications for my user's assigned ODS instances. When defining a new Application, the specific instance to add it to would need to be known, either as a new field in the Add Application overlay or as a tab-wide Instance selection/filter showing only those instances associated with the user.
- Descriptors - Because this is read-only and because the content is not district specific personally identifying information, we believe there would be no changes here. It does raise the question, where exactly are descriptors stored in this situation? Is each instance database expected to have a matching set? Does the single API combine results from each instance? If this is in fact a global concept, should it move to the Global screen? What motivated it to be on the Settings screen's "ODS Instance" tab in the first place?
- Education Organizations - Similar concerns as with Applications. The user should only see Education Organizations from their assigned ODS instance, and when they hit Add Local Education Agency, they'll need to have an ODS instance selected.
- Risk: This screen raises further questions about terminology. Early discussion of the deployment model displayed in the "Goals" section above tended to equate "District" with each ODS instance database. The sample Education Organization of Grand Bend ISD suggests that Education Organizations may be districts. It's unclear, then, whether there is a strict association between Education Organizations and ODS instances in all cases, or whether there are, say, non-district Education Organizations which might in fact span ODS instances.
- Bulk Load - Because bulk load hits the API with a specific Key and Secret entered in this screen, we expect no further need for Multi-Instance concerns here. Is this in fact a "global" API-level concern, belonging under Global, or is it somehow in fact ODS instance specific?
- Learning Standards - Same questions as for Bulk Load.
- Reports - AA currently adds reporting views to the target ODS database to enable reports. We expect this page to need an ODS Instance selection similar to Applications and Education Organizations.
- Risk: There's a similar conceptual/vocabulary risk here as with Education Organizations above. This screen has a District drop down list. Given that specific ODS instances have been described in terms of districts so far, it raises the question about how strictly true those examples are, or whether we need to be extra precise in our language: on the reports tab, for instance, would the user select both an ODS Instance and a District, and when would those not be the same apparently selection to the user.
Work in Progress: Early designs for Multi-Instance predated the above deployment recommendation. They involved defining instances in Admin App using a URL / Key / Secret, and then adding an instance selection drop down within the ODS Instances screen. We're beginning to think that design is mistaken, especially in light of the desire for a single API. Therefore, the pivotal design questions come down to the capabilities of the ODS both present day and in the future for this recommended deployment diagram, and whether key/secret therefore need to be per User, or per User+Instance, etc.
...