Techstrong TV July 8, 2025

Hey, everyone. Is Apple back in the AI game? You're watching Textron Game.

Hi everyone. Happy Tuesday. It's Alan Shiel for Techron Gang.

I hope your Monday went well after that long holiday weekend. You know, Mondays are always tough when you come in off a three day weekend, but now it's Tuesday and you really have no excuse. We're in the swing of things this week.

We actually have a tech field day, or networking field day, I guess is the proper term, right, Steven? That's right, that's right. Yep.

Um, coming up tomorrow and Thursday, which of course we'll be streaming live here on Tech Trunk tv. Might as well introduce our, our, uh, gang members today. And then Steven, I'll do you less and you can talk a little bit about networking Field day.

But joining us is, uh, the one and only JP Morganthal, the Dean, Mike Ard, and of course, Mr. Tech Field Day himself, Steven Foskett. Steven, what's up with Networking Field Day this year?

Yep. So this is, uh, the second one of, uh, 2025. Uh, I think we might even have a third one.

Um, yeah, we've got hedgehog coming back, uh, c packet of vi and, uh, probably the biggest, uh, news maker of the, of the crew will be HPE networking coming in, because, you know, they just got approval to purchase Juniper. So I can't wait to hear what HPE Aruba Juniper have to say at I, I think this is their first public appearance following the, uh, announcement that they got approval. Cool.

Cool. It'd be interesting, and as I said, we'll have it here live, uh, on text, on TV after the gang on Wednesday and Thursday. So let's turn to Tuesday's news.

Mike Apple made news in ai, and it wasn't necessarily negative. True. Who would've thought?

And this is our second day in a row talking about AI coding tools. But Apple is using diffusion techniques to write code differently and maybe more efficiently than humans do. And it's an interesting, uh, tape because I gotta wonder if the way we write code and gonna fundamentally change in the age of ai, but we'll dive into that in a minute.

Jp, what's your take on what's going on here? 'cause it doesn't seem like we're writing software the way our grandparents did. For sure.

There's a, there's a lot of things that I'm questioning about, uh, how we interact with these new creations. Uh, I actually wrote about one of these things recently with regard to resumes. Why are we still using an 18 hundreds, you know, created construct to give to a machine to analyze whether the person is a good fit or not, right?

It, it certainly can analyze individuals on so many dimensions. We need new inputs. And the same thing with how we think about coding is, you know, as a person, I'm coding, I, I need to think a little structure.

My brain needs the structure, the top down, right? And it, for me, you know, it starts out, I can, uh, create a, a, a, uh, a framework or a skeleton, and then I can put comments in, this is what I wanna do here. This is what I wanna do.

And then slowly and surely start to add more. And eventually my mind goes, oh, I've seen that before. Let me refactor that so that I get reused, right?

So my brain's got background processes going on, analyzing as I'm coding, right? But the AI doesn't need to do that. AI can kind of like take a high level snapshot and say, this is kind of what it looks like.

And so, and it generate version one. And in the time it took me to write my code, which probably would be, you know, an hour to two hours, it, it, it can do hundreds of thousands of generations reiterating on that call code, making it better, right? And so that's what's happening with the diffusion model versus the next token model, the diffusion model saying, yeah, let me start with, uh, you know, I, I think it looks like this.

Nope, that's not right. Sh maybe it looks like this. No, but each time it's getting clearer and clearer.

Remember the old days when we had bandwidth issues and maps used to come in like that, right? You'd have first, you'd have the very, very coarse grain, low res, low number of data. And then over time, depending upon, you know, the, you know, how much, how, how, uh, clear you needed the image to be the next you, you know, the next level down and the next level down.

Each one being more and more data. That's exactly the diffusion model and how it works. And to see it applied to code is interesting.

I, I, I do think that the other side of the story is, where did Apple come at left feel with this? What made them, what made them move to this, right? What do they, uh, so obviously Apple has been quiet.

They're certainly not out in front making a lot of noise like some of the others. But, you know, they have done, you know, had Siri for years. They have had, you know, an investment in, you know, integrating AI into their operating systems and phones, and uh, uh, and clearly they're on a path where they're doing research internally.

I guess Apple just doesn't feel a need right now to be a noisemaker, right? To them, it's more about, it's a great tool. We add it in for people, our users, we use it ourself to help be more productive.

Right? Now, we don't need to demonstrate that we're, you know, that we're king of the hill. We're not gonna fight the king of the hill battle with Anthropic and Microsoft and Google, right?

We don't need to be there. That's not our game. Our game is our devices.

Our game is our operating system and machines and, and, and, and it's really user experience. Here's the thing that I kinda wonder about as I look at all of this. So, we're finding a more efficient way to write code using AI agents.

And I have to wonder, if I look back in time, we have all these programming languages that we created so humans could interact with machines, look at Java and everything else. They're higher levels of abstraction. Steven, if I look at this, well, the AI agents at some point just decide that they're gonna create a more efficient programming language to write code.

Maybe even, who knows, it'll be an assembly or something, and we're just gonna, you know, move to a whole different software era. And I may not even understand how the software is written. Well, I certainly hope not, uh, because if we don't understand how the software is written, then it sounds like nobody does.

Um, I think it's important to remember, as JP was mentioning here, that this is not some kind of, uh, I mean, this is fundamentally some new technology because they're using this diffusion concept where they essentially continually iterate on the entire section or the entire, uh, sub-routine, uh, rather than just predicting the next token, which of course was completely doomed to failure when it came to producing, uh, high quality code. But even so, um, I, I still don't know that I would trust, uh, blindly AI to spit out code that no one looked at and no one could review. Um, and I hope that nobody else would either, though.

I guess vibe coding is a thing. Um, it, it's maybe not a good thing if you want good code. Um, you know, but, but you do bring up an interesting aspect here, and that's the different languages.

I mean, we've heard of, for example, um, COBOL and FORTRAN code being improved dramatically by ai, uh, especially in terms of AI documentation and, uh, AI tuning. We've also heard of, um, you know, the, the questions about Apple's swift language. There's been a lot of talk in the Apple community about whether Swift is really going to succeed because Apple just has not been able to put, you know, despite the might of the company, they haven't been able to put enough, uh, you know, development effort behind it.

In fact, I wonder if perhaps the result of this paper is that it would be used, this technology could be used to improve swift. But one of the challenges there is that there just isn't a lot of examples. And since ai, uh, as it exists, large language models are just basically, uh, they ingest and then disgorge, uh, tremendous, uh, amounts of, of, uh, text based on what they've seen.

The fact that there isn't that much swift code to train a model on means that it's harder to get a model to spit out swift code, but maybe this diffusion technique works better. That, that was where my mind went when I saw this, uh, announcement. Uh, what about you?

Well, I, well, let me just answer Steven's point, because I thought about your issue with, with amounts to explainability of code written by an AI that we don't understand. But maybe I'll just go to a different AI agent and ask it to explain what the AI just did to me in a way that I can understand it and therefore solve that particular problem. And then we can be more efficient.

And if I need to check up on an AI agent, I'll just have another AI agent do it. That's the theory. Just just a clarification of a point that was made earlier.

They have come up with their own language. The only reason they continue to produce a program is structure programming language is for us. So that it's a means of communicating with us in a way that we can comprehend what they did.

And I can tell you, as somebody who's been working, you know, heavily over the past month with, uh, you know, AI generated code that, you know, there's a lot I need to go back and tell 'em, like, nah, nah, you didn't get this right. Go back and do this again. Right?

It really is like working with a junior programmer. So I've got a bunch of thoughts here. So first of all, this particular instance, jp, you're right, it is sort of how a map got used to get kinda filled in, but it, it's more akin if you're ever watched like how chat GPT draws a graphic.

It's layers and layers and layers and layers, and, and when it re and when you tell it to make a change, it can't just like, take a layer off, it really kinda almost starts over. So it's, it's a very, you know, it's not a linear way of, of drawing a picture, nor is it a linear way of writing a code. But that being said, you know, from an anthropo, anthropo, anthropological perspective, to your point about if we let you know, if you don't have a human do it, then you don't know.

And we won't know, you know, if human history's full of this, there were probably good reasons. There was good reasons why Jews adopted kosher food, right? Don't eat shellfish, don't eat pork, because these were foods that actually went bad first, right?

They were the first foods to spoil. So there was probably a good common sense, real reason why shellfish was not kosher. But over time and refrigeration and everything else, that's no longer, you know, a viable reason not to eat shellfish.

But nevertheless, this is the way we do it. And so it's still not kosher. I suspect we may have a similar thing with coding, just because humans did it not, you know, and we're looking at what AI's doing.

We're saying, wait a second, it's not kosher, right? Well, because they didn't have, we didn't have refrigeration then, or we didn't have the ability to look at it in a non-linear way, in parallel process and do all these things. It doesn't make it wrong.

It just makes it different. And, and so over time, yes, it's a junior programmer today, but today's junior programmers are tomorrow's crackerjack programmers. And the same will be true here, and it'll do it its way.

And we may just all go along for it because it's kosher, right? In terms of new, in terms of new technology, though, let's not forget what Apple did here was evolutionary not revolutionary. They built on top of, I think it's an Alibaba Kwan, Yeah, it's a good library there.

I like one. And you know, I don't know how well that will sit with the rest of the world. People are liable to say Alibaba has some sort of back door into it, or can sabotage it, or who the heck knows?

It's open source, It's open sourced on hugging face. Anybody wants to review the model or review the model. So, absolutely.

Well, but look what we saw with Deep Sea, right? That was open source too. Uh, it's from China.

It's tainted at some level with a certain segment of our industry and population. But give Apple credit, you know, a lot of people don't realize the real strength of Microsoft is their channel and specifically their developer channel, right? It's huge.

Apple has an okay developer channel. You're right. Swift hasn't become the, the standard that everyone thought it was.

It would become, but look, maybe this is a way for them to piggyback and, and, you know, leapfrog over in, into something here. I It is actually kind of more revolutionary than you're giving it credit for sure. They're using an existing model, which actually, as JP mentioned at the top, I think that's a great idea.

And it shows that Apple is not trying to build their own foundational models. I think that's a wise move for them. Uh, the last thing we need is yet another fin foundational model.

I think the, the revolutionary thing is using this diffusion technique instead of just predicting the next token. And, and that could result in a really novel way of using this technology and, and may produce better results. Time will tell.

Time will tell. Alright? Yeah.

And, and I think the applications will be better because one of the issues that humans have is thinking about processing things in parallel is difficult for a human. And you have to kind of structure that maybe easier for machines to build applications where I've got 10, maybe hundreds or thousands of processes that are going along simultaneously, which would be much more interesting. There are, there are considerable, uh, performance, uh, improvements that you can see when using diffusion over linear.

Uh, it's quite noticeable. You know, you can really see it. Like if you were to use something like a VS code and hooked into, you know, one of those coding agents, if, you know, you can watch it, build the serial code, and it's, it's kind of slow.

And, you know, this thing, this is just in the background, re doing iteration, every iteration, the mutations of, you know, what was it, what we, we learned during COVID, right? The thing how viruses, how many generations viruses can create in a short period of time, right? It's, it, it, it's at that level of mutation.

My question is it, is it more or less energy efficient to do this? Because by doing things in parallel, as things change over here, they gotta change over here. And that means you gotta redo stuff.

I wonder, I, and I don't know the answer, I'm just speculating. I wonder if it's less energy efficient to do that. That might be something we look into.

Anyway, we're, we're outta time on this segment. Let's take a quick break and come back and, and talk about some more here on Textron Gang. Discover Textron Group, the epicenter of tech innovation.

We are your go-to for reaching IT leaders and practitioners worldwide. Our secret impactful content that sparks awareness, engagement, and top quality leads with us. You'll access editorial websites, streaming videos, virtual events, custom content analyst research, and more.

Join our satisfied clients. Let's revolutionize your tech journey. Contact us today and tell your story to the world in the most powerful way with Textron Group.

Hey, folks, we're back and we're talking about AI a little bit more, but this time it's a use case. 'cause everybody's arguing about what's the return on investment on ai? Well, how about just living life longer or maybe even saving a life?

Microsoft is talking about how they've come up with a way to use AI that will do diagnosis and other tasks better, more efficiently than a human physician would. And as we all know, you know, doctors need all the help they can get. Alan, what's your take here on what's going on?

Is this a, an, an early primary example where the ROI is just too big to ignore it? I don't know if doctors would agree with you, Mike, but, and, and look, it, it's refreshing to talk about this when it seems, you know, all we talk about with AI is its ability to generate code, right? Or help make code better.

But sometimes we can't lose, not sometimes we can never lose sight of the fact, really how disruptive AI can be in so many different verticals, not just it related. This, this one, here's a perfect example. You know, it, we, we've sort of had it without the ai, but the AI is supercharged it.

You know, you have a computer with a collective medical knowledge of humanity over thousands of years, right? And the ability to analyze and sift through many, many more cases, many, much more information than even the human brain can. It was only a matter of time until someone puts this out and says, Hey, when it comes to at least diagnosing, I'm not saying doing surgery.

I'm not, you know, talking about that, but diagnosing based upon symptoms and information, this is, you know, this is a no brainer in my mind. This, this, this, yeah, this, this was gonna happen. And, and let's not, I don't wanna pick on doctors, it's not their fault, but how can you compete?

And, and quite frankly, it's gonna be the same thing with lawyers and, you know, accountants, anything that, you know, the body of knowledge, an AI could get its head around and tabulate better than a human, quicker than a human, it's going to happen. So, you know, I say bring it on. I mean, as Mike, as you said, I think makes, it, makes for better diagnosises will save people's lives.

I think also in the long term, with the shortage of qualified doctors, I mean, for all of us, right? When you go to the doctor's office now, how many of you actually see the doctor versus the registered or, you know, the, the, Yeah, somebody comes in, the doctor comes in at the end just to sign off. Yeah.

Their name on the, uh, on the paperwork, nurse Practitioner and everything. I mean, this is, thank God could, couldn't have happened, you know, not soon enough. But think about it's, uh, uh, the, the input to this process, right?

I mean, uh, that overcome silos within the medical profession, whereas, you know, I, I'm gonna give it your x-rays, so you have the radiologist, I'm gonna give you the symptoms. So I have the, you know, the general practitioner. Um, and then I'm going to say, you know, based upon, uh, the symptoms I provided and the radiology, you know, uh, images that I provided, you know, give me the top five likely causes for this person's condition.

And, uh, and the, and right now that would require a collaboration between multiple doctors, which are very hard to schedule. Anybody who's ever gone through any kind of, you know, operation or any kind of medical examination across multiple practitioners knows how long they sit and just wait around waiting for these doctors to be able to schedule their time together to get a, uh, you know, a, a conference on, on the individual's state, that all of that can kind of be mitigated to some degree. And you, you know, the AI can push back out to each of these individuals and say, you agree with this or not, right?

And then it can be kind of a consensus vote, uh, or vote voting type process that allows the person to, you know, the procedures to move ahead or hold up. Mm-hmm. You know, this is a survey of one, I gotta say.

So it's usually just me, but, and maybe it's my perception, but, you know, I've reached a certain age where, you know, I'm losing friends as we all are. I imagine, and it seems like there's a current, uh, theme that keeps coming up, is that a lot of these folks, it just took a long time to get diagnosed and for people to understand what they had, and then they didn't get the treatment going in time as a result. Yep.

Now that's, right. Now I'm seeing that. I don't know if everybody else is, but I feel like, um, if AI makes a difference on that, you know, that's, that's probably, you know, no vote prize material in my mind.

And it, it, it's important to note Microsoft isn't announcing that they're using AI to provide diagnosis here. I mean, that's been done for a long time. What they're announcing is that they've come up with a system that simulates the way the doctors diagnose medical conditions through sequential analysis of symptoms, uh, testing, and importantly, by getting together a group of, I guess you could call them independent minded, um, uh, diagnostics to determine what the most likely cause is.

I mean, anybody who's watched a medical program on TV has seen the scene where the chief attending says to all of those young, handsome, probably doing naughty things, doctors around the patient and says, okay, what do you think is wrong? Now? What do you think is wrong?

