Data Governance for Source System Vendors 

Data governance invariably looks different across the agencies that you work with. It is important to understand these data governance activities and how they relate to your engagement to achieve the best outcomes for your agency partners. 

As a source system you likely view yourselves as an important hub of key agency data.  However, your customers are more likely to want to take a modular approach to their software tooling with the flexibility to pick the “best of breed” in each category and be assured that the data will be accessible to them out of the box. Data governance activities are used by agencies to help them make determinations about the best solution to meet their needs. This often includes considerations involving data management, collection, and ownership; architecture; and security Supporting agencies with these key data governance activities would mean providing clarity on: 

• Data ownership: You may have traditionally stored data that you are not the system of record for. For instance, the customer probably has an ERP system that maintains staff and financial data that is then imported into your system in some way. In the Ed-Fi model you will not be responsible for every piece of data that you store, and you may in some cases be dependent on another system – as a SIS vendor for instance you may not be able to post Staff Section Associations until an ERP vendor posts Staff records. 
• Extensions: This covers data that an agency wishes to collect that is not represented in the Ed-Fi data standard or is not represented in the way that the agency wants it. Extensions tend to be implemented at the state level, and the Ed-Fi alliance has a review process to determine how well they align with the core model. You can read more about existing extensions here: (https://edfi.atlassian.net/wiki/display/TNG/Examples+of+State+Extensions) 
• Business Logic: Agencies may ask you to replicate business logic that they could just as easily generate from raw data in an ODS. This is a teachable moment! The Ed-Fi data standard supports raw, transactional data that can be summarized and calculated downstream by an analytics platform or data warehouse. Supplying this level of data ensures that you’ll be able to implement in any geography no matter what their eventual reporting needs are. 
• Security: Good news! The REST API standard and built in support for modern authentication methods are naturally more secure than many existing methods of data transfer. Your support of the standard reduces the need for custom reports and exports that have the potential to expose personally identifiable information. 
• Data Integrity: The API surface itself enforces many high-level integrity constraints (every student must have an enrollment, etc.). Your ability to ensure accuracy and completeness is important to your customers, and the feedback loop you gain from submitting your data to the Ed-Fi API will make your internal processes more robust. 
• Data Dictionary: an agency may have already tried to map your data elements to the standard. You should be involved in this process to avoid confusion and also to feed other projects. Mapping your data to the standard as an internal resource gives you consistency and repeatability across geographies and implementations.

To summarize, as a source system vendor you should make sure that you are included in data governance conversations early and often. Agencies may have policy and legal responsibilities that differ from what you’ve seen before, so don’t assume every implementation will be the same! Having the right understanding of how your system can integrate is a key part of the equation.