Carl Molyneux

Hi, everyone. Thanks for coming to this talk. Hope you're all having a great time at the DevOps Summit so far. So this is our story about how we've moved through DevOps at the United Kingdom Hydrographic Office so far. We know we've got a ways to go, but this is our story so far and some of the challenges that we've had as part of that. So first of all, hello.

My name's Carl Molyneux, and I'm the lead application lifecycle management engineer at the United Kingdom Hydrographic Office. I've got a background in software engineering and worked in a few industries before I joined the Hydrographic Office. And I'm excited about enabling teams to deliver quality digital products. I live in the southwest with my wife and two kids, and we spend most of our free time exploring the wild outdoors.

If you want to get in touch with me, then I'll have LinkedIn and Twitter on the final slide.

01Setting the Scene: UKHO and Its Data

So first of all, I want to talk about what is the UKHO, what is the Hydrographic Office, what do we do, and why is DevOps an important part of that. So we provide marine geospatial data to inform maritime decisions in navigation, safety, security, and development globally. We're a trading fund of the Ministry of Defence, so that basically means we run at

no cost to the taxpayer, and we make our own money from our commercial arm. We're over 220 years old, so we have years and years of history, and a lot of that in itself is innovative, so we've been able to change with the times. We're about 850 people. 200 of these are in change, either continuous improvement around the business or in our digital delivery teams. In terms of the company drive, it's quite interesting blend.

We're fulfilling the UK's government obligation to provide hydrographic products and services in the UK waters for safety of life at sea. We're also supporting the government's national security strategy, so we work closely with the Royal Navy and other defense customers. And we provide specialist advice to the government maritime coastguard agency and the public, and we represent the UK worldwide in hydrography.

And all of this means we hold a massive amount of data from seabed to surface, so tidal height, streams, navigational data, hazards, light structures, port information, climate conditions, that sort of thing.

02From Paper Charts to Marine Geospatial Data Services

So where have we come from? So this is where we've come from. Literally, copper plates hand engraved by cartographers, printed through manual print presses. Obviously, it looks a bit different today. So we now have fully automated print lines and folding, and I'm told that printing is easy, but folding is very difficult, especially the Japanese, because they fold everything backwards.

So we've moved with the times with our business, and we now provide our products, which were traditionally on paper, through digital means. One of the big challenges we have is a lot of our data is not inherently digital, so it's not necessarily structured. So where are we going? For the foreseeable future, we will be providing our current customers with products in the way that we currently

do. So we will have some paper, and we will deliver some of those products that are analog products in a digital fashion. We're a member of the Geospatial Commission for the government. So that's us, the British Geological Society, the Coal Authority, the HM Land Registry, Ordnance Survey, and Valuation Agency. So we've been put together to see how we can

define a geospatial strategy in the UK. We're also moving towards being a marine geospatial information agency above and beyond our current hydrographic business. So the blue economy is expected to be worth around $3 trillion by 2030. So there's a lot more market than just shipping and what we currently do at the moment. So let's say, for example, you want to build a wind farm in the sea or tidal energy,

that sort of thing, we've already got data which will help you do that. So those are new markets for us to move into as a marine geospatial information agency. We will begin to provide more and more data, not in prepackaged products like we currently do, but in Data as a Service approach. So these are new areas of the market for us, and there are much younger, more malleable competitors in these markets. So as a business, we need to change how we're doing things.

So this is why we're looking at DevOps. We need to modernize our business approach in the markets that we're moving into.

03What DevOps Means to UKHO

So what is DevOps to the UKHO? So I'm going to steal Amazon's definition rather than reinvent the wheel. So DevOps is the combination of cultural philosophies, practices, and tools that increase an organization's ability to deliver. It enables organizations to better serve their customers and compete more effectively in the market. So there's a couple of key points there for me. First of all, it increases the organization's ability to deliver, not just IT within an organization. And the second one is to deliver better

serve their customers and users. So that's why we want to take a more DevOps approach. So we're undergoing a digital transformation at the moment. The core of our business is moving more towards digital. So we need to compete in these new markets that we're moving into whilst we're maintaining our existing market share and our high standards in safety. So we need to be able to adapt quickly and smoothly.

We need to be resilient in our current markets as well as the new markets we're moving into. We need to store our data better. So we need to store it in formats where we can exploit it for its value and ensure that our customers are getting value from it. And we need to build our systems more intelligently, more incrementally to deliver value earlier to our customers. So I would say this is very much a journey for us. We've made big changes to our business in the last three years around this, but

