#261 Low Code Data Science with Michael Berthold, CEO and co-founder of KNIME

Hi, I'm Maggie, VP of Curriculum at datacamp, and I know firsthand how overwhelming it can be to keep up with the rapid changes in data and AI. But staying ahead doesn't have to be hard. That's why our curriculum team has curated the best learning content to help you and your team stay ahead, covering everything from data and AI literacy for busy executives to cutting edge generative AI for developers, and everything in between. Whether you're upskilling yourself or your team, we make learning practical, engaging and flexible. It just works. Power your data and AI transformation journey on datacamp.com.

I mean, there's this democratizing of data science that everybody keeps talking about, and I think low code tools are fundamental for that one. There's this nice quote of someone who said, I don't want to teach my students half a year of programming before they can actually start working with data. I want to make sure they get started doing interesting stuff from the get go.

Hello everyone, this is Adele, data evangelist and educator at datacamp. And if you're new here, Data Framed is a podcast in which we explore how individuals and organizations can succeed with data and AI. One thing that we're very passionate about here at dataframed is the idea of democratizing data science, where data science becomes accessible to the masses within the organization. We've talked a bunch about how culture and skills are essential for driving this, but tools also play a big role here. You can argue low code or no code, data tools are probably one of the biggest drivers of this democratization. This is why I'm excited to chat with today's guest. Michael Berthold is co founder and CEO of knime, an open analytics platform used by thousands of data practitioners around the world. He has co authored several books, is an IEEE Fellow, and a former President of the IEEE SMC Society. Throughout the episode we speak about how low code data science has evolved over the past few years. What are the challenges data teams can encounter in scaling low code data science in their organization, how AI is going to further democratize data science, and a lot more. If you enjoyed this episode, make sure to rate, subscribe comment wherever you get your podcasts. And now on today's episode, Michael Berthold, it's great to have you on the show.

Thanks for having me. Adil.

So you are the CEO of knime. So let's talk about low code data science and maybe to set the stage, how would you describe right now the state of low code data science and how do data teams leverage it today?

So low code data science I Mean, it is used in different ways, and I think we'll dive into that a little bit later as well. But fundamentally the idea is to get data, data science out of the hands of programmers, or at least make it easier so that people don't have to write lines of code for each and every little thing they want to do with their data.

Okay, great. And maybe how do you see it now, the current state, how widely applied is it, how widely adopted is it as a tool within any modern organization today?

I would claim that a lot of people are using some bit and piece of low code data science for some aspects of what they're doing their daily work. But fundamentally it's really about is the low code aspect really only kind of like a wizard or an easier way to create code, or is it really a tool in itself? And I think that makes the big difference. And I think that's also where KNIME differentiates itself from quite a number of other low code tools.

Over the past few years, a lot of the data science workflow has shifted. We've seen a much bigger emphasis, for example, from going from experimentation more to deployment. And given that you're building tooling that really focuses on the data science workflow, I'd love to see from your perspective, how has the data science workflow shifted over the past few years? And where do you see low code data science fitting into that new evolving workflow?

Yeah, that's a very good point. Right when we started doing that, data science was essentially done by small teams in the corner of an organization. It was like the geeks. They were sitting in the little cubicles, nobody talked to them, problems were thrown over the wall, they addressed them, came back with answers. The answers were usually the wrong ones. Nobody really cared about the answers because they were actually interested in different questions. And what really happened behind the scenes didn't really matter. So people were sitting there and writing different types of code, right? There was Sassbase and R&SQL or whatever was sitting out there. And low code really has allowed people to start working with data, making sense of data, without having to go through all of these technological complexities. So I think that's really something that, I mean, there's this democratizing of data science that everybody keeps talking about. And I think low code tools are fundamental for that one. Because there's this nice quote of someone who said, I don't want to teach my students half a year of programming before they can actually start working with data. I want to make sure they get started doing interesting stuff from the get go. And the other piece I think is that there's a bit of this field of spreadsheet kind of wrangling, data wrangling, whatever you call this, and this idea of data science where it's really about machine learning and hardcore statistics, those types of activities have merged a lot of lot more so that you now want to get the people that are actually used to working with data and making sense of data, working with the spreadsheets and doing really sophisticated things in Excel or some other spreadsheet. You also enable them to gradually improve their skillset around the machine learning aspects of it. How can I build a predictive model those types of things? And I think that's where low code allows people to get in touch with different types of technologies a lot easier.

