Host Intro (Gene Kim)

Rasmus Hald is the head of the Cloud Center of Excellence at Maersk, the world's largest container logistics company. Last year, he presented about his work building a cloud-first capability, helping product teams become more productive and gain the capabilities to market faster. He joked he was doing this in literally the world's slowest-moving industry. He returns to DevOps Enterprise Summit to describe the continuation of his journey, helping Maersk compete in the marketplace, as well as transform in an industry that is being disrupted both by smaller startups and the newer tech giants.

Here's Rasmus.

Rasmus Hald

Hello, everyone. Thanks for tuning in, and thanks for attending this session here. My name is Rasmus. I come from Maersk, a global leader in container logistics, and I'm here today to talk about how Maersk is building a unified delivery model to accelerate our engineering productivity and get new products to market.

I've been working at Maersk for about three years now. I come from a big tech giant, and one of my things and themes here at Maersk is how we can use cloud to change how we deliver. But also the opposite, right?

How we need to change how we deliver technology services to benefit from the cloud. I was here at DevOps Enterprise Summit last year talking about exactly that, and today I will share a bit about the learnings we have done since then, but also take you on the journey of how an enterprise can transform delivery using DevOps.

Today, we will talk a bit about Maersk, and Maersk being in the middle of a digital transformation that has a huge impact to how the enterprise views value and how we bring value to market.

Now, you can call this a digital transformation, a word that's been used throughout for a long time. At Maersk, we are changing it with DevOps, right? We are changing our organization and how we deliver value with DevOps. And today I will talk a little bit about how we have achieved that. Not that we are done yet, but the tools, the methodologies we have done or used in this process here to create new, innovative digital service and bring them to market.

So, for the next 28 minutes or so, I will give you a bit of introduction to Maersk, why we are doing these changes, and how we are realizing DevOps through a series of methodologies and actually practical examples of how we have done it at Maersk.

So first, let me talk a little bit about Maersk and what kind of company we are. We are what we call an asset heavy enterprise, meaning that we live by the physical assets of the company. We have a fleet of more than 750 container vessels. We have a large number of terminals, tugboats, and whatever goes in between here. And our fleet of containers is above five million as it stands right now.

We are the absolute market leader in this space, and we have every intention of staying so, of course. Our technology organization is becoming very much an engineering driven technology organization, and we number around 3,500 as we record this session here.

So, what I really want to emphasize as part of my introduction to Maersk is the need for change, right? First of all is our integrator vision, how we want to become the global integrator of container logistics by simplifying the supply chain.

I can't imagine if the audience today knows about the complexity of supply chain and supply chain management, so I try to draw it up here. But just to give you an example of when you go to the shop and buy perhaps bananas or a new pair of shoes, the complexity that lies behind getting that product to the store so that you can buy it is just tremendous. Just consider import, export.

Consider the number of trucks the banana has been on, the number of ships it's been on. It's very complex, and it's also very old fashioned. So we are really looking to simplify this for our customers, but also using modern technologies to drive technology solutions in this actually zero trust environment, because you have many different carriers and you also have government officials like customs where trust is not a thing, right? We have documents, and they need to be certified in order for us to import goods into a given country.

Another thing that's taking up a lot of our priorities these days is, of course, sustainability and how we can drive towards carbon-free logistics. Now, last year, I also talked about the industry as such.

So, logistics industry is a very polluting industry, and for Maersk, it's very important that we are changing this, and we even have a goal, a future of having a carbon-free logistics company. Now, what we have done lately is another good example of how we have used technology to drive down our fossil fuel consumption with our marine batteries.

And on the screen today, you see one of our new batteries. I think it beats a Tesla battery by far. So this is a 40-foot container or battery that we actually put on our vessels.

Not that we can have a complete journey end-to-end on batteries, but if we can run our engines at optimal, which is often high utilization, so it burns less fuel and pollutes less, and then compensate with batteries when we don't need our engines to run at full capacity. And the link here is the technology. Just with sensors, we are driving a new way to optimize each vessel in our fleet to bring down fuel consumption, which, of course, in itself is a nice business case, but also promotes our sustainability agenda.

So these are the pressures on Maersk, right? We are in this global market, market leader, and want to keep like that, but we're also driving towards changing our industry, both simplifying it and bringing sustainability into it.

So with that, enough about Maersk. Let's talk about our DevOps journey. And for that, I actually want to take you back in time with me, and talk about the history of DevOps at Maersk. So what you have in front of you here is my view on how we have adopted DevOps.

