A new model for interoperable administrative data
•Download as PPTX, PDF•
0 likes•51 views
This presentation shares Kwantu's work on interoperable administrative systems. It was given at the Global Partnership for Sustainable Development Data National Data Roadmap Workshop in Costa Rica in 2018.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to A new model for interoperable administrative data
Similar to A new model for interoperable administrative data (20)
Recently uploaded
Recently uploaded (20)
A new model for interoperable administrative data
- 1. How can we better connect administrative data?
- 2. What are the most common service delivery problems in my canton?
- 3. Data warehouse model “a set of clearly defined methods of communication between various software components.” - Wikipedia API model “a central repository of integrated data from one or more disparate sources.” - Wikipedia
- 5. From app centric to ecosystem centric design
- 6. Principles to guide the development of a Data Registry model 1. Demand led and incremental 2. Platform agnostic 3. 80:20 rule 4. Start at the lowest level possible
- 7. Building a library of comparable, disaggregated data
- 8. National Development Plan indicator – Number of jobs created
- 9. Simplify how we request, access and use data in the ecosystem
- 10. Which are the most common service delivery problems raised by citizens in my canton?
- 11. How might this model work in Costa Rica? (1) Focus on one area to start with: Map core business processes and data building blocks Work with administrative systems that can publish this data Led by Data Governance team (2) Co-create shared administrative apps: Different government agencies can co-create apps Linked by common data building blocks Respond to common needs (3) Shared library of administrative apps: Different apps shared in one library Government agencies choose which they want to use Each app ‘talks’ to the Data Registry
Editor's Notes
- As other panelists have discussed, there is a wealth of administrative data available It is often highly disaggregated, updated frequently and of high quality In many cases this data is directly relevant to urgent data needs However, one significant problem is that different systems for administrative data are not connected They are like islands full of data.
- What are the most common service delivery problems in my canton? (SDG 16.6.2) And by extension what is being done about them? May sound like a simple question, but to answer this we need to connect data from a number of different systems tracking delivery of services to citizens. These may include admin systems: Tracking service delivery for each sector(education, health, social development etc.) Tracking problems affecting citizens Administrative systems tracking projects that respond to these problems Answering these questions requires that data from different systems run by government (and NGOs) are combined to provide a unified picture of what is happening This is one example of a question that requires interoperability among different administrative systems Another example might be an SDG or NDP indicator that requires data from different systems (eg employment opportunities) Another example might be data on LNOB groups such as the disabled, gender or indigenous populations, which are served by multiple government programmes
- Let’s now look at different options for connecting data across different administrative systems that we’ve seen people try. Unfortunately this means getting a bit technical… The first model often tried is that of a data warehouse. Put simply, this creates an up to date copy of all data from all the administrative systems in one place Since it’s all in one place you can work with it to combine data from different systems The next model that we’ve seen tried is that of an API. This creates a common way in which different databases can communicate and share data with each other For example, if you need a way for all administrative systems to verify beneficiaries against a central beneficiary list an API would be a good option The Global Partnership is using APIs to make key global datasets more accessible. Both models are well suited for bringing together data that has a similar structure and similar context. For example statistical data. They are less suited to connecting systems that each have their own ways of structuring data and each deal with different contexts In these cases the complexity of using either model grows quickly as you connect more systems and deal with different types of data This in turn adds to the cost and time needed to deliver a project
- Sadly the most common model is closely to the reality, at least in South Africa. Story from a provincial department in South Africa: One official has a full time job exporting data from different systems that the provincial department manages They must then extract specific information to compile into a report that includes data from all these systems This must be prepared every three months and sent to the national department By the time they have completed this pain staking (and error prone) manual task, it is time to start again for the next month…
- In our experience, the existing approaches to connect administrative systems are not working They are expensive, require a lot of ongoing maintenance and are inflexible. We believe it is time for a new approach to this problem. This requires us to change how we think when we design administrative systems. Instead of thinking about data in the context of an administrative system, we must begin thinking about data in the context of a shared data ecosystem. This means agreeing on common data standards that are shared by many different systems
- Data Registry is a new model that we have been developing and testing over the last five years that builds on 20 years of work with administrative systems. Over this time we’ve identified some design principles that have been key in guiding the evolution of this model. First, the principle that it should be support a process that demand led and incrementally built – must not try and create a monolithic system that responds to all needs at one. Start small and build incrementally, focusing where there is demand Second, that it must be platform agnostic – must work nicely with any administrative system, built using any software Third, that there is a surprising level of similarity between different administrative systems from a data perspective. We’ve worked with many different parts of government. Also with a wide range of different NGOs implementing programmes. In our experience over the last 20 years we see a high level of similarity. If we compare two applications that track and manage support services - one to farmers, and the other to small businesses respectively we find that 80% of the data needs are common, 20% is different. Fourth, this level of similarity is highest when you work with the lowest level data structures. Our aim in developing this model was to reduce the cost of connecting data and make it a more manageable process.
- This is St John's College Old Library at Cambridge University. One of many libraries at the Uni. Like over libraries it has been built around collections of books added over many years. Each collection responds to a specific set of needs for those using the library. This process of gradual accumulation has resulted in a large and varied collection of books. The data registry works in the same way: Instead of librarians it is managed by a Data Governance team Instead of books, this library holds data building blocks Data building blocks provide a common format. This ensures that all data is stored in the same way Data building blocks also agree on a standard set of information. This ensures that the data is comparable Data building blocks focus on the lowest level of data collected possible. This ensures that the data collected is already disaggregated. Collectively they provide administrative systems with a way to publish the data that they collect in the same format in a comparable way.
- Let’s take an example: In South Africa, employment generation is a top priority for the government This is measured via an indicator – Number of jobs created – in the National Development Plan Delivery against this indicator is de-centralised across various government departments run programmes or projects that create work opportunities or jobs for citizens The systems used to manage these programmes must track how many days a person receives work as a result of the project or programme Since this work is very de-centralised, it is challenging to connect this data to see how many work opportunities are created nationally. And of course to disaggregate that data by gender, age and disability status. Not to mention other criteria like socio-economic status or ethnicity. To connect data from different administrative systems we have identified and agreed the following key data building block: Beneficiary timesheet – Attendance register tracking which beneficiaries were present on the project site for each day that the project is active However, implicit in this are several associated data building blocks: Beneficiary – Name, date of birth, address and other information on a person Project – Project managed by a specific agency that is providing work opportunities Project site – Specific place or places where the project is working Note that beneficiaries, projects and project sites are also very relevant to other data needs. Hence they would ideally be shared with other systems Now that we’ve agreed on what data to publish and how to publish it, those producing this data have two choices. Publish from an XLS or CSV file direct into Data Registry Publish data into the Data Registry using an API For older systems they will need to convert their data into the data building block format first For new systems they can store data in this format directly - All data published to the Data Registry is encrypted This is then an incremental, demand led process that agrees on and creates collections of data building blocks that link data already in admin systems to urgent data needs.
- In this model the ecosystem of data grows as we connect more and more islands, according to the current set of priorities While this responds to these data needs, it also creates spill-over effects as it responds to other (un-anticipated) needs To take advantage of these opportunities, the data registry makes it easy for data users to see who is publishing data And see what kind of data they are publishing However, to access that data they must request permission from the entity publishing it. This gives data publishers control over who access their data Should permission be granted, the data user gets their own database. One that grows over time as the publishers that have agreed to share with them publish more data Instead of spending their time trying to find (and then often process) data, they can instead spend time using it to answer questions. Which brings us back to where we started…
- Now let’s come back down to what really matters. What kind of questions can we answer when we are able to connect administrative systems? This image is from work we are doing with three separate programmes in Mozambique. They have agreed on core data building blocks to collect data on citizen’s perceptions of health and education services This data is collected independently by three different programmes, working with different schools or health facilities While they manage their own systems, they also publish selected data into the Data Registry. This is connected and used to generate a shared dashboard showing (among other things) the most common service delivery problems reported In this case the big picture on problems affecting service delivery, disaggregated by type of LNOB group Clue lack of ambulances is the highest priority What questions would you want to answer if you could combine data from different administrative systems here?
- This model has the potential to join up administrative data in a way that has not been possible before What would it look like to use this model in Costa Rica? First, an iterative, demand led approach to solve specific data needs. This would be led centrally, but would be consultative, engaging both data users (to define what they need) and data producers. This will lead to the creation of new data building blocks – or enhancements to existing ones This process can repeated as demand dictates and capacity allows. It doesn't need to be an all or nothing approach to create a mega system Second, start to look at the data gaps. In South Africa we come across many government agencies collecting and managing data on XLS This has obvious data quality implications We’ve pioneered an approach to co-create apps (based on common data building blocks) that serve a set of common needs These apps store data directly in data building blocks and are directly connected to the Data Registry Third, start sharing these apps on the Data Registry We already manage a shared list of apps that respond to specific needs of different departments in the South African government Instead of engaging in a software development project, they may simply adopt and use any app that is relevant to their needs. This provides a low-cost and risk free way to move from Excel to an App. This in turn increases the data available for data users to work with, which is ultimately what matters