You mentioned something here on the democratization. This is something that we really think about as well, how to make data science accessible to the masses within the organization. I think if you're able to unlock that, you're able to unlock a lot of the value of data science. How do you see this democratization playing out now with low code data science tools? And how has it changed maybe the dynamics and priorities within the data function? You mentioned that merging aspect, right? So maybe expand on that a bit more.

So what we see is that Knime is often now also being used as part of the upskilling initiatives in organizations. So it's really this idea of everybody who wants to make sense of data. I mean, they need to be willing to invest a little bit of an effort. But at the end of the day, you're doing complicated things, but has a tool at the right level of complexity that allows them to get started. And in a sense you're used to writing macros in Excel, but you have a really hard time automating that one. So low code data science allows you to easier automate those types of things. On the other side, you have people that come from the machine learning field, they have a really hard time merging data sets, doing all of the data wrangling because they may not be SQL experts, but they can now use a low code tool to do that part of their activities as well. That kind of brings all of these different groups together and allows them to collaborate within the same environment. I think that's also a huge strength of low code that you kind of. It's almost like you get the SQL expert and the R expert and the Python expert and the JavaScript expert, they can collaborate within the same environment. That's one of the powers of low Code as well.

Yeah, and I love that collaboration angle. And there's one thing that you also mentioned that in the past, data science workflows, where a lot of teams, business teams, come with a request, they would throw it over the fence, come back with the wrong answer. Like you had that siloing effect. Do you see now that the data team's time is on lock to work on more higher level strategic objectives rather than doing analysis that no one ends up reading anyways, because the business user now is empowered as well to fish for themselves and find the answers for themselves.

Part of that is true, right? I mean, at the end of the day, I always compare it to if you don't know what a regression line does, I can make it as easy as possible for you to create one. You will not be able to interpret the results. At the end of the day, you still need to understand what those methods all do, but you don't necessarily need to understand how to make them do it right. How is it done? I don't need to know how these coefficients of the regression line were actually found, but I need to know what they mean. So yes, I think it makes it easier to get that into people's hands, but I wouldn't say now everybody's empowered to run complicated analyses. I think you still need to train people up so that they understand what they're doing.

You've seen definitely successful implementations of Knime from an upscaling perspective. What was the formula for success for a lot of those successful implementations of Knime?

So one of the nice aspects of Knime is that the open source, the analytics platform itself, so the workbench that people build these workflows in the low code environment to actually work with data is free and open source. That makes it a lot easier to be part of an upskilling initiative in an organization because everybody wants to try this out, just try it out. You don't need to buy a license, a seat or something, but you allow people to get started and only when they really want to deploy it, when they want to seriously collaborate, when it really becomes part of their daily work or their quarterly work, whatever, that's when they require a seed and that's when our commercial complement offering comes in and then allow us to deploy that to others, to share with others, that type of stuff.

When you think about the presence of low code data science tools within modern data teams today, how do you see those tools coexisting with the more traditional coding tools like Python or R? What value does low code data Science tools provide versus these tools. And where does the more traditional programming tools provide value? When should you use each type of tool? Essentially, as a data scientist, I think.