we've got loads to do, and it's great to come to something like this and hear about companies that may be a couple of years ahead of us and get some ideas from that. So we've got the Auto Trader guys in the front row who are probably a little bit further on than us. So it's been great to hear their stories as well.

04People and Culture Challenges

So I'm going to talk through some of the challenges we've had, what we've done about them, and the outcomes that we've seen from the actions that we've taken. I'm going to break it up into the traditional people and culture, processes, and tools that we see with DevOps. So I went to a conference recently and heard this phrase, "People culture is the way we do things around here." And I think that's absolutely what culture is. And I'm also a strong believer that our people make the culture.

So in order to change culture, we need to bring our people along on the journey. So some of the cultural challenges we've had. So as a business, we are very siloed. We have influence from the Royal Navy, which is very hierarchical. We're siloed as a business and as technology. So development and operations were sat separately. The business was split into internal cartography and operations and external customer-facing services. So obviously, this is a big problem when we're looking at a DevOps approach.

We've got people who think that they're working towards the same goal, but they haven't really talked about it and understood. Engagement from the doing layer. So we noticed there was a lack of people wanting to change what they were doing. So we looked into that and we found that people were- they didn't really understand what was expected, or it was outside their comfort zone, or they were fearful of the change, what it meant for them. Did they have the right skills?

And obviously, to make DevOps succeed, we need psychological safety in the environment. So skills was another area of challenge in people. Technical and soft skills. We were asking people to behave and work in different ways with different people. We were asking tech to get more involved in business and business to get more involved in tech, and that requires a lot of translation and different skill sets. We were asking developers to understand how to configure Active Directory

and operations to learn Git and version control. So a lot of skills blending going on. We also had a disinterest from senior management in building a DevOps approach. And this is really our fault because DevOps was originally described as a technology change project, which obviously the

business isn't really interested in changing technology. What the business is interested in is what are the things that we're going to do to enable us to move forward as a business. There's a fear of blame and failure. So we're a massively safety-focused organization because of the industry that we work in. When we take risks, there's

an impact on life... Sorry. Might put lives at risk. So we're risk-averse, and we're naturally fearful of failure because there are serious consequences in the things that we do. So we had to learn how to measure those risks and measure those consequences to allow us to fail in places in order to be able to learn.

So empowerment and teams thinking that they're not empowered. If they felt that they couldn't make those decisions locally, they didn't have the tools, or they weren't allowed to by management. Lack of good communication and collaboration. So again, because of the siloed approach, there was not particularly good communication about where are we going, what we're trying to achieve, what are the central problems that we've got that we could address.

And a lack of transparency. So again, with a DevOps approach, you need to have a high-trust environment, and lack of transparency and misinformation breaks down that trust.

05Addressing Culture: Alignment, Teams, Communities, and OKRs

So how did we address some of these things? So we took time to align with the business. DevOps is not just a technology change project. It needs to be an organizational buy-in to change. We built cross-functional teams. So to help break down the silos, we put developers, ops, testers, product people, people from the business, business analysts

all into the teams. That helped to break down the silo. Silos increase the communications between the areas of the business. And it gave the teams more autonomy to make decisions locally. They had the skills and the SMEs and the team to be able to do that. So we moved away from a formal practice model and to a community of practice. So this helped by bringing SMEs,

the people who are close to the work to engage and build strategy around how we're moving forward and the technology decisions that we make. And it really gave the ownership to the people in those communities to guide us. So we created guilds, a way for like-minded people with common interests to feed into our technology roadmaps. And we started a monthly DevOps forum. This was quite interesting.

So we had generally a core group of people in the business who were interested in moving DevOps forwards, and we had our CTO attend, our technical systems manager, scrum masters, and other people throughout the business that were interested. And it was just a place where people could share what they thought DevOps meant to the business and what changes that would bring. Our corporate planning approach. So this is bigger than just technology.

So we moved to an OKR, objective key result approach. And this meant that we moved away from telling teams how to do their work, and we moved more towards outcome and key result focus work, giving the teams the empowerment that they needed to make the best decisions locally. So DevOps approach has required a different skill set. So we've taken this as an

opportunity to value the skills that we need. So in government, we have something called the DDAT framework, which is digital data and technology. This provides a framework of skill sets and roles that you would see in a more modern IT approach. So we've taken this as an opportunity to look at that and see where our gaps are. And we were clear with teams that they were empowered to make decisions locally, and we trust them that when they feel they can't do that, that they will

