EVENTGet 50% off your ticket to MongoDB.local NYC on May 2. Use code Web50! Learn more >

Digital Transformation in the UK Government Transcript

Good afternoon, everyone. Thank you for joining us again in the business track. We've had a great morning talking about transformation. We just heard about a very detailed journey of Ticketmaster. We've got three great presentations for the rest of the day. So hang tough. I know it's hard in the afternoon.

But this one is particularly exciting. Mr. James Stewart comes to us from the UK Digital Office in the UK government. He is the Director of Technical Engineering and has really done extensive research into architecture and moving the government from-- 10 years ago, when everything was cut-and-dry, off-the-shelf kind of packages, to moving to open source.

And what open source means for him is coding in the open. He's done such a good job at that gov.uk has been awarded, and he is sharing some of those findings around the world. And we here get to hear what that transformation looks like. I'm really pleased to have James Stewart with us today.

We'll have questions at the end. Please turn off your phone if they're on. Please download the app to make sure you can do survey questions at the end. James, thank you so much for joining us today.

OK. Thanks, Rebecca. So, a previous speaker was talking about selling tickets for the London Olympics. I can't claim to have ever sold tickets for Olympics, but I do you come from about half a mile from the London 2012 site, which means I have a fantastic new swimming pool.

So, I'm James. I have a sort of fancy title within an enormous organization, which is the UK government. But my background is working with small, agile teams focused on making products for the web. I'm a technologist. I love trying new things.

But these days, a lot of my job is bringing that kind of enthusiasm, and that kind of energy, into an organization that really isn't known for behaving that way, and kind of bridging some of the technical decisions and the enthusiasm of our tech team, and the concerns of people involved in a lot of governance, and trying to make sure that we're having good conversations around that.

So, I'm from the Government Digital Service. We're a team of designers, developers, operations people, policy, commercial-- all the sorts of skills that you need to run and build digital services. And we're very committed to working in a very collaborative way.

We're part of the cabinet office, which sits at the center of the British government. It's one of 24 departments. And it exists to coordinate the work of those departments, 300 government agencies, and about 412,000 staff. My talk is very much going to focus on what we're doing within a government context, but I think that most of what we're doing applies much more widely.

So, I'm going to talk about bringing Mongo into government, and the sort of transformation that exists within. It's something that we see in many, many large organizations-- people who have a lot of legacy technology, complicated decision making structures, and so on.

But to give you a little bit of background to where we came from and what we're doing. We came into existence because of a letter. It was a letter written by a woman called Martha Lane Fox, who was a leading UK internet entrepreneur, but also what we call our digital champion. She had responsibility for getting more of the population online, enabling them to take advantage of the opportunities that the internet offered them.

And she was asked by the incoming governments in 2010 to review one of the main government websites. But Martha didn't really feel like that was the right focus. And she took a step back, and talked about the opportunity for government to deliver its services better in the modern age. Making use of new technology and new communication channels, we could drive a huge amount of efficiency, but more importantly, we could provide much better public services.

She sent this letter-- it was four pages, rather than the usual lengthy government report-- and this gave us a plan. Martha and this gentleman-- who is Francis Maude, the minister for the capital office. He's our political master-- agreed on four actions.

We needed to create the Government Digital Service. That was a digital center at the heart of government that knew more than just how to buy technology. We knew how to build services. We focused on doing that in a user-centered way.

We needed to fix publishing, because we needed to bring together government information in a way that was much more comprehensible to people. We didn't assume that they understood government before they came to interact with it.

We needed to fix transactions, by which we mean the kinds of services that people access, like paying a tax or renewing a driving license. And some of those were already online. Some of them were reasonably good experiences. They were wildly inconsistent and very difficult to change.

And we needed to go wholesale. What that means is a recognition that we can't do all of this ourselves as a small team at the center of government. We need to open up dates for our APIs, so that people outside of government can build innovative products around what we're doing. We need to transform the organization as a whole so that this is how government starts to deliver its services to citizens.

