ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
2
ObjectiveMeeting 1 brainstormingMeeting 2 notesSpecific recommendationsWho would be developing/investingWhat is the ideal outcome of tackling this?
3
1) Improving API error responses and handlingEg. intervention domain

Needed access to backend logs and information

Lots of APi error occurring - who is monitoring those - and remediating

E.g. trying to access API years that are not available

Single, multi-tenant API or 1 API instance per LEA

WI has single API

Use Azure App Insights - sampling

INSITE has 1 API per LEA

Vendor tooling to review/manage errors

Can we improve L1 errors returned - with more information

Database constraint errors are confusing

WI - added more human-readable layer

Vendors - issue calls to generate errors to inform action - can this be improved -- auth strategies

Providing test/bad sets - from #2		JR: Foundational core, technical

JS: WI internal tools, what is the outcome - should break down

Could this area be delegated to the TAG?

Jenn - 1& 2 combined?

How can we make most basic and widely impactful errors more understandable
Reliance on database referential checks that don’t make sense in the payload


Calling API’s to get error information

Having to delete child records to delete parent records

- WI - built tools and portal
-- Vendors have built better support - but cryptic messages

- Pair with a dat set of common bad data errors? -- in the source system!
- INSITE
-- Keep an anonymized version of bad data from SIS*
-- Creat ODS in an incomplete state - and build up, fix?

- ODS - w/ descriptors + seed data -- and ask SIS to complete transaction - that should fail or be handled
--- illustrate error patterns early in vendor implementation		Identify 10/20 highest impactful errors - and return more meangful responses.

Develop a strategy to to cut down errors

Enable calling system to make sense of errors (start with a few high ones)
--focus on human readable errors - for source system users vs APi developers?

TAG + Alliance Tech
4
(2) How do we give new vendors better information to get startedInformation of cost/effort/best practices/upgrade/migration

Provide bad data in test data sets - for testing, certification, getting started

Pulling data from the API - Difference between sample data and real world data was a surprise - needed to do additional work on top of API results


Certification & Testing environments
Varies across states

State-level certification - 7 SEA’s

Core certification - supports Ed-Fi core certification only


ta stored in different locations in SIS - SEA and LEA?

Testing environments

Simulate production environment for testing - and built a tool for vendors to clean up their sandboxes

Student id’s get messed up in multi-tenant sandboxes		This is related to #1.

For new vendors - general best practices
Also use-case-based

See WI use case examples

best practice - e.g. order of posting - Section association error -- doesn't tell them about a bad staff associatio
Improved on-boarding / best practices documentation

Investments in real-world sample data sets
TBD - Alliance Training focus?
5
(3) Tackle collision of SEA/LEA data collection requirementsCan we encourage SEA’s to collect standardized, granular data - and do aggregations up-stream. Rather than pushing business rules down to the LEA/SIS

Examples are attendance, Instructional hours


Data stored in different locations in SIS - SEA and LEA?

Vendors - distinguish between work required for state reporting vs optional fields (largely for LEA use cases)

SIS selection - features vs state reporting

Bring differences to SEA work-groups -- review across major SIS vendors		Alliance staff + Governance groups
6
(4) How to help districts make an informed decision in vendor selectionWI - how to help districts make an informed decision in vendor selection

E.g. in WI - 27 new choice schools - for new vendors or switching vendors

E.g. Basic market information about Ed-Fi vendors - in one place, support capability
7
(5) Tackle expectations of vendors/interop and bring data back into the SIS - via APIE.g. Immunization, Discipline, SPED, Assessment data -- via the ODS

Add-ons/integration - as an add-on/charge opportunity

SIS as a source of truth

SPED source of truth

Where is reporting done from

SIS vs ODS

Staff access to systems
8
(6) OtherAdding “value-added” features (e.g. Immunization API) - add effort/cost to vendor


Large districts -- won’t take SIS vendor upgrades on a timely basis (w/ on-prem)
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100