Amazon Connect weeknote, w/e 22 May 2020

Things are starting to get real now. We’re in our last development sprint and I’ve just had a demo of what our system looks like (it’s really easy to use!). It’ll be handed over to us next week for user acceptance testing – basically, make sure it works and see if you can break it. Then we’ll have a whirlwind week of training, bug-fixing, final preparations and finally switching the two lines over on 2 June. That’s barely 10 days away. But that’s looking to the future, rather than what’s happened this week. 

We’ve made some real progress on our call recording issue. Our supplier has shown us an assisted payments module which is 100% compliant with the payment industry standards and is in use with a couple of other clients. The agent remains on the call, though they cannot hear or see any card data as it is entered by the caller. The card details are encrypted by the system and sent to our payment processor. We believe there is an API for that, and so should we adopt the Amazon Connect system after the trial, this is likely the first thing we’d do. Until then, we will not record calls. 

We had another retro on Monday and our team working and collaboration stood out again. It has been good working with Mission Labs and the Contact Centre, everyone is really flexible and I’ve learned a lot about how the centre works over the last couple of weeks. 

A lot of this week has been spent tying up loose ends. We’ve got our training plan outlined, infrastructure changes lined up, and a go-live plan. Service Support colleagues have joined us and we’ve agreed how we’ll manage any issues reported by staff. We’ve also drafted the questionnaire for usability testing – we’ll be recruiting some Hackney residents to test this for us and give feedback. We need to get this right, and I’m sure people will be frank and honest. 

Liberating our social care documents

Watch the Show & Tell on our YouTube channel

Even before the COVID-19 pandemic, Hackney had taken steps to move some of our corporate applications outside the firewall, though still requiring a council-managed device. With the urgent move of as many staff as possible to home working, many staff are using personal devices or council-owned Chromebooks which aren’t configured to access corporate apps even outside the firewall. Therefore, for these apps, staff use a virtual desktop service called MyOffice. But with so many people trying to use this service at the same time, it’s not always reliable and can be slow. 

Mosaic is one of our main caseworking applications, which we made available to staff over the internet to reduce pressure on MyOffice. However, it has two document management systems associated with it, Comino and eDocs. Both of these required users to log in using MyOffice; this meant the end-to-end user experience was poor and complex, and there was still an unnecessary load on MyOffice. Our aim was to enable staff access to their documents without having to use MyOffice. 

We put together a team made up of staff from Hackney and developers from MadeTech, who had been engaged to support our move off MyOffice. We identified three areas of work:

  1. Exposing eDocs documents via an API with Google authentication
  2. Adding support for Social Care Comino into the W2 Documents API (and potentially exposing an interface to query it)
  3. Redirecting the user from the URL stored in Mosaic to the correct URL for the document
Season 6 Episode 3 GIF - Find & Share on GIPHY

We established pretty quickly that Comino documents were not heavily used by staff in comparison to eDocs documents – they are mostly legacy documents. We decided that we could leave these documents being accessed via MyOffice; although not exactly an edge case, it was much lower priority than eDocs. 

There was an existing API for eDocs, so we built a simple tool that uses the existing document ID as the input to retrieve the document from the remote server to AWS, and displays the document in the browser. This part of the project was relatively quick and we thought we’d be done in days. 

The last step was to redirect the (internal) URL in Mosaic to the new URL at – and this is where we became unstuck. While we were able to translate the internal URL to the internet URL, we just couldn’t get the systems to connect. On investigation, we discovered that Mosaic codes the URL into the “Display document” button. Buried deep in the system we found a config file that we thought would control that… but no. We needed a Plan C.

We scoured the technical documentation and found the Frameworki API in which we could change the URL in a config file… and it worked! 

We used otherwise lost time to enhance the prototype service so that documents convert to PDF on download, and set up additional monitoring. Preventing automatic download of documents is important, given the potential nature of the content, but at least having the ability to view the document is a game-changer for our staff. 

We’re using the council’s existing Google Single Sign-On service to secure access, and we’ve set up a separate group to restrict access to the right people. If someone tries to open a document that isn’t web-native, they get a friendly error message telling them to use MyOffice for that document. 

Nothing in this system is new; indeed, MadeTech wisely built upon work they had done for the council’s Single View system used by Benefits & Housing Needs. And the work that we have done around authentication has been reused by the council’s I Need Help service. 

Pleasingly, we only found two bugs in testing, and one of them wasn’t really a bug as the system was working as designed. However, we found that if a user edited a document then uploaded it again, the user would be presented with the original document from cache. We had done this deliberately to speed up the process, but decided it would be better to serve up a fresh copy every time, even if it takes a little longer. 

Towards the end of the project we held a retrospective, which was positive. For a team which had never worked together, never mind together remotely, our teamwork and collaboration stood out. We thought that we were truly agile, using the daily stand-up as a daily planning session for that day’s priorities, and we pivoted quickly to find paths around blockers. 

In terms of future work, if we decide to develop this further, we’d probably look to fix the caching issue first so that the API looks to see if there’s a more recent version of a document each time it’s requested. There may also be opportunities to widen the range of documents that can be viewed in a browser. But we’ll be interested in colleagues’ feedback. 

Platform API weeknote, 20 May 2020