They coexist very nicely. And I think this is the point where we should talk briefly about the difference between some low code tools and other low code tools. Because fundamentally, a lot of these low code environments that are currently out there underneath the hood, they still generate code. And at some point in time when you want to really fine tune what's going on, you need to reach into that code and do that there. So in a sense, it's a wizard that makes getting started and writing code easier and just takes care of that. But then fundamentally, you're still dealing with code. And then there's the other class of tools that KNIME is a part of, where the workflow, this visual environment is really the programming language itself. So obviously we're not rewriting everything underneath the hood. It calls out to Python, SQL, whatever, some of these technologies, all of these cool libraries. But if you don't want to, you never need to reach into code to turn a pyramid or something. So you have control over what these methods do, but you don't need to deal with how they do it. However, it's super important that if you do have coding experts in your organization, you allow them to still collaborate with the workflow users. And the way we do this at KNIME is that we allow people to integrate code and wrap it inside a node in one of these modules and then you can expose that to others. And I think this is really the way to have these people coexist and actually not just coexist kind of neutrally next to each other, but really actively collaborate by allowing the people that are writing code and doing maybe it's very customized stuff, accessing a strange little data source that only your organization has. KNIME doesn't have a connector for that one. So somebody writes that connector in some code, embeds it, wraps it into a node, and that way everybody else in the organization can use it.

Okay, that's wonderful. And it really speaks to the importance of a great user experience and user interface here that combines both of these use cases together. Maybe walk me through the lessons you learned over time at naim as you were building out this functionality and catering to that wider data team and all of these use cases, how did you kind of lessons in building user experiences here for low code data science.

So the one lesson I keep learning is so this workflow building, which at the end of the day you're programming, right? You're visually putting together logic, which is what programming is. You kind of design logic is so close to actual code based programming that explaining to my developers from time to time, hey, your audience isn't quite you, right? It's someone who doesn't write code but still creates logic. It needs to have a slightly different angle to it. The user interfaces, the user experience is fundamentally different. That's actually pretty hard to do because it's too close to each other. Right. I mean, it's probably easier to do. I mean, design an ATM interface. You realize this could be my mom standing in front of it or my dad, but for this one it's kind of the audiences are very, very similar because they're building complicated things. So that one keep hammering this one, we are building a tool not for you coding developer, but for someone very, very similar to you, but who's interested in making sense of data. Nudging that obviously in the right direction has been difficult. And then the other piece is of course there's this constant debate of how much granularity do we really want to have. Fundamentally, what we could have is one module like the Swiss army knife that you can configure any way you want to do anything you want to do with data, and then you have a couple of these blocks next to each other. But making sure that the granularity allows you at the workflow level to understand what you're doing with the data step by step. But not forcing people to add a thousand nodes for simple task. Right. Making that balance. Right. There was always a bit of a struggle, but I think they found a nice compromise there.

Yeah, perfect. And maybe can we comment on the speed of learning that you get? Because data science workflows are very complex. Right. And when you learn from how customers are actually learning how to use these workflows that you have on Knime. Right. Walk me through the iterative process of further improving the product. Right. And like the workflow to be able to accommodate all of these different styles of analytics workflows and how people use data in the real world, because it's a lot more messy than just having a workflow. That is very neat.

Yeah, that's a very good point. I mean, in that sense it's very similar to code based programming. Right? I mean, if you want to, you can build a messy workflow that nobody will ever understand ever again. So you need to kind of have a bit of self discipline to make sure your workflow is well designed so that it actually does document what you're doing and doesn't completely hide the complexity at the end of the day, you're absolutely right. Some of the workflows that we see in production are super complicated, right? But the nice thing is, so what we typically see is that when we have new users that are coming from a spreadsheet world or from somewhere else doing data engineering type activities, it takes people typically a day or two to understand, have this mental click that they say, ah, this is what a workflow does and how it works. Because then they are able to say, but if I want to do this, there ought to be a node for that one, right? And then you start finding it and doing that. And what we typically do is that we then come in a couple of weeks later after people started working with Knime workflows and we offer workflow doctor sessions where we essentially say, just bring your workflow that you built and we'll give you advice on this. Oh, I mean, you did this. This is one way of solving the problem, but here's a better way of solving the problem or a different way of solving the problem. Just kind of giving this kind of education a little bit of a polish. And that works extremely, extremely well. And as I said, I mean it's super easy for people. I mean, we have these hackathons where you get people started and guide them to building their first workflow to do a little bit of spreadsheet automation or do something with a bit of AI integration, or do a little bit of data wrangling, depending on where they come from. And then once they do the stuff they used to do in a different, more complicated way, typically using Knime workflows, then educating them about other techniques is then very easy. We don't need to teach them how to do that in Knime. They get that anyway. But we can tell them, hey, by the way, there's other types of stuff that you can do with data and here are the modules in Knime to do that. So from an upskilling, it's a very, very smooth journey. And the nice thing is you keep staying in the same environment, right? I mean we see Knime workflows that just do and just large air quotes because it saves a lot of time, regular spreadsheet wrangling and just gets automated. And now from two days we're down to two minutes. On the other side we see people doing really sophisticated deep learning type workflows that are for quality control and images.

