Akash Tayal & Bob Vuong – Scaling DevOps across the Enterprise

Hi, everyone. This is a Akash Tayal, and I'm here with Bob Vuong, one of my colleagues, to discuss our experiences around how do you scale DevOps across the enterprise, but very excited to have this discussion with you and share some of our experiences and learnings from this. Very quickly, we're going to spend some time going through how we define DevOps to begin with, because, as you know, there's slightly different variations in definitions of it.

And then we want to describe to you, you know, what is the kind of journey we see our clients generally taking and the challenges they see in that journey and then spend a majority of our time towards describing based on experience. How do you actually scale that adoption? How do you drive that adoption measure to success?

Some of the ingredients for the success and what are the kind of gaps we're seeing in the industry and closing out with a quick case study of a successful experience. With that, let me just give you a quick background of us and our team here, so this is a Akash Tayal, I'm a principal and I lead our cloud strategy practice across the US. As part of the strategy practice, we essentially help clients get started on the cloud journey all the way to executing.

And then these situations where they find issues or they get stored in the cloud journeys, help them reset and evolve into a scale model for adopting cloud. And my colleague Bob is here with me. I want to introduce yourself to your cash.

Good morning. My name is Bob Vuong and I'm a principal partner of Deloitte's Cloud Practice. I also co-chair the DevOps practice and where a lot of synergies between lower cost narrative or is where implementation be strategy.

So where Akash generally helps clients think of the overall strategy for DevOps adoption. I'm more into the implementation operations base where we actually get our hands on the keyboard as well as sustain that environment over time. Akash, back to you.

Great, thank you. And just for your reference, you know the size and scale of our team here. Deloitte, as you may already know, is the largest professional services firm globally of all.

Almost three hundred thousand people have published a lot of evidence pieces around this topic, as well as large scale organizational transformations. We have a lot of wide variety of tools and accelerators we bring to bear. We'll give you a quick view of that today as well.

And then it's a globally integrated capability, because what we really see is that you're doing cloud not for the sake of cloud, you're doing DevOps, not for the sake of DevOps. These are cool words. But what you're really trying to do is you're trying to drive towards business outcomes.

You're trying to change the view of IT from being a cost center to a value driver to a business. And that's how we bring all our offerings in an integrated way together to help our clients drive that success. So with that, let me switch to our topic at hand.

So first of all, what is DevOps? So if you move to the next page, so the way we think about DevOps, it's truly a transformed software delivery approach. And what we are looking forward to is essentially using DevOps to deliver an experience, to deliver a method that helps you be delivering better value sooner, safer, happier.

So let me tell you what that means. So better quality software, better quality applications. Right.

Delivered in a faster pace, sooner right. Flow efficiencies, greater in a safer manner to make sure security, compliance and all of those things are big then and it's not breaking, but it's sustainable. And in all this, the value delivered is not just from a business standpoint, but the process of delivering is also happier.

So both for your developers, your employees, your colleagues, as well as more importantly, your customers. So you're delivering better value sooner, safer, happier. That's how we can actually define what a DevOps means.

And what you will see is that there are two parts that come together to deliver the DEV part in the OPS part, and that's what that infinity sign at the bottom is. And we'll cover that in a lot more detail during the session. But the idea here is to take those steps of the journey and make them seamless so that developers and technology folks can focus on driving real business value rather than getting stuck in the processes.

So that's how we think about DevOps. And then if we move to the next page, you know, by DevOps. Right.

Why is it important to do so? In a nutshell, our research and experience has clearly indicated that, you know, people who do this well, organization that do this well can drive as much as forty six times more code deployment's into the production than the people who don't do this. Right.

So I mean. Forty six times that's a mess. And that too at a seven times lower change failure rate.

I mean that's just powerful. And that's why we think that DevOps is the journey that a lot of organizations are already taking and are being successful. T.

budgets are allocated towards 30 percent of that towards business innovation. And we need to change that because a lot of that time and effort should be spent in building new business capabilities and deploying it so that it can help business drive differentiation and outcomes and less about just running the IT and the changing landscape is really driving that the speed of technology, innovation. Especially with the Covid, the whole acceleration of digital transformation, virtual collaboration that has come with it, you know, all these things and automated processes.

