Techstrong TV – September 26, 2023

Hello everyone, and welcome to Techstrong tv. Today's Tuesday, September 26th, and I hope y'all are having a wonderful day so far. I'm your host, Willie Willis, and in today's show, we're gonna bring you some fantastic interviews with incredible guests from around the world.

So, without further ado, let's get the show started. com is the number one online destination for DevOps education and community building. com covers all aspects of DevOps, including DevOps, best practices and tools, DevOps culture, SecOps, business impact, continuous testing, continuous delivery, and more.

com has the largest collection of original DevOps content, featuring breaking news, blog posts, podcasts, and more. com to learn more. com.

Where the world meets DevOps, This is Techstrong tv. Hi everyone, welcome back here to Tech Drunk tv. Have another new company and a new person here on Techstrong tv.

To introduce you to, I'd like to introduce you to Roni Dover. Ronnie is the Chief Technology Officer for a company called dma, D I G M A. And Ronnie, welcome to Techstrong tv.

It's nice to have you on. Hey, Alan, great to be here. Thanks for inviting me.

Thank You. So Ronnie, you are the, uh, c t O for dma, but let's hear, let's hear a little bit about your journey, your life journey. How did you come to be here today?

So I'm a developer, uh, by background for more than 25 years. Um, I kind of couldn't quite pick between product management and development throughout my career, which was kind of my personal tragedy. So whenever I was a developer, I couldn't stop thinking about the why.

And whenever I was a product manager, I was kind of mourning my time away from the code. Uh, but to kind of find different, uh, ways to, to bridge the two. Um, and kind of what got me to DMA was the, the fact that I, as, as a developer and a product manager, I was kind of noticing the developers have much less feedback than product managers.

And this is kind of what got me to notice a lot of things about the development process, um, and about why it's, it's really critical for developers to understand their code better. Absolutely, absolutely. And you know what?

CTOs are great for someone with the dilemma you have. CTOs gives you the best of both worlds a little bit. Let's talk a little bit about DMA, though, a little background, a little history.

Let, let's hear a little bit. So DMA was founded about two years ago. Um, and the concept was we wanted to create the first continuous feedback platform.

Now, continuous feedback is, is a new type of idea within software management. And the idea is that you want, um, as much feedback as possible as a developer about your code, um, in order to prevent and uncover issues before they even occur. Uh, so you can think about it that way, that today we're kind of at a juncture where as the phrase go goes, we have the technology.

So we, we know how to collect a lot of data about the code, um, about the runtime, about how it behaves in real environments, about how it behaves on my machine. But what was frustrating me to the point where I was starting to pull out hairs and frustration was the fact that developers were using none of that. So yes, the feedback that we know as developer is debugging, uh, and maybe running tests, but even with tests, we're using a very limited subset of the data that they produce, which is basically the pass fail.

So a lot of things get, uh, kind of, uh, go, go unnoticed. Um, and I think couple that with the fact that developers are kind of, or in organizations are very forward-leaning and everybody's thinking about the roadmap and nobody's kind of listening to that feedback. And you get a situation where we were trying to accelerate releases, but essentially to me it appeared like sometimes we were just throwing features over the fence at the higher velocity instead of really creating a learning process.

And, uh, I actually found this quote recently by Kent Beck and he said, you know, optimism is an occupational hazard of programming and feedback is the treatment. And I just came by that like two weeks ago, and I was, it, I'm really hit the nail on the head for me because this is, I think exactly a part of the problem. I love it.

And it's exasperated by other trends, uh, that we're seeing in the industry, which is LLMs, for example. So, you know, I've just seen a study by co-pilot that said, developers write features 55% faster with ai. Awesome.

But then think about how much code there you have that you have even less visibility about what it does because it wasn't even written by a developer. So to me it seemed like it, it ha there has to be much more visibility for developers so that they can have confidence in their code in LLM produce code and other, uh, people's code, legacy code. All of that needs to to, to be clear to them.

And this is kind of where Dig McKay comes into the picture. So I, I would put forth the proposition, it's not just developers, but the ops people want to have confidence in that code too, right? There was a time, you know, the old, the old saying, right, it ran on my machine.

Uh, well that's great, but it didn't run on the server and it didn't run in production and, and that's why you developers make us crazy, right? Some ops people still have that attitude. And, and now with, with the introduction of, of, you know, generated code, machine generated code, uh, it's even more so.

But you know, Ronnie, I saw an interesting stat the other day. Something like 42% of all the code in GitHub has Gen AI fingerprints on it. So either gen AI generated the code, check the code helped with the code, there was something to do with AI in, in, in that code.

So that means almost half of our code today right, is being touched by this. And, and so I'm a glass, the glass is half full kind of guy. I think that's not a bad thing.

And I think as AI becomes better at generating code and doing code and checking code, it'll allow us to do so much more faster. It's gonna make developers so much more productive. I'm not one of these guys who think we're gonna put developers or testers or anyone outta business.

I think it's gonna make us more productive, but we're gonna generate so much more code. I would go one step further that developers that don't adopt gen I will fall behind. And organizations that don't use gen AI to get more team productivity will fall behind as well.

But the question is, how do you offset that with the right guardrails? So, you know, throwing a gen AI at every problem will produce code, but it will eventually collapse onto itself because you won't have, uh, the right measures to understand whether the code is good, is it bad? And what happens in these kind of situations.

And lack of feedback in general is something that I've experienced firsthand in my team. I call it B d D, and I'm not talking about behavior driven design, uh, something that many developers are familiar with. It's bug driven development and just that just means that you keep having bugs in production.

You keep running back to try to find a cause. And when you talk about observability and all of these nice things, you're just saying that you're trying to troubleshoot things that have already occurred and kind of the team is running after its own tail trying to, um, to, to solve all of these issues instead of really being productive. So in order for that to work, we need to kind of break that specific equation and introduce a lot of AI generated code that's awesome into the code base, but also make sure that that code is kind of, uh, fitting the organizational way of doing thing, that it aligns with the rest of the code, that it doesn't introduce issues, that it's scalable, different things that, you know, when you enter a prompt, you're not guaranteed that the code beyond may be working something that you also need to test will de deliver on.

Fair. I think that that's something that that's really, um, um, kind of made a a lot more pronounced with, uh, gen ai. And then the other point you were making is also, I think amazing because this is where there is a lot of asymmetry between developers and the rest of the teams because SREs, uh, DevOps, um, it, all of these teams have amazing feedback and observability.

They have dashboards and service levels and uh, SLAs and, uh, SLOs and all sorts of, um, kind of, uh, gouges and graphs that they can look at, and they're on top of it. Where the gap begins is when you cross over to the dev team because you have all of that wealth of information and you know, I've been to many organizations where yeah, they had all of the major APMs and that's amazing. And then you ask the dev team, are you actually using that when you're developing?

Not when something is wrong and you're trying to, to run after a problem. Are, are you testing your code the minute after you deploy? Do you check if your code ran and can you know if it improved things or not?

Um, and, and the answer is always no, because it's complicated and it's very reactive, like who has time to chase after a dashboard and so on. And what we try to do was to create a developer platform, um, one that is free for developers, and that is integrated into your I D E. So it's in your field of vision.

So the concept is that you can look at any function in your code that you just wrote and see, um, how does it measure up? Do you have any obvious issues or code smells or anti-patterns, query issues, security problems, different things that we can detect right away, and how does it perform in the different environments? What did my tests tell me about this new code and how it affects the system?

What does production tell me about this code? So having all of that information, just one click away and having these critical insights visible and in my field of vision so I can, it's kind of like a living documentation that's bound to the code. And only by so doing, we manage to actually get developers interested or, uh, in, in that information.

Because if you talk to developers in the vocabulary of SREs and DevOps about service levels and, uh, it doesn't really match up or, or it's e it's hard to very quickly map it to my code, which is what I know as a developer. Yep. You know, I, I was at a conference last week, uh, for Jfr.

Mm-hmm. And that was something that was discussed here, which is, you want to call it shifting further left, or, you know, we had GI ops where people were doing ops and Git and so forth, but now developers want tools inside of their I D E. Mm-hmm.

They want to check the security of code in the I D E. They want to see is the code working tested, whether it's generated third party additional code, you know, a APIs, whatever you're bringing in, you're introducing to the code. The, the time to see if it works or not is in the I d e, not, not at testing before deployment.

Not to say that you shouldn't test before deployment, but it's where the idea is where the action's taking place today. Mm-hmm. Right.

And, and so this is in line with everything else we've been hearing. So Ronnie, let's, let's talk kind of nuts and bolts with D then. So it's a platform that integrates into your I D E.

Mm-hmm. It's a hosted platform like SaaS or is it, how, how does that work? So the way it works is you install it as a plugin into your I D E.

We we're currently focused on the intelligent ecosystem, uh, but we'll expand from there. Um, and once you've installed it, it's a standalone, uh, thing. So no data leaves your premise.

You're right now running in your own id. DMA is, um, kind of completely running within your local environment. And we did that on purpose just to minimize friction and make sure that, you know, you don't need to worry about any data, uh, PI issues, you just own all of your data.

Um, so the kind of time that it takes to set up is two minutes. Uh, you basically download the, again, it, uh, configures all of the components. And then the other thing is there, there are no prerequisites in terms of existing observability to the project.

Like DMA relies on OpenTelemetry, which is amazing technology behind the scenes, but it take cares takes care of all of that on its own. So you can start any project, even one that doesn't have OpenTelemetry yet. Uh, just installed stigma.

There is a nice toggle button that says Enable observability. And once you do that, it'll automatically start collecting information about your code and then doing the data science to analyze it and to, uh, give you the results, which is basically as you work, you can see what the code you're introducing, uh, how it performs, uh, uh, detect any errors, issues, um, uh, different types of, uh, code, anti-patterns and so on. Excellent, excellent.

Ronnie, I don't know if we mentioned the website. Yeah, so we, we, our website is, uh, DMA AI and can go there to get DMA right now. But on September 26, uh, we have a big release where we're actually, uh, officially releasing the product and, uh, um, we're going to have a couple of, uh, great, uh, surprises as well that day.

So, uh, that's, uh, that would also be a great, uh, day to follow us. Excellent. That, that is, um, Ronnie, this is exciting.

You know, this is, again, a big, sounds like a company that's made for this new age we've been dealing with, and, and the fact that users OpenTelemetry and so forth is, is fantastic. I wish you most, a lot of success with dma. Come back and keep us posted about what's happening here.

Okay. Thank you so much. It Was my All right.

Roni Dover, chief Technology Officer dma, check it out if you're, especially if you're a developer, this could be just the ticket you're looking for. We're gonna take a break on Tech Drunk tv, we'll be right back. This is Textron tv.

Hey everyone, welcome back here to Textron tv. I'm really happy to introduce you to our next guest. It's his first time with us here on Text Strong tv, and it's kind of the first time we're gonna introduce you to his company.

I'd like you all to say hello to Zach Wasserman. Zach is the co-founder and c t o of a company called Fleet, f l e e t. com.

Hey, Zach, welcome to Tech Trunk tv. It's nice to have you on here, Alan, thank you so much for having me. My pleasure.

So Zach, before we jump into Fleet and, and all that you guys do, and, and there's a lot here, let's start with kind of the Zach story, right? Share, if you don't mind, with the audience, a little bit about your journey. Sure, yeah, absolutely.

So, I mean, I, I was a child of the nineties, born in, born in 1990, and I grew up in the, in the Bay Area near Silicon Valley, seeing the stories of, of tech and things like Google blowing up. And I was a young nerd reading the newspaper and who liked math and stuff, and somehow got the idea in my head that I wanted to get into computers. com crash happened, I think I was still too young and immune to, to notice the ups and downs, but the idea of working with computers really stuck with me.

And so I, you know, I ended up studying computer science in university, dabbled in cybersecurity a bit, working with some really, with a really interesting professor, uh, at Matt Blaze and some, some grad students doing research on radio protocols that, that federal agencies were moving towards. And we found all sorts of ways to break them. And, and that got my, my taste wet into cybersecurity.

Um, so it was, it, it was both, you know, a desire to work with computers, to do entrepreneurship, and then to figure out how to kind of, uh, build and, and understand and break things as well. That kind of brings me to where I'm at today. Very cool.

com days and got the scars to prove it. Um, and it's interesting back then, you know, we didn't have cybersecurity programs in college or high schools or anything, and most of my friends who were in security got into security in one of two weeks, either. They were kind of drafted, they were network people and back then network security was really network security or endpoint security, that's where you were.

And, and so they were network people who wound up doing network security or the, the, the real good hacker dudes were people who just got off on breaking things, right? They wanted to understand how to break things and then how to build it back so it wouldn't be so easy to break the next time. Right?

And, and I think that is, that's like core critical to, to the whole security mindset right now. We call it cyber to the whole cyber mindset, right? Is, Hey man, I, I like trying to figure out how if things could be broken and if so, how and how can I make 'em better?

So, you know, I I think you're a good company there. Um, you were very involved also in the open source community though, correct? Yeah, that's right.

And open source was always something that, that fascinated me. Again, as a child of, of Berkeley, California and, uh, you know, ha having some, having some not, let's not say radical parents, but living in a place that was fairly radical and the idea of open source and this kind of mixture of, of capitalism and communal effort together was always something that really fascinated me. And, and that's, you know, that's really become the story of my career is finding that open source is a way to kind of link narratives through across different companies across different kind of economic interests.

But being able to bring that impact across that whole journey has been so exciting. And, you know, so I'm, I'm sure we'll talk about it in a minute, but it that the journey really started at, at Facebook as I got to start work, I helped create OSS Query, which we open source there, which the plan was immediately to open source it, and we did within six months of creating it. And, you know, that's a project that's been now open source for almost 10 years and been the foundation of my career across a bunch of different endeavors.

Very cool. We're gonna talk a lot about OSS Query as, as it relates to Fleet as well, but let, let's jump, let's jump a little bit into Fleet, right? Um, tell us, you know, I mean, you're one of the co-founders, you're a C T O give, give us kind of the fleet story, the background here.

Yeah, I mean, the story of Fleet is, is really that, that Fleet was something that I originally helped build at my prior company Collide. And we built Collide Fleet and we released it open source as we kind of pivoted towards building a SaaS product that was a bit of, of a, a different product, but we thought people are, would be interested in Fleet, and Fleet was an OSS Query manager essentially. So OSS Query is a piece of software that runs on endpoints.

So Mac, Linux and Windows computers and reports information about what's going on. We built essentially a management server so that you could, you could configure those agents, you could collect the data coming up from them, and then we just kind of released it open source and abandoned it in some sense. But the amazing thing, and the thing that really drew me to it was people started using it and as Kali kind of pivoted through various ideas in my eyes, people weren't using that stuff so much.

And I was always really excited about, about doing things that people cared about. And so I got drawn back towards this open source project, which again, you know, is kind of really caused me the concepts around that. And so I ended up kind of working on Fleet as the sole developer after I had left Collide.