We've been doing that for about three years, and it's grown to involve a huge amount of detail. Publishing leads you into search. Working on transactions leads you into identity. There's a lot of metrics. There's just running a business that goes with that. In order to focus what we do, we've distilled it down to six main programs.

First of these is called gov.uk. That's our answer to that challenge to fix publishing. We didn't coming in how many websites the British government had. Nobody knew. There were hundreds and hundreds, probably thousands. And if that was difficult for people in government to understand and catalog, it was enormously confusing for our citizens.

So, we needed to reset the way that we approached this. We called that single domain. It is the platform for everything, which means it's the place where people start and end all of their interactions with government online. And we didn't just consolidate websites. We took a step back and we looked at, what are the user needs people have of government? What are the things that they're looking for, what are the things we're required to publish? And we started again from that. And then did a huge amount of work redirecting all the URLs from the old sites so that nobody's experience of the web was broken.

At the moment, gov.uk has around seven million visitors a week, but it's growing very rapidly as we finish the process of migrating everybody on. There are about 600 people who regularly publish through the tools that we've built, and there are 5,000 more publishers coming as we start to expand this out.

And we built it in a very iterative way. We have a DevOps approach to things, a lot of continuous deployment, and that means that in that first year, we've had around 2,000 code releases. Which, if you're thinking in a world that operates on enterprise release cycles where six to 18 months is the norm for shipping a new feature, that's a pretty radical change.

I've just mentioned that we didn't know how many websites we had. Perhaps more fundamentally, we didn't know how many services we offered, at least not from the perspective of citizens and visitors and businesses who needed to access our services. So, measurement and analytics have become a really important part of what we do.

We started out just by trying to catalog what do we have, how much does it cost us to run them, what's common between those services, who operates them, and that kind of thing. Each time we counted, we'd find another 50 or so services. The current count is around 760. But with that, we could start to build dashboards that exposed across government and to the general public a real-time understanding of how those services are performing.

And it lets us really focus in, again, on what we call user needs. We can define a need. We can point to the services that are meant to meet that need, and we can show whether we're succeeding. And that's particularly important in a context like government, which doesn't have the same commercial drivers that you might find in other places.

We need to define metrics of success that we're shooting for, if we want to understand how we make these services better. We can't just look at, has the check-out rate gone up or down when we shipped new features, as you might on an e-commerce site. But we can look at, are people receiving services quickly and efficiently?

We're working on identity. Britain doesn't have a national identity card scheme, unlike some other countries. There's no consistent identifier for the population. There's actually a lot of popular resistance to creating such a scheme. But in order for people to use government services, they need to be able to make some assertions about where they live, whether they're entitled to manage certain tax affairs, and that kind of thing. And we wanted to provide that in a consistent way that made people feel secure.

So, we've been working with a series of the third parties-- the Post Office, telecoms companies, and a few others-- who already know some of that information about people to build a trusted system that can make assertions on people's behalf. It's an approach that's made a big impact around the world, even though at the moment it's still just in a private preview-testing phase. Over the course of this year we're going to be rolling that out, and that will be how around 45 million users identify themselves to the British government.

To pull all of this together, we needed to really look again at how we do technology, which is a hugely broad theme. For us, it's about how we deliver those services, but it's also about the 6.7 billion pounds we spend a year on keeping the lights on, and providing tools for our 412,000 staff.

We've made some very clear statements that the era of big IT is over. We're no longer going to say, here is a department. It needs IT. That is a single contract that we outsource. Instead, we're breaking that down. We're understanding the services that we have, and where we're going to get value, and we're commissioning services that we need.

We're trying to provide tools for civil servants that are at least as good as those they have at home. No more laptops that take 10 minutes to boot. No more layer upon layer of security that's simply theater. Instead, lightweight, flexible solutions. And that lets us really start to drive in an adaptive approach to providing services for citizens.

