Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth, I'm lead advisor and senior analyst with KuppingerCole Analysts. My guest today is Alexei Balaganski. He is lead analyst with KuppingerCole.
Hi, Alexei. Good to see you.
Hello, Matthias. Thanks for having me again.
Great to have you, and we will be talking about a topic that we slightly touched in an earlier episode, but we want to have more focus on that for today. We want to talk about low code and the question why low code should not be low efforts, so that that's the starting point. What is low-code slash no-code in that context, Alexa?
Well, let me kind of start a little bit from a far you've probably heard about the guy named Constantine Stanislavski. Who's like a famous Russian theater director and the inventor of the method acting he wants to say it or a hundred years ago that whenever your stage, your play for children, you have to be at least as good at it as if you're doing it for adults and even better.
And at least in Russia, and this has become like a guiding principle for doing things for children, obviously, and not very skilled people in general, like you have to, when you're doing something for them, you have to be at least as careful as for the adults or the specialists, but probably even better. And this applies to anything right in books, cooking, and obviously it as well.
And this is why I think it's relevant for this whole citizen development movement, which has emerged in the recent years, this idea that a company should no longer invest money into dedicated software development teams and processes, and then start, let's just normal business people, coding skills, create their own applications to solve some menial tasks, to create maybe reports doing small calculations, stuff like that.
So instead of submitting a formal request to our development team, and then waiting for two weeks, you just open and a little code or a no code tool, do your work maybe in an hour, then you're done great idea. A lot of buzzing around this, a lot of marketing effort in the recent times. So kind of low-code slash no-code is a huge thing. A huge buzz word. People are talking about almost like zero trust and stuff like that.
Right?
How, how should I think of, of low-code no-code platform? Are they comparable or are they something like I used to use for years now? Something like if this, then that or the, the power apps that we have on Microsoft 365, where you more or less create applications by dragging and dropping components to each other, is this the, the, the, the notion that this password comes with?
What, what's the thing exactly the problem we are going to discuss today, right? Because just like many other words, words like zero trust or cloud or big data before that different vendors, different customers know different people in general have very varied expectations of what such a solution should be able to do. And especially for marketing people, it's basically means a convenient label to slip into an existing product and try to sell it for a different audience without putting a lot of effort into actually make it useful and easy and secure.
So yes, all the things you mentioned are basically local tools, but I believe in that regard, well, if you create a macro in an Excel table, it's also low code, right? Because you don't have to learn the language, you just hit a button to record your steps, and then it's done. Some companies go even further and they would say, okay, we have this wonderful, conversational AI, a chat bot. You just tell us what you want to do. And we'll do it for you, which is low code and probably no code at all.
And others go and say, okay, we have this powerful, robotic process automation platform, which is like enterprise grave and cost, probably hundreds of thousands of dollars, but you don't need to know Python or Java for it. So it's also a low code tool, or the problem is that everybody has a different understanding, but all of those solutions have one major problem. They are essentially existing tools repackaged to the new label.
Okay. Understood.
But the, the main idea behind that is to get the developer out of the equation to, to have the people who actually know the, the, the business aspect, the technical aspects behind what needs to be accomplished, do it themselves, create the software themselves that sounds promising and, and maybe even money savings. So, so where are the, the issues that come into place when you, when we talk about creating software, just like this.
Yeah. That indeed sounds awesome.
Because, or if you ever had an opportunity or have you ever been cursed, they need to talk to a developer and explain your own domain knowledge and explain, like, for example, an accountant would have to explain to a developer how to conflate Texas, or I don't know, a scientist would have to tell a developer how to parse chemical equations, stuff like that. That's extremely difficult to tell the person who is, who has no idea about your domain knowledge might have the coding skills, how to do basically your job.
This is why this whole idea of becoming a citizen developer and learning something easy and convenient instead, and do your own job yourself is so promising. In theory, the problem is that with too much power comes to the greater responsibility or what was it that Spiderman said, the problem that the tools which are now being offered solution for those students and developers are sometimes way too powerful and allow you to break everything.
And this is exactly what we see.
For example, in the recent publications, just a couple of weeks ago, we had two related accidents with one company that's been Microsoft first to learn that their power apps platform was compromised because essentially you can create a business application or you can upload your sensitive data into the data platform. You can even configure authentication and access rights to the application, but due to a misconfiguration or over data would still be freely available to anyone through an API and saying, it's all those applications are hosted on the same domain.
And the API end point is known as security or social work, able to identify or thousands. I believe freely available databases. It's sensitive information, ticket data, healthcare records, and stuff like that. Although things which citizen developers would love to put into their handmade apps and all those data could be leaked stolen, exploited you name it.
And at the same time, a similar problem happened toward a different product from Microsoft. This time being a cosmos DB in a database, basically a few years ago, Microsoft decided to throw in a free add-on Jupiter notebooks.
So every time you create a cosmos DB instance, you get this free visual environment where you could just run your simple code and execute dynamically. And again, this was enabled by default for our customer without any security tools and controls in place. So in theory, anyone could compromise your data, steal your secret keys, and then do whatever they want your sensitive data. And this is just one company within one week who knows how many other similar scenarios fasting, waiting to be discovered.
Okay.
But when, when we look at the two aspects that you already mentioned, first, the, the term is not yet clear. So there there's, this label is applied to lots of different types of software, which are sometimes even just these guys as, as low-code no-code. And on the other hand, the power and, and the, the, the, the level of, of task that can be achieved. So we have already two issues that, that are some, some obstacles to the usage of low code, no code or a certainty citizen developer work within an organization.
I remember talking to Annie Bailey, our colleague about AI and BI, and also there was this AI support for business intelligence for creating, for leaving out the, the, the business analyst out of the equation, but putting lots of power into the hand of the, of the, of the end user of the, of the business user. And there were also some kinds of low-code no-code tools here in place. So that would deal with massive amounts of data and putting them at danger, as you just described would be a real threat. So how can you as an organization do things right?
Or two things at least better when it comes to creating these types of software, are there recommendations things to do? What, what should I do? Because the idea is, as you said, brilliant, put in enabling the, the business user, but how to do that. Right.
Well, as I just mentioned, at the beginning of all of this discussion, the biggest challenge I believe is that the vendors and they put an equal sign between low code and low effort, or apparently the idea that one of the biggest advantage of a local to no code solution, it would be easy to use, which is technically true. But again, if you just creating a weapon, which is extremely easy to use, and anyone can fire it, that's still not a good reason to give it to a child, right?
So this, this logic applies to this development tools as well. This is truly a massive potential security and compliance risk for any company. So it has to be treated perhaps even as a part of critical infrastructure, even more so than let's say, an API gateway or antivirus solution. Because again, those later tools are operated by security professionals and the low code isn't a local platform is not operated by professionals.
It's designed to be used by a gay quote, unquote, citizen developers and guided and unsupported by 80 experts.
So it has to be at least secure and compliant ever, proper enterprise tool and even better. Otherwise, if you do not follow this principle, you will end up with a huge shadow it problem, which would dwarf the challenge.
If you have risk clouds, you know, it things like Dropbox or anything like that, because if you have a tool which anyone can use, and anyone can, for example, self provision to themselves, and then use this tool to connect to several critical systems, HR, finance, customer data, and then just run a script to download all the data, supposedly to make a report, but also to leak it to a Hecker, what, what are you expected to do, who will be responsible for that? And again, this is not a fantasy. This is what happened earlier, and we have multiple examples of those things happening.
And unless there is something in that software, which would inherently stop it from happening, it will happen again.
And did you just mentioned three examples, you mentioned HR data, and you mentioned customer data and combining that, having access to that, mixing them that within one application, creating new types of reports, you don't need, you don't need a breach for that being dangerous, because that would most probably already be an issue when you look at data protection regulations, because there won't be content for this specific usage of this data, especially when it's customer data or employee data. So that would be really an issue without even having a breach.
So these new types of processing you've mentioned that as, as, as shadow it as shadow programming, should the shadow citizen development. This is an issue in itself.
So, and you've mentioned the eye shadow it when, with regards to cloud, the promise of cloud was to get to infrastructure very quickly without the cost. Now we have getting to software very quickly without the cost, but we, as security professionals would say, okay, do things right. And that might take longer if you want to do it properly. Right?
Well, as we have learned a lot of times before getting to a resource quickly is not a goal. It's just a means to solve a business problem that gains the problem by solving this business challenge.
Okay, how do I run my calculations quickly? Or how do I crunch my customer data and find patterns or whatever, how do I send the file to an external person when it's not handled properly when it's not secured properly, it inevitably becomes a huge risk and the huge kind of potential compliance, boredom, and the gain in the gain. I have to repeat that for citizen developers, for people without coding skills. And of course, without security skills, this is a much bigger problem, potentially for quote unquote professionals. We all know that developers and security experts can make mistakes.
If they've learned from examples like Amazon S3 debacle, which actually continues for years because of insecure default configuration, it will happen the same and will happen more and more if, for example, at some time, Amazon would offer a low court tool for accessing that data.
So it has to be ideally it has to be presented in advance. So we often talk about security by design or privacy by design, and all those principles have to apply here as well and much more in a much more strict and comprehensive manner then for professional tools.
And of course it has to be part of a secure infrastructure. It has to be part of our security stack.
So if, for example, you are a low code platform to a database. The database itself has to be secured. The API APIs have to be secured because this was probably be the way for excess to pulling the data from the database or the UI has to be secure so that nobody could inject a crypto miner or a credit card stealer into it. But there's lots of things to consider, which are, which already exist as separate tools, just kind of nobody can expect your HR or accountant or, or in your line of business person to even be aware of those tools.
Well, either you have to look for, to manage the solution, which has all this kind of delivered to you on a plate, or you have to make sure that your it department builds this environment for the features and developments first builds tests, whether it's vets and then kind of continuous monitoring and patching and updating it, or if no other way.
Right? So the overall infrastructure should be as secure as possible to make sure that if you add such a component and when it is properly chosen, can then act and, and, and conform to your requirements as defined.
So maybe one last question, how mature is that market of low-code no-code software. You've mentioned that these are popping up for us right now. They are added on to existing products. Maybe there are some startups providing new functionality. This sounds like an immature market. Am I right?
Well, I wouldn't call it immature, but it's extremely fragmented. And I say, it's all now driven by the hype curve. Cause everybody wants to have a no-call tool. So everybody, every winter is rushing to deliver one. Some owners have a huge advantage because they started earlier. I don't know, just one simple example or Oracle.
I mean, they are doing the database security for, I don't know how many decades and the hymn, the local platform built directly into the database, which is probably available since like 20 years ago, Microsoft. I mean, they also have very reliable databases and cloud infrastructures, probably just kind of not investing enough into making this ad on the low code platform, secure by default, again, something which can be easily fixed, but it has to be kind of, it has to be driven by customer demand and the customer demands. We will never arrive without awareness.
And this is what we are doing today, right? This is what we do daily. As analysts. We have to tell our customers to ask specific questions from the vendors. And if enough customers start asking those questions, at least they will provide enough pressure to force a specific local tool to become a little bit more secure by default.
And again, now the market is extremely fragmented. The capabilities vary dramatically.
Again, one vendor would offer you a glorified scripting tool with the visual editor. The other one will give you an enterprise rate, robotic process automation platform. And another one, we'll probably talk about some kinds of an integration platform, basically, where you can connect to multiple existing database sources and then correlate the data across them, wonderful tool for data scientists or business people.
But again, it's like the weakest link in your data platform and it has to be secured properly.
Right? And I think that that notion of being aware of what is going on, making sure that enterprises organizations are aware of what's going on are really applying the right scrutiny, especially to these type of wonder tools that come with with, with huge promises that they are analyzed and, and treated just as any other corporate infrastructure.
I think that is the most important thought that we can convey choose the right product implemented properly securely, have your environment securely designed and make sure that you have applied the right governance also to the software processes and make sure that the developer and the developed software is, is well checked and well quality assured.
I think that's the most important thing because as this market is so broad, as you've described it with a broad level of variations, there is no one size fits all recommendation apart from be careful, make it the right way whenever you do something to it. Right? Any final addition from your side?
Well, I would say, I want to reiterate that the quote unquote shadow citizen development is an already existing and very tangible risk for your security and compliance posture. It may very well be that your company already have several such solutions in place. You just don't know you have it. As I mentioned, if you use a cough was DB database from Microsoft, it already comes with a trooper to notebook. You've probably never used and never needed, but it has to be disabled, exclusively, same applies to multiple other products and services.
So you have to start just like with any other field of security, you have to start with inventory visibility and monitoring, and then you can properly assess your risks and understand what you have to do to decrease that attack. Surface wonderful idea comes with the huge kind of a dark side. So you have to deal with it,
Right? When you think of having an inventory of your enterprise software being difficult yesterday, this problem just has gotten very much more difficult because everybody could be the author of just another business critical software, just using these technologies.
I want to hint at the, at the blog posts that you, Alex, they have written are around this topic, which, which looks at the same topic and highlights some very interesting aspects as well. So everyone who is interested in learning more about these low-code no-code platforms and their security implications, please head over to the Kuppinger cole.com web page and check out the blocks section and find Alexei's text about low-code no-code platforms. And if you have additional questions, please just get in touch. Thank you very much, Alexei for pointing at that important and really, yeah.
Dangerous aspect, although it's so promising and for being my guest today. Thank you, Alex. Thank you. Bye-bye
