Techstrong TV June 13, 2025
Watch our live stream Monday through Friday, featuring exclusive news, announcements and conversations with IT leaders and experts on topics ranging from digital transformation to #DevOps, #Cybersecurity, #CloudNative, #Containers and deep-dives into specific technologies and best practices. http://techstrong.tv/
Transcript
gov? It's a little murky right now, but isn't everything that this administration does, you're watching Textron Gang. Hey everyone.
Alan Shimmel. Welcome back to Textron Gang, and happy Friday. We've got a great way to send you off on your weekend.
We got a cyber heavy show today, and we've got some cyber heavyweights to, to discuss stuff with us. Let me introduce you to our gang before we jump into anything. First of all, he is founder, former, oh, he's cso, just all around security guy.
I happen to call him Fred for a long time. My friend Fred, Fred Wilmar. Fred, how are you man?
It's good to see you. Doing great, brother. Thanks for having me.
Hey, Fred, I, I, I apologize, I don't remember your company's name off top of my head. Can you remind us? You bet.
Tech team, the tech team's famous for, uh, automating, uh, what we think about static code for detection generation and data generation to test and validate and really about bringing autonomous, continuous validation and detection generation to the province base of the ecosystem. So take your weeks and months and put it into the, to the detecting platform and turn it into minutes and hours. Very cool.
Very cool. Thanks Fred. Hey, speaking of security folks, they don't get any bigger than my friend Ira.
Ira joins us from Foreign Shores today. Ira, wink Winkler. How are you, man?
Just wonderful. How are you today? I'm good, IRA.
It's great to have you on here and looking forward to your always insightful and passionate comments regarding the world. Oh, It's good to be part of the formal gang gang today. Yeah.
You, you're a real gang member. Don't tell them that when you're coming back into the country, they're live to send you to El Salvador or somewhere, or South Sudan. Uh, speaking of, let's go over from South Sudan though to the Silicon Valley.
Our Silicon Valley man on the street. Well, he's, he's Silicon Valley royalty, our own John Schwartz. Hey, John.
How are you? I'm good. Good to be here.
It's good to have you on. No problem. And then finally, I, I assume, are you still in a hotel room in New York City?
Have they let you go back up to the suburbs? I am leaving this hotel room right after this call. All righty.
He's our chief content officer, Mike Ard. Hey, Mike, how are you? I'm well.
I'm looking at all these ice protestors outside in Manhattan, so Good. Well, they're peaceful at least, right. There you go.
And, and still get arrested. So who knows? We could discuss that.
I, I'm actually gonna talk about that on a shimmy says episode, but let's, let's, let's not go there. It's early. gov.
Uh, it's coming as you know, plans are a little murky. When does this administration ever give you anything that's crystal clear, but Ira, why don't, uh, why don't you kick us off here. What do you, what, what do you think this is about?
So, what it theoretically is about is having company or government agencies adopt AI models. It looks like, according to the article, if I read it correctly, they wanna monitor AI use, which frankly sounds like such a noble cause and so brilliant and all that sort of stuff. And just sounds so obvious.
And it's specially obvious is, I mean, specious is the word that comes, I guess that might be the word of the day. Um, 'cause when you look at it, what really needs to happen with ai, because they say they're gonna be a repository according to the article for AI models, which is theoretically nice, but in order for a large organization to actually make use of ai, they need to go ahead and be able to start to have the data in a format that they can pull in. Because in order to implement ai, you need data and you need all the possible data you can get, because all the possible data you can get is what makes the better decisions that come out of the ai.
Then you need to have the proper models, and the models need to be appropriate. The models need to be tested, the models need to be validated and so on. And then you need to make sure that you're actually making the best use of the output of the system.
And what it says is they're gonna monitor how employees are doing it. I mean, gee, it's nice that they have an LLM, but in theory you need to have so much more than a small focus group of people who are gonna monitor employees and look at which functions. And yes, we do need somebody to go in with a consultative attitude to go to different government agencies and say, there are AI models that would improve this process, this process, this process, this process, and so on.
But without, for example, what people are missing is a chief data officer, as an example, that's gonna standardize data format so that all these AI models can pull it in and make use of the data. 'cause otherwise, it's kind of like human decision making. These models only make decisions based upon the data that they have, not all the data that's theoretically known and available.
And that's a critical factor. Then of course, we have to make sure that, 'cause when you throw models together too quickly, you're not doing the validation, you're not doing the security, you're not making sure the right data's there, whether the data's clean, whether the data's murky. Alan likes the word murky, so I'll use that one.
Um, and I could go off for a while, but fundamentally, in concept it sounds brilliant. In reality, it's much more complicated than the article seems to have. They, they realize apparently, because there's so much more behind it.
I realize high level article, but I don't see talk about data. I don't see talk about validation. 'cause if you Yeah, I, I, so I use murky in the headline for a reason, and I, I sorry to interject, but, uh, it's, this is a classic Trump plan.
It's, it's vague, sloppy, incoherence incomplete. There's, I think there's a, an ultimate goal here. And I think what they wanna do ultimately is replace federal workers with ai.
I think that's actually what they wanna do. And, and what, what's telling to me is this was posted for a very short period of time, then it was taken down when it was discovered. gov thing, I I I, I think the whole thing is basically extension what Doge has been doing or try wait, tried to do.
Well, I would actually ag i, I would actually just to go ahead and agree that that's part of the plan. That's part of the plan. When anyone introduces ai, whether it's, you know, Tesla, IBM or whoever else we, you know, we can bring up.
But, But, but here, so here's the the thing. So the, so TTS, which is the Technology transformation services group within GSA, the head of it is a former software integration engineering manager at Tesla. And he's a, a buddy of Musk, and he wants GSA to operate like a software startup with AI first strategy to automate much of the work done by federal employees.
To me, it's just like, it's so patently obvious what they wanna do. I don't know what the timeline is because as we talked, Mike and I talked out about this briefly yesterday. These guys changed their minds so many times they could delay this.
It's supposed to be announced July 4th, you know, symbolically, it, it, it, by the time they come out with whatever they have, this is gonna be like a tariff policy. It's gonna be all over the map. It's gonna be a amended, it's gonna be discarded, it's going to be revamped.
Once they get the lobbying from the tech industry, it's, it's just like a classic Trump plan. No, we're in violent agreement because I, I described it from the tech perspective. You described it from the big picture perspective because we both agree either way, just from me, from a fundamental tech perspective that are you, can I curse Alan?
You know, but are you effing kidding me? Is the first thing that comes when you read this at a high level. And then from your perspective, it's like reading through the lines.
What are they trying to do do? And if I was an employee at GSA and I'm reading through the lines thinking they're trying to get rid of me, I would be like, good luck with that, with that plan. 'cause they don't even implement the plan.
Well, You, you, you do it a favor. He's trying to get rid of their employees. I mean, they're trying to figure out a way to get rid of with AI and become more productive.
And these guys just wanna do it. And, and guess who sufferers in the end are the people who, who are served by the government, which is all of us. Exactly.
That's, yeah. But guys calling it a plan, does it, does it more justice than it's worth? Okay?
It's an aspiration. That's what you call these things. It's an aspiration.
And the road to hell is lined with the best of aspirations. Okay? Let, let's call this what it is and what's gonna happen if Elon kisses his ass, can the guy at GSA stay there and start implementing this?
Or if Elon's on the out. So we gonna purge all the, all of the of, of Elon's buddies in some kind of Stalinist knee jerk reaction. We're gonna have show trials right after we arrest Gavin Newsom.
Well, I hate even wasting time talking about what this government wants to do with these plans. You know, I, I sent Mike something last night, the $500 billion starlink plan. Nothing, nothing has been done.
Soft. Uh, not SoftBank. Yeah, SoftBank hasn't even started, RA hasn't even started raising the money for that.
Oracle hasn't done anything. Uh, the CEO said it yesterday on their earnings call. This is the same BS we hear over and over.
You could b******t some of the people some of the time. Donald Trump has b*********d this country for too many years, and we shouldn't even give this the oxygen that we're giving it today. I think we should point, but I think we should point out what they're trying to do, though.
I mean, this is like, when we're talking about, we're all Trying to do, talking about John, every, every CEO in America is trying to cut heads about Openly about what they wanna try to do. You, and we just can't ignore it because they have some very devious plans. I think, in my opinion They do.
But it's no more devious than private industry. Let's be clear. Why do all these CEOs rub their hands and start putting all this money in ai?
They wanna cut heads. But Alan, here's what we're, here's what I hope we're here for. First off, yes, there's the big political issue, but second, and again, I keep coming down to the fact that we need somebody to not just say, Hey, this is b******t.
This is a political attempt. This is just co covering people up and just making it seem like some rosy thing and everything like that. Because I think fundamentally, I'm just trying to say, I, I completely agree with you, Alan, don't get me wrong.
But to me, the fundamental issue is this is, so people need to understand how poorly implemented it is, even as a plan. Because too many people are taken in by a grand claim. Like, who doesn't want to cut government waste?
You know, who doesn't want to cut trillions of dollars? Well, it wasn't trillions, it was a billion. But we need to explain why It's also bad.
That's The thing. I know the no saying, fool me once, shame on me. Fool me twice.
Shame on you. We've been the American public, right? The, the American public's been fooled a hundred times over with this nonsense and this administration, And here's why we need to make, and here's why I'm just trying to stick to the technology because too many people hear these claims and then they're like the claims without data.
And even most people don't care about data. I admit that. But the claims without data make it seem like, oh, they're just criticizing everything.
And so what I'm trying to say, why is this fundamentally b******t? It's fundamentally b******t. 'cause there's no data z it's fundamentally b******t because they are implementing a piece of a plan.
If they have a plan at all, they're, they're, they're identifying a piece of a problem that doesn't have the breadth that it needs to, to actually be successful and is gonna ruin things if they go ahead and try to pursue it because it's just gonna be such a half-assed implementation because they don't have anything else. And yes, everything you said could be the same. Half the country wouldn't care about what you're, well, 30% of the country wouldn't care about what you're saying.
Another 30% just are like, I just want to live my life and I don't care. And then another 30% are pulling their hair out saying, I don't, you know. But really what the mid 30% at least needs to hear is this is a fundamentally flawed plan.
Not from a political perspective, but from a fundamental technology cannot be implemented perspective the way it is pulling together. And you can't pull this together quickly. I'll leave that there.
I I, I would agree that the plan is flawed, but this is gonna happen and it's gonna happen not just at the federal level. It's gonna happen at this individual state levels. It's not gonna matter whether it's a blue or a red state because tech marches on.
I don't think that this administration probably has the wherewithal to execute this in any kind of timely fashion. So it'll probably take them to the end of the next term to kind of get to that, maybe even remotely close. But, uh, you know, as to Alan's point, this is the way of the world and all this stuff is gonna happen.
And there is massive amounts of data and everybody has a horror story about some engagement with some government agency that could be better. That's the positive side of it. On the negative side, Alan, um, there's an opportunity for a lot of abuse here, right?
Because I can also create AI to do all kinds of nefarious activities that maybe I don't want the NSA and the CIA doing on US citizens. So, and I don't see anybody talking about how that's gonna be managed or what oversight might be in this thing. So I think there's a lot to go wrong here too.
That's, that's the, that's the thing that I worry about, right? So if the Supreme Court is doge access to social security systems are a fairly embattled fraudulent platform. And we also know that a number of these models are already in use in private, uh, private organizations.
And they struggle with the ability to manage the guardrails of what types of intellectual property and or sensitive data can be put in or taken out. And there's a hiatus on the accountability for, uh, AI through the state legislative, uh, bodies. So now you have an unfettered access for n number of and x values of all of the types of models and platforms and engines to be provided by folks who are less than caretaker, uh, stewards of the data and probably are not the level of, of competency of an AI startup organization from a technical perspective.
All coal line together is a perfect storm. That, that I'm glad you mentioned, Fred. The, uh, Supreme Court decision that's really important.
And you know, the thing is, the difference between this scheme or half-ass plan or whatever initiative, whatever you wanna call it, is these guys are gonna struggle with it, but it's happening with Nvidia, Salesforce, you name it. These companies are all gonna follow through and they're gonna be much more efficient in how they implement. Oh, absolutely.
Look, this, this ai gov thing seems like something wily e coyote orders from the Acme catalog. Okay? But, but there will be, to IRA's point, there is a, a valid reason to wanna do something like this.
And there is ways of doing it better. And there will be companies and local governments and other entities that do do it better. It's just, you know, did you ever go when you were in school, you know, they used to give you a group, you had to break into groups and you had to do a report on stuff, and there was always two or three kids in your group who were the schlep rocks and didn't do the work.
And then two days before the report was due, you had to do everything. 'cause this moron was too busy getting stoned or whatever they were doing in high school or college. Well that's, that's the life we leave here in America.
You, you sound a little bitter about that one. Hey, I, I didn't, I was, I, I'd been the guy who had to do the report the last day. 'cause everyone else, it wasn't that I wasn't stoned, but you know, I had to go do it.
So, and but, but the, the, but I always thought those people would never be in charge of the government. Who knew Beavers and Butthead is president and vice president here. Anyway, let's take a break.
I had enough of this one. We're gonna come back. Let's talk about Shift Wright a little bit.
You're watching Text on Gang. Hey folks, we're gonna revisit this whole debate about ship left and ship right in the land of application security. And, uh, for a long time now, we've been pushing the notion that we should push more responsibility for security apps as far left to the develops as we can.
Uh, in this week though, contrast security, who many don't probably know, came out with a solution that focuses more on the shift right side of the equation. They're putting the controls in at the runtime level. And what makes this all really interesting is the CTO for contrast security is a fellow named, uh, Jeff Williams.
And he was one of the original developers of the original OASP initiative. And he's basically saying this whole ship left thing isn't working. Brad, we've been having this conversation now for a while, and I wonder if AI and graph technologies might change which way we lean on terms of left versus right.
It's a good question. I think, and these guys have been around for a while, and obviously, uh, just been around for a while. I think the, how do we introduce new technology to old problems is a common question.
And whether or not, you know, sort of graph and, and AI bring things together in a way that allow you to work on it, um, you know, there's a very real value in understanding vulnerabilities in real time scoring vulnerabilities in real time understanding and instrumenting things that happen. You know, in runtime. My questions are sounds great.
Last time I let a kernel engineer operate in kernel space in real time was the last time that guy was allowed to touch production. So the question I have is, this sounds really good, but everything that you touch in those spaces is highly risky things. And so when we think about AI today, whether you've got an MCP, uh, server or not, uh, the question for me is please tell me all the information.
Please make it highly available to me to please give it to me in, uh, a way that allows me to understand the implications in the context. But please don't do anything about it, especially in, in this particular space. Uh, there's a, there's a bunch of companies doing stuff like this right now.
A lot of startups really empowered, uh, emblazed and by the types of software that people are starting to utilize, not in large part due to ai, the questions are going to be whether or not this helps us, you know, create more secure code over time and whether or not instrumenting that in real time actually solves problems for incident response and vulnerability management when there is actually a current ongoing investigation. Fair. So, so Mike, Jeff Williams is a friend of mine.
Sounds like a song. Um, Jeff Williams is a friend of mine. I actually sat down last with Jeff at the RSA conference.
I it's probably on text on tv. I had a good talk with Jeff. I'm not sure you're characterizing what Jeff is saying correctly.
I I think what contrast is about is not necessarily shift left or shift, right? It's shift everywhere. They're not saying that you should give up on the whole shift left thing, right?
Because at the very heart of AppSec is, is sort of a shift left sort of motion where we're gonna look at application security pre-deployment, right? That was kind of the, always the, the, a big focus of AppSec. I think, frankly, what happened, and Jeff is a friend, and I don't mean to put words in his mouth or or to disparage contrast.
There are great company, but there's a lot of companies focusing on that left side of the equation in the AppSec space. And I think contrast is trying to stand out from the crowd a little bit and say, and say, instead of just purely being focused on shift left, we gotta look a little bit to the right. We gotta look a little to the up, a little to the down.
We gotta shift everywhere. And so what they're, what they're trying to do is use buzzword bingo technologies like AI and graph tech, right? To, to take the focus wider, make that lens wider than just shift left.
And it's an interesting play. 'cause contrast in particular here is taking their traditional AppSec scanning tools And, and shifting right with them. So they're doing not the old vulnerability scanning that maybe I was doing, it's still secure 20 years ago, Fred would know, or or Qualys or Foun Foundstone, that's a name from the past.
Ei the, the, the streets are littered with littered with these names. Instead of doing that sort of traditional vulnerability scanning, he conscience is taking their AppSec dynamic static scanning code scanners and, and and focusing it down on, on already deployed, uh, applications. And then feedback looping that into the developer, into the left, left side of the equation to, to iterate and reiterate and make better applications.
So it really is a shift everywhere. Yeah. Alan, could I, um, um, Good Ira?
Yeah. So let me make a point because fundamentally in cyber, so dating myself, I wrote a report at the Pentagon on defensive information warfare. And this was in roughly 1994 ish or so.
And we had a smart guy there, 1994. And it was called defensive information warfare. There was no, by calling it cyber warfare.
'cause at the time you would think that means robots are fighting. And we, and then some smart guy basically said, okay, here's what your reports format's gonna look like. It's gonna be protection, detection, reaction 'cause protection, obviously we need it.
Protection's gonna fail. We're gonna need detection, and we need reaction all as part of a consolidated plan. Now that is brilliant.
We have the miss model in many ways, which, um, has res uh, for, I forgot all the five layers, but you know, again, protection, detection reaction is built in the application security space has focused on primarily writing good application software, SBOs, things like that. You know, writing, you know, evaluating software as it's going. You know, the fact we have a vendor, because I think this is a gimmick in some ways, but at least it's an acknowledgement as to where we need people to look.
We need detection and response built into the application security market that's not really well addressed. And you know, if you look at, you know, Sunil, you, for those of you who know him with his, um, cyber defense matrix where he breaks down technologies and looks at, you know, protection de uh, I, sorry, can't again, it's a morning in Costa Rica, you know, leave it at that. But you know, you have the five layers of cybersecurity and it includes like mapping out which vendors are where.
And it's good to see a few more vendors now moving into AppSec detection and reaction. And I'll just leave it there because is it like a radical play? No.
Is it a radical play for the AppSec market? Possibly. But we really need all vendors to be looking at this to provide comprehensive coverage.
'cause all their AppSec will fail. Let's write better software and maybe learn from it. And if we have a left, I hate the term shift left to compare to shift, right?
But either way, we need the detection to feed back into the reaction, which is what's gonna make good Cybersecurity. Here are the criticisms of the whole shift left conversation. And Jeff would be the first one to say, um, first of all, that top 10 list from OAS hasn't changed in almost 10 years.
It's still the same damn vulnerabilities over and over again. So that suggests that, you know, developers aren't getting it, don't have the time for it. Secondarily, they're writing code, but you know, when they write the code and then by the time they get their review of the code, they moved on to their next project.
And a lot of times they lose the context and they don't spend a whole lot of time on vulnerability fixing in the first place. And then the third element is, in the age of ai, we're gonna have all these tools that are generating more code. And some of that is better and some of that is worse, but the people reviewing the code don't have a lot of cybersecurity expertise anyway.
So there's just more of that code that's gonna have issues gonna find its way into the build, which means we need more help from the right side of the equation. So I think Ship Left is a lovely idea and you know, the best vulnerability is the one that never existed in the first place, but I just don't think it's ever gonna be a silver bullet or even a bronze bullet or anything else. It's just, you know, it's a lovely idea, but it doesn't get it, it's not executable.
There's a, there's a bunch of cool elements that get tied together, uh, when you do it, when you do this, right? I, the distinction I was trying to make here is responding to the things that you find in real time is probably not the target focus here. If you thought about it and you looked at what the software development lifecycle looks like, you look at what continuous integration and continuous deployment does, right?
Shimmy. And you look at this and you say there's a very interesting, uh, convergence of things like looking at what you get from your IAS tools. Like, you know, like, uh, like these guys, uh, that are moving in the spaces where you say, okay, there's an SBO here.
Okay, I wanna make sure that what I thought was deployed right is what's actually running. There's a lot of value in that. And being able to bubble up that type of information, a lot of people are working on that particular problem.
And there's insights there. Like you said, Mike's great point is that folks are worried about they're not incented, right? Uh, put your CISO hat on for a second, right?
Ira, uh, shimmy, right? People are not incented to reduce the vulnerability count. That's not important, right?
Shipping software's important. Doing it in a timely manner, making sure the trains run on time. Those are all important things.
That's what drives the business. And our job is business as usual. So when we think about the instrumentation here, those are at odds.
But the benefit of being able to surface what is, you know, can be construed as a DevSecOps problem into operational hands is great. The challenge is, it doesn't necessarily mean that remediation of that problem is a good idea, right there. The implications can be very broad, right?
And when you think about the types of testing required to mitigate certain types of vulnerabilities, some of those are, you know, planet killers and some of those are very easy to fix. And the challenge is understanding that. So if we're providing the utilization of AI tools that help give the context of all of that, that's super valuable.
That's really important. How we triage that and who takes the actions on that, I think really makes a difference on its ability to be impactful for the business. But it's that it's a cool set of problems and there's a lot of instrumentation that can be brought together here that, that part's Yeah, I, I would, you know, other things that I find exciting, and again, I I've spoken to Jeff about this.
Two, two things. Number one is the auto remediation of, of, of, of, or of vulnerabilities in, in production, which is, I'll tell you the truth, we tried to do this. It's still secure 15, 20 years ago.
And, and the, the, the, the market slapped us, slapped us down pretty hard. People were not into auto remediating vulnerabilities without first testing them, right? You know, classic Microsoft had patch Tuesday, but the patches wouldn't come until 90 days after, you know, many large organizations didn't implement them.
They had to test them first. And so it'll be interesting to see the auto remediation. We, we've come a long way in 20 years though.
And that's the other thing that gets me excited here. Part of what Contrast is doing is using graph and, and AI is, is using a, a digital twin of the app. So in essence, what they're doing is they're taking a, an image of your app, running it in a sandbox, so to speak, looking for the vulnerabilities, applying the fixes, and making sure nothing breaks.
Now, it all depends how good that sandbox is, right? How close does that mimic the real world? It's truly a digital twin kind of thing.
Um, but if it is, and you could do that. Hey man, that's, that's exciting, that's exciting. I also think not all vulnerabilities are the same.
And some, you might be able to auto remediate and others are more complex. And I think we should, you know, start to distinguish between them. 'cause at least we can fix some of the low hanging fruit automatically.
Maybe. Hopefully. I thought that's why we had the CVSS scores and everything.
Hey, so, uh, should, who manages CV now? Right? Right.
Well, well it's still, it's still going to be Mitre. I think they did sign the contract, but I, I think there's a movement afoot to, to kind really privatize it. Either that or we're gonna, we're gonna lean on the Europeans one or the other.
Well, I mean it, sorry, I I I'm just like hypothesizing 'cause I just went, I was, had a great response then you went to the whole Mitre thing, which is a nightmare. But anyway, but I mean, but fundamentally, I still think cybersecurity. Anybody who is relying upon perfect cybersecurity and saying somebody could write perfect code is a fool, a liar, or a combination of both.
You know, we have to go ahead. I mean, I funda Yeah, I mean, I fundamentally just say, look, I acknowledge no matter what we do, something is gonna fail. And you mentioned, like, for example, the top 10 hasn't really changed over the years.
And fundamentally I don't expect it to. And the reason is, I break down things into the fundamentals. There's so many fundamental ways to write code and write secure code.
And if there are just so many fundamental ways to write secure code, there are so many fun. Those are essentially the same fundamental ways that you write in secure code and, and implement insecure systems. So we're not gonna have changes over time, in my opinion, that are that radical.
You know? 'cause everybody's expecting a radical change from something. We have evolutionary problems in cybersecurity.
And these evolutionary problems are fairly static from, you know, moment to moment. Whether it's, again, things will fail. There is no industry on this earth which protects everything perfectly.
And we need to acknowledge that at least. What I like about this is somebody's finally saying, because when somebody said shift left, the problem is when I was doing research a while back, I found a confidential document on the internet from Symantec that said 80% of of spending in cybersecurity was based on shift left all protection. Only 20% was based on detection and reaction.
That's 20% of budgets really underspending in my opinion, because things will fail. And if you're not there looking at how to make it resilient, you're going to have a failed cybersecurity program, which is a lot of what we see. So, you know, saying, oh, we're ship all these people saying we're shifting left.
Everybody was doing that already. It's kind of refreshing to hear somebody say shift, right? Even though I fundamentally hate those terms.
So, you know, I want to hear them say, look, we're doing detection and reaction 'cause shift left and shift, right? That could just be a, you know, teaching somebody to drive a car. I don't like that.
I wanna hear, hear people say detection reaction. Exactly. So anyway, I'll leave it there on my rant.
All Right. Hey, let's take a break 'cause we're running a little late. We're gonna come back, we're gonna move off of cyber a little bit off of cyber.
Uh, Mike was, as he mentioned, was in New York City all day, all week at this Data dog conference. And we will get an update. You're watching Textron game.
Join Cruise Con Virtual on June 17th in 2025 for breakthrough strategies to address advanced threat intelligence, proactive incident response, exclusive bonus material and regulatory adaptation. Hear from our keynote speaker, Admiral Michael S. Rogers, former director of the National Security Agencies, and an outstanding lineup of industry experts as they navigate emerging threats, the core principles of crisis management and the evolution of CISO Leadership.
Register now for free. Hey, everybody, we're back. And as Alan mentioned, yes, I spent two and a half days with the Datadog dash conference.
They took over the north hall of the Javit Center here in New York City. So there's like three floors, and maybe I, I couldn't count 'em all, but I wanna say there were at least, you know, three to 4,000 of my closest DevOps friends walking around for two days. So conversations were awesome.
But Datadog is also rapidly evolving into something more than an observability and monitoring company like every other company on the planet. They rolled out a bunch of agents and they already had agents from last year. So now they're previewing more agents.
But interestingly enough, they're also talking about tools to fix code, going back to our last, uh, conversation, which we'll look at something and say, here's our recommendation for fixing that. They may not automatically apply that yet, but they're also looking at, uh, MCP servers, which allows them to integrate their observability platforms with other agents that execute things. So you can think about the world this way, maybe Datadog becomes the center of the observability motion, but now they can actually go fix things by talking to other AI agents that say, Hey, we observed this.
You should fix that. And maybe these agents will do that without any intervention. Fred.
I don't know how you feel about that, but at least somebody programmed that other agent to go do something when you put it all together. What's interesting to me is one, Datadog is becoming more than what it used to be, but now I start thinking about all these AI agents and these integrations, and the argument against a merger and an acquisition was, it was gonna be too hard to integrate something. Well, now I can see a world where everything can be integrated through an AI agent.
So maybe we'll see this massive wave of mergers and acquisitions and companies that were in one segment will be in multiple segments, and maybe there'll be a lot of consolidation going on. Alan, I know you follow Datadog, but what's your take? So, look, I'm, you know, another company releases AI agents.
Shocking. But, but that being said, specific to Datadog, let, let's, let's call a spade a spade. If these guys didn't jump on the AI bandwagon and do something drastic, they were toast because, you know, just pure observability and, and Datadog is, you know, you know, they're one of the pioneers of this whole observability market that grew out of the application performance monitoring, market management, you know, a PM market AI was a lethal threat to their existence because using ai, you could probably conjure up a lot of what they were charging people a lot of money for relatively easy, uh, or easier.
And so they needed to pick up that AI baton and move the mark up. And they have, and it sounds, it sounds, from what you're saying, Mike, like they have, I I guess ultimately the market will, will tell us. But you know, I, it's gonna be an interesting, when, when we look at disruptive disruption by AI in, in certain verticals of technology security, we spoke about, um, observability is really one that's ripe for huge disruption.
And, and it's not just Datadog and I'm, I'm naming names, you know, uh, uh, PagerDuty Datadog. Look at all the big observability companies that went public in that last round of IPOs right before the market kind of went the other way. A lot of those observability companies, if they don't embrace and extend with ai, are are gonna have a hard time surviving.
And you will see m and a, you will see, you know, disruption. So Fred, I want to come back to what we were talking about last segment and marry it up to this segment. 'cause sometimes I feel like we are all collectively talking out of both sides of our mouth.
So on the one hand, the IT ops people and the security people will say, I'm sick of people who show me tools, but don't gimme a way to fix it. And then I'm dependent upon somebody else to go fix that thing. And then on the other end of it, we're also saying, oh my God, don't touch anything because you might break it and therefore, you know, we're gonna have a problem.
And we, but we don't have the time to go actually fix the thing that you just told us needs to go fixing. So how do we kind of get to something that feels like, you know, operationally middle? That's a good question.
I think, uh, and this also touches a little bit on what IRA was talking about really, but part of the reason why the OPI haven't changed in, you know, forever and a day is because hygiene's still a problem. So when we talk about things that are observability problems for IT or security, right? Those consequences are kind of, will will say there's security consequences or something else.
But, you know, inherently those are things that we manage from an IT perspective. And sometimes we don't do a great job at 'em. Still, we don't do a great job at those things.
So an example where, you know, Datadog's, uh, a addition of a bunch of tools, and I do mean a bunch, uh, is, is that some of those things can put together the consequences in a way that allows either side to make good decisions. And I think that's very interesting. Uh, Datadog's, Logman viewed as the purely an observability platform.
Uh, in fact, they intentionally didn't build a sim, uh, when some others might have suggested, Hey, that's probably a good thing to do. The data's very common and there's an awful lot of this type of information. People are shoving application data in here, right?
To go evaluate that. Then the question becomes, you know, if that's an IT tool, is it also a security tool? Of course, it's, so there's value in tying those things together.
And I like the idea a lot, um, and we've talked about this a bunch on here, is that there's, there's great ways to tie these pieces together through things like agents. Uh, my my question is, you know, at what point is this sort of an acars, uh, approach, right? There's, we're talking about at performance lms, we're talking about a sim LLM that does triage and stuff for cyber.
We're talking about, you know, a way to, you know, monitor the, the, the rest of the agent's performance, AKA watching the watcher, right? We're talking about workload protection and a whole host of other things here. And, you know, the thing that I wonder about, and there's also code security in here.
So the thing that I wonder about is that's an awful lot of things tied together in one place. I'm not sure, um, how connective tissue there is going to, is going to respond. I mean, how the market's gonna respond to that level of connective tissue.
But I'm assuming here the, you know, the, if you don't do something right, you're gonna be nothing. And, and in this case, you know, when you compare to like a, a Dynatrace or AppDynamics, um, they're all doing very similar things. This is a big shot by Datadog to take on this many components.
It's, it's like five different industries that they just, And I'll add to that, they also launched an internal developer portal and IDP and gave a salute to platform engineering and said, part of the reason we wanna have all this connected tissue is that we are gonna see the rise of platform engineering and AI will help drive that. And I know those are at least two topics that are close to Alan's heart, but, you know, platform engineering is also part of this equation. Well, this is something I, uh, I mean this is kind of something I think really should have been done decades ago because, you know, I've always said like cybersecurity should be embedded in just about every unique function theoretically.
And that means, for example, administrators should be doing a lot of cybersecurity responsibilities. Help desk analysts, same thing. Operating system developers should have cybersecurity teams embedded within their development organization.
You know, same thing with all, and like Datadog, they, vendors like them should be going ahead and implementing cybersecurity along with everything they've been doing. And it's refreshing to actually see a vendor do this. I mean, I think Microsoft started trying to do a lot of this by writing more secure code and more secure development standards.
But at least this way, a vendor is taking responsibility for saying, you know what? Security is an integral part in everything that we're doing and we're enabling on your behalf. So I'll just say it's refreshing and leave it there.
Good for them. Now, kudos to Datadog, guys, I gotta pull the plug here and, and wrap up. People gotta get on with their weekends.
Uh, Fred Ira, having both of you on this show is for, from this, you know, old security. Dude, it, it does my heart. Good.
Thank you both, both, both for coming on, John and Mike is always as great sharing with you. Great sharing with you. I hope you found our conversations interesting today.
As usual, we have a full text, strong TV lineup immediately following, uh, Textron Gang today. A couple hours worth of more tech news in case you need it. If you don't have a great weekend, we'll be back Monday with more Techron Gang and more tech interviews and news and happenings.
Until then, though, this Alan Shimo for the And gang, have a great day, everyone. We're out. Hey everyone, welcome back to another Text Drunk TV segment.
I'm really happy to introduce you to my guest. I think this is his first time on Text Drunk TV with us. His name is John Raco.
John is the SVP Senior Vice President for Enterprise Engineering at our Good friends at OpenText. Hey, John, welcome to Tech Drunk tv. It's great to have you on.
Thanks, Alan. It's great to be here. So John, you know, we're gonna talk a little bit about OpenText in a minute, but for now, suffice to say OpenText is a really one of the giants in the tech industry.
I don't know if a lot of people realize the full breadth to be SVP for all of enterprise engineering. There is, it's quite a job, quite frankly, right? And congratulations to you.
But can you share with our audience maybe a little bit of how you came to be SVP for Enterprise engineering, kinda what your path has been? Yeah, Absolutely. Thanks for asking.
Um, one of the funny things is I am an extremely rare animal in the tech industry. Um, I am still essentially with the organization I joined out of, out of college. Um, when, uh, when I graduated, I joined, um, uh, general Electric in what was then GE Information Services.
I know it well, used to be a merit data before that. Yeah. And, and then it was, uh, spun into private equity, um, about 12, 14 years after I joined.
And then I came to OpenText as many people come to OpenText, I dare say the majority, through an acquisition. Um, so my, my career has been pretty varied. I started it, I spent a brief time in it, moved over to software engineering.
Um, I did build management project leadership. I was an engineering manager. Um, and then I got an outward facing job where I spent a lot of time with the sales team explaining our technology.
Uh, that led to an inside job in leading an enterprise architecture team. And that's the role I had when, um, when I was, when OpenText acquired GXS. That's a, that's a particularly good job during an acquisition or a major change because you have the advantage of explaining a lot.
So talking to people at a high level, the our executive leadership team and the, and the CEO, and then you also get, um, you also get to know all of them. So when the opportunity to lead, uh, lead enterprise engineering came up, I was able to transition first into business network and then into, uh, enterprise engineering. Excellent.
What a great story. John. You know, we, we'll talk off camera.
I actually have a lot of experience with the GE information system of married data folks. Uh, the group that founded that good friend of mine, Brad Feld, was the CTO when, when that deal went down. But we'll save that for an off camera discussion.
I mentioned OpenText having, you know, a wide breadth of, of products and solutions. Most of our audience, I'm sure is familiar with the name OpenText, and they probably have a very tunnel vision of yes, OpenText are the people where I get this solution from, or that solution from, I don't know how many of them really see the bigger picture. John, if I had, you know, to put it on your shoulders, you've been there long enough, how would you describe OpenText to these folks?
So, so OpenText is really about managing information across a, a series of problem donates. Um, our, our, the thing we're best known, or that we've been known for the longest is document or content management. Um, but we also manage information that companies exchange back and forth with each other through our business network.
Um, we help with marketing and customer communications through our experience group. Um, in the, in the last five to seven years, we've made a major thrust into cybersecurity, both on the consumer space with WebEx and Carbonite, and also in the enterprise space with, with key brands like Fortify and ArcSight. Also, in those last, um, last few years, we've entered the developer space in a big way, especially through testing tools in our A DM division.
And finally, I would say of the, of the big ones, our IT operations management. And what's interesting is when you look at all those spaces, what they have in common is generally we are managing information that belongs to the enterprise, but making it available in a secure way to the, the teams and staff that work in those enterprises, whether it's content management or service tickets or, or, or, you know, automated tests. It's all about managing information and increasingly in the cloud.
Excellent. And, and I should also mention, look, you came on board o to OpenText via an acquisition. OpenText is a company that has grown both holistically or, or organically, let's say, you know, as well as via acquisition, right?
They've made a number of acquisitions, uh, some big, some not as big, but really just, you know, a tuck in here, break into this market there, and you look back over, as you mentioned the last couple years, and you could see a real big expansion in the go go-to market here. Yeah, I mean the, the company is I think easily four times as large as when we initially joined it. Um, and that was only back in 2014.
It's crazy. Yeah, I mean things, it's nuts. Some Of that is organic and some of that is acquisitions, and I think it's the blend of the two.
It makes it such an interesting place to work. Agreed. com, correct?
Absolutely. Yep. So we'll, we'll close that one out.
Let's move over to what we wanted to talk about that today. And it's what everyone seems to be talking about today, right? Agent ai, AI agents, some people are calling them digital workers.
I think that freaks people out a little bit because those digital workers might be replacing human workers. You know, we think of them as competition rather than his tools. Um, and you know, we, as I said, everyone's talking about these, there's so much hype, so much fud, so much fake news, you know, really where, what, what is.
But that being said, beneath all that, there's reality that this is, this stuff is real. It's getting more real every day, it's getting more capable every day, and it's doing more every day. So how, where do, how do we see through the fog, through the, the hype in terms of what's real, what's possible, what's doable, what's OpenText seeing and doing?
So what's interesting is we a a few, you know, maybe even just two years ago, right? We had the LLMs burst on the screen, on the screen, and, and that was chat, the chat interfaces and being able to talk to 'em. And those are still playing a big role with everybody.
And everyone saw that and was wowed and blown away. And we thought, this is gonna change everything, but it actually wasn't. I think AgTech is gonna be the driving change.
And, and the reason is that it is going to enable us to realize the latent potential in all the work we've been doing for the past decade or two. What I mean by that is it's true automation of knowledge work. If you think about the, the change automation drove in the physical space with factories, with robotics and, and, and CMC machines, we haven't been able to hit that in the knowledge workspace.
And that is because we generally need, and I'm, I'm gonna use a word here that's overloaded in the AI space, but, but you need some context and, and some goals, right? So I, I can go to an information system, an ERP system or a manufacturing system, and I can get all kinds of wonderful information, but the system has no intent and it has no ability to understand what that information means. There have been some, some niche areas, you know, with, uh, typically other areas of ai like machine learning and whatnot, but it's been really hard to say, you know, give a, give a tool something and say, Hey, go analyze my product set and, and gimme a profitability analysis on each arm.
Obviously technology is incredibly important to answering that question, but generally there's an army of people hitting keys and stuff, and you go back and forth. There was never a, um, a system or a piece of software that could understand your goal and try to carry it out. And this digital knowledge worker or agentic ai, there, there's two really important things.
One is you can be way less precise about what you're asking for, and that's where the LLMs come in and their ability to understand human language and try and turn that into something more specific. The second thing is its ability to interface to systems that are already there using APIs we've already built. And that's what I mean by the latent potential.
So we have all these systems we've rolled out across our enterprises and that dominate our world, but it's not necessarily easy to hook them together and ask them questions. Um, agentic AI is sort of that last mile, if that makes sense. There is, that's a great way of looking at it, John.
It's a great way of explaining it. I don't wanna put you on the spot, but John, how much of it is real today? I think, I think a lot of it is real today, but the wave is just building.
And, and let me explain, let me explain why OpenText is so interested in this. Um, we, like I said, we give our customers tools for information management across all the, all those domains I talked about. And the, the only limitations customers have on what they can do with the tools we give them are their capacity, typically human capacity and their imagination, right?
AI is not gonna help us with imagination, right? Nobody's found a, nobody's found a computer, um, tool for imagination, but it's going to help us a lot with capacity. And what, what I mean by that is think in your own life or in your own business how much information is available to you versus what you can process.
At the same time. Think of like the best assistant or or direct report you've ever had who could go find the answers to you when you asked interesting questions. A agentic AI is gonna attempt to automate some of what that assistant did relative to those data.
Now it's not going to be as good as the best people out there, right? The best analysts, the best consultants are still going to outperform. But if you think about the areas where it's just not cost effective to put people in analyzing data or put people in there working across systems, agentic AI is gonna give us disability and we're starting to see it.
I'll, I'll give you a case from, uh, another division of open talk. Um, I work with, um, another, uh, vice president Tall Levy Joseph, and she runs our developer tools division. And her customers are using our AI agents to generate test cases.
In many cases, customers don't have automated testing across their whole portfolio because the, the ROI on devoting QA staff to build out tests on existing code is not there. But by using AI agents, they can now fill that in. So that's happening today.
That's an existing, um, in our, in our content management space with our Aviator product, we've been giving customers the ability to talk to their documents, um, via chat interface. So essentially you load a document up, it gets ingested, and, and you can, um, you can ask questions of it very similar to what you'd see in an LLM if you uploaded a file, except that all the, all the protections and security are still applied, which is very important to our customers. What we're launching next in the next two quarters is basically a agentic version of that to the point where you could workflow it.
So I want you to think about a customer, um, opens a, uses a self-service ticket to open an incident. And we know the customer, we know the product, we know about the configuration, the workflow can actually ask the documentation of the product about the error, the error, and generate a summary. And when the agent first opens that up to address the client, they already have a whole bunch of context on the customer and the problem.
So agents, agentic, AI have already worked on it. And, and the power here that that is amazing is I was at the Google Cloud next event recently. Each company is implementing agents in their own software.
So ServiceNow is doing it, Salesforce is doing it, OpenText is doing it. So all these agents will be able to collaborate together, so you're not losing the benefit of all the partners you're working with. But this can all happen in an automated fashion before you look at it for the first time.
So it's, it's, that is happening today. You can see examples of that today. And I think the biggest limit right now is on the imagination front.
'cause the technology's there, this, uh, the protocol, uh, MCP, um, you know, I'm looking at what people are doing with it. Um, MCP enables those APIs to be accessed with agents, and then the agent to agent protocol, which is younger, um, is gaining traction, and that's gonna let agents interact with each other. So, I, I think it's coming on really fast.
I love it. I love it. You know, unfortunately, Charlie, we only have 15 minutes.
This is a subject, well, I, I do a lot more interviews than probably you do. I do five, six of these a day. So by the end of the day, I do a lot of talking on agents and, uh, agent ai, but unfortunately, we, we need to pull the plug on this one.
How can people stay abreast of what OpenText is doing in this, in this new frontier? com is your best resource, and we have blogs up there and announcements. Um, we're, we're putting up demos on a regular basis of what we're doing.
And in OpenText, it's all about our Aviator AI strategy and the digital knowledge workers, which is what we, we refer to our AI agents as well. Sure. I should also, a quick plug.
We're actually doing a series of interviews with OpenText, I think Mitch Ashley, uh, CTO here at Tech Trunk Future Analyst for Doops, uh, is doing a series of interviews around ai, gen TKI and so forth. I specifically on the developer tools For, and that's a really exciting area because of the productivity and the improvements of quality. You can see working with our A DMT.
Absolutely. Uh, you know, for whatever reason we, and maybe it's because I live in the IT bubble that I live in, we tend to really focus on what AI's role is in terms of the developer experience, in terms of testing, in terms of writing code and security. I think AI is gonna disrupt so many different verticals across the board, but we're very focused in, in this IT area right now.
Well, and can I share one more thing with you then? Sure, you can. The whole basis of the package software industry is that it's too expensive to write software that's customized for your business.
But what if that changed? What if suddenly you could, and that is what we're seeing is we're seeing it. Uh, We're still, that's the promise Applications, but these agents basically make the application look more like a library.
We, um, and you have people stringing together capabilities from different vendors and homegrown, and you can do it so much more quickly. I think it's going to revolutionize our industry, and I don't use that word lightly. I, I've, I mean the, No, I, I don't disagree.
Look, I, I think it's not good, just the industry. This is, this is a, a civilization changing kind of thing, right? And it's gonna disrupt and change.
Just real quick, that series I mentioned is called Control Alt Deploy. So you can catch it on text drunk for people watching at home. You could catch it on, uh, tech Drunk TV or on our OTT app or what have you.
Anyway, hey, John, it's been great having you on. Please don't be a stranger. Come back on.
Keep us posted, keep up the great work. These are exciting, you know, for people like you and I have been around a bit. These are exciting times.
I mean, there's such, so much good stuff happening. Thanks, Alan. I really enjoyed it.
John Ratko, senior VP for enterprise Engineering at OpenText here, ONT Text Drunk tv. We're gonna take a break. We'll be back in just a bit.
Hello and welcome to the latest edition of the Techstrong AI video series. I'm your host, Mike Zu today, where we're talking with Eric Choan, who's the CTO for Pendo. And we're talking about Vibe coding and the impact that that's gonna have on enterprise it.
Hey Eric, welcome to show. Thank you very much for having me, Michael, For those that don't exactly know what Vibe coding means and is, maybe you could describe this a little bit. 'cause I think some folks listen to this and they're like, well, this must be something left over from the sixties.
Yeah, I mean, I'll, first of all, I'll give you the very extreme vibe co coding definition. Now, I think the term is all of two months old or 10 weeks old, so it's pretty new. But at the extreme, it means using an AI to kind of do everything for you using human language to drive the ai, even to the point of just doing really rapid iterations.
So you tell the AI to build something, it's not quite right. You tell it to fix it, it's not quite right, and you just keep feeding the AI and give, going through a really rapid set of cycles with it to try and get something that looks like what you want. It's not test heavy, it's not spec heavy.
It's not like people are riding a whole bunch of cars in Jira and moving them through a lifecycle to define everything. It's just sitting down and trying to get an AI to do something for you and get some working code that you can go use for your next step. To your point, it hasn't been around very long, but it sure has engendered a lot of love and hate on both sides.
So, yeah, Absolutely. Um, there are folks out there who say, this is great. It means mere mortals will be able to build software and others that say, well, the problem is mere mortals will build bad software.
So, um, how do we kind of think about this and what is the impact that, that might have on the way we build applications in the enterprise? Yeah, so first of all, I say why not both? Like, I think both of those things can absolutely be true.
And one of my favorite things when Vibe ca vibe coding came out was this Twitter thread from somebody who say, oh, this is great. I did this. I'm bringing it all to productions.
This is amazing. I didn't have to hire any engineers. The next day it's not scaling.
Oh my God, what's going on the next day? People are attacking me and breaking in. Third day, I'm, I have to turn this off now.
Why can't we have nice things? Right? Um, and that's certainly one extreme of it.
Um, that's probably the one where people are saying, oh, this can't work. The other one is we have people here, app penda who are non-technical. They might be designers, they might be product managers, they might be salespeople, and they're using Vibe coding to go bring an idea to life, except they're showing us what they, what they're thinking.
It's a way of, um, doing more than a storyboard and more than a picture on a whiteboard. They can generate something that looks and feels like working software. So it's almost prototyping at Arch and as a way of communicating ideas and thoughts.
It's a, it's incredible. There's nothing really like it and there's nothing for that speed. So that's on the other side, right?
Where's the reality gonna be for the enterprise? It's probably gonna depend a lot on not only your risk tolerance, but your, how, how important is it? It's correct.
Look, I have money in a bank. We all have money in a bank. Do I want someone vibe coding the application that's transferring my money into my kids' allowance every week?
Not really. Like that would make me nervous. Do I wanna vibe code some workflows at Pendo that we're using with our BDRs in order to have them identify leads, scrape information off LinkedIn and figure out who the right people to target are and who the people would be receptive to Pendo, um, to Pendo message?
Yeah, sure, let's do it. Right? There's very different cost of failure, very different testing requirements, uh, in the sense there's not only even the latter one, there's not even a correct answer.
While in the bank case, there is a correct answer and it's really important you get it. Will this kind of change the way we interact with developers and the people that they support? 'cause historically, and I think we've all been there, people come up with an idea, they put something together that feels like a requirements document that gets handed off to somebody, it comes back, builds something, and uh, typically it doesn't quite match what the original vision of the thing was.
And then it goes back and forth a half a dozen times till everybody gets really frustrated. And typically what we wind up with is a shadow of the original idea anyway, And we didn't give up. So with vibe coating, can we get to something that does feel a little more interactive and kind of close that gap between, you know, what some people would say are left brain and right brain people?
Well, I think it's gonna definitely close the gap, but I also think it's gonna re, uh, create a lot more software that's getting deployed. So I think you're gonna find non, um, software specialists building solutions and expecting 'em to run. Look, I mean, the cloud was, if you go back 20 years, the first step in this, all of a sudden people could start deploying things without having to go through it.
Now people can deploy more complicated workflows, more complicated agents, even more complicated UIs without having to talk to it. And they're gonna do it. Like, it's crazy for us to say here and think we're gonna be able to control that.
We couldn't control cloud because infrastructure is a service. We couldn't con, um, control business SaaS applications. This is going to happen.
So I think IT organizations need to understand what does it mean when their employees are vibe coding things on the weekend and getting things that helps 'em do their job? 'cause the whole goal is from it is to help people get more productive. I also think what you said is true.
We're seeing App Pendo where our designers are vibe coding things and bringing 'em to engineers. And the fidelity of comm idea communication in a vibe coded application in a rich prototyped application is in an order of magnitude better than what you could build with Figma, which was an order of magnitude better than you could put in a Microsoft doc. So you'll have much better cycles, much more rapid cycles.
It'll also either allow or force product managers and product designers to think through edge cases a little bit, right? I've said that one of the skills of an engineer is finding places where maybe the spec has gaps in it, they'll see the gaps in real life and they'll get to go fill them in. Now, that's a case where I think a lot of those vibe coded apps are gonna end up being rich prototypes and where engineers are gonna have to rebuild them for industrial use, at least for a while.
But I think it's gonna change the communication dynamic significantly. So what happens to all those low-code no-code tools that we had for all these years where we're trying to create this, uh, community of citizen developers with make success? I mean, do they go away or are they gonna be more just vibe coding platforms?
I think they're gonna become vibe coding platforms, or they'll go away. I think those are the only two choices, right? There's a reason that Python is such a popular vibe, coding language, it's easy to learn.
It has no memory management. You don't have to be an expert on how computers work on the inside. And a lot of these low code, no code solutions have these scripting languages.
You don't need a scripting language in a, in a world of AI and gen ai, you need human language definitions of what you want to do in an LLM to turn it into something more rigorous, which is really what Vibe coding is. So I think you're gonna see vibe coding certainly generate JavaScript code like you see it now, but platforms like Bolt, it's generating something. I don't even know what it is.
Nobody cares, right? It's just, it's being some something they can execute my idea. And frankly, a lot of agents are an instance of vibe coding.
And if I wanna build my own agent that preis personifies something, I'm doing it with LLM instructions, I'm doing it with sample documentation. I'm just throwing stuff at the wall. How that gets executed, I neither know nor care.
It's about the business value. It's about building an application or an agent that people can interact, uh, interact with and use. And it's interesting to me is AI agents are an instance of vi coding.
Well, um, we're using them to create code written in Java and whatever else it may be, which we created as an abstract to provide an interface between humans and the machines. But if the AI is a machine, maybe it will write something in a programming language that's a little more efficient than the one that we used for humans, right? Yeah.
I think there's two possibilities that are really interesting and neither one may come to pass. One is what you said, why are AI is writing Python code instead of machine code? Like, it's not entirely clear to me.
Now, the reason isn't not good enough at writing machine code, right? And people have to, humans have to read it and fix it right now, but that's not gonna last forever. We have the worst AI today we'll ever have.
They're only gonna get better. Um, so that's one thing that's interesting. And another one is where is the line where an LLM is just your execution engine as well, like in an agent, you're generally writing English code and the LLM is the execution.
It doesn't turn it into Java code, it doesn't turn it into Python, it just goes and executes your instructions. And an agent is doing it in a loop, right? It's going and repeating tasks.
It's doing things for you without a lot of code being generated at all. So is the future end state of all this, I write human instructions to generate Python instructions that get generate machine instruction. That seems a little clunky, right?
It does seem like there's an extra step or two in there. I also wonder if it will change the way people work in the enterprise, because it seems to me it will become a lot easier for somebody to say, here's my idea, here's my idea in software, and then share it with other people who aren't developers and they will collectively build something whether they build on top of each other, because a lot of that innovation is still, uh, you know, a group does better than a single individual most of the time, at least for the long haul. So, we'll, the way we kinda work together change.
Yeah, I mean, individual software use software development used to be a proprietary exercise, a solo exercise where you went in the closet and did it right? You think back to the movies about 1960s, um, MIT closets, and now it's a very collaborative effort. These first vibe coding tools, they don't have collaboration, they don't have version control, they don't have the ability to work together very well yet, but it's gonna happen very, very quickly.
You're gonna find the, uh, uh, the hugging platform or the GitHub platform. You know, one of those things for vibe coding tools where people can't collaborate and work together very rapidly. Now, professional developers are usually supported by something that feels like a DevOps slash software engineering team.
Will those folks be then working with a lot of the applications that are created now by citizen developers who are provide coding things? And will that change the way that that whole process works? I mean, your guess is as good as mine.
My guess. My guess, though, is that you're gonna find those teams building a platform that these applications could be run on without taking responsibility for those platforms or for, without taking responsibility for those applications. So I'll say, all right, you want to use this vibe coding tool at my co at your company?
Great, you can use it. Here's where you run it. Here's the cloud environment.
We maintain the cloud, we give you the ways to deploy and run your agent or your whatever it is that you just built. But those people, the people who wrote them are, are gonna have to take responsibility for 'em. I don't think any IT organization's gonna be able to take five applications a day that are being spit out across an organization, a scale of 1500 applications a year and have any meaningful ownership of it.
But will they provide the core database that's used? Absolutely. The will they provide a 24 7 infrastructure to run it on?
Yep, definitely. So they'll provide the enablement and the platform, uh, layer of things, and then they'll just see, you'll see this huge number of applications just running around On top of that, One of the ironies though, is when we tried to have this citizen developer revolution using low code and no code tools, at least in my experience, half of the people using those tools were actually professional developers who just preferred to use something at a higher level of abstraction. They write something that, you know, they kind of just need it quickly.
Is that gonna happen all over Again? And engineers want to go fast. They wanna build software quickly.
And the story of a kind of innovation as we went from assembly to low languages, like c to higher level languages like c plus plus to Python and Java, at every one of those movements you've seen engineers climb up the stack to something that let them do their job faster. Lab coding tools are gonna be another layer that lets them do their jobs faster. And I think you see that in data scientists probably, first of all, where they spent the last 10 years learning Python wearing data science libraries.
I'm like, I have a kid who wants to do data science. And I'm saying, why would you learn to code, like, just go use some platform. How you put to get through sling python together, do matrix operations is not interesting.
It's understanding what matrix operations need to be put together. And these tools will get you there faster. And that will happen across all the whole development lifecycle.
Will everybody eventually start to think more like a software developer? Because there is, it is not just the tools, it's the way you can think about problem solving. And maybe, you know, we collectively as humans will be trained by the AI to think differently.
No, I don't think so. I think that's actually exactly the opposite, that all of these tools are about letting people think, like humans in the machine, able to adapt to human think it's, we'll, we'll see. By the way, I think that's interesting, but I don't know that everybody in the world needs to be able to algorithmically decompose problems to be successful with in a AI vibe coding world.
So what is your best advice then to CIOs who are looking at all this right now with probably a mixture of odd anticipation and a little fear? I think all this feelings are probably like the ones that had when mobile happened, probably like the ones when web browsers happened and the internet happened. Like, this isn't anything new.
This is the next seed change. What, what did we learn from those? That if you try to stop it, you're gonna get run over.
If you try and prevent cloud, everybody's just gonna deploy your cloud and you won't have any control at all. So be open to it. Enable your, your team to try things, enable experimentation across your enterprises broadly as you can.
Literally today I tried three different coding, AI coding platforms to solve the same problem to see which one worked best. I won't name them and I won't tell you which one worked best, by the way. Um, but we're try, that's what we're doing here at Pendo.
We're getting encouraging our engineers to try all the tools they can. They find, try everything. Make sure that you're not only building your individual skills because you know, no job is forever, but you're helping Pendo learn, which are the ones we should embrace.
Now, my ciso, he's absolutely approving all the platforms. We are looking enterprise deals with all the different providers so that we can use single service sign, single service, sign-on so we can have the right levels of accountability, the right levels of auditability. So we're trying to let people use the tools they want to inside of a IT compatible universe.
But that can't mean just saying, no, you can't do it. 'cause then they're just gonna do it on their personal credit cards. It's true.
We'll just have another flavor of shadow it, right? Yeah. And one that is probably 10 times worse, right?
It's that enough. When you use random applications, can you imagine writing random applications? You need to find a way to have corporate control, corporate blessing of it.
Also, will the applications themselves become a little more disposable? And I ask this question because so many folks have an idea, but by the time they stand up the development environment and do all those things, they just decide to go back and sit on the couch. So will we have, you know, things that people are gonna do that they only need for, I don't know, a month If it only takes you, if it only takes you an hour and a half to build?
Definitely. Mm-hmm. And you see, ID you see computer specialists doing this all the time, or how often do we throw together something new script?
We use it for one task and we throw it away. And we do it where our peers don't, because we can do it quickly, but people do it in spreadsheets. Who our spreadsheet experts site is when the, when the difficulty and the expertise, you need to automate something, it all goes down.
The number of things you automate goes up. It doesn't mean you need to automate it for the next 10 years. You may only have to automate it for the next two weeks.
And it's one of the, it's one of the places where I think you can see the most productivity improvements from this, by the way, is everybody being able to automate little, little tasks as they need, as they see fit. All right folks, you heard in here, there's no avoiding it. And frankly, if you're an IT leader and you want to hang out with the cool kids, maybe it's time to host that vibe coding party.
Hey Eric, thanks for being on the show. Thank You, Matt for having me. Enjoyed it.
All Right. And thank you all for watching the latest episode of the Techstrong AI series. You can find this in other episodes on our website.
We invite you to check them all out. Until then, we'll see you next time. Hey everyone, it's Alan Shimel and we're back here at Techstrong tv.
My next guest is Anthony Woodward. Anthony is the co-founder and CEO of Record Point, and I think this is his first time on Textron TV with us. Anthony, it's a pleasure to meet you.
Thanks for coming on. A pleasure to be here. And yes, it is my first time on Text Street Take Strong tv, so thanks for having me.
Fantastic Anthony. Um, I, you know, we were talking off camera. I founded a few co-founded and founded a few companies in my day as well.
You know, you gotta be a little crazy to found the company. You gotta be driven. You gotta really believe that what you are doing is important, right?
No one ever says, yeah, I started a company. We don't really do anything important. No one really cares.
You know, you, you, there's gotta be a belief that somehow you're making someone's life better. You're making the world better in some small way or big way. Talk to us about kinda your journey and where you found your passion.
Yeah, it's a great question. I've really spent my entire career, um, looking at two key things. I I, I worked for a long time in the legal industry, had some training, um, in the legal industry, really thinking about regulation and data.
The early two thousands, uh, in fact worked on, um, a bunch of processes around data. 2000 Olympics in Sydney, um, and went on and took that career to working to all sorts of organizations, looking at how they're handling information, what they're doing with it, and what are the controls wrapped around it. And, um, you know, that really delivered me, um, a bunch of understanding and training to think about how, um, organizations should be more effective at, at data control.
Absolutely. And so then you're co-founder kind of by definition means that you had someone else also as a co-founder with you. Talk about how, how record point came to be then.
Yeah, so Alon Astro, who is my, my co-founder, no longer operational in business, but, um, we worked alongside each other in a, in a previous business doing a lot of consulting, uh, you know, in, in the data management arena, primarily in those days. In fact, with Microsoft, on the Microsoft SharePoint platform in the Asia Pacific, so in Singapore and in Australia and those places. Um, so we had previous business, we actually sold that business to the Jacobs Group, um, who bought that, bought that out to build a consulting practice down in, in apac.
Um, and in fact, while we were in that business, we were sort of thinking about there must be a better way to actually address, um, the problem of managing data, particularly records, and you can tell from the record point name, we, we came from storing, um, your data as records, um, and really applying machine learning and rule sets. So this is going back to like 2009, 2010, um, to classify and then build better control so that you would, you know, be discovery ready, be able to hit particular pieces of regulation and, and deal with that challenge. And that was really the inception.
What what we saw was that most companies were pretty good at collecting their data and working on it, but they were really bad at storing it over the long term and making sure it was ready for stakeholders that needed to use it. And, um, that was really the mission initially. Excellent.
Um, timeframe, how long, how long have you been at record point? Uh, sadly, sadly, uh, uh, uh, you know, as I said, we start yeah, around that, um, 2010 timeframe, so it's coming on 15 years now. So, uh, we've been, there's Nothing to be said about that's, that's an accomplishment, right?
Yeah. You know, in a, in a world where the average business venture, you know, doesn't last a year, being around 15 years means you're doing something right. Yeah.
We like to think something, right? Yeah. Yeah.
Uh, Anthony, for people want to get more information about record point, where, where, what's the kind of the best on ramp here? Um, you know, traditionally my answer would be, you know, go hit the website, uh, record point dot come and have a look at. But, um, I'm actually more recently and we are really leaning into large language models and those things just go and ask chat, GPT and, and, and Gemini.
Um, they have some really good answers. I think these days around what we're doing and what we're focused on. You know, we've evolved a lot since our early days, so the things that we focused on, you know, classifying information, building file plans, disposing of information, you know, which were really early iterations of the product have now evolved considerably to, to reach to AI and other things I'm sure we'll touch on in a minute.
Alright, with that out of the way, Anthony, let's turn to our topic of discussion today. And that, you know, is framed as the intersection of data, technology and compliance. Mm-hmm.
Yeah, A lot to unpack there. Why don't you start off unpacking it with, for us? Yeah.
Look, uh, the, the reality is, and we see this I think in most disciplines, is, you know, technology is moving so fast that, you know, there, I think, you know, um, right now we're feeling that more than ever, um, that that pace of change, um, regulation and compliance is not move at the same speed. Um, so you have these two different disciplines that are, uh, you know, very much integrated and reflective of each other, but they don't actually move, um, in a, in a connected way. Um, and so what is kind of occurring is you've got companies trying to exist with regulations that often can talk about paper processes, can talk about how you shift and stick things in envelopes and send it across, um, mail boundaries.
And that was the thinking of how that regulation was written. Um, and we've gotta apply that to technology that doesn't even have any of those concepts. So, um, really where we live is being able to take those regularly regulatory controls, and that could be something as simple as, say, the Banking Security Act and, uh, what we need to do there around managing people's information to something more complex like CCPA, the Californian Privacy Act.
Um, it's really looking at how do you bring regulations to data and to technology, and then apply that in a way that doesn't block an organization from getting value out of the technology and the data sets that are there. And it's really that intersection that we live out where you can codify regulation, um, to make sure systems are doing the things they need to, and that data is managed in a way that's going to evolve, uh, away from risk and away from, you know, any legal issue that might occur. Excellent.
Um, you know, you mentioned AI before Anthony, and it's obviously touching on and changing so many different thingss. How, how is, how is it affecting your world at record point and at this intersection that we're talking about? Yeah, uh, look, um, there's already 167 pieces of regulation globally on ai.
Um, the most familiar ones are the European, um, AI regulations. But, you know, you've got, um, various other permutations, which could be from, um, some of the OECD, uh, uh, sort of self-governed, um, processes through to what you're seeing occur in New Zealand and some of the other countries out there around how to, uh, manage ai. And really what we do is try to flip the problem on its head, um, and take the regulation down to the data itself.
So there's lots of products in the market that will help organizations, um, you know, build better models, curate, uh, how, um, what are the biases in ai, you know, deal with some of the things that are required from a regulatory control, but they're really done generally outta model level or, um, trying to silo data in, in turn in into different generative AI or other AI applications. What we've really focused on is no, no, no. What we actually need to do is focus at the data level, because if you don't focus at the data level, you haven't already, you haven't dealt with some of the baseline things before it gets into the model.
So that could be thinking about data privacy, which is a really big element. Are we ensuring that we're not putting data into models that, or, or even into open AI or, um, with Google that has levels of sensitivity. So how does an organization classify and flag and deal with the data lifecycle that's associated with sensitivity?
So, flagging out, you know, really simple things, children's information, uh, pri you know, private addresses, those sorts of elements we make sure, wanna make sure that's our, we also do a pass and tagging of flagging thinking about the combinations of things. So I might have a piece of information which talks about, you know, Alan, without mentioning your name, but in an LLM maybe you can join that information. So maybe I've got, you know, your, um, united mileage plan number, uh, and somewhere else I've connected the mileage plan number to your name.
Well, we, we also go to the next level of looking for, okay, what are the signals inside that data that might have the mileage plan up, might have other el elements of sensitivity that you might not think is sensitive. So it's, it's quite deep around how this technology is now applying that We also then go one more level before we package it up and, and push it off, um, to the generative AI or, or any other, um, AI element. We'll do a, um, cleanse of the data.
So the other thing you want to do to make your models more accurate is pull out any redundant, obsolete, trivial data that is going to skew the models and doing that these days, you know, by hand, and that's what people used to do a lot of the day, scientists would pick that out effectively and find those signals is quite a intensive and expensive process. So what we allow you to do is we look for the patterns of what is redundant, obsolete, and trivial data. We look at minimizing that data set and sort of removing, um, bad signals alongside the sensitive signals, and that allow you to work out what should come in and out of ai, what are we gonna use in, um, different types of ai, uh, and then drive that from the data side.
But we go one more step in terms of regulatory compliance, and that is we observe the prompts going into ai. So as you go and ask chat CPT, and you've got, um, record points sitting there in the background, or as you go and ask, um, Gemini or any of the other flavors, um, we will monitor the prompt, we'll monitor the response to the prompt, and then we'll store that off so that in the future if you have, uh, a legal issue or the courts come past and ask, where did you get this information? What occurred?
You've got what we describe as providence to prove what happened, what was the data that went in, what was the query that went in, what was the response from the generative ai and how do you then manage that? Thanks a lot, Vince, Nicole does, you know, I'm reminded I, Anthony, I was in security myself for 25, 30 years and, you know, uh, unfortunately the bad guys, it sometimes they're just out in front, right? And I remember back in the day, it probably was from an old Verizon data breach report or something that when you looked on the dark web, you know, if you just wanted someone's first and last name, yeah, it was cheap.
You wanna match it to an email address, a little bit more money, but still cheap. You want a phone number associated with it, well, it costs a little bit more money and it went down. You want to get social security number, well, there's a price for that too.
Credit card number associated to that person, zip code, you know, and, and, and in so doing, you could build up a dossier on a person, right? An entire record that oftentimes they would use that not just to rip that person off, but to create a, a fake id, right? Go file a tax return under a false address and, and stuff like this.
So, you know, the bad guys have been doing that sort of model for a long time now with ai, we have the capability of doing it a lot easier, but so do they, and I think that's something that we need to remember as well is, you know, the, the white hats, the good guys just don't have the monopoly on this. Uh, no, no. Look, you, you've brought up a really complex issue that I think we're all struggling with.
Um, this technology's amazing, but as, as we're going forward, being able to identify what is, um, constructed or, or sifted data to then, um, effectively spike it so that it can be reused in different ways, um, is a really complex area. And it's something, what, what we're really focused on is how do you make sure what goes into the models doesn't get accidentally mixed? And I think that does limit a little bit of your exposure, but the reality is, you know, um, what's happening with these models, and we're already seeing a lot of cases of it out there in the wild, is people are really joining large, disparate pieces of data and constructing whole new identities or whole new, um, you know, ways that, uh, the data can be, can actually be reconstituted so that you can effectively create, you know, a whole new version of Alan that, um, exists out in the ecosystem.
And, um, the reality is there, there is, I think this is an area where we're waiting for governments and regulators to kind of catch up so that there are some more controls in that space. Yeah, I, it may, may, my fear is, is that the space, it's moving so quickly, right? I don't know if government ever catches up.
Yeah, I, look, I I mean we probably come from a slightly different perspective. You know, I think it's quite encouraging that, um, that, that you, you are seeing a lot of folk in government think about these issues. Yes.
Um, I would like them to probably take a little bit more of a step forward around thinking about what are the, the key things they wanna focus on. 'cause a little bit, um, distributed the thinking at the moment, but, you know, um, you, you do have, you know, some leg legislation, you know, here in the us but globally around things like deep fakes and manip manipulation and the identity theft. The issue is that right now, the, um, onus onto, you know, Facebook and other people that have large amounts of data that go into these things haven't, hasn't really transferred.
You know, they don't suffer if you end up having a reputational damage issue or any of those things. You know, Anthony, a a hundred years ago I was in law school, and I remember I, my constitutional law professor, he was a pretty good professor. He, he said something that I never forgot, which is generally from the adoption of technology to society and then legislative regulation catching up to it, there's anywhere from a three to seven year gap.
Now with the ad, this is way before there was an internet and everything else, with the advent of the internet and the internet time crunch, if you will, maybe it's not three to seven years, but it, it's not measured in months either, right? And so it's probably close, let's say two to five years, or two to four years. And I, I think that's probably what we're looking at here.
Yeah, look, I think that's fair, but I would point out that, um, when you look at, you know, CCPA, the California legislation around privacy or GDPR in, in Europe, and, and there are various other, uh, US state-based legislation like that, um, some of this is already there. It's really more about enforcement, right? Um, CCPA has the right to be forgotten, has some, um, ability to manage data going into the complex AI models.
And, and so it's really on organizations and us as individuals, not just to wait for the regulators, but to look at these model approaches and enshrine them into our, into our organizations. Because I think we have a, a moral responsibility to do. No, no, I, it's a personal, it's not a method one personal and it's a personal and organizational responsibility.
You can't wait for the government to come protect you here, right? That's, that's not a formula for success either. I don't think anyone's ever succeeded in that.
Anyway, Anthony, I promise you the 15 minutes of these things go long. We're already over time. com.
COM com Yeah. Do com. Yeah.
Record point do com. Yeah, The old fashioned way. Old school, But yeah.
Hey, Anthony, thank you for coming on Text trunk tv. Pleasure to have you on here. We're gonna take a break.
We'll be back with more in just a moment. Hey guys, thanks for the throw. We're here with Dom Rizzo, who's the CEO for zero risk, and they're fresh offer of raising $10 million in additional funding.
And a lot of that is gonna go into the commercialization of an open source silicon project known as Open Titan. And then I'm gonna let Dom explain what it is that does Dom, welcome to show. Absolutely.
Thank you for having me. Really appreciate it. All right.
So, uh, Let's start at the beginning as they say. What exactly is Open Titan? So, open Titan, uh, is actually a, a project that I, I started almost, uh, 10 years ago.
Uh, and then eventually really got it off the ground when I was at, uh, Google about seven years ago. Uh, and since then, it has really grown to become the first kind of commercially relevant open source silicon project. And so what we do is we are major contributors to Open Titan, but we also take the IP that we developed under that project, and we work with customers to both integrate it into their designs, but then also provide the sort of supply chain integrity services to sort of manageability of these devices in the field, which is really where a lot of our focus is, because a lot of the work Broken Titan is, is fairly mature at this point.
Where are we on the adoption of this? I mean, are we still building out the silicon or are we seeing use cases for this already? And what are they?
Well, So the silicon itself has been adopted by Google and their Chromebook and the data center, or is in the process of being adopted by them. Uh, we also know, and I think this is, this is public, is that Voss is using it as the silicon root of trust in all of their triplets. I think there is a really, uh, really exceptional talk given at the Risk five Summit in Paris a few weeks ago by a Voss employee, a fellow named, uh, Robert Shilling.
Just done some really exceptional work in taking the first kind of discrete open Titan design and adapting that to be a, a sort of secure element that's much more suitable for inclusion into any kind of device. Where does zero risk fit in? What are you guys doing?
And, and, and are you, I'm assuming providing some level of support, but what else are you doing? Yeah, so we do a, a couple different things. Basically three different tranches.
Uh, we are major, like I said, major contributors to the upstream, uh, open Titan project, uh, primarily around cryptography, post quantum cryptography, certifiable cryptography. Uh, we do also work with customers to, uh, help with integration and support of the open source project. I mean, as we kind of know, uh, open source isn't free.
It does require some often level of support from the people who know it. But then what one of the things that we really focus on is we are deploying hardware into the, uh, uh, sort of silicon manufacturing facilities to establish trust in these devices from, from the, from the get go. And what we do with that, that sort of initial trusted, uh, relationship is we're then able to, uh, manufacture and assemble anywhere, uh, while still retaining, uh, ownership and control of the silicon and the devices it goes into for customers.
What Leads people to conclude that they need a new process or architecture? Is it just some new project, or are there other forces at play here where people are starting to reevaluate the legacy architectures they have? Well, I think it's, it's not just about legacy architectures.
It's about, uh, secure security. And silicon has traditionally been kind of a high-end feature. It's been a, a premium feature.
And I think something like, uh, open Titan, other projects, uh, really the, the ecosystem of IP that's been created by Open Titan enables the ability to bring security everywhere, right? If you have to pay a huge licensing fee to add a secure element to a commodity chip, a 40 cent chip, you're not, you're not gonna do that, right? Because why would you increase the cost basis of that device if the security is borderline free?
Why wouldn't you do it, right? It, it makes, it makes the, the designs more trustworthy, more transparent, more controllable by, by the end user. So that's just a net good for everyone involved.
Is the concern about, uh, post quantum encryption also going to change the conversation as well? Because I think some of the cryptography we're gonna run maybe is a little more compute Intensive. I think it can be.
So I will say post quantum is very, very important, uh, regardless of what your stance is on, on when we're gonna have a cryptographically relevant post quantum computer, uh, the reality is, is that everyone is transitioning to that and, uh, that is going to be quite a significant investment. So, uh, our, uh, we, our, our principal cryptographer, Jade Philipo, has done really exceptional bleeding edge work on not just the secure verified boot, but also sort of computationally efficient implementations of the latest NIST lattice based standards, right? So there's, there's still, uh, kind of some open research questions there, especially around the fault injection resistance, the side channel, uh, resistance.
And later this year we're gonna actually be releasing, um, some pretty impressive kits that implements that in a very area cost and compute, uh, efficient way. So will people implement this silicon as kind of like a co-processor for security, or does it become the main processor of the platform that just happens to be more secure? You know, it really depends on what class of chip you're talking about and whether you are primarily concerned about sort of static at boot time integrity, or you also want to leverage a, um, sort of leverage a secure co-processor as like a secure element or a secure enclave style processing device during runtime.
So it really, uh, it really depends, and that's why a lot of the IP has designed to be in a very, like, flexible modular fashion. 'cause some people, some people don't even need a processor, right? They just care about identity, which is really important, still relevant for us because we build the identity database, we build the ident ident identity harvesting sort of equipment.
Um, but they don't need all the bells and whistles of having like a full 32 bid or 64 bit core in there to run applications. So it, it's a, it's a little bit of a wishy-washy answer, but the, the real answer is it really depends on what your specific, uh, security secure identity needs are. So what's the plan for the 10 million?
What needs to be done next? Uh, well, we, uh, have, have been hiring fairly aggressively, uh, in the engineering space. We are, uh, bringing in additional commercial support because, uh, you know, there's a lot more to running a business than just really, really good engineering.
Um, and I think what that really does for us is it gets us to the next level in terms of customer acquisition and support. When you think about this, there's been a lot of concerns over the years about how companies make money in the open source era. So how do we kind of make a project maintainable and still create an ecosystem where there's people who are like yourself, who are building companies and making money on this in a way that's sustainable?
Well, I think, uh, red Hat really showed the way for that, where you, you decide on an open source core, which you support and maintain, and then you add a lot of support and services around that. So there's the support and services associated with the silicon ip, which there's plenty of room to run there. But then for us, there's also the manufacturing time and the runtime, uh, sort of cloud-based identity as a service model where, uh, we just feel like there's a very, uh, uh, very rich environment.
There's a lot of lot that can be offered that leverages some of the secure silicon that we can basically give away, uh, to support it all. What do people who want to build something on this need to be aware of or to think about? I mean, a lot of folks would be hearing about this for the first time.
So how do they get started here? I mean, you can get started with the, the upstream documentation, uh, and, and try and run with it. Uh, that's often fairly challenging.
Uh, you can always reach out. We have plenty of points of contact, uh, ways to contact us through our website. Um, I would say the best way to get started is just to download it and start, um, it's all there.
It's all, it's all freely available. And if you, and if you have a question, please don't hesitate to ask because it can be quite challenging to navigate on your own. Very good.
Are you at all worried that the Intel's nads of the world will just, you know, basically see what you've done and follow suit? I think that that kind of adoption just sort of shows that, uh, this is, uh, valid and commercially relevant. I don't see any cause for concern there.
I would hope that they would want to adopt this because this level of transparency and high quality development is quite good. And I know that Intel and, uh, a MD in particular, they have a long, long history in doing open source, uh, being supportive of open source firmware and various other, uh, uh, open source software projects. I don't know why this would be any different, especially Intel who has a very large fab that they would like to fill.
So, So speaking of that, are there foundries that are prepared to go build chips on this? Uh, well, we happen to know that there are some foundries who are already building, uh, chips, leveraging this technology, but I think for now, the foundries are really deferring that to their customers. The SOC uh, vendors, people who are designing the FLIs, the fabs, uh, semis who are designing the devices As you kind of put all this together, um, is the nature of the workloads that we're running, particularly in security changing.
'cause I feel like, well, there's just more data to be processed and analyzed, and we're grabbing more telemetry data than ever. And so are the characteristics of the workloads and security changing to the point where I do need some different approach to the silicon? So I think, yes, there needs to be a different approach to the silicon.
I don't think the changing nature of the compute is driving that so much as the growing awareness that security is not a feature to be stapled on. It is a holistic sort of design enterprise. Uh, and so people are becoming more and more aware, this is especially true with the Cybersecurity Resiliency Act in Europe, that you do have to take some responsibility for the lifetime integrity of, of what is in your silicon, what is running on your silicon, where your silicon is coming from.
And I think that is really driving some of the, the change, right? Um, I don't think that today's workloads are necessarily, um, require a different approach. I just think that there's now more of a realization that there needs to be a holistic sort of security architecture in every chip.
So how did you get involved with this? Not everybody wakes up one morning and says, I know I'm gonna go build an open source silicon project. So what's the backstory here?
Well, when I was a, an undergrad 20, 20, 25 years ago, I worked for a fellow named Andrew Bunny Wang, who really impressed upon me that, uh, visibility matters, especially in security. You need to be able to trust the things that are running your code. And owning a device means being able to control the code that runs on it.
So, you know, fast forward 10 years, I, I first started pitching this, it was originally called Honest Machines, took me about another three, four years to land it inside of Google. Um, and now we're off to the races. Right now we've got commercial chips coming out, being released by New Baton that are based on the design.
We've got people like VOS adopting it for their, uh, internal, uh, their triplet root of trust. So it's been a bit of a journey. Um, and I think this is really, this is just a, uh, for me, there's kind of two things motivating it.
One, I find it bizarre that my, my iPhone has better security than the, the industrial controllers that run our critical infrastructure. And two, it just kind of seems an obvious thing, right? If we're gonna run, if most cryptography libraries are gonna be open source because they're inspectable, well then the thing that verifies what's running on the chip should also be open source because it's even lower down the stack, if that makes sense.
Sure. So ultimately, you know, as you look in the year ahead, what's gonna be next for the project? What are you guys working on?
Oh, I think for, for the project, it just continues to move forward. Like I said before, there's been a lot of interesting work recently, uh, around the, uh, integrated, uh, secure element space, the sort of, uh, uh, what they call the Darjeeling design that, that Vos and Robert have been driving. Uh, that's something that we're particularly interested in.
I think there's likely to be some additional work on the cryptography, sort of moving it towards a production ready basis. And those are, I think, the really, really key, uh, important aspects are, uh, for the future, right? So it is an, it is an interesting thing because we've sort of, we've proven that the IP is good.
We've gotten it over that first hump, and so now it's ready to use in a way, right? So it's, it's the, the work required going forward is gonna be significantly less than the work that was required to get here. And Folks, well, you heard it here.
We've had open source infrastructure for a while, and now it's all the way down to the silicon level, and it's gonna be optimized for specific use cases like security. So it's a brave new world. Stay tuned.
Hey, Dom, thanks for being on the show. Absolutely. Really appreciate your time.
All right, I'm back to you guys in the studio. Hey everyone, I'm Alan Shiel and this is Jonathan Singer, and you are watching The DevSecOps Show Cracking the Code. You've never heard of that show.
Well, for good reason, this is the very first episode of it. We're just starting it. And thanks for joining in.
Um, we're going to take today's show to just kinda give you a what to expect and what's coming here and introduce a whole concept to you. Uh, DevSecOps show Cracking the code is a joint production between us here at Techron Group, techron tv, as well as check marks, our partners check marks. We partnered with check marks for many, many years.
They've been a leader in the AppSec space, DevSecOps coming now into platform engineering as well. So I'm thrilled to have check marks co-producing this with us. And my co-host I mentioned, his name is Jonathans, Jonathan's with check marks.
Hey, Jonathan, nice to have you co-hosting with us. Welcome. Um, thank you.
You know, you are the new guy on the block. Tell people a little bit about you. Sure.
So, uh, it's nice to virtually get my face out in front of everyone, and thanks again for the warm welcome. I am very much looking forward to doing this series with you. Uh, my background, I've been with check marks for a couple years now, and, uh, I've spent a lot of the last 20 plus years, sadly.
But yeah, it's been, it's a long time. You don't look adult. Uh, well, uh, you know, I'll, I'll take it, I'll take it, but yeah, no Good living.
Uh, yeah, what can I say? Good skincare. It's, it's great.
Mm-hmm. Uh, but I've been in cybersecurity and, and some adjacents work in telecom for the last 20 plus years. Uh, and I, uh, I'm current in my current role at Check marks, I'm doing a lot to help the organization shift our focus into the realm of developers.
And we've done a lot of work, uh, as a company over the last four years, like really making our platform developer friendly, good for developer teams, good for huge like development organizations. And so we wanna take an opportunity to sort of get the word out, uh, as a company. Um, and I am, I'm sort of leading that effort, so that's why I'm here.
We've got a lot of fun topics to talk about. I've been talking a lot recently about DevSecOps maturity and, uh, about what that really looks like and, and how you advance as an organization. So lots, lots to dig into.
Absolutely. I want to dig into some of those topics, kind of pre-announce them here today. I'd like to go into a little bit more about check marks in their history, though.
You know, like you, I've been in security, well, probably longer than you, to tell you the truth. I've been in security now about 30 years, and, um, you, I've seen a lot of water under that bridge, right? I've seen us move from a predominantly network security type of world where we put big boxes, you know, at the, at the drawbridge with the moat surrounding the castle to the advent of the cloud, to the advent of DevOps, ai, now platform engineering, SRE, so many, you know, subsequent waves.
And each wave has brought new innovation, new techniques, new best practices. So over that time, I would say one of the biggest Innova, not innovations, but shifts in security, was the shift to AppSec, right? Even before DevSecOps, the shift to AppSec, the idea of we are going to secure the applications, whether they're in the cloud or in a data center, or on your phone.
We need to make sure our application code is secure. It's free of buffer overflows and cross site scripting and SQL errors, and, you know, all of those kind, kind of common things. You know, obviously, uh, OAS top 20 kind of, you know, uh, of, of, uh, vulnerabilities.
And that's when I first became aware of check marks, right? Check marks was a pioneer in AppSec, right? And we, you know, the idea of, of static code analysis, dynamic code analysis.
Then of course, later on came, um, uh, open source scanning, and I always forget what we call it now. Secure code analysis, SCA, right? Basically scanning our open source code.
Um, all of these things really, I think they made a huge difference in the quality of the code that gets released. And, you know, that's in our applications. At the same time, things like DevOps and agile man change the way we develop software.
The biggest change is what, you know, I call the shift to a software factory, right? Where it's not, I used to think of software as like, you know, like mid 18 or mid 18 hundreds Germans, craftsmen, fine craftsmen making furniture or iron metal workers or, you know, the guild where you had apprentices and, and lifelong, you know, that real craftsman kind of role. But I think we saw a shift to the factory, right?
Much like we did in automobile production, right? From bespoke automobiles to assembly line. And we saw a, the same shift in software.
Uh, we also saw the advent of repos and open source software where people, I, I, you know, it's like Frankenstein software. People stitch together a whole bunch of different components right? From different places, and that's 85% of the code in today's applications.
Um, these are all big changes. And then of course, the biggest one for us here on this show is the whole start of DevSecOps, right? All of a sudden it became cool to say, Hey, d you know, hey, developer, we know you want to develop quality code.
Even though we're not those old, you know, mid 1800 craftsmen anymore, we still have pride in our work. We still have pride in the code. We're publishing.
We want no one raises their hand and says, Hey, I feel like putting out some crappy code today. No, everybody likes good code. And, and so that was a revelation for security people, Jonathan, right?
We, we, we spent 20 years, we always said, nah, no one cares about security but us, we're the only people. But no, they care about security. Let's give them the tools to do it.
And, and again, check Marks led the way there, I think, right? With, uh, well, the most recent is the advent of check marks won that whole platform. So that was a long-winded intro for you to discuss check Marks one and what that is.
Well, uh, there were a lot of things in there that I'd love to address, but since you asked me directly about what check marks one is, I mean, uh, you know, I I think check marks one is our response to everything that you said. And yeah, like, I mean, we can go back to the Toyota production system and, uh, and, and, and, you know, Kanban and, and how that's, you know, grown up and influenced agile development and, and the kind of march from DevOps to somewhat argue back to DevSecOps. Um, and, and I'll say that I was, I was talking to someone recently and he said, you know, I spent years as a DevOps leader, and I always thought DevSecOps was just a marketing term by security vendors, because we always knew that DevOps had to, it was, it was supposed to be everything, and security was a part of it.
Yeah. So, you know, as, as a guy who's out there now talking about DevSecOps, I think I'll, I'll at least, uh, say, yeah, like we're, we're, we know. But, uh, check marks one is still the response to this, right?
It's the response to that need that, uh, maybe security folks felt like, uh, well, that's nice that you included it, but we're not talking about it enough. Um, and you know, your reference to, you know, coders as, and developers as originally kind of craftspeople, I, I think they still are. And I think that what all the open source stuff and the kind of Franken code that people put together is because we're trying to refactor people's time on doing the craftsman stuff, where it's really, really important, uh, and we want security to still be a part of that, right?
So we want security to be a part of your software supply chain. So everything that you pull down from the internet, we wanna make sure that, you know, that code is secured when you build new code and you get time to do that. Craftsman, like work, we wanna be there.
Uh, you know, doing the analysis of that code before it gets into production and, and check marks. One is the response to those needs of taking all of these different types of analysis, right? Sas, SCA, das, API security, uh, container security, and, and building those engines, not separately, but so that they work together and that they can fit into your production pipelines, right?
Because if you're gonna do this effectively at scale, which is, which is really what large businesses need, they're trying to get all these developers, all these craftsmen who, you know, work on these little individual things to really, to make a big outsize impact. Um, we wanna fit into all of those production lines, integrate with everything that you need, and make sure that we're securing as much early as possible so that when things get to production there, you know, there are as few critical vulnerabilities as, as there need to be. So that's check marks one, is the response to that need for that to happen in the cloud for that, to make it easy for everyone.
Love it. So you opened this can of worms. Let's go back to the birth of Jeff SecOps.
com in, uh, when we first published it in March of 2014. We started in 2013, you know, planning and getting everything done like September, October, 2013. And, um, let's be clear back then.
So I came from the security world. I, I thought what a tremendous opportunity DevOps represents for security. There wasn't a thing called DevSecOps.
There was, there were proto like proto humans, you know, not Neanderthal, but Africans and some of the proto humans. There were things like Rugged DevOps. My friend James Wickett, who's now a runtime or drive run Securities, is his new company.
Uh, he started something called the Rugged DevOps Movement, right? And there was, you know, rugged as DevOps making it resilient. org.
Maybe we'll have Shannon on a show going forward. I, a good friend of mine, um, and she actually wrote the Manifesto for DevSecOps, right? 10 years ago, this May was the very first DevOps DevSecOps Connect that I did at the RSA conference in partnership with my friends at RSA.
Um, and the idea then was when we first did this 10 years ago, again, DevSecOps ops, it was funny, the security people thought it was full of crap. John Jonathan, right? 'cause they said, oh, nonsense.
No one cares about security. And the, and the developers thought it was full of crap too, just a marketing term. The true DevOps people like my friend John Willis and, and Patrick dubois, who coined the term DevOps and, you know, the, uh, Andrew Clay Schafer, and, you know, the Damon Edwards, the, the, the founders of DevOps.
They felt, of course, security was part of DevOps. DevOps encompassed all of that. But what kind of needy, whiny individuals or security people that they feel it necessary to stick check right in the middle of the dev and the ops, and they resisted it, right?
And when we first started doing these events at RSAI, that was my mission, to bring the security community to the, and the DevOps tribe together. It's kind of mixing peanut butter and chocolate. And there was a lot of resistance.
Go ahead. I, Yeah, and I mean, let's, let's be honest. 'cause we're, we're gonna talk, we're gonna have a whole conversation on culture later, but like, yep.
From my perspective, that what you just said, well, everyone thought it was, everyone thought it was bs. Like both. That's kind of, that's, that's kind of part of the problem, right?
And that's why we needed to have it in there in the first place is because you can say DevOps always included security, okay? But DevOps started in 2009. It is 2025, and there is still a massive culture clash between security organizations and development organizations.
I was talking to my friend who, uh, you know, she was recently a senior staff engineer at an Amazon based company. And, and, and now she's often a, um, uh, in, in a startup again. Uh, you know, but, but they were saying like, you know, the security people want it so secure that like, well, we're just gonna unplug everything, right?
Right. And developers like, well, I still need to do my work. And that requires things to be turned off, right?
And, and if we're still there where we have this, this big culture clash, which is fine. And again, and I say this all the time, like, developers move fast and break things. Security people don't ever let anything break.
And if we can't start coming together as, as distinct disciplines and working towards the goals of the business, not just our own individual metrics of like, I've tracked this many vulnerabilities so that I can buy more of this software and secure this, right? And developers saying, well, I'm not meeting my development milestones, so I'm gonna skip this step and I'm gonna meet my development milestones. If, if we can't work together and have the business align us on goals of what producing secure software at a rapid pace looks like, then we still need to be talking about DevSecOps and talking about DevSecOps maturity and where you are.
'cause like that the, the cultures have to find a way to come together. We can't just have security being the department of No. And we can't have developers being like, oh, they're all 20-year-old yahoos.
And it's like, they're not like, these people have been doing this for 30 years. Like, come on. So, absolutely.
So let me, let me give, let me spread the good news today. Like it's Sunday and I'm selling Watchtower or something. Um, the good news is we've made a tremendous amount of progress, Agreed Over the 10 years I'm doing this thing at RSA, which we're doing again this year at RSA in May.
Check Marks is a sponsor of it. They'll be there, I think they're on one of the panels even, uh, at, uh, Toby, the chief product officer, uh, check marks is, is on one of the panels, um, co. But anyway, people recognize that DevSecOps is a real thing that you need.
The second DevSecOps even more than that, when you look at the leading DevOps platforms in the world today, companies like GitLab and Jfr and Harness and CloudBees to name a few, they don't even call themselves DevOps platforms. They call themselves DevSecOps platforms because they recognize how important security is. So we have made progress.
I have a more nuanced view of it today than maybe you, Jonathan, or what you've said so far in that I think what we're seeing is under the maturation of DevSecOps, we've learned some lessons. Developers are not against developing quality code, but they're never gonna be security professionals. A hundred percent agree.
Yep. And I think one of the mistakes that our DevSecOps industry has made is giving security tools to developers. We need to give developer tools to developers that help them do better security, right?
Because they're never gonna truly understand the, the nuances of the CVSS rating system or something like, you know what I mean? One of these kinds of things. Yeah.
And that, so again, we talk about Check Mark Swan, bringing it back to that. That's one of the beautiful things about that is, right, creating a, a platform that developers can use and feel comfortable in without having to be a security pro, but also having an aspect of it that the Security pro can use to get their job done as well. And again, these are things we're gonna explore.
I wanna explore shift left, have we over shifted? I wanna explore how platform engineering has kind of come in on top here and said, Hey, let us work with security to set up the guardrails so that those developers can just go faster. We, we do do the platform engineering show, right?
Of which you, you've been or guest on there and Check Mark's sponsor. We'll be discussing more of that on there. But we, you know, we'd be wrong if we didn't include it in, in here too.
Um, and I think, here's the other thing. This whole, uh, software pipeline security, right? Software supply chain security, that's part of DevSecOps too, right?
It's a huge part. The SBOs, everything else. And here's another thing I'm seeing, John, and I'm wondering if you see this too.
We're starting to see people say, Hey, we gotta expend extend DevSecOps past the deployment horizon, right up till now. DevSecOps, it, it was like it hit a black hole when we deployed, right? No light escaped to the other side.
Well, no, there's life after deployment, right? For apps and the security after deployment. And that has to be tied into your DevSecOps too.
So I, another thing that I'd like to see us discuss, what else would you like, think we're gonna cover, Sean? Well, um, see, we're gonna talk about culture. We're gonna talk a lot about security education, because, you know, while you said that, so look, everything you said about making security tools into developer tools, I completely agree with you.
I think I even said it at Techstrong Predict, uh, that, you know, that's, that's the goal. Um, but I wanna talk about security education. I wanna talk about how it's working, uh, because it is, we just did, did a survey of 1500 developers Yeah, sure.
Working or not. But at least the developers who are out there seem to feel like it's working, and maybe security needs to change the way that it speaks to the market. And stop complaining that they don't teach security and secure coding in as part of, you know, a university degree and say, okay, well, amen.
We're, we're, we're doing it. So let's start speaking differently to developers about security. Right?
I agree a hundred percent Again, that, that ties back to culture. So like, I think that the overarching conversation that we're gonna have across every single one of these meetings is the culture. And it's gonna be like the culture around integrating properly, around metrics, around security education, around matching the velocity of security to the velocity of development.
Um, you know, about security champions programs, all of these things that we're gonna wanna talk about throughout the course of this show. Uh, I, I think it's, it's all gonna tie back into culture and how we learn to continue working together and, and agreed, you know, security goes beyond deployment. That's why check Marks one partners with, uh, with folks like Wiz and, and, and with Cystic right Runtime partners.
So agree. Like we need to be looking at the whole software life, life cycle as developers look at the software lifecycle. Agreed.
Agreed. Hey, you know, what else though, for people watching this, are you a DevSecOps person? Are you a DevOps person?
Are you a developer? Are you a security? Would you like to be involved?
Perhaps be a guest? You have a point of view. It's not just going to be you and I talking every week, Jonathan.
We're gonna have hopefully a panel every week of at least 3, 4, 5 people. Not every week, every other week. I think we do this.
Um, but every show, and we're looking for people. So if you have some thoughts and opinions and everybody has an opinion on, uh, DevSecOps and DevOps, write to us. com, or reach out on LinkedIn or wherever you can reach me.
I'm pretty accessible. So you could reach out to us there and we'll, we'll entertain any and everyone who'd like to come on here and, you know, have a thought o on, on what we're gonna say. You know, what else, John?
I'm really proud of us. We're on now. Oh, a good 15, 0, 25 minutes.
We haven't mentioned ai. What about AI at DevSecOps? We'll, we'll talk about ai.
And you met, you mentioned, uh, Patrick Debar earlier, but he and I had a, had a long conversation about AI that you can find somewhere online, probably on our website, uh, as well. Um, but yeah, you know, ai, uh, we're gonna talk about AI in a bunch of different ways, right? 'cause there are, there are lots of different ways of looking at, which is like, how does it help developers code faster?
How does it help them do security faster? How does it help se security engineers to, you know, tune their products faster? Um, and then what does it mean for the software supply chain?
You, earlier you were talking about, uh, code and, um, and, and downloading other people's code and how that needs to be scanned. Well, but now there's hugging face and there are all these LLM models. And you know, we've got a guy on, at our company s who's one of our lead researchers, and he's done a demo of like, here's how you poison an AI model, and here's what it looks like, right?
Gimme a recipe for, you know, pasta Alfredo. And one of the ingredients that gives you is rat poison, right? When he, when he does that, well, he's got poison this model.
So there's, you know, if, if, if companies are building their own LLM or they're looking to build off of an open source, LLM, what's the security of that? Who's gonna scan that? Who's gonna know whether or not your model is poisoned?
So like, there's, and, and I don't mean to ramp up the fear factor 'cause that's obviously what security folks typically are, are known for doing, or at least accused of doing. But it's, it's a concern. AI is now a supply chain concern in addition to all of the ways that it can be helpful.
So we'll totally talk. And like everything else, it's the duality, right? Light and darkness.
Uh, it's always there, man. Every technology, you, you get it, it's new. It does something cool, and there are risks, and that's just life.
I always say this is why we can't have nice things on the internet. Um, but we do have nice things on the internet in spite of all. And, and, and, you know, again, I I, I've wanted, take a positive view of this as a result of DevSecOps, our code today is much more secure, like the apps you're using today.
And even though you may be updating them daily, weekly, monthly, whatever, they're much more secure today than they were before DevSecOps. I, I think we have made tremendous strides in, in releasing much more secure code. Yeah.
So, Agreed. That agreed? Mm-hmm.
All right. Hey, that's gonna wrap up our very first version here of the DevSecOps Show. Cracking the code.
We're gonna be back in two weeks with a full on panel. Jonathan, let's tackle culture right outta the bat and talk about the DevSecOps culture on that show. Um, you can catch this show on Text Drunk TV and the Tech Strunk TV network.
So it'll play on Tech Strunk tv. It'll be streamed to LinkedIn and Facebook and X and YouTube to our tech Strunk tv, YouTube channel. It'll be available on the Techstrong TV website.
com, security Boulevard, cloud native, now, tech Strong, AI tech, strong it, and digital CXL. Um, additionally, audio versions of this will be available on Apple Podcast, uh, uh, Spotify podcast, Stitcher, and all of your favorite podcast platforms. So if you prefer listening to audio while you're running, exercising, whatever, driving, you'll be there for you too.
Um, Jonathan, I'm, I'm pumped. I can't wait to get cooking with this. Yeah, I'm, I'm excited too.
I think it's gonna be a great series, and I appreciate you and the organization for hosting it. Looking forward To it. Absolutely.
Absolutely. All right, until next time, then that's a wrap on episode one of the DevSecOps. So DevSecOps show, little tongue twisted there, DevSecOps show cracking the code.
We're out everyone. Thanks very much. Thank you.
You've spent all of your money upgrading your wifi gear, but for some reason, things don't seem to be going faster. It doesn't matter if it's at your house or at your office. The numbers just aren't adding up in this episode of the Tech Field Day podcast.
Is wifi fast enough? Welcome To the Tech Field Day podcast, where we bring together a group of influential IT experts from across the industry to discuss a single idea about key concepts. This podcast features a variety of perspectives from members of our Tech Field Day delegate community, and we often recorded it in association with one of our events.
In this case, our upcoming mobility Field Day Tech Field Day is a part of the Futurum Group, and this podcast is also published on our sister side at STR Techstrong tv. In this episode, we're gonna be talking about wifi, but before we get to that, I'd like to take a moment for our guests to introduce themselves, starting with Keith. Oh, hey, name's Keith Parsons.
I, uh, produced A-W-O-P-C conference. The Wireless and Professionals Conference as well have been doing wifi for, oh, more than two decades. So this, this is gonna be fun.
Hey, I'm Rocky Gregory. I'm principal architect at eTech. Previous to that, I was global director of Wireless for Nike.
Thank you, Tom. I'm Ron Westfall, research director here for Communication Networks at the Futurum Group. Alright, well, thank you all very much for joining us.
Let's jump into the premise for today's episode. No doubt you've gone into a store recently and been overwhelmed by the amount of choices that you have when it comes to wifi hardware. Sure.
The wifi alliance has simplified it by adding numbers like six, six, e, and seven. But what you're really interested in is the other numbers on the back of the box, the throughput numbers. Is this gonna be the magic device that allows me to stream my movies even faster?
Is this gonna be the thing that allows me to download those files off of the internet even quicker than I possibly could have? Well, the answer is probably not, because as it turns out, wifi is fast enough. All right.
Before you start a play more in the comments, because I've actually been involved in one of those before when I said that the new, uh, radio in the MacBook M1 was fast enough compared to the, uh, radio in the previous generation, even though there was only a hundred, uh, megabits per second difference in the two. I think we need to kind of start off by, by letting people know that, you know, the wifi speed that you see on the back of the box isn't exactly the wifi speed that you're gonna get from the access point. I'm gonna leave it to my experts out there to maybe explain to our audience real quickly, why is there a disconnect between those two numbers, the, the, uh, perceived throughput versus the actual throughput.
I, I'll, I'll, I'll start. That's it. That's a pretty easy one because, uh, marketing is the, is the actual answer.
Marketing likes to show really big numbers, and the numbers they use are not throughput. They're what's going on at the phi layer, the physical layer. So the bits are actually going fast, but a whole lot of the bits have nothing to do with carrying your payload.
So wifi has, uh, the 8 0 11 protocol. It's a lot of overhead built in, so you'd be lucky to get half of what the bit traffic is, is actual payload. So that's one.
Two, when they are marketing those, they take the best possible technique that could be used with that version. Say wifi seven with eight spatial streams. Well, clients don't have eight spatial streams, so your device will never reach the reach the level that the AP has on its box.
So they're, they're, they're good marketing numbers, but in reality, you'll never hit those numbers so that you shouldn't be looking at those numbers. You should be looking at what does your application actually need. And for this one, I'd like to just go back to a simple one.
Uh, the lowest slowest possible wifi today is six megabits. And that's, that's terrible. That's MCS zero.
It's the worst wifi you can have. And it's six meg, which is more than you need to send a YouTube video at 4K. So one user watching, one Netflix can work with the worst possible wifi.
So it's not really about throughput. I, I agree with Keith and I, I don't think it's unique to the wifi industry. I think marketing is out there across the entire industry.
So we can certainly look at, you know, the routing, switching vendors doing the same kind of thing, et cetera. And what I think is important here is, okay, what is the wifi industry doing to, you know, enhance what is realistically possible in terms of throughput speeds, uh, regardless in the environment, whether it's enterprise, consumer, uh, new deployment, uh, you know, a ground field deployment, et cetera. And one thing I wanna like, uh, shine a spotlight on is, uh, a couple of key takeaways that I saw from the wifi world Congress that was just, uh, completed out there in Mountain View.
And, uh, I think what's interesting is, uh, I've been having these conversations and many of them are wifi centric, but some of them are like, let's look at, you know, the network overall and what's needed. And yes, um, on interject AI here, because I think it will have a positive impact on what's needed. And that is improving really the quality of experience, uh, for a wifi implementation, you know, at home within the enterprise.
And this includes, uh, players, uh, such as, uh, Qualcomm, uh, media tech as well as ize. And what they're looking at is that because wifi is integral, you know, it's an essential connectivity technology for, you know, any, uh, experience that is the AI capabilities can actually improve what's going on at the edge that is implementing, uh, AI at the edge. You know, bringing AI to where, uh, the data is, if you'll, and as such, what I think is going to, uh, happen is we're going to see AI become an ally for improving wifi performance as well as quality of experience.
And, uh, that includes reducing the latency more, just having more intelligence at the edge to, you know, optimize what's going on out there amongst the access points, but also what's going on at the backhaul and o the overall network that is, you know, having more visibility, awareness, and intelligence as to what's going on, not just with the wifi portion of the network, but the overall network. Now that's simpler within, you say home environments, but the same principles apply. And so I think that's something that's important that this was getting, I would say, uh, a lot of not just, uh, technical, um, emphasis, but also again, that marketing emphasis.
And so this is gonna help the CSPs out there become, I would say, more proactive at being able to troubleshoot an issue with a, a wifi implementation or telling the customer, Hey, it's not your wifi, it's something else, it's your browser, it's your pc, and so forth. But just having more rapid turnaround and being able to do that and having, uh, just that more capabilities at hand to solve, you know, the, the problem at hand when it comes to performance. I think the other piece is that's an unloaded network that they're talking about when they put the number on the back of the box.
And especially in the enterprise, you know, when you're serving 50,000 clients on a campus, they aren't all gonna get that connection that they had at home. net, right? net, and the phone rings at the help desk.
The wifi sucks, right? So to Ron's point, there are so many pieces in between the user and Google and the user and Facebook, whatever they're going to, but in the end user's view, it's always the wifi because it's the, the unknown, right? It's, it's what they see ultimately is their entire connection.
So I think there's, um, the, the visibility throughout the network to Ron's point is absolutely critical. It's very critical within the enterprise where, again, there's this perception that if it's not as fast as it is at home, it sucks. Right?
com, whatever, to say, see, it's, it's, it's not what, what's the number that they're after? And they, and I, I, I had my ISP to my house came by and he's like, what are you complaining for? And I said, it's not that I'm not getting, I can get 300, 400, 500 some days.
net. They're hosting their own server, it's their upstream internet that's slow. And when you explain all of the parts to them, well, yeah, but, but you got this big number.
It's not about the big number. It's kinda like doing wifi surveys and say, Hey, it's all green. Yeah, that, that doesn't matter.
Just because you had a or a signal doesn't mean your WiFi's good. So there's, there's a lot of things we can do in a troubleshooting sense. One of the things that, that's a good, good answer to this premise we're talking about is how do you measure that quality of experience from the client side?
And vendors have been thinking about this for a long time, and they've realized there's a whole bunch of different parts. The, the wifi is just the, like the last mile. It's from the access point to your client device, but the entire network is being judged from the, and the consumer's standpoint.
So we need to have our tools that can look at the wifi portion client to ap, and then the AP through the switch fabric over to the WAN link, and then out to wherever the apps are. We need to be able to see all those parts. And one of the things that Ron was talking about bringing AI in is a lot of the vendors are now using AI to look at that, that really rich set of data they have collected from how long did DHCP take, how long did it take for a DNS query to come back?
Where is the latency in all those little hops and is it affecting an entire building or everyone off of one switch or off of one WAN link? And be able to help identify those problems sooner by looking at that huge set of data that they're collecting. Oh, sure.
No problem. Rocky, I'll just make a quick observation here. I think, uh, to Keith's point, and, and your point earlier, Rocky, about, you know, a network wide intelligence is that I think it's fueling the campus network as a service or nas, uh, use case.
And I think that was, uh, another important takeaway, uh, from the recent Congress, and that I think is being accelerated by players like Nile that have demonstrated, you know, uh, with, uh, demos like at late 2025 now that they can support up to 2 million square feet, uh, and also show, uh, you know, an implementation of a zero trust, security implementation along with, uh, the other, you know, built in, uh, benefits such as rapid deployment and having just that, that network wide awareness. And I think this is gonna help, you know, with, uh, the competitive, uh, mix that is, you know, help enterprises with campus or any organization with a campus requirement just have, you know, a more options out there. And yes, folks like Cisco and hp, Aruba and CommScopes, uh, ruckus, all these folks have, uh, these, uh, NAS offerings.
But I think that this is aligning with what we're talking about here. It's fueling, I would say, more interest in that use case. And I anticipate that we'll see more adoption of this approach to solve, you know, some of these problems that we're talking about.
Over to you, Rocky. I was gonna go back to again, the user experience piece and having that end-to-end visibility. You look at a large enterprise and there's the corporate code of arms.
I, am I in frame where it's your fault? No, it's your fault, and you've got a switching team, you've got A-D-H-C-P team, you've got a DNS team, you've got a WAN team, and you know, there can be finger pointing. Sometimes everyone's not holding hands and, and singing Kumbaya and, you know, for the wireless professional because we get the blame nine of 10 times.
Having that instrumentation in the network, being able to see it from client to end point and, um, being able to find those bottlenecks is, is absolutely critical today. It's the only way that you're going to be able to suss out in these more and more complex networks exactly where is that bottleneck, where are the issues? So especially in the enterprise and especially for meantime to innocence or, you know, to be nice to find the issue and work as a team and be able to fix it.
So I think it's, it's pretty mission critical to have that view at this point. And, and some of the new technologies that they're bringing to bear with, with not just the artificial intelligence stocking that data, but the ability to, to have synthetic testing that, that your infrastructure can switch roles temporarily and become a client and join and act like a, like a device collect data and report that proactively. So you don't have to wait until the end user's device fails.
You have a built in system that will test that, or in, in the case of some of the NAS providers, they have a digital twin, a full copy in digital form of the entire infrastructure that they can run tests against and, and solve the problems before they happen. So I like the proactiveness that's coming, and yet with all of this, we've been looking at RRM, the radio resource management, trying to solve the RF issues for 20 year plus years now, and it still has issues. So we're, we're, this is an ongoing problem, but it's nice to see that they're, they're pulling all the pieces together.
It's not just an RF issue, it's not just A-D-A-C-P issue that they have the ability to see in real time what's going on in the entire network. And RRM being broken has a title, Keith, it's job security for us, right? Like keep it broken.
I love being a wireless guy, but in, in truth, that complexity I don't think is really understood even within IT organizations end to end that radio frequency is actually really difficult. It's only about 20% physics and the rest is black magic, right? So you've, you've got a lot of moving parts that people just don't understand outside of the wireless community.
So having that instrumentation helps with broken RRM. Yeah, sometimes it's our fault, sometimes the baby's ugly, right? So it's, it's important to be able to suss all of those individual pieces out and um, to absolutely verifiably be able to say, Hey, we found a bug in the RRM.
And I think there's a key too that there's not just the, the infrastructure vendors, there are overlay networks, there are client-based solutions that give an even deeper view that can sit in the background of a client and run synthetic transactions, or you have something third party that sits and runs the synthetic transactions. And I think those are key force multipliers in the enterprise. And, and those features that you just mentioned can be automatic that when things are happening that they're actually just doing it without any IT person's involvement.
It's just there. And some of the new features that I really like in the, in this, this age of AI and RRM is that some vendors make a change to an RM algorithm implement it, and the value of whether or not it was successful is automatically calculated based on clients. Did the client see an improvement?
And if they did, that was a good choice, if not revert back to what we had before without any end user involvement. No, it stuff have has to be involved and then it's a self-learning process. And he took the words outta my mouth, Keith, what is going on that can help improve, you know, uh, these challenges and automation I see is making more progress.
And it's also not only specific to, you know, the wifi implementation, but I'm, I'm seeing, you know, the, at the, uh, CTO uh, level or the CIO level, the prerogative to implement automation across, again, not just the wifi and, you know, mobility network, but across the entire network. And that is, I think, uh, re uh, vig invigorating, uh, for example, intent-based networking, uh, principles, but also, uh, more attention as to, you know, how can capabilities like event driven automation can again, uh, compliment and reinforce, you know, that network wide visibility and observability that's, you know, folks like Cisco and HPE and Juniper are all, you know, prioritizing in terms of, you know, why go with them in terms of, you know, the wifi network. So I find it encouraging.
I think it's something that is, uh, bearing fruit, but also it's showing that, okay, we have to, you know, walk away from, you know, some of the silos in this case, uh, that have, you know, been a, a, a barrier for, uh, get just that, getting more intelligence about what's going on with the, the wifi part of the network. One thing that I wanna bring up here, because we've talked a lot about infrastructure, we talked a lot about making sure that this, uh, you know, experience looks like this for these users and, you know, uh, your use of speed test do net is like the ultimate, um, you know, arbiter of how quick a connection is is probably inaccurate. I I would go one step further though, in saying that the way that most people interact now with the internet has nothing to do with raw speed.
com online or, you know, firing up their favorite mail app or streaming through Netflix. And when you introduce that kind of barrier, you run into other problems. A, a good example is Netflix, right?
Um, the speed of Netflix is impacted by your connection, whether you're using a gigabit wired connection or you're using a, a wifi seven wireless connection. But what really impacts it is, um, latency in the network. Connection is the movie that you're looking for preloaded into a content network that is easy to fetch.
Uh, there there are things outside of the user experience that aren't printed on the back of the box that we have to worry about. And that's one of the things, uh, a recent article that I posted on Textron, it talked about user experience monitoring, which is one of the next big phases that we've been hearing about from, from wifi companies where they're saying, you know, we need to look at more than just the raw numbers in the connection. We need to look at things like retries.
We need to look at things like, um, you know, jitter in the connection. So are we, are we kind of hamstringing ourselves by focusing too much on that one number without giving our users that holistic expectation? Or do the users even care at this point?
I, I think it's the former. net example is how the end user sees the network, right? net, and they're getting that much of the picture of what's actually happening.
So it, you know, and they're making assumptions based on that. And I don't know that you can educate, again, a campus of 50,000 people, but you end up with 50,000 wireless engineers, right? Everyone's gonna tell you what's wrong with your wifi, the signal's bad, blah, blah, blah.
And to be able to go into a dashboard or to the points earlier, have AI pop up and say, you know, you, you've got a crappy connection here. Um, or to be able to go in and pull a report and say, you know, this was a great connection, but high latency, a lot of jitter in getting to Salesforce that day. To your point, Tom, Luckily though, the vendors know this too.
And so the vendors, whether it be HP or Juniper or Cisco, they're all working towards that holistic view. Um, but the whole idea that it's about speed is been a fallacy for a very long time, and yet we still revert back to that because it's just, it's a simple, easy little number. Um, one, one example I can give is at a, uh, airport, there was some people who wanted to download movies, and that's what you get off a plane, you wanna download a movie to go to the next site.
Yeah. Uh, and the airport authority wanted to throttle their connection because it's not fair. One person's taking too much of the bandwidth, and after multiple cycles of testing, it was stop with the bandwidth, just give them everything they want.
And when they ran the data, they found that if you, if you throttle it, actually you choose up more airtime. And it's the one thing in wifi we have the least of is airtime. And you used more of it by putting a bandwidth throttle on, just let them get as fast as they want.
If they can download a movie in three seconds, they get off the network and give you back your wifi, give you back your airtime. So I think we need to be looking at a bigger model that's not just the number, it's how did that number affect the actual end user experience in airport it is, give it to 'em as fast as they can take it and they'll get off your network. In hotels, it's something different.
So in each environment, we need to understand how the technology works, but also how to fix it in those situations. And it's just comforting me to know, to see the vendors are out there addressing this specific issue and they're looking at each of the parts and how to, how to tune the middle better specifically for Zoom calls, uh, WebEx teams, whatever. That's the focus of how do we make those go as fast as possible.
Keith's point, I think what is the good news is like for all of WiFi's challenges, the market is going to continue to grow significantly. And I think we understand, you know, some of the reasons why it's, uh, the, uh, ease of installation and, uh, relative costs compared to some alternatives out there. And I think we're seeing that, you know, with private networks, yes, they have a presence, they're adding, you know, more organizations, but usually they're being implemented in coordination with, you know, the wifi implementation that already exists.
So it's not like, okay, private networks are gonna replace wifi because wifi is well understood. It's, you know, the double that is known, so to speak. And, and if anything, most cases, something like a private network implementation will be a compliment to it.
And I think wifi just has more potential out there because, you know, circling back, you know, to, uh, the, uh, the Congress is that I saw a, a couple of important takeaways about, hey, can wifi halo be something that will make a difference for, you know, scaling these, you know, billions of iot connections out there and do it, and just that in an affordable and secure way. 3 kilometers now in open environments. And so I think that's something that will be, be a factor in terms of, okay, IOT connections don't have these performance demands they have for, you know, high bandwidth intensive applications, you know, like Netflix at the home, but you know, certainly, you know, workloads, uh, you know, at the, uh, enterprise environment.
And so, you know, being able to support, you know, 78 kilobits or, you know, at the very top level, 150 megabits, well, that's something that I think is driving, you know, wifi fis, uh, I would say, um, not just, uh, capabilities, but also, uh, favorability in terms of why it is this gonna get more and more consideration and implementation out there. And, uh, and the ecosystem, as you can see, there's more that goes into speed than just a number. It's the complex interaction of the technology that lies underneath.
And no user is ever going to be truly happy with everything unless it's instantaneous. What you have to do as an IT professional is create a balancing act. You need to invest your money wisely to provide the most utility for your users that you can, while also setting expectations that you are accessing resources that are not directly on your computer.
So you're gonna have to expect a little bit of delay. Now the thing you have to understand about that is, is that no matter what you tell them, and no matter how you try to convince them, they're still gonna complain that it's too slow. So maybe you can convince them that they can upgrade out of their budget instead of yours.
That will just about do it For this episode of the Tech Field Day podcast, I'd like to take a moment for our guest to kind of give you an idea of we're to find them. If you wanna learn more about subjects like these and the other things that they talk about, Keith, where can people go to learn more about your writings? com.
And on the other social media, I'm Keith r Parson, I'm at Bionic Rocky on all of the social stuff, and bionic rocky do com. Thank you, Tom. Naturally, there's LinkedIn under, uh, my namesake Ron Westfall.
In addition on XI could be found at r Westfall DX and Futurum Group. Uh, please visit the website futurum group, uh, do com. Not only does it include the most valuable tech field day, uh, content, but also our future research and future intelligence content, which includes, uh, for example, AI data sets, et cetera.
So that's where I can be found. We wanna thank each and every one of you for listening to this episode of the Tech Field Day podcast. If you enjoyed this discussion, please make sure that you subscribe on YouTube or use your favorite podcast application so you don't miss an episode, and consider giving us a rating and a review because that really helps people as they're searching out new, uh, podcasts to listen to.
This podcast is brought to you by the Tech Field Day Group, which is a home of IT experts from across the enterprise, which is a part of the Futurum Group. com/podcast or view us on Techstrong tv. Thanks for listening, and we'll be back with another great episode next week.