Guillermo Martinez

Hi, everyone. Welcome to the Shell App enabling DevOps in mobile ecosystem presentation. This presentation goes around a DevOps transformation that we are currently running for Shell, for the most famous applications they have in the market at the moment. The logos that you can see here in the left is, of course, Shell logo, who is the client that we are working with. Liquid Studio, which is a department from Accenture that is specialized in DevOps enablement, DevOps delivery, and full-stack engineering. And Accenture Interactive, the creators of the application from the design point of view and implementation. Here in this presentation, we have Samrat as DevOps enterprise architect from Shell, Bas Duprie.

Hello, Bas.

Bas Duprie

Hello.

Guillermo Martinez

And myself, Guillermo Martinez. Both of us, Bas, myself, are from Liquid Studio. We are DevOps architects within that. So, well, let's start into the context. What we got from the beginning. Well, basically Shell at certain point, when they were already quite mature in terms of agility, when all the teams were working in a Scrum manner and they were releasing the application every couple of months, they were looking for a way to increase the business agility. They wanted to increase, of course, with the quality and satisfy the customers in a faster manner by reducing the time to market. So basically increasing the value. So within these three points, we thought, okay, is there anything we can do to achieve them?

And we consider obviously DevOps, because at the end, DevOps is made for that. This is the spirit of DevOps, these three boxes. But well, as you can imagine, there is a lot of doubts about what is DevOps and what it's not. So initially, one of the things that we were asked was to do the CI/CD, the famous pipelines that we are always doing here and there. Continuous integration, continuous delivery. However, I don't think just with CI/CD we can achieve the three goals we defined at the beginning. And therefore, the first thing to understand is DevOps. When you want CI/CD, you don't want DevOps, you just want automation. When you want DevOps, you want a lot of other things like the organization of the teams, the way of working, the processes, embedding the business, the development and the operations all together, the architecture.

This is when you are going to be able to really break these three points, being able to react to the market in a faster manner and give the customers what they are looking for. If you only do CI/CD, hardly ever you're going to reach everything. And of course, CI/CD is the most important practices or one of the most important practices within DevOps, so it's going to be embedded there. But in order to take advantage of them, you have to change a lot of other things. This is how it is and well, it's something that we like to do that and sometimes has its challenges because of politics and other things. It's not only technology, but it's how it is.

However, there are a couple of difficulties and something to align with the client at a certain point.

Bas Duprie

Yeah. So thanks, Guillermo. Now that we have established that we actually don't want to focus on CI/CD alone, and we want to benefit from DevOps, as a different way of working, we're going to face a few different challenges than we originally were thinking about. And we like to think of these challenges in three areas. We have the people, we have the processes, and we have the technology. And we focus on people first. People are the most important thing we have. It's the most valuable asset. Without the people, we're nothing, basically. Especially in today's world, in the digital world. Then we're going to think about who they are and what they do.

So we're talking about things about as common goals, team composition, coaching, of course, and one of the most important thing here is trust. And then process is all about changing how the people do their things. Things like self-organizing teams, outdated or incompatible policies, mainly for delivery. Think about manual stuff that is there because of policy and not because of limitation. Things about security, outdated or incompatible security policies. The way people communicate their stuff, report their stuff. That's all processes. And only then are we going to think about technology because we feel technology is only there to support the people and support the processes to work in a DevOps way.

In other words, the technologies we are using or building for DevOps are dictated by the requirements that the transition on the people and the processes side are requiring. And that's not so traditional way to approach digital transformations. Typically, these things can take years. Here you see a poll from Gartner, where they queried a lot of the Fortune 500 companies about the state of the digital transformations they are doing or have done in the last few years. And here you see that three out of four transformations are not even halfway done. So they are not even delivering any value. But traditional views on implementing digital transformations are very long-term projects, especially traditional views, right?

Especially in a digital world, that means that you are outdated and irrelevant by the time it's complete, and then mainly on outdated ideas, outdated tools, or irrelevant ideas and tools. And therefore, you want to add the transformation value as soon as possible, and this in small increments. Basically, you want to apply the DevOps way of thinking, not only to what you apply, but also how you apply it. The view expressed in this slide is very traditional, right? It's a real recent case that was applied at a big firm. So it is to show that in the current world, we're still approaching these things in a suboptimal way.

Guillermo Martinez

I totally agree with you with this point of trying to avoid approaching a transformation in a waterfall manner because otherwise you are not going to see any result in the short term. However, there is something that's-- Well, you need to define a starting point. We are always running the transformation following this domain of assess, plan, implement, and improve. That, of course, can sound a lot of waterfall-ish way of implementing. However, we are not really doing like that. Initially, what we did initially is, okay, let's focus on the assessment and planning within two months. We need to understand what we have in front, how the teams are working in the technical domain, in the business domain.