Right. But automated processes not just to say for automation, but to drive efficient handoffs and seamless visibility across everything that the developers are doing for the business is where we see DevOps really being very, very powerful. So that's what we mean by, you know, DevOps and why you should go through that journey.

So let me pivot a bit and describe to you how we see the current journey that organizations are taking and some of the challenges and how we think about eliminating and solving for those challenges. So number One, if I'm a CIO, you know, what am I worried about? What what are the things that are top of mind for me?

So those are things like enhanced security, compliance and governance. I wanna make sure whatever I do, whether on prem or cloud, is done in a way that it's secure, it's compliant, it's the government right. Two, it's done at affordable cost to my business.

You know, if IT is taking off significant points of the margin base, that's not good for any one of us. So we want to make sure it is doing IT in the most efficient cost reduce we have possible. At speed to make sure that we're delivering things that are faster.

I mean, we have seen this example where an investment bank set up a retail bank and basically took over deposits from a lot of different banks as market share. We saw a car manufacturing company start building ventilators and ramp that up faster than even the manufacturing companies that could do. So this is where agility and really driving business disruption would help from an IT standpoint.

And then obviously all that delivered through the enterprise platform that enables your developers to focus on delivering business capabilities to your business in high quality, faster way. So those are the kind of things we typically see CIOs that they want to achieve. And today's answer to those capabilities is a lot of different tools, as you see on this page.

I'm not going to name any one of them, but you can imagine that if you take this step process and just take any one step of it. Let's say coding, right. The source code management, the integration, the bear, the database management.

I mean, the two choices are immense in this space. And what happens in this is, you know, every business unit, every developer has a very religious preference around this. So what as a CIO or the executive you lined up then is a lot of stitching around all these tool sets to come together and deliver a single pipeline for your application and while that is great, but the amount of effort that is required operationally and engineering less to deliver that is immense.

And it doesn't help that the number of two choices is only expanding exponentially. So we see a lot of the challenge around just stitching this together and making it sound like it's done for an enterprise, not just for one application. So that's, I think, number one challenge we see.

The other part of it is what you see in this infinity is just the eight steps. There's a lot more to this from a software development and delivery lifecycle management standpoint. So if you go to the next page, you know what we'll see?

There is there's a lot of other things, you know, continuous testing, security, progress reporting, application monitoring, all of those things. And what it does is it takes the the youthful energy of the developer towards managing a lot of different things, which are not directly related to developing new code. It takes all that energy and it focuses towards and starts driving bandwidth issues.

And, you know, security and compliance is a lot more reactive than proactive on this. There is no visibility as to where I stand in that pipeline process, exactly what issues are blocking it and who owns those issues. And those are some of the really complicated challenges we see our clients facing today, which drive some of this challenges.

So in a nutshell, if I just have to wrap up the challenge, decide to go to the next page. But from a business as well as an IT standpoint, there's a lot of things that we can do better, right. And in the end, the single most goal is can we spend less time on the store and more time reducing the cycles and the cost of texturally software and make it faster, cheaper, better.

As we said, better value, sooner, safer, happier. Right. So in order to do that, some of these challenges need to be addressed directly, whether it's about, you know, the timelines, that it's about functional or operational, regulatory or from the standpoint of resources and skill sets, how do we create that agility within the organization with the right skills to deliver this?

And what we're trying to get to is DevOps is not just a technology journey. Technology is only one component if it's truly a mindset shift. And that's what I want to emphasize on because, you know, can we engineering wise build and stitch together all these tools to build a pipeline.

Absolutely we can. But can we scale that? Probably not, because if we do that for every single business unit, for every single application, we cannot really scale it and then place them.

And that's what we have seen our clients challenge with. So with that, let's just look at how do we actually solve these issues? How do we think about a process for delivering that?

So we're going to go into a lot more detail. But let me start with you. What are some of those basic enablement activities?

So if you are starting from scratch, you know, CIOs can really influence the business leaders on how exactly to move technology forward and drive this adoption. So what that looks like, you know, number one, creating that alignment and focus. How do you do that?