I was kind of like the, the, the one man band running an open source project. And then in 2020 I was approached by SSID C Brandy, the c e o of GitLab, who's now working on, uh, you know, of course he still runs GitLab, but he's also got his open Core ventures now, and he's looking out for open source maintainers and saying, let's build companies around this. So essentially that's what, that's what SSID came to me and said like, Hey, let's build a company out of what you're doing with Fleet.

And he connected me with Mike McNeil, who's now our c e o and my co-founder. And we started building, you know, from the one man band up into a, a real company, figured out how to kind of build a business model around this that was different than the consulting model that I was working with on my own. And, and, you know, three years later, a almost to the day, I think it's, uh, you know, uh, it's a week from Monday is our three year anniversary of, of starting working on this.

So three years later here we are. That's great, man. Congratulations.

So it, it sounds like sid's, uh, open Core Ventures was the kind of the seed money on this. That's right. I, I thought you guys had raised, and, and I don't remember, I go through so many of these man, there were some other investors as well, though.

There was a round that was done. So there was, so it's a, it was a pre-seed, if you will, with ssid. Mm-hmm.

And then we raised a, a series, uh, or a seed, and then a series A later with C R V. So they are Oh, very cool. Are C R V and, and Reed Christian at C RV are, are now our main investors.

Uh, and SSID continued to participate as well. Great. No, SIDS and Fred.

Awesome. Yeah. Oh yeah.

Yeah. Uh, and SSID has been a great mentor to us. And, you know, for folks who are out there who are interested in, in company building, the, the GitLab handbook that's public out there is such a wealth of information and it's something that we've modeled so much of the fleet company off of what SID'S done at GitLab, and it's incredibly useful, incredibly inspiring.

And again, like that transparency I think is just so refreshing and so interesting and hearkens back to the, the spirit of open source in my eyes. Yeah, no, it's, it's literally an open book, right? Uh, you know, we've been following GitLab pretty much since they came out.

And, uh, we've had sit on here many, not recently, but we've had sit on many, many times. Actually, Ashley Kramer from GitLab is doing a panel with us on our DevOps experience, virtual, along with a bunch of other DevOps c uh, CEO os. So it should be pretty cool.

Anyway, um, so let, let's talk about the relationship though, between OSS Query and Fleet, right? Because, you know, you spoke about open source and, and, you know, when you were a kid in Berkeley, I, I call that the, the, the, the Cathedral and Bizarre, uh, hit, you know, era of open source with Dr. Richard Stallman and, you know, all of that good stuff.

And then we, we kind of graduated from that into what I call Big Brother open source, where every open source project had a, you know, a big brother who, who really owned it and managed it. And unfortunately sometimes just for their own benefit, you know, they, they talked a good game about the community, but a lot of it was for their own benefit. And then of course, we, you know, now we're in what I call the foundation era of open source, where a, a lot of these open source projects are administered by like organizations like the Linux Foundation or Cloud Native, or, you know, there, there's many foundations out there, the Apache Foundation, um, and, and that allows, would be competitors to work together, right?

For the good of us, all right? 'cause that Rising Tide kinda lifts all boats and, um, fleet. And, and so the relationship between Fleet and OSS Query to me is, is kind of one of these new foundational error things where, Hey, look, you, you were there for OSS Query, you helped, you know, birth that, right?

You were very involved. It, it's part of LF now, isn't it? That's right.

OSS query. Yep. And so you were there helping maintain it and everything, and now we have sort of a commercial entity that is capitalizing.

I'm put, anyone can go start a company and capitalize on, on what's out there with it. But let, let's talk about that relationship. Is Fleet a commercial version of OSS Query or more in that open core model where OSS Query gives us, you know, these core functions that are part of the open source, uh, product project, and then Fleet is building on freemium premium type of functionality that rides on top of that?

Yeah, uh, it's a bit of both, I'd say. I mean, OS Query on its own is a very, very capable tool for pulling data from endpoints. And just as a quick summary for folks who don't know, essentially it exposes endpoint data as though it were a relational database.

And in fact, it actually uses SQL Light under the hood. So you have the kind of the full SQL light syntax to write queries there. But osquery is just the agent to really powerful.

It pulls a bunch of great information, again, across Mac, Linux, and Windows. But being able to collect telemetry on an individual system is really just a small part of the problem that security teams and IT teams are trying to solve. And so what Fleet does is kind of integrates the system across not just the endpoints, but also including a server to manage everything, a way to drive insights based on what we're, what you're finding.

So we've built like these higher level concepts on top of OS Query and on top of being able to operate individual agents very effectively and very efficiently on Mach on machines, but it's not enough. And so then, you know, as we move towards more solutions, then, then fleet builds things on top, like being able to pull a software inventory of the device, uh, from the devices that are connected, and then being able to identify which of those pieces of software have vulnerabilities, for example. And that's not something that Os Query does at all.

Os Query lets you on a single device, pull the software inventory essentially, but then there's so much more that needs to be done. And so Fleet layers that kind of stuff on top. And then, you know, fleet allows you to do things like specify organizational policies.

Maybe these are compliance policies, uh, based on frameworks, or maybe these are just security best practices that you wanna enforce. And Fleet will help you see across all of your devices and all your platforms. How is the compliance with those policies?

And again, OSS Query can allow you to answer those questions, but Fleet really provides sort of the higher level abstractions and the coordination across all the devices. So OSS queries, you know, was built to be efficient to be deployed to Facebook's production, right? And at one time was deployed, uh, to over a million, probably servers at Facebook.

Um, so that scale, It's Yeah, that, that, that scale and, and it's deployed, you know, massively at, at places like Apple and Google as well. Like, it's, it's really huge. Um, but those places have whole teams who can figure out how to turn a tool into a solution.

And in, in a lot of ways, fleet is figuring out how to turn this tool into a solution for anyone who's, you know, essentially a little bit smaller than your Apple, Google, Facebook. But certainly organizations with up to hundreds of thousands of computers that they manage are working with Fleet and, and using it to kind of drive those insights with Osquery. Yep.

You know, I, I think another thing where the market has really kind of changed, and I don't know if people's perceptions have caught up, Zach, is, you know, when we talk about endpoint management, a lot of people still think of like, you know, lower on the food chain or, you know, beyond the edge. Laptops, desktops, phones, tablets, those are endpoints. But we live in a world today where endpoints, they're not even just servers, they're instances, they're containers, they're APIs, right?

These are all, you know, all the many. And then, and then of course there's, there is I o T devices that, but that's kind like on point. But, so there's many, you know, the, when we say endpoint, we're not talking about desktop management anymore.

We're talking about, you know, if we look at our network and, and there's a core though, that core is often distributed as well, just about every node, it's almost node management instead of endpoint manage, right? We should, we should adopt that word or that term node management because there's so much, there's so many identities, there's so many, you know, more than just endpoints that we used to think about. Yeah.

In, in my eyes, any sort of individual unit of compute that can be accessed and controlled is, is essentially an endpoint, No doubt about it. Yeah, I mean, as of today, fleet and with OSS Gray focuses, you know, primarily on Mac, Linux, windows with some container support as well, and some Kubernetes support as well. We've also just added like a Chrome OSS extension that allows you to get some of that telemetry there, Chromebooks Mm-hmm.

Yeah. For Chromebooks. So, but I, but I think that, you know, mobile devices certainly are endpoints.

And, and I think that, uh, especially, you know, with the rise of containerization, you've, we've got like nested layers of endpoints as well, where, like a node that runs containers in a, in a Kubernetes cluster, for example, that's an endpoint. But then the containers themselves, I think are also endpoints, essentially. Well, you, you know, you know where this really, when I talk to the folks, like in the certificate space, like a Digi Cert or a Tigo or someone like that, you know, every single container has its own unique identify identity and its own unique certificate for the most part.

And, you know, then the numbers start getting crazy, right? I mean, you know, you wanna talk about hyperscale that it, it really goes up quickly. Um, where a million is at table stakes, you know, that's nothing.

I mean, so it, it's crazy, but you know, it, it is a, it is a, uh, it's a real issue that, you know, device management, fleet management, like the name fleet in your, you know, we, we think of that, or I think of that 'cause on mold of where it was in 2005 or even 2010. And it's a, it's a brave new world now. It's very different.

Um, speaking about that though, look, ai, everybody's talking about generator of ai. How, how, what, what's the AI story over at Fleet? How is helping you, just looking at it still hurting you?

What do you, what do you think? Yeah, I mean, fleet is focused on getting people the, the data that they need to make decisions. And we're not, we're not incorporating a AI into the fleet product as of today.

Like, we're really focused on continuing to get people the, the, the accurate and timely data that they need and to give them the capabilities to manage these things. And, and AI is not a portion of that. And I think that, you know, where we might find AI more in the future is, you know, fleet has also entered the space of active management of devices.

So through the M D M protocols on, on Mac, which we released this year, and Windows, which we will release by the end of this year, you know, we're, we're starting to get more active. And I think that there's, there's probably a space for AI to come in some and allow people to write kind of natural language and convert that into, uh, more structured queries about devices or configurations that get pushed to devices. But again, I think that we're, we're really focusing on, on the, the, the facts that, the facts of the devices.

And I think that that ai, you know, can supplement based on the actions there, but really it's gonna be that it's the ground truth that we wanna collect. And so AI is not gonna be a core part, I think, of, of what we do. What about in terms of security, though?

I mean, you, you guys are doing kinda like scanning and, you know, c v e, uh, kind of, you know, severity kind of stuff. I mean, I I, in, in talking to some of the vulnerability kind of folks, you know, they're using AI to kind of help them along there. Yeah, yeah.

And I mean, and I think people throw the word AI around, uh, all, you know, all over the place these days. 'cause it's, it's hot to use. And certainly I think if you're looking at a vulnerability management program, like you want to probably be able to do some correlations to understand the risk, uh, that that is implied by a vulnerability being present on a device or that kind of thing.

And I'm not sure, I, I'm not sure that it's, you know, quite these, this generative AI, large language model kind of stuff is really gonna drive the right, the right insights there. I think that's probably actually more just stepping back to the sort of the more fundamental, um, you know, earlier ai MLOps, kind of like machine learning, AI ops kind of thing. Yeah, I think it's, it's really more the fundamental stuff and finding the right ways to put those primitives together to assist humans in their prioritization kind of efforts, that that's the thing that's gonna make the most impact.

Very cool. Um, I'm just trying to make sure we covered everything in here. com is, is the website.

You guys are also obviously as part of OSS query that it's out on GitHub, thousands and thousands of stars people can get in there. Do you find that most of your Fleet DMM customers are people who've already, you know, they start with OSS Query, certainly they would dabble with OSS Query and they'd say, Hey man, this might be a little bit, you know, I'm ready to move on. So I, I, you know, I, I had friends in cloud based, for instance, who had started the Jenkins project, right?

They got it down to a science where they knew when like an open source Jenkins user was ready to migrate to the, you know, premium CloudBees version. Yeah. Do you have a similar kind of thing between OSS Query and Fleet?

Yeah, I mean, I think that we're the really obvious choice for the, the product category, if you will, which is very niche of, of OS Query Fleet Manager. Like we've been doing that, uh, or essentially, you know, the Fleet Code base and the Fleet projects has been doing that longer than anyone. And that goes back, you know, three years before the, the founding of the company to back to six years.

And certainly in the first, uh, year or so of the existence of, of Fleet as a company, our customers were folks who were already using OSS Query and were using it for fleet management. And I think that as we've been evolving and as we've been like, we, like I said, moving to these sort of higher level abstractions and driving more at, at solutions and not just tools. We are getting more people who've heard of Osquery and think it could be useful in their organization, and they just will do their initial deployment with Fleet.

And then even people who don't even really know what Osquery is, and they just know that they have challenges relating to configuring and managing and retrieving telemetry from devices. So there's definitely, in some sense, there's like a chasm crossing that we're making here where we move out of the, of the really niche, the really powerful niche and important niche for a lot of people, but into something that's more widely accessible and more digestible for folks who don't have that background on, you know, what is always query and, and why should they care. And I think that bodes well for the company, right?

Because it kind of breaks you out into a whole new funnel, if you will. Anyway, Zach, we're way past 15 minutes, but I enjoyed talking with you, so I figured we, we'd keep it going. People.

com to find out more. Zach, we wish you lots of luck with Fleet and keep us posted and, uh, we'll, we'll be following we're fans. Thank you so much for having me, Alan.

Zach Wasserman, co-founder, C T O Fleet here on Tech Trunk tv. We'll be back in a minute. Cloud native now is the web's leading resource for the growing cloud native ecosystem.

com is your destination for news, thought leadership, features and webinars on cloud native architecture, Kubernetes, serverless, cloud native application development, microservices, service mesh, cloud native security, and more. Stay on the cutting edge of modern application development at Cloud Native. Now, This is Textron tv.

Hi, and welcome to Textron Research Review. My name is Mitch Ashley. I am principal and general manager, also founder of Textron Research.

Glad you've stopped by to check in, see what's happening. You know, you probably can't turn left or right without hearing or reading or seeing something about the, uh, assistant announcement of acquiring Splunk for 28 billion. And of course, you know, we've all got, uh, interesting thoughts and comments about it.

When, when I heard about it, read about it, et cetera, we immediately went out to kinda see what the executives were saying. Um, and there were several things that jumped out to me. So a lot of people are talking about, is this the, is this a sign?

Things are turning around. There's gonna, we're gonna see a wave of m and a similar to this one, maybe IPOs even. Who knows?

Maybe, you know, maybe this is the sign of a turn. Uh, I don't necessarily say one event, uh, we will cause it, but we'll see. We'll see if that happens.

Um, uh, the, one of the things that jumped out at me, it may seem like a minor thing to others, but the way the executives, even, even the media are presenting it, 'cause that's how Cisco is presenting it, is they're acquiring Splunk, a cybersecurity company. Now, I know Splunk since the early two thousands, mid two thousands ran into 'em at a conference and they had a, maybe a 10 by 20 booth, maybe smaller, 10 by 10. And of course, they were giving away black T-shirts then.

And I saw their idea and I said, oh, log aggregation, that's a great idea. I, I can see that, why that would be beneficial. And of course, there've been successive as the company's grown and matured and things like that.

Um, you know, it's gone from log aggregation to really thinking about how you build applications around that data, moving into observability, moving into kind of being a data platform for this. And I think a lot of the observability companies have, have realized and, and grown into security as part of their business. It's not just IT operations, but, uh, the soc the, uh, security organization.

But I, I think one of the reasons why Splunk is presented as an, as a security company and not an observability company is 'cause the market will understand that they get Cisco buying a cybersecurity company, and they would value that differently than how would they value an observability company if they don't know that much about that particular segment of the tech sector in it. So interesting that it's positioned that way, I would expect that to continue and maybe that will guide and, and direct a little bit of where Splunk goes next. We will have to wait and see.

So that was interesting. The other is, of course, Cisco's been working on shifting more of their revenue into, uh, annual reoccurring revenue, a r r. And according to the executives, this should put about 4 billion a year, uh, on onto the books in a r r.