To do all that, you need people. And while there are many, many talented public servants in the UK, as there are around the world, there aren't very many people who really have the expertise to drive the sort of change we're talking about. So, we've been working really hard at bringing in new senior leaders at board level within all organizations and government who get digital services. They know how to start understanding their Users. They know how technology can help them serve them. And we're also then providing training for people lower down in those organizations, about how do you operate services? What should your concerns be? How do you measure whether you're doing a good job? And just training all of the grassroots stuff, in how can new collaboration tools help them do their jobs better?

And an awful lot of that comes together in what we call our transformation program. And that's where we've picked 25 of the most important transactions in government, and we're working with eight different departments across government who deliver those to reinvent them top to bottom, to revisit what the user needs are that are driving them, and to think about how we're going to build out the right teams and the right technology that we can make them significantly better, but, more importantly, continue to improve them.

Some examples of those. Until two weeks ago, to register to vote in the UK, you would get a piece of paper through your door which asked the head of household to decide who in that house was eligible to vote, and to send it back. It's kind of amazing that we had the level of suffrage that we did, given that was our process.

Two weeks ago, the law changed. Every citizen is responsible for registering themselves to vote. That's a big step forward for how we do democracy, but it actually introduced a challenge. And there was a risk that we might see a drop off in voter numbers, because it's a bit more work for quite a lot of people.

So, it's been really important that we provide a good online system for doing that. When we did that, we could also start matching up with some of the government databases in an appropriately anonymized to give confidence scores that reduced the risks of fraud. Do we have other records of this person living at this address? And so on.

Looking at student finance. When somebody is going to university, do they know what support they can have? Do they understand what they need to do in order to receive it? Do they understand what debt repayment obligations they're going to have?

And we're looking at how people understand their taxes and how they pay them online. We already had an online system for doing this, but the way that the data works behind the scenes was far from efficient. You had to state how much bank interest you'd received, even though the banks were also having to state that to the organization that managers this.

And it's an annual process to understand your taxes, but understanding your cash flows and behaving responsibly, you want something a little bit more responsive to your changing circumstances, especially in a context where more and more people are working multiple jobs. So, we'll have a portfolio of work, which makes the taxes more complicated, but shouldn't have to.

So, that work is spread out all across the UK, working on 25 services with eight different departments, spread from Plymouth right down in the southwest up to Glasgow. That means that we can really tap into expertise that exists all over the country, as well as people outside at times.

And one of the most important things there is that it's also allowed us to do some work about improving the local supply chain for lots of these services. So, instead of being driven by a few companies based usually around London or on the south coast, we can start to look at how can they build teams in these places using a mix of their own staff and suppliers in a much more interesting way.

And to summarize some of that-- from a technology point of view, we're moving from outsourcing everything and some top-down mandates about technology stacks to empowered, capable teams who are focused on great services with a library patterns to build on, the right skills to make good choices, and access to the right suppliers to help out.

And that lets us take the responsibility for meeting user needs. There's been an opinion that you can outsource that responsibility and you can outsource the risks. But, as a government, that's not an option. And for any company with customers, that's probably not an option either. You're the people responsible to your customers.

For us, it's also let us start to do a lot more to make a level playing field for open source and proprietary software, because as we start to understand at a more granular level what we need, we can have much more informed conversations about that, and driven an approach where we get better understanding the cost of exit as well as the cost of entry for every contract. It also lets us have a much more diverse tech stack and do a lot more experimenting, which is a lot more fun.

We're very fond of slogans. One of them is, show the thing. So, let's talk about some of our projects in a bit more detail, and come back to gov.uk. Gov.uk was kind of a dream project for a technologist, because we got to start from a blank sheet of paper. We knew that we weren't simply going to pick an off-the-shelf content management system, and we knew that we weren't going to just migrate all of the information that existed on other websites. So, we were able to think a lot more about, how were we going to meet people's needs?

And we settled on this phrase of tools over content. It used to be that if you want to understand, say, maternity leave allowance and benefits that come with that, you had to read seven different pages of information, figure out how they applied to your situation, and do an awful lot of calculating in your own head. You can ask people three or four questions, and you can tell them the answer. And if you've got the right team in place, that's what you should do. So, we were able to start building that way.

