How DevOps Drives Digital Transformation | Digital CxO Summit

All right, folks. Welcome, welcome. My name is Sharon Florentine.

I am the managing editor at Textron Group. And today we are here at the digital C X O summit, talking about how DevOps drives digital transformation. I am joined today by Mike tki, Mike Vard, and Mitch Ashley.

And, uh, without further ado, I'm gonna keep it short and sweet and just jump right in. So, gentlemen, thank you for joining me today. I hope this is gonna be an awesome conversation.

First question, ready? Mm-hmm. How pivotal a role does DevOps play in digital transformation?

What's the crossover there? Is there a button we have to hit? Can I go first?

You have to go first now. No, just, just go. No, I love that.

I love this topic because, you know, being involved in DevOps for, for a while, quite a while now, is you see how the adoption of curve has happened with DevOps and organization. And I'm sure we have some data, some data and text writing research down somewhere in our database about that adoption curve. But I think one of the biggest, the biggest drivers of it isn't just that IT teams want to do, you know, DevOps instead of some other way.

It's the businesses putting more pressure on delivering more software quicker, faster, or more secure adapting, you know, being able to take risks than market, respond to competitive threats. You don't do that doing, you know, long tail development processes. So I think for digital transformation, that feeds very well into that.

And frankly, that's probably enabled a lot of those projects. Now, not everybody's high in the maturity curve. Some folks are, you know, in that, in the trough or, or, you know, kind of pulling out of that curve.

So, um, but I think very, it's very much so a pivotal part of it. Now, is everybody doing it? No, but, you know, pretty soon everybody will.

I think to Mitch's point, DevOps is kind of the unsung hero of these transformation projects, at least the ones that succeed. Because you don't have all data deliver, you're under a lot of pressure. And on the other side of that coin too, is the DevOps teams.

There's only so many applications you can roll out at a given time, so you need to start prioritizing what there's gonna be. And then there's untold number of dependencies between all these digital business transformation initiatives. A lot of times I think folks go down this path and then they get about a year or so in, and then they wake up and they go, wow, we're doing a lot of custom coding, and we're got a whole process here and a procedure.

And then it's kind of like, look, ma no hands, we're doing DevOps. So they kind of like back their way into it, and then they discover that there's a process and a thing and there's a methodology, and suddenly they're like, oh, I'm hanging with the cool kids, but that's just me. Yeah.

Yeah. I would concur. It's, uh, I mean, for me, I, I have a little bit of a different experience.

I mean, it came from, uh, the major telco, Verizon, uh, they were pushing digital transformation for quite some time, most of my career there. So, to, to me, it's kind of like what part of my wiring, almost like, it's just kind of how I view the world or how it skews the world. Like it is how most organizations want to do business, right?

If you're not doing it in a digital way, uh, you're kind of leaving money on the table. Um, but yeah, DevOps is, uh, DevOps is definitely fundamental to that. Uh, and also my, kind of what Mike was saying in my experience, it's kind of, well, we want to transform, so let's start doing that.

Oh, we have to do DevOps. Um, but then even as part of DevOps, there's just a lot to those sets of practices. Uh, and a lot of my advisory experience, it was pretty obvious that, you know, maturity was lower on things like infrastructure automation, test automation, uh, continuous delivery, all all those things that become part of it.

Uh, but yeah, it's, there is, uh, certainly a lot to it, uh, very heavily intertwined. Uh, and then certainly cloud technologies also. Yeah, it's the, uh, the chicken and egg thing, right?

Which came first, DevOps or digital transformation and how they, how that parallels the, the growth of the cloud, especially with, you know, the pandemic a couple years ago really forced the issue. Um, and that's a nice segue, I think, into talking about whether digital transformation mandated that organizations embrace DevOps. Uh, what do you think?

Well, who is it? Einstein said, the, the, the thinking that got you into the problem is not gonna get you out of the problem. That's my paraphrase of it, right?

Yeah. So I think, you know, digital transformation means a lot of things to different people. DevOps does too, but I think if you sort of take the technical tools and that part out of it, really think about what is it about DevOps that that could be fundamental to digital transformation.

Well, a lot of it is automation might mention automat, uh, infrastructure. Really, it's all of it. But the reason why automation is important is that things are changing fast, and you're having to deliver smaller increments of code, infrastructure, functionality, dusting, whatever it is, in a much, uh, faster R P M P flywheel cycle, if you will.

So you can't do the waterfall, you can't do the kind of, you know, phased approach you might have done in, in, you know, of, of years past. But even, you know, a service oriented architecture still isn't flexible enough to do things quickly. So I think it's a, a really step back and just say, well, what's important about DevOps?

