Hackney Council is prototyping an API-centric digital architecture. The HackIT manifesto tells us to ‘learn more’ by it was important for us to learn from experts who has successfully implemented a WebAPI in a government environment on a larger scale. So HMRC was the best candidate to visit and provide our developers with a unique opportunity to learn from the experts.
The visit to the HMRC office, based at Shipley was really useful and gave us a deep understanding of how they implemented and maintain their API platform. The team took us through their development journey for their API platform and provided us with insightful information to support us on our journey.
The journey of the API-centric development at HMRC has started in January 2015 with the involvement of 3 teams initially. After 4 months of recruiting people with the right skills, they have started their API development, taking 2 years to publish the first public APIs. The most requested API was from taxpayers for self-assessment module. The team had SMEs and contract developers to deliver the first set of APIs and gradually the team expanded based on user needs.
Key things learned from this visit:
- Overall Technical Architecture: HMRC has an in-house developed application which monitors the ongoing management of subscription, authentication, authorization and metrics processing for requests coming via client requests. In retrospect, they mentioned that it would have been better to go with the external vendor instead of building the in-house application which resulted in additional efforts to support it. However, they also explained the reason for using this approach to avoid vendor lock-in. Adopting a similar strategy would be very beneficial for Hackney to be able to monitor and maintain the WebAPI efficiently. They also use multiple level of abstractions in their infrastructure, such as proxy servers, gateways etc in order to make the API secure.Most of their infrastructure is hosted on AWS.
This inspires us to revisit our API architecture and create layers of abstraction before deploying our API public so that it is not subjected to vulnerabilities. It also prompts us to begin thinking about how we can host our API platform in the cloud. There will be some challenges around connectivity to our back-office systems, but products such as Direct Connect offered by AWS do give evidence that this hybrid platform is a viable solution.
It is also noted that they follow the DevOps approach for service delivery whereby one or two infrastructure staff are included in development teams for API delivery. This is a brilliant concept of having a platform team heavily involved in the Continuous integration of the WebAPI.
- Product management and understanding user needs:
Even though they develop APIs, they still follow a user-centered approach for development, where the client developers are considered to be their users. This extends their API-First approach where the endpoints are developed to meet user needs and not around the workings of back-office systems.
This approach makes us think “are we going in the right direction when it comes to WebAPI?”. We believe, adopting a similar “API First” approach where we develop our end-points to the users (developers) would be beneficial to create a flexible, standardized WebAPI.
They have design clinics every month for introducing and discussing design principles and they often hold Hackathons, inviting external developers to work with their API as part of their user research. This is something we are currently doing as part of Show and Tells however we can expand this on a wider scale by inviting external agencies who are interested in our Web API.
- Skills and Capabilities: Any skills not available internally are outsourced. These skills are then introduced and shared within and among teams; this way skills are retained. As mentioned earlier there was a sense of having clear standards set up and it was embedded within the team by having the same taxonomy followed throughout. We have adopted a similar approach of working with external companies but could do more around the transfer of knowledge and skills, possibly by highlighting key new skills in project retrospectives.
- API Service Standards: They also mentioned that they are building their own API standards which based on GDS standards. The standards have been gone through a well-thought process with a lot of scrutiny in place and consultation with various teams including Technical architects and Enterprise architects. There is a separate team for API Standards and Assurance who is responsible to review the changes in the API and also make sure it follows the standards they have set in. This well embedded process itself is something we are lacking on. We are currently working on our own Hackney Development Standards which will ensure that same taxonomy is followed throughout our API and new developers coming on board can easily understand it.
In all, it was truly a well-spent day with HMRC API team with so much to take on board since they have a massive API implementation. We did realize that it would have added even more value if we were to invite our platform colleagues along with us to get more information on their infrastructure; maybe next time.