So we stay with them, sitting up with them, working with them, just really understanding what they were doing, what type of practices they were following, what type of practices they were not following, what type of tooling they had or they didn't. So really understanding the current situation, basically, one, just know what we have there. And then, of course, coming with a plan because it's, especially for the business, they want to know what's going to happen, and it makes sense to have some planning in order to understand, well, those are the actions that we are going to take based on the inputs, based on the assessment that we were running.

Those are the most critical points to cover, and basically, this is how we approach everything. Some of the deliverables coming from here are architecture designs, roadmaps, DevOps vision for the whole company because, of course, you need to have an alignment or the governance, even a proof of concept just to show, okay, this is how everything could look like. And after that, this is when we will move into the implementation and so on. That will go later into the presentation. But first of all, let's focus on this assessment and planning, and let's see what we found from it.

Bas Duprie

Yeah, but let's take a few step backs, right? What's the context of this transformation? What apps are we talking about and the what and the who? So if you go on your smartphone right now, well, don't do it right now, after this talk, but if you search for the Shell app, you find one app, and that's the app that we are talking about. And on the screen, you see some context about this project because it's not a little app. It's a big app. It's used by more than 1.5 million users each month in almost all markets that Shell is active in. So technically, we're talking about six programming languages. Well, that means that it's a really big technical thing, especially if you talk the technology side of DevOps, that means that we need to have a lot of technology to support that.

There's more than 15 components. Well, if you talk about microarchitecture, stuff like that, but there's also some legacy monolithic components. So there's more than 100 people working in this project in more than four countries in the world. And they're working together in all ways that you can think of, mainly like we do right now, all because of the COVID-19 crisis, remotely. But there's also a lot of traveling happening, and that means a lot of communication and a lot of alignment. Okay. There's a lot of things that we want to measure, right? Lots of things that we want to see going well in the scope of the DevOps transition. So there's a lot of data, and you don't want to guess that data.

So from good DevOps practice, we want to have reliable and transparent data to base decisions on. So early on in the transition process, we have the tendency to run with people's feelings about how things are or like guesstimates. But typically, those numbers are clouded by false assumptions. So measuring things is very important. There are a lot of things we can measure. And it's really hard to decide on what you want to measure and what makes sense to do because to really understand what the numbers are saying, you need to know what they mean. So we're measuring things mainly for us, the teams, not to report to higher management. That's a whole different story, of course.

We want to have the numbers to base decisions on about what's delivering value and where is the value to be found in this whole transition process. So once we have these KPIs in place and we have some workable numbers there, we can move on to the next phase

Guillermo Martinez

Yeah. And next phase is basically getting things done. That's when the beauty starts, when really the action happens. We, as engineers, we, of course, like to make things happen and solve the problems. But yeah, so things that we came out from the assessment and planning are just basically what Bas mentioned. We've been able to understand what was the landscape of the application, something that at the beginning we had no idea, or defining how we want to measure success, how we want to measure that the transformation goes well or not. And yeah, from that point, it's the moment of really taking action. And by taking action, we mean implementing and coaching everyone into the process and technology that we defined previously during the assessment and planning.

Something that very important to consider and something that sometimes, well, I've seen places where it's not considered is different technologies might deserve different tooling and different way of delivering. Same as different teams, different ways of delivering. There is no one size fits all in this scenario in DevOps. Most of the times, it's one size fits one or couple of them, but not everything. So that's how we did it here. We created, first of all, an architecture reference. An architecture reference that shows not only the delivery and doing delivery tests, but also the technologies and how they are going to be approached. And then box by box, the idea was to go and implement all of them based on the customer needs, obviously.

And customers, in our case, are the actually developers, testers, operational guys, business. Those are our customers. And how we approached it this way, how we executed this action. Well, just think about that friend that you have that, well, you didn't see him in six months or one year. When you see him, you really think like, "Oh, that person has changed a lot. You didn't have a beard. You even have hair in your head, and you don't have it anymore." Well, we don't want to have that feeling. We want to work in a manner of a continuous way of working. You don't see the change from one day to the day after. You feel like nothing is changing, but a lot of things are changing, but we don't want to disrupt you in that manner.

And then when you look back six months or one year back, it's the moment when you see like that person, it's bald, or it's actually happened a big change for him. This is the way how we want to do it, and this is how we are doing it, basically. One of the things that we cover always is the user, the needs of the people. That's the first thing to start with. First of all, we need to understand what people want to do and how they want to do something. And then we use technology to achieve that goal. We don't want to go and fall into the waterfall way of transformation that we defined at the beginning because that will be a big mistake. You want to approach the DevOps transformation in a DevOps manner, which means in a continuous way.

Why we do that? Because imagine that you are going to change everything, and suddenly, the moment you change is after one year. After one year, you have kind of a big bang of a change where you enable all the automation and all these type of things. That will be a big challenge for everyone to understand and take part of that. So that's why we work in a different manner. As mentioned, we understand the user needs. We support their needs with technology, and we do that with every week. We have the global vision of covering the three points we mentioned at the beginning, which is business agility, the quality, and the customer satisfactions. We define quarter goals to have some big targets, but then every week, we are changing the priorities, understanding what are the new needs, and implementing these situations.

