Simon Parkes

Afternoon, everyone. It's a real pleasure to be here. It's really inspiring to be surrounded by so many like-minded agents of change. Don't get that very often. It's brilliant.

So as Ben says, I work for Ordnance Survey. The title of the talk: "Turning a Dinosaur into a Unicorn." Now, I got into a bit of trouble with the management team back at OS, who weren't overly happy with me calling us a dinosaur, but it's primarily in reference to the fact that we're really quite old. So we're 225 years old this year as an organization.

And the reason for putting that up, and the reason for referring to dinosaurs and unicorns, is to really re-emphasize the message that I think has come out a few times. It was emphasized with Darren and SAP and so on this morning: that if we can, and we're 225 years of history, there's a lot of legacy there. If we can get benefit from DevOps, then pretty much anyone can. It's all about how you do it. And that's really the purpose of the talk, really, is just to give you guys some inspiration that it's not just these special organizations. Anyone can do it.

So a bit about me and my gurning face there quickly. I've been in IT for 20 years. As Ben says, I'm Enterprise Infrastructure Architect. Essentially that means I'm in charge of defining what we do with our platform and infrastructure services.

Primarily, when I joined OS three years ago, it was our internal services. Now there's an increasing focus on adoption of public cloud platforms, and the belief that actually moving to the migration to the cloud is the way to go. So I'm in charge of actually defining what that means for OS. And I seem to have generated a history of focusing on collaboration and automation. I did it at a previous post at JP Morgan, and I seem to be doing the same thing at OS, and I keep getting blamed at OS for bringing DevOps to OS. But it seems to have some sort of level of success.

So, in case anyone is wondering what on earth Ordnance Survey and paper maps that you carry around when you're walking has to do with DevOps, just a few figures and numbers and context around what we actually do these days.

Paper maps is a really very small part of what we do. These days it's all around the capture, maintain, and dissemination of digital data, a digital representation of Great Britain in terms of geospatial intelligence.

A few figures there just to give you an idea of the rate of what we do and so on. Thirty-five million buildings, 27 million residential addresses, 10,000 updates each day. Now that's not just single lines in a database we're updating, like some finance transaction and so on. That is usually complex polygon selection of lots of different records, updating for a single feature at a time. Equates to roughly seven per minute, something like that, which to some people may sound quite slow, but when you're looking at the size of data, and some of these changes can be terabytes in size, that's quite a lot.

We have a key role to play as far as the success of Great Britain is concerned, and there's a belief that were we to not provide the data, Great Britain would come to a standstill. Not just in terms of producing maps, but we support an awful lot of business-to-business activities.

A lot of insurance companies use us to make sure when your guys' insurance premiums are calculated, it's based on where you are, and therefore it's an accurate premium.

Other use cases include using our data to work out where it's best to put a wind farm, or where it isn't best to put a wind farm. Loads of public sector scenarios on top of that as well. Disaster response planning; i.e., if we're to get some sort of security threat or flooding disaster and so on, using our data to actually work out the best way to be able to recover, how are we going to recover and so on.

And then, for me, the really cool things at the bottom: some of the major events planning. So as I said, I joined OS two or three years ago now, three years ago now, and I was really proud to find out that our data was used to design and then maintain the London Olympic site, and then the same with Glasgow in 2014. Some really cool stuff there. And you learn that and you go, "Yeah, it's really nice to be part of this place."

So just to give you an idea of org structures. I know there've been one or two talks that say, "Don't worry about org structures," but it's just to put some of our problems into context.

Quite a traditional IT organization structure: software development on the left, infrastructure on the right. Infrastructure is responsible for provisioning anything that supports the development teams. So we invested, about five years ago, in a large VM farm run by VMware, and it's been a policy of, up until recently anyway, prioritizing that and internal hosting.

So the service delivery division on the right provides all the support services to the software developments on the left, which is split into three main areas. You've got your geospatial systems, which is roughly your systems of differentiation; i.e., the stuff that makes us good at what we do. Business systems: systems of record. Okay, stuff to run the business. And then our digital data delivery. This is how we start to serve content online through our API platform and so on and so forth.

And actually, the API platform, digital data delivery, that's quite a cool space. There's lots of stuff going on in microservices, magic container platform. There's some cool space there. That wasn't the problem that I wanted to solve when I joined OS, and I'll come onto that in a minute.

Me, my gurning face, I sit there. So I'm responsible, or was responsible, for designing some of the internal infrastructure. And as I said, I'm now responsible for defining cloud.