What is it?

The platform API project is part of an effort to separate the end-user interfaces, business logic and data of the various databases used by Hackney Council to deliver services to residents. 

What have we done?

The goal for this sprint was to complete the first iteration of the Mosaic resident contact information platform API and to set up the data migration service. In line with the philosophy of “fail fast”, we picked this one deliberately as the data source was complex, but not too complex. It would also be a good test of our data migration strategy; our options were CDC or DMS with MS replication. CDC failed with our data source but tests with DMS with MS replication were promising. MS replication takes advantage of the inbuilt SQL replication feature and could be used because Mosaic’s tables have primary keys. 

We started the week finishing off the essential tasks to build our “foundations”, things that will be of value to all APIs such as our deployment pipelines and Terraform scripts. This is part of making everything we do easily reusable. We also planned the following:

  • Create the repo for the Mosaic data source
  • Set up the database in the cloud for the migrated data
  • Set up the infrastructure needed for the service
  • Create the API with two GET endpoints – one for listing results, and one for viewing records

All these job stories have been templated for future reuse and also for a consistent framework to be followed, as the work required for the other data sources will be pretty much the same. 

Also this week we started work on our roadmap. We probably should have done this earlier but it was picked up in our first retro as a way to bring clarity to what we are doing, and when we’ll be doing it. After Mosaic, we will do Academy and Universal Housing; then in the next quarter we’ll tackle Qlik first. Work on the Academy has started, as its database is unusual in Hackney, and a solid understanding of how it works and is replicated is needed before we can do anything with it. 

We didn’t quite manage to finish the Mosaic tasks – another day is needed – but we’ve learned a lot. The next sprint will be shorter due to the bank holiday, and we’ve planned accordingly. We’re still finding our pace, but we’re almost there. 

Amazon Connect weeknote, w/e 15 May 2020

What is it?

Amazon Connect is a new IVR/call handling system we’re trialling in our Neighbourhoods Contact Centre. It can automate certain types of calls, which should free up Agents to deal with more complex matters. We want to establish if residents will benefit from and trust an automated system for basic enquiries. 

What have we done?

It’s been a slightly quieter week, on the Hackney side at least. Our main focus has been on the payments compliance issue. Our first mitigation, to transfer the call to a colleague on the Puzzel system, will not work. Our supplier has devised a workable solution, but given the time and money that would require, we have agreed to not record calls during the pilot. This will be an interesting learning point for the evaluation: what difference will not recording make to the overall experience?

Our supplier, Mission Labs, has been making good progress on actually setting up the service. After the API was deployed last week we had to make a couple of minor tweaks to it so that it handled postcodes correctly. I’d like to thank Matt in the Development team for his flexibility here and for helping us out. Kameel has also started work on the infrastructure changes required to the firewall and call routing. 

We’ve also made progress on new(er) devices for some of our agents. With such a quick mobilisation to home working, there’s quite a mix of devices in use and some of our agents are using quite old laptops that won’t play well with the new service. Now that we have a proper policy and process in place for allocating devices, these very old machines can be swapped for a newer computer. Big thanks to Yvonne and Paul for agreeing this. 

Thinking has now turned to success criteria. We had some in outline, but they weren’t quite right. Although things like platform stability and uptime will be important, we want to focus more on strategic outcomes:

  • Customer experience
  • Fit with operational needs (reporting, ease of use)
  • Fit with strategic needs (cost, our tech principles, data strategy)
  • Long-term value (e.g. growing new skills within the council)

We’ve put some plans in place for the first two points, and a service assessment should tease out the answers for the second two. We’ll schedule this in around week 3 of the trial. 

Platform API weeknotes, 13 May 2020

What is it?

The platform API project is part of an effort to separate the end-user interfaces, business logic and data of the various databases used by Hackney Council to deliver services to residents. 

What have we done?

We’ve had our first “proper” sprint, though it was only four days due to the bank holiday. We still got a lot done in that time, however. Our focus remained on building our foundations, and following the previous sprint’s workshops we had a number of tasks lined up and waiting. We wanted to test what we had agreed on the Mosaic social care database. 

The first thing was for Ben R to update our base template repo to use .NET Core 3.1, as pretty much everything depended on this. Mirela set up Terraform for the base API; Terraform is an infrastructure-as-code tool which allows us to create our infrastructure quickly and easily in AWS. She’s also used Terraform to automate setting up data migration. 

The developers had some more short workshops and discussions to agree rules on linting and testing style, which then led to work to set that up as part of our continuous integration process. We agreed to add a couple of tasks coming out of these discussions to the sprint – normally this is frowned upon in Scrum, but my take on things is “what works for this team in their circumstances”. If there is work we didn’t foresee during planning, we should take it on if we can, especially if it’ll unblock other work. 

We didn’t manage to start work on migrating the Mosaic data. The system owners, entirely properly, asked for additional information on what we were doing, and it took a couple of days to agree access to the data and the approach. On the positive side, we’ve done a lot of good work on data protection up front which we can reuse with other data sources, and the business areas are really interested in what we’re doing. 

Early sprints can often feel slow, with not a lot of work done, but in just seven working days I really do feel we’ve done a hell of a lot – this will really set us up to move quickly in the coming weeks.