How about you, you know, how do you build on this? That's what Microsoft is announcing here. That this, uh, MAI diagnostic orchestrator is essentially that chief resident and the people that he is talking to, people in quotes, isn't, uh, handsome residents.

It is in fact, uh, existing ais. And so that's really what they're talking about here, is that they're, they're using all of these off the shelf ais, they're feeding them, uh, the known the facts as of now about the patient, about the patient's condition, about test results and that sort of thing. Having them all respond with what they think is the problem, and then iterating on that.

And I think that's a really interesting idea, because like I said, they're, they're duplicating what doctors actually do, rather than just throwing it at chat GPT and saying, what do you think chat GPT? That being said, none of these models are actually medical trained models in any way. They're just large language models.

They're just spewing out the next token that statistically comes up based on the inputs that they get. And so, you know, I mean, they're not doctors. Maybe they can diagnose things better, and that's certainly better.

But once again, we're using AI in a cool novel way, but in a way in which maybe it's not the best for. So, I, I, Steven, I think it's just a matter of time until you have specialized medical LLMs. I mean, that, that's not gonna be a great leap for me.

The great leap is when do you let them prescribe remedies, whether it be, you know, uh, medicine or, or, or therapy or whatever, right? That there, because it's almost like that's the point where a human has to look at the code, or before I give someone some prescription that may or may not help them or hurt them, you know, I probably, I personally, and maybe it's just 'cause I'm old, would feel comfortable having a human look at that. But again, it could become kosher in another couple years, right?

That, hey, just the AI pers makes the diagnosis and gives you the, the, the, the prescription based on it. People are typing in their symptoms into various apps these days. Then a, some sort of doctor is allegedly reviewing that, and then they're getting a prescription and it pops up at CVS.

So, uh, for all I know that AI agent one day is gonna review the symptoms because the doctor doing the review of the symptoms is just statistically make it a guess. I mean, how many of you guys have done I'm telehealth, I what? Done Telehealth, telehealth?

Oh, I hate telehealth. Yeah, But you know what? I, when I'm on the road and I get a, a bad cold or a sore throat or something, I use telehealth.

I've done it in Europe, I've done it at, you know, on the road here in the us. And I'll tell you the truth, I don't know if that's a doctor, a, a, a, a, a practical nurse, you know, or, you know, whatever the term is, I apologize or fraud. I know it is an ai, right?

But the last time I did it, the, the, the, the person on the other end said, well, let me see your throat. Can you turn your camera on your iPad into your mouth? And I did.

Ah, he said, oh, yeah, I see it's ratted. You know, they prescribed something. Who knows?

I, I, I know that there's a test going on within a chain, uh, pharmacy chain, the u the uk. Now the UK is a little different 'cause they have the NHS, which is the socialized medicine, right? And as an attempt to offload some of the traffic that's been going to NHS centers, they allow now these pharmacies, uh, and for particularly the pharmacists to diagnose a subset of conditions and give a certain, uh, um, medications based on those conditions.

And it's like seven. And it's really lightweight, nothing life threatening or anything like that. But what happened was all this traffic started now piling up, I, you know, waiting for the pharmacist to get the diagnosis.

And that's holding up things in the pharmacy from running. So, uh, uh, this particular test that they're running in one of these chains is that the workers in the pharmacy where, you know, get a, uh, a handheld assistant and it, it's listening to the person talk. It's listening to the conversation, and the person reads the prompt to the, to the individual and says, you know about symptoms, do you have this?

And then the person responds, and then the AI tells it, okay, the next question should be this. And it listens. And, and it gets to a point where it makes a recommendation for the person.

And if it's within a yes, you're in the subset, we can recommend this. This is what the recommendation should be. And the pharmacist just has to sign off on it, and then it, it's done.

So it, it's being used to offload traffic from, you know, critical, uh, patient care. My father used to say, whatever you do, don't go to the hospital. 'cause that's where all the germs are.

That's where the same people are. You know what though? But let me, so my my oldest son graduated law school in May, and he worked in the legal technology lab there at Suffolk University Law School.

He worked on chatbots, two kinds, chatbots for lawyers, chatbots for civilians. The chatbots for lawyers basically is you uploaded a fact pattern and it spit out your pleadings for you, your, your interrogatories, your bill of particulars, your complaints, everything just crazy. Boom.

And that's great. It's gonna put lawyers outta work, but it's great. But for civilians, it was really, and the one, the one my son worked on was for landlord tenant court, 75% of tenants can't afford a lawyer.

And so they go in the landlord tenant court unrepresented. And as one might expect they lose, well, most of them haven't paid their rent, so they, they kind of, you know, it's a for, but there's things they could do to delay being evicted too. Sometimes the landlords have an agenda why they wanna evict him, and they don't accept payment or, or whatever.

And this chat bot really, I mean, it did yeoman's work. It was, it was actually adopted by the state of Massachusetts. They're using it out of the lab at his law school there to really help people navigate the legal system, put pleadings in, put in extensions of time, work out re uh, uh, litig mitigation, you know, arbitration kind of things, rather than getting put in the street.

And so, again, guys, I'm telling you it's novel now, but today's novel ideas are gonna be common stance a lot sooner than we think. I I think this thing with, with the doctor, uh, with diagnoses is gonna be standard within two to three years. I'm looking forward to that new metric that comes out.

It's called AI kosher, AI Kosher for ai. Now, that's a, maybe I could be like the council that gives it its stamp. Uh, all right, let's take a break.

We'll be back here on textron act. com is the leading resource for news analysis and education on challenges facing the cybersecurity industry. com covers all aspects of cybersecurity, including data security, DevSecOps, cloud security, application security, network security, security threats, and more.

com has the largest selection of security content featuring breaking news, blog posts, podcasts, and more. com to learn more. com.

Home of Security Bloggers network. Hey, everybody, it's Tuesday. And well, we always talk about the environment in some form or another.

So let's not make this one an exception. Steven, it's interesting times. There's the big, beautiful Bill has kinda reduced their thinking about at least reducing some of the credits for clean energy.

It's not going into an immediate effect. But as I turn around, I also noticed that we seem to be making a lot of progress on clean energy lately, and there's about a million announcements, including ones from just about every one of the big cloud service providers. But what's your take on what's going on here?

Are we kind of solving a problem even though the politicians don't even know what the problem is? Well, I I think there's a couple of angles here. I mean, as you mentioned, I guess we could start with the, uh, the bill.

Um, it has indeed changed some things related to clean energy. Uh, I should note that some of the worst parts of the bill that were proposed by the House and the Senate have actually been removed. Uh, there was a huge tax on wind and solar that was injected in there, in the name of National Security.

Uh, essentially they were going to put, uh, massive, you know, 30 40% tax on wind and solar projects that relied on, um, products that, uh, uh, physical components that came out of China, which would be, you know, all of them. And so that would've really caused a problem, uh, that's gone, uh, that didn't get through. But what did get through is a phase out of credits for, uh, tax credits for wind and solar projects starting at the end of 2027.

Many of, uh, the provisions of that bill, by the way, um, don't happen this year or even next year, and happen, uh, later, uh, for political reasons. Uh, the phase out of the wind and solar though, um, gives us, you know, 12 months to start these projects and another 24 months to actually reap the credits for them, which frankly is, um, surprisingly good news for the industry because it means that they've got some time to still get some of these credits. And frankly, by that point, uh, I've said many times on the show that wind and solar is already so much cheaper than other forms of energy that the horse is kind of out of the barn in terms of, of tax credits.

Maybe we don't even need tax credits to, uh, push these projects since the projects are so financially viable already. Uh, we certainly don't need a 40%, uh, excise tax on top of them that, you know, would cause problems. But, uh, frankly, just letting them run on in a free market is probably going to, uh, cause them to grow, uh, even without that.

Um, there are other elements, by the way, of the, of the bill in terms of, um, renewable, uh, fuels and hydrogen and things like that. But, but let's focus on wind and solar. Uh, as you mentioned, there's other news here as well.

Um, once again, we have, um, major hyperscalers talking about adding wind and solar energy for data center. Uh, I have questions about that. I did some research into the background of some of these things, and, and it, and it all kind of, um, comes out.

Is this all just sort of propaganda from the industry, or is this actually news? Because the fact that meta is gonna be buying all this wind and solar energy, the projects that they're buying from aren't located anywhere near the data centers, that they're going to be actually deploying this power in, which means, I mean, it's fungible, it's a grid. The, the, the electrons don't have to come from this particular solar panel.

But I will say that, you know, in looking into the background of these things, these projects that, that, that meta is gonna be leveraging, for example, they were built in places like Ohio, Arkansas, and Texas with promises to power homes. In fact, the Ohio one specifically says that it's going to power 46,000 American homes. Well, that energy ain't gonna be power in no homes.

It's gonna be powering AI data centers. And I'm curious what people will think once they see these big contracts come through for these big projects that were supposed to benefit Well, states and people, rather than ai, Maybe the metas or the world will pick up people's consumer bills as part of this. What do you think?

Snowballs chance, You know, interesting use of ai. What, what, what, what are, what are these, when, when a bill comes to the floor, especially these big ones, what's the one complaint representatives always say, who has the time to read 2000 pages in order to, you know, affirm what I'm voting for? Right?

I have a limited amount of time to, to get my, you know, to, to the vote. And I gotta understand all this. Well, you kind of don't anymore, right?

Just hand the thing off to, to Gemini, throw it in a notebook, lm, and say, I'm a representative for this state. What do I need to be wary of? Right?

And get your list back instantaneously. Now, you know what you're voting on. Now, you know where you know what you're looking at.

Uh, I think it, I I, I keep saying I'm ready to hand this government over to Claude because I think it could do a better job, but either side right now, I, I, I think a bunch of monkeys on a board might be able to do. Yeah, I, Steven, I agree with you. But, but a couple things.

So Steven, you're right. Thank God they, they didn't go ahead with the, the Chinese tariffs that would just kill the industry. And I, I think even as we sit here today, wind and solar could go toe to toe.

If you took off some of the inherent bias towards fossil fuels in this country, especially, right? I, I think we're getting to that parody level right now in a couple years more. But in a couple years, you might have a new administration.

And, you know, the great thing about legislation like this is what's done can be undone. The Supreme Court can change who, you know, things. This isn't necessarily forever, but here's the thing.

These hyperscalers say what you want about them, but they're smart money. They're smart money, and they're making their bets. They're talking, they're betting with their money, right?

They're talking with their pocketbook, and they're betting on renewable clean energy because they know, they know that that's the future for them. They know that's the only way they're gonna do it. Is it gonna be at the expense of consumers?

Steven, perhaps you're right. And that's a shame, Jp, let's bring this full circle and close it out before we run out of time. Um, might AI agents not write more efficient code that would result in less energy being consumed by infrastructure at least more efficiently?

And maybe we might solve our own problems? 'cause I like it when technology solves its own problems. I, I think it has a great, tremendous power to optimize its own, you know, uh, approach to the way it's used, right?

You we're getting to the point where, you know, with the right observation tools, right? Everything is data. With an, with an LLM, if, if it hasn't seen it, it doesn't know it, right?

So it needs a feed, it needs a feed of data given to it that says, here's your power consumption model for, you know, the past six months, you know, given the body of work that you've been working on, you know, how, how would you optimize this? You know, where do you see opportunity for improvement? And I think it can analyze it and give you back a, you know, a rudimentary set of steps to say, well, you know, I think if you know this, this, this, and this happened, you know, I would've used this many less megawatts.

Okay, but who's feeding that? Nobody's feeding that data. Nobody's capturing, you know, megawatt usage yet.

And you would think that an anthropic or, or somebody like that would be like, you know, now we're talking almost like manufacturing levels. If I save a penny, creating a car, it, it works out to, you know, millions of dollars over the long run, right? It, you're getting to that level where these guys are, are, are adding so much volume and, you know, there's only so much compute available for them that it, it's gonna be become a requirement to say, well, we need to do more with what we have.

We can't just keep adding endlessly. Agreed. Guys, I need to end this one right here.

Jp, Steven, Mike, thanks for joining. As usual, we have a full text on TV schedule immediately following today's event. And a reminder again tomorrow after, actually, Steven, what time does that start tomorrow?

Yeah, Alan, the tech field day presentations start at 9:00 AM Pacific time, uh, Wednesday and 8:00 AM Pacific time on Thursday. And, uh, basically continue throughout the day. So they'll be on, well, uh, on Wednesday.

It'll be about an hour after we end up here. And on, uh, Thursday, it'll be right after the gang, so there you go. Alrighty.

Until then, everyone, this is Alan Shimel for Textron Gang. Thanks for joining in. Take care.

Hey everyone, it's Alan Shimel. Welcome back here to Tech Drunk tv. I'm really happy to have this next gentleman on with us right now.

He's been on Tech Drunk TV before, but usually, and part of his role with the CD Foundation, the Continuous Delivery Foundation, he's here today in his, his full-time gig, right? Which is Principal DevX researcher at Octopus Deploy. Let me introduce you to Steve Fenton.

Hey, Steve, how are you? I'm fine, thanks very much, Alan. How are you?

Good. It's good to have you on. Appreciate it, Steve.

Um, I mentioned your Principal DevX researcher at Octopus Apply, but let's, let's unpack that a little bit. What exactly does Principal DevX researcher mean there, and how did you wind up in that role? Yeah, so it's a, an interesting story.

Um, I've been in software for a couple of decades, um, and when I came to Octopus Deploy, I just, um, had so much curiosity for what was going on. I couldn't leave things alone. I was like, every time I found some data somewhere, I wanted to find out more about it and understand what was going on.

Um, and I've been kind of participating with the CD Foundation when they've been doing their research efforts. Um, and I, uh, participate in the Dora community around that state of DevOps research, and I just kind of can't get enough data. Um, and so I've kind of ended up building that in as part of the role that I do here is that I'm really curious about software delivery and culture.

Um, and this is a way for me to kind of scratch the itch and find out more about it, especially things, um, you know, uh, like get ops and, um, infrastructure as code and loads of things that I didn't actually get to, um, get my hands on back when I was developing so much. Um, so yeah, I'm really interested in these, these newer ways of working. Absolutely.

I absolutely, um, you mentioned Dr. Pus ploy a few times, Steve, I, I think most of our audience, of course, is familiar with Octopus Deploy, also familiar with codefresh, right? The, uh, one of the, uh, companies that merged into Octopus Deploy, and of course, they're the people behind Argo GI Ops and, and all of that.

So, um, but for those who maybe aren't, give, give us kind of the, the overview of the, of Octopus Deploy. Yeah. So Octopus Deploy focuses, um, in on the, uh, continuous delivery part of software.

So there's loads of tools out there that will help you, um, build your code and create artifacts. But when it comes to doing deployments, especially at really large scale, um, there's not as many tools in that space. So that's really what we're interested in, is solving the deployment problem, data operations.

Um, we're kind of in that space, so where people are trying to do unusual things like deploy software to, you know, hospitals and retail stores and lots of cloud, um, infrastructure and places like that. Excellent, excellent. Um, Steve, just real quick, the website for Octopus Deploy?

Yep. com. It's great, great, great, uh, url, isn't it?

Yeah, I know. Something about great URLs. Okay.

So Steve, you know, let's turn to our topic of discussion. Now that we've gotten all that out of the way, uh, you guys recently released the GI ups, the state of GI UPS report. Yeah.

So eagerly anticipated, uh, report, talk to us about it. Yeah, so we were really lucky. Um, we went out to the community, asked them to share the survey that we had asked them to fill it in when, um, 660 people came back and gave us answers, which was really amazing.

'cause that meant that we could cut up the data in lots of different ways and still have nice sample sizes for everything. Um, and what we wanted to do was find out, we knew, um, open GI Ops has existed for a while, which is A-C-N-C-F project that defines what GI Ops is supposed to look like. Um, and one of the questions we had was, is that correct?