And we could pick on a lot of the fun things about it, but it is getting the cycle time to be shorter, and your ability to increase quality and react to what needs to be done, um, is super important. I don't remember long ago in a galaxy far, far away, when I started my career, uh, I, I've developed this rule of thumb, never be the be the first or second project manager on a new, on a new product. 'cause they always got fired because it was by the third one that you sort of figured out what you're supposed to do.

Well, now we figure that out, out much more quickly in days and weeks and months instead of months and years. Yeah, I think it forces the issue no matter what happens. And I guess my point on it though, would be DevOps is not limited to, you know, the software engineers of the operations.

I think what we're seeing as we go along here is more of a convergence of the idle folks and the DevOps folks are trying to figure out how to work together and kinda sometimes use a graphical tool to automate something. Sometimes they do it programmatically because now we don't have enough people in enough skills. And half the time the developers find it a little easier just to use the graphical tool to do something themselves that could code it, but they got other things that they want to do.

And so there's this, um, almost, it's like water. It's like DevOps finds the right level within each organization. I don't think that we're seeing this kind of model that says, you know, you must attain this perfect level of DevOps maturity.

I think each organization finds its own way. Mike, I don't know. You've been around.

What do you see? Yeah, uh, I mean, I, I kind of like the point Mitch was getting at too. Uh, I don't know if he said the words explicitly, but it's kind of the, the iterative approach, definitely, but also fail fast.

Uh, and that, that's uncomfortable for a lot of, certainly practitioners in my experience, right? Like as an engineer, like that's kind of how I started my career. You never wanna do the wrong thing, right?

So you, you will kind of overthink the problem, try to think through everything that usually equates to time, right? So that was a little bit more conducive to waterfall. Uh, you don't necessarily have that in an agile mindset, and that certainly lends itself to DevOps practices.

So you have to kind of challenge yourself, uh, mentally to, yes, we're gonna do this iteratively, maybe over a year. It looks a lot more like the end goal. Uh, and we're gonna fail doing that.

That's okay. 'cause we have to recover or respond from that, um, quickly. Uh, so y yeah, there's, I mean, in my experience, most organizations, it's, it's the, it's the journey, right?

To use the cliche, but you're talking years or decades, right? 'cause it's, it's a lot, uh, for, for kind of the human brain to wrap themselves around it. I, I do still see kind of the, um, uh, I think this was your original question, Sharon, like the, that remote access or the pandemic definitely pushed some things, uh, or stressed out of delivery, right?

It's like, well, can I trust my developers to deliver this code? They're not in the office. I can't control that.

Um, but to, to me, that again goes back to the, the psychology, right? It's like you have to kind of loosen the reins a little bit on what you perceive to control. Uh, but then you're instituting other things, right?

Like guardrails or having established process. So not flying blind, uh, but you're kind of empowering people to, to do things themselves and trust the systems to keep you on track. And meanwhile, sitting in the back of the car, is somebody going, are we there yet?

Are we there yet? Yeah, exactly. We're never there yet.

Multiple people. Yeah, sure. Well, so that is an interesting point though.

When you're talking about, um, you, Mike, uh, tki you mentioned, uh, resilience and, you know, making sure that, uh, the, that the processes were supporting the ability of the, the applications to do what they need to do. So do you think there's enough focus right now on that resilience? Uh, I'd say there's awareness of it.

I mean, even, I'm thinking back to my time at Verizon, there was always like stressing about five nines. Maybe it was four nines, right? It would change, right?

Set the bar high. Well, that's kind of not realistic, right? Given the, we'll Get, we'll get to that Org structure, right?

It's a, it's interesting too. 'cause you can look at like cloud providers. They're either their four nines, uh, might be like 99, 9, 7.

I I'm drawing a blank on the numbers, but yeah. Uh, uptime's tough, right? It's like you, you to maintain those availability numbers that includes planned downtime.

So, uh, resiliency is definitely nuanced. Um, I mean, in my experience, it tends to be we need to, um, kind of mitigate the effects of, uh, outages obviously, but also the planned and downtime. Um, in my experience, I don't see a lot of organizations doing things like DevOps style releases, right?

Where they have blue grain deploys and canary full, full-blown canary environments, right? It tends to be, we have production, we have non-production, and it's, uh, it's not a exact mirror. So hopefully the code that works in non-prod will work in prod and then, uh, we pray, right?

On a production release. So there's, there's awareness of the concepts, but, um, there's definitely more, more room to kind of evolve, uh, programs and resilience. Resiliency to me too.

