DevOps and Data Management Convergence with Foundational’s Alon Nafta

This is Textron tv. Hey guys, thanks for the thrill. We're here with Alan nafta, who's CEO for a company called Foundational, and they just announced that they are not only making their product generally available, but they have raised $8 million to fund the development of it from here.

And we're talking about a new way to manage data, which I guess given our current situation with AI, may be a little overdue. Alan, welcome to the show. Hi.

Thanks for having me, Mike. Great to be here. Explain, if you would, what is the fundamental problem we're seeing with the way that we approach data management today?

And then how are you guys taking a different approach to it? Uh, yeah, thanks for the question. I mean, there, honestly, there are quite a few problems.

Uh, the one that we are targeting is the one where, uh, developers of all shapes and kinds, uh, throughout, kind of like the value chain of data are pushing code, uh, which is usually what they're hired to do. So they write, uh, and want to deploy code that manipulates data at a certain stage of the data lifecycle. Uh, and normally today because of how data is process transformed, consumed, and whatnot, and because it's really distributed across different teams, they don't really understand how that change is going to impact the data and whom is going to get impacted across that chain.

So just to kind of like really simplify it down, someone makes a small, small change. The smallest change, they would change a name of a field or a name of an event, or they would remove something from the schema and that ends up breaking something somewhere. And the developer kind like had no idea, uh, that, that that is what it would do.

That is happening all the time, both because data is somewhat complicated, but also because, uh, today because of that distributed nature, uh, it's really not checked. So the code is not, is not checked. And as opposed to software engineering where we have compilation and CICD and and end-to-end testing in data, that is really not the case.

Uh, so this is what we're focusing on, and we help those developers check and validate their code and understand who are they impacting downstream and, and, and make sure that it doesn't break anything. How does that work in the context of, say, a larger DevOps workflow? Because this issue's been around forever and a lot of these processes intersect, but they seem to be different in every company you visit.

So, so that, that's a really good question. I think that we're used to having DevOps and specifically CICD when we're building software products, but in data that has someone did not make it kind of like to the mainstream. Uh, anecdotally, you do have some processes if you are working within a specific platform.

So if your, uh, organization works with a product like Databricks, uh, there are some tests that you can do within Databricks environment. Uh, if you have a product like DBT or Snowflake, there are some things that you can do there. Once you have data that goes from let's say, uh, uh, an S3 bucket into Databricks and then to a Tableau dashboard, that cross is my what, what makes it hard to test.

Uh, and the way our product works is we're integrating ourselves, uh, to the, uh, to the GitHub kind of like workflow, GitHub, GitLab. Uh, and we essentially kind of like augment, uh, those checks that normally you would have something that does or you would need to write yourself. And, and, and that's how kind of we check the code before it's being checked in, before it goes to production.

If I understand this correctly, it's essentially another type of gate in the workflow that lets me make sure that whatever changes were made to the data or consistent with some sort of master data representation or golden file or something, or how do I know what's what? Uh, yes and no. It is, it is kind of like that thing in terms of being in the place that you described.

It doesn't actually look at your data. Uh, we look at the code. We, essentially, what we do is we check your code statically, dynamically, uh, and whatnot.

And we essentially kinda like add this step indeed, kind of in your deployment step that makes sure that the project would compile, if you will, uh, would compile and walk correctly, uh, with, with all the other components, kind of like in your, uh, in your stack, uh, which can be quite a few. Uh, and then we tell you, I mean, it's, it's a gate in the sense that we will tell you, Hey, you're going to break something, or you, you can kind of like go and define your own rules to say, okay, if that person in the organization is going to, uh, I dunno, do something of this nature, then I want to make sure that someone reviews it right. Or I want to make sure that that doesn't go to production with, without someone, uh, looking at it, uh, again or code reviewing it, right?

Even the notion of code review in the data world, you'd be surprised, but sometimes it's just not the norm. Uh, so a lot of code is not being peer reviewed by, uh, by other folks in the team. It is something that is getting more, more, uh, kind of done more often, but not always.