So, not bad, you know, definitely a thing that would move the, the needle. So they said over the next, you know, over the, over the past several years, they've, you have kind of been shifting this, I think they mentioned number like 24 billion analyzed revenue, annualized revenue recurring. And, uh, this will co contributed to that.

Uh, I did, I did listen to a little bit to, uh, Gary Steele, who's the c e O of Splunk, and also Chuck Robbins, c e o of Cisco. And you always think about acquisitions with Cisco. Of course, it's, it's a machine.

It's been a machine for acquiring companies and technologies and doing it pretty well, having a, a regional track record of it. A lot of companies fail at m and a, it's hard to acquire a company and retain the talent or the technology or the customers or, or it's, uh, it's easy for kind of the acquiring company just to sort of overtake it, you know, be the immediate that wipes it out. And, uh, Cisco's kind of figured out a formula for not, for not doing it that way, not letting that happening.

But of course, we're always thinking about m and a acquisitions as synergies, meaning cost cutting. You know, you're thinking about marketing and HR and maybe IT sales, et cetera. Uh, that's usually the first place we look when we say there're synergies according to the executives, according to Gary and Chuck, they claim that there, their really what was motivating this deal was top line synergies, meaning revenue.

And if you hear a number like 4 billion a r r added to the bottom line each year, that's significant. I can, I can believe that, I mean, there certainly will be cost cutting synergies, but I think Cisco's going to let plunk kind of chart its course. Like, don't, don't stop it, keep it going, but let it do what it's gonna do and figure out how, maybe how Cisco can get more of its things behind its products and services behind Splunk, uh, versus the other way around.

We'll see, we'll see if that happens. Um, o of course, you know, in being a data platform and aggregation point for so many source points of data in such a large, vast amounts of telemetry and other kind of information, makes it a great platform for ai. Uh, particularly machine learning, also generative ai.

I mean, that's really what fueled, when I talked kind of back when ML was sort of picking up about five years ago, like, why is this happening? It's the data, it's, there's just so much data available now. And of course this is, you know, five, seven years later since then, the amount of data that we have is, is truly vast.

And that's what makes, uh, unsupervised learning things like that, algorithms and ml, uh, work so well, and of course it does with, uh, with well-trained gender of ai. And so I'm curious to see how that, that data that's, that's collected through Splunk and maybe as other products that Cisco has also, again, added into the mix with that could lead to some really interesting AI applications that maybe they're in a unique position to develop. So maybe already we're developing.

We'll see. Uh, so I'm excited to see where that might go. 'cause I think that could be the offspring of a, of some really interesting new waves of what Splunk and Cisco can do together.

So even whether it's, you know, generally general purpose security, cybersecurity operations, or maybe it, maybe it's domain specific, you know, in this kind of attack situations, they have so much data available. Uh, they have a specialized LLM for different domains, things like that. See where it goes.

Last thing I do wanna point out in listening to, uh, Chuck and Gary talk, and I don't know these guys, they're talking about him as Chuck and j Jerry, but, um, you know, they were asked on, on one of the programs, you know, is this a good time to do this? You know, we're in the tech sector is, you know, not, not as healthy as it was a couple of years ago where we've had a pretty significant turn. And is this the right time to be acquiring a, a company like Splunk?

And I thought the c e o of of Ciscos had a pretty interesting, and I think relevant for all of us way of saying, you know, that the, for them, this was mod mo motivated by top line synergies. Um, but they're still being prudent. You have to be prudent, but you can't stop, uh, what, what, what it takes to continue growing your company.

So, and, and all of us have to do this. I think if you've been through a, down a downturn or two, you know, yes, you have to pull back, you have to conserve cash, you have to do some things like that. You have to really be tight and, and disciplined and, uh, introspective about spending and things like that.

But if that's all you do, you're probably gonna, you know, just kind of turn in like the turtle in its shell and others who are a little bit smarter about it are gonna pass you by. 'cause they're investing in the right ways. And Cisco actually is a very good company about this.

And why I bring this up is, in the 2008 downturn, Cisco really remade its manufacturing strategy change. It kind of did a 180, uh, where they were going to very specialized manufacturers who could make these specific products and do 'em in high quality, high volume, et cetera. The technology and the, the capabilities of the market had changed the, and during that downtown turn, they changed their supplier network, the manufacturing network, to be unable to have multiple sources in their network to provide them the same products in many cases.

And you think about that, 'cause in a downturn, the people who are there may not be there when you come out of the downturn. The, they may be, they may be there, but they may have a different business model completely. So you, your suppliers could completely, uh, turnover on their own without you doing anything.

So it's a good time to rethink that strategy, and I think that's, that's a good time when, when, when, uh, Chuck talked about, you know, do what it takes. You have to do what it takes, but you don't stop taking your foot off the gas or your, uh, paying attention to what you have to do to grow your business. And so those changing conditions are a part of rethinking or maybe implementing strategies you've been thinking about, uh, when the opportunities were right, when the conditions have changed.

And I think we're certainly in one of those periods where what was true today is not, yesterday wasn't true. Today may not be true tomorrow. We're seeing so much chain happening, so fast chain AI, chain, AI being just one, you know, recent example.

So I think that saying, you know, you have, you can't, you can't stop doing what it takes to grow your business is true for all of us. So keep that in mind as you know, we're you're dealing with whatever challenging or difficult kinds of issues you might have, or you're maybe you're enjoying, you know, a really, a really good time during the downturn. There are companies that do do quite well also.

So thanks for stopping by. I wanna take a moment to share those few thoughts both about the acquisition, but also some of the implications and, and things that might come out of that. And, uh, some past observations and learnings from acquisitions and similar economic conditions.

Thanks for joining us on Textron Research Review. We'll see you on our next episode. This is Techstrong tv.

Hello and welcome to Techstrong tv. I'm Bonnie Schneider. Today we're delving into a critically important aspect of sustainability data footprints, specifically their environmental impact and how organizations manage them at the end of their lifecycle.

Joining us now to unpack this complex issue is Adam Moloney, C F O of Blanco, a company leading the charge in data erasure and mobile device lifecycle solutions. Blanco has recently released a compelling report revealing how many businesses, particularly in the healthcare and financial services areas, are unintentionally walking into a sustainability trap. Let's dive into these insights and understand what it means for the broader IT industry.

Welcome, Adam, it's great to have you here. Thank you, Bonnie. It's good to be on your show.

Well, can you start by telling us a little bit about your background and your role as C F O at Blanco? Yes, thank you. Um, yeah, as you say, I'm the Chief Financial Officer at Blanco.

Um, I've been in the post since 2018, and, um, I've also been assigned the role of heading up all of our efforts around E S G and particularly the environmental aspects of that. And that's because Blanco's key proposition is the, is data software. So this is most commonly used when your computer equipment, which is the end of life, um, or you don't wanna use it anymore, you need to dispose of that asset, but you don't want to get the data compromised.

So you can either wipe the data completely from the device by using software like Blancos, or you can destroy the equipment, uh, by shredding it into quite tiny fragments so that the data can't be recovered. And unfortunately, what we find in most instances, it's around 80 to 90% of all compute equipment is destroyed because companies are very concerned about the, the, um, the data being compromised. So Planco solution offers a, a alternative to that practice, and as we grow, we're hoping that we can help our customers be much more sustainable.

That's great. And it's, it's good timing. Now, as many, uh, companies are certainly looking for, uh, tools to do just that.

I was wondering if you could explain what the sustainability trap is as described in your recent report. Yeah, sure. So as you say, we did a report on the, um, cost of end of life data.

And what we're finding is in this report we spoke to 1800 IT decision makers. Um, and we're finding that companies are finding an increasing challenge to manage the data that they're storing. So the data that they're storing is getting bigger and bigger on an annual basis.

Um, they're collecting more data, but they're not getting rid of data at the other end. And so what's happening is, is that this data, um, storage is, is just getting bigger as we as we go on. That means you need more equipment to store the data on, you need more energy to power the devices that the data sits on.

And so therefore companies are increasing their scope free emissions through this massive increase in amount of data that companies are, are, are currently storing. So it's a, it's a problem that's just getting bigger and bigger. Yeah, it is.

And um, of course we have regulations that are coming out globally, um, that's making people more, um, and more inclined to wanna monitor, um, their, their emissions as well. So the environmental footprint of end of life data is a unique concept. Can you explain more about how that would work for end of life data?

I think some people have a general idea about it, but I'd like to take a deeper dive into it. Yeah, so what we are finding with a lot of data privacy regulation that came through over recent years and was really kicked off by the, in the EU by the, um, GDPR regulation is that you really shouldn't store data for any longer than you need it. Um, so you know, good example was always if you, somebody sends in a CV because they are interested in a vacancy that you've got, you can store that vac that CV whilst you're looking for someone to fill a role.

But once you fill the role, you should really be getting rid of that cv. But what we find in practices is that companies don't get rid of the data that they don't need anymore and they just store it indefinitely. And so that just creates this, um, yeah, increasing carbon footprint issue that, that we see across all of the companies.

So I think it's, it's a mixture of both the data privacy issue as well as a, a sustainability issue that, that companies are falling into the trap of not really knowing how to manage. That makes sense. Um, how does environmental sustainability significantly influence how businesses process the end of life data?

Yes. What we, we've seen from the survey that we did was that the, the vast majority of companies have a plan in place to, uh, uh, to manage the data that they're storing, but actually not that many have actually implemented that plan fully so that the, the data is being minimized. Um, so I think companies are finding the challenge is how you identify and separate the data that you don't need from the data that you do.

And so because that data isn't really being tagged on its way into an organization, companies can't really find it and identify when they wanna get rid of it. And so this gives companies a real challenge into, into how they're gonna manage all of this. Well, despite the influence of sustainability and um, people wanting to reduce their emissions, there seems to be a gap in implementing footprint reduction plans.

So why do you think that this is to be the case? And and do you think that that's changing for a lot of companies? Yeah, I think it, I think it is changing, as you mentioned earlier, there is a lot of regulation that's coming.

I think the primary concern at the moment for companies looking to comply with regulation is to gather the data that will need to be disclosed on, on a regular basis. Um, the regulators are really looking to make sure there's some consistency around disclosures that are made. So I think that's the first challenge.

Um, and, and they're not really thinking as much about how they reduce their footprint. They're just trying to work out how they gather the data. The other challenge we have is that, uh, buyers and the people that, that manage the data and manage data, uh, data centers primarily concerned around data privacy and sustainability tends to be lower on their agenda.

So I think the pressures on, on changing those attitudes are really gonna come from other parts of the business where probably board driven decisions to, on organizations to present themselves in a more sustainable way and make changes probably gonna come from other parts in the IT departments. And I think that will force change through organizations. Well, speaking about these regulations, um, I am, I know, um, things are different in the US versus, um, the eu.

Can you talk a little bit more about the regulations that are coming down the pike, particularly affecting the IT aspect, our audience of Techstrong TV is filled with IT practitioners from all around the world. So I was wondering if you could talk more about that and, and also how organizations can avoid potential compliance pitfalls. Yeah, there's, there's a range of regulation.

It's, it's very similar to what happened with data privacy a few years ago. Um, and it's been driven from the eu. Um, so there's a Green deal package of incentives that are coming through from the eu, which are really designed to get consistency around the data that companies are presenting, and also to really get around companies who greenwash themselves and will talk a lot about perhaps a, a plan to hit net zero by certain day, but not really have any plan for how to get there.

So these, these disclosures are gonna need to be assured by third parties, perhaps as part of your year-end accounts. And what we're seeing is this now starting to spread out to other parts of the world. So in the US for example, the s e C have come out and said, we are gonna want some disclosures from public listed companies in the us, uh, outside the EU and the us There's the International Sustainability Standards Board that will also want companies to make disclosures.

And across the board they're saying, you're gonna need to disclose what your scope one, your Scope two, and your scope three emissions are. Now scope one and two are those directly, um, coming from your organization. But Scope three is about the, um, emissions that come from the goods and services that you buy into your organization.

So from an IT perspective, companies gonna really need to think about what it is that they buy into the company, how much compute equipment they they buy, how much cloud, um, instances that they currently consume, how they power the, um, equipment they have to really reduce those Scope three emissions as much as they can. So I think it's gonna be a real change and a lot of pressure on IT organizations to, to reduce footprint over the next couple of years. And it's gonna come from the need to disclose to all stakeholders, this is what our carbon footprint looked like this year.

And is it better or worse than it was last year? Do you think that there, there's, um, a lot of people that are unfamiliar with Scope three in general, that there, that's something that's overlooked? Yeah, I think, um, you know, from a, from a Blanco perspective, we became carbon neutral in 2021, and I think kind of dismissed Scope three a little bit, thinking it wouldn't be that significant.

An impact for us actually turned out that 70% of our footprint came from Scope three. I think a lot of organizations that are perhaps outside the manufacturing industries, but those are perhaps a bit more, um, IT based are all gonna see a very significant proportion of their footprint coming from Scope three emissions. And that means you'll need to look very hard at the suppliers that you use to make sure you're using the most sustainable ones if you wanna reduce your Scope three emissions.

And I think it's only once you go through the process of trying to measure what those emissions are that you really become aware of, of, of the impact that they have. And I think it, uh, there'll be a lot more focus on that than there will be on scope one and two. Well, you focused a, in the report about, um, healthcare and finance.

Um, I know that our audience, uh, people that work in it might be working for these sectors. Um, first I was just wondering why did you focus on these sectors and, and what you found in your report of, of what they need to do to avoid falling into that sustainability trap? Yeah, for us it was really focusing on those industries which are very highly regulated, where, where you perhaps the most sensitive, um, personal data might be stored on the individuals.

So healthcare, obviously having people's health records or in financial where you might have details of their, yeah, their account numbers or how much money they're holding in their accounts. And so those are the most heavily regulated companies. Um, and so we felt that they were particularly interesting because they are the ones that have got the biggest challenge around how they manage their data, which data they need to keep, and which data, data they need to get rid of.

Um, so that's where we thought a lot of the focus of the report should be. And I think it was, it was correct to do that. You know, we, we see a very large proportion of companies are beginning to work on, on the carbon footprint side of things and sustainability, sustainability impacts of their operations.

Actually, I think a lot of 'em are still in the very early stages of that and, and have yet to present the full output from the data collection that they're doing. Well, for our last question, if you could, uh, share with us what you envision for the future of end of life data management and also share what you're working on now at Blanco. Yeah.

Well, I think, um, where we think this will have to end up is, is a much tighter data lifecycle, uh, management process. So the challenge, as I said earlier at the moment, is that when information comes into your organization, it's not being classified. And so you have no idea where it is or what it is when it comes out the other end.

So in my example earlier where I talked about a cv, if you, if you tagged a CV as a CV when it came in with an automatic rule to erase itself after six months, then that would manage the whole issue. So I think there'll be more automated processes in place to manage the data lifecycle. Um, and Blanco's role in that is very much at the end.

