Discovery to explore the benefits of a common API platform

Full Application: Not funded at this stage

As signatories to the Local Digital Declaration we want to break our dependence on inflexible and expensive technology that doesn’t join up. This means using modular building blocks for IT, and open standards to give a common structure to the data we create. But we can’t achieve this by switching software.

To migrate live services we first need to separate our user experience from our business logic from our data so that better services tomorrow aren’t at the cost of a worse service today. A suite of common APIs across local government datasets, processes and applications would enable us to meet the goals of Declaration.

This proposal is for a Discovery exercise to explore how ‘government as a platform’ approaches might be used to deliver dramatic improvement across councils and public sector partners:

  • Decouple replacement of legacy back-end systems from delivery of new digital services, allowing councils to accelerate their digital transformation
  • Open up opportunities for design and development of new front end experiences which can connect as part of redesigned end-to-end services that better meet user needs
  • Open up the supplier market and enable collaboration across councils, by enabling new services to be reused across councils, even where back-end systems differ
  • Adopt ‘open source’ principles that will enable councils to meet their local populations’ needs while also benefiting from each other’s work

Local government shares open or common data schema (eg housing need data created to the H-CLIC standard) and many of the same applications (eg Academy for revenues and benefits). If we can define and build APIs that perform the business logic then we can decrease the costs of change.

 

Whilst there are a substantial number of local services and vendors, a significant proportion of the highest volume services are supported by relatively few IT vendors to business processes that are tightly defined by national bodies.

 

To be successful, the Discovery phase will need to:

  • Define a common way of building robust, scaleable APIs that can be easily reused
  • Demonstrate which suite of APIs would achieve most value if they were to be built in this way
  • Persuade a number of other councils of the value of this approach
  • Identify existing suppliers, or new entrants, that could support this approach

 

The Discovery phase will have the following elements:

  • Depth research to understand work done to date by particular councils
  • User research and business analysis to identify the barriers to different councils adopting this approach
  • A business case that presents a credible financial savings case and tackles the barriers
  • Prioritisation of the datasets and services that would be most attractive and achievable to deliver first (our initial view is housing and planning)
  • Technical discovery to identify the common tools / platform that would be necessary to scale API development

 

Within the 8 week discovery phase, we would seek to hold four events, modelled on the approach for the local GOV.UK Verify pilot:

  • Senior leadership session to identify the user needs from the business case
  • Standards and architecture, including security and privacy
  • Supplier workshop to assess the viability and blockers
  • A Design Sprint to demonstrate the value that can be achieved through a REST API

 

We will look at appoint an agency, or proven consortium of agencies through Digital Marketplace to lead this work so that we can understand the technical standards required.  

 

The work will be:

  • Published on GitHub
  • Blogged about and weeknotes shared
  • Show & tells and project assets will be available on common libraries such as Pipeline

 

The Discovery phase will be successful if:

  • We understand how to build a suite of APIs that can power more than one local service and reduce dependence on a line of business application
  • Two councils commit to collaborating on the development of APIs to a common standard
  • Another council, not in the partnership, commits to the approach  

 

As a result, the market for local government IT is inaccessible for many SMEs due to long procurement lengths, a resistance to change and opaque requirements.

Local government typically changes key line of business applications infrequently. Systems for revenues and benefits, social care and housing will be let on 5-10 year contracts rather than used as software as a service. Changing applications is commonly expected to take 18 months to two years and (depending on location) may cost £1m in additional expenditure to support configuration, migration and training.

 

Despite many years effort at digitisation, few local government services are digital end-to-end:

  • Data from webforms or ‘MyAccounts’ rekeyed into business applications
  • No customer notifications available at key steps in the process
  • No common identifiers available to power a master data strategy

 

As a result:

  • The customer experience is fragmented
  • Leaders see a change of IT system as a threat rather than opportunity
  • ‘Digital’ services have a significantly higher cost per transaction than expected and generate failure demand

 

Redesigning council services is often hampered by the inflexibility of IT solutions. For example:

  • Health and social care integration is requiring £mns to be invest in each STP area to enable sharing of patient records (despite the existence of data standards)
  • Shared services can lead to increased overheads due to greater customer confusion and difficulties of joining up data
  • Internal restructures can be hampered by IT applications that require reconfiguration to support service redesign

 

The user research will be vital for ensuring this work meets the needs of a cross-section of local authorities, not just well-resourced, London-based authorities with the technical capability or local supplier markets to enable this to happen.

 

We will:

  • Deposit user research in the open user research library
  • Report on project progress through Pipeline
  • Host show & tells via video conference
  • Share weeknotes via email to subscribers

Ensure all project documentation is available for reuse – eg open Trello boards

The goal of this Discovery is to:

  • Build a business case that meets user needs, and the user research will be documented in detail
  • Understand what common components are needed to support the development of an API platform that would abstract data and business rules from legacy line of business systems, enabling new digital services to access and update live data. This might include:
    • A mock API with common commands
    • A style guide for API naming and end-point standards
    • An open source code library for APIs
    • Mechanisms for open source collaboration between councils, with guidelines on code and community management
    • Recommendations for scaling APIs as usage grows
    • Identify APIs that would be most attractive and achievable to build first
  • Demonstrate the value of APIs to a non-technical audience
  • Provide the above in a sufficiently detailed way to enable people to start contributing to an API platform

We believe there are five categories of users:

  1. Senior leaders that set the strategy for IT in the organisation (this will vary council to council)
  2. Heads of Service that will typically inform vendor selection in a traditional procurement
  3. Heads of IT, Heads of IT Security and Information Governance who will need to need be supportive and reassured of the approach
  4. IT suppliers (existing and prospective)
  5. Government departments that play a role in determining the data standards or processes that accompany legislation

During this project, we would like support in being able to contact the following:

  • HMRC, DWP and DVLA to understand and influence their development of APIs
  • Policy leads for housing, housing needs and planning to influence their work around local authority data schemas

Comment on or support this project

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.