And that flexibility is really interesting. Right? And when you look at, for example you're mentioning these examples of simple spreadsheet automation or even deep learning workflows. I assume here. Depending on the type of team, depending on the type of organization, you may have different challenges when it comes to adopting low code data science and switching to low code data science, whether for an existing data team or expanding it to business users. Maybe. What are the major challenges associated with adopting a low code data science tool in your organization?

It's often almost religious type difficulties. When you walk into a room and you realize people sit in there and it's like, but I want to keep doing this in whatever tool they're using. That's a very, very hard hurdle to get over. Often when we. It depends a bit. Sometimes you talk to these people that are avid coders and they see the power of continuing to code what they're doing, but being able to share that with many more people in their organization. Very, very easy hook. They see the value there. Sometimes it's more the manager of the team that says, pooh, I have these eight people that are all doing wild stuff. If one of them leaves, we have no idea how to maintain this going forward and says, hey, this is all becoming part of a workflow, maybe with some code embedded within. It's something that people can actually build on top of it and keep maintaining. So it depends a lot of the dynamics in the room almost. But fundamentally at the end of the day what we are doing is we're providing people with a programming language. It's a visual programming lang at the right level of obstruction to do something with data. And the moment people get that, it's actually very, very easy.

Yeah, and this is I think goes. You know, you mentioned again the religious aspect here of like a lot of data practitioners. Have one fallen to the trap of always favoring one set of tool for the job for cultural reasons rather than what is the thing that does the job best. And then second thing also like they fall into, I call it same trap here of like resume driven development where the type of projects that they choose as well is dependent on the tool and like wanting to try out certain packages or technologies. Right. How do you work on that as a data leader and try to create more cultural flexibility within your team when it comes to the toolkit to what type of projects and like focus on the value.

Oh, I think that's a problem. Not only Knime has. Right. You always have one. People got hooked to it. When you have a hammer, everything looks like a nail.

Like a nail.

Sometimes I see people building Knime Workflows for stuff where I think, you know, I know Knime can do in. It's a complete programming language. So in principle you can do anything and people sometimes do anything. And you're like, you should not be using Knime for this one. I mean, it's kind of cool, right? But that part, I mean, sometimes we do these hackathons where we try to get people to just explore it just for the fun of it. But that to me is the bigger problem. Getting positioning this, right? I mean, also when people sometimes say, so are you going to replace axles? Like, no, not at all, right? I mean, Excel is good for a lot of things and it's actually often the consumption layer for a 9 workflow and say, hey, for other people to consume to see what we were building as part of this 9 workflow, it's an Excel sheet or it's a PDF reader, I don't really care, right? So we're in the middle part doing all of the data wrangling, automating this one. If it's about a one shot analysis that you will never ever try to do anything like that again, use Excel quilt, right? But if it's something where I say I need to be able to explain that to my boss what I did, or I'm probably going to do this many more times in similar fashion, then it's probably worth building a workflow for this one and getting that mindset into people. But I think that's a problem with pretty much all tools.

I think it's going to be very hard to unsee Excel as at least one of the main tools in any modern professional's toolkit. Maybe coming back on the importance of upskilling and data skills here. You mentioned here how democratization part really rests upon understanding what you're doing rather than how you're doing it per se. Maybe walk us through a bit more the importance of data literacy and data skills when it comes to adoption for these types of tools. And how do you get started as an organization when building kind of that data literacy quotient within your organization?