It, it's partially the availability piece, but also the security angle, uh, which we're starting to see more in cybersecurity strategy, really putting forth, uh, resiliency is lacking, right? Partially 'cause of like, supply chain issues. But, um, yeah, it's, there's a lot, lot of, uh, work to be done in it to support all that.

Hey, Mitch, theoretically we're supposed to be using microservices to ensure resiliency because the a p i calls will be rerouted anytime as a service is no longer available, and we will have the perfect architecture. Is there any such thing as the perfect architecture, or is resiliency and downtime always gonna be with us? Well, you know, it's, it's interesting because it goes back to what Mike, number one, Mike number two me mentioned was about failure.

Um, the, the, the sort of shift between minimizing failure, mini minimizing downtime, you know, uh, meantime to repair all of the, the normal kind of things that we measure that have measured for a long time tend to be more quality metrics kind of things too. Resilience starts to push us into, failure's gonna happen. I mean, we all know failure's gonna happen.

It's just don't matter what, what we do, what steps we take, it's always gonna happen. Whether it's add, you know, automatically add 10 more microservices instance running because we need it for load. We need it for failover proof.

Something happens. And now, you know, now you've gotta react to it or the system does. But that's what, uh, fundamentally what resilience is about, is not just focusing on, um, meantime to repair and uptime, but saying failure's gonna happen.

And how does the system respond, whether it's your system and your supply chain and your software development cycle, or it's your production environment, the network, the infrastructure, the application security, the unexpected is gonna happen. And what, what happens when that occurs? You know, the unknown unknowns idea.

And that's where chaos testing and some of these other ideas have, have come into play of, you know, chaos monkey. Let's see what happens. I will, we be able to stand up, uh, be stand left standing when something occurs.

And maybe not every time, but you take every one of those instances and learn from it and, and do the things that say, well, this is where things are brittle, and how do we help them not be so much that case? So your, to your question, that should be one of the aspects of microservices, right? To be able to re be more responsive.

Um, of course, it's all how you architect it and, you know, a lot of, a lot of great things go into it and a little bit of Kubernetes dasher and some containers over there. So, um, is there a perfect architecture? No.

'cause we're gonna, we're still working on the perfect. Mm-hmm. There you go.

It depends on the business case. Yeah. But to Mike's earlier point, I've yet to meet that engineer who's like, yeah, go ahead, break my thing.

Yeah, Push that glass system off the shelf. Let's see what happens. Don't, don't run those scripts here, You know, couple in the sandbox, couple a couple months ago, uh, was it, um, was it Amazon that, uh, there was the big kerfluffle about, they architected everything and then dropped it back to a monolith because the microservices were just not reliable enough.

It's complex. That was time video, right? Complex.

Yeah. It had a lot of complexity to it. And that's the challenge is, you know, it's, things are so complex now.

No one person can have their whole mind around the entire system, right? It takes a collective understanding. And then there's a lot We don't understand behaviors.

We don't understand why it's doing what it's doing. So it will we ever be able to properly instrument to the nth degree to be able to answer every question him, every situation? No, because the system changes while we're working on it, while we're running it.

And that's, I think a lot of times, I can't speak to that specific example, Sharon, but it's one of those, and we intended to do this, and you put it in the real world, and that's not the conditions that runs under. So, uh, oh, what do we do? Right?

Is it is fixable in this state, or do we have to back up and change architecture to do it differently? Yeah. Yeah.

And there's kind of a, um, there's an intersection. I mean, there's a few things that start to emerge. There's kind of the technology complexity as you do, as you start to explore microservices.

You typically do the slide into containers and then Kubernetes and maybe service mesh after that. And it's like you start to introduce a lot of newer technologies, which are going to have additional complexity, um, which creates, you know, operational burden. Um, but yeah, there's a lot of new signals.

So, I mean, the technology exists to gather those signals, but how do you make sense of it all? Like Mitch was saying, it's so femoral, uh, which is really hard for us to wrap our brains around, right? As humans, like you have all this data flying at you.

Uh, how do you respond, right? And that you need that to support resiliency. We need to write that book Zen in the Art of Microservices.

I feel like somebody has written, I've seen, uh, I'm drawing a blank on the name, there's kind of a very good website that kind of details. All application design patterns all are valid, right? Not everybody has to do a microservice.

There's the monolith is okay, nothing wrong with the monolith. So it was actually nice to see Amazon publish that, right? The monolith is just a big ass microservice, right?

Yeah. One micro Macro service. Thanks for making it real, Mike.

