Hackney Council

Support and challenge for building REST APIs

6 Incomplete applications

4 SME, 2 large

11 Completed applications

10 SME, 1 large

Published: Tuesday 30 January 2018
Deadline for asking questions: Tuesday 6 February 2018 at 11:59pm GMT
Closing date for applications: Tuesday 13 February 2018 at 11:59pm GMT

Overview

Summary of the work: Supporting a team of developers to build high quality REST APIs
Latest start date: Thursday 1 March 2018
Expected contract length: 3 months
Location: London
Organisation the work is for: Hackney Council
Budget range: £60,000 - £80,000 excluding VAT. We’d expect to flex the total price depending on the level of ongoing support and challenge required.

About the work

Why the work is being done: The Council has built over 100 web integrations between software with its development team and external contractors. However, these are not well documented and do not support a modern microservices architecture. We have been exploring the opportunity for REST APIs to connect our digital services. These are documented at https://github.com/LBHackney-IT. We now want to support the training of our developers, ensure that our code is robust and documentation is easy to follow.
Problem to be solved: Our development team needs support and challenge to ensure that our REST APIs are built to best practice. This includes adopting test driven development and pair programming practices.
Who the users are and what they need to do: As a developer I need to be confident in test driven development so that I can write high quality code
As a developer, I need to understand how to build REST APIs so that I can support the council’s approach
As a developer, I need to write high quality documentation so that my code is consistent with the council’s approach
As a digital agency supporting Hackney I need to understand how to build digital services consistent with its approach.
As a third party developer, I need to connect to Hackney’s APIs so that I can provide a digital service.
Early market engagement: We discussed an initial brief with a range of agencies that contacted us via Twitter. Lots of different approaches were suggested, which helped us develop this brief.
Any work that’s already been done: Three members of the development team have been seconded to a project team to develop a new housing repairs service, led by DXW. Through this work they have been supported in adopting test driven development and building APIs to the structure advocated by the White House. They have shared this approach with colleagues in the development team. These are documented at https://github.com/LBHackney-IT
We are now exploring this approach further by developing REST APIs around our master datasets, LLPG and Citizen Index.
Existing team: Development and Integration Manager, three lead developers and three junior developers, supported by an external consultant who is leading the work to develop the APIs. All of the team is familiar with .NET and the associated Microsoft stack.

The team is also supported by three additional developers on short term contracts to support the teams developing digital services for tenants and leaseholders.
Current phase: Alpha

Work setup

Address where the work will take place: Hackney Council offices in Mare Street, E8
Working arrangements: We would expect the team to spend some time co-located to develop relationships, but other support can take place via Google Meet and Slack.
Security clearance

Additional information

Additional terms and conditions

Skills and experience

Buyers will use the essential and nice-to-have skills and experience to help them evaluate suppliers’ technical competence.

Essential skills and experience: Have experience of working to the user-centred, Agile methods advocated in the Service Design Manual

Have experience of developing the technical architecture for secure, scalable data platforms

Have experience of designing and developing minimum viable solutions

Have experience of developing ‘in the open’ - using tools such as Github

Be able to advise on the best technology to adopt given the council’s aims

Demonstrate experience of developing REST APIs to open standards

Have experience of working with .NET and the Microsoft technology stack

Have demonstrable experience of supporting knowledge-transfer
Nice-to-have skills and experience: Developed a service to meet the national, or local government digital service standard

Experience of master data management

How suppliers will be evaluated

How many suppliers to evaluate

Proposal criteria

Understanding of user needs from the service
Clarity of the approach
Experience from an analogous project
Team structure, including skills, experiences and relevance of individuals

Cultural fit criteria

Work as a team with our organisation and other suppliers
Be transparent and collaborative when making decisions
Share knowledge and experience with team members and the wider service
Demonstrate simplicity (e.g. do less but better, explaining complex issues in a clear, simple way, break down and prioritise complex issues)

Payment approach

Capped time and materials

Assessment methods

Written proposal

Evaluation weighting

Technical competence

55%

Cultural fit

15%

Price

30%

Questions asked by suppliers