Are those the things that are needed for, um, for GI Ops to be successful? Um, so we were asking people what practices they were applying and what benefits they were getting from it. And we started to build a picture of what do you need to put into that GI Ops process in order to get the benefits?

So things like increased security and easier compliance and simpler audits and less production access. All of those kinds of benefits, the things that we think GitHubs are gonna get us, we wanted to say, if you do this, will you get those things? Um, so yeah, we, we couldn't have done it without all of those people giving us answers, and I couldn't have done it without all of the GitHubs experts who I could then share that with and say, why does this graph look like this?

So, yeah, there's lots and lots and lots of real GitHubs experts that have helped, you know, people, uh, like Dan Garfield, Costus Caponi, and, and, um, people from organizations like Cross who, uh, they're doing this every day so they really know this stuff. So, you know, absolutely. And of course, Dan has been on our show many, many times over the years.

Um, so there's always sort of at least three key findings in these types of reports. Steve, what are the key findings here? Yeah, so, um, one of them is, um, in terms of the future of GI Ops, um, most of the people that are using it are excited and wanna do it more.

So, um, I think there were, uh, out of all of the people that we spoke to, only 7% were thinking of reducing or stopping GI ops. Everyone else is either maintaining or increasing their, their GI ops usage. So, um, if you throw away all of the data analysis and just think if GitHubs is, is working, people want to keep doing it, that's a strong signal that people are getting something from it.

Um, which is, which is kind of like a really important thing. Um, we also dug into that 7%, um, 'cause that's what I find, this is where my curiosity comes in. It's like, oh, 7% don't wanna do get Ops.

What do they have in common? Um, that's different to all of those other people that wanna keep doing it. Um, and very often they are missing the reconciliation loop, which is this crucial part of get ops where, uh, you know, your state keeps on getting brought back into the correct target state when it gets, when there's drift.

And people who aren't, aren't doing that Reconciliation Loop, are much more likely to be in that group saying, actually, we might stop using GI Ops because we're not getting the benefits from it. So that's probably one of the crucial findings is, uh, don't give up until you've tried, um, using the Reconciliation loop. Yeah.

That, that, that is a, that's good advice right there. Um, you know, Steve, I recently in, uh, New York for, uh, the in-Person Day for Platform Con platform engineering is, you know, a lot of people gathering around that title. It's, it's something that's not necessary.

The title's new, but what, what underneath it is not. Um, I'm wondering, and, and they had some sessions there about GI ups, you know, as part of working with IDPs, working obviously with coop platforms. Yep.

I'm wondering if anything in the report sort of lent itself to that. Yeah, so, uh, I'll, I'll try and subtly pull up the numbers in the background. Uh, whilst I, whilst I answered this, we, uh, we did find out what roles, um, people had, um, and platform engineers are in the top three roles using GI Op really.

So That's what I, that's kind of what they were saying there too. So that, that, that's correlation for me. Yeah, and I think it makes sense because, uh, when you think of how GI Ops works, we're using tools that developers already like to use.

We're using version control and we're using configuration files that hopefully are human readable and they can make sense of them. So I mean, I, I feel this, when I was doing development, um, I had to log into cloud portals to, to do anything when it came to infrastructure. And trying to remember where everything is inside of a cloud portal is actually quite painful, especially because the portals then get refreshed and all of that memory.

I remember when Azure Blades changed from being like this horizontal thing to being a more modern look and suddenly I couldn't find anything anymore. Um, so I think, uh, platform teams will want to give, um, GitHubs as a tool for those developers as a way of just removing the need to, um, log into three different cloud providers portals and maybe, um, find IP addresses and do remote commands, all of that headache. So whenever a developer needs to do something, there's like one place and it's the place they're already using.

So I think that's the very sensible move from platform engineers to look at this as an option. Absolutely. Uh, absolutely.

Um, what other key findings or maybe even something that surprised you In the report? Yeah, a big surprise for me was, um, the Open GI ops principles lean very heavily on, uh, the configuration should be declarative. So instead of being like a sequence of steps that result in, um, the state that you want to get to, you actually define that as your configuration.

You say, this is the end state, like the target for what we want. Um, and the idea behind that is it serves as like a document of what the, the state should be. Um, but it also means that a new kind of tool can kind of be brought in that will automatically reconcile that for you, um, as opposed to you having to have no a baseline and then kind of operate against a baseline and get it to a state.

Um, but we actually found a very large number of people aren't yet doing that. Um, they're still using, uh, kind of step by step imperative, uh, configuration. So they'll be missing out on some of the benefits that you get from having that document.

'cause it's, it's executable. You use it to bring your, you know, maybe it's your Kubernetes cluster and the applications running on it. You use it to get those in the right state.

Um, but having that document means that you can tell what it's supposed to look like, um, even if you're just reading it. Whereas with imperative, you have to build the picture in your head as you read it line by line. So we expected more people to be doing declarative config, um, than, than actually were.

So, um, and that changes by role quite a lot as well. So again, um, when we were looking at roles, we found that, um, DevOps folks, architects platform engineers are more likely to be doing declarative config, but then system and, um, system engineers and site reliability engineers were slightly less likely to doing declarative config. So very Interesting.

There's more to explore there. I don't have, I don't have all data. I need to understand that.

Yeah, because it's such a, the connection between those roles, you would think there wouldn't be a divide like that, but more, definitely more to discover there. Lemme ask a question, Steve. You mentioned twice the Linux Foundation's GI Up, GI ups.

It's not GI UPS project, it's committee or action committee Something. Yeah, that's right. They've got, they've got a, um, the, there's a project called Open GI ups, which Right.

Um, it has like these four principles, which they kind of all got together to decide what GitHubs should look like. Um, and that's been a really useful guiding, like this is what GitHubs means and it's, it's helping to stop some of that semantic diffusion that we often get around a term. It's like, there's four things that you can say, if it looks like this, it's probably GitHubs.

Yeah. Steve, what's the connection between that and Argo? So, um, a a lot of the Argo folks were involved in forming those principles, but I Believe Some of the Flux folks were as well.

So it was like a big collaborative effort. Um, that's good. And bringing it together.

And, and that's the beauty of the Linux Foundation, right? It it does, it brings what may be competitors into coopetition and that's, uh, and you know that rising tide lifts all boats and then you go from there. Yeah.

That's super important. Yep. com, but where can people get this state of GI ops report?

So, um, we have it linked from our website. com/publications. Okay.

Uh, you'll, you'll be able to download it from there. And I'm also working, um, on some interactive diagrams that will help folks understand some of the really deep insights we got. I created a diagram called a strength relationship diagram, and it maps each individual practice to the different outcomes, but it can be a little bit overwhelming 'cause there's lines everywhere.

So I'm creating some interactive versions, which I'll be publishing soon that will make it easier for people to explore that data. So watch this space. Absolutely.

Steve, thank you so much. I appreciate it. Um, keep up the great work, both you as well as our friends at Octopus Deploy and, and some of the folks you mentioned.

I hope maybe to see you, uh, CubeCon in Atlanta. Well, it's still a few months off, but I know we're already planning on being there. I assume the the octopus deploy folks are as well.

Yeah, we'll have a, we'll have a whole contingent attending CubeCon. We had a great time in Europe at CubeCon and I'm sure the, uh, it was great. Won be amazing tea.

Yes it was. Yes, it will be. All right.

Steve Fenton, principal dev, dev X researcher at Octopus Octopus deploy all about the state of GI ops report here on Tech Trunk tv. Check it out. We'll be back in a moment.

Hello, I'm Mike Fazar and welcome to the latest edition of the Techstrong AI Leadership Insight series. We're here today with Dole Abrahams, who's principal technologist for Forter, and we're talking about the impact AI agents are gonna have on e-commerce. Dole, welcome to show.

Well, thank you so much. Thanks for having me. Excited to, to take part, I think everybody and his brother's talking about agen AI in some form or another, but I don't think we've actually kind of walked through, well, are AI agents gonna buy stuff for us?

Are they gonna sell stuff for us? And how might they actually negotiate and how do we know that the AI agents are authorized to do whatever it is they're supposed to be doing anyway, so start from the beginning. I mean, what role will AI agents play in e-commerce?

So first of all, I think AI agents already do buy stuff for us. I mean, sometimes you would ask Alexa to refill your, um, whatever the paper towels in the kitchen 'cause you just run out. I mean, that is a very beginning, initial, um, you know, AI agentic abilities, right?

Because Alexa has to choose which type of the white papers you wanna buy, and then maybe you're going to ask, uh, hair or it to be, uh, you know, cost conscious or not. So this is the beginning, but today we're already seeing even, you know, Chad GPT features of your compare flights, uh, and, and make a purchase for you. So if you're starting to talk about, uh, what you mentioned, um, and negotiate in our name.

So these things are already out there. I think what you alluded to at the end of your question, uh, was super important is how do we know that this specific agent has the authority to use someone's identity or potentially payment instrument to actually go ahead and complete the transaction? And this is something that the world or the e-commerce world is, is definitely dealing with today, both from the functional aspect of how to make it work, but also on the other side.

That's what, you know, we do at, for, uh, try to validate that there isn't any fraud happening or any manipulation of identities or someone's using someone else's credit card without them authorizing them. Dive into a little bit more though. The e-commerce providers will each have a series of AI agents and me as the purchaser or the consumer will also have AI agents.

So how will these AI agents kind of interact with each other and, and I guess at some point they might even have to negotiate. So how does, how will that all manifest itself? Uh, so that's, it is interesting and I think we also, um, you know, Walmart's, uh, declaration, I think last week or two weeks ago about them starting to integrate AI agents to, you know, pick and choose for consumers what they need.

Um, uh, the, the interaction between different AI agents is always interesting and I think there there is more, um, more of a guessing or uh, I know we can assume what's going to happen than what I can actually speak to. But yes, what you said is exactly right. Um, stores or retailers are going to start offering some AI agents to help with, uh, price compare or functionality comparison already to help you identify what you need at this point.

And on the other side, as consumers have today, AI agents that are trying to do the same but optimized for the consumer and not for the merchant, will there be a point in time where two AI agents negotiate in our name? Probably it's probably already happening today. Um, I think very much so is happening when you think about, um, algo trading, uh, functionalities.

So not very much for the consumer retailer relationship, but more in stock market. Um, it is happening today and I can say too much about how it's going to work 'cause I'm not an expert in that front, but it definitely worries me. So it seems to me at least, there's two aspects of securing these things.

One is the AI agents themselves after they've been created, somebody may try to compromise them and take them over and essentially commandeer whatever process that they've been authorized to complete. So how will we know when the AI agent that you or I created has suddenly been, um, stolen essentially by somebody else for a nefarious purpose. The question is, how do we know when it's being compromised?

The answer is, we don't always know. And, and what, what, what I'm dealing with on our side. So, just to say a little bit, share about a little bit what we do.

So we prevent fraud from happening for retailers. And for the most part in the near history, when you see someone or something, um, transactioning on your website or even scrolling your website, you would have to make a decision on whether they're good or bad based on whether it's a bot, as we used to call AI agents up, up to very recently, or a human being where for the most part, bots considered a bad thing human being. Consider the good thing Today, one of the key problems we're dealing with is that we are going to see, like you said, good bots or AI agents that are actually, um, sent by humans to perform their actions.

And you'll run the risk of declining their activity based on the fact that it's not a human. But what you do, you, you'd actually turn away good customers. What you are referring to is the next step.

So even now that we've established that there is such thing as good boss or good AI agents that transact for people, how can we identify that these are not compromised bots who are taking advantage of the delegated authority that was given to them? The short and easy answer would be to understand the behavior. When I say behavior, I, you know, I, I've mean a lot of different things that you can do, um, with the cyber intelligence.

Identify the device from which, um, you see an activity, you can identify the location. You can measure all sorts of things in terms of like the latency to try and as to try and assess where the activity is coming from, um, and what types of operating systems, uh, what versions of browsers or exce, et cetera. So these are things that we call, um, behavioral analytics.

And you can understand if statistically what you're seeing is good or bad activity based on all, all, all these features you run, uh, machine learning models, uh, and some AI or old AI features to determine, uh, those factors. Um, whether a good bot turns back to be a bad one. That is another thing that you can assess using statistical methodologies and, and really to validate the behavioral activity.

And again, when I say behavioral, sometimes people think that I'm referring to how long they spend on the site or where on the side, uh, on the site they clicked, what pages they they looked into, it's this and more. 'cause we're also talking about the actual device identifiers, which are an indication of the behavioral, uh, that, that you can see. And secondly, won't the nefarious actors out there create their own AI agents that will, uh, behave like they are trusted AI agents for a little while and they have gained your trust and then maybe strike and do something malicious as well.

Right? A absolutely, this is a fear and a major concern in all, you know, cybersecurity industry and also, uh, fraud and payments fraud industry that I'm part of. Um, one thing that I think is important to remember, um, about ai, I, I'm not sure if I'm, I'm sure you have had your attempt with, uh, cha Gt or any other tools of just trying to generate emails or do all sorts of tasks.

It's almost always not enough to ask the AI agent or the LLM to do something for you without having a very clear idea of what you ask them to do. Um, and I say that because I think when you think about nefarious activity or fraud, AI is not a good fraud or scam generator. It's a great accelerator.

If you have a very clear idea, it can save time. It could do things, uh, automatically. The scale is unfathomable, but it would never replace, um, honestly, a good, you know, common sense, uh, and, and human creativity.

So, you know, when I think about, uh, I've seen, uh, AI generated songs or poems of stories, it, it always, it's not that good. You know, you can always tell that there's something to it. It's the same with fraud.

If you're just asking AI to come up with, with ways to do stuff, uh, it would wouldn't be perfect. It's, it's only based on things that it's seen from the corpus of whatever, you know, internet access that it has. But you always need to actually be, it's gonna be a word phrase, but you need to be a good fraudster to tame the AI to your needs.

So that's something that's important to remember on both sides, by the way. So we are still people who are leveraging technology. Um, you know, bad people, well, you know, bad people on one side and good people on the other side who are trying to, uh, attack and protect, uh, the tools and technology changes, but it's still not something that I think is, uh, life changing in, in the sense of, um, the fraud types we're going to see, or unimaginable fraud attacks.

Um, the scale and automation is significant, but there are tools that, you know, that can help contain that as well. Essentially, uh, I would imagine that the same way that we are monitoring for anomalies with human frauds, we can also kind of apply that to any kind of AI agent that somebody creates. Uh, that, that is correct.

And, uh, um, and again, important. Remember, uh, human fraudsters, uh, took advantage of AI tools, maybe not agentic or language models, AI tools and automated scripts and bots. Ever since this, these things were invented.

Now the barrier of entry maybe is lower. So, you know, I can now, I I I, I cannot code, I cannot build apps alone, but now I can leverage AI agents to do that for me, fraud, amateur fraudsters who never had the skillset that allows them to take advantage of, of bots or even all sorts of, uh, IP spoofing or masking technologies now have an easier access to these via AI agents. Um, so that is something that, that is somewhat changing.

Uh, but at the heart of the thing in, in my opinion, um, we're not seeing fraud that we've never seen before, per se. Um, again, scale is significant, automation is significant, but it's not. And to your point, is one of the dead giveaways maybe, that there always seems to be, when somebody wants you to do something that is being driven by fraud, there's always some sense of urgency in it where I'm supposed to do something unusual or different because there's some sort of crisis at hand.

And, and is that kind of a dead giveaway? Uh, correct. This is when we're talking about, uh, scamming personal like individuals and not, and when you're not trying to steal from a retailer, this is something that is, I, I, I would agree with you almost that giveaway.

You're getting a phone call or text messaging saying someone you know has been hurt and that you need to wire money somewhere, for example. Um, it's, you know, the old, um, um, um, uh, you know, I'm an African prince who want to donate all my money to you, but you need to provide your bank number first, whatever, no, um, bank account number first. These things were always seem like you just get a stupid email that's not written correctly, and it's always looks bad today.

Fraudsters have tools that allows them to send very eloquent messages. They can actually have a conversation with you if they're texting with you. For example, you, you would think you're texting with a human being, and they can come up with, with a lot of ways to make it seem urgent.