So once you've identified that data and you need to erase it and reduce the amount of storage that you're, that you're using, um, Blanco's solution will be, will be there at the end of that process to, to help erase that data and reduce your footprint. That makes sense. Um, it was really a fascinating conversation, Adam Moloney, C f o of Blanco.

We really appreciate your time and joining us on Techstrong tv. Thank you, Bonnie. All right, well stay with us.

We're going to have a lot more on sustainability and technology coming up. I am Bonnie Schneider, sustainability contributor to the Techs Strong Group. I'm excited to introduce you to a groundbreaking new initiative from Techstrong Research, the sustainability pulse meter.

The pulse meter offers valuable insights into how environmental responsibility factors into tech purchasing decisions for key players in the industry. Position your company as a leader in the industry and differentiate from your competitors with a sustainability pulse meter offered exclusively from Techstrong Research. Hi, thank you for, uh, joining me for this presentation for DataOps Day 2023.

Uh, my name is Scott Malani. I work for medical imaging and division of Lead Technologies, uh, incorporated, uh, the head of business development and health tech. Um, I've been working here for, uh, about 20 years, um, and that, uh, is about the length of time that I've had experience within the IT healthcare industry as well.

Um, just to give you a, a very brief overview of, of of the differences between, uh, the, the, the medical imaging division and lead technologies. Uh, lead basically caters, uh, to the needs of software developers while as, uh, Meco caters to the needs of, uh, healthcare end users. Uh, so we at meco develop, uh, end user products, uh, that are meant to be deployed in a healthcare enterprise, uh, where lead, uh, sells, uh, software development toolkits, which can be used to build products for development within healthcare, uh, develop, uh, uh, enterprise.

Um, I am personally, uh, a voting member on the A d A standards committee. That's the American Dental Association Standards Committee for Dental Informatics, uh, otherwise known as the A D A S C D I. Um, also a member, uh, personal and corporate member of DICOM Working Group 22.

Uh, we'll get into what DICOM means if that, uh, term doesn't ring a bell, uh, uh, here in just a few slides. Uh, so to get it started off, uh, let's just talk about what the goals of this discussion, uh, are. Um, and, uh, basically to define what, uh, what are these islands of data in small and mid-size healthcare organizations, um, the, the benefits of of, of, uh, industry standards.

And there you see that word DICOM again. Uh, and again, I'll get into, uh, what, what DICOM and, uh, and, and the, the term PACS means. Um, so we all have a fully full understanding of of, of, of that.

Uh, during this presentation, um, wanna talk about the barriers to centralizing, uh, healthcare data storage, um, in pacs. Um, and, uh, talk about how small to mid-size healthcare organizations can implement PAX on a small budget rather than, um, some of the, the larger PAC systems out there, which range into the millions as, as we'll see in a few slides. Um, also want to talk about how, uh, implementing A A A PACS can help seamlessly communicate, uh, help devices seamlessly communicate, ensure, uh, you know, all, all your healthcare data's backed up, um, secure access to, to patient health information and then, uh, improve user workflows on top of that.

Um, so let's, let's first just talk about what are these islands of data that I'm, that I'm talking about? And, and generally these are, uh, healthcare, usually imaging devices. Um, and, uh, those, those imaging devices might be ultrasound devices or CT scanners or M r I scanners.

Um, we see some of them, the dental industry as well that are specific to dental, um, that are, uh, cadcam basically same day implants systems, um, ECGs, EKGs, really any other medical device or modality, uh, modality being just an, an imaging or, or, or, uh, uh, information gathering device that, uh, uh, is, is used within healthcare. Um, any of these devices often have internal storage or might externally ex store to a, uh, a n share or u n c share, uh, and, and connect to a database. Um, but often, uh, these islands are neglected.

Um, so locally, uh, on the device's internal storage, um, is, is is where the data is typically stored. And, and these devices, uh, don't usually run windows. They usually run a custom Linux use Unix or, uh, distribution, um, with a GUI that's, that's only intended to operate the device.

Um, so basically you boot the ultrasound, uh, machine up and, uh, the first thing you see is it's ready to operate, um, ready to, to query for patient information. There's no, you know, uh, uh, log into windows or anything like that. Uh, um, so this makes backups a challenge, um, because, uh, you know, this, this data that's stored locally on a Linux device, uh, has, how does that get integrated into your, uh, backup within your organization?

Um, and, uh, the ability to apply group policies to these, uh, devices is virtually impossible. Um, when, uh, the images are stored on a network share instead of in internal storage, um, it's often stored, unprotected with, uh, improper permissions restricted. We've, uh, seen, uh, plenty of lo of, of, uh, occasions where, uh, healthcare data is just stored out in the NAS on the, on the, uh, network.

And, um, it's, it's just not secured to the people that need to view it, uh, which is the way it should be. Um, and o often, uh, these devices store information in a proprietary, uh, database or format. Um, so it makes it difficult for interoperability with other systems, um, unless we depend on a, uh, some sort of standard, um, that internally stored data is, uh, well, it's rarely backed up, um, if ever backed up.

Um, another downside to it is that it's not available for viewing from a central location. So if, uh, if, if, if a patient were to have a, an ultrasound or an E K G captured on a device, well, that ultrasound or E K G is stored on that device, um, we've, we've seen users often rely on thermal printouts from ultrasounds, and they scan that printout into the E H R as permanent storage for the image. Um, so, you know, original images is stored in, in, in data on, on the actual device.

Um, they've, they've printed out this, you know, small thermal scan, you know, if you've been to a, a, a, a baby appointment and they printed out an ultrasound of your baby at, you know, whatever weeks. Um, that's, that's the type of thermal printout that I'm, that I'm talking about. Um, and, and that's what's actually scanned permanently into the patient's record rather than the full, than the full fidelity, uh, ultrasound, uh, which is still, you know, located, uh, on the internal storage of that device.

Um, so this makes it, uh, this makes these files susceptible to description and failure. You know, if something happens to that device, um, then the data, the, the full fidelity data that you've got, uh, stored on there is just gone. Um, and, uh, it's often forgotten about until it's too late.

Um, it's, uh, makes it difficult or impossible to provide, uh, patients with a c d or D V D, um, of the, uh, of, of, of their patient, uh, healthcare information if they've requested it. Um, so just not, not, not, not, not a good situation to have the situation or, or, uh, data stored on these, uh, internally, uh, in this internal storage. So what's the solution to ensuring that all data is centralized, backed up and viewable, viewable from outside the device itself?

Um, well, we need a central places for these files to be stored. Um, we need, and, and I'm talking from all modalities, not, not just, uh, from, you know, a particular ultrasound device. I'm, I'm talking x-ray ultrasound, M R I CT everything.

We need a central place for all these files to be stored. Um, we need a way to, uh, to get the files from the medical device to the central storage location, just from point A to point B. Um, we need a way for the clinicians to be able to view the images.

Uh, so, um, rather than making them go back to the device or viewing that, you know, scanned thermal printout inside their E H R, um, actually giving them a proper viewing, um, application to be able to, you know, manipulate images, make measurements on images, uh, do the things that they need to do. Um, and, um, we need to wait to provide these images to patients, uh, when requested as well. So, uh, if the patient wants to take their images home with them, um, I know as, as someone in the in industry, I, I, I al always ask for my images on a cd, um, just, just so I can have them, uh, in our, uh, and my, my, my personal family's archive of DICOM files, and, uh, of course, it needs to be backed up.

So there is a solution, um, and, uh, it's utilizing a, a universally accepted medical standard called DICOM to implement a pax. Um, and as I mentioned earlier, we're gonna go over what those terms actually mean, uh, in case you are not familiar. Um, so DICOM is the international standard to transmit store retrieve, print process, and display medical imaging information.

Um, it stands for Digital Imaging and Communication and Medicine. The standard's been around for, uh, over 30 years now that it's been in development. 0, uh, of the standard.

And, uh, it's, it's, it's a very lengthy medical standard, uh, printed out. Um, I've been told that if, if it were printed out, you know, page for page, it would be probably taller than I am, and I'm six three. So, uh, it is a, uh, uh, certainly a long, uh, standard.

Um, but, but, uh, there have been a num a number of working groups, uh, divided up to develop this standard to make sure that, um, as long as devices follow the DICOM standard, they are in interoperable. Um, so, uh, the DICOM standard allows for an easy conversion from one imaging platform to another. And the reason for this is because pretty much all PACS platforms and imaging platforms already utilize at DICOM standard, um, if it's, uh, not available on a particular imaging device, um, it is often available as an add-on for that imaging device.

So generally speaking, uh, all medical devices, uh, with, with the exception of few, uh, do support the DICOM standard already. Um, and, uh, it allows for the, uh, exchange of files amongst multiple providers. Um, so rather than, uh, exchanging like a, a JPEG file, which doesn't have any patient information, um, tied into it, uh, they could, uh, exchange a DICOM file instead.

And as long as, uh, both the, the sender and the receiver, how do we have viewed DICOM files? Um, then they would not only receive the imaging data. Um, and, and I, I'm possibly, uh, getting, uh, ahead of myself here, uh, with, with, with the slide coming up.

But, uh, they, they would be able to see the imaging data as well as the actual, uh, acquisition data about the device, the time the images was, was taken, the anatomy of the image, et cetera. Um, so, uh, there, there's, there's metadata that's, that's baked into each DICOM file. Um, and, um, the, that, that includes, uh, the patient identification.

Um, so basically if I have a DICOM file, uh, versus a, uh, standard JPEG file, um, a DICOM file, I'm able to, uh, look into the metadata and find out what, what patient it belongs to, um, without having to reference a database to a file pointer to a jpeg. Um, all that information is just baked in the DICOM file. Um, it also provides, uh, interoperability with other medical systems and imaging devices.

Um, like I mentioned, uh, you know, most devices out there have DICOM compliance may not come with it by default, but it's usually available as an add-on module to those devices. Um, and it, uh, provides interoperability with specialty imaging software devices. Uh, for example, if, uh, I had a, uh, specific cardiology based viewer that had cardiology specific functionality that maybe a, uh, uh, ophthalmologist might have no interest in, um, then, uh, there is such a thing as a generic DICOM medical viewer, which basically handles, you know, 95% of all, uh, medical, uh, image viewing cases.

Um, and then there it would be a cardiology specialty viewer, which would be DICOM compliant and would be able to download those images no matter where they were captured from any DICOM compliance server. Um, so the, the DICOM standard is, is currently used universally in medicine. Um, it allows for the exchange of digital images among practitioners.

Um, it allows for integration of imaging devices from different vendors into one system. And what I mean by that is that, um, let's say, uh, let's say you're one of the big boys, you're one of the big hospitals, and you've got a multimillion dollar GE pack system, um, that, uh, that manages all your, uh, your, your healthcare imaging data, um, then that, that doesn't mean that you have to buy GE devices for all of your imaging devices. You could buy a, a Siemens ultrasound and an agfa uh, printer, and a, uh, a different brand of, of a CT device and a different brand of, uh, E K G.

Uh, it, it doesn't matter to the brand, as long as they all talk the language of dicom, then they would be compatible. Um, it's, uh, an actively developed and maintained standard, uh, to meet the evolving needs of technologies and, and, uh, medical imaging in general. Um, we're constantly, uh, adding, uh, technical reports and, um, additions to the DICOM standard, um, to, uh, ensure that, uh, all devices, uh, are covered as in including any new technology that might be emerging.

Um, so that, uh, once it does in fact emerge, we'll have a definition within the DICOM standard of, uh, how to handle those particular images or, uh, information. Um, it's an accredited, voluntary consistent, uh, consensus development process, um, that involves and vendor, uh, vendors, uh, such as myself, um, industry experts. Um, so we've got, um, members from, uh, universities, uh, and, uh, other INST institutions, uh, such as the, uh, D O D D H A, um, are all part of the DICOM standards committee.

And, uh, end user volunteers are also included, um, to just ensure that the end user's, uh, requirements are, are, are met. Obviously, we don't, don't wanna set the requirements as the vendor. We wanna make sure the end user's happy.

Um, and, um, yeah, I think I've already reiterate that one that allows devices and applications from, uh, different vendors to communicate with one another. Um, so what, what, what I like to do to kind of help describe what the DICOM standard form, uh, is, is, is divided it into really two pieces. Now, uh, this is sort of my thing.

Um, this is not necessarily, uh, you, you, you won't necessarily find it in the, uh, DICOM standard, uh, listed this way. Um, but, but, but I think as long as you can understand these two things, um, then, um, dotcom should make sense. Um, so the first thing is an imaging file format, um, just like, uh, jpeg or tiff or bitmap or, or a docx or, or MP three or, or, or whatever.

Um, but, um, the DICOM file is different in that it includes that metadata. Um, and that metadata could include, uh, all sorts of information about the actual device and the, uh, information about the patient, um, about the, the anatomy imaged, about the, um, person that was actually capturing the image, um, et cetera. So there's a lot of baked in information inside the DICOM file itself.

Um, even if you just have that one file, uh, you can know a lot about the patient, excuse me. Um, and the second part of the dotcom standard is the communication protocol. Um, so this, we would be kind of comparing this to like H T T P or F T T P or email, um, basically the, the language, um, the way that, um, to nodes on a network can talk to each other using the DICOM standard.

Um, so, uh, it basically, uh, begins with a T C P I P connection and, um, an association and then transaction begin going on, um, during that T C P I P connection. And that, uh, facilitates the transfer, uh, to or from of the DICOM images, uh, from either to a, a, a storage server where they're gonna be stored or, uh, back to a viewer where they're gonna be viewed. Um, as I mentioned, the, the DICOM file format, and I, I won't necessarily go through, uh, all of these, um, but, uh, the metadata is embedded into the files header, including, um, as I mentioned, patient demographics.

Um, the equipment manufacturer model name, serial number that captured the image is an important one because you can actually track an image back to a particular serial number of device. Uh, just again, with that one single file, all that information's baked in. Um, the imaging pixel data is of course, in included, um, and, uh, display positioning information.

So if, uh, an image should be displayed in the left or the right, or the top or the bottom or, uh, in, in a certain format, um, then that, that display information or, uh, protocol information is included, uh, in the DICOM metadata. Um, and there's, there's too much to list here. It's a ton of tags.

This is just to give you an example of what dicom, uh, file, uh, the DICOM file format might look like. Um, this is just a screenshot from, uh, my company's, uh, storage server opening up a DCOM file. Um, this is obviously Bob tests from an anonymized patient, so I'm not, uh, revealing any, uh, P h I or anything here.

Um, but, um, these are just some of the tags that are included. And this list, uh, does go on. And as you can see, I've not expanded out all of these, uh, options on the tree.

So there really is a lot that's stored inside the file, um, in inside of a DICOM file. Now, the, the DICOM communication protocol, uh, portion of things, um, is, uh, it communicates over T C P I P. Um, it does have a iana, uh, designated t CCP IP port.

Um, that port is port 1 0 4, however, uh, it's not a necessity to run PAC Services on port 1 0 4. Um, the, uh, that, that's just the, the designated port, it can certainly run on a different one. Um, it is the, uh, the, the standard method of data exchange for images, radiology reports, and, and other captured medical data, either from devices to a central server or back from a central server to actual viewing locations.