The second part is complicated because that really depends a lot on your organization. But at the end of the day, as I said, we are building a tool at the right level of abstraction for data workers. So if you have someone who is willing to make sense of data, they're willing to learn how to build these types of workflows and they very quickly see that they can do pretty interesting things with that data. And I mean, you now have a lot of Requests. We see that. I mean we at Knime, we use Knime workflows all over the place to figure out what's going on on our forum, what's the download patterns, where do they come from, that type of stuff. And that just allows you to automate so many things and give people people. So what we do is we provide to people either complete data apps where it's really a web page. You log in, you don't even see the workflow that runs underneath the hood. You can deploy workflows as data apps, but in many cases more powerful is to wrap a piece of a workflow into what we call a component, which essentially looks like a node, but inside the node is another workflow. And that allows you to give people entry points to different views of your in house data. So think about having an organization that has, I don't know, five different CRM systems because they bought companies left and right, they'll never really integrate all of that stuff into one CRM system. But having people analyze that one requires them to have a view, a unified view on these different CRM systems together. And when they buy the 6 company, you don't want to change everything. You just want to make sure that you now has the 6 CRM system be part of that. And that's underneath the hood is a Knime workflow. So we see that often that organizations build, I call that it's almost like a virtual data warehouse. Rather than trying to get everything into this one data warehouse and then you have to change it the next day because something changed. You're just building this one component that dynamically creates these different views. So what we are doing in house is that we have a couple of actually many different components that give you these views on things that you might care about. Right. Users that we have, what's going on technology side, what's going on on the website, that type of stuff that I think is super powerful. Having these workflows as a documentable way to wrap that component. Say this is your entry point to get started.

Perfect. So definitely create templates, make it easy for people to become part of the program. And maybe you mentioned that the second part of my question is harder to solve than usual. But what are you seeing as good patterns for organization kind of building up those data skills that they have to be able to increase adoption?

I would see that as, I mean building these entry points where you say this is a good view on the data that we have to get started with. And the other part is of course providing a Lot of blueprints. So we are providing you with the Lego to build your own data applications, so to speak, or workflows. We are not the ones that provide you the complete solutions. Right. We say, hey, this is it, and that solves all your problems. However, what we do, and that's the Knime community hub where we have thousands of workflows, we call them blueprints that solve similar problems. So if you want to do, I don't know, churn prediction, you find a couple of workflows on the community app that do churn prediction, where you say, ah, this is something that looks similar to the problem I'm trying to solve. I'm going to use this as a starting point. So many, many people that we have don't start from scratch and build workflows, but they start with a template, a blueprint and they say, okay, this is already solving the problem. Okay, my data is not in Oracle, but it sits in some other database. I need to change the connectivity here. Column names are a little bit different, but the rest of the workflow works. And I think that's from an upskilling perspective. Also a very nice way to get there in coding. People do that now as well. A lot more than when I was young. You actually wrote code from scratch now. There's a lot of this copy pasting. Where do I say, here's already a solution to my problem. I copy it over. These coding copilots do that fundamentally as well. They give you suggestions, here's a building block, adjust it to your needs.

Yeah, I couldn't agree. We're definitely going to talk about the rise of copilots and what that means as well for low code data science. But maybe switching back here to the broader low code data science industry. Right. There's different flavors of low code data science tools from tools that are much more focused on ETL analytics tooling, for example, tools that are much more focused on automated machine learning. Walk us through the different sub genres of low code data science tool and where Knime fits in as well in the broader ecosystem.