I will say to any of the listeners here, if you, if you are a target of a scam, a it's not your fault. It's almost as if you're being like, you know, mugged at gunpoint in the street. It's, it's out of your control.

The one thing you can do is try to, you know, manage how you react to it. Um, but, you know, we can all all be victims, even myself as an expert, sometimes find myself almost clicking on things just because it seems too real. Uh, but a good piece of advice I've heard once is to try to get yourself out of the loop.

So if you have someone you trust, text them, tell them, Hey, this is what, you know, someone's telling me that they kidnapped my mom and they need payment like this. Does that sound right to you? Like, or I need help.

And often just even taking a step back, get you out of the loop and you can, you know, start thinking straight. Because the one thing that a lot of scam victims say, I mean, it's, it's outside of ai, but AI definitely contributed to that and skilled things. One thing that scam victims always say whenever they do the thing, the second they wire the money or the second day, you know, find themselves do something, it's almost always they're like, what just happened?

And it is clear as daylight. I was just scammed. So try to get to that clarity a second before, and not a second after is always good.

And, and, and again, one good way of doing it is, is try to take yourself out of the loop, talk to someone else, take a breather, move away from your phone, go get a glass of water or think through the things. Um, it's, it's always helpful, uh, but, but again, of course, if you are being put in the position, when you are convinced to believe that something bad is happening to someone you love, it's, it's not, it's not easy or expected to be able to control your emotions at that point. So how is fraud different for the retailer?

It sounds like for consumers, it's one thing, but for the retailers, what are they struggling with? So there's a lot of different types of, of fraud for retailers that you, you might never have thought of. Uh, but, you know, uh, some retailers offer you a discount when you open an account with them, um, like $10 off your sold.

What prevents you from creating a thousand different accounts? Right? Vis one, micro, invis two, vis three, um, you can, you know, generate as many emails as you want, and you can get a lot of freebies.

Ai, orent AI can help you generate thousands of accounts in seconds. Um, this is something that for a retailer, I mean, you'll think, oh, it's a write-off. It's $10 off.

It's nothing. This could have a significant impact on a retailer's, uh, on a retailer's margin. As you know, margins are, are key to a profit profitability of the company.

The entire C-suite is being comped on the margins they're making. It sounds stupid, but $1,010 off coupons can actually move the needle on the stock price. Uh, and on executive compensation, this is a big deal, uh, for, uh, for a lot of, for a lot of companies.

There's also the risk of accounts being taken over. So, you know, some, uh, retailers offer loyalty, uh, loyalty perks and benefits. So you can accumulate points and then you can apply these to purchases.

You can transfer points between different accounts. Uh, if you are for think about hotel chains, these points can actually buy you, um, future stays in hotels. Um, there's a lot of things you can do when you take over an account.

I mean, these are tangible things like loyalty points, but also untangible things like, if I access your account, uh, at a Marriott, I now know your name, your address, your payment information, even if I've, even if I stole nothing per se, I have a lot of information I can then use against you or to, to, you know, to present myself as if I'm you. And account takeovers are also something that agent AI in the wrong hands can help scale of things. At the end of the day, you need to guess a lot of passwords.

Um, and with the right, uh, set of, uh, technology that helps you automate things at scale, you can do that, um, pretty easily. Those are just two examples of where retailers can actually be impacted, um, and significantly impacted, um, um, by fraud. The, a lot of instances where the retailer is, is trying to provide you with the specific tailored experience based on who you are.

If you are considered a good wanted user, if you're considered this new user, the cost of acquisition is so high, they wanna make sure they maintain, maintain you as a customer. They might offer you unique experiences, discounts, uh, promos or whatnot. Uh, and fraud and identity fraud can significantly, uh, deter, you know, the, the purpose of, of these, of, of these unique experiences.

So, retailer challenge is always to understand who they are dealing with when they see someone opening an account, trying to transact, trying to make a purchase, even when they reach out to customer support to either initiate a claim or, or a complaint. All of these things can be manipulated by fraudsters. And of course, until now, the scale was not significant.

With agen ai, again, in the wrong hands, this could become an extremely significant problem for a lot of merchants, retailers, organizations. Well, folks, you heard it here, we have yet to see something that is maybe uniquely different than somebody created as fraud for ai. But the level of scale is gonna be a lot different and a lot more challenging for sure.

Dole, thanks for being on the show. Yeah, of course. Thank you so much, mayor Forgus.

All right. And thank you all for watching the latest episode of the Techstrong AI Leadership Insight series. You can watch this episode and others on our website.

We invite you to check them all out. Until then, we'll see you next time. Hey, everyone, we're back here live at Platform Con Day in New York City.

com, register for the virtual event. It's been going on all week. I believe you can watch these sessions from earlier this week on demand.

Go do that. Do it right after you watch this. But for now, let me introduce you to what this is.

I wanna first introduce to my immediate left, Leah. Hi. Hi, Leah, your last name, I'm sorry.

I'm Leah Rivers. Leah Rivers, welcome to Techstrong tv. It's great to have you here.

It's great To be here. To my far left, James Brook Bank, Brook Bank, easy names, E two easy names. Thank you.

Thank you parents. James, welcome to Text on tv. Hey.

All right, let's jump into this. So, Leah, you, you are with Google. Yes.

Tell us kind of your physician, give, actually give us a little bit of your journey, how you wound up here today at Google. Sure. Uh, well, I have a, a background in both computer science and anthropology.

And so my career has been kind of a, a mix of really taking, kinda the heart of really understanding from anthropology and the possibilities and technical, um, insights of computer science and putting those together, really trying to help create, uh, technology systems that enable, you know, humans to, you know, keep getting better at getting better. So that's led me through, uh, you know, working at cloud, uh, in various like cloud scale problems, um, other cloud providers, um, and startups. And, uh, eventually to Google where I get to focus on leading product for Google's internal developer platform.

Kind of a dream job That is, I, especially here at the platform engineering com. That would be like, I, yeah, if we said, Hey, who would like Leah's job? They'd be lined up from here to the end.

And today, uh, James and I are here at Platform Con, and we're, uh, we're kind of representing our, these are our personal thoughts in this conversation today. Not on behalf of Google. Our formal talk is later.

I gotta be honest with you, I've been in tech a long time, 30, 35 years. I've been doing interviews like this for 12 years. You may be the first anthropology major I've interviewed.

Oh, I didn't quite get my anthropology major. I think I was one class away from actually com, but it came down to computer science or anthropology. I had to go with the computer science.

You went with computer science. Oh, okay. I loved anthropology.

I have to tell you, look, I was a poli sci history major, so what do I know? Oh, yeah, yeah, yeah. But, and we all wind up here eventually, but that, that's a fantastic thing.

Um, so how long has Google had a formal internal developer platform, if you know? Um, well, I've only been at Google for three years and it, it predates me. It was well established.

So It was well established by the time I arrived. It, do you know, to the point where they're putting product leadership, you know, I, my, my, my role as director of product, um, um, so it, it was established enough that you added a layer, you know, of product management capabilities to that Formal product. And In my experience, you don't put product management on a platform to help make it better.

You put it on when it's really successful and you really wanna amplify that success and accelerate You, you have to have a certain level of maturity there. Yeah. Well, Well before we had a cloud, right?

In this scenario. And, and I guess just for context, right? So, um, while, while Leah sits on the, the sort of core pieces and looks after those, those elements for the whole of Google, um, like myself, I look after a team like solution architecture where we only really worry about the cloud piece.

And that like sits as one of the customers for the overall, you know, alongside YouTube and Waymo and all the other cool things in that space. And, you know, for the cloud platform that really is, you know, sort of 10 so years old, right? In its modern sort of the way it looks.

And well, before that, there was an existing platform within, within Google listing. You know what's fascinating? If you ask most of the people here, they think of IDPs as, as rather a new thing.

Just like platform engineering is a new thing, right? And, and it's almost always hosted, right? Mm-hmm.

Yeah. Um, but there's no reason it has to be, and and quite frankly is, I think in the case of Google IDPs have been around a lot longer than, you know, the, the, the, the invo platform engineering kind of, It's been a, a long time since sort of Verna came out and said like, you build it, you run it. Right.

You know, that's 20 odd years now, right? But like, that was the year where platforms are being constructed at other hyperscalers as you as you know, so, you know Yeah. A long time.

Yeah. It's like, to take the anthropology lens on that for a minute, um, one of the effects I think we're seeing is, is like there's new vocabulary that comes out. We, we get better at understanding the core issues.

We're solving the opportunities and new language comes out. So the, you know, the, the language of an internal developer platform or the meaning of platform engineering has, you know, sort of bubbled to the surface as the thing that we have in common and we can, like, get better at. But the concepts and what we're doing and how we're doing it, we've been working on those for decades.

Same, same things put together in new ways. Yeah. You know, it's funny as well, 'cause I, I, I obviously don't, I don't have a degree in anthropology, but my degree is in biochemistry.

Mm-hmm. So it's a very strange sort of space that I think a lot of us get into. But you'll hear us talk about like things like ecosystems a lot mm-hmm.

For that same parlance that like all those components are still fundamentally, well, some, some have evolved over the years. Sure. Um, but to extend that analogy, like the way the ecosystem works in this space is really what we're interested in.

And some of that is very much terminology. And some of it we see, I think talking to people today, like, Hey, you're doing something new in an interesting way, but it, it's a way that you've re-contextualize all of those components. I get it.

Kinda like carbon atoms, how easily they can combine with other elements and Stuff's not so much. That's, Yeah. Well, I just, that's about all I know about chemistry, so I went with it.

You, you're technically correct. No. Alright.

Now you guys are presenting here today. Yeah. Yeah.

Yep. What are you presenting on? You, you should say shift down, getting that shift down.

Shift down. All right. You know, scale up.

Look that camera down, down scale Left down to scale up. Shift down. Shift Down.

Alright. That's a great catchy phrase. Yeah.

It's, it's a natural, um, extension of shifting left. When we shift left, we move things earlier in the developer workflow. We help developers do things faster or, you know, more correctly.

But we're not fundamentally changing the things that developers are responsible for. With platform engineering, we have the ability to systematically solve problems in the platform that, you know, need to be solved globally. So we can take it off the plate for developers.

Um, so they don't have to think about the implementation at all. I think, I think it's, it's one of those things we talk about as well. 'cause people are often like, well, aren't we doing that with DevOps?

You know, and I spent a lot of time, I work with the Dora team at Google, which does a lot of sort of DevOps research work, which is, um, you know, I think very insightful in this, in that we've all got the same goals. We're all trying to achieve some of the same things in these areas. But, you know, a lot of the things we, that we've tried to do in DevOps, um, have worked effectively almost so that it's become the standard in many areas.

Um, but sometimes when we've shifted some of those things left, we've become kind of overwhelmed. Like, there's just so many topics. There's so many new things to tackle so many security vulnerabilities every day.

And that's overwhelming out of it. It's overwhelming me, right. I'm constantly having to deal with these new things.

So, you know, I, our sort of view, I think in that space is we're not stopping the DevOps journey. Like that's still a very normal and healthy thing, but, but at scale, we, we've gotta do something to start pulling some of those capabilities down into the platform and, and, and stop overloading our development teams. And, and I think that's what the, the vision is in this space.

I, I, I agree with you. I, I think, James, what you just described is actually the reason for being of platform engineering as we understand it today. Yeah.

Which I, I was talking about it. Our last guest just wrote a book on platform engineering for O'Reilly. Oh, Camille, er, you get a chance.

She's also speaking this afternoon, I think one of the problems, and it, and it was the problem with Shift left, and, and let me preface all this. com. I'm a big DevOps fan, right.

I've got 30, 35 years in tech. I, I think DevOps is a great thing. And it really changed the way kind of we look at working together.

The problem with Shift left, which was, you know, fundamental in DevOps, is we, we've set up this religion that we pray to the developer, God who's the predator, alpha predator at the very top of our food chain, the orca of our food chain and everyone else kind of exists to make that developer better. Yeah. But you just can't keep throwing, it's not an omni potent being.

He's, they're a developer putting more and more on their backs eventually that camel's back breaks. Yes. And it, and that's because it, it's a person, right?

Like I'm a developer, so when I go and ask from, you know, my internal platform teams, like, Hey, I need these things. Like, that's your responsibility. Now.

I don't want that responsibility in some of these areas. Developers want it develop. They don't, you know?

Yeah. I, I, I think that was a fundamental mistake where we said, Hey, developer, you're responsible for developing your own platform, right? Yeah.

No, that's not the way I think it was supposed to work. But you're disagreeing. Well, no, No.

Well, we is a necessary learning process along the way, you know, we try, we learn. That's, that's kind of the whole thing. So we can thesis anti synthesis.

Yeah. And we get better at identifying the actual stable sub problem that we can solve. And if you like, we've built up a big practice around focusing on, you know, instrumenting and focusing and understanding that I'm doing the, the affinity loop here.

Mm-hmm. The, uh, you know, the developer experience. We could have a blind spot or a streetlight effect around that because it's really understanding what they're up against in terms of scale, in terms of what we call quality attributes or non-functional requirements.

These big challenges. And looking at where opportunities are to solve what they're up against on their behalf. And you have to look outside, you have to expand the frame beyond simply looking at how they're working.

You fundamentally wanna change how they're working by taking some of the those tasks away. Yeah. And I still want that freedom, right?

Like as a developer, I still want the freedom to operate. And that's why we can't go back, like the DevOps journey that we've been on. Like, we can't go backwards into, oh, I now I just throw it over the wall.

I want to have that optionality, but I want it with the comfort of being provided those quality attributes, being given those things as part of the platform. So, you know, if, if, if I decide that, oh, I think I need this new feature, and then suddenly it's not available from the platform we're back at 20 years ago, right? So we have to go through that journey.

We have to have that constant iterative process for that. And that's very DevOps itself. Yeah.

No, I preaching to the choir, right? com and, and I, I don't think they're mutually exclusive at all. I think they're That's the continuum here.

Yeah. That we, that we live under. And, and you one be got the other.

Yes. And, and, but it is an infinity loop to your point. Um, we haven't mentioned ai.

It's been, it's been, I don't know, 10 minutes. That's a record. How is that playing into Google's IDPI mean, they're all about Gemini, right?

That's all we're hearing. I see it every time now. How, how are we, how's this playing in?

I mean, you know, I, I think there's a, there's a, there's an open talk track here. We've published, so I think some, um, some very obvious numbers in the past about how much code is being written internally, um, by, by AI or in this scenario in terms of our internal platforms. And that's getting to the sort of 20, 30% rate.

That's a huge amount of code being generated in those spaces. And that's done by our internal equivalent for, for Gemini. Um, I think the distinction there is we want to do that in a very cautious way.

We want to make sure that there is a human in the loop for, for almost all of these changes. And, you know, when we, when we talk about how we embed those, uh, into our platforms, that's gotta be done in a very conscious way. So that's already, I think, quite effective.

And if you think about the history of Google, we've been using ML platforms for a very, very long time. And so, like having those capabilities using them, that's already happening today. So that's already changing, I think what if we're doing, but I think there's a lot of areas where it doesn't necessarily change what we need.

I'm more and more dependent on the platform to provide all of those quality attributes for the model usage. Right. So I've got even more platform dependencies and even more asks from, from the IDP, But that's not a bad thing.

Yeah. It, it's like another way to look at it is, platform engineering solves business problems, right? And, and so the goal, like the commercial goal of platform engineering in any organization is to maximize value with existing resources at acceptable quality with sustainable costs.

And so our ability to work with the resources available and solve more and more complex problems just gets better and better and better. And, and AI significantly helps, but still that same goal that we're, we're working towards. Understood.

Understood. So have you been here most of the day? I don't know if you've logged onto the virtual event at all.

What, you know, the vibe here is high energy, certainly. I mean, it's not a huge venue, but it's packed. Mm-hmm.

I heard London was even bigger, know. Were you there yesterday? I, I wasn't.

I'm from London originally, so I was missing out, but I, I think I'm too old now to try and do back to back. Yeah. No, Lu Luca ante from, uh, human tech from the pleasure's a big horse.