Um, so images can be retrieved from a PAC server as well as stored to a PAC server. Um, and of course, we've gotta allow the, the user to be able to search, uh, because they can't just open the, the viewing software up and, and immediately know what, what, uh, image they need to be able to pull up. They need to, need to be able to query and search the PAC servers.

They need to search for Sally Smith and, and know that, uh, Sally Smith's got a CT waiting to be viewed, um, on the server, uh, to download it. Um, and additionally, one other thing that, that, that DICOM communication protocol can provide is a work list. Um, and this is generally, um, when, uh, integrated with a radiology information system, um, where, uh, images, imaging procedures can be ordered.

Um, so for example, a provider would order a ct and upon ordering that ct, um, in an item would appear on a, uh, sort of like a to-do list, uh, it's called a modality work list. And, um, then from the CT device itself, uh, the CT technician could simply, uh, query the PAC server, and the PAC server would tell the, the user that, Hey, there's a, you know, CT waiting to be captured that's been ordered for, uh, for a specific patient. Um, and, uh, it would pass along all that patient demographic information, um, so that the user's not manually typing in that information themselves.

Um, so, uh, as I mentioned, it provides a standard language for all devices and, and applications to communicate with one another. Um, it allows for the exchange of images between applications without having to use import export. Um, like you might have to with, uh, importing and exporting a JPEG file, um, from one application to another, um, in, uh, storage medium such as CDs, thumb, DR thumb drives, et cetera.

Um, provides, uh, correct patient demographics and order information from the system of record. Um, and that's what I was speaking of with the, uh, modality work lists. Um, we'd actually be getting that order from the system of record being the, uh, the electronic healthcare record, uh, rather than depending on the user, uh, to manually type that information in, uh, which of course leads to mistakes.

So utilizing the DICOM standard, um, we have a standardized file format that we can use for all captured healthcare data, uh, imaging or otherwise, that doesn't just include images. You can capture other healthcare data as well in DICOM files. Um, we, we also have a way to exchange information from point A to point b i, uh, image and non image data, uh, between applications.

So for example, between a ultrasound device and a PAX server, or between a PAC server and a PAX viewer. Um, and, uh, we also have a way to, uh, burn, uh, CDs, uh, and, and, and, and create storage media. Uh, also, um, So a software that supports the DICOM standard, um, you've heard me utilize the term pax, um, and, uh, what that stands for is picture, archive and communication System.

Um, now PAX is the industry term for, uh, basically the imaging system within a healthcare organization. Um, the, uh, the, the, the terminology is a little confusing because it stores more than images, but since this has been around for 30 years, and it started with images, uh, that's just, just been the defined term. Um, there's no concrete definition of the term pacs other than it must be DICOM compliant.

Um, everyone's sort of got their own definition of what a PACS is. Uh, some people, um, even claim to, uh, have a PAC system that's not DICOM compliant. Um, I, I don't know that I would be in agreement in agreement with that, but, uh, simply put a PAC system is, is, is software that fully supports the DICOM standards, both the file format and the communication protocol.

So what are the differences between DICOM and pacs? Um, DICOM is in name of the developed standard, and PACS is the imaging system, which can, uh, as I mentioned, accept images from any DICOM compliant, uh, device or application. Um, can store the images, uh, to, uh, local storage, uh, including into a database.

Um, doesn't have to be a specific type of database, just whatever the application has has chosen in its full ly per, uh, full fidelity format, uh, permanently, rather than relying on, uh, scans of, of thermal printouts or, or things of that sort. Um, it, uh, sends images to any DICOM compliant devices or applications. So examples of those are DICOM compliant printers and CD burners.

There are actually DICOM compliant printers and CD burners, D V D burners out there where you can store DICOM files directly to them using the DICOM protocol. And, uh, it will either create a film x-ray printout or burn a CD with the patient's information printed on the CD automatically. Um, we can, uh, provide imaging procedure order information and patient demographics to the, uh, capturing devices and applications, uh, so that the user's not manually having to type that information in.

Um, know what medical, uh, devices often don't include the module that enables the device to communicate on the network using the DICOM protocol. So this is one of the barriers. I, I'm sorry, I forgot to, to mention, I, I sort of switch subject switch subjects there.

The barriers to centralizing healthcare data storage, uh, generally these upgrades to devices to an ultrasound device, for example, might cost anywhere from 2,500 to $10,000 per device. So there is an investment, um, that, that, that, that is required. Um, software solutions that support the DCOM protocol can be very expensive.

Uh, PAC systems often run into the multimillions of dollars. Some major players are ge, acta, Siemens, Phillips, Fuji, et cetera. Um, at smaller health centers, a local IT team may not be able to implement a PAC system.

Uh, they just aren't affordable, they aren't manageable, um, from, from a, uh, a, a, a small to mid-size healthcare organization. Um, they, um, some devices don't have support for the DICOM standard. Uh, this is prevalent in dental and ophthalmology, where these devices simply output files and formats other than dicom, and we don't have an option.

Um, a lot of times in what we do in these cases then is encapsulate those DICOM files as binary data inside a, uh, or, or encapsulate those files as binary data inside a DICOM file so that it can be stored to APAC server. Um, and some PAC systems require extensive knowledge of Linux in order to implement, um, which isn't always available at, at, at, uh, smaller healthcare centers. Um, PACS implementation can be expensive, but it doesn't have to be.

Um, we've mentioned the large players in the, in, in, in the PAC systems. Um, they come with large price tags. And despite these costs, uh, these, these PAC systems are, uh, often rely on on antiquated code.

Um, they've been around for years, they've been around since the DICOM standard was developed. They're often command line based, um, and, uh, we've heard that they're, uh, difficult to deal with. Um, less expensive options are available if you know where to look.

Uh, there's several open source free pack systems, uh, that can run on Windows, Linux, and servers. Uh, a couple of those are, are orang uh, supports, windows, Mac, oss, and Linux based operating systems, uh, includes a very basic, very, very basic, uh, web-based zero footprint viewer. Um, DICOM four CHI is another option.

Um, it's a Java based open source PACS components system. It's not necessarily a PACS system, but what you can do is piece together, uh, different components of that system to create your own PAC system. Um, this generally, generally relies on a very knowledgeable IT team and one that's, uh, willing to implement, uh, systems that, that might be a little lot of their comfortability zone.

Um, there are also, uh, commercial lesser known PAC systems, which can be implemented on a much lower budget, um, as low as $10,000, not $10 million. Um, I, uh, have to mention our own, uh, PAC system, which is called Medical imaging, uh, mypac Enterprise pacs. Um, it runs on a Windows server, um, includes a fully featured zero footprint web-based viewer, um, and can fully integrate with an E H R system for one click access to patient's, uh, healthcare and imaging data, and, uh, supports multi clinic organizations also that need to centralize their healthcare data into one, uh, location.

And it, it does support every imaging, uh, file format within the DICOM standard. So no matter what type of devices, uh, the, the customer's using, whether it's an ultrasound or CT or M R I or chest x-ray or mammography or, uh, you, you name it, um, it is, uh, supported in, in, in, in, in inside of mypac. So, uh, free open source, uh, low cost viewers are also available.

Um, some options for free and low, low cost viewers are, uh, I don't necessarily list them all, uh, but we've got several options here. Uh, me film is currently being sunset by I b m. Um, some popular ones that we hear about are ROS on our Cyrex, those are for Mac OSS only.

Um, and they actually require for their f d a cleared version. It is a paid viewer. It is not free.

Uh, they offer a free version for non-diagnostic purposes. Um, they're gonna be deficiencies in their, in, in, in these free viewers. Uh, they are not fully featured with the exception of, uh, Seno Cyrex, which are fully featured viewers.

Um, but as I mentioned, those come with a price tag, and I believe that price tag is, uh, around $2,500 a workstation. Um, I, I, I don't know that for a fact though. Um, a simple but effective, uh, PACS can be implemented by combining, uh, components from different PAX compliance, uh, compliant applications, uh, for your low-cost PAC server, uh, for your low-cost DICOM compliant viewer, which can retrieve images from a PAC server.

And, um, you know, since these applications use the DICOM standard, they can come from different vendors. Uh, so you can have one brand of a server and a different brand of viewer. Um, and I know I'm going just a couple minutes over, but I think I've got two more slides.

com files. Um, so images are no longer scattered amongst the, uh, internal storage of these imaging devices. They are now backed up into one location, um, and all modalities are configured to stored the capture captured imaging data to that single location.

So anytime you take an ultrasound, it's automatically stored to the organization's PAC server, which then, uh, is automatically, uh, follows their, their standardized backup procedures. Um, so, so we've now got a backup of, of, of this patient data, not to mention the fact that we can centrally, uh, view this patient data rather than having to go to the actual device that the image was captured on or rely on a, uh, scan of a, of a printout. Um, I, and I, I, I, I think I've, uh, actually covered these.

I, I got ahead of myself. I I covered these on the last slide. 3, um, and it's only permitted to communicate with all authorized devices.

Uh, you can restrict what, uh, IP addresses or what host names, or what AE titles, which is, uh, an AE title is sort of like the DICOM identifier for host name. Um, and, and unless it's in a promiscuous anonymous mode, um, you can, uh, require the PAC server to authenticate with these devices so that you can ensure that no devices, uh, are present on your network that are not authorized to communicate with your PAC server. Um, the, um, so they, many, many small to mid, uh, size healthcare institutions don't currently utilize PACS because they think it's outta their price range.

Um, in these organizations, uh, healthcare imaging data is scattered amongst their multiple image imaging devices. Um, in these islands of data, they're stored, uh, locally on these devices. Um, implementing a PAX doesn't have to cost millions of dollars.

Um, it can drastically improve, uh, the user workflow. Um, just because they're not required to go back, um, you know, you re, regardless of the backup, regardless of the, uh, the ha having everything in one central location, um, the, the users are able to view images without having to go back to the actual device that the image was captured on or rely on a scan of a printout. Um, it can, uh, PAC systems, oh, sorry, I skipped ahead.

By accident, uh, PAC systems can help ensure that all patient data is properly backed up. And, um, utilizing in industry standards like DICOM ensures that your devices and applications can communicate with one another using a standard, uh, protocol that, uh, where, where everything can harmoniously communicate with each other. Um, and, uh, that will, uh, wrap up my presentation.

Um, thank you for your time. Uh, please. Uh, if you are interested in learning more about, um, our low-cost PAC system, um, feel free to contact me.

Uh, my, my information's on the screen there, um, and I thank you all for your time. Hi, I'm Jennifer Glinsky, director of product management in BMCs Innovation Labs. In an error defined by data's exponential growth, businesses are driven by a common ambition to become data-driven powerhouses that make strategic decisions with precision and foresight.

Yet this journey is not without its challenges. The path from data to actionable insights can be obscured and investments need to be meticulously justified. Today we embark on a voyage of discovery to unveil the transformative potential of data ops, a methodology that empowers organizations to estimate and elevate the business impact of data-driven strategies.

Did you know the global big data and analytics market is projected to grow to over $307 billion this year? In this era of unprecedented data growth and technological advancement, organizations find themselves swimming in a sea of information. The promise of insights and opportunities lies within this vast ocean of data, but the question that looms large is how do we NA navigate?

But the question that looms large is how do we navigate through this data and extract the value that drives meaningful impact? We are embarking on a journey to uncover the keys to turning data into insights that lead to tangible business success. To bridge this gap from data to impact, we introduce data ops, which blends agile methodologies with automation to orchestrate data management.

DataOps empowers organizations to optimize business processes, talent allocation, and their overall data flow, ultimately translating to a net benefit for businesses. So let's begin with the need for data ops. Why are we concerned with it and why are we here today?

So we know organizations are investing heavily in data and analytics and AI projects. Well, unfortunately, a significant number of these projects fail to meet expectations. Only 40% of firms are managing data as a business asset.

In order to monetize data, you need to be able to get it from the sources that create it into the hands of people that can do something with it, people that can take action based on it. And what we're seeing is almost half of these big data projects to do just that or failing. 19% of firms consider themselves to be data-driven, which is awesome.

It means that they're using data to make decisions, but if half of their big data projects are failing, could they be using bad data to make those decisions? Why then are so many of these big data analytics and AI projects failing? Well, there are several reasons why these programs could fail, starting with the exploding amount of data and the increase in the number of data sources due to newer types of data or more complex business flows that make simplification difficult or challenges into in deploying to production at scale with high expectations on flexibility, speed, and customization.

A lack of collaboration doesn't help either, especially when different teams are involved in the projects, nor does process mismatch where traditional data management technologies and approaches don't really match up well with new advances such as ai. We're seeing a limited talent pool in the industry since data analytics and AI projects require both internal domain knowledge as well as deep technical skills. These data analytics programs require significant investment and there's a risk of becoming overly focused on the latest tech at the expense of delivering real business value.

How many of you have been asked how can we use chat GPT or AI in X, Y, or Z, where it's a very simple process like mailing your letters at the bank post office, or conducting your general day-to-day businesses? Not everything needs AI or analytics, and sometimes we overcomplicate things just because it's shiny and new and exciting. Lastly, a unclear approach to measuring success doesn't really help either because many of these benefits are often observed in other teams for these foundational initiatives, these are certainly hefty problems to solve.

Which of these would you say is the biggest challenge in your team? Which of these challenges are you witnessing in your organization? Personally, I've seen an exploding amount of data in many environments, so let's take a little look at that challenge for a moment.

Businesses worldwide have been on a data collection spree driven by the staggering projection that will double the amount of data generated in the world in just four years, from 2022 to 2026 to around 221 zettabytes of data according to I V C. Now, I will confess, I don't even know what a zettabyte is, but it sounds very, very big. And just the fact that we're going to double all the data in the world in four years is astounding, but admits this data frenzy, a fundamental challenge emerges how to transform this data deluge into actual insights.

It's the same challenge we've been faced with, it's just gonna get harder. The journey to meaningful insights begins with clarity. First of all, do you know what data you possess?

Is it the right data? And more importantly, is it yielding real value for your business? These are key questions I would encourage you to consider as you begin your data ops journey.

The second reason analytics and AI projects fail is because organizations face challenges in operationalizing data pipelines at scale. This is just as important as that first reason. A few data pipelines might be easy to maintain manually with only one or two small problems, but as you scale up, those problems quickly become unmanageable.

This is when you need to introduce data pipeline orchestration to keep things under control. What happens then when you overcome these challenges? B M C solutions like Control M are supporting industries around the world to orchestrate and manage data needs from mainframe to the cloud.

And we're seeing BMCs customers like Raymond, James, I n g, Navistar and more making a difference in the world around them through their successful analytics and AI projects. For example, they are saving more lives by analyzing hospital operations data. They are building tools that help students and they are optimizing commercial space to make room for cute new shops and cafes.

In turn, making someone's morning just that little bit brighter with a cup of tea a biscuit. Of course, this is only a tiny taste of all the ingenious ways EMC's customers are improving the world around them through analytics and ai. How then can organizations get more of the programs just like these into production?