1. Proven capability in developing and iterating hosting and platform management services" do you require the supplier to host the platform and environments or will hosting, maintenance, 24/7 support etc be through existing service management functions provided by DEFRA?: We do not require the vendor to host the platform but would value advice on the best way to manage our APIs - whether that’s working with a service such as Apigee, Mulesoft or an open source solution like Tyk. Responsibility for management, maintenance and support will remain with Hackney.
2. What are your expectations around team experience of Test-driven development - does the supplier need to be expert in this area and provide training to your team?: We’d expect to review this after an initial discovery, but currently anticipate that the team would need support and training in test driven development. However, we remain open to alternative approaches to achieve high quality, robust code - provided those are widely followed.
3. Agile repertoires can be quite broad and can encompass aspects of the organisation having little to do with tech (e.g. applying Lean Startup principles inside & outside the organisation) with robust mechanisms for assessing key metrics. 1. Does the organisation have a view of where it would like to get to within the contract period? 2. Is tech/DevOps the main focus? 3. Does the organisation want to "stop" at the GDS/LGDS design manuals (which in the grand scheme, has low agile fluency) or would the organisation be open to the idea of going further in the time?: 1. We prefer learning through doing so haven’t made a clear statement of intent that we’re working towards. If we have the skills to push forward an API strategy and it demonstrates ROI, then we would want to have developed APIs around all our main datasets during the course of the contract.
2. This contract relates to tech and Dev/Ops but through a range of other activities we are promoting digital as an enabler of service redesign
3. Yes. The LGDSS is an important baseline for good quality services but we’re not wedded to GDS approaches alone
4. With reference to the user stories: "As a developer, I need to write high quality documentation so that my code is consistent with the council’s approach" What format does documentation currently take? How does the council envisage that writing high-quality documentation will make the code consistent with the council's approach? Is there a policy of documenting code and if so, does the documentation get out of date quickly? Can the documentation be 'live' and a byproduct of the development effort, not an explicit static deliverable?: The documentation is as currently set out in Github. We envisage the purpose is to enable it to be easier for third party developers and agencies to both conect to our API layer and develop REST APIs to our standards. So we assume that the documentation would be ‘live’ and a byproduct of the development effort.

Code (outside our APIs on Github) is generally not well documented currently.
5. a) How many developers and development teams require support. b) there is reference to external digital agencies in the set of stories. Our assumption was that the work would be entirely focused on the council. Is this assumption correct?: a) We currently have a team of nine developers, with four contractors retained in 2 housing sprint teams. Three front-end developers will be recruited shortly. The focus of this work is on supporting the nine developers - though the contractors will need to be able to work to our emerging standards (and may be able to support our in-house developers in their learning).

b) that’s correct.
6. What level of security would the API be expected to work to; token based API, login authentication? What security do the existing systems use? Do they each have their own security that the API would need to have knowledge of?: We believe most of our systems will require login authentication. Most of the existing systems use windows or system user login.

A small number of applications such as OneAccount and our corporate document management solution require token based authentication for web service communication. However, it is not anticipated that these will be part of the initial focus.
7. Can you tell us any more about the protocols and communication standards that the existing SOAP calls and XML documents would be delivered over? Are the calls asynchronous or synchronous? Queue driven or direct request?: All the existing Soap and XML documents are delivered using standard HTTP protocol. Yes almost all the calls will be asynchronous but some of them will be expected to be synchronous as well depending on the requirement.

All of calls are direct requests.We do not have any application requirement where calls were queue driven.
8. Can you tell us any more about the protocols and communication standards that the existing SOAP calls and XML documents would be delivered over? Are the calls asynchronous or synchronous? Queue driven or direct request?: All the existing Soap and XML documents are delivered using standard HTTP protocol. Yes almost all the calls will be asynchronous but some of them will be expected to be synchronous as well depending on the requirement.

All of calls are direct requests.We do not have any application requirement where calls were queue driven.
9. Can you share any information on what ‘ways of working’ have been used by the development team, have attempts been made to introduce approaches such as TDD and pair programming? If so, can you tell us what has worked and what challenges came up?: TDD and pair programming was introduced and continue to be part of the core development team.

What has worked:
- Unit testing made sure parameters are properly tested.
- Writing the test cases before more useful because it gives an opportunity to fix issues while you are developing.

Challenges:
- Getting all developers to understand the concept and implementing it
- Insufficient collaboration between projects using the same webAPI
- Resilience from developers not adopting TDD citing ‘time consuming, not enough information to write the foundation test etc.’
10. The tender notification mentions an external consultant that is working as part of the team to lead on the API work. How do you envisage this contractor working with the team being sought through this tender?: The consultant was, until recently, interim manager of the team so is well-trusted. His engagement is due to end at teh end of March. He can help project manage the engagement and advise on the existing APIs - but his involvement will be flexed depending on the preferences of the successful bidder.

Can we store analytics cookies on your device?

Awarded to Made Tech Ltd