The major milestone of early 2015 was the move to IATI 2.01. So what comes next? Is it closer integration with other open data initiatives (HDX, EITI, OpenContracting)? Is it soemthing else? Where can we continually improve?
1st: Data use. We need to break the chicken & egg situation between âdata is not good enough to useâ and ânobody is using the data so we donât know whatâs wrong with itâ.
2nd: If not integration with other initiatives, at least work on some of the joint foundations. Top of my mind is the issue of identifiers - business, NGOs, government organizations.
Eat Your Own Dog Food: the only one providing quality data about YOU is⌠YOU. The best people to provide feedback about your data are YOUR staff.
How can you use implementing IATI to accelerate better information management and use within your organisation, before youâre ready to publish, and eventually become an IATI promotor to your peers?
step 1: you produce
step 2: you use <<< focus here in 2015
step 3: you publish
step 4: you promote
Design Patterns: as mentioned in the Using the data forum, every publisher has its own âdialectâ. A simple first question on a common NGO case resulted in multiple ways to do that in IATI
In programming, design patterns have helped make it easier to understand code on a higher level of abstraction. Likewise, IATI design patterns could help make it easier to understand data, by providing high-level conventions on how you represent e.g. core funding, multi-level programmes/projects, location data, ⌠Weâd have to start with identifying such patterns (I have some starting points).
Proper Master Data Management
We all must act as âAgents of the Global Partnershipâ, and to that end it is of Paramount importance to demonstrate what it means to have âone common standardâ, as promised in Busan. Early in the process, it was duly demonstrated that DAC-donors could convert valid CRS++ data into a simple version of the IATI-format, but we still need to prove that âthe standardâ also Works the other way: That it is possible for the same donors to aggregate data from IATI-format into CRS++.
Some of our codelists need minor adjustments, before this can be done. I am aware of a few, but this task must be anchored in some sort of institutionalised MDM approach, with the aim of ensuring that we still have only âone standardâ - regardless of the future enrichments in either of the formats we must consider as Views of the content of the âone common standardâ.
âWhatâs in it for us?â: With a consistent MDM, we could piggyback on the efforts invested by DAC in the definition of their validation-rules needed to ensure the statistical quality of historical data, and benefit from this in our pursuit of better quality in current and forwardlooking IATI-data. Even if it would mainly or only be applicable to DAC-reporters, it would be a major step forward.
A challenge I would appreciate at some point exploring is what is the lowest common denominator of data that organizations should be thinking about capturing related to their investments / donations that not only meets the needs of IATI, but other standards such as for the Foundation Center, G-Finder, IHME, etc. I feel this would help keep our focus on the longer term picture and information needs of the various sectors.
1 Data quality (consistency and accuracy);
2 Data coverage (providing a complete picture of all the activities);
3 Data timeliness (so that your data are available at the right time to be used);
4 Linking the data with other publishers (so that we can work together on the basis of shared facts we all understand).
5 More focus on results in stead of the current focus on funding (input)
In one line: tailor IATI more to the task of supporting data driven policy making, do not use IATI only for accountability and transparency as a goal in itself.
Iâd agree with most things here. The what nexts for us in the UK are:
Greater use of the data for decision/policy making
Publishing results
Integration with other standards, particularly open contracting, and with the NGO Accountability Charter.