The answer lies in data off. Data ops has emerged to help organizations overcome some of these challenges and increase the number of successful data and analytics programs out in the world. What is data ops then?

Data ops applies agile software development best practices to managing data pipelines. This helps engineering and data teams deliver the right data to the right people when they need it. BMCs Quest for knowledge led us to commission 4 5 1 research part of s and p Global Market Intelligence to survey 1,100 data and IT professionals around the globe about the value of data and ops.

In particular, the insights gained from this extensive study show that organizations with higher data ops maturity experience greater data efficacy, provenance and availability. The correlation between data ops methodology and business objectives is undeniable. We've discussed some of the reasons analytics and AI projects might fail, and we've introduced data ops, so let's consider an example to illustrate these concepts.

Consider this scenario which illustrates some of the challenges data professionals face when they try to manage data pipelines manually, and show us why and how data ops has emerged via valuable tool. I'd like to introduce you to Jane here. She's a data analyst who's been asked to build a report to show how segments of customers changed their spending over time.

Also, this is based on a true story. So to create this customer spending report, Jane builds a SQL query into a data warehouse to get revenue data by customer. She then creates a Python script to aggregate everything by the date of a customer's first purchase, and she imports the data from all of these fun scripts into a reporting server so that she can load her report.

Finally, she builds a scheduler to run the data pipeline and populate her report every Monday morning. Things are looking pretty good for Jane, and really this is all she thinks about when she thinks about her data pipeline. She thinks about the areas that she touches, which is how most people think about their pipelines.

However, it's not the full story. Jane's pipeline actually begins with data coming from three different source systems from customers, sales and finance. Considering a world without data ops where Jane is managing her pipeline manually.

Small changes can have large undesirable impacts. For example, say the finance team changes something in their database, say they add a new category for revenue. Well, traditionally, Jane's not gonna necessarily know about that or calculation scripts not gonna know it's gonna miss this new category and it's gonna impact her final report.

When she finds out about the change, she'd have to go make multiple versions. Now she's managing a bunch of different files because what if that change broke it? She'd need to back it up.

Things start to get very messy this way. Also, in the worst case, Jane doesn't notice this reporting issue right away, and Jane stated, consumers like her boss or a customer are the first ones to notice there's something wrong with that revenue calculation in her report. They're not really sure what's going on, but her report doesn't match her the other reports they get.

So now they don't really trust Jane's reports and maybe they're not, they don't really trust Jane. This is not a great day to be Jane, and I'll tell you a secret, I have been Jane before and it is not fun. In another case, Jane might notice that the problem exists before anyone else catches it, but that's also not great because think of all the people who've been using her reports thinking it was right, who knows what kind of decisions they made based on that information that was inaccurate out of date or just flat out wrong.

Add that to the whole messy file management issue we just talked about, and things start to get very undesirable very quickly for Jane. So we need to reframe how we think about data pipelines and the flow of data to consider the full path of data through an organization, and we need a framework for managing those enterprise-wide data operations and transformations. This is where DataOps comes in.

It is a framework for you to do just that. By implementing data ops principles, including pipeline automation and data observability, Jen can orchestrate her pipeline and proactively manage changes to keep things running smoothly. We know data ops brings the best practices from software development and IT and applies them to data pipelines.

What does this look like? This includes automation and orchestration, which allows you to efficiently move data from different sources such as structured IOT or streaming data like we see on the left side of this diagram all the way through data pipelines to consumers of data on the right side of this diagram, including analytics, a data warehouse, visualizing reporting, or my personal favorite data science. Unfortunately, as we saw in our example with Jane, manual efforts alone cannot keep up with managing the immense volume of data generated in enterprises today.

This is why many organizations are implementing DataOps best practices to bring automation and observability and more to their pipelines. As I'm sure you know, working with data is not without its challenges. The following ones are good ones to look out for four or five.

One researcher's study revealed common issues, hindering progress towards a unified view of data. They uncover that there are persistent struggles in data quality, automation and culture, specifically meeting complex needs, automating processes. There are many data quality problems and data silos in system interoperability poses a challenge.

First, a key reason why organizations need data ops is because the data pipelines required to feed data and analytics and AI projects are so complex. Believe me when I say the sheer number of tasks and connections involved in a data pipeline can be intimidating. Take this image for example.

It's a real data pipeline with tons of different data tables and jobs across different environments. They are transforming data, they are moving data, they are filtering and uh, joining data. They're doing everything you can do to data, and this is only a single data pipeline.

This isn't even the biggest data pipeline in the world. This is just a very typical data pipeline. When you scale up to larger, more complex organizations, navigating and managing data pipelines becomes tremendously complex and difficult to solve.

A large company could have 20,000 data pipelines with 5,000 data scientists or ML engineers around the world consuming thousands of data sources. All of this complexity provides endless ways for data pipelines to break, especially when changes are introduced by different people managing different parts of the process. The demands of a 24 7 business model and the internet of things and edge computing, all of these technological advancements also necessitate seamless data collection and oftentimes streaming capabilities just adding to the complexity of data pipeline needs.

Secondly, B M C recognizes that data pipeline failures are often caused by a change to the data or workflow, and people need a way to manage them and catch them or prevent them in the first place. Ultimately, Jane's problem with her pipeline situation was that there was a lack of automation and observability in that pipeline over reliance on manual methods, hampers efficiency and innovation. Unfortunately, doing everything manually just doesn't scale.

Data quality is also a top challenge in data management today. Inaccurate and outdated information undermines trust in decision making. Like we saw in Jane's example.

Imagine you are a data data consumer. Would you use a report if it was inaccurate once a year, once a month, once a week even? What if it showed wrong data?

Perhaps it's out of date. Perhaps someone typed in a typo and it's just the wrong number altogether and you didn't know when it was accurate or when it was corrupted or wrong. If I was in that situation, I would do my best to proceed with my job with the information I had at hand.

But knowing that the data I had was often wrong or invalid would make me very hesitant to act on it. I wouldn't be very sure of the decisions I was making or the direction I was taking, and it would definitely impede my progress and slow me down. I would have to be looking at other data points or trying to validate my ideas elsewhere, knowing that I couldn't rely on just this data.

Would you behave differently? Unfortunately, without DataOps, without data observability, many people are in this exact situation and they don't even realize it. System interoperability and data silos are our fourth challenge on our list to watch out for fragmented data hinders holistic insights and efficient operations.

Different pieces of information fill in the bigger picture, like pieces of a puzzle. With disparate data silos, you end up missing pieces of that puzzle. And with challenges in system interoperability, you have trouble getting and adding those puzzle PE.

With challenges. In system interoperability, you have trouble getting and adding those puzzle pieces to the picture even if you find them. It's not all challenges though.

Fortunately, DataOps brings innovative solutions to help us maximize value from our data. That is what we are most concerned about getting true business value from all the data that we are collecting, storing, and processing because let's face it, it's not cheap to do all those things. Costs us money to collect store and process data and invest in analytics and AI projects, and we want to maximize that return on that investment and really get all the value out of that data that we can.

Turning challenges into opportunities requires innovative solutions. And these challenges we just reviewed illustrate why automation and observability are critical to the success of DataOps initiatives. You need automation to help reduce errors in the first place, and you can use data observability to help you catch the issues that do make it into your pipeline.

We can see here where automation and observability fit into our data ops diagram that we saw earlier. You can see that orchestration really touches all parts from the data sources through the data pipeline to the data consumers where data observability is really critical and useful in the data ops pipelines themselves. Data ops is a transformative force, applying agile engineering and DevOps best practices to our data management and helping us solve some of our biggest challenges today in those areas.

Through data DataOps, collaboration among DevOps teams, data engineers, data scientists and analytics teams, fuel data-driven insights. Three key pillars of DataOps impact are one, data quality, two, business insights, and three, innovation and efficiency for data quality. Establishing guardrails for data identification, collection and analysis enhances your data integrity.

It makes your data more reliable, more usable, more trustworthy, all the things that you want your data to be. Uncluttering, data enables precise insights, driving revenue, generating activity, and DataOps brings cost savings from streamlining data processes which fuel innovation initiatives that can drive growth. Who doesn't like saving money?

I love it. To unleash the full potential data, organizations must cultivate a culture of democratized data, underpinned by unified views, automated processes, and comprehensive data management. You want to develop a holistic data approach, a 360 degree view of data assets underpinned by a data ops methodology paves the way for data maturity.

Now, of course, it might be easy to say you need a holistic data approach, but implementing that can be a little hard, and oftentimes I found that it requires a culture and technology shift to adopt this holistic approach that marries agile methodologies with automation to drive data-driven business outcomes. Now, in many organizations, if you're already using agile methodologies or you've got some DevOps practices of principles in place, it can make it easier to get started on your DataOps journey as well. These are recognizable to many teams and you can understand how the benefits would transfer over from traditional IT domains into data management.

So it's less of a cultural shift if you can show those types of benefits like we've explored here today. Also, a lot of people like getting their jobs easier, faster, smoother. So when you are able to explore the benefits of data ops and particular reducing errors, streamlining processes, and reducing costs, it can be, these can be very helpful tools in motivating that cultural shift as well.

Remember at the start of our journey today, when I mentioned that many analytics and AI projects fail to meet expectations, it was around half. Unfortunately. Well imagine all the cool things that could be if the other half of those analytics and data and AI projects were successful, the impact could be as big as saving your aging parents from cancer or as small as discovering your next favorite band, and DataOps will help us get there.

Our voyage through the realms of DataOps and datadriven excellence has revealed a landscape teaming with potential by embracing DataOps and leveraging automation orchestration and observability organizations. Can steer towards unparalleled business impact together, let's seize the power of data to unlock a future of possibilities. com to join the data ops revolution.

Thank you so much for having me today. In a universe, as vast and complex as the world of DevOps, balance is not a concept to be taken lightly. It is the life force that binds the galaxy of development and operations, uniting them in a seamless flow of power and efficiency.

Or you underestimate the power of the DevOps experience Virtual events, it'll not only enlighten your mind, it'll show you how to bring balance to your D ops world. The DevOps experience will they bear the arcane secrets of maintaining equilibrium between speed and security, automation and manual governance, freedom and compliance. Even I find their methods impressive.

While you may consider PCD pipelines automated testing and container remu tools, I see them for what they are Weapons used effectively, they can elevate your operations to unprecedented heights used poorly, and they become no more than crude machinations Lester in a world of lightsabers, even the dark side requires balance. This is Textron tv. Hey guys, thanks for the throw.

We're here with Martin Mao, who is c e o for Chronosphere, and we're talking about finops and observability and how there's not enough of these two things going hand in hand. Martin, welcome to show. Thank you, Mike, for having me here.

We're hearing a lot of folks talk about finops these days, and there's clearly a lot of interest, especially as the, uh, economic headwinds get a little tougher for certain vertical industries. The question I would have though, is it seems to me there's a lot of folks who just simply forgot how to do fin ups. I mean, we used to do capacity planning all the time, and now we're kind of like struggling.

And every survey I see suggests that there's a lot of interest, but not a lot of know-how, what's going on. Yeah, I, my personal view on things is, I think over the last couple of years in a, in a zero interest environment, uh, perhaps the focus on cost efficiency took a backseat to improving the top line, to building new features. And I don't know if people necessarily forgot how to do it.

Perhaps it was just lower priority on the list of things that every team, every company, every engineering team, perhaps, uh, had to focus on. Uh, I think that changed in the current macro, uh, macroeconomic headwinds. I think that has put the, the finops function, um, and, and the focus on cost back front and center, uh, and on, on everyone's minds.

Now, It also seems to me as once you go down this path, you quickly discover that these, it environments got pretty complex in the last few years, and it's getting pretty hard to figure out what's going on. There's not a lot of transparency. There's a lot of dependencies, and I'm not sure you even know where your costs are.

So we've talked about observability. How do I get in there and correlate what I'm seeing to something that relates to what it's costing me? Uh, a hundred percent.

You, you're spot on there. The, the other trend we've been seeing the last three to four years is this move to perhaps a more cloud native architecture, right? A lot of companies are containerizing their infrastructure.

They're moving more towards a microservices oriented environment. And you think in that type of, of architecture, it's much harder to attribute costs. You know, you are running and using a tiny piece of compute for, for perhaps a fraction of a second or perhaps, you know, a couple of hours, as opposed to in the older world where, you know, teams just had a bunch of VMs and that was their cost.

So I think the problem of even, uh, identifying and attributing cost has become a lot tougher over the last few years just as our architectures have evolved. And observability does play a pretty key role there in the sense that imagine these observability systems, like the ones that we build predominantly are used to tell you when something is wrong in your infrastructure or in your application. However, it also has all of the utilization data.

It actually tells you how much compute is being used for a particular workload there. And that utilization data you can imagine, is key to figuring out how much resources is actually consumed for the workload. And that's a key ingredient into figuring out your efficiency and looking for areas of, of, of improvement.

I'd say We collect all kinds of fascinating metrics in the world of DevOps, but I don't think we have one that says this is how much it costs alongside the performance one. So do we need another tab or window that says, you know, this performance came at this cost and correlate the two? Yeah, I, I, you know, I, I think so, and I think that is, you know, one of the main functions, a lot of these cloud cost optimization, uh, platforms out there.

Um, again, that may have taken a backseat of the last few years, but we are starting to see that become increasingly more popular for sure. And I think to your point, having that view side by side is, is pretty critical. Um, having that view side by side for your infrastructure is pretty critical.

So you can imagine what is my utilization of my compute? Uh, and, and versus, you know, what is the capacity I provision? How much am I paying for it versus the value out of it is definitely an interesting concept, uh, in, in our cloud providers in general and in the compute infrastructure.

However, even when you shift over to observability and when you look at the observability data, same thing applies. You know, increasingly over the last few years, a lot of observability data is now produced. It's very expensive.

You need a similar concept of, or how much is this observability data costing me? What is the value in utilization I get out of it and trying to look for optimizations there as well. So similar types of concepts now need to apply well beyond just the infrastructure that a company runs today.

Can I play what if scenarios? One of the things you wanna do is get in front of this before the workload is deploy. So can I kind of slide things on a scale and come up with a cost factor?

And can we just be generally smarter? That's, that's a really great question. Um, uh, for us in the observability space where, where trying view place, we're definitely thinking about things like that because you can imagine as soon as you've done the changes and, and pay the cost, it's almost too late.

You can only sort of, uh, uh, perhaps fix things moving forward as to prevent these things from becoming outta control. So, um, for our platform, one of the things that we are looking at is as new observability data, uh, does get produced, uh, we do want to give companies an ability to sort of, uh, assess how much that's gonna cost, uh, ahead of time, uh, before they have to end up paying for it, right? So you can, you can imagine you can produce all the data, but before you actually pay for the data, because you may not be using it, you want to give them an opportunity to say, this is what the cost is going to be.