Yeah, no problem. Yeah, I mean, I've done so many talks too on, uh, I mean, on cloud certainly, and, uh, applications. How do you secure apps?

And, uh, in my experience, like everybody's kind of tinkering with containers, uh, maybe not for production workloads. Maybe they know of Kubernetes. So, but you know, everybody kind of hears, well, we can do micro surf.

It's, uh, it's gonna solve all our problems, uh, and make digital transformation possible. And it's like, it's, it's a little more nuanced than that. Well, And I spent, I spent quite a bit of time in Gen Telco too, in the telecommunications industry, Mike, and, and, and there is a mental model around infrastructure and systems.

And because of everything is large, and, you know, it's, you know, you don't roll out an application in one place or a new system or a new device in one part of the network, right? It's how it scales across the entire network. So you, you not only have complexity, but you have scale at the same time.

And I think in situations like that, that's where you, um, you introduce things more slowly because their resiliency, if you wanna go back to that term, has to be pretty high to be able to stand up in that kind of a load, that kind of environment. So if you take back us back to DevOps, if you're gonna write a microservices or update an up update a microservices, one of the things that can make it more resilient is your ability to respond when it's not, when it's got an error, we need to fix something. I can get that back out there in 30 minutes or an hour or two instead of a six or eight weeks, right?

To go through a full test cycle and, you know, get them on to stand up through the whole thing. So that, that is in theory, and it is a practice to, when you have the flywheel working, when you're using, you know, componentized architectures, containers, et cetera, it does work. But it's hard to say, let's change the telco infrastructure and the provisioning system and the inventory system and billing into microservices and containers and all the good things.

And that, that, that is, uh, about 500 monoliths trying to figure out how Yeah. Microservices, Yeah. And it, and it, and it creates operational risk, which could lead to regulatory risks.

So yeah, it's, uh, it's a lot of, lot of moving pieces, a more conserved environment. Yeah. I mean, there were some niceties in the waterfall world, right?

That, uh, agile really tests, uh, and it, it, it definitely creates a lot of, uh, headaches and heartburn for, for a number of, uh, personas. Yes. It creates a major headache for the IT folks who are trying to drive these efforts.

'cause the business side is like, how come we can't do this cool thing that this little startup did with no, you know, and, and this whole greenfield kind of application. And they go, these guys are killing us, blah, blah, blah, blah, blah. And they don't realize that, you know, they're carrying 20 years worth of IT stuff behind all this data that they can't just throw out.

So I always feel like there's this disconnect between the IT side and the digital business transformation leaders who are kinda like sitting there going, oh, well, it just magically happened. And I don't know, Mike, if you have any advice to folks about how to have that conversation? Oh, yeah.

I mean, I, I lived that, uh, it was painfully apparent, you know, and, um, the way I would kind of see it played out is, you know, you'd have your monolith, they often lived in the data center. It's a much more structured environment, controlled, um, and then maybe new product development would occur in the cloud. Uh, you could argue that was probably more front end design, and then the back end would reach back into the data center, which can create some other networking complexities and challenges there.

But I, I've seen that model work, uh, for kind of more of the heavily regulated industries. Um, you know, otherwise if they are very risk averse to cloud, uh, and I should have backed up, right? Like, cloud makes a lot of these things possible because it's, it's quickly too spin up what you need or just enough compute to do that, as opposed to provisioning all these things, all this infrastructure or platforms in your environment to support it, which takes months, right?

Or, or years. Like if you think all the things that go into that, having the power and heating and cooling, all, all those great things. Um, so cloud, cloud kind of, uh, absolved us of some of that.

But, um, if you are risk averse to cloud, it becomes incredibly challenging. Uh, but yeah, I've seen for some of those heavily regulated verticals, they'll, they'll want to embrace microservices and like cloud native designs, but then they're, they get in this camp of, well, we have to manage all that infrastructure, which it's possible, right? But it needs to be very well funded and, and well staffed.

It's Interesting, does this challenge, it applies to, you're talking about Intel communications. Some of the systems could went back and Bell Labs right, in the sixties, et cetera. But this also applies to their, I'm not gonna name company names, but there are vendors who are, have been 10, 12 years old, who, who did not build their own microservices, and they've gone back and re energy rearchitected to rebuild their products.

And it's a big lift, it's a big haul to redesign and re-architect and redeploy. But some of their incentive is, is we're trying to monitor, or we're trying to do performance analysis, or we're trying to, you know, improve development through some management or automation. So they will kind of need to eat their own, their own dog food by creating their app in that kind of an architecture.

