WEBVTT 1 00:00:07.799 --> 00:00:09.679 What's going on? Warren? How are you? 2 00:00:09.679 --> 00:00:12.000 You know? I was so totally unprepared for that question. 3 00:00:12.199 --> 00:00:13.359 I don't know what I thought you were going to 4 00:00:13.400 --> 00:00:15.599 say to start off the episode, but of all the 5 00:00:15.599 --> 00:00:18.839 things you could have picked, it was not that right. 6 00:00:19.359 --> 00:00:22.559 Just what a jerk asking someone how they are? That's 7 00:00:23.760 --> 00:00:25.399 oh man. I can't remember who it was. We had 8 00:00:25.399 --> 00:00:28.559 a I can't remember who the guest was, but I said, 9 00:00:28.600 --> 00:00:31.920 you know, there's no like stump the chump or surprise questions. 10 00:00:32.280 --> 00:00:34.960 And my first question what tour was how she's doing? 11 00:00:35.399 --> 00:00:37.000 And she's like I thought you said the would be 12 00:00:37.000 --> 00:00:38.039 no trick questions. 13 00:00:39.880 --> 00:00:42.439 That was Adriana. She was just on here, you know. 14 00:00:45.039 --> 00:00:48.799 Cool. So today we're gonna be talking about AI ready 15 00:00:48.880 --> 00:00:52.000 data and AI governance, and to help us through that conversation, 16 00:00:52.640 --> 00:00:57.600 we have Ina tokodev Sela from a Lumex. You know, 17 00:00:57.719 --> 00:00:58.520 welcome to the show. 18 00:00:59.320 --> 00:01:01.119 Thank you so much. Will happy to be here. 19 00:01:02.119 --> 00:01:04.400 I'm excited to have you here. So give us a 20 00:01:04.480 --> 00:01:07.640 little bit about your background and what led you to 21 00:01:09.200 --> 00:01:12.319 creating because you're the CEO and founder of alumin X 22 00:01:12.599 --> 00:01:14.920 or Alumax, So give us a little bit about how 23 00:01:14.959 --> 00:01:15.680 you got there. 24 00:01:17.159 --> 00:01:20.640 It was a long passway, but also happy about the 25 00:01:20.680 --> 00:01:24.280 way you know that my career took me. I started 26 00:01:24.359 --> 00:01:30.760 an enterprise, SAP, a huge German software company, and I 27 00:01:30.799 --> 00:01:33.519 think this is the you know, the most hidden choose 28 00:01:33.519 --> 00:01:36.640 about enterprise. You can actually have quite an adventure and 29 00:01:36.680 --> 00:01:39.239 then you can build stuff, big stuff right and switch 30 00:01:39.280 --> 00:01:42.560 careers within. So I spent twelve years at SAP, starting 31 00:01:42.640 --> 00:01:47.200 as an architect and then basing evolving into a customer 32 00:01:47.239 --> 00:01:50.040 facing role as a partner manager and then a head 33 00:01:50.040 --> 00:01:52.680 of pen Alpha video analytics units. So quite in the 34 00:01:52.760 --> 00:01:56.799 journey and quite a privilege to work with the world 35 00:01:56.840 --> 00:02:01.640 biggest company. Think about the worldmar builder buying and so 36 00:02:01.640 --> 00:02:05.480 on and so forth, so really washing companies and boarding to 37 00:02:05.560 --> 00:02:09.159 the cloud journey, and then machine learning and then you know, 38 00:02:09.680 --> 00:02:14.199 neural and augentic as well. And then I continued my 39 00:02:14.240 --> 00:02:17.759 career to license as business intelligence vendor and then understood 40 00:02:18.159 --> 00:02:23.000 what an underserved segment of business users actually are. You know, 41 00:02:23.039 --> 00:02:25.400 after building all these analytics for all those years, you 42 00:02:25.599 --> 00:02:27.919 know you're speaking to to the actual users and some 43 00:02:28.000 --> 00:02:30.479 of them are CEOs of the companies, and they still 44 00:02:30.479 --> 00:02:34.199 cannot get the hands on the actual self service analytics. 45 00:02:34.199 --> 00:02:38.159 So this has really moved me to build a company 46 00:02:38.680 --> 00:02:43.719 which creates a space where data could be recognized and 47 00:02:45.280 --> 00:02:48.840 meaningful semantically and business wise to the business users to 48 00:02:49.000 --> 00:02:52.240 enable them to self service analytics and data access. Right. 49 00:02:52.280 --> 00:02:55.639 And so whenever you're thinking about self service data, one 50 00:02:55.680 --> 00:02:59.719 of the challenges I've had in the past is self 51 00:02:59.759 --> 00:03:04.520 service sometimes means guiding yourself to the wrong answer. And like, 52 00:03:04.599 --> 00:03:07.759 one specific example I have is I was working for 53 00:03:07.800 --> 00:03:11.000 a company. It was like, how many how many users 54 00:03:11.039 --> 00:03:14.560 do we have using our app each month? It's like, oh, 55 00:03:14.599 --> 00:03:18.599 that seems like a pretty straightforward question, right, But turns 56 00:03:18.599 --> 00:03:21.879 out it wasn't because then, oh, when I meant monthly 57 00:03:21.919 --> 00:03:25.319 active users, I actually meant people who weren't on the 58 00:03:25.400 --> 00:03:28.080 trial and had converted to paid, but you know, they 59 00:03:28.080 --> 00:03:30.560 were like using it at least three times a week, 60 00:03:30.680 --> 00:03:33.280 not just once a month. And so, like a really 61 00:03:33.360 --> 00:03:37.120 relatively simple question turned out to be coming with a 62 00:03:37.120 --> 00:03:38.800 lot of constraints. So how do you deal with that 63 00:03:38.840 --> 00:03:39.840 in a self service world? 64 00:03:40.000 --> 00:03:44.439 It's perfect question for status data has to be you know, 65 00:03:44.599 --> 00:03:47.560 the state that you can actually create analytics on scale 66 00:03:47.560 --> 00:03:50.919 for many users. So when let's speak about highly curated 67 00:03:51.039 --> 00:03:54.879 dishboards in your intelligence tool. It's no brainer because you 68 00:03:54.919 --> 00:03:57.879 can sell specific data sets which you go to specific 69 00:03:57.919 --> 00:04:01.240 report and make sure that the hecks actually have decent quality. 70 00:04:01.919 --> 00:04:05.400 For companies to have self service on scales and need 71 00:04:05.479 --> 00:04:10.280 to make sure that any potential question could be answered 72 00:04:10.319 --> 00:04:14.039 with a high quality data, you first need to get 73 00:04:14.080 --> 00:04:17.439 your data in order to be able to provide this 74 00:04:17.560 --> 00:04:19.720 kind of service. And the second one is as you're 75 00:04:19.759 --> 00:04:23.480 right to mention single source of truth, right, So definition 76 00:04:23.600 --> 00:04:26.160 what active user is, so how many users do we 77 00:04:26.319 --> 00:04:30.959 have could be defined in dozens of different ways in organization. 78 00:04:31.120 --> 00:04:33.680 If you speak to someone from product departments, they will 79 00:04:33.680 --> 00:04:36.160 go for the active users to actually, you know, use 80 00:04:36.160 --> 00:04:38.959 a product. And maybe if you speak to your financial departments, 81 00:04:39.000 --> 00:04:41.639 it will go to someone who actually signed the contract 82 00:04:41.639 --> 00:04:45.560 with you. So the different ways of calculators things, and 83 00:04:45.680 --> 00:04:49.079 especially for self service, again you're asking about things which 84 00:04:49.160 --> 00:04:52.639 might have different meaning. You have to have governance actually 85 00:04:53.120 --> 00:04:58.759 understanding semantic business definitions of business matchakes and business terms. 86 00:04:59.079 --> 00:05:01.639 I feel like that's a bit of a moving target 87 00:05:01.720 --> 00:05:03.519 from what I've seen in my experience. Like I was 88 00:05:03.519 --> 00:05:06.199 remember in an organization where I'm like, we figured it out, 89 00:05:06.279 --> 00:05:08.439 you know, we we managed to get a single source 90 00:05:08.480 --> 00:05:10.959 of truth for even what a user is. Like, you know, 91 00:05:11.000 --> 00:05:13.720 there's a lot of identity aspects for a user, but 92 00:05:13.759 --> 00:05:15.959 then there's also a lot of business aspects to it, 93 00:05:16.279 --> 00:05:19.959 and like how great of a customer are they repeat customer, 94 00:05:20.399 --> 00:05:23.120 how much they've spent and then you know individual events 95 00:05:23.199 --> 00:05:25.959 related to it, and trying to get a single identity 96 00:05:26.000 --> 00:05:28.079 for that was always potentially a problem. And then you 97 00:05:28.079 --> 00:05:30.639 you know, every team in your organization has their own 98 00:05:30.720 --> 00:05:32.720 idea of what a user is and probably has their 99 00:05:33.120 --> 00:05:36.399 each organization has their own user management service with his 100 00:05:36.480 --> 00:05:40.279 own special data. And I just I wonder how possible, 101 00:05:40.279 --> 00:05:41.879 like if it like if there is a company out 102 00:05:41.920 --> 00:05:45.199 there that actually has good, good data, you know, high 103 00:05:45.240 --> 00:05:49.800 marks on health Scorecard for their data management, Like what 104 00:05:49.839 --> 00:05:51.800 does that look like? You know, is that actually do 105 00:05:51.800 --> 00:05:53.160 you actually see that in practice? 106 00:05:53.600 --> 00:05:57.319 So I would say again, because we're operating in the space, 107 00:05:57.360 --> 00:06:01.639 so naterally it's possible. Otherwise it wouldn't have any customers. 108 00:06:01.720 --> 00:06:01.879 Right. 109 00:06:03.360 --> 00:06:08.000 On the other hand, this is truly changed for many organizations. 110 00:06:08.399 --> 00:06:13.319 And I would also say that agentic practice, so generally 111 00:06:13.319 --> 00:06:16.959 to BI it's another silo, right, So because usually data 112 00:06:17.000 --> 00:06:19.680 management departments that have their own single source of truths 113 00:06:19.759 --> 00:06:24.519 may be implemented in the data pipelines, ls so, calculated 114 00:06:24.560 --> 00:06:26.439 fields and so on and so force, and then analytics 115 00:06:26.439 --> 00:06:29.199 department have their own single source of truth which is 116 00:06:29.240 --> 00:06:32.480 probably in the bi to feature store, metric store, what 117 00:06:32.600 --> 00:06:32.839 have you. 118 00:06:33.279 --> 00:06:36.000 That's an interesting point because we already see that with 119 00:06:36.120 --> 00:06:38.639 the public agents that are out there, they're trained up 120 00:06:38.680 --> 00:06:41.040 to you know, if we're lucky, even six months ago, 121 00:06:41.600 --> 00:06:44.360 and especially things in a business context are rolling very 122 00:06:44.439 --> 00:06:48.319 quickly what the principles of the organization are, or you know, 123 00:06:48.399 --> 00:06:51.360 what features need to be implemented for customers. Those things 124 00:06:51.360 --> 00:06:55.519 are iterating very quickly, and so you know, I'm know, 125 00:06:55.600 --> 00:06:57.800 I'm this is a new problem that I actually hadn't 126 00:06:57.800 --> 00:07:01.560 considered before, and it means models are fundamentally always out 127 00:07:01.600 --> 00:07:04.800 of date. Do the just like your documentation and our 128 00:07:04.839 --> 00:07:07.560 source code, right, it's all legacy as soon as it's made. 129 00:07:08.439 --> 00:07:12.839 Does does RAG resource augmented generation help here to reduce 130 00:07:13.000 --> 00:07:15.639 the changing nature of those things because you can point 131 00:07:15.639 --> 00:07:19.319 to potentially the production data store or is there something 132 00:07:19.319 --> 00:07:24.360 else going on where that realistically you're copying that data 133 00:07:24.399 --> 00:07:27.959 is RAGGED being used against stale data sources anyway, like 134 00:07:27.959 --> 00:07:29.480 you're not using the production database. 135 00:07:30.240 --> 00:07:33.879 It's a fair point if ROG is a separate silo 136 00:07:34.120 --> 00:07:37.240 in the system and you just you know, keep fitting 137 00:07:37.279 --> 00:07:41.079 it with examples which all of the outdated when they created. 138 00:07:41.399 --> 00:07:45.000 So no, RUG is not actually solving the problem. If 139 00:07:45.040 --> 00:07:49.000 you have started site you know as a sidecarrent data science, 140 00:07:49.040 --> 00:07:51.319 it will never leave up to that. But if you 141 00:07:51.319 --> 00:07:56.360 combine metadata management your business ontology and use it for 142 00:07:56.399 --> 00:07:58.959 your gentic properties, is exactly what can be up to 143 00:07:59.040 --> 00:08:00.720 date that point of time. 144 00:08:01.759 --> 00:08:04.040 So the level of overhead to pull that off seems 145 00:08:04.079 --> 00:08:09.000 pretty significant. Everyone feels these pains, But what at what 146 00:08:09.040 --> 00:08:12.279 point do you hit the scale or the quantity of 147 00:08:12.399 --> 00:08:16.040 data where it actually seems like a worthwhile exercise to 148 00:08:16.120 --> 00:08:16.639 implement this. 149 00:08:17.920 --> 00:08:21.079 I guess it's a healthy practice for any size of 150 00:08:21.240 --> 00:08:28.040 organization unless you know, we just want to rely on 151 00:08:28.040 --> 00:08:32.120 on the one developer who maintains your snowflake what have you, 152 00:08:33.039 --> 00:08:35.840 which is which is fine, okay, But but I think 153 00:08:35.919 --> 00:08:39.879 like Organizational Knowledge Way and its documentation was always a 154 00:08:39.960 --> 00:08:43.919 challenge for any size of organizations. To me, it's it's 155 00:08:43.919 --> 00:08:46.519 a healthy habit to actually have it from starters, to 156 00:08:46.679 --> 00:08:52.279 have the you know, knowledge graphts about you different data 157 00:08:52.279 --> 00:08:55.279 structures and the different data sources created from day one 158 00:08:55.320 --> 00:08:58.519 when you actually have data stores. But alway said organizations 159 00:08:58.519 --> 00:09:02.320 which just have one database, so one warehouse, a small one, 160 00:09:02.559 --> 00:09:05.639 I would not necessarily invest in that, despite the fact 161 00:09:05.639 --> 00:09:08.559 that I think it's not a good practice, because right 162 00:09:08.600 --> 00:09:12.519 now we will see flourish of agentic workflows where different 163 00:09:12.600 --> 00:09:15.240 agents going to communicate with each other and they have 164 00:09:15.320 --> 00:09:18.480 to have shared context and reasoning. And the shared context 165 00:09:18.519 --> 00:09:21.840 and reasoning is exactly this knowledge which you should document 166 00:09:21.919 --> 00:09:25.679 about your organization, right so we become more more and 167 00:09:25.759 --> 00:09:28.759 more automated, and we should and this is also a 168 00:09:28.759 --> 00:09:33.559 differentiation business differentiation between companies like if you actually advanced 169 00:09:33.679 --> 00:09:37.919 in keeping your knowledge and building agents around that or 170 00:09:38.000 --> 00:09:38.279 you're not. 171 00:09:38.840 --> 00:09:42.240 Do are there out of the box agents to help 172 00:09:42.279 --> 00:09:47.240 with this or is it completely built custom for everyone. 173 00:09:47.679 --> 00:09:50.279 I don't think it's feasible to really, you know, make 174 00:09:50.320 --> 00:09:54.919 it a max employment manual for any size of organization, 175 00:09:55.000 --> 00:09:57.840 because you know, data is exploding even for smaller companies. 176 00:09:58.279 --> 00:10:04.039 We got this approach of actual predefining ontologies for different 177 00:10:04.080 --> 00:10:07.320 particles and different lines of business and then automated way 178 00:10:07.399 --> 00:10:11.759 to simple metadata from different data sources. Don't stand with 179 00:10:12.360 --> 00:10:16.600 what the specific logic changes for different systems and basically 180 00:10:16.639 --> 00:10:20.759 automatically creates business autology. But I must say to your 181 00:10:20.799 --> 00:10:24.480 previous points, what we discovered as automated on boarding, which 182 00:10:24.519 --> 00:10:26.639 is like a few hours a few days, is that 183 00:10:27.919 --> 00:10:30.759 there are many proflicts of definitions. You might not aware 184 00:10:30.799 --> 00:10:33.960 about that now, but you have ten different views in 185 00:10:34.000 --> 00:10:37.200 your power bi tool where you have the same metric 186 00:10:37.279 --> 00:10:39.840 defined in different ways based on different data sources, and 187 00:10:39.879 --> 00:10:40.840 this is what we discover. 188 00:10:41.159 --> 00:10:43.759 Yeah, that makes sense. I can see it going horribly 189 00:10:43.799 --> 00:10:47.440 wrong asking your technical people about the quality of the data. 190 00:10:50.080 --> 00:10:53.639 We're all technical people, but I guess if you want 191 00:10:53.720 --> 00:10:58.080 to have a business logic, let's say, all those agents 192 00:10:58.080 --> 00:11:01.440 which automate customer support and so forth to be automated 193 00:11:01.480 --> 00:11:06.480 top your data, there should be aligned to sign organizational knowledge, 194 00:11:06.519 --> 00:11:09.080 which is not necessarily on technical size. It's an operational 195 00:11:09.120 --> 00:11:12.559 size side, so it's coming from those departments, not from 196 00:11:12.879 --> 00:11:14.200 us technical people. 197 00:11:14.399 --> 00:11:16.879 Maybe to make this a little bit more concrete, do 198 00:11:16.919 --> 00:11:20.720 you have like some canonical examples of what businesses are 199 00:11:20.759 --> 00:11:24.440 trying to often answer with the storage of their data. 200 00:11:24.559 --> 00:11:28.000 So I would say again, there is no business case 201 00:11:28.320 --> 00:11:32.399 a solid for automation as agentic as, also data compilots 202 00:11:32.399 --> 00:11:35.000 and ergentic and automation workflows, because if you do not 203 00:11:36.000 --> 00:11:39.960 inspired to automation, why would you sort out your data 204 00:11:40.240 --> 00:11:42.879 or why would you sort out your governance? Right if 205 00:11:42.919 --> 00:11:45.279 you don't have automation, like this is a killer use case. 206 00:11:45.679 --> 00:11:48.440 But when you have the CERO killer use case, usually 207 00:11:48.440 --> 00:11:51.919 companies tend to start with more like a knowledge center 208 00:11:51.960 --> 00:11:58.120 and discoveries so basically search right all the customer support 209 00:11:58.200 --> 00:12:02.240 functions on one site. On the site. We also have 210 00:12:02.399 --> 00:12:07.320 like companies and pharma for example Holiday building the digital 211 00:12:07.360 --> 00:12:12.240 health platforms with agents. We have customers and financial services industry, 212 00:12:12.440 --> 00:12:16.200 which which implemented self service quotation for serve party brokers. 213 00:12:16.720 --> 00:12:19.720 So basically is the use case would be always shortening 214 00:12:19.799 --> 00:12:24.279 the time and increasing conversion rates. So there are always 215 00:12:24.480 --> 00:12:28.200 business or metrics for implementing those use cases in the 216 00:12:28.240 --> 00:12:32.440 first place, but internal use cases first and then sell 217 00:12:32.559 --> 00:12:33.399 customer facing. 218 00:12:34.039 --> 00:12:36.080 And just thinking back to all the times that I 219 00:12:36.120 --> 00:12:39.039 was working at companies and they were saying how valuable 220 00:12:39.080 --> 00:12:43.720 their data would be and collected everything just waste and 221 00:12:43.799 --> 00:12:48.759 storage and building up internal tables of just garbage from 222 00:12:48.840 --> 00:12:52.159 years and years back, and realistically, I'm still waiting for 223 00:12:52.200 --> 00:12:54.840 the point where we could be utilizing tools to even 224 00:12:54.879 --> 00:12:59.399 evaluate that effectively, because is there something to this, Is 225 00:12:59.440 --> 00:13:02.000 there an area where it's like, oh no, actually, this 226 00:13:02.720 --> 00:13:06.240 probably highly useless data does turn around and solve a 227 00:13:06.240 --> 00:13:10.399 critical need for the company today with the advent of 228 00:13:11.399 --> 00:13:13.759 agents that can potentially utilize it in a much more 229 00:13:13.799 --> 00:13:17.840 effective way than humans can, or shortly down the road five. 230 00:13:17.720 --> 00:13:22.360 Ten years, Yeah, yeah, I believe so, because most of 231 00:13:22.480 --> 00:13:26.240 organizational data is unutilized, as I mentioned, so we see 232 00:13:26.279 --> 00:13:31.120 that even most advanced companies use mainly twenty percent of 233 00:13:31.159 --> 00:13:35.240 that data on you know, relatively frequent cadence and the 234 00:13:35.360 --> 00:13:41.600 res is unutilized basically, and for that data, AIO readiness 235 00:13:41.919 --> 00:13:45.840 also means that you actually understand few of the health 236 00:13:45.840 --> 00:13:50.159 core components. So startus if it's duplicated, if it's used, 237 00:13:50.240 --> 00:13:54.960 and if it's used by which applications, and if it's sensitive. Right, 238 00:13:55.080 --> 00:13:58.559 so then cent also the risk factors as well. And 239 00:13:58.600 --> 00:14:01.559 then a last but not least, I think it's even 240 00:14:01.600 --> 00:14:04.519 the most important one is what is the semantic meaning 241 00:14:04.559 --> 00:14:09.279 of that? What's actually hidden in this data? Right? And 242 00:14:09.320 --> 00:14:13.600 then that's why knowledge graphs become handy because knowledge graphs 243 00:14:13.600 --> 00:14:16.360 they create or suggested connections. Say, oh, did you know 244 00:14:16.519 --> 00:14:20.960 that additional feature of your conversion score might come from 245 00:14:21.000 --> 00:14:24.759 this customer demographic exparamitter like such and such, Right, so 246 00:14:24.799 --> 00:14:29.519 it's kind of giving you related a data which you 247 00:14:29.600 --> 00:14:33.120 might not encounter so far, like by your experience. But 248 00:14:33.279 --> 00:14:36.039 it's in there. The thing is in there right now 249 00:14:36.159 --> 00:14:39.679 is not covered. So companies usually do not index to 250 00:14:39.759 --> 00:14:43.200 catalog data, which is not used actively for applications. Again 251 00:14:43.279 --> 00:14:47.639 because cataloging was used for compliance and insurance sor to say, 252 00:14:48.159 --> 00:14:51.519 for governance, and now cataloging is small, or we should 253 00:14:51.639 --> 00:14:56.600 use cataloging indexing to actually for discovery. Discovery is semantic mapping, 254 00:14:56.840 --> 00:15:02.000 risk mapping and risk management. And of course also by definition, 255 00:15:02.360 --> 00:15:07.240 agents are better than humans to understand those relations on scale. 256 00:15:07.480 --> 00:15:11.759 I'm also like on scale, say, and then they see 257 00:15:11.960 --> 00:15:14.759 humans us as moderators. 258 00:15:14.960 --> 00:15:17.039 So you mentioned like twenty to thirty percent of the 259 00:15:17.120 --> 00:15:21.320 data is being utilized, So seventy percent is you know, 260 00:15:21.480 --> 00:15:24.519 not utilized. Is that because of the lack of value 261 00:15:24.519 --> 00:15:28.559 in it, lack of it being categorized effectively? Is there 262 00:15:28.559 --> 00:15:31.919 another bucket that I'm missing here? Something there could be 263 00:15:31.960 --> 00:15:34.159 something interesting in it, but no one's taking the time to 264 00:15:34.240 --> 00:15:37.559 actually understand it. Because I get the sense that the 265 00:15:37.600 --> 00:15:39.759 agents aren't going to be able to just see this 266 00:15:39.879 --> 00:15:43.519 uncategorized data and magically pop up an answer of how 267 00:15:43.519 --> 00:15:46.120 it could be valuable there still requires a human to 268 00:15:46.320 --> 00:15:49.960 evaluate it and know that there is something valuable in there. 269 00:15:50.639 --> 00:15:52.600 How it could be utilized still has to be done 270 00:15:52.639 --> 00:15:53.120 by a human. 271 00:15:53.519 --> 00:15:57.399 Yes, it's a good point. So in the databases which 272 00:15:57.519 --> 00:15:59.759 only have some analytics on them and so on, so 273 00:15:59.799 --> 00:16:02.720 first the role of the agent could be suggesting additional 274 00:16:02.759 --> 00:16:08.559 features to look at to take into consideration in databases 275 00:16:08.559 --> 00:16:10.919 where you do not have analytics at all. So, for example, 276 00:16:10.919 --> 00:16:15.159 we have this discussion with the company which never introduced 277 00:16:15.200 --> 00:16:18.399 and this is a huge company which never introduced analytics 278 00:16:18.440 --> 00:16:21.840 for people's departments. There are not dashboards for people's departments 279 00:16:21.960 --> 00:16:24.240 right now. They want to skip the stage of bi 280 00:16:24.399 --> 00:16:27.679 tools and go to self service data copilots to actually 281 00:16:27.720 --> 00:16:30.320 create this analytics to kind of scape the stage. Right, 282 00:16:30.720 --> 00:16:33.759 So in this case the data is supervalable. Of course, 283 00:16:33.759 --> 00:16:36.480 it does have to, you know, to go through automated 284 00:16:36.559 --> 00:16:39.840 labeling and reconciliation and semantic definitions and all of that, 285 00:16:39.879 --> 00:16:42.679 and you know, centrally, we have tools for that now, 286 00:16:43.600 --> 00:16:47.000 but here the case is you had unutilized data not 287 00:16:47.080 --> 00:16:48.000 for the right reasons. 288 00:16:48.440 --> 00:16:52.200 So do you find that after going through this process 289 00:16:52.240 --> 00:16:57.080 that companies actually have less data storage concerns? Because, like 290 00:16:57.360 --> 00:16:59.120 you know, we talk about a single source of truth 291 00:16:59.159 --> 00:17:02.720 and a lot of times I seen where everyone claims 292 00:17:02.840 --> 00:17:05.440 theirs is the single source of truth. So they want 293 00:17:05.480 --> 00:17:08.880 their own copy, their own database servers, their own storage 294 00:17:08.880 --> 00:17:11.640 system because they don't want anyone else polluting it. So 295 00:17:11.799 --> 00:17:14.440 after you go through this exercise, do you find that 296 00:17:14.480 --> 00:17:16.440 a lot of those can be decommissioned and you actually 297 00:17:16.519 --> 00:17:19.240 end up with less data storage overall? 298 00:17:20.880 --> 00:17:23.000 Just a question because single source of just has to 299 00:17:23.039 --> 00:17:26.160 be virtual, so it's kind of a virtual layer which 300 00:17:26.160 --> 00:17:30.160 connects to your operational data source, analytic data sources, and 301 00:17:30.200 --> 00:17:33.680 even applications because there's lots of business logic and application side, 302 00:17:34.240 --> 00:17:38.039 so it's always virtualized. And then the question is do 303 00:17:38.079 --> 00:17:43.960 you even need aggregating layers like warehouses? You know, we 304 00:17:44.000 --> 00:17:48.240 see this question popping up more and more and we say, okay, 305 00:17:48.319 --> 00:17:51.039 so there are probably going to be stages, right, so 306 00:17:51.680 --> 00:17:55.000 some companies are going to reduce Companies like in IoT 307 00:17:55.319 --> 00:17:58.519 your manufacturing space. They might want to reduce the size 308 00:17:58.559 --> 00:18:02.000 of the data to to some warehouse to basically have 309 00:18:02.200 --> 00:18:06.839 more focused use cases, right, more focused and sculpt use 310 00:18:06.920 --> 00:18:11.279 cases cheaper for processing. Right. And some companies who might 311 00:18:11.400 --> 00:18:15.119 have less data will just you know, goal result any 312 00:18:15.160 --> 00:18:18.880 aggregation toll. And what I'm saying less data is because 313 00:18:18.920 --> 00:18:20.759 the storage is not expensive anymore. 314 00:18:21.200 --> 00:18:23.599 I mean, I feel like there's a whole systems thinking 315 00:18:23.720 --> 00:18:25.920 problem here, which is just because it would be better 316 00:18:25.960 --> 00:18:28.319 to have a single sources. Truth, it doesn't automatically make 317 00:18:28.359 --> 00:18:31.160 the organizations you know, migrate to that. I do see 318 00:18:31.200 --> 00:18:35.279 the the XKCD article on the number of number of sources. 319 00:18:35.400 --> 00:18:37.039 I mean it says standards, right, you know, we have 320 00:18:37.119 --> 00:18:41.160 three three databases with user identity, user tracking metrics data 321 00:18:41.240 --> 00:18:43.519 in it, and oh we should have one you know, 322 00:18:43.680 --> 00:18:48.200 unified answer, one perfect database that is sanitized, that is 323 00:18:48.240 --> 00:18:51.640 categorized correctly. And the result is now we have four 324 00:18:51.799 --> 00:18:54.359 user databases, you know, with all the data in it, 325 00:18:55.079 --> 00:18:57.960 and and you know, someone still utilizing those old ones 326 00:18:58.119 --> 00:19:01.359 and to your point of storage still getting cheaper for us. 327 00:19:01.839 --> 00:19:04.759 There is no justifier, and it takes effort, you know, 328 00:19:04.880 --> 00:19:08.839 human time and resources to actually decommission a database. I 329 00:19:08.920 --> 00:19:12.000 can see that just not being encouraged to even happen. 330 00:19:12.200 --> 00:19:14.240 What if there's some something we missed in there that's 331 00:19:14.240 --> 00:19:17.559 still valuable that we could be utilizing to increase our 332 00:19:18.000 --> 00:19:20.480 business even by you know, a couple of percentage points. 333 00:19:21.680 --> 00:19:25.279 So I guess it's a virtualized ontology which lies knowledge 334 00:19:25.319 --> 00:19:27.519 craft which you can connect to many data sources and 335 00:19:27.680 --> 00:19:30.680 indicate which data source and which table call you need 336 00:19:30.759 --> 00:19:34.400 to use for specific vision. To me, is something that 337 00:19:34.680 --> 00:19:39.079 can with the time help you to decommission specific data source. 338 00:19:39.880 --> 00:19:43.079 All in migrating you know, systems to new storages. And 339 00:19:43.680 --> 00:19:48.119 I heard this talk at Gardner last year when someone 340 00:19:48.279 --> 00:19:52.799 was comparing hadup to data lakes or data lake houses 341 00:19:52.920 --> 00:19:54.519 and all of that. Because if you do not have, 342 00:19:54.720 --> 00:19:58.319 like the semantic layer, the business understanding of what's in it, 343 00:19:59.200 --> 00:20:02.920 this big store of data doesn't really solve your problem. 344 00:20:03.000 --> 00:20:06.720 So what's the biggest driver for this is it does 345 00:20:06.799 --> 00:20:10.119 it typically come to you from the business side or 346 00:20:10.279 --> 00:20:14.519 from the technical side customer? 347 00:20:15.720 --> 00:20:18.200 Yeah, I think it's good news for the whole industry 348 00:20:19.160 --> 00:20:25.079 that everything about Argentic is coming from the business side. 349 00:20:27.000 --> 00:20:30.559 And yeah, it's a good position to be in because 350 00:20:30.640 --> 00:20:32.960 this is where money is, right, it's where decision power 351 00:20:33.119 --> 00:20:34.720 is and so on the first and you don't need 352 00:20:34.799 --> 00:20:38.079 to explain the technology anymore, right, you don't need to 353 00:20:38.160 --> 00:20:43.039 explain yourself anymore, because you know, I think it's the 354 00:20:43.119 --> 00:20:46.039 same that what happened with the Internet, and you know 355 00:20:46.319 --> 00:20:48.960 early two thousands with the dot com boom, that the 356 00:20:49.359 --> 00:20:52.680 business side were like super inspired to create e commerce 357 00:20:52.839 --> 00:20:56.519 use cases and what have you. And that's what's happening 358 00:20:56.559 --> 00:20:59.599 with Argentic. It's business side. It's already you know, also 359 00:20:59.680 --> 00:21:03.160 inspire art with all the capabilities of this new technologies 360 00:21:03.200 --> 00:21:05.759 that are actually inventing the use cases and the building 361 00:21:06.079 --> 00:21:10.640 you know, business drivers and calculations behind that. This was 362 00:21:10.799 --> 00:21:14.839 usually the prerogative of technical teams, right to come up 363 00:21:14.880 --> 00:21:18.440 with a new technology and then find a compelling business case, 364 00:21:18.519 --> 00:21:21.400 and now it's the other way wrong. On the other hand, 365 00:21:22.480 --> 00:21:26.839 business so technical teams are struggling on the site to 366 00:21:26.960 --> 00:21:29.640 provide this type of service that the business as far 367 00:21:29.680 --> 00:21:33.039 as to because of law data quality, because of low 368 00:21:33.160 --> 00:21:38.640 data readiness, and because of this multiple definitions where if 369 00:21:38.680 --> 00:21:42.319 you connect agents to them, you know it's it's a business. 370 00:21:42.000 --> 00:21:45.079 Sir, I mean, it really seems like there's the innovation 371 00:21:45.279 --> 00:21:49.680 Here is a fundamental paradigm shift from having business intelligence 372 00:21:49.839 --> 00:21:55.759 and even data centered engineers working within organizations to completely 373 00:21:55.839 --> 00:22:00.119 outsource the handling of any sort of data from your 374 00:22:00.119 --> 00:22:03.000 production systems, because at the end of the day, they 375 00:22:03.039 --> 00:22:05.359 were always sort of a bottleneck for delivering things that 376 00:22:05.440 --> 00:22:07.160 used to be someone's like I need a dashboard for this, 377 00:22:07.319 --> 00:22:08.920 or being able to answer the question of how we 378 00:22:09.000 --> 00:22:11.759 talk about monthly active users, Well, where is that data? 379 00:22:11.839 --> 00:22:14.000 What does it look like, and then figure out utilizing 380 00:22:14.039 --> 00:22:16.359 the tools to actually build the dashboards. Having the data 381 00:22:16.400 --> 00:22:18.400 in a single place all that had to be solved, 382 00:22:18.480 --> 00:22:21.759 whereas now those teams don't necessarily need to be working 383 00:22:21.839 --> 00:22:25.119 on that anymore. The data starts in the original application. 384 00:22:25.200 --> 00:22:28.039 You don't want a middle layer. You want it given 385 00:22:28.119 --> 00:22:31.000 to companies that understand how to sanitize it, what's relevant, 386 00:22:31.359 --> 00:22:34.000 where the insights are, and providing an interface for those 387 00:22:34.079 --> 00:22:37.039 asking the questions to directly interact with the data in 388 00:22:37.160 --> 00:22:40.079 an understandable way, rather than looking at dashboards that are 389 00:22:40.119 --> 00:22:42.960 out of date or configure some ultimately utilizing tools that 390 00:22:43.480 --> 00:22:46.240 just don't really work that well because there's there's too 391 00:22:46.279 --> 00:22:49.279 many degrees of freedom, too many variables, too many columns 392 00:22:49.359 --> 00:22:51.920 or pieces of data that all needs to be displayed 393 00:22:52.079 --> 00:22:53.440 depending on what you're actually looking for. 394 00:22:53.839 --> 00:22:56.559 Yeah, it's a good point because a majority of foul 395 00:22:56.599 --> 00:23:00.400 decisions are ed HOLC decisions on aed hoc questions. I 396 00:23:00.480 --> 00:23:04.039 do believe that we'll still have space for KPIs and dashboards, 397 00:23:04.200 --> 00:23:06.480 Like I am starting my day with you know, Google 398 00:23:06.519 --> 00:23:11.559 Analytics and Salesforce and all of that, but I also 399 00:23:11.680 --> 00:23:13.960 have like a bunch of questions which are not in 400 00:23:14.079 --> 00:23:17.799 those reports, and it is actually changed with the data 401 00:23:18.000 --> 00:23:19.920