Is this really worth the value you are getting out of it? And have a company make that decision of a yes no call there before they end up having the cost. So the pattern becomes more of a preventative approach as opposed to after the fact, here's your overage bill, uh, and maybe you can do better, you know, for, for, for the next month there, because that pattern, um, generally doesn't work out, uh, as well.

Alright, here's this little thing happening called AI out there. So can we apply that here and, you know, maybe AI will save us from ourselves? Yeah, I think, you know, if you look at the, the latest, uh, innovation in, in the AI space, there's a lot around large language models, a lot around generative ai.

And I would say that innovation in those spaces are probably less, um, uh, directly applicable to, to the problems that that, that we have been talking about more, more recently. Perhaps it could be a better interface, uh, into, into how you interact with some of these insights. Um, but I think that the innovations there in, in, in the past year, I don't know if can be directly applied, um, to the type of problems that we're talking about.

However, I would say, um, if you look at, you know, the cloud cost optimization industry or even the observability industry, there is a lot of automation that can be done these days. So, uh, one example from the chronosphere side is, you know, we are, um, automatically detecting now inefficient usage of particular observability data and suggesting and automating the optimization of that, just like cloud optimization platforms have done for a long time, they can now automate a lot of the optimizations there. Um, now it's automation.

I, I don't know if a company wants to market that as, as AI per se, uh, but, but there is definitely an automation component, uh, to things. I dunno if it's, you know, quite in the same, uh, uh, ballpark or, or or square as, you know, a lot of the, the, the large language model innovation and the generated AI innovation we've had, um, in, in the industry in this past year. Who's driving this spin ops conversation?

Is it the finance people showing up and saying, you know, thou shout and are they really trying to drive down costs or are they just trying to get a more consistent cost level going 'cause they're tired of being surprised at the end of the month? Yeah, I, I would say it's a little bit of both. Um, you know, if you look at the finops Foundation, it was actually creating 2019.

So it's been around for quite a few years. If you look at the Fortune, 50, 90% of them, uh, do have a finops function, uh, there. So it's existed for a while.

And as we talked about at the beginning, I think the, perhaps the focus on it, um, uh, or, or, or the sort of priority to it, uh, dropped in the last couple of years. But this year it seems to be front and center. I would say heavily driven, um, by the finance organizations who are trying to make every company more efficient this year.

Right. That seems to be the headline. Efficiency do more with less seems to be the headline for most companies, uh, in this particular year.

And I would say that's why there's a renewed interest, um, in a lot of these. And when we talk to companies, it's a little bit of both of what you suggested. It's both, can I reduce my current bill right now, uh, because, you know, that would help me, uh, reduce a company's burn, reduce the bottom line there, um, and get a lot of companies towards profitability.

But more importantly than that, which you pointed out, companies really want control over this. They more than just having a lower bill today, they want predictability, and they want control over the fact that, okay, if my business does grow 20% next year, I wanna predictably know how is my cloud infrastructure spend gonna grow in correlation with that? How's my observability spend gonna go in in terms of that?

And we are talking to a lot of finance organizations where they have a calculation, you know, for each increased top line dollar I am, I'm happy to pay x uh, in, in infrastructure costs, or I'm happy to pay y in observability costs, but as long as I have visibility and control over that, over the long run, I think that's even more important than saving dollars today. Of course, everybody wants to save some dollars today, uh, at the same time. So what's your best advice to folks who are trying to implement observability?

'cause a lot of the folks that I talk to, they love the idea, they're just a little overwhelmed by everything, and they're not quite sure how to get it to actually function as the way that they had hoped. And even once they get it, they're not sure what questions to ask. So how do I kind of get this into some realm that it's just more accessible to everyone?

That is a fantastic question. I'll say, um, you know, even explaining why that is happening, you know, as we talked about earlier, the architectures are getting a lot more complex. So the tool sets that worked for us years before don't quite work anymore.

They, they weren't really optimized, um, for, for cloud native workloads, for, for containers and microservices. So I'll say the first thing is probably looking at, uh, a, a, a tool set and applying the right tool set for the right environment and for the right architecture. So if you are moving more towards a cloud native workload for those workloads in particular, perhaps picking a a tool that is optimized for that type of workload, um, would be one thing that would make it more effective.

One of the other blockers we've been seeing, and this is related to cost, is the traditional tools as a company does the shift over to containers and microservices. The, the traditional tools get a lot more expensive. 'cause a lot more data gets produced in these new environments.

So cost is often a blocker. So these tools may be working great, but cost-wise, I just cannot afford to have coverage or all of my workloads or all of my hosts. And that is really bad place for, for companies to be in.

So I'll say from that perspective, um, there's something as, as K Chronosphere joined the finops Foundation, uh, we, uh, released a, a vendor neutral framework called the observability Data optimization cycle. It's a bit of a mouthful, but essentially it's a framework to, to apply, uh, to get visibility over the cost of observability and apply particular techniques, uh, into how to control, uh, that, that growth and data irrespective of what, uh, a tool you have. Um, that there are ways and techniques in which, um, uh, through this framework you can go get control over that growth of, of observative data.

So that could be one thing that could be useful for companies out there to solve that cost problem. And then perhaps picking the right tool for the brand environment would be my other piece of, of advice there. Mm-hmm.

Aren't we still culturally too wrapped up in chasing predefined metrics and monitoring tools and not quite going to the next level? I, I feel like a lot of people are still struggling with, well, I do monitoring, what do I need observability? 'cause doesn't monitoring mean observability?

That's a great question. Uh, I think there are a lot of thoughts in this particular area. Um, my personal view on, on this is, to your point, you know, the buzzword is now observability.

The, the end result of what you're trying to achieve is the same, right? We are all trying to reduce M T T R like we have for the last 20 years, or M T T D, right? We're, we're trying to reduce the time we can detect and resolve issues.

That's the name of the game. And that hasn't changed. Uh, the thing that has changed is, again, these architectures have changed that, that the, the, the, the infrastructure you're running on is so much more complex now than it was before.

And perhaps you need a new tool set to go and, and approach that. Now, that new tool set could be, to your point, um, may maybe not predefined, maybe you don't want anything predefined and you want everybody just to go and access the raw data and go debug your problems that way. That could be one approach to, to the problem.

What we have found working with a lot of companies out there is that approach is, is only effective for certain individuals in an organization, the power users, the folks that know how the infrastructure runs. However, what we find is most of the, uh, the operators of, of services in production these days is the average developer. And the average developer doesn't know how the rest of the infrastructure works because it's, it's fairly complex.

Uh, so, so we do find a need to still have some, I don't know if they're predefined, but have some easier concepts, um, that anybody who's not an expert in observability can pick up and use those concepts, uh, to, to go and debug their systems and, and to go get the job done and not just cater to the power users. Uh, so, you know, my my belief is both exist in the world and the tooling probably needs to serve both audiences. Uh, there.

All right folks. Well, you heard it here. It's an angel of truism.

You can't manage what you can't see. And if you can't manage it, you certainly can't control the cost. Hey, Martin, thanks for being on the show.

Of course. Thank you so much, Mike. All Right, back to you guys in the studio.

This is Textron tv. Hey guys, thanks for the throw. We're here with Morton Rogar, who is c e o for maps people, and we're talking about how three D mapping will actually result in a better application experience for folks.

Morton, welcome the show. Thanks, Mike. Glad to be here.

When it comes to indoor mapping, especially, I don't think a lot of developers give this much thought. I mean, no one seems to really have a keen understanding of the simple fact that people are walking around an office or a mall or wherever they happen to be using applications, then it has an impact on their experience. Walk us through what it is we should be thinking about here.

Yeah, I can, I can absolutely do that. And it's like, uh, you're absolutely right. Like we all, we all know how to use maps on our mobile devices when we are outside, uh, which, like the Googles and the Apples of the world has basically drawn based of driving cars, the streets and satellite photos.

But none of that actually works when you are inside a building. And that's actually what we do. We help map the build world, uh, is, is, is what I would say.

Uh, so we normally take like ca cap drawings of a building and we con confirm, uh, convert it into a map, uh, just like you know it, and then we geo-reference it, so it, it actually works on a map. And then you can actually have a seamless navigation from outside, inside, and inside and out. Uh, and that gives a lot of different use cases.

And what we do here is fundamentally like a platform as a service, uh, because clearly people needs to have an app, uh, for doing that. But that could be the app for mall or for hospital or for a stadium. And that's where you need that map.

That's where you need to give that customer employee experience. That that is easier if you can actually use a map and you can do some way finding and you can find other things and you can see status, uh, on other things. And there's a, there's a bunch of use cases and we do that.

And, and, and that's where our technology stack, uh, allows those applications, uh, to have a content management system and have the APIs, uh, to basically show real time status on a map. Like, is this table booked? Yes or no?

Where is the x-ray machine at the hospital that is currently available? Uh, like asset tracking, stuff like that. So, so this is a little bit what we do.

Does that make sense to you, Mike? Yeah, it does. In fact, in life today, you'll see users kind of roaming around places 'cause they get to know a place and they get to know where the application experience is a little bit better than other places, especially airports.

And it kind of creates an inconvenience. But it seems like people are, uh, adjusting in ways that perhaps we don't need them to have to go to the trouble to figure out if we could actually do the mapping correctly. So who has this conversation?

Is it the developer, the wifi people? Where does this conversation occur and need to be fixed? Yeah, it comes from so many places, uh, right now, Mike, to be honest, right?

But, but, but in the end it's the people that, you know, we have an application that makes sense and we can see that the use case of that application is better if the end user have a map. And these end users can be consumers, it can be employees, uh, it can be it, it can be workers, right? But if we take one step back on this one, if I may, just for a second, right?

Because like digitizing the buildings that we use, uh, for work or for, uh, for, for, for leisure, I would say the investment in technology into these buildings compared to other, uh, investments where you have digitized the processes and the systems and all that stuff for a long time for buildings, it's actually, in my opinion, been underinvested, uh, for a long time. And that is currently changing dramatically. That is being invested a ton of money in making buildings smart so that we can optimize the usage of them, right?

'cause there's so much optimization to be done in the buildings. How can we run them, uh, efficiently? How can we utilize them, uh, to a much higher degree?

How do we make sure we get the most revenue out of the square footage we have if you're on the retail and, and, and the consumer side. So there's a lot of digitization that goes into this one. And, and, and I, that's the concept of smart buildings, making the buildings, uh, smart right now.

And that's what we are helping with. We talk a lot about digital transformation out there, but is this a space that's been overlooked? 'cause a lot of that focus seems to be, well, either it's on an external user at home or it's somebody walking around.

But perhaps we don't think too much about the fact that somebody's gonna be in a building somewhere, whether it's a coliseum or a mall or whatever it might be. But turns out we all spend a lot of time in these places. We all spend a lot of time in these places.

And there's a, there's a ton of use cases. May, may, maybe, if I should give a couple of examples of the, of the types of use cases we see. 'cause then you'll also understand what are the applications that is out there and, and, and what is, what is these developers and software engineers, what is it that they, they that, that they're looking for?

And how do you embed that into the application to give a better experience, right? But like, take something like super symbol traditional, like, uh, sport venues, big stadiums, uh, uh, and other things. How do I find my seat?

Uh, uh, how do I navigate out? How do I find my friend? Uh, and stuff in like that, that's been, that's been going on for a while.

These stadium and sport venues are now putting what we call occupancy sensors in. So you can actually see where is, uh, the foot traffic of people. Even to the extent, if you are searching, I would like to have a BF at the stadium.

It will show you where the shortest line is because we can see, uh, that there's a lot of people in line here. Go to the other one. It's actually shorter.

You have a good experience and they probably sell more beer, if you know what I mean. 'cause you don't have to wait in line. No one wants to pay an expensive tickets and then wait in line.

It actually also goes into, uh, the whole security management, uh, of people, of places where there's a lot of, uh, people gathered at the same, uh, at the same time, you know, uh, from, from, from, uh, where are people, uh, if there's an incident and something like that. How do you basically track everyone? How, how, how do you do this?

Even providing first responders and indoor map, which they probably don't have to 'cause them have stops at the building, uh, just like Google Maps and the other one stops at the building. So these are some of the things offices is getting, like smart offices is getting, uh, a lot of traction, uh, here post covid, right? Uh, uh, and this is really about employee engagement.

How do we engage our employees to at least come to the office, uh, once in a while? Uh, because we know like routine work at home is like as efficient as in the office for most people. At least that when it comes to creativity and working with other people.

Hmm. We all have a lot of zoom and it's actually good to be together 'cause we are more creative when we are physically together. Uh, so you see applications where the, oh, I'm gonna go to the office on Wednesday.

On Friday I'm gonna work with Mike. Where is he sitting? He's in that building.

He's on that floor. He has this desk. And then I find a desk close to you 'cause I'm working with you.

And I can see which ones are available because they're green, real time data on the map. And the ones that are occupied are red. And I pick, uh, one next to you.

And I can even see the type of a desk. Is it like someone that can go up and down or is it close to a window? So you can kind of pick this and you can book a meeting room.

And again, in meeting rooms, we start putting these occupancy sensors in. So even if you book the meeting room, but you never show up for the meeting, uh, then after 10 minutes, the sensor says, there's no one in here. It's not really booked.

I release it so someone else can use it. Then the office managers can start figuring out what kind of office space do I actually need? How many desks and chairs do I need?

How many meetings rooms do I need in order to optimize this? And then you can optimize your office real estate footprint, uh, based on these data while giving a much better employee, uh, uh, engagement experience. If I may say.

So this is, uh, even coming into parking. We have partners who makes application and for parking, like at big campuses, right? Uh, you know, how much time, oh, I'm in this building, then I need to go here, uh, then I need to find the parking spot.

And we always think we are gonna get the one right next to the entrance. So we go there and then we start circling out and then, oh, now I'm too far an now and circling in the employee engagement or guest experience, you just book a book, a parking spot, and you just navigate it right to your parking spot and then you know where it is. And if it's with an EV charger, it can even send, now your car has been charged, please move it to somewhere else so someone can use the EV charger to optimize the utilization of that infrastructure.

So this is the whole smart building. Healthcare is massive right now. Uh, it is really about like, uh, optimizing it Like many places, we don't have enough nurses or doctors and like helping you find where you need to go to get a block test on x-ray or something like that is literally a waste of time of them taking your hand and walking you there.

If the application could just show you where to be and, uh, when to be there, uh, that would be a, a whole different experience. And as I said, uh, even during covid, we have partners who had like UV robots driving around, uh, illuminating the rooms with UV X-rays to basically kill, uh, bacteria or whatever. It's, they do viruses and you need to have a map so they can basically navigate and you can see, have they been there or not.

You can have a map for like cleaning which rooms or toilets has been used. So we need to clean them. You know, in general, toilets doesn't get dirty over time.

It's really how much are they used? Uh, so, so again, this one has not been used today. Let's not clean that today.

This, this one has been used. So you can start guiding that. And then asset tracking, where is the closest x-ray machine that is currently available?

So we start being more efficient in, in, in, in utilizing this, um, public safety, um, schools, uh, public building, uh, emergency response, uh, keeping track if there's an incident, incident. Where are everyone? Uh, are they where they're supposed to be?