He did. He was there yesterday of flew back. I said, unfortunately, we don't have the Concord anymore.

Right. Mine, you might never do it. Ease.

I had A, had a couple of colleagues there as well. And, and I think, um, this was something where we, we, we weren't in person last year. We did like a watch party.

It was in Austin, and yeah, there was a lot of demand. And I think that's surface today. Like there is a lot of demand here.

I've been been talking with a lot of people here, some, some existing customers, some people who've never, never really heard of Google Cloud itself. Mm-hmm. I don't think anyone's not heard of Google, but like the Google Cloud piece.

And I think, you know, a lot of, I think very interests, um, very interesting conversations around all of the topics inside platform engineering. But we've got away from the time of, is this a thing? We've moved past that in this space.

So everyone has come here for how do I solve this particular problem? How do I go tackle this particular area? And, and I think that enthusiasm that we, we, you know, for a while was like, oh, is this gonna kind of fade?

Or like, it's really just matured. I, I think it is maturing. com.

Every fifth article is what, what, what is DevOps? What's what is not DevOps? And now we are doing that.

Um, we've moved past that. We've moved past that with platform. Well, we've now still gotta argue what's our own definitions of DevOps versus platform engineering.

So, yeah. No, One of the things I've really enjoyed, uh, in my conversations and being here with high energy today is whether you're building, you know, at Google scale and supporting platforms at that scale, or you're, you're building at a startup, it, when we start talking about the problems of platform engineering, we have the same problems. Yeah.

It's pretty consistent. Yeah. And You know, there social problems as much as they are technical problems and kind of the thing you, you get to notice as you solve these problems over and over again, is no matter how good you solve a particular problem, like if you're successful, you just have another problem.

Get more On that. I don't know if you ever read, do you know the, the book, the Goal? Have you ever read the, oh, you Had the Goal, Eli?

Yeah. Yeah. So that was more manufacturing than tech, per se.

But that, but that's the whole point. Yeah. As soon as you solve this bottleneck, there's a bottleneck behind it the next Yeah.

Yeah. And so We have lot that's business. Yeah.

It's job security. Anyway, we are about outta time. Okay.

Leah, James, thank you so much both for coming on. You know, we do a podcast on platform engineering. Actually, Luca and I, oh, uh, called the Platform Engineering Show of all things.

Love to have you guys come on one day. You know, it's remote. We don't Yep.

Can't always get together in person, but we'd love to hear more about what Google and Google Cloud are doing around your IDP around platform engineering. Yeah. More, more to come.

Right. We've got more to come, I think in that space. There's a lot of things in preview at the moment and sort of, you know, I think just excited to be part of the platform engineering journey with the community.

Love It. Yeah. We're live here at Platform Con.

Thank you very much to Google and Google Cloud. James and Leah, thank you. We, we have more coming up in just a moment, so standby.

Hey everyone, welcome to Control Alt Deploy. This is episode two, and we're glad you've joined us. I'm Alan Shimmel of Techstar Control.

Alt Deploy is a video show we do with our good friends at OpenText, where we talk about cutting edge, leading edge stuff, topics around DevOps of all things. Um, we're really glad you're joining us. We have a great panel.

How often does this happen? I'm the only guy on the panel. I have three amazing women to introduce you to who's who are on our panel today.

Let me introduce you to them right off the bat. First of all, joining us, uh, from New Mexico. She's the CEO of Deploy hub, open source, CDF board members, uh, on several boards, our friend Tracy Reagan.

Hey, Tracy, how are you? I'm doing great. I was gonna mention this.

I think that this is the first time I've been in an all female panel. It's very cool. I love it.

Not that I don't like the, the dudes on the panel as I'm not saying that. It just is extraordinary. It's all women.

Yeah. Now, you know, we didn't plan it this way, to tell you the truth, but hey, more power to you. Good for you guys.

And it's, it's, I, I feel flattered to be here joining us from Canada. She runs the, uh, one of the leaders of the Canadian DevOps community, but really a worldwide, uh, person in the DevOps world, as well as top contributor at the CDF. We've just been informed, my good friend, Garima Boal.

Hi, Garima, how are you? I'm good. How well you, Excellent.

I'm glad to have you here. And then last but not least, he's from OpenText, Hillary Johnson. Hillary, welcome to Control Alt Deploy.

It's great to have you on. Um, I give a little bit of background. Um, I'm Sean.

I was gonna Say I'm the new person. Tell us. Yeah, I'm the new person.

I'm the senior industry strategist here at OpenText for manufacturing. I've been in manufacturing for 14 years now. Um, and so I've got a vast background from really small job shops to really large enterprise like me, medical devices.

So been in this for a hot minute. Got it. I appreciate you being on.

So, so panel, today's, uh, title is, uh, compliance and code security and DevOps navigate regulations and supply chain risk with ai. Well, everything's with AI today, but really as we get into it, it's a how can, how can our DevOps teams and, and let's not just confine IT to DevOps team could be platform engineering teams, developer teams. How can we stay audit ready and secure the software supply chain, you know, leveraging things like AIS and SBOs and of course automation.

And, you know, this was a hot topic before AI was hot. Of course, we weren't talking about using ai, but securing supply chain has been a problem. Certainly, you know, it first burst on the scene, I guess, with the SolarWinds breach back during COVID, right?

Where there was a, the malicious code inserted into shipping product. Um, Tracy, I know you spend a lot of your time focused on this, where, you know, ha has AI changed the game here for us? Where, where do you see Poten?

Where do you see progress? Where do you see we still need to make a lot more progress? Um, well, um, before last week, I would be far more optimistic.

Um, uh, I was at CD Con and we did a, a, a focus group around CICD cybersecurity. And I discovered that many of the DevOps engineers are not interested in adding security to their pipelines. In fact, they're flat against it.

They don't want to do it. Um, and that's because I, I don't think that there's, maybe, I don't know what the reason is. I don't think they wanna be disrupted.

Again, I don't think they wanna touch their workflows. Uh, so we have some work to do in DevOps around the understanding of why security is important. You know, I, I keep my foot in two different worlds.

I'm on the board of the open source security foundation, so I understand in here what they're working on. I know about their new tooling, like proto bomb, and then I have the other foot in the, in the C station, and I'm on their technology oversight committee. And I see that there is a very, very large gap.

I'm practically doing this place here, folks between the two worlds, because there is such a wide gap. Um, at our focus group, one of the most concerning things that I heard, but I heard many of them, the, the first one was, they don't believe that SBOs are important to incorporate into DevOps pipelines because they're not always accurate. They're just a check box.

And without consuming the data, it's useless. Which I agree, that's why Atill is around. We're consuming that data and making it as actionable.

But the point is that they don't see a strong need for securing the code base through the CICD pipeline that somehow is an engineer's job, a software engineer's job, and not something to be automated. And I, you know, this, this concerns me because if we're not looking at disrupting ourselves, we will be disrupted. There will be two younger people come along and do things differently.

And AI will be part of that solution. There's just no way to stop it. It's a freight train.

Get off the tracks. Yeah. Gima, I'm, I got to tell you the truth.

I'm, I'm shocked. How about you? I'm not that shocked.

I think that, you know, I understand where Tracy is coming from. I am also associated with the Cortes Delivery Foundation. We have a lot of ambassadors who are trying to steer the needle in the right direction.

And I also see that Tracy is heavily invested in, uh, open source security. But I understand, uh, the community kind of sentiment and, you know, not overlooking the recent past. Right?

You mentioned about SolarWind. We have seen log four js and we have seen x, uh, Z back doors, you know, so the regulatory pressure is intensifying on us, whether we see it or not, right? Regulations like EU Cyber Resiliency Act, or even the N two in Europe, or executive order in, you know, us.

I think they are all reflective of the fact that we have to take security seriously. And SBO m is comprising of one of the biggest pieces of the puzzle when it comes to content monitoring, the vulnerability scanning, and maintaining that transparency in the system. So I would like to have a more discussion on this topic and raise awareness and see what we can do from a practitioner's point of view or community point of view to ensure that we, uh, move the needle in the right direction.

Hillary, help us Labor shift going on right now, right? You've got old labor kind of coming towards the end of their career, younger labor who doesn't quite understand some of the, the trades or some of the manufacturing world. Um, and they're looking for new tools.

So I think it's gonna be, at least from what I can tell, is there needs to be a shift in thinking from upper management and from owners, and even SMBs. You know, nobody likes change, but it's inevitable. Kind of like what cybersecurity was when you were breached and, and manufacture, I know from a manufacturing point of view, they didn't think it was gonna happen to them.

Um, and so they, their, their guard was down. So eventually, maybe it's, you know, um, where they need to see it, that it's happening to somebody else, or, you know, okay, I, it hasn't happened to me yet, so maybe it won't happen to me and I can focus on getting some other things done with my business. And so there is, there's gonna need to be a shift with the different kinds of people who are coming into the business full stop.

Um, and whether or not you like it is one thing, um, that's, I mean, my 2 cents, but I kind of, it needs to be a shift in mental, Well, we that, and that's part of the problem. We've been shifting. We've been shifting left, shifting left, shifting left, shifting left to the point that DevOps engineers are not shift, they're not left, they're not software developers.

So we've been pushing it all to the software developers and the DevOps engineers are like, that's not our job. We shifted all that to the, the, the developers. They're the ones that should be protecting their software supply chain.

But that's exactly the point. It's not the software dev software developers want to develop quality code, but they're not security experts either. It's the security people or the security experts.

But that's one of the, you know, I was at while you were at the open source summit last week, I was in New York at the platform engineering Con. And, and that's, you know, what a, what a dynamic community with lots of buzz and lots of, a lot of young people, to your point, Hillary, right? A lot of young people coming in here.

Even though, you know what was funny? I interviewed a lot of folks that were closer to my age and they said, I've been managing platforms for two, three decades. Managing platforms is not a new discipline.

Calling a platform engineering maybe is newer, but managing platforms is what we've been doing. And I think one of the reasons that platform engineering has struck an and, and gotten as popular as it has is that part of their, not manifesto, but part of their reason for doing it is you can't just keep shifting left and saying it's the developer's job to do, developers wanna develop, right? Developers wanna develop code.

They're not security people. They're not DevOps engineers, nor are they platform engineers telling developers that you're responsible for security. Oh, and by the way, you're also responsible for building the platform that you develop on because we're shifting everything left.

Well, that's not, that doesn't scale, doesn't when you get, when you get to enterprise levels, that doesn't scale. However, I am surprised to hear that DevOps engineers would want to sort of abdicate their responsibility in terms of, because it, in terms of secure code, because it's not just the software engineer who makes sure it's secure code. What about testing, right?

That to code, code needs to be tested. Whether it's, it's whether the code's written by AI or people or both, it needs to be tested, right? We, there should be a pride in what we are in what we are doing at our jobs where, no, I'm not gonna release shoddy code, I'm not gonna release insecure code, I'm not gonna release code that doesn't comply, comply with regulations and compliance.

Right? I think what we're hearing is more what Hillary said is it there is sort of an old guard that wants to stick their head out the window and say, I'm fed up and I'm not gonna take it anymore, right out of a movie. And there's also a lot of people in, in the workplace who, you know, this is their fifth disruption in the last three years.

And, and they're shell-shocked, right? They just want to dig their heels in. And honestly, I'm fed up, I'm not gonna take it anymore.

But progress waits for no person, man or woman or what have you, right? No person. And so they can, they can protest all they want.

That doesn't mean that SBUs aren't gonna be required. That doesn't mean that AI is going to stop writing more code and having as big a, a bigger impact. Wait, wait till the agents come in, right?

We, we, we spoke about that earlier in our episode, one of control alt Deploy. And I apologize, Tracy, Hillary, you aren't on that episode, but Mima was on with me. And, and, um, you know, we spoke about what agentic AI is going to mean for DevOps engineers, right?

So thinking your head in the sand and your head and your, and your heels in the sand, I don't think that's a, I don't think that's gonna work here. Yeah. So I think what I, what I, what I saw what in that meeting, uh, was a lack of curiosity.

Um, because I am one of the most curious people. I know, me and Brian Dawson were kind of OCD about things, and we'll get on something and we really will research it and have fun playing with it and trying to understand it. And I, I saw a lack of that curiosity in that group.

Um, and I understand that they probably have a lot of work on their plate to keep those brittle workflows up and running. And the thought of trying to create something new, maybe an overwhelming task. But what one person said, struck with me, stuck with me, is he said, PE people will start generating SBOs when their bottom line depends on it.

And he was a company servicing the, the, the public sector. Uh, he said, we don't have a choice. We have to, but we still feel it's like a checkbox.

And I could submit the same SBO over and over and over and nobody would know the difference. Which is a true fact. Totally True.

So that, that is true, right? Yeah. To me, the SBOs always seem like the tag on my pillow, that if I tear it off, it's a federal offense, but whoever reads what's on that tag, right?

And I'm always eager to tear it off just so I can break The law. So that's, that's the kind of person you are. Exactly.

Who else here, Hillary? Do you pull the tag off? What?

Do you read the tag? No, I don't want the tag in my ear if it pops out of my pillowcase. Um, I think, I think the thing is that is so true.

People are learning AI out of necessity. I learned AI out of necessity. 'cause I was doing the job of four people.

So as we're, as all of these comps companies are still running lean, they're gonna have to figure out that, that to date their, their heels in and start testing it. I think the other thing about AI is it's not a hundred percent accurate. Um, right.

You know, so you've got that, that cautious behavior behind it. Like, well, what if it isn't? I can't trust it fully.

Yeah. You still need a person to verify some of this stuff. And so how do you, how do you start progressing, um, still knowing that there's, you gotta have somebody who, who's checking all of this.

So, um, just 2 cents. I, I agree. See, so Tracy, I'm more like you.

I started using AI purely outta curiosity, and now I find it an indispensable tool to the point. Yeah, to your point though, you were doing the job, you had to do the job of four people, so you had to use AI as a force multiplier. So I was reading an article, I think I mentioned in the earlier episode, uh, mark Benioff from Salesforce claims that maybe up to 50% of the work being done at Salesforce now is being done by AI and agents and stuff.

I don't know if I believe that to tell you the truth, but that seems, you know, is, is this where we're heading? Are we, let's say it's not 50%, is it 25% Garima? You talk to people in DevOps all over the world's more than anyone.

What do you, are we, are we already using AI that much? As I said, uh, in the first episode, I will stick to that. I think we are in the experimental phase for ai, right?

I mean, we are using AI for experimenting around a lot of productivity and efficiency gaps, which we have, right? And then we are also thinking about using it in different dimensions when it comes to like, um, exponential scaling. But we're not yet there.

And I, as I pointed out earlier in the episode as well, that, you know, when we look at things around, you know, we are building things with ai, like what type of code are we referring to? What kind of enterprise we are, like comparing it to? Because if it's a large enterprise, we have a lot of legacy, uh, systems, right?

So it's not easy to refactor, rebuild, you know, repurpose code, um, even for humans. So, I mean, AI is, uh, something which we should have a secondary thought on. If you are an AI native company, you are building an AI native platform, I would believe that there is a substantial amount of, you know, excitement, enthusiasm as well as potential what we can do with ai.

But again, you know, uh, we haven't substantiated this. Nobody has producted it in a larger scale. So we don't know how much technical depth we have built around this, right?

So there's a lot of questions around, you know, how AI is enhancing the productivity for DevOps pro professionals. This is yet to be seen. Hillary, what about your experience at OpenText?

And don't say anything that's gonna get us all in trouble, but, you know, is, is AI doing that much of the work around there? That's what part of the company you're in. Um, you know, from, from a marketing standpoint, probably more so.

Really? Um, yeah, very much so. I mean, it does all the research for me.

It, it, it writes a lot of stuff. It gets me started. I'm not a writer.

So, you know, there's plenty of times where I need someone to get, um, my thought process going. Um, you know, in a manufacturing, uh, in a manufacturing perspective. I know of friends who have smaller manufacturing business.