I said a couple of minutes ago, this is the main area of focus for us: the geospatial systems. It's the heart and lungs of what OS does. This is what makes us what we're good at. This is a set of systems that essentially take detailed mapping data, as I said on the previous slide, accurate to within one meter, and actually munge that into something that customers can use for whatever purpose it is.

We can't just serve out the content raw as it is, because it wouldn't make any sense to anybody. So that red box and those green systems are what makes us good at what we do, and that was the area of focus with regards to how we got some DevOps going, and the area of focus for this talk, really.

So why? Again, it comes back to: why do we want to do DevOps? If we're quite good at what we do, what's DevOps going to do for us?

So if we think in terms of the future, there are some business drivers, all of which can be summarized as the need for more rapid change. And that can be change with regard to the geospatial context; i.e., the world is changing rapidly and our data needs to keep up with it. But also change of our systems, as customers start demanding ever more complex solutions to problems and so on and so forth.

So there's the kind of need for speed, need to be able to keep up with speed of change in two aspects, really, and lots of drivers there about what's causing that need for speed and so on. But really, it's about being able to go faster.

A couple of challenges with being able to go faster, really. We are not talking about microservices. When it comes to these geospatial systems, we're talking about the complete antithesis. I say large monolithic components. A lot of our geo systems are comprised of a number of different COTS packages all put together, usually linked by some sort of peer-to-peer messaging, sometimes a message bus.

And it may sound like I'm kind of poo-pooing the architecture. Far from it. It's very good at what it does, but it's quite difficult to unpick. Okay, so the message really is: this isn't a kind of SOA-based microservices world. Far from it. This is what most people would think is the complete antithesis of what you can do with DevOps.

I kind of alluded to it: very tightly coupled implementations, and it's very, very hard to pull them apart at times.

Most of our data, I say most of our data, is stored on Oracle Exadata. At one point, it was the largest in the world until a couple of years ago. I believe Amazon may now have kind of captured that mantra from us, but it's still a pretty large database. We're talking petabytes in total, as I said before. We're talking terabytes per small update, let alone some large ones and so on.

The overall message is there's some big, clunky things going on that we're trying to do something with here. And on top of all that, everything we do is manual. So the provisioning of the infrastructure, the installation of the systems, the testing and so on. This is not new to you guys. You're here because you know all about DevOps and so on. Manual processes all over the place, lack of reliability, no real configuration management, delivery cycles measured in months, not days, and so on. Okay?

The other challenge. Now, I'll start by saying I would love this to be my diagram, but it's not. This is a diagram taken from a blog by Matthew Skelton, which is describing all the kind of organizational patterns and anti-patterns that can support DevOps. If you haven't read it, I strongly urge you to go and seek this out. It's really, really useful in order to try and help you get going and so on. It's also really useful for me in terms of illustrating where we are and how we've got there.

So when I joined, very traditional split between the Agile methodologies of dev on the left, and then the more kind of ITIL, slower waterfall-based processes of service delivery on the right. Method for engagement was always through a ticket. We seemed to have developed entire processes because the ticket system would support them, as opposed to getting value out of them.

So I'm a dev and I want some infrastructure: raise a ticket. My infrastructure's not working: raise a ticket. Even walk-bys, where a dev would walk up to someone's desk and say, "Can you just do this for me?" The response would be, "Can you raise a ticket?" Because that's the processes that everyone's familiar with.

There was also, and there continues to be to an extent, that kind of clash between ITIL and Agile and the constant debate about whether the two can coexist. And we were just having a debate over lunch where actually, for me anyway, they're both... I've chosen words methodology and framework deliberately. They're just frameworks. You should be able to implement the things that give you value.

My experience kind of tells me that people will implement Agile or ITIL, or both, to the purest extent possible, and that's where you get the clashes. That's where you get the culture clashes, where the two can't coexist. I think if you pick the right things from each one, you can actually overlay them and get what you need from both in order to be able to deliver faster.

So, bit of context around how we were set up and so on.

Where to start? So I've been doing talks on DevOps now for a couple of years, and the question that continues to come up even now is: how do we get started? How do we get going with DevOps? Where do we begin?

And my answer is always just saying: what's the problem you're trying to solve? There's no point trying to do DevOps if you don't know what you're trying to solve, because you've then got no idea of what good looks like or when you're done with it.

So what was the problem we were trying to solve? When I joined, I did a little bit of analysis in terms of, I call it there, the life cycle of a feature. Feature could be an update to the system, it could be a new geo data product, could be a number of things. It's essentially a cycle that delivers product or value to the customer at the end of it.