come to us and tell us that. One of the big things that we did was allow the time to do culture. We constantly were hearing from people, "I don't have the time to go to that guild," or, "The team's got this delivery that they need to get out." So allowing people the time and the space to invest in the culture and the business.

06Culture Outcomes

So what did we see from doing these things? So we saw we've got a commitment from the business to change. It's written into our corporate plan OKRs. It's not described as DevOps anymore. It's now what is the business outcome that we want to achieve by taking a DevOps approach. We've got

people on our executive committee that are fully and committed into supporting this. We've seen experimental approach begin to emerge in the teams. So because teams feel more empowered, teams are able to make decisions about how they do the work. We're seeing far more experiments in the teams and faster feedback on what works and what doesn't. We're seeing more data-centric decision-making.

So teams are asking for the evidence and for the data, and if they can't get it, then we're experimenting or finding that evidence and data to make our decisions on. We're also seeing a growth mindset, especially in the guilds and the communities of practice space, where people are far more engaged in learning and growing in themselves and growing other people as well. We're seeing more of a collaborative approach.

So with our cross-functional teams, we're having far more input from more areas of the business. And as a byproduct, it's not a culture thing, but it's reduced our time to market. We're working in a way which is far more iterative and incremental now, and a lot of that is because of the cultural changes, not the process or the tooling changes, but because we've changed the culture around it. And we're also seeing that teams want to understand, they want to be more user-centric and understand the user problem space

rather than just what is the product I'm building.

07Process Challenges

So next, I want to talk about process and some of the challenges we had there. So process is put in place for a reason, and that's generally to protect against something. So it could be security, it could be permissions to do something. If you're not an SME in an area, you might not have the expertise to do this thing. So some of the process challenges we had were the process wasn't challenged. It was just accepted as that was the way that we do things, and there was a lack

of understanding of what the process did or what it achieved. Processes were aged and no longer fit for purpose. So processes had been in place for months or years, and because they weren't being challenged, sometimes they were protecting against things that were no longer actually risks. And sometimes they were a traditional approach rather than being replaced with tools or capabilities that we had. Speed was a big challenge for us.

So for example, when I started provisioning a virtual machine for a dev team, two to three weeks. So obviously, whereas we want to go faster, that's not really an acceptable process. It's no longer fit for purpose. Processes are wasteful, so either in time or overcomplication. A lot of manual processes, so run book based point and click. So

we are primarily a Windows shop at the moment. We have got some Java and Linux, but Windows admins love to point and click GUIs. So it was a shift in behavior there. And they're not repeatable. So manual process is inherently not repeatable, and they relied upon you being in a particular state to start the process to get to your end result. They also were zero trust, so we had a lot of processes that didn't trust the

people doing them. This made them very inflexible.

08Addressing Process: Guide, Trust, and Verify

So what did we do in the process space? So we took some time to understand what our processes were protecting against. Was it a security thing? Was it because only one person had the skills to do that thing? And we looked at, well, can we automate this? Is that still a risk? How big is the risk? We challenged the need for that protection and moved towards more of a

trust-based culture. So we brought in to our governance model a guide, trust, and verify approach. So for example, for our change management, which everything used to have to go, you raise a ticket to change management, you have to wait for change management to look at that change and decide whether or not they accept it. So again, that's massively slowing us down. So for very small changes, it's not really necessary. So we moved to a guide, trust, verify approach where change management would

provide guidance around what is a low-impact change, what's a medium-impact change, and what's a high-impact change. And they would trust the teams to then follow those processes around those different change sizes. So for a low-impact change, yes, we want a change ticket just to record the fact that a change has been made, but it doesn't have to go to change management to actually be approved. It's an informational thing. We made some massive improvements to our CI/CD and infrastructure provision. So I mentioned that two to three weeks for a server when I first started.

That's now down to minutes. For CI/CD, we had, again, massively impacted by the change management and approval process. So we've moved to a trust approach. That's removed a lot of approval gates which were dependent upon individual people to move the process along. And so we've seen that our processes are protective enough.

Guide, trust, and verify allows us to show trust in our people but is verifiable for compliance, which is important to us as a business. It's all auditable. It empowers people. We're no longer saying, "You can't do these things." What we're saying is, "Here are the tools to do it, and here are the guidelines." Processes designed to change. So we come from a world where a process is very fixed, and we see that in our core business. We want processes to be able to change with the times, so processes