And the scale here is from being under the radar, probably more shadow IT, into being tolerated and ending up being strategic for us. Now, the timeline at the bottom here, we talk about before, during bimodal IT, and after bimodal IT.

We did a couple of years with Gartner's recipe for bimodal IT, and if you're not aware of it, I recommend reading about it. There's some good learnings there, especially for companies that has been through it. But let me put some numbers on this.

Before we did our bimodal IT, we were very much a functional organization based on Waterfall. Average lead time to production were, if it went fast, about 24 months, right? Two years to get any idea to production. And of course, I think in this audience today, we can agree that that's absolutely too long.

Nobody talked about DevOps. I would even say it was frowned upon. We couldn't even agree what DevOps meant, right? So during the bimodal IT, we kind of came into this accepted shadow IT, where you could do shadow IT, you could do DevOps with a startup mentality, and was very much entrepreneur focused, like let's build something, let's create results.

The downside was we created this divide between our engineers in what's called Mode One, which is Waterfall, and Mode Two, which is Agile and DevOps based. And our Mode Two initiatives, so the new things, didn't really leverage the enterprise capabilities that Maersk has invested in over time. Just a simple one, like a common service desk or shared monitoring.

We managed to bring down our lead time to 18 months. And you would say, "Well, if you have a startup mentality, why could it still take you 18 months? How did you go about taking that long to reach production?" But 18 months to production was the average number. And really, the thing that kind of deflated the DevOps initiatives were that all the data we needed for our initiatives were still hosted in this old ITSM world, where you needed to deal with a Waterfall organization.

So lastly, on this slide, I want to talk about what happened after. Because when we decided that bimodal IT had done what it could for us, we started bringing together these initiatives back in 2019. By then, we realized that we could benefit a lot from both the DevOps and startup mentality, but also being an enterprise, and I will talk about those capabilities in a second. But really, that's when we started the inception of the unified delivery model and how we would use the learnings of the old world, and of course, the new ways of working, and bring them together to unite our engineering communities.

So imagine that you just come out of accepted shadow IT. On one hand side, you have classical IT that are, I will paraphrase here, a bit p****d that they weren't considered. And then you have a huge engineering community that's created a lot of value for the company with a startup mentality. So bringing those together was a bit of an effort, but everyone was very keen to drive this, and we just used an Agile retrospective to do it. We took in stakeholders from classical IT that had concerns and requirements. We took in engineers from the developing team, from the DevOps teams, and we brought people together with sticky notes. It took us two days, I will say.

And we just aired all those concerns about slowing down and not being secure, how we could scale innovation, not leveraging enterprise capabilities. And out of that really came a balance on how we could start working together, both on one hand side to scale, but on the other hand side, leverage that we are an enterprise. We are not a startup. We are 80,000 employees here.

So we will never be a startup, but we can of course do it in some scenarios. So really this was about finding the balance of what I like to call aligned autonomy, because every developer, every product teams want autonomy. They want to be master of their own house.

They want to decide the direction of their product. So we looked at the goods and the bads as you do in any good retro, what works well. We looked at the concerns, and therefore, we extracted the opportunities here.

So if you look at this, and this is my opinion again, and the opinion that we derived out of those conversations. So when you are in a functional enterprise, which is functional IT, you're very siloed. And that construct is good for managing risk, managing cost, but not so much for driving agility and driving innovation. And that was kind of what we need, and we still need it.

When we look at, for example, the processes. In a startup you have very few or none. In a functional enterprise, that's kind of the control. That's the benefit, is that you have this control and you can really control what's going on in your technology.

So we took the good from both worlds and drove it into what we like to talk about is enterprise DevOps. And really agile was a no-brainer. We agreed that Waterfall doesn't really do anything for us.

I'm not saying ITIL isn't good. But Waterfall process and project management is something that's not really driving the innovation we want. We also needed to look at our culture to be empowering.

We will have the agility of a startup to some extent, but it's really about empowering our engineers to do the right thing rather than be telling them or being this functional one. And then focus on reuse. What is the common capability that any product team needs?

Those are here. We have our potential as an enterprise. We could just do startups, but it scales very poorly. So being an enterprise, we want to build hundreds of products and just using the scale of the company is where we have a benefit over the next startup, I would say.

And having these fundamental capabilities. So we ended up with quite a short list of requirements, and decided to move this ahead. So I'm just going to introduce you to the unified delivery model here, and what it looks like. So basically, this is the delivery flow. So any product or project that wants to deliver at Maersk, they have a choice. You can do one of three delivery methods.