Well, let's describe what is that future developer experience going to look like? What is the operating model that will deliver that right. So get into the low end side of it.

Start thinking about taking a group of applications, doing some portfolio analysis and seeing which applications are going through the largest number of changes, which applications are truly a business critical, which applications? We want to pilot to this because that's where you're going to see the momentum shifting built up to say that I've described my DevOps operating model, but let me apply to the most serious problems I have to the application that go through the most changes and start showing that progress. And in that process, bring my organization along the the DevOps or the workforce, redesign the skills around it, upskilling them.

That will help you not only test in prove and pilot the model, but truly start thinking about improving your capacity. You don't want to be doing it at a two teams, three teams, four teams level. You want to do want to be doing it at an enterprise level.

And that's the idea behind that. And then from there is where you can start scaling this to an enterprise or adoption and then operating through that. So now I describe the enablement activities.

But, you know, this is where I see organizations. They generally started the transformative pilot phase level and not really have some of the initial steps taken on. And what happens in that process is a few things.

One, you do a great job of building a pipeline, but it stops at the moment. So you do a great fast released to dev environment. But to get to production, you need all your approvals, compliance, security, all of those.

And hence, but you can say that you have a pipeline. It's not going all the way to production, which means you are actually solving one part of the problem, but not really changing the way and the pace at which you are deploying application and changes in production. The second part of the problem is you look at it from an individual business unit lens.

So every business unit with every developer may have their own preference of tools and how you stitch the solution together, essentially making it five DevOps journeys rather than one. And again, neither one of them will help you scale. So what we have come up with is a way to think about it a bit more Bottom-Up to think about it a bit more.

How do we engineer a solution that can drive that mindset, shift not just the technology, but the true mindset shift and deliver that. And I'll invite my colleague Bob to start describing some of those operational elements that we have done for our other clients that have actually shown success. So Bob, over to you.

Thank you, Akash. So it's the Akash describes a lot. A lot of our clients are actually embracing this journey already.

They're taking on at least developing the strategies for DevOps looks like the organization and starting to implement certain aspects of what they consider a DevOps and try to proliferate, proliferate that to all parts of the organization. Some are successful in developing a CI/CD pipeline. Some are successful, of course, correcting what they've done with parts of that pipeline.

But I think what we're seeing now is that it embarking on this journey is much more difficult than anticipated. Getting all of the firm to find a an organization to buy into the actual change requires not only the top down approach that cost talks about, but. Also really a bottom up approach, really enabling each of these teams to understand what it means to develop code.

faster to be part of the business and to entwine it into all parts of what they're doing. So as we talk about overall, DevOps journey is critically important to understand what is the role that the working group or the product teams play in this journey? There is...

As you.. As a... as an overall environment is changing, people are starting to see that there are there are critical steps that need to go along this journey to see a lot of my clients now embark on this project, a product in conversion, trying to figure out what the mesh of the development team, operational teams look like, how to implement security in there and so forth.

And so for us, it's about the people process and technology change. And how do you make that part of an entire cultural change? And our perspective is really there needs to be four major pivots to this and four major pivots are what we call it, the pace of the journey.

So in that we actually look at the processes, the architecture, the culture and the engineering changes that have to occur. And all this when it's modeled together have four major benefits to the organization. Number one, it increases agility.

So agility of the organization, the teams go up. Number two, it helps to drive business forward and drive the business value forward. At the same time, we're hoping to reduce toil, the toil that creates conflict and slow things down between teams and and the product development cycle.

And most importantly of all, it helps to shift left responsibility and build. So you're looking more at how do you put code defects detection ahead of the process? How do you build in operational requirements ahead of the process?

And we believe that if you take these four pivots holistic, the process, the architecture, culture and engineering pivots and look at the holistically that the organization can, it can indeed embark on this whole world journey. So let's dove in a little bit into what these four pivots looked like. Akash early on talked about that we've seen a lot of organizations do the CI part of this very well.

But the CD part is kind of where it suffers right, the change from test to production is difficult. There's some manual. The implementation of infrastructure can be difficult because some of this architecture still lives on prem and so forth.

