Localo is a LocalGov Digital Makers project to create by community consensus local government data and API specifications relating to the services and information provided by local government.
In local government we tend to buy line of business systems by service and for a specific task (e.g. Planning or Cleansing) and often from a big supplier. Typically they're not very open being either difficult and/or expensive to get data in or out which makes things difficult when we want to be able to integrate systems to allow end-to-end digital services which means users should be able to view current and correct information as well as transact in real-time. Councils also want to be able to evaluate performance which relies on being able to access appropriate data from their line of business systems. When access to the data within the line of business systems is possible, it's often bespoke. This means the other systems using data from the line of business systems would need to be updated if there was a change to, or replacement of, that system increasing cost and time required which potentially affects the viability of making the change.
There are two parts to the project (where the work hasn't been done already).
The first is to specify the data models. Data models specify how to describe a thing. Taking a bin as an example the table below shows what some of the standard attributes might be:
Type, could be open or have a list of values. Alternatively it could be something that computers understand such as a hex code #000000 (the hex code for black)
The second part of the project is to develop an API specification. APIs are a mechanism for other applications and hardware to interact with a system. The interactions allows access to the data within the system together with some or all of the funcationlity it provides. The APIs typically use web technologies so analogy is that they are a set of web pages that don't make much sense to humans, but do to machines! They are an integral part of how the systems in companies such as Amazon, Google, Facebook, PayPal and Twitter work.
Standardising the interfaces between systems should allow a more modular IT architecture. This has the potential to reduce reliance on a single supplier by allowing components to easily be replaced without having to redevelop neighbouring systems. It can also help increase competition between suppliers and support new entrants including civic coders because they don’t have to supply an all-or-nothing solution and the specification for the interface is open. Where development is required, throughput may also be increased by allowing teams to work in parallel on different parts and release their work faster.
A standard should reduce integration costs because for those suppliers that adopt the standard it will no longer be a bespoke integration. Councils will then be more easily able to share and reuse the work of others and collaborate without having to use all the same technology. That also increases the options for supporting one another and should create consistency for things like reporting.
The standard also infers a base level of functionality a system must provide helping to ensure that systems that are developed or procured work the way council want them to – based on the identified user needs.
Bringing this all together means we should be able to concentrate on building great user experiences, collaboratively.
The Gubbins of Government video below by Foden Grealy explains in "plainish English" how making systems modular and shareable can change government for the better.