And things were going fairly well, but as we begin to build out the system, we realized a kind of reflex action to reach for a relational database that we were all familiar with maybe hadn't been the best decision. As we looked at how we would versioning content, how we were managing some of the data, we were starting to tie ourselves in knots. And so we thought that, perhaps, there might be a better way.

And a few of us had been playing with Mongo and a number of other databases, and it felt like Mongo would be the right fit. But we're working in government. And usually the way that you might explore that sort of option would be to write a paper, make a business case. If you really unlucky, you go through the full business case process of a strategic outline business case, and an outline business case, and a full business case, security assurance, governance boards, and you might as well not bother. But I'm here today, and that probably suggests we got a different approach. And we did.

We downloaded Mongo. We saw how we'd be able to move things over. We realized that it would let us move a lot more quickly and it simplified our code enormously, and so the team got on with that. And a little while later I had some conversations with the security assurance people, and we did all the load testing that we needed. We could do an ongoing assurance process around this, but we didn't let it get in the way of the thing that let our team operate quickly.

But it wasn't without challenges, the biggest of which was that for our initial small core team, they made the jump quite easily. But as we grew, we brought in a lot of developers who weren't quite so comfortable operating with a new model and a new paradigm. And that not only slowed us down, but it hurt morale a little bit, as people tried to make Mongo do things that it doesn't naturally do, or in ways that it doesn't naturally do, and thought that was the fault either of me, because I've made those decisions-- which wasn't very nice for me-- or of the product.

The answer to that was training. We worked with Mongo. We brought in training. We had some of our more experienced people help that team. And we very deliberately also did the same training for our developers and for our operations people. Because we wanted to operate in a DevOps world, the whole team needs to understand the whole cycle of using something.

So the training both made people a lot more comfortable and a lot more confident, to improve morale, and it improved our product. But it actually knit the team together better, which was really exciting to see.

We also, early on, made a bit of a design mistake, which was to look at the content of gov.uk, split it into two pieces, and say, there's mainstream information. That is, things that you need as a small business owner, as a citizen, as a visitor, but without much specialist knowledge. And there was corporate information. So, that's the workings of government, its speeches, it's who are the government ministers, it's what are the policies?

And we decided that, for the purposes of speed, we'd approach those two things as quite separate products. And on the corporate side, that data did look a bit more relational, so they picked MySQL for that. And it worked out reasonably well, until we decided and discovered that that division was artificial, and that there are plenty of specialists who actually need a bit of both types of information. We needed good ways of joining it up.

And while it was quite important for us to capture a lot that relational information in the back end for future inquiries, when you're publishing, you're putting out static pages and they're flat. And that we didn't have to have a single database, a single model driving this whole thing end-to-end. We just needed one that made some sense.

So at the moment, we're in the process of putting all of that closer together, flattening out the information when we come to publish it, which means that we can manage the whole thing through Mongo and we can more easily query right across all the data.

We also used Ruby extensively. And those of you who may have used Ruby as a programming language might have had some similar dependency management challenges that we've had. We were operating on an old version of Ruby, which had an old version of some particular Mongo drivers, which were tied to an old version of Mongo. And the way we'd set up our configuration management made it hard to upgrade Ruby, which locked us into all the rest of that.

That was really a challenge around our own prioritization. We've since built out much better tools for operating every piece of that stack. But it was quite a challenge early on, particularly as we looked at all the exciting new features that we couldn't use.

But perhaps the challenge that was most surprising to me was the way that our actions influenced other bits of government. And we started looking around at some other projects in our government, and saw that they were beginning to adopt Mongo. And that was exciting. That was fantastic. We like Mongo.

We were glad to see them using it, until we realized that it didn't fit what they were doing at all. Because there'd been a lot of attention on us and on the decisions we were making, other people thought that decisions we were making had to apply to them as well. What we really want is teams to be making sensible decisions around the services that they offer.

