JLT World Risk Review - Rapid Innovation

Afghanistan Country Dashboard

We have recently delivered a project for Jardine Lloyd Thompson (JLT) to re-design and build their World Risk Review website. We're currently in the final hardening sprint, doing some bug fixing and UAT. We'll be able to talk more about the benefits in a case study, once the site has been live for a while and we can look at the analytics. In the mean-time I want to discuss some of the great bits of innovation (both tech and process) we have produced in delivering this project, which was just 8 weeks in total with only 6 weeks of development. 

What is World Risk Review?

World Risk Review is a country risk ratings modelling tool that JLT founded in 2006, providing corporations, banks and other organisations involved with international trade and investments with an assessment of short to medium term country risk. This allows users to build well informed strategies to manage political, security and economic risks. 

JLT is the only Insurance Broker to have invested in this capability in-house so they required a really modern website that would allow users of World Risk Review to have an intuitive and highly informative experience when consuming JLT's expert advice.

What did we do?

World Risk Review is made up of three key areas - peril ratings data for each country, key insights (articles, insights, reports and blogs) and news. Red Badger's role was to make these three areas easily accessible, engaging and informative. With more and more devices being used in the financial services sector, it would also need to work on tablet and mobile. So as well as being visually rich, the site would also need to be lightweight with regard to page size so that it remains speedy on mobile devices.

Heatmap
Heatmap

We designed the site using a visually rich set of dashboards to allow users to consume the data in a really intuitive way, compare different types of data and perform country comparisons. This is underpinned with easy navigation throughout the site via the dashboards and a flexible and fast search function.

How did we do it?

The site is effectively made up of two applications. The main website and a custom built admin console which consists of an analytics section as well as a custom built content management system (CMS) that provides the ability to do inline editing of content, preview of changes and deployment straight into the live environment.

I am not a techie, so I'll ask the developers of the site to produce some more technical blogs with more detail (They promise me these are to follow!). However, below is a brief outline of how we delivered the project.

The tech

For the visual dashboards we used D3.js. D3.js is a JavaScript library designed to bring data to life using HTML, SVG and CSS. It is based on web standards. It is efficient, flexible, lightweight (which means it is fast) and the animations and interactions look and feel beautiful. The front-end is then underpinned by a Node.js server application stack (Any JavaScript run outside of the browser is run on Node.js including the admin console, APIs and Livescript - see below) and a powerful search function built using Elasticsearch. We have built an incredibly fast search based on tags, allowing flexible filtering of data with some advanced features such as "did you mean" suggestions.

My co-founder Stuart is a huge fan of Component (read his blog) so the website is built using components in almost every way you could use them, from just packaging bits of JavaScript, through custom UI elements (such as the autocomplete tag field which we vastly improved - public repo can be found here. We also improved the datepicker component - public repo here) to whole pages being rendered by a hierarchy of components. All client side JavaScript we use in the website is packaged as components, including the visualisation code. The benefit of building a site in this way, is that it is ruthlessly efficient and every bit of code that is contained in the application has a use. You build lots of little tiny modules that are great at doing one thing and then you hook them all together.

We also switched from CoffeeScript to Livescript to compile our JavaScript by writing in a functional way. The developers on the project find it really nice to use. It has tons of little tools for the typical boring tasks you do all the time and also has a lot of functional programming features, including the amazing prelude-ls, which make it ideal for data processing, such as the static site generator (see below). 

Last year we re-built red-badger.com as a static site. We loved the results so decided to follow a similar technical architecture for World Risk Review. The static site generation architecture deploys the site at the time that content is updated so that when users access the site, they are accessing a very simple static page rather than requesting content from a database for each action. The result is a website that is more secure and can serve pages much faster than traditional Content Management Systems (such as Drupal). The site is deployed to an Amazon S3 bucket and distributed via Cloudfront to 51 edge locations around the globe. Originally we were using Docpad as our static site generator (as we had for red-badger.com) but we found it started to really slow us down so we built our own static site generator which brought down the time it takes to generate the HTML from the source markdown documents and Jade layouts from about 90 to about 6 seconds . This allowed us to work much faster and also enabled us to build a CMS where you could preview your changes almost in real-time. Having tested the application around the globe, it is incredibly fast wherever you are, with as little as 10 milliseconds and no more than 300 milliseconds to the first byte.