So we have tools in the low code space. As I said before, they're essentially just wizards on top of code. And just it's not very nice to say there are wizards on top of code and they do pretty sophisticated stuff and generate code underneath the hood. Then we have other players that are essentially building workflows. But as you said, they're focused very much on the ETL part of it, but they don't really support the data science. The machine Learning the actual analytics part of it very well. The reason for that is that some of those tools are really proprietary tools, that it's all written by themselves, so to speak. But at knime, and that's one of the reasons why the Knime analytics platform is open source, we are of course standing on the shoulders of many, many, many, many giants, right? So we have on the ETL side, we have integrations with Spark and lots of other these things in the old days, of course also Hadoop in the middle part for all of the analytics were of course then on the shoulders of tons of libraries out there, some in R, some in Java, some, I mean xgboost, some written still in C that we just call out to. And then on the visualization side, we are using lots of libraries most dominantly. In our case, it's echarts for the visualization. So we're not reinventing all of those wheels. So from that perspective, I think Knime is different in that it covers probably the most complete set from really the entire data science lifecycle, from ingesting the data all the way to analytics and visualization. The one thing you Also mentioned is AutoML. To me, that's a little bit of a different animal because that's really trying to automate the model finding and the parameter optimization. And we have components in KNIME that allow you to do that as well. But some of this AutoML stuff, I'm fairly skeptical about that. If you aren't really transparent about what model you're using, it's often not about the last percent of a percent of accuracy, but it's also about how efficient is this model? Am I going to pay huge computational cost on the production side just to get that last percent? Is that really worth it? So I think fundamentally a lot of automl, I'm totally fine with automatic parameter optimization and model selection, those types of things. The tool needs to be transparent about what it picks and why, so that you as someone who still understands what the models actually use, as you know, yes, I know I get a little bit of extra accuracy, but the price for that one is much bigger. Volatility, for instance, on prediction accuracy when we retrain. So let's stick with the simpler model and pay a little bit of a price on performance. That's something, I think that's a call you need to make and you can't make that if you don't understand what's going on underneath the wood.

There's a lot of nuances around deploying machine learning that goes beyond Just accuracy that needs to be taken into account with these tools. Couldn't agree more. And then, you know, you mentioned here the rise of copilots and the rise of generative AI tools that help with building the skeleton of code that you're building. If you're doing a coding workflows, how do you see generative AI changing or accelerating the low code data science tooling space?

That's an excellent question because we've been pondering that for a while as well. I mean, as you probably have seen, we have integrations in Knime. We have, we call it the Knime AI. That helps you build workflows. It helps you also assist just answering questions. I used to do Baba Vlookup in Excel. How do I do that in Knime? Gives you, you lots of help there. So I think for that it's super useful. It's doing like in many, many other tools. It's a copilot that gets rid of the boring stuff, right? And just takes care of all of that stuff. We also have another element of that one that builds bits and pieces of workflow for you. I think that fundamentally for the easier ones you can probably generate the complete workflow. That's fine. But for more complex data science, I think you will use that more as a step by step assistant where you say, okay, let's focus on the data integration first. Okay, fine, now let's start modeling, whatever and you kind of walk with that. And the AI will just take care of a lot of the simple things. Fundamentally I think, however, is that the huge difference is that a lot of people then think, oh great, I have a solution, all good and you move on. But in many cases when you're building analytical workflows, I think you require are pretty high reliability, meaning that you can't afford that. Just because the AI had a weak moment and hallucinated a little bit, your workflow is creating complete bogus results. So I kind of compare that a little bit to a good programmer that's using an AI copilot shouldn't just copy it over and say yeah, all good, I'm going home and drinking beer now. But should actually verify that the code that was delivered is meaningful. It makes sense. Just like if you have a lawyer creating contracts or something using AI. I think it saves a lot of time to do it that way way, but you should still look through that and make sure it's meaningful. I mean we are using in house, we use AIs to help us fill in RFIs. That's why you get these 200 questions, 180 of those are so obvious, let AI do the job. But at the end of the day we still go through and read briefly, sanity check the answers, and here and there we do make corrections. And from a data science perspective, what does that mean? Do you really want to go in and look at the SQL and Python and R& JavaScript code and validate that it's really doing what you want it to do. And that's where I believe workflows come in super handy, because it's the level of abstraction where you can validate that what the AI built actually does make sense. That helps you at the beginning when we're collaborating with AI to build this workflow to say, okay, that makes sense, makes sense, all good. But it also helps afterwards to document and validate later. So it's almost like AI is for the AI and the collaboration with the human, the workflow is the common language.