On the left-hand side, you would see we talk about DevOps. On the right-hand side, we talk about a classical delivery. Now, a classic delivery is a fully managed service offering following a classic Waterfall process where you would say a developer team doesn't really care about anything with infrastructure.

Even testing is something that happens downstream. This is really good for managing vendor-developed software, or for very old applications that probably should call them fragile application. Just having that complete control process for products that just needs to be kept alive.

And we often use a not so nice phrase, but we call this the hospice mode. This is about keeping the software alive until we can either move it to a software as a service, or we can rebuild it and host it in a modern, different way.

On the left-hand side, you would have our DevOps, and this is really about empowering and supporting dedicated product teams that are capable of building and running their own production services. So the end-to-end responsibility sits within the product team, all the way from idea and driving the business outcomes here. So really full empowerment, no handovers, give them the funding, the bag of money, and they can just go and do what they need to do. So fully empowered team. And we also found that we needed kind of a middle ground because we had very small product teams that might build an important application or critical business services, but didn't really have the manpower, or it wasn't feasible to establish the engineering teams that would be able to drive around the clock a 24 by seven operations service. So just having this middle ground, especially here in the transition where you still have end-to-end responsibility for your code, but you have a managed service at the end that looks after the infrastructure 24 by seven. And again, this is not necessarily the strategic direction, but just in the journey of the enterprise.

Remember, we have thousands of applications that we take care of. And having a semi agile or semi DevOps delivery method really, really helped build this story and helped us get this aligned through. So consider that you want to build a new product. You have these three options.

We actually don't use the classical for greenfield. So if you're building something new, the default is DevOps. Let me just for a brief second talk about these capability or enterprise capabilities, because they are important.

If we are to reap the benefits of being a large organization, we really need to see where we can reuse. And I mean this very seriously. Otherwise, we will just be outcompeted by the startups. We need to figure out as an enterprise, where can we have our strength? And that is actually an enterprise technology capability. So we have a security operations center.

It's a big investment for us, but we have around the clock engineers at work ensuring that we are protected, we have the appropriate security posture, and they can respond, right? We also have a shared service desk, as I'm sure many of you have.

That's also an enterprise capability. Cloud management services, command and control, classic ITIL incident management processes. Not to fix it if something goes wrong in a DevOps space product, but just to manage the organizational impact it has if a critical business service goes down. Now, that's an enterprise capability. It adds a lot of value.

Centralized DevOps tool chains, and of course, a concept for infrastructure as code. And we agreed on a short list of technical capabilities that we wanted to share across all product teams.

However, it came with a price. What we decided at this time was to be a little bit inspired by the AWS engineering teams here. And then not just build and agree on capabilities that then would be gates for any product teams, but have as a requirement to have these capabilities to be, one, self-service, and two, automatable, right? Because if we ensure that they're self-service and automatable, we can also ensure that any team using these capabilities can do so without having to wait, without having lead times to do so. So just having this API mentality that if I provide a service to others, then I must do so via an API or via automation and self-service. And this really drove the next part of the conversation.

So, and there we are. Now, at this point in time at Maersk, we had a really nice PowerPoint that talked about how we do DevOps, what kind of shared capabilities we should have.

And that's probably what we had. And at this point in time, nothing really happened. I'm going to be really honest with you. It was a really nice PowerPoint. All the directors, senior directors, they had said, "Yeah, that's what we will do."

But it was still just a PowerPoint. So what we did with this was we kind of had to figure out how to operationalize it. And here's my easy guide to realizing DevOps in the enterprise. And, yeah, I'm sure you get the joke. So first, let's talk about where it hurts, right? And let's turn those pains into opportunity.

Secondly, let's drive awareness. Awareness on the benefits of aligning to this way of working. And then rinse and repeat, right? All over again. Everything here is circular. So now I'm going into that part of the presentation where I will be a bit more pragmatic on what we did as a company, and give you a few examples on how we realized these opportunities that we saw. So number one, agree on pain points and opportunities.

Here is a very good practice that I have used for a number of years, and it's called value stream mapping. And you can have experienced it in many different flavors. But it is a lean way of working, originally from lean manufacturing, but has been translated multiple times into technology.

And there's some good books out there that I can only recommend looking at. However, if you can get or if you have in your organization some lean practitioners, you might also be able to get some support here. The value stream mapping process is really about mapping the end to end of how we create, how we go from idea to production, how you go from realizing that business potential into actually serving your customers. And we look at the end-to-end development process.

