Digital innovation relies on the smooth and secure circulation of data. The 'information' in information technology, data is what software solutions store, analyse, enrich, and represent to users. If data is shared too generously, it risks being compromised and leaked; if it is held too closely, systems that rely on it to function will fail. A local government digital procurement strategy must therefore be predicated on ensuring the smooth and secure exchange of data between all relevant stakeholders: government, corporate, the third sector, and the wider public.
<aside> 💡 APIs, simply put: "Essentially, APIs allow different systems and applications to talk to each other and exchange information both within and between organisational silos, and with digital developers and data scientists in the wider community. In doing so they provide a crucial part of the ‘plumbing’ system for delivering cross-agency services designed around our citizens’ needs." Read more about APIs for the public good here.
</aside>
This circulation flows in two directions. The first is from IT software providers to local authorities. IT software providers hold data that government users or citizens have submitted or enriched through their interaction with the software. For example, the software used to manage social housing may contain information related to ... A local authority may need to extract all of this data, both at a batch and individual level, for example to hand information to a user who is moving out of the borough and would like a copy of data related to them for their own reference.
The second direction of data flow is from one software provider to another. Government buyers of technology need to consider how one party's software may need to be able to access government data hosted elsewhere in order for the third party software to effectively deliver its own functionality. For example, a provider of insights and analytics solutions will need to be able to draw on live feeds from a housing system in order to provide a live dashboard of which flats need new keys. This B2B flow of government information is becoming ever more important: instead of vertically integrated providers who provide an end-to-end solution, digital solutions are trending towards so-called 'microservices', or modular software solutions whose data feeds can be seamlessly coupled up with ('integrated' or 'made interoperable with') those of other pieces of software. Those commissioning digital solutions therefore increasingly need to be proficient in bringing together multiple software solutions which together deliver an efficient and flexible service to users. They may even need to account for future B2B data needs that may as yet not exist in order to 'future proof' their commissioning strategy. As Paul Neville of Waltham Forest put it: "A CIO's job now is to integrate microservices".
<aside> 🥙 An example API use case: health inspection data. MuleSoft, an API integration firm, present the following example: "Take, for example, the restaurant inspection scores of a local government health department. In the past, the utility of such scores may have been limited by the lack of engaging means to publicise them. Now, by making such scores publicly available on the web and easily accessible through a well-designed API, the local health department can leverage the ingenuity of outside developers to disseminate and find new uses for the restaurant scores through new applications. Developers create apps that list local dining spots based on various user-selected criteria, including health scores. Healthcare organisations create apps that use the scores, combined with dietary and nutritional information, to recommend healthier eating options for its subscribers. And the health department itself creates an app that makes it easy for the public to find the health score of any restaurant within its jurisdiction. In these and other ways, the health department has vastly expanded the public utility and reach of its restaurant health score records – all simply by making the data accessible through an API."
</aside>
It's important to note that there are different ways to access data. There are more manual models, where data is imported and exported in a batch and sent over as a file. Think of an "export" button on a piece of software you may have used: this requires active intervention from the user, and produces an output that will need to be uploaded elsewhere or otherwise manipulated again for it to be useful. However, APIs work somewhat differently: they structure data in such a way that other programs can access the data, rather than individual human users, allows the data to be extracted and manipulated directly by another piece of software. Important here are third-party integration apps, which "allow content managers to connect various data sources with little technical skill and programming capabilities required. Such connections occur using APIs, but the third-party applications act as intermediaries for non-coders."
Simply put, the ideal situation for data access is that all data that a buyer has a legitimate claim to can accessed by that supplier or others they authorise to access it in the format they desire and at no cost. This has the following practical benefits:
The 2018 APIs4DGov survey by the European Commission showed that economic benefits were top of mind for those developing API strategies (below).
<aside> 🏥 Health and Social Care Information Systems have been particularly central in the drive to ensure public sector IT interoperability. A report by the LGA, Socitm, and various councils explored steps taken to make social care systems more interoperable and API accessible. The focus here has been on "joined-up care": care where "where people providing care are [not] pending too long chasing for information or not able to make decisions with the best available information to hand". Read here about the effort led by TechUK to drive uptake of an Interoperability Charter for health and social care organisations, as well as to see if your suppliers are signatories.
Further work in advancing the cause of interoperability in the health and social care sector is undertaken by INTEROPen, "an open collaboration of individuals, industry, standards organisations and health and care providers, who have agreed to work together to accelerate the development of open standards for interoperability in the health and social care sector". Consider joining their effort to advance the cause of interoperability in health and social care.
</aside>
However, in the real world of local authority IT procurement, many obstacles exist to both of those flows. On B2G (Business to Government) flow, many local governments find themselves facing situations where they are being charged extortionate fees to access data that they themselves have. Since the data being requested is the local authority's, it can be frustrating that data held by a supplier isn't accessible quickly and for free. On the B2B flow, many young suppliers complain that they are not able to build solutions because the APIs offered by incumbents are expensive, badly documented, or not even existent.
The reluctance of traditional incumbent suppliers to open up data on systems they host is widely believed to be a key obstacle to interoperability in local government digital ecosystems. It is believed they place restrictive contracts on their systems or unreasonable charges for the APIs to access them, in part in order to restrict the growth of potential competitors who would benefit from accessing the data stored on their systems. A January 2019 report by UKAuthority, sponsored by IT service provider Cognizant, surveyed and interviewed UK local authorities to better understand the key barriers that exist to the deployment of APIs. It found that the
"highest scoring barrier in our survey was ‘Restrictive contracts with legacy suppliers’ (2.8 stars), closely followed by ‘Charges from legacy systems suppliers for individual APIs’ (2.7 stars)."
Correspondingly,