Uh, we even have, uh, partners, uh, who have solutions that you can like, use all these sensors to detect if someone is armed. But there is an an incident as well. This is, this is going to be big.

And, and again, imagine fire department. If there's a fire in a building. Uh, I heard somewhere that the fire department in New York is driving around with binders with old cat drawings of the building.

And then you have to like, like imagine that you can give the outdoor mapping experience on the indoor and an application, send people to the right places and see where to go. It just drives so much efficiency in this case. It saves lives, right?

And the last thing that we, that we started looking into, uh, there's actually a lot more, but construction, like, it's all about carbon emission. And I'm, I'm learning new stuff about smart buildings every day. It's so amazing, right?

But one of the most expensive things when constructing a new building is the concrete. And it's actually also the heaviest carbon footprint. 'cause it takes a lot of carbon, uh, to make the concrete.

Now concrete has to hard and it's not harden enough. Uh, then you risk, uh, ruining it and you have to start over. It's expensive and have the biggest carbon footprint.

So they start putting sensors in the room because heartening, uh, is not like a science. It takes 29 days and 31 minutes. It depends on the, uh, air humidity, the temperature, uh, and other things.

So you start having sensors say, okay, now this room is ready for the next, uh, set of workers and constructors to go in and finish the inside of the room. They don't start too early 'cause then they risk breaking it and they have to start all over, right? So it's just like, how do you do this smart?

And then of course we have the whole retail sector, as you said, with shopping malls. There's a lot of use cases and that just being more efficient. So this is a couple of examples that I hope helped a little bit to understand this.

Mike, How do I inject this into the application development process? Because the developers are building the applications. There's a DevOps team that's trying to deploy it and optimize it.

Do they get involved in the front end of this or do I deploy the application and try to tune it later? Or a little bit of both? How does that kind of manifest?

Yeah, so again, we have all the, we have like the APIs for a lot of hardware sensors and software applications. But normally the developers will take our SDKs and basically use the S D k, uh, to embed our indoor mapping capability into the application. Uh, so it's taking those, uh, and, and, and, and clearly we're making them more, uh, more smart, more easy to use.

We even make templates that work for, like, if you are in retail, then use this template of a map. So it's, uh, it's easy to basically, uh, build the visual expression in this. And if you have certain like colors and stuff like that, that you want your desks, so your rooms and everything else to be in, then you can basically choose this.

So making it very easy to use the application. Um, so, so we have all that ready. Then we have, uh, something like I think is super cool where we use some machine learning AI capabilities.

And that is when you have to make the first maps, uh, right. You know, normally you get the cat drawings of a building and then you convert them into a map. And they always come from like in large, uh, uh, buildings or corporation.

They come from like a facility management system. And we can actually integrate into these. And then we get the, the, the, the drawings.

Then we make, uh, the building, we geo reference it so it's put in the right place, uh, and then we give it back. That sounds simple to most people to understand, but maintaining the map, which is part of our services for these application is a massive task. Like, because there's always a lot of updates.

And then we think, ah, how often do we build a new wall, a ted on wall? No, but it's actually also all the logic changes, like in the meeting room, like the facility management understand where, what kind of desk is in there, is a TV screen, is there like a conferencing system, stuff like that. All these logic changes are dramatically, let, let me give you an example.

For one of our largest customer, which is in the financial sector, uh, for the last four months, we have made 5,122 floor updates, which means that we have updated more than 180 million square feet because of all these little changes, physical or logical. And it's all automatic. No one has to touch it.

There's always updated and in real time. And that's a massive burden that you take away from the people that needs to use the application. That has the lag of that has probably also like held back, uh, the, the users of indoor maps, uh, in, in these kinds of applications.

So these are some of the things you get, right? You get the creation of the map, you get, um, uh, you get the maintenance of the map, you have a content management system, so you can drop things in, uh, uh, on, on the app. You don't have to develop that.

Uh, and then you have all these APIs. So you can add, uh, the SDKs for software applications and the APIs for like hardware sensors that you can basically add to your solution that comes as a platform, as a service that fits right into your app. I hope that answered your question, Mike.

Sure it does. Hey, folks, as always, application development has a lot more nuances than you think and location matters. Hey, Morton, thanks for being on the show.

You're welcome. Thank you so much, Mike. All right, back to you guys in the studio.

Discover the cutting edge insights of our new show, AI Times a series that explores the limitless potential of artificial intelligence sponsored by the AI Infrastructure Alliance. The AI Times is at the forefront of the AI revolution, tackling the crucial questions of how we can leverage AI for the betterment of humanity. Stay ahead of the curve as this show delves into all things surrounding ai, including trends, pressing concerns, and the positive impact AI is making around the globe AI times.

Hello, I'm Amanda Razani with digital C X o, and I'm so excited to be here today with Pete Stein. He is the president of Merkel Americas. How are you doing today?

Great, Amanda, how are you? Good. So we both attended the Adobe Summit last week, and I know Merkel was there.

Can you tell me a little bit about Merkel and what y'all do? Yeah, so, uh, first thanks for having me on the, uh, podcast. Great to be here with you.

Um, so Merkel is a company that's focused on customer experience transformation. Um, we help our clients move from a, uh, focus on channel or product to one that is focused on their customer and understanding that customer in a way that only data can enable, um, and then leveraging that data to create the, a connected customer experience across all touchpoints. So that's, uh, that's fundamentally what we do.

Wonderful. And I know with more and more online services and everyone moving online and work going hybrid and remote, et cetera, that is very important. So what's so important about the online customer experience?

I know that y'all work a lot in human-centered experiences online. Can you tell me a little bit more about that? Yeah, sure.

I mean, look, we live more and more of our lives online as, um, bandwidth has gotten pretty much, you know, real time for all of us. And, um, as the, uh, interfaces have gotten easier and easier to use our expectations as people are that we're gonna be able to interact with the businesses, um, you know, that we want to do business with online. And it's gonna be a be a very easy experience.

And, and what we've seen unfortunately in the research tells us pretty dramatically that while, uh, businesses think that they're delivering the customer experience that their customers want, the customers are saying, Hey, you know, the experience is not great and it's not where it needs to be. So that's where we step in to really help the businesses optimize that customer experience and and improve it. Um, I would also just add that the business impact of doing so is very evident, um, that the customers who have a great experience online are, are willing to pay more, pay a premium for, uh, to that brand who delivers the experience.

And also, um, that, uh, something like 37% of consumers will walk away from a brand that they love after one bad experience. So it's, it's more and more imperative that brands, uh, deliver a great experiences for their customers online. Absolutely.

So I know along that note, businesses are trying to figure out how to harness all the data that's coming in, and it seems to be a real struggle. Where are some of the issues and roadblocks, um, occurring and how can this be solved? Well, the, look, I'll say the, the biggest hurdle tends to be around organizational alignment, right?

I mean, first of all, there has to be a clear strategy around the data and how businesses want to leverage it. They have to know what data they want to collect and, and what they want to do with it in order to, uh, enable the right experience. So that's so, so first they've gotta have a clear strategy.

Second, they've gotta have alignment across the different divisions, um, in terms of that strategy. And then, um, in addition to that, they've gotta have the right technology in, in place to enable the execution of the vision, right? They've gotta have the tech that's gonna be able to collect the data, um, bring it together into, um, a a one way that's a clear and simple way to use it.

And then they've gotta be able to activate that across different touch points. And so, um, without a clear strategy around the data, without the data actually being, um, managed in a consistent way and then without, uh, the technology that's in place to enable it, it, it's all of these are blockers, um, for businesses in, in terms of leveraging the data. And we, we still find that today, I would say one of the things we we're seeing is that clients are really investing in the tech.

And the tech is incredibly, as I mentioned, incredibly important to enabling that vision of the, you know, the beautiful customer experience and the delightful customer experience. But without the data, you're not gonna recognize who that customer is. You're not not gonna know, um, which segment they fall into.

You're not gonna know the next right, um, piece of content or experience that you should be delivering to them. And so the, it's, it is, uh, I think it's important to, just to note that it is about the tech for sure, but it's also about the data And combining both that customer experience and harnessing the data. Um, there's a lot of talk about realtime data.

I know you help in that area, especially when it comes to messaging, digital messaging in real time. So can you speak to that a little bit? Yeah, for sure.

Look, uh, messaging is an important part of the journey. We, you know, we, we want to be able to understand exactly the, the context in which a customer is coming to us, um, understand who, who they are, right? And whether or not we've done business with them before, and then be able to, to leverage messaging as one mechanism for being able to help them in their journey, make sure we're getting them the, the product and the service that they need, uh, make sure that they understand how best to do business with us.

Messaging is a really important and effective way to communicate with customers. And again, as you said, like having that data in one place and, and being able to activate it in the right way with messaging is critical. Definitely.

So looking overall at the big picture, that big word digital transformation, many companies are trying to undertake these transformations. What is the biggest, um, barrier that they have? Um, and for businesses that are behind, what do you think is the way for them to get started with digital transformation?

Well, look, I think let's, let's just start with the second question. I think for a business, it's critical to be clear on, uh, to have a vision for where you're trying to go, to be clear on where the business opportunity is, right? Understand what is the business impact that you're driving towards, then it's, uh, important to understand based on your customers, what are the use cases that you think are most central to delivering on that business case.

Um, with, with those two in place, then you can start to build a roadmap for where you're headed. You can start to make sure that you've got the right building blocks, blocks in terms of technology and in terms of data in place. And you can, you can build a, a plan.

Now, to your question of what the biggest barrier is that, you know, a a as we're talking about at the top, digital transfer or, or digital channels have become more and more central. And it used to be that, that digital channels were sort of a sideline. You would go to the website, you would go to the e-commerce store, there was email running on the side, like these, these were new, uh, net new communication channels that were created, but they were not always tied into the core business.

They were not always connected into the store. They were not always, um, connected into the other touchpoint, those more legacy touchpoints that businesses may have had with their customers. At this point, digital is so pervasive that it all needs to be very connected.

And so the, the challenge for businesses is how do they reconcile the two, right? How do they make sure they're delivering a great customer experience? But it is indeed one integrated customer experience.

So getting all of the right players, um, at the table for the business is probably the biggest challenge is, is make, is rationalizing how to take the old way of doing things and the new way of doing things, and then make them one central way of, of running the business and interacting with the customer with, with just different channels that enable different experiences. Um, I think, you know, I, for me, for me, that's the area where we see the, the biggest challenges when we're talking about digital transformation, because it is ultimately it, I, I think that, I guess one other thing I would add, like, this is not just an opportunity to optimize digital. It's an opportunity to become customer centric and everything that you do.

And so a lot of businesses have historically have been very product centric or very channel centric in their activities, and now it needs to be customer centric in everything you do, right? So you have to have a clear sense of who those customers are, um, how the different segments align, and then how you want to deliver experiences to them, uh, almost regardless of channel, but, you know, uh, with, with the channel behaviors in mind Absolutely. About the customer experience.

So let's go back to the Adobe Summit, which is, um, a big topic from last week. And what are some of the things you saw that interest you the most? Um, what were some of the things you were hearing from the summit?

I, I think, look, uh, I would say some of the themes that I heard is, uh, from people is, you know, definitely we're seeing a lot more connectivity across the Adobe ecosystem. It's maturing. Um, they've done a really good job of building that connectivity across their product suite.

So that was, that was a big theme that we're hearing. Um, there was a lot of excitement about, uh, Firefly and generative AI and the role that it's going to play in helping teams. You know, as clients are moving towards personalization at scale and trying to deliver individual experiences and getting the right content in front of the right person at the right time, that requires a lot of, you know, massive scale of content creation.

And so tools like Firefly will help enable organizations to scale, um, exponentially, which is really what everyone needs to do in this digital world as you're trying to get towards those one-to-one experiences. And on that note, I would say the content factory and that, that, that whole, um, experience of creating content at scale was a big theme that I heard. Um, I'm seeing a lot of clients really embrace Workfront and, um, you know, some of the, uh, uh, capability that that brings in terms of managing workflows and keeping the organization in line in terms of who's creating what and um, uh, where, where we are in the process.

So those, those were some of the bigger themes that I heard. Awesome. And now, what is your relationship with Adobe?

Uh, so we are a, uh, platinum partner. We're, um, one of their, uh, largest, if not not the largest, um, agency partner that they work with. Um, you know, we're not only working together to help our clients on this, uh, transformation journey, we're also working on integrating our products with their products to, to help, uh, accentuate, uh, what both of us bring to the table.

So yeah, they're a really important partner for us. Awesome. And, uh, last question.

What do you see for the future of Merkel? Anything in the works? Well, yeah, there's a lot.

There's a lot in the works for sure. Um, you know, it's, it's interesting. I mean, I I, I've been in the business for a while.

Um, and you know, it, it seems odd to say this, but I think we're still early days in digital transformation, uh, or maybe, maybe middle, middle days, but we're certainly not at the end. There's still, uh, a lot of, um, people have adopted digital, um, but, but businesses have not enabled sort of that seamless and, and frictionless experience across the entire journey. Um, and we're very far from, we, you know, if you think about personalization, it, it used to be the, the personalization came from that one-to-one relationship with a salesperson who knew you, who knew what you liked, who knew when new products came in for them, they were gonna bring those to you because they were the best suited for you and your needs.

Personalization now has become sort of a, a cold and distant thing that maybe recognizes your name or maybe knows that you left something in the shopping cart and is gonna, and they're gonna recommend that you purchase those goods. The opportunity with the way technology is evolving, with the way people are starting to organize their data in a way that it's more useful, um, and with the way that, you know, uh, technology like Adobe's is more connected across the entire journey, there's much more of a capability to actually deliver that personalized experience to recognize who that customer is, to know that they're a loyal customer, to understand the products that they've bought from you in the past, to know things about their lifestyle and life stage that can influence the solutions that you craft for them and bring to the table for them. Um, and, and so that I think is, you know, that's very central to what we see in the future.

Um, along with just, just making sure that you are building your business in a digitally enabled way. And, and le not only leveraging digital to create that great connected customer experience, but also thinking about new products and services that you can offer your customers that wouldn't have been available before. I, I think the, the reality is that the world is going to continue to evolve, and it's creating opportunities to develop new business models, to create new products and services that may not have been possible before.

And so a lot of the partnership that we're doing with our clients is to help them understand what those possibilities could be, how they can really, truly have the best possible understanding of who their customer is and what, uh, how that relationship's going to evolve over time. Well, thank you Pete, for coming on today and sharing your insights with us. I look forward to speaking with you in the future.

Thanks for having me, Amanda. I appreciate it. Hi again, everyone.

I hope y'all enjoyed today's episode of Techstrong tv. We had an amazing set of interviews with industry professionals to give you the inside scoop into the tech world. We'll be back again on Thursday, so we hope to see you then.

In the meantime though, if you want more text strong TV content, be sure to check out some of our podcasts or download our mobile app. Thank you so much for watching, and I hope you have a wonderful rest of your day. As always, stay strong.

Text strong.