What the unified delivery model is about is the end-to-end development process. And the practice we used within value stream mapping was the macro level mapping, right? So we don't really look at each process step. Now I need to do a Git commit. Now I need to do a release to my pipeline, et cetera. It's not about that.

It's more about the macro level steps you have. So in the end-to-end process, we mapped out these maybe 15 to 20 different steps. We did it with the stakeholders. So, the thought leaders within the engineering community, from the IT organization, people representing these capabilities that I talked about earlier.

And of course, we brought in some experience on how to drive these conversations. And it's a two-day workshop, and it's absolutely worth it. We are looking at and learning how we work as a collective. And you, when you do these exercises, you would be surprised.

So here's an example from a way back, where we have from one hand, on the left-hand side, we have the idea. On the right-hand side, we have the customer. And how does an idea flow through the different macro level process step into production? And what you then do is map out how long it takes, who is involved, what's the lead time, et cetera. And what we derived here was, and actually we've been using this tool for a while, this, again, we went from 24 months release times to 18 months, and actually today, we are able to drive this down to weeks, of course excluding the actual development process.

So really, really a powerful tool when you're driving these conversations. The second part we did was we introduced an assurance framework. Now, in my presentation here, I call it awareness, and I will tell you why in a second.

But consider in a waterfall process, you have gates. We have release gates, and they all serve some sort of risk mitigation. But if we have an empowering culture, would we then introduce gates? Probably not, right?

So we kind of changed the analogy a bit here and also the purpose. So we can see that we have what the gates did in Waterfall was they provided assurance. For example, let's have a security gate that provided security assurance that, for example, we have done penetration testing.

Now, in a DevOps model, you probably want something more empowering, and that's where we came up with beacons. A beacon being the lighthouse that guides the vessel through the sea and safely to port. So I'm sure you appreciate the maritime reference here.

And we just created beacons, like an MVP set of beacons of technical requirements for each of the capabilities we had agreed in the previous retrospective. And we then worked on the automation and self-service part to drive, make sure that all these beacons are self-service and are automatable.

And then actually you turn something good from the classic model into being something that's empowering by still doing the purpose really is driving the assurance that, yes, our apps are secure. And let me just try to give you a few examples here.

And actually allowed myself a few screenshots on how we monitor this. So our support tool here is called Admiral. And inside Admiral, we manage our unified delivery model.

And the beacons here shows whether you are good or you have a risk in your delivery. And here you see I have one risky beacon and four that are positive. Here's an example of some of the checks we do within the beacon, where you can see we are cost aware inside our delivery. So really a way of driving awareness inside the agreed technical capabilities.

So and then we basically start over again. In February this year, we started with a new group. We have very much focused on engineers, software developers, and infrastructure engineering.

And the new theme was developer productivity. And there are really good initiatives. I even had workshop this week to find out new items we can focus on to optimize our process even further, bringing down our time to production to even less, right? And the target is that we want to be able to release an idea we got Monday. We want to get it secure, all green beacons in production by Friday.

And when we're there, I'm probably sure we will drive it down further even. We will never be satisfied, that's for sure. So I promised Gene I would just finish off with some learnings and also what's next for us. And I think I've been through most of them here.

Lean is really a strong tool, and agile for that matter, to drive the conversation, to build the evidence. And you also see, I talk about 24 months, 18 months now down to weeks. This lean has really helped us build the evidence that we then in turn can show you today, but also our leaders here.

What's next for us is even more of the same, right? Our focus is very much on driving the end-to-end development process, and focus on engineering productivity. How do we get more? Or I would even put it differently, how can we remove waste from our engineers so they can focus on business value?

We also have a new CIO and with a new CIO comes a lot of changes, a new operating model, and I'm very excited. Of course, I would say that on camera, but I'm also in fact very excited. But of course, we need to cope with the new operating model that comes with a new CIO.

And then actually, we are quite successful here. Everyone wants a beacon, right? Everyone that wants to add value to the development process comes to us and asks for a beacon. "Can you help us build this beacon?" Or even, can the classic delivery products shift left in the process and onboard UDM DevOps or continuous delivery? So it's a good thing, but we have a lot to do. We have a lot of work ahead of us, and again, we need to continue to improve our delivery process and perhaps I can come again next year and tell you how far we've gotten then.

But we are absolutely not done. So with that, I want to thank you for tuning in. I hope this story was interesting. I would for sure have liked to have known what I know today a few years ago. So I hope you can take what you can from the presentation, and of course, I hope for a lot of good questions today as well. So thank you so much for tuning in, really appreciate it.

Thank you.