Uh, that's the case. We've seen the rise of data engineers and organizations, but I feel like a lot of times there, it's a different culture than the DevOps culture. So do we need to bring these things together and, and how do we go about doing that?

So that's exactly the thing. Uh, when you look at the folks that build code for data or develop for data, uh, you also have the software engineers because usually that's where the data is collected from. It's collected from your, from your platform, from your product.

Then you have data engineering, uh, in all shape and forms, sometimes, uh, kind further along, uh, folks are calling them also analytics engineering, uh, which are responsible for like data pipelines, ingestion, transformation, streaming and whatnot. Uh, and they are, at least if it's data engineering, sometimes they don't report to the software engineering organization. They report to the data organization, which has its own tools and doesn't necessarily need to conform to the tools that the software organization is using.

And then you also have the business facing analysts. So they would normally report to the data organization. Sometimes they would even report to other organizations such as kind like the, the domain specific.

You know, you have an analyst reporting to sales and analyst reporting to marketing and whatnot. All of these organizations are essentially pushing code that needs to comply with, uh, what you want in the organization that needs to adhere to certain quality standards, to certain checks and whatnot. And, and this is essentially where a foundational in.

Do you think that the rise of AI is gonna force this conversation? Because I feel like this problem's been around to varying degrees for years, but maybe we're reaching some sort of tipping point? I think that the rise of ai, from our kind of humble point of view, uh, uh, definitely made it seem more of an urgency, uh, starting with the large organizations actually.

Uh, I mean there, there is some aspects of AI that actually looks more at unstructured data versus structured data. Uh, so, so in a sense, what we typically work on is, is more of the data product, kind of like thing, data products, data platforms, but I think it all connects together. I think that a lot of organizations now in this kind of new phase of platforms and tools are realizing that data has a lot of value, both for ai but also for data products, uh, that are now being kind of like used with, uh, with users and customers and so on.

Uh, and that has made just data urgent, uh, data quality, uh, and also governance, uh, a much bigger priority for organizations today. Uh, and, and the manual work that was being done in those areas, let's say 10 years ago, not several manual, maybe not, not completely manual, uh, today with the volumes and with the multiple tools, it's just not scalable anymore. A lot of the business executives that I talk to don't always trust the data.

So have we got to some point now where we need to be able to make sure and verify that the data that we are using to make these decisions is trustworthy? Because a lot of times the business people who enter the data in the first place, and they know how sloppily it was done, That's exactly the point. They, there, there's a trust issue because, uh, there are a lot of surprises that, uh, that ultimately kinda like impact your, your ability to trust what you're seeing, right?

So suddenly it changed day after day, it changed from yesterday to today, and no one understands why, because someone changed something or now the data comes in and it's not actually validated, but the business person knows that now that metric is not what it's supposed to be. Uh, so there is a trust issue. And we think that a big part of the trust issue is because today all of those folks that are touching the data, if you will, which is, which is by design what does supposed to do, uh, they don't, they don't check kind like their work in a sense, and they don't have good predictability of kind like, okay, I'm going to do this.

What is it going to do? Who is it going to impact? Right?

So, so there, there's a lot of elements for trust that you want to improve to, to get to that place, right? When people actually kind like, not just use your data because that maybe you can enforce them to do that, uh, but also trust the results and, and kind of are confident in what they're doing. So do you think data management is about to have its moment in the sun?

Because we've been dealing with these issues for decades, and it was always kind of like maybe on the back burner somewhere. I mean, it's funny, I've been talking to, uh, to folks that have doing kind like not similar products, but products in that space and, and it's kind of like it repeats itself every 10 years, right? Like folks that, that you tell them, oh, I do this and I check your code, and oh yeah, we did that 15 years ago, but the tools were different, the systems were different.

Maybe the scale was also different, less cloud, uh, and whatnot. Uh, so I think that it's a cycle. I think that right now, uh, there's a lot of focus on data management, which includes change management, data quality, uh, things like data contracts, which, which are getting popular, uh, and of course, of course data governance.