So how do you how do you get away from that space and how do you actually start to allow the coder and the developer in your development teams to have to be greatly empowered? And one of them is understanding the existing processes that live there today in actually developing new processes. And know that this is pretty common when you talk about DevOps in general, but I think I don't think we emphasize enough on how difficult it is to break down some of these barriers.

One of the key ways that we talk about people making these changes is looking at the overall organization. One of the great things that Akash brings his clients forward with it is look at the organizational change that has to occur and what is the new org model look like? So if you create a new org model and understand that no product teams are essential to operate together and that new operating model help to drive new processes, then your DevOps can, in fact, have complete control over the deployment process.

Right. So the CD becomes a critical part of this entire process. And then we also want to at the same time, starting to get more maturity into some of the lighthouse projects and teams that are already part of this journey.

So what we're seeing is that there is a focus on SRE teams and focus on high performance engineering teams and so forth. And with that is a complex adoption of new KPIs. And so SLIs, SOls, SOHs become a major part of the discussion.

But it's a lot of my clients tend to adopt old KPIs, and so it's extremely important is for us to focus on, again, what we talked about earlier, which is the BBSSH framework. Better values are safer, happier, and start to focus on a few of those metrics. Right.

We talked about happier and so no net promoter score becomes a critical component of that understanding. What what actually gets the clients to come back? What actually gets them to talk about your product and voice their happiness and overall reference of that product to other clients?

And so we want to make sure that we start to leverage KPIs minimally just to understand how do you improve parts of the overall adoption. And I would say one more thing about the KPIs is that we generally look at KPIs in three different forms and try to lead my clients this way, too. There is the transformation KPIs, what's happening as part of the procedure, transforming the business led once.

And we want to make sure that that's important because we want to put the business along for the ride. And then finally, the more important I think is the overall adoption metrics. These are teams actually adopting this fast enough of how much of the organization is just proliferating across.

And I don't think my clients pay enough attention to those type of KPIs to understand how the organization is being affected. The next debate that we generally take is the architecture pivot. And this is slightly different from how we would think of architecture, because I think a lot of people think of architecture as the infrastructure behind it.

But we're really thinking about what is the new application of architecture look like. And this comes responsibility to everyone. No longer is it just a software development team.

It becomes a core responsibility of every team member involved in this process. So you have a DevOps pod or a product team. Now, you may have traditional people that are focused on operational services or security services, but they have to actually be very much ingrained in how the application architecture is changing.

And you see trends in the industry now with containerization, micro services and so forth. But there's also new critical factors in how that is adopted, obviously. But things are moving towards the cloud.

Containerization may make a lot of sense because as a migration occurs and as a product team is starting to shift that application towards this new architecture, there are natural fits into which type of architecture you want to leverage. The culture pivot, I think, is probably one of the most difficult ones my my clients see and I, I generally lean towards making minimum viable changes to the culture rather than trying to have Big Bang approaches. So we would love to live in a truly flexible, truly agile organization.

But there are legacy processes in place. There are legacy silos of parts of the organization. There's people who manage different work streams.

And so those things have to come together into a overall culture change. And the minimum viable changes is kind of how how we think of it, right. To pick one team, figure out what works well with that one team that proliferate that out.

So it makes smaller changes into into how the teams are being measured, make small changes to how individuals and coders and developers are being measured, make sure that proliferates upwards, make sure that the leadership is involved with it. So even though it may seem daunting to take these smaller changes, but we see that is that the overall adoption occurs with greater buy in when you have smaller and more viable changes. But but there's no right way to do this.

We hear a lot about the fail fast mentality, but also clients that don't want to fail fast. They rather learn fast. And so there's no right way to do it.

The answer is really to figure out what works well for your organization. It's small, start small, very organization, and then kind of a lot that adoption to breed greater adoption. And the last of it that we take is really the engineering pivot where we start to look at how do you start to manage everything as code?

And now architects and software developers and everyone are are taking a hands on keyboard approach. So we're no longer, you know, having an architect create application architecture on one side and then throw it over the fence for an engineering team, a software development team to start coding. And throw it over the fence for operational team to manage.

Right? It's really everyone has has a key role, not only the operational aspects and the development aspects of this, but they're actually hands on keyboard. Architects are no longer sitting on an ivory tower looking down and say, hey, this is what their architecture standards look like, make sure you code to them.