So I did a bit of analysis and put it into a value stream picture, whereby activity is recorded against time, and value on the vertical, to see where we were getting our most value and where we were losing the most time with regard to the implementation of new features.

And what you find pretty quickly is you've got development activity, which are kind of short bursts of iterative activity in the Agile process, where you deliver high value in terms of: this is the function, this is the code that supports the requirement.

You've then, at the bottom, when it comes to the activity before go-live, you've got ops doing lots of work. Now that's high value because that's going to secure your system and make it ready for production. That's quite important stuff.

And in the middle, you've got provisioning activity. So if you think back to the org chart structure, we had infrastructure provisioning as a team within service delivery. They're responsible for kind of taking in the tickets, building the VMs, and handing them over to the projects.

And then looking in terms of this picture here, what we're finding is the provisioning activity was actually taking a really long time in comparison to anything else. And because it was taking a long time, and because there was nothing special about what they were doing, they were just provisioning VMs, you could class it as lesser value than some of the dev and ops functions and so on.

So hence, they're slightly smaller blocks in terms of height, but they're much longer in terms of elapsed time. And that shows us straight away that the problem that we needed to solve to start with is this provisioning activity.

Where to start? Start with what's broken. What was broken for us... I say broken, people weren't likely for that. What wasn't working well for us was the infrastructure provisioning activity.

A few metrics which we'll come back to, but just to talk about them quickly. Because it was a central provisioning team, we were looking at a backlog normally of 20 to 25 orders at any one time, usually a lead time of a couple of weeks to pick up an order, et cetera, and so on. You can probably see where we're going. There'll be an improvement on that over time.

So how did we get started? Once I highlighted there were some problems, and I said, "Well, DevOps could help us with this," the management turned around and said, "Okay, can we run a project? Can we just run a project to do DevOps?"

Absolutely not. Don't be so silly.

Anyone who knows anything, so what are you going to do? Are you going to run a project to build some automation because DevOps is about automation? Well, okay, you're just going to build some automation. You've still got that same org structure. You've still got that same pipeline. You've still got the same processes. You may speed up delivery activity, but if your processes haven't changed, then how do you actually get any more value?

Do you run a project to actually do a reorg structure? Well, that doesn't seem like a particularly sensible thing to do.

So how we started, and how I'd recommend you guys get started: find a willing project. Find something that is going to deliver business value, and then use that project to demonstrate how following a DevOps methodology can increase the value you're going to get from that project. Okay? And that's how we got started.

We found a project that was an 18-month program to actually implement quite a big system, again, using lots of COTS software and so on. And we said right from the beginning, we're going to follow DevOps for that.

And how did we do that? Well, we actually embedded some infrastructure engineers with some DBA skills, some sysadmin skills. We placed them in the project. Okay? It's a couple of people. We placed them in the project to start acting as localized sysadmins, people who would be able to interact with developers who wanted the infrastructure on a daily basis to be able to get things done quicker.

Part of the reason for that is you remove the need for ticketing because they're there, they're part of the project. But part of the reason for that is to start thinking about teams as cross-functional activities. Jonathan Reicox mentioned earlier in terms of cross-functional teams is where you're going to get the most value. We wanted those with that cross-functional capability very much within the project itself.

But of course, somewhere along the way with DevOps, you want to have a look at some automation as well. So we did spend some time automating our provisioning processes, and you can start anywhere. For us, this is where we started. We started with the simple stuff.

We've heard it time and time again over the last couple of days: infrastructure as code. Okay? It's nothing new. I'm not teaching them to suck eggs. We all know infrastructure as code is a good thing. When I joined a couple of years ago, it was quite a new concept to OS, so we introduced that from the beginning.

And then we just used that for the regular low-value but highly repeatable activities: VM provisioning, operating system configuration. We started off by automating those bits and those bits alone. Essentially started to create a boilerplate using automation that becomes a standard thing that you're rolling out again and again.

And then we got onto the application installs. Okay? Now, I said before, there's a lot of COTS in what we do, munched together with some code in between. Rather than try and recode application installs and write our own methods for installing these COTS applications, what we did was use the automation tooling to interact with the install scripts or whatever the vendors were providing.

So in each case, we engaged with the vendors and we talked to them and said, "Well, each vendor must be running some sort of CI function, some sort of automated test function. No software vendor in their right mind isn't going to have that these days. So can we get hold of those CI scripts? Can we use those to start automating our deployments?"

