What's the project doing?

As you can probably tell from how we got here and what we learnt, there's things about our APIs and environment that we'd like to change. We're planning to address four core aims in this project with a tight focus on housing data for our tenants and leaseholders that our current services use (we're not looking at any other data sets for now as there's quite a lot to do in housing as it is!).

We identified nine key areas of skills which would enable us to develop APIs independently in the future. They are listed in the document below

We baselined our knowledge a few weeks into the project. Since then, we have had regular check-ins (every 2 weeks or so) to see how we're progressing with our knowledge level as a team. We track this in a radar chart which you can see below. The different coloured lines indicate the date of the check-in. The scale we use for our learning is:

• 0 - No prior Knowledge
• 1 - Some awareness
• 2 - Using it somewhat
• 3 - Using it competently
• 4 - Using it enough to challenge / teach confidently
• 5 - Subject matter expert

We are making a platform that can serve all our housing data needs. This means we're making sure the APIs we build are not specific unless they absolutely have to be i.e. instead of 4 specific service API's all serving, say, customer information from a data source, we will have 1 API that 4 services can integrate against to get customer information. If a service needs data in a specific way or to perform calculations etc. then they can create their own service API which will consume our more generic ones.

Our reusable housing data API's will be secure, data driven, structured, built in conjunction with data experts who can tell us where data is needed, what need it satisfies and where to get it from.

Running services from a physical server on Hackney premises (on-prem) means any failure of that server results in all services going down. In the cloud, a replica server can take over if a fault is reported. There are other problems associated with on-prem infrastructure (e.g. updates having to be applied manually, VPN tunnel access etc.) that can be dealt with in an equally secure but less labour intensive way when on cloud.

We published our first development playbook back in November 2018. Since then, we've learned a lot. As we've evolved, so have our standards. We're iterating them all the time. We want to constantly hold ourselves to these standards. Yes, that means refactoring code but it also means a much more sustainable, scaleable, secure and robust service for our users (and they're worth it)