So in a way, you might have a 12 year old monolith or worse sort of version of it. It doesn't have to be things that were created, you know, 20, 30 more, more years ago. Yep.

Yeah. It tends to, I'd see, uh, splinters, I wouldn't say splinter cell, but like smaller project, new, new products. Like, so you sometimes see things run almost as independent product teams.

Um, but yeah, it's kind of, um, it's an interesting dilemma. I mean, there's no, there's no easy answer there. And it's also the cost benefit analysis.

Like Mitch was kind of getting at, like, you would still see mainframes, right? It's like, well, don't touch it, because if you crash that thing, there goes our business, right? And then that's gonna be huge impact and potential lawsuits.

So nobody wanted to touch that, because if you did, right? It's like, it tends to be a very slow movie process to, to re-architect those things. So yeah, you, you kind of tend to see the middle ground, like everybody loves that microservice utopia, um, and full Kubernetes or service mesh, but it, uh, usually it's a mix, right?

You get, you might have some of that for a new greenfield, um, and then kind of the, the crown jewels, right? For the business, that's likely gonna be a monolith, especially for a more established organization. Yeah.

Teaching those Elephants to dance is not as easy As it looks. You Just need to stand back when you do that. Yeah.

Well, and I mean, now there's the whole movement to, you know, making DevOps a DevOps practice on the mainframe to modernize those mainframe applications, right? And be able to bring those things over so that they can still be effective. The legacy is maintained, but with, you know, more modern technologies, modern processes.

That's, that's a huge area of, of focus right now. Um, Good point. Because I think the school of thought has changed, right?

We're like, that's mainframe, leave it alone. We, we can't DevOps yet. Let's go DevOps on the new stuff, right?

And I think we've learned that the model, the mainframes aren't going away. Finally, finally, we've accepted that, right? And they play an extremely crucial role.

So the question is what? Just like, we took development off the mainframe and did it on, you know, our computer, our PCs and laptops and stuff, but how do we, how can we DevOps that process and integrate the mainframe as part of it, as a test environment, deployment environment, whatever. We need to be able to do that.

So I think we've, we've gotten a little smarter about let's not be dogmatic about DevOps, and it has to be this way. Let's take the ideas and, and then adapt 'em to this environment, whether it be mainframe or, you know, so what kind of architecture or, you know, new apps, greenfield stuff. So where does this whole DevSecOps conversation fit in?

Mike, you do a lot of work in the security side. So we are, uh, always talking about the shifting of left and these digital transformation things. I think, you know, they're kind of valuable.

So where does this, how do we insert that into the conversation? Yeah, and I, I couldn't tell you how many times I got that question as a analyst and advisory, and it was like, what do, what do you think DevSecOps means? What does it mean to you?

Or where would you start? Uh, 'cause it does, I mean, at the high level, it's where it's kind of, well, we need to get security baked into DevOps. Um, for some, um, practitioners and leaders, that means, uh, you need to embed security staff within development even, uh, but certainly DevOps teams, right?

Where they're more actively partnering as part of design and development, um, uh, that doesn't always scale, right? You don't tend not to have enough security practitioners to support that. Uh, so self-service is the other kind of big piece of that, right?

So give give the tooling to, uh, development teams and QA if you have them. So they can, they can be running, uh, tests early, uh, and iteratively as they, uh, build code and commit it. Uh, or I should say, develop the code, commit it, and then build it, right?

Because those, those are distinct kind of testing phases. Um, but there, you know, there's usually two, two, um, it's kind of dogmas, but it's mindsets, right? Shift left or shield, right?

So I'd say insecurity kind of, uh, it's almost the old guard, right? Like, we're gonna protect production. That's where we can focus all of our resources, that that was often kind of network security focused.

So firewall used all the network access controls, um, that can be much more, um, granular, uh, kind of associated with workloads. Um, now that's something we, we do at cystic, but, um, uh, different ways to approach the problem, right? And it's, there's no wrong answer.

Some organizations still prefer kind of, well, we're gonna protect the perimeter. Maybe they still have well-defined perimeters. Uh, I have to be careful 'cause this can, this can rabbit hole very quickly.

So it's kind of, your design choices really impact how you can, uh, protect things in production. Um, but it's kind of, I feel like we've been talking about this, right? There's so much complexity.

You're going to have a mix of microservices and monoliths. How do you, uh, rationalize all that? Well, you, you kind of need all of those things, right?

You have to be looking kind of at the network level. You also need to be looking at the workload level. Uh, you have to be looking at the, uh, management plane, which is often the cloud, uh, tenant configuration.

