What if DevOps Changed How Every Business Runs?

In this Tech Barometer podcast segment, explore the benefits of bringing software developers together with IT operations managers, a combination that generates continuous business value, according to Mark Lavi, principal DevOps advocate for Nutanix.

By Jason Lopez

By Jason Lopez March 26, 2021

DevOps typically refers to removing friction between developers (‘Dev’) who build software and operations people (‘Ops’) who have to run it. But there’s much more to it, said Mark Lavi, principal DevOps advocate for Nutanix.

His definition goes much further. 

"It’s about removing the friction between developers and the customer," Lavi said. "DevOps isn't a state; it's a constantly evolving process. Removing friction means finding all of those barriers [and] understanding how to deliver your business efficiently."

In this Tech Barometer segment recorded in 2019, Lavi explains how a DevOps approach breaks down barriers and makes things work together and speed time to market.

True DevOps is a two-way street, said Lavi. Organizations sometimes focus their efforts on the speed and frequency of deployment. That's valuable, but it's equally important to improve the speed of information coming back from the customer. The better this feedback loop, the more software will deliver what customers want, which unlocks revenue and profit.

"If we don't have that feedback, then how do we know the developers or engineers, or product management, or business development folks, or any of our leadership is actually encompassing the consumer experience and their feedback and their needs?"

RELATED

Why DevOps Brings Business Value

Transcript (unedited):

Mark Lavi: What would you do? What would you say? What would you think if I told you that I could help accelerate your business infinitely for the rest of your life, for the rest of your career, starting now, would that be of interest to you? This is a DevOps outcome.

Jason Lopez: That's Mark Lavi, the DevOps solutions architect for Nutanix. Here's his definition of dev ops. It's the process of removing all friction between the developer and customer value. The way you remove friction is by identifying the barriers to efficiency. Lavi has worked in it for more than 25 years and has been involved in DevOps ever since it emerged as a standalone practice about a decade ago.

Mark Lavi: Practice that is constantly evolving. We're always improving our craftsmanship. And not only that, there is no beginning and there is no end to this. It's a mindset. If you don't know the value process of how you produce your goods, your services, all the way back from the original creators and authors, then you can't actually understand whether or not you're doing in an efficient manner, or if there are any process improvements that can be done or even worse. If you don't even understand your internal processes, you can't find the friction points in those value chains of delivering value. Then you can't actually understand whether you're delivering your business efficiently or even well, the correspondingly that value chain is by directional. We also have to map the value from the consumer of any of our value services and products back all the way to the developers. Because if we don't have that feedback, then how do we know the developers or engineers or product management or business development folks, or any of our leadership is actually encompassing the consumer experience and their feedback and their needs.

Jason Lopez: Here's an example, an organization has relationships with 17,000 developers. You have that many in this case, the organization does not have good control over the processes of how its developers build test and deploy. And they don't have a way to measure success, which means they can't ensure how effective those developers are or how to make them happy. Now, you might think from this example, a DevOps pro would come in and install a communications platform or some other organizing technology.

Mark Lavi:  Technology might be the primary driver of some of the discussion. That's not the actual constraint of what it is. Its constraint is the entire business. So I really look at dev ops as being, um, a manner of, of really just figuring out how to efficiently run your business. If the only reason why a vice president might need to make the approval of a release of a change or an improvement for a customer right now. Well, if that VP could institutionalize whatever the acceptance criteria he would use or she would use, well, then we don't need to have a person involved in that. And we've reduced the friction and delivering that value. So whether that's a technology implementation doesn't matter, the first discussion is what is our business optimization needs. Uh, whether our government's needs really are hamstrung by people because we haven't found the right solution. We haven't found the right technology, or we haven't found the right, uh, assessment of whether or not we're actually blocking or slowing down the delivery of our business.

Jason Lopez: Lovey says the constraints of business experiences are not just the obvious company-wide challenges. Friction can exist for one group in the organization, but not

Mark Lavi:  For another. When we talk to different audiences, they have their own constraints on their part of the business. I'm on the operations team. I only care about delivery to customers in production, but I don't necessarily care about developers delivery of value on development stages or on their laptops, because that's not my area of expertise, but the truth is if operations folks can't help the developers do their work or even do the same work that they're going to do in production, then they've created a disconnect. And so that's how you can say a developer doesn't know what a performance issue is in production because the operations teams have blocked them from understanding even how to understand the performance or even create the tooling and instrumentation of understanding of performance problem on their laptop should be the same tooling that you use in production. So that again, you have a unified way. There's no friction between what you do here and what you do over there. So DevOps helps reduce the silos between all of those value chains, all those different silos of the organization, all those different teams, their cultures, their SLS, their business principles, and finally makes it a continuously shared responsibility of delivering that value.

Jason Lopez: He points out that DevOps is a practice often misunderstood. There are critics who rhetorically ask. If everyone in the organization just does their job, what's the need for DevOps. His answer is that DevOps is an approach and it's not a response to new problems or novel tasks. Those problems and workflows always existed. Dev ops is a way to organize solutions.

Mark Lavi:  Morphous term. You can't buy it. You can't sell it. You can't certify it. Although all of our vendors and even us to an extent will say, well, this is a DevOps platform, or we will give you a DevOps outcome or we're DevOps seeing this thing, or this use case is dev ops. And all of those are various aspects of, again, pointing to this amorphous term. And if that's the right bridge to a customer, connecting to how to start to look at running their business more efficiently, and then by the way, we have a product or a solution or a technology to help foster that that's absolutely fine.

Jason Lopez: Mark larvae is a DevOps architect. His official title is dev ops advocate for Nutanix. You might check out his blog post on the subject, use the search terms, Mark lovey that's lav I, what is dev ops and why? Now, this is the tech barometer podcast. I'm Jason Lopez for more tech stories you can find them at www.theforecastbynutanix.com

Jason Lopez is executive producer of Tech Barometer, the podcast outlet for The Forecast. He’s the founder of Connected Social Media. Previously, he was executive producer at PodTech and a reporter at NPR.

© 2021 Nutanix, Inc. All rights reserved. For additional legal information, please go here.