Let's take this from the size of the business. You were saying. Enterprise has a harder time.

'cause they have legacy systems, they've got disjointed, you know, Salesforce, half the time, one's in Europe, one's in the us one, you know, they're all over the place. Um, smaller companies are really starting to explore this more. 'cause they have the bandwidth to do it.

They don't have as many legacy systems. So I would say almost reach out to those smaller innovation businesses and see how they're handling it. Maybe let them be the Guinea pigs, create some friends, create some networks, right?

And figure out how they're using it because it's gonna need to scale. Enterprise is is incredibly disjointed. And it, there's so many processes.

I think small, I think the smaller to medium sized companies are actually gonna kind of pave the way on this. And this is just my prediction if I get my crystal ball out that, you know, they're only gonna be the ones helping this. Yeah.

You know, we saw this in DevOps, right? When DevOps first burst on the scene, there was this whole argument, is DevOps better for small medium companies where they have to do it by necessity? Or is it better in enterprises where you can do it at kind of great scale?

And, you know, counterintuitively, I I think it was both, right? It worked, it worked to both. Now, if you talk to the platform engineering people, they'll tell you it's when you really start scaling up that DevOps runs into scale issues.

And that's why you, you can help with platform. But let me, let me put something else in front of you, the three of you, and see what you think about this. If you are gonna believe that SBOs and, and like a lot of security, it's what we call checkbox security, right?

Compliance is the least common denominator type of security. It's doing the minimum you gotta do to comply with whatever your regulations are. But if, if SBOs are part of that least common denominator security that we need, isn't automating that with ai, the easiest thing to do then, because if, if it really is not that important, but we still gotta comply.

Wouldn't I wanna just automate it and get it out of the way? Tracy, I'll go it to you first. Yeah.

Generat, generating an SBO is easy. We don't, there's many tools out there that will generate an sbo. M it's very simple, uh, command line to add to your workflow, by the way, folks, very simple.

It's about as simple as they get. It's probably four words. So generating SBO m is not necessarily the issue.

I think what the issue is, is touching the scripts and dealing with, um, any modifications to the workflows themselves. That's the, that's the real issue. Unless it has real benefit.

And that is the problem with SBOs. Yes, everybody should be doing 'em because it's the first step down the road, right? But then there should be a second step.

Evidence stores are important. Let's start gathering that information. Let's start watching for changes in the sbo m What is different between this, this build and the last build?

Are we bringing in new package versions that we were, um, that the, the developers have have updated now we need to make sure that the testers go through that, make sure that it's properly tested. How can we make the data actionable? If we do that, then DevOps engineers will be more motivated to use an SOM because it has a purpose.

Right now it's just a government regulation that says you have to have one. So why, if I'm a, not, if I'm not delivering code to the US government, and I don't have customers who are demanding an sbo m why would I bother? I, I totally understand the sentiment.

I understand why I would bother, because I, I wanna know what, uh, I, I really do wanna know how compliant those packages are that I'm consuming because I'm delivering code to customers. So I need to protect myself. And the way to do that is to know, again, I'm curious.

I'm a curious person, so I wanna know what's happening. I wanna know what's coming through the pipeline, but not everybody is, and you know what's really gonna change DevOps, it's when DevOps engineers are gonna start having to manage AI agents and LLMs, that means that they're going to have to change the way they, you know, our, our DevOps pipelines are pretty traditional still. The two, the two pieces that we do is we run a build, right?

We take code and we turn it into binaries, create a container, and then we call a deployment tool. We, you know, DevOps pipelines themselves don't do deployments and they don't do builds. They call scripts that do that work or they call external tools.

So we're doing builds and we're doing deploys, and we're happy. And that deploy may go out and may go out to testing or it may go out to production. We don't even have to worry about that because the deployment tool deals with that.

And most of the time we're consuming something that's a helm chart for that. Or we are, we have GI ops that's, that's supporting the de the, the deployment. So we really don't have a lot in the pipeline anymore.

We just have a ton of pipelines. Thousands of them. Thousands and thousands of pipelines.

So when we start asking for things like what version of the LLM was used in this build, that's when they're gonna say, well, I don't have an AI bomb to tell you that. And that's when we're gonna start seeing changes in the pipeline. In the pipeline itself.

It has to be driven by a serious need that's going to motivate a DevOps engineer to dig into thousands of workflow files and start updating them. Or guess what they might do. They might use AI to do that.

So they will, And, and if it, if it checks the box, they will. Right? If then it's, yeah.

If it's just a checkbox. Yeah. And so, you know, maybe compliance isn't the right driver, is what I'm hearing you say.

I don't think compliance is, is something that they really are focused on. The compliance is being forced at the dev at the shift left side, there's quite a bit of work that developers are doing. They're taking classes.

They're trying to learn to write better code, make sure that they don't have stack overflow issues, for example. They're working at that. But the DevOps pipeline, there is tooling that can be added to it that's not necessarily being added.

At the CD foundation's at our focus group, I asked if anybody knew what proto bomb was, which is a big tool that the CI that open SSF has been working on. Nobody understood what it was. They had no idea.

That's a big, there's a big disconnect between the two. And I wanna point out that these tools are coming out on a very fierce, there, there's new ones all the time for security that can be added to the DevOps pipeline. At the CD foundation, we're working on something called the CICD cybersecurity sig.

We're putting up a website that will have defined for achieving, um, the software, the secure software development framework, for example, NIST 800, whatever it is. Uh, we, we ha we are working on every single task and we're finding what open source tool could be added to the pipeline in order to achieve that NIST task. Because develop DevOps engineers don't have time to go hunt down tools and understand exactly every single task that you have to comply with, which is numerous, and what tools you have to add for that.

So we're trying very hard to understand what the DevOps teams are looking for. And what they're looking for is just gimme the information. What do you want me to add to the pipeline?

I don't wanna go sort out security. I manage the pipeline. What do you want me to add to it?

And how will it benefit you? So that's where we need to get to. Fair.

You know, I remember being a little boy in school and some sixth grade philosopher told me, all spaghetti is macaroni, but not all macaroni is spaghetti. Okay? Bear with me.

AI helps us with automation, but not all automation is ai. Right? And automation is something we've been trying to do in DevOps from day one.

'cause the very idea of automation seems to, at least, you know, the idea behind it is, oh, we could go faster because it's automated. We get humans out of the way. We, we could go fast.

It just runs as fast as it can. It's automated. And that's very much like AI is part, is a, you know, automation is a big part of one of the, the, uh, you know, the things that attract us to AI is it could automate stuff, take humans outta the equation and just do it.

And we spoke in, in episode one, the differe between automation and autonomous, right? Is autonomous ai, AI does more than automation, right? AI could bring autonomy, AI could do.

It replaces humans in, in so many in some ways. Um, what about non-AI automation in DevOps helping to navigate compliance and regulation and, and supply chain risk? Is it all AI is, is that, has all all automation now become ai?

Hmm. No. Reem or I see you wanna talk or thinking?

Yeah, I, I think, um, and, uh, you are right that automation is different from what we are seeing now. Because if you think about SBO M management, for example, we can automate a lot of SBO management stuff, uh, in the CICD pipeline itself, right? Versioning of SBOs, for example, vulnerability management scanning tools.

There is also SBO M platform management. If you are a fan of PLA platform engineering, you could appreciate that. But when we talk about ai, it is, uh, I would say there are four aspects which we have to consider, which is different.

First of all, timing of when and how we are putting automation into the stream, right? So that is very important because when we consider secure by design with respect to ai, it makes a lot of difference. You know, throughout the lifecycle, we are considering ai.

And that, uh, also kind of helps us understand that why timing of security is important. Our approach is also another factor because, you know, automation is often reactive. Um, uh, from AI perspective, we are more proactive, right?

They anticipate and mitigate threats before they occur, right? Integration, for example, is another, uh, aspect, which is also different because you are not only considering code, we are also considering data processes and all other aspects of like, modern model training, deployment, as Gracie mentioned, you know, what version of LLM you have used in the pipeline. So all those kind of things also become important.

And lastly, I would say adaptability. Adaptability becomes, uh, more critical. Because, you know, when you're talking about AI in the mix, it's more real time, you know, self-learning loops, you know, they, they can kind of enhance itself.

So it's a lot of other factors, which you have to think about. And again, that's the reason why I was thinking that, uh, you know, the AI integration and the, the, the journey of AI integration and SBO m in security management is still at an experimental stage. So I think RIMA used a very important word in that.

And that's adaptability. So right now, we have, we have job schedulers, let's just, CD is all driven by job schedulers, JINS Jenkins, a job scheduler, harnesses job scheduler. They're job schedulers.

And you pass things to them for them to execute and order. That is what we call workflow automation, right? That is what we do.

The problem is adaptability. Because of the fact that we use scripts to build that automation, it makes us less agile. Even though we preach agility all the time, we ourselves are not very agile because we can't adapt easily, which is why we can't add a lot of security steps to the pipeline.

So that takes me to why l uh, the potential for AI to manage our workflow instead of having a job scheduler. When we start moving into AI and having an LLM actually manage the workflow like a, like a cloud Opus four, then we can be more agile, we can be more adaptable. We can ask it to change faster.

So right now, humans are struggling with the, with being adaptable and changing what AI has and could offer to DevOps in the future, or platform engineering, whoever takes it on first is a more adaptable way of managing the automation. That's where we're stuck. Fair.

So, as, Sorry as I'm listening, um, I'm thinking about machine, uh, monitoring and then learning, and then what is, what can come from that? So, you know, when you have a lot of information coming in, machine monitoring, it's just putting the data out, and then you have a human who's, who's reading that information, the next step then is to take that information and have, um, your AI then analyze that information and say, oh, I'm seeing a forecast here, or I'm noticing a, a trend here. And then you can align it with things that are going on in, in the natural world.

I, I'm wondering if it's just a lack of like, curiosity, like we're saying, and they don't even know that there's this capability out there is, I've talked to people about AI when the biggest things, I, I talked, I talked to the president of an old company I worked for, I was 3D metal printing. He's fantastic. But I, he asked me, he said, Hey, how can I use ai?

And I was like, you were one of the smartest, you're, I mean, really, really smart gentleman. But we had a lunch meeting and I said, this is how you can use it, personal and professional. He goes, a whole, I didn't even know.

And the amount of platforms out there. So I wonder if it's more or less like opening it up and saying, here's what the actual capabilities are, versus just saying who's gonna take it first? Maybe you point out both y your POS particular position can do it this way.

And here's an example. I just think it's lack of understanding a lot of it, um, and not actually knowing what the different capabilities are because they haven't had the time to jump in. Everybody's working lean.

Um, so sorry, 2 cents there. It's almost, it's a progression one, right? You get, you get in all this data, but what are you gonna do with all that data?

Right? We got data everywhere. Everywhere, right?

But I think a lot of it is maybe they just don't know what the capabilities are and they need someone to show them Well, but also their attitude. You gotta be open to learning about the capabilities. I'm sorry, go ahead, jc.

We, we don't keep data in DevOps. That is a big problem. We, uh, so the data that we keep in DevOps is stored in log files.

Okay? Um, sometime they're checked in, but generally they're probably left on the, in the directory where the, the deployment was, uh, executed or the build was executed. Uh, we don't even create, uh, historical records of how, what a, a workflow looked like when it executed.

That's not stuff that's a DevOps pipeline, uh, gathers. So we have a problem with actually implementing AI around DevOps with a lack of, of data. So we can't, so let's say we are, we take a large company, I don't know, standard oil, whoever we wanna think about and watch their DevOps pipelines over the course of time and store that information in an evidence store, we could absolutely start watching a model and, and having that model make predictions.

But without the data, we struggle. Um, so these pipelines don't have that kind of information. Now, what we do have is we have workflow files that are checked into gi.

We have, um, build files that are checked into gi, we have POM files that are checked into gi and we have, uh, helm charts that are checked into Git. And the, the existing models can go look at those to regenerate things for us, right? But we don't have historical data to do predictive work because we are, the data is fragmented in log files everywhere.

Every tool has a different log file. They just get stuck in the director that they executed. And we're not doing anything with them.

Kind of like an S bum, exactly. Like an S bum. So without that, we as DevOps engineers are going to struggle with having the ability to do anything more than generates a, a new helm chart or a new, uh, workflow file from ai, which you can already do today.

You know, God helps those who help themselves. And I think people, I think there's so many things that AI can do for us, not take our jobs or replace us, but augment us and extend us and make our lives easier, better that, you know, there's gonna be, there's going to be people who work because of ai, and then there's gonna be people who don't work because they just don't want to recognize the ai, if you will. So I would, uh, also add something here, because we have been talking about this for a long time, that, you know, there's a lot lack of awareness at every level that you know, how AI is adding value to our ecosystem as a software developer, I did a talk, uh, at, uh, DevOps con, uh, in Berlin, and I started with this, that in 20, 35 years down the line, do you think that your software development, uh, would look the same?

Is the job the same, you know, five years down the line, what could change and what will be the challenges and risks when you start thinking about it? There is like a change in how practitioners would see, you know, software development and what skills are needed, how teams will be structured. Because there will be, if you like it or not, there will be a lot of AI assisted software development in the ecosystem.

There will be teams where you'll have like five code assistants as well as, you know, four senior devs in the same team. So how do you cope up with that? And then from an enterprise perspective, do you think that all the big bank changes which are happening, they're not human led anymore.

They are AI led micro changes which are happening in the ecosystem. You know, if you open your eyes, you see you, you're using copilot, you are using, you know, all these tools and time has come, you know, people have to realize that their job is changing. So now you have to think about your left hand side and right hand side of the brain, like what needs to be getting added to your left hand side of the brain, which is like creativity, you know, your co-creation with AI tools and capabilities and right hand side of the brain, like what?

Computational logic, statics stakes and LLM models and all those kind of things, which needs to be up, uh, you know, upgraded to your skillset. So this is like, you know, this is a self re reation. You know, you have to think about what, how the industry is changing and what is in, for me as an individual, as a team, as an enterprise, right, as a leader.

Agreed On, On love That you agreed too, Hillary. All right. Hey, you know what, though?

We're at, we're about outta time here. This has been a great conversation. Look, I, I think every day the way how fast this AI stuff is moving and, and compliance will need to catch up towards doable with AI too, right?

Compliance is, is in, in and of itself will become a moving target. So this is gonna be something we're gonna be watching going forward. But for now, Garima, Tracy, Hillary, thank you for joining us on Control Alt Deploy.

Thank you to our friends at Open Tax for sponsoring. This is Alan Hummel. I hope you've enjoyed this episode.

Stay tuned for more. Hey guys, thanks with Throw, we're here with Jaa, who's president for Ware, and we're talking about a survey they did related to threat intelligence of the recent RSAC conference. And it's kind of surprising 'cause well it turns out that not that many folks are getting a whole lot out of that threat intelligence, but I'm gonna let him explain.

Jawa welcome to show. Yeah, thank you Mike. It's a pleasure being here and I look forward to the discussion.

Alright, so what is going on here with the usage of threat intelligence? Because on the face of it, it almost seems like it's another one of those oxymorons. Yeah, so it's, it's two parts, right?

If you look at it, hey, the top tier of the enterprise segment, the large government organizations, they're leveraging cyber threat intelligence in a very sophisticated way, if I can put it that way, right? So we are seeing a lot of traction with large banks, you know, big fortune 500, fortune 1000 type of clients. But where we are seeing adoption, I wouldn't say lacking, but it is getting better as we speak.

You know, moving from legacy tools into full on cyber threat intelligence is as you go one, two tiers below. Uh, and that's a little bit of flexible what we heard in that survey feedback, right? Where they see, hey, cyber threat intelligence is absolutely critical for my overall security needs, but I'm still struggling to operationalize that cyber threat intelligence, which is where cyber we come into play.

Where our goal is to help customers of all sizes operationalize that cyber threat intelligence. For those organizations that are struggling with figuring out what to do with threat intelligence, what is the fundamental challenge that they're encountering? Is there just too much noise and not enough signal for them to do something that's actionable?