are built to be flexible. And a rapid improvement in the speed of the processes, as we've seen in CI/CD, change management, things like that.

09Tooling Challenges and Tooling Choices

So tooling. Tooling is there to enable our teams. Some of the challenges we've had around tooling is we were quite slow to introduce cohesive tooling. So we had tool chains that weren't fit for purpose. We had gaps in the tool chains, existing tools that we had that didn't work together from quite old-school backgrounds. They didn't have APIs. They didn't have endpoints or webhooks.

So there's no way of chaining the tools together in a coherent fashion. So again, which is something which is quite important for a DevOps approach to be able to see your end-to-end value flowing through your tools. So how do we address some of this? So we start looking at tools from a capability perspective, and then we could use the market and other people's experience to choose those tools based on the capability that we actually needed to have.

We utilized the cloud. So in the last six months, we've really pushed into the cloud. So we're using a lot of platform, which once you move to the cloud, you get a lot of things for free on the cloud platform. We also introduced PowerShell as our primary automation language. So this is the Windows-y bit. Previously, there was no real standard around how we did automation, but by introducing PowerShell as an automation language allowed us to build

central components and modules to enable teams to take advantage. So, for example, our operations guys have written SCVMM and Hyper-V modules for infrastructure automation and provision. We consolidated around Azure DevOps services for our CI/CD route to live pipelines. Moved to GitHub for version control.

Introduced tools like Checkmarx, OWASP Dependency Check, SonarQube for static code analysis, ProGet for private feeds, and third-party license management. And we looked at all of this from a capability perspective. So what we saw was by looking at this from a capability perspective is we reduced overlap of tools, and that allowed us to better use the tools that we had. So, for example, before we consolidated around Azure DevOps services for

pipelines, we were using CircleCI and Azure DevOps and on-prem TFS and Jenkins, and there were pockets of skills all over the business and we weren't making full utilization out of the capability. We found that naturally our toolings promoted transparency. And by using the same tools across multiple teams, that's allowed teams to collaborate around common problems.

10Lessons Learned

So some of the lessons that we've learned while we've been undergoing these changes. The biggest challenge is people and culture. I think we all know that. But we need to have patience and perseverance. Culture and people is slow to change. And you're not the only influencer on culture. Keep communicating. So it's really important to keep coming back to the why we're doing behind the what we're doing.

So why are we trying to move to a DevOps approach? It's to enable the business to move forwards in the markets they want to move forwards. Communicate in the right language for the situation. So you can't convince someone in the business by having a technical conversation about how awesome DevOps is. It's copy the questions, not the answers.

So when I joined, something that kept cropping up was, "Oh, well, Spotify do it like this." Yes, but Spotify didn't always do it like that. They went on their own journey. So it's great to have aspirations as to where we want to go, but we need to choose how we get there ourselves. We can't just copy somebody else's answer. Bring the right people on the journey. Find your champions and get them to advocate and drive for you.

Get them to bring as many people as they can. People that you have, they're already invested. This is about helping them to get a better return on their investment. So bring them on the journey with you. Build a community. So communities help to drive collaboration, and it puts the power and decision-making into the community, into the

people, and it keeps the enthusiasm and will naturally change culture over time. So there's always room for improvement. When you think you've done the best you can, there is always that little bit more. But what we found is just be careful for keep in mind diminishing returns. Don't just focus on one area. Make sure that you are looking across the board. Be kind. So change is an unsettling experience to go through for some people, some

more than others. You're all in it together, so make sure you're kind to one another within that. Expect change. So set yourselves up to expect change. If you don't expect change, it's always going to be a painful process to go through. So embrace it. Get support from the top. So especially for an organization like ours, which is very hierarchical to start with. If you've only got bottom-up support, you can only get so far.

So get commitment from the top to support you, and do this by translating what are the benefits to the business of us doing this. Tackle organizational impediments. So if organizational impediments are ignored, at some point, they'll become blockers. So even if you start the conversations about these things early on and start to think about how you might address them, that's better than just leaving them to become blockers. And finally, don't try and boil the ocean at once.

So DevOps is an exciting thing to do. It's an exciting space to be in. It's all too easy to try and do it all at once. So just like not copying the answers, we need to change things incrementally. And by all means, have the vision, but break down your journey, how you're going to get there. Thanks very much.