G-Cloud 8 has just opened for supplier applications on the Digital Marketplace. From a supplier’s point of view the application process is much the same as previous frameworks but behind the scenes a huge amount of technical change has taken place.
Each buying framework is a new agreement between government and suppliers. For G-Cloud 5 and earlier framework iterations, the Digital Marketplace didn’t handle supplier applications at all. Suppliers had to use 2 separate systems to complete their application: they had to submit their supplier declaration through an e-Sourcing tool operated by the Crown Commercial Service, and there was a separate Service Submission Portal (SSP) where suppliers gave details of their services. The Digital Marketplace simply provided a searchable catalogue of supplier services that were accepted onto the framework.
In this post I'll explain how, over the course of a number of iterations, we’ve evolved the Digital Marketplace from a simple catalogue of services into a platform that can handle supplier applications and service details for multiple frameworks. There is no longer a separate e-Sourcing tool or SSP.
These changes meant the new G-Cloud 8 framework was relatively easy to roll out, taking 2 developers less than a couple of weeks to get up and running.
G-Cloud 6: building our own Service Submission Portal
There was already a plan in place to bring service submissions into the Digital Marketplace when I started work on the project as a developer in September 2014. We were up against an incredibly tight deadline with only 6 weeks to build our own version of the SSP from scratch before G-Cloud 6 opened.
Following some exploratory work we decided it was not feasible in the tight timeframe we had to build a full-blown submissions tool within the existing Grails web application we were using. Instead, we built a completely separate web application - our very own Service Submission Portal - using the Java Play framework that runs on Google’s App Engine platform.
Our new SSP was well integrated with the look and feel of the existing Digital Marketplace site to give the appearance that it was all one thing (eg it used a shared login), but it was still a ‘portal’ in all intents and purposes.
The G-Cloud 6 SSP was very much a throwaway piece of software. It was designed and developed solely for G-Cloud 6 service submissions and we knew it would be turned on for just 45 days while the framework was open for applications. After that we’d export the data and turn the SSP off, with no plans to try and use it again in future. The tight deadline meant there was no scope to try to make it a general-purpose tool.
However, the SSP had one feature that marked the first step towards us taking a ‘platform’ approach. All of the question content (ie the exact wording of the questions to suppliers) was held in a completely separate repository to the code, and pulled into the application at build time.
These content files are in YAML format with embedded Markdown for longer sections of text. We created this separate repository to allow content designers and other non-developer product people to edit the wording of the supplier questions without needing to get developers involved. Adding new questions or changing the type of response options still required developer time (to implement changes in the code), but editing the words could be done independently.
G-Cloud 7: ‘de-portalising’ service submissions
In the 9 months between the G-Cloud 6 application period closing and G-Cloud 7 application period opening we completely rebuilt the Digital Marketplace. We gradually replaced our monolithic Grails application written in Groovy running on Skyscape infrastructure with a system of five Flask applications written in Python and running on AWS infrastructure.
This new system fully integrated the service submission process as part of the Digital Marketplace proper. This time it was built with generalisation and re-use in mind, while keeping the separate content repository for content designers.
We also brought the supplier declaration part of the application process into the Digital Marketplace. We carried out user research and re-wrote the supplier declaration questions from the e-Sourcing tool into plainer English before adding them to our content repository. For the first time the entire supplier application could be done in one place.
As far as possible we made the main Digital Marketplace web applications “framework agnostic” so that any information specific to a particular framework would be stored in its associated content repository. The Marketplace applications would show pages based on general rules rather than having knowledge and logic about individual frameworks embedded in them.
Digital Outcomes and Specialists: testing the limits
The Digital Outcomes and Specialists framework was the first framework other than G-Cloud we had to consider. This had the potential to test the limits of what we were trying to achieve (in creating a platform) because in some respects the service applications were very different from G-Cloud.
It turned out we had to do a lot more unpicking of G-Cloud from our code than we had expected, or perhaps hoped. Generalising service submissions for the Digital Outcomes and Specialists framework brought the Digital Marketplace a long way from just “G-Cloud online” towards “procurement frameworks online”.
G-Cloud 8: a platform at last?
As the end of March approached I explored getting the first version of the G-Cloud 8 application process up and running locally. I wanted an idea of how much developer time we’d need to get G-Cloud 8 open on 17 May. The results were promising. In just a few hours I was able to copy and transform the required service and declaration question content from G-Cloud 7 to G-Cloud 8, set up the framework information in my database, start an application, submit some dummy services and identify a few bugs that we’d need to fix (mainly where things had subtly changed for Digital Outcomes and Specialists but didn’t quite work for G-Cloud 8).
After discussing these results with the team we allocated 2 developers to spend a couple of weeks getting G-Cloud 8 up and running. In this time, they set up the framework in all our production environments, updated the service and declaration questions, fixed several validation bugs, improved our administration application to support G-Cloud 8 and set up a suite of automated functional tests (these run continuously to check that submissions are functioning as they should).
In the end the developers didn’t even need the full 2 weeks. It felt like everything just worked as it should do “out of the box”. This may be partly due to the fact that G-Cloud 8 is so similar to previous G-Cloud iterations, but it really does feel like the Digital Marketplace is on its way to becoming a platform, where simply plugging in the right content gives us a framework submission system.
While it took our development team 9 months to completely re-platform the Digital Marketplace and open G-Cloud 7 submissions, and a further 3 (very busy!) months to generalise the platform for Digital Outcomes and Specialists, the hard work is now definitely paying off.
Sign up now for email updates from this blog or subscribe to the feed.
If this sounds like a good place to work, take a look at Working for GDS - we're usually in search of talented people to come and join the team.