I mean, I get that the big guys understand it, but one are the folks who are just newbies to this encountering Yeah. Beyond the, the large enterprises in the large government organization, the top challenges that we see is still, they're tethered with lots of legacy technologies that they're continuing to invest in. I think of the SIM tools that have been around for 15 years, uh, where they've not seen the operationalizing part of threat intelligence, something that they can go get started.

Uh, that is one of the biggest challenges that we have heard from customers because yeah, I need to bring in three, four different tools to effectively operationalize the threat intelligence concept itself, which is what we want to simplify, again, bringing in multiple components into the threat intelligence concept, if you will. Not just the traditional threat intelligence platform, but also other things coming to it. So that is where, you know, we cyber, we're pushing this market so that these customers can seamlessly turn on get started or mature their existing CTI program.

And to your point, we hear a lot about how organizations might be centralizing the management of cybersecurity. And part of the issue that drives that is the consumption of threat intelligence. But other folks will say that they don't want to consolidate 'cause they don't want to be overly dependent upon one tool, and they like having that defense in depth.

So, can I have my cake and eat it too here? Can I find a way to operationalize threat intelligence across multiple tools? Or do I need to centralize my platforms?

You don't have to put all your eggs in one basket. Uh, in fact, again, as we are looking at different tiers, different segments, the upper end of the market, they have multiple threat intelligence feeds typically coming in three, four or five different feeds coming in. And they wanna aggregate that with one platform so that they can correlate that information, look at the high fidelity threats that they want to prioritize to take action.

But once you go to this customer base that we're talking today, where these customers, they typically don't have the skillset to ramp up on a threat intelligence program. So typically in this case, uh, they're looking for a way to get started, you know, to be very honest. Or maybe they have one feed a threat intel feed that's coming in, maybe an open source feed that's coming in.

They just wanna make more sense out of it and get more out of it. Uh, and that's really where, you know, we're focused to make sure that we're getting the right ROI for that set of customers as they try to operationalize their intelligence. What role might AI play in this in the future?

And I'm asking the question 'cause at least in my experience, the, the volume of the threats and the sophistication of the attacks is increasing beyond the ability of a human set of cybersecurity professionals to manage it themselves. Absolutely. So we're already seeing the impact of AI in cyber threat intelligence.

We're seeing it in the broader cybersecurity, but also within the context of SOC security operations center. But even if you zoom in within the cyber threat a thousand space, we're starting to see AI being leveraged. I mean, the starting point is using NLPD for threat queries, uh, what type of threats I'm seeing, how should I prioritize my threats, what actions I should be taking?

So that's kind of table stakes, if you will. But where we are seeing this heading towards, and I would say in the next 12, 15, 18 months, is a true multi-agent agent AI approach where threats are important, but what do I do with these agents or the multi-agent approach that I'm taking to solve some of the specific problems that I might have been using a legacy tool in the past? And maybe I'm, I was just doing that response in a manual fashion AI and multi-agency approach is going to automate a lot of that in the context of cyber threat intelligences, Of course, not all threats are equal and not all threats are equal to the same organizations.

And so will we be able to get better at kind of identifying which threats actually have the greatest potential impact for a specific company? Because, you know, a lot of the times they'll look at the threat and they'll say, oh, well I already got that protected. And other cases they'll won't be able to understand that this threat is particularly weak for them.

Exactly, exactly. Not all to the same, uh, are not all threats are equal. And even if you look at threats that, you know, what we call as high fidelity threats, high priority threats that you wanna focus on, it might vary by sector to sector.

What's critical for financials might not be imported for manufacturing, might not be, might be slightly different for healthcare. Uh, so we are seeing that evolve where sector specific threat intelligence, threat intelligence management is becoming a higher priority or a focus, uh, as we've seen in the last, you know, couple of years where it's not about CTI's cyber threat intelligence, a one size fits all approach. We gotta be prescriptive about cyber threat intelligence management and response, the action part, and it's based on the size, it's based on the sector, it's based on the geography that you're in.

Uh, so again, you know, not all fits are equal. It's not a one size fits all approach. And this is very, it becomes super critical.

Again, I go back to that border around operationalizing cyber threat intelligence. You can get as many feeds as you want if you're not prioritizing, enriching, correlating the threats the right way, you're not gonna take action on the high priority threats that you should be focused. What else leaps out at you in this survey that you guys did?

I mean, besides the threat intelligence stuff, is there other things in here that you know, you think that, you know, should be top of mind for folks? Yeah, a couple of things that definitely that, that was a stand out for us with the RSA survey, but also we did a follow up survey at the InfoSec event in London, uh, which just happened a couple of weeks back here in June, 2025. Uh, what came out for us was clearly customers or, or, or the industry itself as starting to prioritize cyber threat intelligence.

Uh, what they've struggled in the past is to truly operationalize it, and they're looking for a platform that'll help them get there. The second thing that we're also seeing is a, beyond cyber threat intelligence, there is an integration that we are seeing with other areas in cyber, you know, be it digital risk protection, exposure management. Uh, and, and that's something that we are aligning ourselves.

For example, we launched Compromise Credential Management that's integrated into cyber threat intelligence like a month ago. So that integration, that alignment of architecture is happening as well. And the third thing I'll really point out is compliance in the past used to be more of a checkbox thing as it relates to cyber threat intelligence.

Now we're clearly seeing CTI as cyber threat intelligence as a requirement for some of the compliance needs like ISO 27,000 1, 20 22, the deadline is coming up October 31st, 2025. 7 a need to have a cyber threat intelligence program in place. So we're, we're starting to see this maturity come in in different directions from compliance, from obviously security, but also the response piece that, uh, we've seen over the course of the last couple of years.

Do you think there's a greater appreciation for the fact that it's now essentially a race against time? I mean, the minute that the breach happens, the longer it takes for me to fix it, the more damage there's gonna be. And so has this whole thing moved into kind of a, a near real time battle?

Absolutely. And how about flipping the script, not react, but be proactive looking at your threat intelligence information. So it's not about managing your logs.

We all did log management, event management, and we've been doing that for, what, 20 years now on the market. Uh, and we still see all of these big breaches, and this is where when we talk to customers, they're clearly saying, yeah, I need to focus on threat and managing threat intelligence. And that means, yes, I wanna be, you know, looking at things when there is a breach and looking at threats, you know, that I'm exposed to.

But how about flipping the script and being a lot more proactive and connecting the dots, if you will, even before a breach happens? Because I'm able to look at my adversary, the adversarial behavior, the tools, the techniques that they're using, and that means I'm better prepared even before a breach happens. So once that one thing you see your organizations doing, that still makes you shake your head a little bit and go, folks, we gotta be better than that, Continuing to, uh, sign up or renew their legacy tools.

I'll put it that way, right? And I've been in this industry for almost three decades now in a 27, 28 years. Uh, and a lot of times, you know, what I see, and I still shake my head, is, you know, something that they started using 10, 12, 15 years ago, uh, and it served a purpose at that time, uh, but they continue to do the same, expecting a different results.

So I, you know, I, I still shake my head, uh, with that. And then given the market that we play in, you know, again, coming to cyber threat intelligence, sometimes when I see a game in, in that segment, which is, you know, below the top tier, uh, not giving enough attention to threats itself. All right, folks, you heard it here.

Hey, there's a world of difference between responding to a breach and actually preventing one. And preventing one actually means you gotta lean forward and know what the bad guys are doing before they start launching that attack. So you can thwart it before it even gets there.

Hey, JOA, thanks for being on the show. Awesome life. It was a pleasure.

Thank you so much. All right, and back to you guys in the studio. Yeah, The world of enterprise, it is complicated enough, so why bother doing it at all when there are so many firms out there that are willing to let you outsource to them?

But have you answered all the questions in this episode of the Tech Field Day podcast? Enterprises shouldn't be outsourcing their IT anymore? Welcome to the Tech Field Day podcast, where each episode we bring together a group of IT experts to talk about a single idea or a topic in the world of enterprise it.

This podcast features a variety of perspectives from members of the Tech Field Day delegate community, and is often recorded in association with one of our events such as Networking Field Day. Tech Field Day is a part of the futurum group, and this podcast is also published on our sister site at Techstrong tv. In this episode, as we head into networking field day, we're gonna be discussing enterprise networks.

But before we get into that discussion, I want every one of our guests to introduce themselves, so you know, who's speaking, starting with ed. Hi, ed Whedon, uh, network engineer, uh, recovering enterprise network engineer at this point. Hi, I'm Chris Gunman.

I'm an executive advisor on network infrastructure topics. I'm Jody Liu. I am a data communications and networking consultant, uh, independent and very outsourceable that's relevant.

All right, thank you very much for joining us today. Let's jump into the premise for this episode. Folks.

Let's face it, IT networking is hard. We've been doing it for years. We think we've got a handle on it, and we kind of do, but maybe we don't.

And that's just doing the basic stuff. If you're trying to do anything more advanced than just connecting switches together, possibly running a simple routing protocol, who has time for that? Who has the talent for that?

Don't worry. We can take care of it. On this episode of the tech field, a podcast enterprises should outsource their enterprise networking.

Now, hey, I know that we've invited some people onto this podcast who are recovering enterprise architects who are responsible for outsourcing things, but I wanna kind of open the floor up to you gentlemen about this. Why are enterprises still doing their own networking? Because I know that when I used to do this for a living, I was responsible for doing networking for a lot of companies that quite honestly didn't care to have the IT talent to run their networks.

Yeah, it's a good question. I think, um, you know, you compare the fact that networking is absolutely fundamental to anything digital, which is most of what most businesses are doing these days, right? Even if you're making physical goods, if you run manufacturing, whatever, you know, at, at, at the base layer, there's, there's a network underneath.

Um, whether it's running the PLC controlled machines or it's conducting the CAD computers together, whatever. I mean, any business you look at now, um, digital technology is at the forefront. And that means networking is fundamental.

However, these companies are still looking at their network as a cost center as something to be run as cheap as possible. Um, and I think you're right, Tom, that like, why, why, why do it that way? Um, and there's a lot of conversation around, well, they should look at it as a, as a strategic asset, which I think is true in some cases.

Um, but if you're not going to, why do it at all? I'll even jump in and say, looking at it at a cost center is optimistic a lot of the time they don't think of it as all at all. Uh, not to be, okay, I'm gonna pull out a real geeky reference and pull our FC 1925 first rule, it has to work.

Most organizations, once it works, they don't care about it anymore. Everything else rides on top. They'll spend thousands of dollars to secure and automate their servers.

And anything in between the servers doesn't even get a thought. I feel all of this, I mean, just less left a sizable IT consulting company, uh, where I was focused on the internal, uh, enterprise network and, um, these, these comments kind of hit home. Uh, and, and it was always something that was a, that was an uphill battle, uh, for us for a lot of things.

Uh, because I, I think both of you are right. Um, you know, that view of the internal network as a call center or really a lot of IT functions, uh, not just networking, but I would say even some of the compute stuff. Um, you know, look, being viewed as a call center, wanting to get as much stuff off premises as possible, uh, and get it cloud managed or everything done in the cloud, you know, a lot of times your, your executive suite doesn't really fully understand the complexities that go into, you know, a modern network today.

Uh, and so that's, that's where that complexity challenge comes in. And how, how do you communicate that and say, yeah, we need to spend, you know, $5 million upgrading our, you know, enterprise infrastructure across like 50 sites, right? You know, and, and, and trying to explain that and, and say, yes, there, this is a cost, but you know, there's a benefit to this.

And it can be, it can lead to some very interesting and uncomfortable discussions for sure. Um, I also think that complexity as well, um, I think networks are getting even more complex as we start layering in more stuff like AI and automation over top of it as well. And, and it used to be that when you are looking at complexity on the network, that goes proportional to scale, scale.

So large networks are more complicated than small networks, but now that we're bringing in things like built-in security at the low level, even the smallest networks are much more complicated than they used to be. So if I've got, you know, 50 people in an organization and my network isn't very big, but I'm still baking in a secure network right from the beginning, that's more complex than it ever was before. And the expertise isn't always there.

So let me ask this question. And the reason that I, I wanna ask this question is because I understand that the IT department has this reputation for being a complex thing that doesn't directly generate revenue for the company. And I know that it's critical to the operations of what we do, but why is it that we outsource it so often when the exact same thing can be said about the accounting department and no one ever outsources their accounting, or if they do, it's very, very rarely, even though accounting is very complicated, you have to know very specific rules.

It doesn't directly generate revenue for the company. It does get revenue by getting all of the paperwork in place, but yet the first thing that usually gets tossed out the door is, well, all that computer stuff, somebody else can handle that. Well, why don't we let somebody else do the accounting?

Oh, no, no, we have to do the accounting. Well, I say that's an interesting question. I mean, and is that, is that totally true?

I mean, KPMG makes a ton of money doing other people's accounting. Yep. Do they do other people's accounting or do they audit other people's accounting?

I would say it's, it's the audit. Oh, okay. That's fair.

Yeah, that's fair. Yeah. That's, that's what a lot of them are doing as well.

I mean, that was from where, where we were, we were dealing with KPMD audits all the time, actually, it felt like year round. I, I think it's a, I think it's a really good point. It's, it's a very good point.

And like, you know, why not outsource other, other business functions? And I think for smaller scale, smaller scale companies, you know, more you asking B markets more on the smaller side, um, you could see some of that happen. Uh, but once you get, you know, again, it goes to that scaling question.

Once you get to a certain scale that stuff, you wanna keep some of that stuff inhouse, I think. I feel like you need to, There's also two pieces to, uh, why you get rid of it. First one, uh, if you compare accounting to it, we have a much bigger price tag, way bigger, um, because yeah, accounting, they, they need their resources to do what they need, but they generally are not buying a whole lot of five and six figure equipment to make it happen.

Um, the other piece is, as I said before, as long as it's working, it's invisible. And so you really have to think about it to say, okay, what is my day-to-day value that I'm seeing in my IT department? And if you're doing your job and everything's working, you're invisible.

There is no immediate value unless people really think about it and how many people really think about it. Well, and this may jump a little bit to the side, but to your point there, Tom, around the idea that, I mean, because I, because I think the answer may be that somehow it's thought that accounting is more business critical or, or, or less fungible, right? That we need to be in control of this because money and money, I mean, companies are essentially money pumps, right?

They're moving capital through and, and, and hopefully collecting a little bit of themselves that that seems to be fun, fundamental to every business. So is it that we don't realize how fundamental the IT aspects are? Is is that just flying under the radar somehow?

Because somehow over the last 20 years, this became a thing and maybe there's still people running around managing companies that don't quite realize that the fax machine has gone away and that the router is now a critical piece of infrastructure? No, it hasn't. And it pains me to say that, um, having worked for a government contractor, um, I, Chris I, that, that's also a really good point.

Um, I, I, I think the other aspect to the, the perception of it from a finance perspective, right? You know, you look at finance and accounting, well, what that information is considered critical to information, um, to the business. It's about how, you know, it, it goes to a lot of, Hey, this is how good or bad a company is doing.

So companies wanna keep that, you know, kind of close to the chest. So you can kind of make that argument like, well, you don't wanna outsource a man's business critical, uh, or something that's perceived as business critical. Uh, you could also make that same argument for HR company or HR functions as well.

Although we're starting to see that we're starting to see HR functions getting outsourced, um, in, in a lot of organizations for particularly, again, smaller scale companies. Uh, so it's, it's it, yeah, it's interesting. Lemme look at, lemme ask this question because I think one of the things that kind of puts us in a certain perspective on things is what in enterprise might look like.

Because for example, we work primarily with people who are highly technical. We work with people who rely on the internet to get things done. We work with companies that have a lot of headcount, but also a lot of companies that don't.

And what made me think of this just now is, you know, I, the thought experiment was fire the accountant and fire the IT staff and see which one starts screaming first. Generally with accounting, you're probably gonna start hearing the first complaints after they're week, maybe 30 days. Especially if you have AR that needs to come in it, you probably won't notice until something breaks.