So I found myself in the bizarre situation of having to go and tell people that perhaps they shouldn't be using this tool that I really liked, or just challenging them on why they made those decisions? How were they testing them? And in some cases, they learned how to use Mongo properly, and it did work for them. In others, they moved off. That took us a better situation. But it was quite a surprise to find that sort of effect of our behavior.

To pick another example, we're doing some work with an organization called DVLA, which stands for the Driving and Vehicle Licensing Authority, or the Driving and Vehicle Licensing Agency, depending on who you ask. But as the name suggests, they're responsible for managing information about drivers and about vehicles, about driver's licenses, and number plates on cars. That means that they have 45 million driver's licenses, and they have a huge amount of technology.

Most of what they have was procured in huge combined lots to try and solve all of their problems in one go. And over the years, a few attempts would be made to consolidate and simplify what they have, but often business conditions have meant that those effects have failed, leaving behind even more tech, and adding even more complexity.

This picture is of my boss, a guy called Mike Bracken, who's Executive Director of Digital for the UK government, looking at a very, very simplified, very high level picture of the organization's architecture, and despairing. [LAUGHTER]

So, we went in, and we started with a very simple challenge. We said, as a driver in the UK, I should be able to see my driving record as it's held by the DVLA, so that I can understand what I'm allowed to drive, and if I perhaps have been speeding in the past, and I've got some tickets and some points on my license, and I'll know when they'll expire so I'll have a clean driver's license again. And as an insurance company, I should have access to some of that information so that I can make the right risk-based decisions about whether to grant somebody insurance and how much to charge them.

It wasn't practical to build those services and plug them directly into that legacy estate, because we're optimizing for the ability to make rapid changes, to test the way we think this will work with our users, and to keep going. And if we'd gone directly into the legacy estates, we would've been stuck here in enterprise release cycles, and we would've been able to move maybe once every six months.

Thankfully for us, it turned out that the data isn't so volatile. It doesn't change so regularly that we had to have real-time updates. Instead, we could rely on some batch processes that already existed to get the data out and begin to construct a model around it.

A driver's license is a relatively simple document. It's got your name, and it's got your address, and it's got some information about what types of vehicles you're licensed to drive. And so on the surface, it looked very, very simple.

And so we dug a little bit further into the history. And in the UK, you don't have to renew your driving license. Once you have one, it's good until you reach a certain age, and then you have to start having eye tests and other things. But that means that we have a lot of historic driving licenses. And it turns out that every three to five years, the rules around what data's captured with the driving license application change, or the categorization of vehicles changes. And so the group of vehicles that applied six years ago is different from the group of vehicles that we have today.

And the way that have been handled was to overload the meaning of fields in the existing database, because schema migrations were expensive and complicated. And so there was some really gnarly application-level logic that would take a record, look at when it was updated, interpret what it meant at that point in time, map it to what that would mean now. It was just a bit of a nightmare to look at and use.

We quite like explicit data models. So, we had some things that looked like documents, and we needed quite a bit of flexibility in our schemas. And given where we are today, you can probably guess where I was going with that. But here there was some pushback. With gov.uk, we got a huge amount cover, we were able to just run on through. People were very comfortable with what they had, and were worried that we were losing some discipline. But by explaining the clarity of the new model we were suggesting, by showing that impending contract changes meant that all that familiar comfortable stuff was going away, and by very quickly being able to show the thing working and show how we were going to responsibly manage it, we were most able to win that argument. But in fact, we then also had new management, and that helped a lot.

And we're now in a position where we have a model that we're comfortable with, we have services that we can update very quickly, and we can begin to decouple all the things that relied on that legacy estate and push them to the new one. And we have a chance to make things better. And that data is all legal records.