We have also set-up continuous delivery using Travis CI and Ansible. This is incredibly important for how we develop software but it also underpins how we have architected the CMS. Using continuous delivery allowed us to commit changes into a staging environment many times a day and made them available to test immediately. In the production environment, once the project is live, the content editor will be able to deploy their changes in the CMS straight into the live environment. The custom CMS is built on Git. An administrator can view the site as if they are a user, but can edit any element on the page, save it and then review comprehensive line-by-line changes to each document (or add new documents such as news items). Once they are happy with the changes, a publish button will commit to Git and will deploy into live. It allows multiple users to edit the site at the same time without stepping on each other's toes and merges their changes in a smart way, so content management is not a race of who saves first anymore. In order to build in-line editing we were looking at a number of options such as CreateJS. However, we again decided to build our own editing tool using Javascript components for YAML and Front-matter.

The final piece of the puzzle and by no means the least important, was to build in analytics. Using the power of Elasticsearch, we built a tag based analytics tool that allows JLT to monitor user behaviour on the site. They can add custom tags to each user (such as "watch list"), filter, sort and search. This gives JLT a quantitative view of customers behaviour to allow them to adapt their future strategy around what their customers want.

The process

Given that we had only 8 weeks to deliver the project of which 6 weeks were for development, we decided to use Kanban as the methodology of choice, reducing as much friction in process as possible and allowing the developers to do exactly that - develop. The backlog was tightly managed by Sinem (the project manager) and the product owner from JLT who was deployed full-time to sit with us in our office every day. I cannot stress how important it was having the product owner integrated into the team full-time. We managed user stories on a Kanban Board and although physical boards are great, the developers managed all tasks in Github. This reduced duplication of effort, increasing productivity. Stand-ups each morning were held around the Kanban board, talking about what we had been doing at story level and we were focussed on getting stories through to delivery as soon as possible so used WIP limits to streamline the process.

To ensure quality control, we used Github flow to manage the process of building new features, ensuring that no piece of code is deployed without first going through code review by a 2nd pair of eyes. There are some simple rules to Github Flow: 1) Anything in the master branch is deployable. 2) To create something new, you create a new branch off of master. 3) You continue to commit to that branch locally until your feature is complete. 4) When you think your feature is complete, you raise a pull request. 5) Another developer then reviews your code and upon sign-off it can be merged to master. 6) Continuous Deployment then deploys your changes immediately.

When delivering a project at this speed, it is paramount that your features are tested properly. To do this, we integrate a tester into the team and get them to test as soon as a feature is deployed. In the past we have used separate tools such as Youtrack as our bug management system. However, in this project, we switched to Github issues. Having one central place for the developers to see all features and bugs together in Github has most certainly helped productivity of the team.

Summary

In just 6 weeks of development we achieved an incredible amount. We had an integrated team of Project Management, UX, Design, Dev and Test, all dependent on constant communication to get the job done. We built an exceptionally well designed, useable site on a really innovative tech stack. The use of Kanban, Github Flow and Github Issues proved to be an incredibly productive way to deliver the project. It was a very intense environment of rapid delivery but was lots of fun too. JLT were a great client not just in allowing us to be innovative with our tech and process, but also in the efforts they put in to make this collaborative. We couldn't have delivered so quickly without their constant involvement.

As always, there is room for improvement in our process and the tech team are looking forward to new technology emerging such as those contained in the Web Components spec. Our project retrospective has highlighted some areas for improvement and we will continue to iterate our process, always pushing to try and provide our clients with better value. We have loads of great ideas about how the World Risk Review site can be improved in future phases but after 8 weeks, it is currently in a great place to deliver a far improved experience for both JLT's customers and their admin staff.