And then you have to be reasoning all those things to really understand, uh, your security posture. Um, and then, you know, the left side of the equation, or shift left is it's usually a lot of pre, uh, pre-delivery or pre-release security testing that takes a lot of different forms, like static analysis and dynamic analysis. Uh, spend many hundreds or thousands of hours talking through that with that at Verizon.

Uh, but it's kind of this balancing act, right? It's, uh, you can only test so much, right? 'cause you're kind of bound by, uh, efficacy of scanning tools.

But also things change as you move into a production environment, right? Or new threats emerge. Uh, but you're also time bound, right?

It's kind of like we're talking about how fast things move. Uh, as part of DevOps practices. Uh, you can't be running a scan for days on end, right?

And that, that can happen sometimes with, uh, security testing tools. So, uh, security has had to become much more iterative. Also, the tooling has had to become, uh, much more, uh, adaptive or flexible, right?

Where it can plug into, uh, developer workflows and uh, uh, build pipelines. Uh, but it, it, it's, uh, a lot of pieces. I mean, that's kind of my teaser of like how you might start to think about DevSecOps.

I used to have like a really elaborate diagram. 'cause everybody knows the infinity, uh, symbol. But it's like, what does that actually mean for, uh, your development release?

But yeah, there's a lot to it. Uh, you know, usually people's eyes would glaze over and then, uh, like, all right, well we need to focus here, right? Uh, 'cause that's your, your risk, uh, prioritized approach, which you have to do for your business.

And, uh, but more often than not, that was kind of shift left, right? So it was like, well, we can't do security testing in production at, after this thing's been built. Let's kind of, um, get that earlier into the S D L C.

Um, Well that's kind of the, the tension too, right? Because the security folks are like, look at this huge list of vulnerabilities that we have. You need to fix every single one.

And the developers are like, I don't know what any of this means. Like, which one is the most important? Am I even running this code in production?

Like, is this, what is the risk to my organization? There's, you know, there's a disconnect in the middle that's kind of holding that whole process up. Yeah.

And that was a good challenge I would get in advisory work. 'cause if people, well, you know, um, somebody more familiar, maybe they've felt some of the pains, um, you'd be like, well, how do I rationalize both sides to the equation? Which is a very good question to ask yourself.

And it's, the technology didn't always exist to do that. Um, it's, it is something cystic provides. I mean, we call it runtime insights.

Uh, and we use in, in use, uh, risk exposure filters to do that. Uh, but it's essentially feeding back. I mean, we could get more technical here, but how, how do you instrument the running, uh, workload to inform what you're doing, um, on the shift left side of things?

So maybe I'm referencing dependency and code. Do I care that it's vulnerable? Does do I even reach that?

Uh, or is that condition exploitable in production? Right? Maybe I just referenced that library and it's not even used, right?

So, um, a lot of those questions would come up, uh, as I would talk to all, all types of practitioners and leaders, and every vertical was kind of, well, I could do dependency analysis, but I'm gonna get just mentioning this Sharon, like, I'm gonna get a laundry list of vulnerabilities just like I did when I was doing production vulnerability management. What do I actually prioritize? And it's not even enough to just say critical, high, medium, low, right?

You'll, you'll likely lock out your criticals. Um, and highest. But I, I've even seen research more recently that's, uh, the combination of medium vulnerabilities is way more damaging or increases risk more than critical and high severity.

So that's, that's a fundamental shift from how most, uh, security practitioners would view the problem. Um, so yeah, you have to be looking at both sides. 'cause you, you will be chasing your tail with vulnerabilities, like as you're referencing dependencies.

Uh, particularly, uh, open source. Not that open source is bad. Uh, but there's vulnerabilities right there.

I'd say there's no piece of code that doesn't contain at least one vulnerability. Uh, and that's my experience as, you know, doing a lot of application security work. I always found issues.

So it's, uh, what do you actually focus on fixing? I never met a digital C X O who didn't think that the potential gain outweighed the risks. So they're basically full speed ahead until it doesn't.

So, exactly. Um, You know, how do you have a meaningful conversation with those guys? 'cause they're all business people and they're all trained at business school that life is full of risks.

And you're just kinda weighing those risks as you go along. And they'll tell you it's unsafe to cross the street. But we, we crossed the street anyway.

So, um, you know, what is the balance to be struck? Yeah, it's a really good one, Mike. Uh, it's one I've started to see bubble up more.

Uh, 'cause the s e c just finalized their, uh, cybersecurity disclosure roles, which have existed for, I think the better part of a decade, but they're final now, right? So the S C C is, uh, we're serious. You guys really need to be doing proper cybersecurity, or at least attesting to that.