So basically, what we do every week is go talk with the people, understand what they need, implement a solution that fits and can solve their needs, hand it over to them, hand it over to each of the teams so they really can give us the feedback in terms of if it's what they want or not, so we have to change it. And then we hand it over to them. And this is the moment when these teams are becoming DevOps. We are not here to do all the delivery actions for them. We are here to, let's say, build a car or build the first structure and then let the team drive this car and do the things. It's making them becoming DevOps. It's enabling DevOps for them.

As an example, let's go to a hotfix development and delivery. I'm going to compare what was the situation in non-DevOps versus the current situation on DevOps. And I'm going into a hotfix because it's something that is crucial for customer when something doesn't work fine, and it could be a bug, but it could be also performance. These customers needs to have a solution as soon as possible. So let's go into this scenario where we are going to implement a hotfix that will take three hours of development and is going to have two unit tests, one bug at code level, and also, we are going to put there a deployment issue. Actually, there was a real scenario that happened.

If you see the graph there in the axis, you see the time, time in minutes, how much time it took to run everything. And in the Y-axis, you see the different delivery steps from implementation to the testing, to the hotfixing, to re-implementation, to checking validation, and so on. Well, in a non-DevOps situation, it was taking a lot of time, more than two weeks to be able to deliver a hotfix because we were waiting a lot for having the actions done. So despite the implementation could be fast and then testing even we had some automation here and there, we were waiting a lot between the different delivery steps, between step and step in between, let's say, implementation and testing and revalidation and retesting.

We were waiting a lot of time. And this is why it was taking huge times to deliver results. While if we do it in a DevOps manner everything is in a continuous manner. You implement the three hours hotfix and then everything is starting to run continuously, and then you are going to spend some time on fixing and so on, but it's a fix that you are going to apply over something that you develop 10, 20 minutes earlier, not something that you develop three, four days earlier. Some of the big things that we gain from this way of working in DevOps is obviously the speed, even more than 23 times faster. But one of the things that I would like to mention is the broken develop branch.

In a non-DevOps situations, we were putting code that was not properly working in a develop branch for 50 hours. It means for one week. DevOps, as we said, is not about technologies. It's about changing the way we work. It's about adopting new practices that makes everyone be more efficient and this was one of them. The branching strategy is something that we changed. There is not that much technology around it, it's just a way of working. And in the non-DevOps situation, we were just placing code there that was faulty and then we had to fix it. And the thing is we were putting faulty code there, not only from one developer but from multiple developers and then at the moment you have to fix something, you have to deal with a lot of code from other people and that could be tricky.

That could really result in inefficiency. So that's why we gain a lot of speed and also a lot of quality. Some of the other benefits we got is traceability on releases, understand what we are going to deliver and where and what type of version we are putting in place. Business involvement into the delivery by one-click approvals, for instance, or automated communications. Also real-time alerts, something quite useful to understand the situation. So therefore we implement a lot of solutions not only in technology but also in the way of working and the processes and of course in a cultural aspect, changing the mentality of the people as it's very important to adopt this new way of working because it's something new.

And still we have a lot of things to do. Obviously, DevOps is in our case a continuous improvement activity where there is no end state but a better one. It's just you always have to do things. There will be always something to improve. Currently, we have implemented CI/CD for all the teams. We involved business into the delivery pipelines. We increased six, seven times the amount of testing executions we are running. But still we want to do more things. And the next steps that we are going to cover is the implementation of Device Farm for further testing, testing in the cloud with physical mobile devices. Something quite cool. Something that we are looking forward to implement.

Advanced release orchestration. Next steps on monitoring and alerting to really ensure that the application is always working and not only from functional point of view but from performance point of view in a very good way. And we will put as well some teams acting as SRE because now that all the teams are DevOps, now that all the teams are able to implement and deliver themselves, it's time to go to the next level. One of the things to mention is, of course, you might think like why you didn't start from monitoring or from operational point of view and you focus initially on the delivery automation. Well, basically it is because that was the big need of the teams.

We already had in place and we already have it at the moment a good support. The application is almost having no issues but of course there is always things to fix. But we were looking for the speeding up the teams and converting them into DevOps. And as we said, we focus on the needs, on the people needs. In our case, our development, our operations, our testers, our business guys needs and then we implement that way. Well, that's basically all. If you would like to know more, feel free to contact us by reaching out by email or connect with us in LinkedIn or use any of the conference channels here. It has been a pleasure to present this scenario to you.

I hope to see you again in the future. Maybe not in a digital way but in a physical way. Who knows? And I will be glad to give you the next level, next inputs, what happened afterwards in Shell, in the Shell app, what's the next steps and show you the evolution that we are doing. Thank you very much. Thank you, Samrat. Thank you, Bas. And thanks audience to be here.