How to Implement Enterprise DevOps in a Huge Organization

Good morning, good afternoon, colleagues, wherever you are in the world. My name is Bramley. I'm from Sasol.

I'm very excited to be here today. It is the first time that I'm presenting at DevOps Enterprise Summit, and I'll be talking to you on a subject that I'm very interested in, which is implementing enterprise DevOps in a large organization. So this is a case study for my company, Sasol, and I will take you through the steps.

In terms of what I do at Sasol, just a little bit more details. I'm looking after DevSecOps and the chapters. The chapters are the center of excellence, responsible for standards and setting up of policies. My background is in electrical engineering, software development, pre-sales, and I have experience in IT consulting. I have a passion about education, mentorship, and anything disruptive. And when I do have free time, I play golf.

All right. So what's on the agenda, ladies and gentlemen? Just to go back a bit. I want to walk you through four items that I have planned for you. I will share the business case that we had at Sasol. I'll certainly walk you through the vision from IT as a function, and we'll touch base on how we organize ourselves for success, and look at some of the processes that we've put in place, and finally, the technologies that we have implemented.

So, what's going on within a big organization? Why did we have to embark on the journey for digital transformation? Sasol, like many organizations that were born in the '50s or even much earlier. Those that study technology revolutions, you realize that oil came just around the first, second revolution. Certainly, in the 1950s, we're not far off.

So you will find that we have legacy systems. We invested a lot in SAP, which to a large part, when we embarked on the journey, was on-prem. Our ways of working were waterfall-based, and when it comes to decision-making, it was difficult. And of course, finding data was a huge concern for business. In the end, our business was out looking for alternatives. So as IT, that was a challenge. We had to find a way for us to be relevant, a way for us to stay really current.

So what did we do? We put together the vision that is in line with business. Our vision was the one that is aimed at delivering great value for Sasol, and by doing three things. Deliver great value by focusing on the customer, investing in modern technology, and embracing new ways of working. So this was very key to a large part for Sasol, where, of course, at the time, Sasol was embarked on setting up a digital office. So we had to make sure that IT is geared for that change.

And we put a few enablers in place. We invested in modern ERP. We invested on cloud journey. Primarily here, we focus on moving to Azure. But our strategy for cloud really is hybrid, and we are embracing both Azure and AWS. It's just we have more maturity in Azure. We also recognize the organizational culture shift that we had to look at, and certainly our people, at the core of the journey that we looked at.

From the people lens perspective, we also had to organize ourselves. Organizing ourselves in that the org structure had to follow the strategy. Sasol today is organized in two portfolios. It's organized in energy and in chemicals. And this is where you'll find a lot of execution, delivery of technology taking place. And certainly, if you look specifically in energy, you are going to find two VPs that are sitting in the space, responsible for platforms and others responsible for portfolios. And the idea is that the two of them will work in a DevOps way of working.

And of course, at the corporate center, we had a CIO, and this is where my team lives. And our responsibility is to set up a strategy, a roadmap, standards, policies, templates, and framework. Our core existence is to ensure that we create a digital backbone for business to be able to digitalize.

Now, if you look at the second part of how we organize ourselves, this was really focusing internally into how the teams will go into the idea of collaboration and also the idea of continuous learning. And here we set up eight chapters. Chapters are a way to promote experience sharing, best practice collaboration, cross-pollination of ideas, and innovation across agile teams. Also coupled with chapters, we had communities of practice. These are the communities that get together on a monthly basis to share some ideas, some practices on what's going on as far as thought leadership is concerned.

So what is DevOps anyway? And I feel strongly that although the DevOps movement has been in existence for quite a while, each organization has to define what it means to them. And to us, certainly, we do recognize that if we are to move faster at customer speed with quality and stability in production, we have to define DevOps as a union of our people, processes, and products to enable continuous delivery of value to our end users.

We're primarily targeting the old ways of working, which at the main, we had silos between or amongst customers, development teams, and operation. And our view here was to make sure that those silos are taken out. And we believe that by doing so, we'll achieve really DevOps as a way or a mode of delivery by maximizing flow, amplifying feedback, and lastly, have the idea of continuous learning.

