Frustration with unreliable IATI infrastructure when using data at country level

Community Zone Using IATI Data
#1

I thought it would be useful to bring this issue to the attention of the wider community. Poorly maintained IATI infrastructure is presenting a significant challenge to the use of IATI data at country level (currently here in Bangladesh).

A recurrent issue has come up with using the IATI Datastore. It is not updating data automatically – the last data available for the Netherlands is from early July (though their data is updated monthly). We previously faced the same problem with World Bank data. This means that a) new activities are not found and b) existing activities are not updated. This clearly presents a fundamental obstacle to using IATI data at country level.

After previously reporting this problem in early July, the data finally became available after two weeks (which is too slow, but OK if it doesn’t happen again), thanks to a bugfix by @andylolz. I reported yesterday that this issue has now appeared again for Netherlands data. My bug report was essentially disregarded and the issue closed, on the basis that the problem may lie with the Registry (which is not a reason for closing the issue: the Datastore is still not functioning correctly, as it is not returning the requested data).

I am extremely frustrated that such a basic, core service to IATI’s mission is so unreliable and that feedback on basic problems with using IATI data is not actioned speedily by the Secretariat, especially given the apparent focus now on data use.

Having been involved in IATI for about 7 years, it is really embarrassing to have to keep explaining to people here in Bangladesh that their data is fine, the government’s software is fine, but it is IATI infrastructure that is preventing their data from being automatically imported and updated. This is undermining confidence in the use of IATI at country level.

How do we fix this problem?

  1. Does the Secretariat need additional resources or just to prioritise existing resources better?
  2. Does the Secretariat even think people should be trying to use the Datastore or does it recommend an alternate option for accessing the data?
  3. Can the Secretariat have some kind of targets for uptime and resolution of major issues?

Suggestions welcome…

3 Likes
#2

You are, I understand, aware that this problem emanates from the Registry, not the DataStore. I appreciate this doesn’t help you at the coal face but a little explanation might be useful.

The Registry is a customised instance of CKAN, originally built by Open Knowledge and now maintained by Viderum, an Open Knowledge company. Users of the registry will be aware that we have been receiving a poor service for some time. The technical team have made a number of attempts to sort this out with little success. I am in the process of escalating the matter on a political level. We will contact you as soon as this is resolved.

At the Members’ Assembly I made it clear that IATI Developers currently have three key priorities:

  • Building a sustainable technical foundation and infrastructure that will ensure all core IATI products and services are as future-proof as possible.
  • Delivering a new integrated website that will ensure, inter alia, that we can scale our support services from 500 to 5,000 publishers.
  • Rebuilding the Datastore so that it
    • Ensures accurate importing of all data across all versions of the standard
    • Provides access to a database that is queryable across all fields
    • Delivers requested data via API in xml, json and a selected range of csv serialisations.

We are currently preparing our detailed workplan for the next year and will share this with the community as soon as it is finalised.

1 Like
#3

Apologies for getting into details here… Here’s the ticket (from June) regarding the apparent underlying registry issue: https://github.com/ViderumGlobal/ckanext-iati/issues/125

The issue was fixed on staging two weeks ago. Yesterday I tested the latest version. It looks good to me. Please could the ticket be reviewed by @IATI-techteam / Viderum be given the go-ahead to push this to production?

I think there are signs of improvement with Viderum. I’ve previously suggested that a more hands-on approach to managing (e.g. diving into the code a bit more) might be more productive, and would help the tech team have a better handle on what’s going on with CKAN stuff.

IMO fixing bugs that are affecting real users right now should feature on this list. I don’t think it’s a given.

#4

@bill_anderson, thanks for your response

This was the same reply I got from your colleagues and I have to say it is a very poor answer. The IATI Datastore is not delivering a basic service required for use at country level. Whether this is the result of failings in a service that the IATI Secretariat has outsourced to a third party or not, the Secretariat remains responsible. Further, it is really not clear that the Registry alone is responsible, and even if it is, the fact that OIPA works and the IATI Datastore doesn’t shows there are workarounds. Whether you choose to fix the Registry or the Datastore, both are within your power :wink:

I remain highly frustrated by the lack of prioritisation given to the Datastore, in preference for other tools like pyIATI where there has been no demonstrable user need or demand outside of the IATI tech team.

The Datastore does not need to be rebuilt. It just needs basic issues to be resolved in a timely manner rather than rather brusquely dismissed.

#5

Hi all,

I have just signed off on the procurement of the Somali AIMS, plus am working on two other IATI based platforms - all of which are designed to use the datastore. I am therefore having difficulty understanding that as a core tool, the IATI Secretariat a) make no formal promise that the datastore will work or have a target/standard for uptime/bugfixing (nor it appears does the contract with the registry supplier), and b) the timeline for improvements is “will be in the Secretariat’s workplan for next year” but unclear in what form/with what resources?

That is not a strong enough basis to develop tools that use IATI data in production environments, so I have to ask, what is the recommendation here? Go back to UNDP and say that IATI tools are not ready for production use for a few years? Find an alternative i.e. is that why lots of people use OIPA, is it better in this regard? If so, perhaps the Secretariat should formally recommend OIPA for production use - I don’t think they will, but what are the alternatives for those of us trying to get IATI data into the hands of users who need bugs squashed faster than the 4! months that the one that triggered this thread is taking?

Two linked thoughts:

  1. Maybe we need to start separating the roles of the secretariat into a technical provider with a commercial/binding service delivery contract for the core tools/services, and a separate role for the consultations, outreach, vision etc as it appears that the two missions maybe cannibalising eachother – perhaps this is the ‘back to basics’ discussion.

  2. Current IATI secretariat support to tools either needs to be stopped, or needs more money - this workplan indicates that maintaining the core tools in 2017 gets GBP 51 out of a total budget of 987 thousand i.e. approx 5% of the budget, or 7% if contribution to the registry is included. This is not the prioritisation, or the amount, I would pick if I wanted IATI to develop towards use in production systems. The rest of the IATI development community must spend over GBP 1 million (perhaps 2 million) a year on IATI systems/tools, it seems therefore bizarre that those core ones we all use, struggle by with under 5% of that.

Matt

3 Likes
#6

Great news: the issue with the IATI registry (that’s believed to be the underlying issue here) now appears to be fixed, and there is some indication that things may now be working on the datastore… I do think a bit more investigation is needed here, but it’s looking positive.

2 Likes