That's really wonderful. And go back to that discussion that we had early on about UI and UX for these types of balanced workflow, because correct me if I'm wrong, I do feel like we are converging to a point where the act of coding will be more and more so taken over by a copilot system and then being able to like needing to review, as you mentioned, like lines and lines of code. Right. Is not existing sustainable solution here to check what the output is? And I do select that workflow vision that you paint here of checking the output of every single substep being quite important. And do you find that the user interface and user experience of a lot of the coding tools or Altix tools, whether coding or non coding tools, will evolve over time to accommodate the rise of generative AI. And we're going to have a new paradigm of tools that we work with.

So that's an interesting question, I think.

Yes.

So for coders, I think AI will still be the same type of paradigm where you're reviewing code, but at a much probably more abstract level. Workflows for data type of work are to me the very natural language to collaborate in. I mean the AI, to me we see that in Knime as well.

Right.

We have an AI assistant for the Python and the R and some of the other coding integrations, but we also have an AI assistance for the Echart extension that creates beautiful visualizations. The Echart extension is something where I think in the near future you will not look at the configuration anymore at all to debug that, because from a human perspective, I'M going to look at the graphic and I'm going to say this needs to be red or green. Change that. And it does that from the coding assistant at some point in time, if you really want to be able to rely on that one, I think you are, you will continue to be forced to look at the code at some point in time and validate that it's doing what it's doing. You can then of course do the obvious right and you ask an AI another one, is that what it's doing? The correct way of doing it and you have an even higher chance of catching mistakes. But it's never going to be perfect. If you need to be sure or some sort of a guarantee that what it was created is accurate, you need to look at the result and you need to have a joint language to compare the AI's thinking to human thinking. In a sense.

If you look at now the space in the low code data science tooling space, where do you see the space heading in the next few years? I hate to put you on the spot, so give me some predictions. But yeah, what are your predictions on the low code data science tooling space in the next few years?

I think the low code space where it's underneath the hood still generating code is something that's going to at least stagnate. I don't think these types of tools will completely disappear, but I don't see a huge potential for growth there also because a lot of that type of stuff will simply be taken over by AI rather than putting sort of the simpler stuff together visually and then have that translated to code. I may as well just chat with an AI, have that taken care of. And you see that, I mean, databricks now has this AI built in that does the data wrangling piece. They also have a little bit of a data wrangling workflow builder. I think that data wrangling workflow builder will fundamentally disappear because both underneath the hood generate code. So to me, really on the data working with data space, the common language will be workflows and I think that will take over what people do with data.

And maybe one final question for me, Michael, for anyone looking to get started with low code tools within their organization, what advice would you give them to get started?

Well, first of all, of course sign up for a course at data camp.

Yeah, 100%. Everyone do check out our NIME course on datacamp.

Ideally it's easy as get started. The nice thing is I can now say you don't even need to download it. Anymore to get started. But you can go to the KNIME web page. We have the first version of our online editor, browser based editor. We call it currently the Playground. So it allows you to experience workflows a little bit, start playing with that one, get a feeling for that one. If you really like it, if you think that's the right tool for you, then you start downloading and using it on your own machine with your own resources. That's the best way. Go to the either start with datacamp or start on the KNIME side, play a little bit with workflows, then go to the Data Camp site and attend the course.

Okay, perfect. And then final, final question. Michael, any final call to action or advice before we wrap up today's episode?

I think to me, having some sort of a data literacy, understanding what you can do with data and what it means when you see data insights, understanding what a correlation, what a requirement regression is, or maybe even more sophisticated models is going to be a skill that's going to be fundamentally useful even more in the future than today.

Yeah, I couldn't agree more. Michael. Thank you so much for coming on DataFriend.

Thanks for having me.