Uh, and it's needed because today a lot of companies really want to utilize the data that they have, the ability to collect a lot of data has continued to increase. So that has become like a big part of your IP now, and you can actually leverage that data to build better products to expose that and ultimately to increase LTV and whatnot. So I think that the data management thing is, is playing a big part of that.

This Seems to me to be as much a cultural issue as it is a technical issue. So how do I approach that part of the equation? Do I just put everybody in a room and lock the door and hope something good happens?

Or is there a smart way to do this? So that's actually what people have been doing. Uh, what I like to think before foundation, not necessarily in a room, but in a virtual room.

So the process to go now and manage a change was to put everyone in a, in a teams channel or in a Slack channel and say, Hey, Mike, I'm going to push this change on Thursday, or maybe not on Thursday, maybe on Tuesday, uh, and, and, and kind of like heads up, right? This is what it might do. But then you have a lot of folks and the organization is scaling and, and you just have too many of these, uh, quote unquote virtual homes.

Uh, so we do think that there's a big technology aspect to, to managing those processes. And again, we, we, we look at our friends from the software engineering space. I mean, those folks have been building and are building, uh, kinda like multi products or, or multiple products with multiple teams in, in, in a good kinda like process that works also from the technical side with DevOps and with multiple cloud environments and staging environments and whatnot.

So there's a lot of things that I think we can learn, and that's, that's kind of our philosophy in foundation and a lot of, a lot of portions that essentially see, okay, this is how folks are doing that for software engineering. Let's just find a way to translate that to the data people. Uh, and, and obviously it's not gonna be one-to-one, but it's going to be philosophically kind of similar, uh, in, in in the approach.

Hmm. Well, now that you're shipping the platform, what's next? Where do you go from here and what should we look forward to?

Uh, so today we have the ability to really go in and look at large environments and understand all the dependencies and really kind of like tap into the code changes and give that visibility to folks, find those issues before they make it into production. I think that in terms of the near term future, it's really about scale, more and more types of environments folks are asking us for on-prem, uh, because a lot of kind like those legacy systems that that usually we don't have visibility to, to, uh, to our, uh, self-hosted. So, so, so far we have been SaaS and cloud and, and now we're gonna do on-prem.

Uh, and a really exciting thing that, that, uh, we're looking forward to is also bringing more portions of AI into the process, kind of like the co-pilot, uh, uh, equivalent if you will, into the data space. So today we actually find and suggest, uh, kinda like what you should do, but tomorrow we can also, uh, do those fixes ourselves or kinda like make it a lot easier for you to actually, uh, go and change something, suggest other optimizations that you have. Cloud cost is a big deal.

A lot of folks are asking us also to look into the cloud cost optimization because you can do a change and now it's going to spike up your, uh, uh, Databricks or Snowflake bill, right? And that's also a type of an issue, uh, that people are dealing with, especially public companies. So a lot to do in that category of data management, and we, we look forward to working on those problems.

Hmm. I think it's no secret that there are a lot of fiefdoms in IT organizations. Do you think as we go along that it's really gonna be about making those fiefdoms work better together?

Or are we on the cusp of kind of reorganizing and fief thems all together? Uh, I think it's the former. I think that people can work together in a, in a better way, and I think that technology plays a, a big part in that.

Um, and, and I think that there's a lot of indeed like alignment to be done, especially when, when folks are kind of building things in parallel. Uh, so I do believe in the approach of taking what you already have, right? Taking those organizations that already have a certain structure and giving them the tools, uh, to work together in a better way that is very much like integrated to how they work today.

So not changing the tools that they go to and the screens that they look at, just making it easier through technology to keep working, to keep doing what you do, not forcing you now to change something very structural. All right, folks, you heard it here. It's all about working better together.

And part of that is just maybe getting out of each other's way by automating more stuff. Hey Alan, thanks for being on the show. Thank you so much, Mike.

It was great to chat with you. All right, and back to you guys and Steve.