And by taking the automation from the vendors and integrating it with our infrastructure automation, we started to get one single integrated automated process that will do everything for us without overcomplicating anything. So underline: keep it simple.

Complexity comes from trying to reinvent it and recode it yourself. We found a way of trying to just integrate and interact with existing install scripts and actually just make it a lot simpler for us.

Wasn't perfect to start with. We had to deal with a lot of return codes, a lot of responses. Some of the code in the early days was quite long, but it was a start. And then over time, once we got good at doing that, then we started to introduce, okay, not exactly the most complex task, but some more complexity. How do you keep your VMs up to date? Are you patching it and so on? Blue/green deployment models. This is quite a new concept to OS, but became quite a powerful tool for us.

But also security. So we always talk about DevSecOps and so on. We started to embed security as part of the boilerplate activity at the beginning. Again, none of this is rocket science. You guys know all this already, but this is just making it clear on what we did.

With our automation, we focused very much on the delivery of the pipeline. Okay? So I said at the beginning, said a couple of slides ago with regard to embedding people in the projects, we wanted to create a cross-functional collaborative space.

So the reasons that we then spoke in terms of a pipeline was to create the idea, the commonality of thought. Get everyone thinking in the same terms so we could deliver infrastructure using the same kind of methodologies and the same language as the developers.

So we just write some code. For that, we use an IDE, which is Eclipse, and we use Puppet. Why Puppet? Well, there are 30, 40, 50 different kind of DevOps automation tools these days. You could have chosen any one. We chose Puppet because someone in the building had done a bit of Puppet, so that was the one to go for.

It is brilliant at what it does, so that's not me dismissing it. It's fantastic and it's done a fantastic job for us, but you could choose any. So this is not me evangelizing Puppet in particular. That just happens to be the one we chose.

Version control, Git like everybody else, code review, Gerrit, and so on and so forth. And what we found, and the reason for putting this up, is we were trying to treat the delivery of infrastructure as code in the same way that people treat delivery of software.

And what we've done over time is we've kind of enhanced that pipeline to go from our original VM structure to start deploying to varied public clouds now. And then, and this was kind of the magic moment, the moment at which you started to see proper collaboration and proper joint thinking within the teams, was the realization that actually you could plug various coding languages into that same pipeline and pretty much get the same result.

And that was the moment where everyone started to realize it's all just a bit of code. All right? There's no difference. Okay, the actual thing you are delivering at the end of it, infrastructure, application, fine. But when you treat it in the pipeline, it's all just code.

And the reason for putting that up and the reason for laboring the point is, DevOps relies on collaboration. Okay? So it's not just automation stuff. It's not just getting people working in projects. You've got to get people working together. You've got to get people thinking in the same mindset. Okay?

You change the culture, and we keep talking about this again and again. There've been various streams about it's people, not automation, it's all about culture change and so on. For us, the key to getting that culture change was getting everyone to think on the same page. It's all just a bit of code.

So, with all that in place, we started to see some success. If we go back to the value stream, we're starting to see some work shifted left. The provisioning activity has shifted to the left now, so it's all at the front of the project rather than the end of the project. It's small periods of time because we've automated it, so it's fast and it's repeatable, and it's also high value because it's the same every time. We're not having to go and correct it after we've built it and so on.

But we haven't quite got there. So again, there was a couple at a talk this morning that asked the question: what about ops? Well, our ops activity, we're still stuck at the end there. At which point, the Roy Walker moment comes up to me: it's good, but it's not right. Okay?

So what do we do next? Well, first of all, we kind of patted ourselves on the back and we asked questions in terms of, well, how good are we doing? It's not right, but how are we doing? Take time to kind of reward yourself for how you got on so far.

So we go back to some of the metrics. The first two, because we'd embedded people in projects, there were no more tickets, so therefore, there was no backlog and there's no lag time. Things are getting done when they appear on the backlog.

Simple VM now goes down from two days to half a day. An environment build, usually multiple VMs, six, seven VMs with the applications on top of them, is now down to two days. Rebuilds, once you know what it is, once you've automated it all, becomes a day and so on. But the transition to operations still remains at four weeks. We still hadn't cracked that.

So this is what we did next. What we had found is that embedding people in the projects is great. Starting to talk about commonality is great. Starting to get the idea that everyone's thinking on the same lines is fantastic. But the projects were still creating their, kind of repeating the same org structures as they used to; i.e., the ops team were part of the project team, but still in isolation in a little silo over there. And then the dev team were still over here, and they were kind of deliberately working on their backlogs and separate activities. They supported the same project goal, but there was still that separation there.