But it's making sure we break down the silos, not only between the different teams, but through all parts of the organization. So what does it look like? Akash really took the enablement activities and walked you through how we can take the top down approach from to time, but also there's the engineering activities, what actually happens on the ground through the work force?

And there are a few ways that they will look at this. Right. For first, we like to sit down and do some ideational with the group, look at the lighthouse projects, look at lighthouse accounts and teams that have been very successful or don't mind being the front runners of adoption and change.

Figure out what it really looks like for them and how do you actually reimagine that across the enterprise? Now, again, it may not happen across the enterprise, but it needs to happen somewhere. And we picked lighthouse accounts because they're what they generally have a buy in from organization, have some of the thought leadership as well, and have team members that have partially either embarked or partially adopted a lot of this philosophy change.

And then we look at different ways to look to leverage the platform to help drive this forward, as much automation as we can build within the platform, as much automation that we can build within the pilot programs helps also the transformation later on. As for the adoption part of that pilot, we onboard DevOps teams, the team enablement is especially a critical part of this. Right.

And so as part of that culture change, we look for things such as building up GILD's, doing a hackathon and supporting the overall organization with what is a team adoption. The and what do what is education and training like an upscale in the workforce looked like as well. You will also find that as part of this, there is a necessity for overall education and institutionalizing what the practices are for DevOps what we've seen is that coders can can code very well, but they don't know how to operate in the environment and vice versa.

People that are in the operational space have to do service that support may not have a great appreciation for scripting or coding or so forth. So there needs to be a platform for education, for training and understanding what maybe DevOps, maybe cognitive development and modernization look like. And eventually we want to get to the bottom of everything being on the self-service.

Right. The platform itself is of self-service aspects of code and so forth. So we talk through our perspective both from the top down and the bottom up, and how do we actually support organizations throughout the entire journey from developing over a DevOps chat to implementation to actually the full DevOps/SRE mode.

And this is an example of a recent client that Akash and I have both worked at over the past one and a half years where we've actually taken that overall approach with the organization. And they've been extremely successful in adopting not only a cloud, but also a DevOps throughout this entire process. So I really started off with our leadership team going in there and helping to develop the overall vision and strategy for what adoption looks like, setting up a business office, helping to manage that transformation across the board.

And then our team is actually implementing SRE teams across different parts of their business units and then allowing that to proliferate ours. Now, we're at a point right now where we mature the SRE thinking into what the plan to call customer reliability engineering. And we're doing weekly discussions with them, weekly discussions, weekly hackathon and happy having different teams taking on that responsibility.

We've educated and trained in over a thousand people in that organization so far, and it's been a huge, massive shift from a year and a half ago when we started at basically zero over a handful of people to add a thousand people. So it's been quite successful for us. And so the last thing that we like to talk about is we do have a perspective as to how to make this how effectively to this quickly and how to get things going in place.

We talked about the holistic approach it with PACE. But a lot of times our clients do ask, how do I how do I jumpstart this? How do I make this really tangible for for my developers and so forth.

And so we've taken an approach of developing a platform which we call the DevOps Call Platform, a DCP, has over 50 integrated tools, 600 APIs. We've added our own best practice from from from the enterprise of enterprise clients that we supported and what we see in an industry. But I think what's really important about this is understanding that even with something like DCP, it's only a stepping stone.

Tools are... Tools are tangible. You could actually see them being implemented.

And clients generally gravitate towards total adoption because that's measurable, something that you could you could put down and your developers are using right away. But even DCP suffers from the fact that it doesn't it can't help push cultural change forward and it can't help the organization change all of existing processes. So so this is just one of our tools.

And it's extremely important for us to understand that in order for organization to to to become part of this adoption, you take the entire PAC approach, take several components of it, and hopefully leverage tools like like a platform to help with the overall journey. But the journey is much more comprehensive than this. So with that, I think I don't have anything else.

Akash, you don't. I think we should take some questions. Yeah, all good.

Thank you, folks, for your time, hopefully you found this useful, and if you have any questions, feel free to reach out to Bob or me.