But boy, when it does, it does. But that's only for certain industries. Like if, if there's an IT problem at Netflix, we'll know right away because their primary business model of delivering entertainment over the internet goes away.

But what about your local sandwich shop, right? As long as they have a way to take payment, even if they have to put the little sign out that says cash only, I mean, they can still operate. I remember last year during the whole CrowdStrike debacle, I was camping at a, uh, state park and we couldn't buy anything in the store because their register was down.

They couldn't even take cash payments, but the park was still operating. They were still able to figure out how to take money for tours and stuff like that. So, I mean, certain kinds of companies can operate without massive IT budgets, but I also think that those are companies that don't qualify in most people's eyes as enterprise.

What do you think? Oh, enterprise means a lot of different things to a lot of different people. Uh, yeah, it does.

Yeah. It's, Yeah. And I think that's, I, I, I, Tom I think that's a really good point because, you know, there are large enterprise companies out there, you know, Well, lemme think about that.

I I was about to say, you know, pull, pull the manufacturing card, right? You know, take a manufacturing company, well, would they qualify as an enterprise? You know, would you make them an enterprise?

Like, you know, because they may, you know, they're large scale operations, they manufacture widgets for whatever, you know, component, um, to go into and they have to do, you know, manufacturing at scale globally, you know, and transportation logistics, right? You know, so a lot of that stuff goes into the question of, well, does that qualify as an enterprise? You know, or does it just have to be a knowledge company?

Of, my favorite examples when I used to do this for a living is a school like a K through 12 education school. They are enterprise grade networks on small business budgets because they have a ridiculous amount of technology designed to educate students, but they don't buy at enterprise pricing, right? They don't have the budget to do that.

So while I may be dropping in, you know, at the time 10 gig internet circuits and entire wireless deployments and iPad carts, it's because they were subsidized somehow. Like nobody would walk in there and be like, yeah, you guys need this expensive, uh, fiber channel SSDs san with blah, blah, blah. They would have a small heart attack looking at the budget on that.

Whereas a company like Boeing is like, yeah, order us another couple of those $300,000 switches to light up this, uh, factory because we need to have it lit up to get plans to the people building the $20 million aircraft Subsidizing makes a huge difference. So for example, I've got customers who are government subsidized who would never be buying the equipment that they do, except for the fact that maybe they're not considered a large enterprise, but the government payment plan that they're buying through is so they can get all those discounts and it gets passed right down. But it's a question of whose definition are you looking at?

Like here, if you've got a, you know, large company, or not a large company, but you've got a company that's got like, say 225 employees doing things officially, their SMB like 2 25 employees is not where we think of as A SMB that's on the low end of what we would think of as enterprise. But if you don't have like thousands, a lot of organizations will say that's not enterprise at all. And that's, and and I, I, I've worked in both, you know, both sides.

You know, I worked for a nonprofit that was about 350 people at the time. Um, but we were one of the largest nonprofits for the particular sector that we were in. Um, you know, and, and we absolutely did run enterprise networking.

We did run enterprise services 'cause we had to, 'cause we operated call centers, um, you know, and, and certification services. So, you know, and then flip a couple years later, and I'm at a large enterprise, relatively speaking, um, you know, government, uh, government IT contracting company, and that's 10,000, 15,000 plus people. You know, that's also a large enterprise as well, you know, so it, it, yeah, that, that, I've always found that cutoff for SMB to be very, very nebulous and totally dependent on who you talk to.

But I think where you see a lot of the outsourcing occur is in that SMB market space. And on the lower enterprise side, I'll say on the lower scale enterprise side, you'll start to see some, some outsourcing happening, um, particularly for your tier one, tier two services, uh, where they can get away with it. Uh, some, some instances, some industries they can't get away with it.

Um, because of reg regulatory compliance, um, we were actually one of those, you know, dealing with government, you know, government, uh, accreditation and government, uh, security compliance, you know, there was a lot of stuff we had to keep in-house and onshore. Um, so we couldn't take advantage of some of those, some of those outsourcing options. Uh, even though if we were in a position where we could, we certainly would've, I think that for the question of outsourcing the network in particular, we can kind of sidestep the official or non-official definitions of like what enterprise is versus s and BI think, to me, anyway, it comes down to specialization, um, and, and criticality, right?

So to me, the question isn't how big you are. It's how critical is this thing, in this case, the network to your business, right? So if, if you're running a business and the network is truly a utility that just needs to work, and when it doesn't provide any differentiation whatsoever, then maybe you should outsource that.

And, and, and maybe that's why people are outsourcing to infrastructure as a service cloud operators, because running servers doesn't differentiate them in the market. Now their software may, you know, they may need those, um, servers critically. Um, but, but the software that runs on them is what actually differentiates them and not the operation of the data center infrastructure, right?

And so I think you look at the network from the same purpose perspective, which is if you've outsourced all of your compute and storage to a cloud provider, then why are you running your own campus network? Um, now is that campus network actually differentiating you in some way? Is, is is there something you're doing that's special that makes that something that you should run yourself and do in creative and in interesting ways?

If not, maybe you should not be running that. You know? And there's, there's new companies that have sprung up that actually are providing hardware and management.

Like it's kinda like a new, uh, MSP, but it's basically, you know, they're calling it network as a service, right? And they come in and load up the gear and, and, and do this. Like that seems like a great option if your network is just a utility.

Um, however, going back to what Tom was talking about around the finances and things like that, is this idea of like business criticality and, and, and then maybe my idea of differentiation, which is what happens to a large organization when they start having as many or more AI agents working than they have employees now, does the network now become a differentiator or more critical because those agents can't actually run the business without it? I dunno. Well, whether you're talking AI agents or just traditional software as a service or infrastructure as a service, the smaller end of the enterprise is leaning far more on the cloud.

It's just because it's easier to outsource services than it is to outsource people. And those organizations aren't necessarily outsourcing things to save money. They're outsourcing things so that they don't have to be concerned about it, and they can hire expertise that they don't have.

So you get someone who is a networking person who knows all the ins and outs of networking security and all of that, who can build this network as a service for them, that's very, very attractive. And what we're finding is that security really has to be built in at the bottom these days. If it's not part of the network design, you can't just bolt it on later.

It doesn't work well that way. And that expertise isn't there. Even in the smaller enterprises, you've got IT teams who are really good at managing their Windows servers, but do they really understand handling things down at the low level and as they move things up to the cloud?

Yeah, the network simplifies in some ways, but it becomes much more complicated because now it's your critical line to absolutely everything. You can't run word without having your internet connection working properly. Um, and it becomes absolutely critical that everything work the way it should.

Do you need to have the big iron switches in there with all the enterprise stuff? No, but you better have redundant paths. You better have secure access.

You better have it so that not just anybody can get onto the network and get at your stuff. And smaller enterprises don't have the expertise for that. Well, Chris brings up a really interesting point here when we talk about outsourcing things to the cloud, because in effect, you're doing a double outsource there.

You're obviously sending most of your enterprise data center assets into the cloud where they can be managed. They have infrastructure and you don't have to worry about buying new switches. And the software that everybody uses is freely available from anywhere, whether it's the office, your house, or a, a coffee shop, right?

So then the network is no longer the transport between your edge and your data center and then becomes the way to access things in the cloud. So in a way, you've not only outsourced your data center, but you've also outsourced your edge connectivity in effort in basically in a self-service thing, right? Because I'm not gonna manage my employees enterprise networks at home 'cause they don't have one.

They have some SMB gear that they bought at Best Buy or, or whatever big box store. And as long as they can get on the internet with their work laptop that has a sassy client on it, then I don't care and I don't wanna pay for that. And, and that's one of those things that as more and more companies have said they're wanting a distributed workforce, obviously those are places that don't rely on things like manufacturing or, or teaching or what have you.

They can get away with that and say, I'm not gonna do any of it at all. And that's why other companies like you mentioned, uh, network as a service companies like Nile Meter and Ramen have stepped in to those smaller organizations and saying, we're gonna outsource the parts you don't like in your office for the people that are still there if you're requiring them to be there. So could this kind of double back on the companies by saying, well, if you can just offload the data center part, you can actually offload all of it because if everybody's working from home, as long as the cloud's up, we don't care.

Yes, yes. But it's a, it's a psyche chain. Everybody's used to people working remotely with VPN clients and not having their enterprise network at home.

But when they're in the office, they still expect to just log in at their desk and go, the idea of treating the office network as a Starbucks with fewer baristas is kind of a new thing. Now I've got customers doing it and it's good because you can just basically say, I don't need to worry about the, well, you do have to worry about some security, but not the bulk of enterprise security on the network when everybody is offloading their security to their SAS e clients. But it's a rethink And and it's not only a rethink, but it's also, it's a cultural shift too, um, you know, within those organizations.

And it, it, it's a huge cultural shift. Um, uh, that's, and and yeah, I've had some experience in, in sitting on both sides of that. Um, and it leads people to be very uncomfortable, you know, especially if you're, you're in that legacy position of like, well, I've run the network all the time, so what do I do now?

And Chris, I think this goes to something that you, you brought up before, which is getting people out a out of the day-to-day minutia of running a network and maybe refocusing them and focusing them on my, on areas that matter and actually, you know, being able to ensure that the architecture is right for the business, that the AI agents that are getting developed have the right information base to work off of, right. You know, that. So I think there's, there's, there's some retooling options there, uh, you know, for a lot of people.

And I think there's definitely gonna be fallout where you'll see, you know, some people will just get worked out of, of, uh, you know, out of a role. Um, but that's just kind of, it kind of goes to that, that philosophy of adapt or die. It goes up to bigger thinking.

It's, uh, you know, too, too many people think that day-to-day management tickets and break fix are what we do. No, there, there are a thing we do, yes. But if we don't have those things, we have the option to think bigger.

We have the option of looking at the design of our networks. We have the option of saying, okay, how can we make this better for the company? And hey, maybe if we're not just fixing things all the time, we can demonstrate our value in the vision we're providing to our employers.

It's, it's, it's being able to shift from a reactive mode to a proactive mode. And, and that's, and that's challenging. It's incredibly challenging.

And, and particularly the larger the organization is. Yeah, there's some interesting, uh, sociological work behind this. I forget the guy's name, but kind of looking at cognitive load and this idea that there's three types of cognitive load, right?

There's intrinsic cognitive load, which is, uh, for example, if you're gonna write a Python program, you need to know Python, uh, and there's some cognitive load involved in just in just knowing that, right? And then there's extraneous cognitive load, which is all the other stuff that we attach to this, right? So like a lot of times it's, uh, I have to remember how to get on my VPN and then where the file is with the passwords or like what password manager I'm using and I need to know like, you know, what libraries we're using.

There's a, there's a bunch of like stuff, right? That that's, that's kind of extraneous. You need to know what to get the job done, but it's not actually inherent to the job.

And then there's a third class of cognitive load, which is germane, which is kind of the bigger picture stuff, which is that like, okay, if I'm, if I make this change, what happens over here and like how does this impact the business? How does this impact my customers? And you kinda look at that, right?

And I mean, this is really, I've been looking at this a lot in, in regards to automation, because what we can do is we can automate the extraneous stuff. And I think that's what you guys are talking about as well, right? Is' a lot of time we can, we can get rid of some of this, right?

Get rid of some of those trouble tickets, get rid of some of this break fix, you know, get rid of some of the, the friction that's involved in doing the job. And now all of a sudden you've freed people up into that germane realm where they're actually thinking about how this impacts the business and they can actually get outside of, you know, just the CLI hacking and, and really look at it. And I think, you know, maybe on a separate point, but maybe kind of related ed, I mean, what you said about, you know, there's a cultural change.

I think that's really, really important. And I think regardless of what you're gonna do next with your, you know, big company network, we call it enterprise or, or, or highend, SMV or whatever it is, you know, if you're gonna outsource, if you're gonna bring in a NAS provider or an MSP or whatever to take over some of this stuff, that is a cultural change on your team. Um, and you need to build, you need to rebuild the, uh, to be able to handle that because now you're managing outsource tools or outsource staff instead of, you know, internal staff.

And that's, that's, that's, that's a big difference. Or if you do decide, hey, for whatever reason our network is a differentiator and we're gonna actually apply modern network management practices, we're gonna build some automation, we're gonna do some intelligence there, that's a cultural change as well. And you've gotta rebuild the organization.

So I think personally, I think no matter what, almost every enterprise on the planet needs to be thinking about how their organization needs to evolve to run their network in the future. And it's gonna be, went down one of these paths. It's either modernize the operations or get rid of the operations, I think, And there, and there's always room to do that.

One of the things that I've found in my business is that there's always room to outsource things, but it doesn't have to be a hundred percent. So one of the things that I find is that I've got lots of companies who are really good with the day-to-day operations of their, of their network, but they need an escalation point. They need someone to come in and say, okay, what are the best practices here?

What are we doing wrong? Help us get into this thinking. And so it's kind of partially consulting, but it's also partially being the guy that they call when everything's gone to hell and they don't know what to do.

Um, both services are equally valuable. One more in the moment, but outsourcing nothing isn't gonna be the way to go because you don't have people whose full-time job it is to keep track of this sort of thing and the best practices and the, the right things to do, and the layers of security that are becoming increasingly complex. You need to outsource at least the thinking.

To a degree, It's a matter of specialization, right? Is this the focus of your business or not? And when it's not, you don't have those people.

Yeah, I, I, I definitely would echo that as well. I think there's, and, and Jody, you brought up a point uh, that you've mentioned several times now, which I, I very, very much agree with, which is the co so the security complexity that is getting baked into everything these days. Um, you know, and not only that, but the security landscape changes so dynamically, I would say arguably way more than anything else in, in it that security landscape is, is ever evolving on a daily basis.

And what you're seeing now with a lot of organizations and, and I come from a federal contracting background, so this is where, you know, my view is slightly, slightly skewed, uh, but we have a ton in the federal wor in the federal space, a ton of security, compliance, uh, hurdles that we have to jump through every single day. Um, and they are a very complex and very nebulous in a lot of ways. Um, and one of the things that I have seen is that a lot of organizations, especially at scale, you, you get a, you get a, the additional problem from the security perspective where you have a lot of security policy people pushing certain things, not understanding the technology stack and how that, how the implementation of those security components tie into the technology stack.

Um, because they just wanna say, well do it and get it done. Okay? It doesn't work that way.

Um, and, and, and as you get in with large organizations, and I think that's where you see some of the consulting companies particularly, you know, coming in and offering that capability of saying, Hey, you gotta go through, you know, CMMC for federal or PCI for, you know, commercial, you know, merchants. Um, there's are two widely different, uh, animals, but it, you know, the point being is that that's, that's an area that people do outsource today. Um, you know, outsource for that expertise.

Um, and I, I think you could definitely see, you know, see that going on the networking stack as well. Alright. As you can see from this conversation, there's a lot of elements that have to go into what your decision will ultimately be about whether or not you need to outsource your system or if you're just doing it 'cause it's what all the cool kids are doing.

Uh, we didn't even get into like the huge amount of regulatory issues that might even come up. But you have to do your homework, you have to investigate, you have to make sure that this makes the most sense for you. And remember that someone's definition of what enterprise actually is may be completely different than what your situation might currently be.

But you have to take all those factors into account because if you make the wrong decision, you might not crater the business today, but you may run into some difficulties down the road. Thank you all for joining us today on the Tech Field, a podcast. Before we go, I want you to let everybody know where they can connect with you and continue this conversation.

com. io. Thank you all very much for listening to this episode of the Tech Field Day podcast.

If you enjoyed this discussion, please make sure that you subscribe and turn on notifications on our YouTube channel, or download this podcast in your favorite podcast application choice so you don't miss any of our great episodes. We'd also love it if you'd leave a rating or review and possibly even a comment letting us know what you thought was the best part of this podcast. We are brought to you by Tech Field Day, which is a home for IT experts from across the enterprise.

It is a part of the Futurum group. For more upcoming events and great episodes, make sure you head over to tech field day com slash podcast or check us out on Tech tv, including the new tech TV app. Thank you very much for tuning in.

We appreciate your listenership and we will see you next week.