So we told them to do away with that and create a single backlog, single common backlog for the project that everyone's contributing to. So devs are contributing to it, the DevOp people are contributing to it, the service delivery people. We're starting to get the op stories in that backlog.

You then start to prioritize that as a single team, single project team. You start to discuss what needs to be done. And as soon as we started to do that, what we found actually almost by accident was that the stories that described the features that we wanted started to contain both the kind of functional requirements and the non-functional requirements; i.e., the infrastructure, all in one story. They became acceptance criteria.

So whilst this backlog shows a kind of separation of the green and the blue, the dev and the op stories, over time we found that our user stories themselves become one set of stories that just deal with everything together. That's when you started to get really strong, true collaboration going. That was the light bulb moment where you go, right, everyone's now working towards a common goal.

But we did also bring ops closer as well. So we encouraged ops to be a bit more collaborative. Okay? So that's one thing. We said to them, "Don't sit and wait for these things. Actually go and talk to these people. These people actually talk your language. Go and talk to them."

But we actually also made it incumbent upon the DevOps people in the projects: "You guys are responsible for making sure the ops requirements are delivered. Okay? So you are the ones who need to kind of engage with this interaction and so on."

And the reason we did that is because those traditional DevOps people, the infrastructure engineers, they kind of spoke the language of ops, so there was a kind of common purpose there. And it was a way in for the ops team to actually kind of find out what's going on in the project and give them that kind of point of entry.

We also automated an awful lot of the ops requirements. So a lot of, I mentioned before, security and so on. A lot of the ops requirements around user configuration, anything that they want to see before something goes live, we automated and put it as part of the boilerplate, so that when a new VM was created, lo and behold, ops have got what they need before the application even goes on there. And suddenly, they were an awful lot happier because they felt like they were getting their requirements prioritized, because their stuff's coming up first as part of boilerplates.

And what we started to find then was actually you started to move towards everyone's working together. Everyone's actually kind of interacting with each other. And then coming back to the value stream once again, this was the big moment for us. This is the big moment, because you can see there's no longer a provisioning activity in the middle. Everything is on a single backlog now, so all activities are done together. And we've handled a lot of the ops requirements. So the ops requirements and the ops actual activities become a lot less. We've boilerplated it all.

And for the eagle-eyed amongst you, you'll have noticed that the red implementation line has actually shifted to the left as well. We've started to bring the implementation date forward. Okay? That was the real winner. That was the moment where, actually, we thought, "This is making good progress."

So go back to the stats again. Simple VM is now down to 30 minutes. Okay? Environment build is now down to half a day. And again, environment builds with COTS software on there. This used to take four weeks. It's now down to half a day. The rebuilds are the same and so on. Transition to operations, there's no transition period anymore. They're in it from the beginning. Okay? That's when we started to feel like we're actually getting somewhere, hence that table is green rather than red or amber.

From that initial project success, and remember at the moment that we're talking about a single project at this point, from that, everyone started looking at us and saying, "Oh, that looks good. I want to be part of that. Can I have some, please?"

So suddenly every project wanted their own DevOps resources. Now, that enabled us to grow our DevOps pool. Suddenly we've got a wider skill base, and we can actually start rolling people out. So we're starting to create that commonality, and it becomes more of an enterprise capability.

The pipeline became standard. Everyone suddenly wanted to start using it. Everyone suddenly thought, "This is a reliable way to go," because we'd invested so much time in it.

I forgot to mention, the pipeline is all done through open source tooling, okay? We didn't plan paying licenses, largely because we didn't have a DevOps project, so we didn't have any funding, but also we wanted to see how far we could go with the open source tooling. And what we've actually managed to do is go a really long way and extend it to the point that it's now the pipeline to deploy into our public cloud offerings as well.

This is the first time, so if the previous stats views were looking at the views in a single project, this is now the view of some kind of high-level stats from the point of view of that central provisioning team.

That provisioning team is still in place today. It's much smaller, and it's much faster at reaction to things because of what we've done elsewhere. But there is still, because we don't have unlimited resources to put DevOps people in the 40 or 50 projects that are in flight at any one time.

But the backlog's down. The lag time was the key one for me. It's down from two weeks to half a day. People tend to get their stuff on the same day. Okay? We're not a self-service operation yet, although I'd like to be there in time, but with the lag time being down and so on, at least it feels a lot more like a real-time operation again now.