We also looked from technology lens. Folks from ServiceNow will be familiar with this slide. We adapted it and made it more Sasol-specific. But really, the inspiration is from ServiceNow. If I can just spend a little bit of time here, colleagues, just to show you what I actually have on the slide for you is that in Sasol, the ambition is to have two things, doing two things instead of a lot of things that we used to do in the past.

One was that the demands, which are project-specific, they'll go through idea portal, prioritized by portfolio managers, and given over to folks looking at the unified backlog and prioritized with the delivery teams that will actually use toolchains to deliver the product in an automated way. Specifically here targeting key concepts like automated changes, which I'll get into details later on, and also making sure that our products are compliance by design, and we are able to see what the bottlenecks are.

And of course, if things are transactions, transactions are cataloged, items are incidents, those will go through your traditional ITSM service portal. We also want to make sure that all of these pieces are connected. We're looking at automating our GRC, looking at the concept of SecOps, bake that in within DevOps to really have pure DevSecOps, and also look at the future world of AIOps. We already implemented an observability platform here.

But at the core of it, really, if there's one thing that I want you to take away from this slide, it is that everything starts with data and ends with data. At the core of what we do is our CMDB. We looked at CMDB, we looked at aligning our CMDB with the CSDM model, which is the recommendation we got from our colleagues in ServiceNow.

We also worked with a partner, Plat4mation, out of Europe, that really helped us to make sense of setting up the base for CMDB. We did analysis that looked at the data, that looked at how we organize ourselves in terms of people, and we looked at processes that we have as far as ITIL, and we also looked at the technical debt. So ITSM in Sasol has gone through a number of iterations, and it was heavily customized. It's only recently where we managed to bring in more and more out-of-the-box functionality. But there's a lot of technical debt that I think it will take us quite a bit to work on.

Just quickly on technology. We also realized that integration is key. Every piece that I have talked about has to be connected. We knew that if we want to have total visibility, we had to make sure that the items that are being put into a catalog need to be connected to a pipeline. The pipeline, the CI/CD, needs to be connected to ServiceNow where the automated changes take place.

A lot of learnings here in terms of really how the flow was going to go, how we map things like epics, the user stories and tasks on both sides of the world to make sure that there is that continuous flow. In fact, the picture that you're looking at from Azure DevOps was also connected to ServiceNow Agile module. So we wanted to make sure that that visibility happens in order for us to achieve automated changes, which I'll give you some details right now.

The idea about automated change is quite simple. So we looked at where the bottlenecks are, and most of the bottlenecks really sit in CAB. The idea that you would have to log in a call, that about five people need to get involved, depending on what CI you are working on, need to get involved to approve that. And also you have to sit in a scheduled meeting to present. We find that a lot of this can be automated, and that was one of the key visions around automated changes.

But automating that for us was practical. It was about moving from weeks and days to seconds and minutes. What you're looking at is one of our products, quite a great product that we've built, a super chatbot that handles thousands of transactions for our customers today, from service desk to having your passwords reset. We're using the chatbot that is based on .NET framework.

And what you see in front of you is that from packaging the solution from one environment to another, to looking at the quality gates, where there is the security, and to making sure that we still get the approval from the service owner was key. But you can see that everything is actually automated. We went from seconds, 19 seconds, to just waiting for about 40 minutes for an approval. When that is done, it would take about two minutes to put it in production.

So ladies and gentlemen, this is what I call moving at customer speed. And it was possible, I must mention, because we have ServiceNow DevOps module integrated with Azure DevOps.

Of course, if you are going to implement technology, you also have to measure what value you're delivering. Although our measurements, we want to move more from proxy metrics that look at transactions to more value-driven. These are the initial metrics that we thought would give us a better view in terms of people, the culture, if people are adopting the technologies that we have put in place. And I would recommend you do the same.

More insights in terms of what you get out of ServiceNow DevOps module. There's more coming with the new version of Rome coming in.

In terms of takeaway points or recommendation, I would like to leave you with three things. One is that you really have to work on the vision, make sure that this is linked to the business strategy. It's very key. Be bold. Do encourage those folks that are different or masters to really innovate and make sure that when they do fail, folks do fail forward. Also, if you're going to have a strategy, the strategy needs to be powered by the org structure. Have the right people around you. And lastly, do set aside budget to invest in modern technology.

Lastly, if you want to know more about ServiceNow DevOps, go to servicenow.com/devops. Thank you, and appreciate the time. Goodbye.