Uh, and then disclosing if there's incidents. Uh, but it's really put a spotlight on, uh, security, but also how you message those things up, uh, to executive leadership and boards. 'cause it's, it's exactly that, right?

Uh, as practitioners, we often go very deep in the weeds on these are all the technical problems that can happen. These are your technical risks and operational risks. Um, but for executive leadership and boards, you know, wanna know how does that impact the business?

Um, so that, that's historically not been a great conversation. So you kind of, you almost get these silos between, um, uh, the hierarchy that way, you know, it's, it's almost like DevOps versus security. Now you're, you've seen, uh, kind of that split between engineering and, uh, business leaders.

But it's gonna have to be solved because that's the only way you can kind of, uh, determine ma materiality, uh, of a given, uh, incident, which might be security could be, uh, availability incident also, right? Which goes back to the whole resiliency point. Um, but yeah.

Is if, if you've suffered a material incident, whatever that may be, you need to be disclosing that. So how are you structuring those, uh, processes in your organization? So, going back to this is, you touched on this a a couple times, but the, the talent piece is starting to become a big issue as well, right?

We saw the great resignation and then the great, whatever it was next. Um, I mean, is there quiet quitting, Quiet cutting. I think we're quiet.

Cutting by Quitting all of that. Yeah. Um, is there enough talent available as a whole?

And, and how do you, I can't believe we've made it, what, 40 some minutes in? We have not said AI yet, but, um, maybe we'll get to that after the, the talent piece. Um, okay.

Is the talent that was Part of my available Yeah, yeah. The AI's large language models. Yeah, it's, uh, it's a tricky question.

I mean, I, I used to have to recruit, uh, application security, uh, practitioners who could actively test and do things like you would expect of, you know, an app focused, pen tester, red team. Mm-hmm. It was really hard to find those people, right?

Uh, so it's changed, the landscape's changed a lot more, uh, awareness and training material. Now that I think that's getting better is definitely a government focus to expand that. Um, also, but, um, there's also ways to kind of, uh, grow talent, right?

So if somebody has, uh, typically it would be development, right? 'cause they have more, uh, awareness of how things are built. Or maybe it's an infrastructure engineer, uh, that can actually translate nicely to, well, how do you protect this thing, right?

So you could train them up on security. So like, to me, it wasn't, it was never an unsolvable problem. Um, but the reality is you're never gonna, even if you could find those people, you never be able to justify the expense.

'cause they're too costly. Um, so you're, you're always doing that juggling act of, um, is this a people problem or can I, um, automate this somehow, right? And facilitate that self-service.

Uh, or these days it's kind of turned as a cyber judgment or cyber decision making, but it's, uh, empowering people with the right tools and information that they can make the decisions quickly. Uh, to me, part of that is ai, right? So it's, it's very nice to see, uh, kind of the rapid evolution on that front, right?

It's like we're kind of in year one where the public is seeing it and using one of these tools, uh, like chat G P T or sec pom, you know, on the Google side of things. But, um, I think it's gonna very rapidly, uh, advance, uh, and security teams are certainly gonna be using it. So I, I don't necessarily see it as a, a, a staff shortage, um, or cybersecurity expertise shortage.

I think it's just, uh, we as practitioners and leaders need to be embracing, uh, more of the machine assistants, right? 'cause it, you're always gonna have that data problem, like we were talking about that earlier. Uh, who, who's looking at, at all these things and then making the determination, is this actually a problem?

Uh, machines are better at that, right? They're not gonna inject motion like we might. So yeah, I think that tide is gonna hit, uh, very hard and fast.

You know, I think we've, we've also lived through maybe decades of kinda living in this denial world of, if I could just find the, the purple unicorn that could lead 8,000 feet and has 10 other skills, 10 years of 10 other skills that for technologies that have been Around three years. Yeah, that's three years new. But I need 10 years of experience.

We kind of do it to ourselves by trying to find that perfect person that's got the five things I've gotta have. And there is nobody, there may be one or two in the world, right? In some cases.

And, and I was having, I've a conversation at a, a conference recently with a, uh, who, a person who was a C I O become a ciso, C I o kind of combinations. A lot of titles for that now, when it's both roles. And, and, and her advice was what, what she learned to do is let's get people to learn a common set of, um, platforms and data that we're gonna work from.

Whether you're in ops, you're in SecOps, you're in development, you're in, uh, IT support, you're in s r e, whatever it is. A lot, lot of it's based around telemetry and observability. And a lot of those tools are used by security and, and ops and development people.