And just to prove the stats, really, if I said up front that we used to use ticketing all the time, this is just a quick graph to show that actually tickets have reduced because, A, they're in projects; B, we've automated and so the reliability means we're not going back and saying it's broken all the time. Just a quick one there.

Key figure quickly at the bottom. So in the first 12 months, this was over the course of 2015, we estimated that of the 10 projects that started to adopt the DevOps way, i.e., have people in them, we saved the organization about a million pound in total, which was a really good news story to tell senior management people. It was so successful that actually we didn't then record the stats from that point onwards, so I can't tell you how much we've done today, because this is now the de facto way of doing it. We almost now can't go back and re-estimate how much it would have cost to do it manually, because everything is done automated. Which really praises that one.

Couple of intangibles. So DevOps is now part of enterprise and architecture. We have a set of policies: everything will be done through the automated pipeline, everything will be done using collaborative methods, et cetera. It's now the norm.

So I said 10 projects in the first 12 months. Now every project has some form of DevOps. Whether it's a resource, whether it's using a pipeline, whether it's starting to do stuff themselves, every project is following a form of this somewhere along the way.

And because everyone's using the automation pipeline, we've started to create standardization almost by stealth. When I started, we had about 15 to 20 different versions of operating systems to support and so on. As we started to boilerplate, as we started to roll out things as standard and so on, people started to use the standard versions through automation. We have cut down the operating systems to the minimum. I think we're down to four or five now.

So almost by accident, it's in inverted commas, we've created a lot of standardization across our tech stack, which actually makes the operations teams easier in terms of managing ongoing life cycles.

And CD for us is now a realistic target rather than a pipe dream. We haven't started on that journey very much yet. We deliver quickly in the projects, but because although a lot of COTS software, there's a lot of work to be done. But because of everything we have done before it, this feels like a thing we can actually do. This feels like somewhere we can go now.

So I'll rattle through quickly because I know time is of the essence now.

So anyone can do it. If there's one message I can tell you, and I started off with this: if we can, anyone can. Legacy shouldn't stop you. COTS shouldn't stop you. It's possible.

It's not about automation. It's a common theme over the last couple of days. It's about people. Automation helps because it helps you do things quicker, but it's about culture change, it's about people, it's about collaboration.

Keep at it. So you saw we had a couple of iterations, and I think even now, we're still not there. We made a lot of progress, but we're still not there. So keep going. A lot of energy, a lot of patience as well, but keep at it. It is worth it.

But one way to not allow yourself to be pulled down in terms of, "Oh, we're not there yet," show off every time you do something good. Let other people see how great you've been with doing this, and actually the enthusiasm that you'll see from the others will help you on your next step of the journey.

And just get started, right? Don't wait for permission. Don't ask to get going. If you think it's a problem, find out what the problem is and just get going with it.

So what don't we know? Or what do we need help with?

What's the right org structure? So being a government department, we tend to be quite hard on org structures. It's quite important for a lot of people and so on. The traditional divisions between service delivery and development are still there, even though we embed people in projects and so on.

But how do you create an org structure with DevOps at the center of everything? And genuinely, if anyone has any ideas, please come and talk to me, because I don't know. Is it job role definitions? Is it just governance? What is it?

Going back to Matthew Skelton's blog, and it feels like I'm being a bit of a PR guru for him right now, but it's really useful. This is the kind of recommended approach for him in terms of an abstracted org chart view. DevOps is a bit in the middle. But going back to the org structure chart that I showed at the beginning, how does that reflect in terms of how do you organize ourselves to be able to support that? I'd like to be able to support that, but I don't know how we can structure ourselves.

How do you bring Dev to DevOps? So when we met on Wednesday night, Gene commented that we were predominantly ops and not much dev. And the work I have seen at OS, we've embedded people in projects, but it's still the DevOps, the infrastructure engineers, who are doing a lot of the innovating, and the devs are still receiving it. It's great in terms of project delivery, but I'd like to bring the devs into this picture. I'd like to get the devs contributing. So if anyone has any thoughts on how to do that, again, I'd really appreciate them.

But also, how do you prevent DevOps becoming its own industry? How do you have a pipeline that is the center of everything you do without having to have massive support team to support the pipeline? Because that, there again, feels like an anti-pattern for DevOps.

If anyone has any thoughts at any point, whether you come and talk to me today or please drop me a line, please get my details as part of the speaker agenda. Please drop me a line with any thoughts, because these are the things that I really need help with when we're going forward from here.

And that's it. So hopefully that's given you some inspiration that, like I said, anybody can. Thanks ever so much for your time. Appreciate it.