And most of our work until now has been just about giving us the infrastructure we need. But we can start to look at interesting things like how we use to manage title deeds, where there were special knots that would show if an approved member of staff had looked at these title deeds for properties. It was important that you knew if they'd been tampered with. Once we have that simplified IT estate in DVLA, we can start looking for modern equivalents of that sort of tamper-resistant storage of data, and build ourselves much more resilient, much more reliable systems.

So now, we're at a point where we're hitting the real challenge that any transformation project has-- how do you make the changes stick? So we've been pulling a lot of our work today together in what we call the government architecture function. Government's full of architects, but it rarely feels like we have a clear, flexible architecture, as that diagram earlier showed.

We're starting out by trying to embed some solid principles. We need to remind people that tech is there to do work for your users, not for its own sake. We need to build a culture where people will regularly be trying new toys, trying new tech, trying exciting new ideas, but know how they're going to test whether those are seriously going to work for them. And we really need to focus on the capability of our teams.

But beyond that, you need a vision and a real drive for transformation. In that case, it's the huge potential that comes with building digital government. That's about invention, not repair.

And we found that while we need to move away from a lot of the legacy technology, for the new world, painting old rolling stock doesn't help us. We need things a bit more like this. We need modern technology that lets us respond to our users' needs.

We're calling that software as a public service, software that responds to the needs of the general public, software that lets us respond to the fact that those needs change. And it's a really exciting new world. Thank you. [APPLAUSE]

Thank you, James. That was truly a transformational discussion and transformation. 2,000 code releases in a year-- does anybody match that? 2,000 code releases in a year. That's amazing. And show the thing. Thank you for showing it as well. See, we don't really speak British. We speak American here. Anybody have questions for James?

Hi James. Mike Anderson of [INAUDIBLE] London. Considering the fact that 30% of all internet traffic comes from mobility, how is gov.uk embracing this, and what opportunity's it brought? Sorry, comes from--?

Mobility. So, mobile devices.

Yes. As the front end of gov.uk is all built using responsive web design techniques, somewhere approaching 50% of our traffic is from mobile and tablets, and that's growing really fast. So, everything works reasonably well on those devices. And when we assess new services, we do a lot of testing on multiple devices.

Responsive design helps a huge amount with that. It's not always enough, because you also have to think about the context in which people are using services. As a baseline, everything responds to the size of the device that we're using, and then we start asking questions about are people more likely to use this service on the go? If so, do you want to design it slightly differently?

More questions? So which is the next project you're going to tackle? The 25 of the transformations--

So, the 25 rule running in parallel, and that program wraps up early next year. So, the focus has to remain on those for the time being.

Out of those, we're seeing all sorts of things, particularly common patterns around, things that were repeated over and over. And for that new architecture function, a lot of the focus is going to be on, so, we do payments in lots of different ways. Perhaps we should start thinking about whether we can consolidate some of that.

And think about how we-- so, you've got the services in terms of how users think about services they receive. You've then got services in terms of how architects think about them, and there's loads of work that we can do there. But also those 25 exemplar projects-- 25 out of 766 public services. So there's no shortage of work.

Any last questions?

Chris B of MongoDB. James, you wound up with software as a public service. Could you expand on that a little bit? What does that mean in terms of your mission?

Yeah. So that's where a lot of our thinking is at the moment. It's really starting to bring people into thinking-- aligning thinking. Alignment's one of the big things that we constantly have to talk about. We've been in a world where there's an awful lot of saying, I have customers, therefore I need CRM. I have content, therefore I need a content management system. And that kind of leading from a problem into a particular technical solution.

And we want to push people back towards saying, we have users and they have needs. In our case, that's needs of public services. The software exists to support that. It's not good in and of itself.

Thank you.

OK, thank you. Thanks, James. [APPLAUSE]

We have two more equally exciting talks coming up. In 10 minutes from now, we have Verizon coming to share about their disruptive use of MongoDB. And then we have the Gap right after that. So, please come back. Don't forget to fill out your surveys. Your surveys get you a drawing into an Xbox as a prize, so don't forget to do the surveys. If you don't know how to download the app to do that, please come see me afterwards. See you in 10 minutes.