But start there. So you, you talk about the same things instead of talking about, you know, these kind of attacks which and developers have never heard of before, or this kind of a, uh, an a p I structure or a p i gateway, which a security person has never heard of before, right? And we sit here and talk cross purposes at each other.

I thought that was, that was an interesting approach. And the other is just to recognize that you have to grow everybody. You have to, you have to help everyone in the organization.

You progress in their knowledge and skill levels. You're not a training organization, but guess what? They don't come fully formed exactly what you want or what you're gonna need a year or two from now.

So you've gotta have an environment where you can not just train them, but give them experiences and experiences working cross-functionally, like team up with a security person, right? And discuss how the app a p i security architecture is gonna work. We walk you through this and help me understand that's very similar to how we might do an application or web firewall.

Okay, great. I get that. I know, I understand how we're, what you're doing inside of Kubernetes.

That makes sense. I can, I don't know all of it, but I know enough to have an intelligent conversation with you, and you'll find out that there's actually some areas where the, the kind of thinking about how to solve problems are pretty similar between software and security. Yep.

Yeah. Really Good stuff. Oh, yeah, go ahead.

I was just gonna, uh, echo that too. That was, uh, something that very, very big at Verizon was kind of the, um, awareness, right? And kind of, kind of promoting that culture of, uh, yeah, we need to be, uh, good corporate citizens, but also helping development and vice versa, right?

'cause they're gonna know the app better than B might, uh, but then also coach them through why it's a security problem. Uh, it's, it's tough, right? 'cause there, there are those egos and then it's like, nobody wants to fail.

Everybody's trying to meet their business goals. So, uh, it's, it's a lot of work. Uh, there's no easy, easy fix for sure.

No, no. I'm sorry, Mike. Note note to digital CXOs.

The HR people are crazy. So when they put that ad out there that says we need 15 years of DevSecOps experience with digital C X O and cloud native miners. Yeah, you, maybe that's not gonna work out the way you think.

How's that working for you? All right. Well, it is, uh, closing in on time for us to wrap up.

So I'm gonna ask each of you to give one your best piece of advice for digital CXOs navigating this issue. And I'm gonna start with Mike. Number one.

Uh, it's, it's an interesting question, you know, 'cause I, I mean, as for myself, I started as an engineer. My wiring is sometimes to say, kinda learn some of the technology. But I, um, I gotta say more, uh, focusing on things outside of technology could help tremendously.

Uh, certainly in psychology, right? 'cause you do, as you, we talked about it, uh, during the panel, right? A lot, a lot of these things are kind of how people respond to technology, uh, and the pace of things, right?

You have to kind of question some very deep things about yourself to, um, and how you receive technology and work with it. So, uh, yeah, I guess that'd be my advice. Kind of expand beyond, uh, the technology pieces.

Uh, understand you are working with people, right? We're not all machines. Um, and, uh, look, look at things outside of that, right?

Listen to podcasts, uh, beyond it and security stuff and books, you know, whatever, whatever your preferred medium is. Cool. Mike Baard.

I guess you get to be Mike. Number two, I would say, uh, don't underestimate the number of hours you need to dedicate to providing therapy to all the people involved. That's a good one.

Okay. Excellent benefits plan. All right, great.

Mitch. Benefits Mental health and your benefits plan. Um, so I'm gonna speak to leadership since we're talking about digital CXOs as well as, you know, technology organizations.

I think the number one question we always have to be answering, uh, because people are asking it, or at least they're thinking it if they're not asking it directly, is you have to always focus on the why. Why are we doing this? Why are we doing DevOps?

Why are we doing this digital transformation project? What is it the outcome that we're wanting to get? Because guess what?

The software tester who is automating tests is going, why am I doing this? Am I just wasting my time? I hate spending time working on stuff that's not doing valuable work.

Is this valuable work? How do I know that this is leading to an outcome when such and so says this is the direction we need to go? Well, why do we need to go that direction?

Or to my boss, why is what I'm doing is helping us? Is that getting us here? Connect some dots for me.

So even if you aren't getting asked why all the time, I think our digital C X O leaders, our IT technology security leaders always need to be answering or putting the answers out to the why these things are important and how they connect to whatever your business outcome is, short-term, long-term strategy, et cetera. All right, folks, well, thank you so much for joining us. Mike, Mike and Mitch, thanks so much for hanging out, having this great conversation with me today.

Folks, stay tuned. We got a lot more great stuff coming up for you the rest of the day, so don't go anywhere.