Welcome to the KuppingerCole analyst chat. I'm your host. My name is Matthias Reinwarth. I'm an analyst and advisor at KuppingerCole analysts. My guest today is Alexei Balaganski he's lead analyst and works with KuppingerCole analysts from the suit off. Hi Alexei. Hello, Matthias. Thanks for having me again. Great to have you again. And especially when we have such an interesting topic, we want to talk about, uh, citizen developers and that is a rather new term coined just recently, before we define what a citizen developer is, where does this trend come from, Alexei?
Well, I guess we have to look a little bit further into the past to understand the, the reasons for this development. I mean this whole, uh, quote unquote digital transformation thing has promised us that everything done on a computer will be easier and faster and more convenient to everyone. Partially, that definitely is true. Unfortunately, users are very much limited by the functionality, offered to them by the office applications or enterprise applications, whatever they're using to do their job. If the application has a particular feature or function, it works fine. But what if it doesn't the only traditional way for these use cases would be just to go write a ticket or send a request to a software developer and then wait for weeks and month for them to implement this new capability, which is of course not always convenient or even possible. So obviously just like 40 years ago, maybe 20 years ago, people were looking for alternatives.
We used to do things like scripting writing, batch files, even some are custom made extension. There are many old and your possibilities to address this problem, perhaps the most popular and still prevalent citizen development tool around the world is Microsoft Excel, where people just write their macros or formula. And always, basically both down to how do enterprises enable this users who have a little knowledge about programming, but a lot of knowledge about the business domains. How do they enable them to create this missing functions themselves with some easier to use tools and traditional application development platforms. And these people are the citizen developers.
Okay. So we are talking about those users and users more or less use existing functionality for programming, for adding code, for adding functionality to existing systems, to extend their work areas. So all around from, from batch programming to, to shell programming on unique systems, to all these shiny new point and click tools that come for example, with Microsoft office. So these power apps, and if this, then that all these platforms, this is what the tool bench for a citizen developer would look like. Right?
Well, you actually mentioned a very important growth in your question or escalate. You said extending existing systems, partially. This is true. Unfortunately, this is not always the case. As I mentioned earlier, Microsoft Excel is the preferred for many people to do their their job though. Instead of trying somehow to extend the existing, let's say bookkeeping software, they would just quickly export the data from the bookkeeping software into a CSV file, load it into Excel and then apply sound formulas transformations to the data it's easy. It's convenient. Unfortunately, this isn't by no definition, uh, extending an existing system is basically trying to reinvent the wheel for all the hundreds of thousands time. When you have some kind of an end result from that Excel sheet, what do you do with it? How do you get it back into the bookkeeping software? That's a challenge
And you've mentioned the word export data. That means you are proliferating or the user is proliferating data from its source system where it's most probably well-maintained and maybe even covered by a good business meet to store the data there once it is outside of this system. And it is maintained in a CSV file in an XLS file. The control that the application system would impose on that is gone. So we are really also in the danger of having that data leaking because it is stored somewhere else. Well, this is exactly the biggest problem are many
People, many companies when your software vendors leave and analysts are now pushing this idea of citizen developers incorporating these specialized tools more and more into their daily job. And some are large analysts houses, which names we will not mention here. Even predict that over 60% of the daily business functionality used by such people would be implemented through this specialized citizen development tools. It's all fine and they need, but what about those securities? Cause you just mentioned costs in a way such tools are a classical example, shadow it. So if a person who is supposed to be using a specific business application for whatever reason cannot use it properly, because there is a missing functionality, they will try to utilize a different tool. What if this tool is not sanctioned by the central it, what if it does not actually fulfill all those compliance and security criteria? What if it's not GDPR compliant? What if it will leak sensitive data or outside of the EU, for example, or not just leak it somewhere where the data is not supposed to be. There are so many potential problems which have to be addressed. And unfortunately this is not a topic widely discussed at the moment,
Right? Fully understand what you mean because all these power tools, if this, then that they are very good in connecting systems together. And with one side is an, a sanctioned business application within the organization and the other is not, uh, it still works very well. So we have a constant flow of information between sanctioned and unsanctioned systems. And that is really a danger, especially when you're thinking of organizations that really focus on defining and implementing and controlling an enterprise architecture approach and others within their own organization are adding functionality and systems to that, which are neither well understood nor sanctioned. So this is really an issue.
Absolutely. And of course, we also have to remember that an enterprise application by its definition is not just something which is used in the large enterprise, right? And enterprise application has to conform to quite a few, let's say quality standards. It has to be scalable. It has to be able to perform specific number of transactions per second or whatever it has to be a resilient, which has doesn't break under load. And then of course it has to be properly secured. Let's imagine that you were work for a bookkeeping department again, and you have this bookkeeping enterprise finance management software, which is resilient and robust and secure it, but somehow you are unhappy with it. So you export all that data into a tiny SAS based application, hosted somewhere in the U S for example, and you're working from Germany. How can you be sure that SAS application would apply the same level of security and the same level of compliance to your data?
You cannot because it's not defined in the contract. It's not enforceable from the EU, from the legal perspective and so on and so forth. I mean, it's even worse if this is an application you have created yourself using some kind of loss or low code, no code on for sure mentioned later in detail, same problem. As in with API, for example, it's very easy to create an API, which is very difficult to create a properly secure and compliant API. And it's just as well, very easy to create an Excel or office based, whatever Microsoft power app or smart sheet or dozens of other online sources, where you can quickly hack together a small application, but then you will publish it to the world. And how can you be sure that it's secured,
Right? And on the other hand, of course, there is also the danger of that the wheel is invented more than once, so that an organization encounters the same problem in different areas so that there are different solutions individually developed by individual people, not knowing of each other. And, uh, they, they have, yeah, they have just a parallel development that cannot be well-integrated. And the same, I think there's integration factor is also an important aspect to look at because what do you do when you have this functionality implemented and you want to share it with others and it does not fit into their business processes. For example, I think maybe we should also talk more about that integration factor as well.
Well, that's a really good point. I mean, the whole idea of the biggest challenge of the digital transformation nowadays is that you have too many silos, right? So every application, every it system has its own data store, access controls, API structure, so on. So basically it's all isolated. And instead of fixing it, instead of kind of integrating those silos together, the citizen developer would actually do the opposite. Every time you export your data from an existing database and put it into an Excel sheet, you are decreasing the level of integration within your company. And if you're rightfully mentioned, or just now, what if someone else will have to use your application or what if your application has to be somehow integrated with another one you might have with someone else in a different tool with a different technology stack, if it's really uncontrolled and unmanaged from a central it perspective, you're creating a huge mess for everyone.
Yeah. Although on the other hand, I fully get the point that if this is done adequately and in a guided manner, that could really codify the experience of individual people that know the task that is missing and understand that very well to provide a solution that fixes really an existing issue. So that could be also a process to impose guidelines, to make sure that this is well-integrated follows at least a set of basic standards. Would that be something that you think can work
Well? I mean, all you just said is absolutely relevant tools. The only question, like how do you do all this, right? And of course the easiest approach in a way, the easiest approach would be the only threaten sanction tools are allowed. And kind of all the people within your company are using the same set of tools that I do. It was the same single platform for creating their citizen applications, if you will. And this is a good segue to talk about this whole, a low court and no court platform thing. So yes, this is actually a hugely booming market. Nowadays, there are so many solutions on the market, all the new, my old, I mean, again, almost, uh, Excel alternatives, which are available from many vendors and there are some purely SAS based cloud, native low-code or no-code platforms. The whole idea that are, instead of learning a programming language, you can just start in who we based like a graphical user interface based application, where we some boxes and arrows and maybe, uh, buttons, you design your workflow, your design, where do you start?
What happens if then else maybe input some easy formulas or into the logic. And so on in the end, you just click a button and you'll be able to execute your logic without even bothering about compiling and deploying that application. Right? The only problem is of course, how do you choose the right, uh, low-code or no-code platform? First of all, let me just say I am I really not a fan of this two different, uh, terms, because to me, the referral to essential is the same thing, a tool which simplifies creating a business logic for people who are not trained application developers, whether it allows you to write a little bit of code or it explicitly prevents you from writing any code, doesn't really matter the whole idea that it gives you enough flexibility to translate your business workflow into an app without having to learn a lot.
Right? So I don't actually understand why they use these two different terms of supposedly four different approaches. To me, it's the same approach. So let's just go and look or platforms. So simplicity, there are so many solutions to choose from, but then again, some are purely SAS based or they hosted somewhere in the cloud and you have to understand and assess all the risks of in your untrained and qualified. At least I'm qualified in it and security or those people to applaud your corporate data and other information into the platform. It might be okay, but you still have to have some controls in place, some security and compliance controls, or you might consider running such a platform on-prem internally. For example, perhaps one of the most popular solutions in that regard is Oracle apex, which basically exists in inside Emery, Oracle database instance, regardless whether you're on on-prem or in the cloud. And of course, if you're on it inside your database, or you benefit from all those security and compliance controls built directly into the database, because the data actually never leaves the database.
Yes KuppingerCole. We have worked extensively with our customers in identifying the risks of cloud platforms and how to mitigate them adequately. All the aspects that you just mentioned when it comes to where's data stored how much security is in place is a certified cloud service provider. And we have lots of research published on that. These are decisions that then would be made in the worst case, by just a single quote unquote user who just makes this decision just as they consider it to be adequate. And that cannot meet the same level of adequacy that we usually try to apply to such a position. So, as you've mentioned, this cloud-based SAS based approach is something that cannot be decided by a single user, somewhere in the field within the organization. I think that is a main issue here as well. And on top of that, of course, there can be so much going wrong when you just click and deploy an application basically to the complete internet available for everybody that can go horribly wrong with corporate data. If
You let your users decide which low-code platform they want to use for the hobby projects, if you will, this is a classical case of shadow it. And the, for sure, the weighty is a no-no right from any perspective it or security or compliance, or the only sensible way to anticipate this arise of citizen development. And there is definitely a rise in the recent years and it will continue to grow. Definitely. So you have to anticipate it. You have to prepare, I mean, you, as an obstruct it or security team or an enterprise, it has to be anticipated and has to become a part of this whole it governance, architecture, and strategy. As I understand, it has to be decided which tools are allowed, how these tools are supposed to be protected and monitored and incorporate it into the overarching it governance architecture. There has to be people assigned responsibility for these projects, or at least some kind of a sensible control.
Of course you cannot expect from our citizen developers to do the same quality control, like a C ICD or version or for their source code or anything like that. All this is probably not available from existing low-code platforms, but there must be some kind of workflow and process involved in quality control, at least some basic molecule control. And then of course you still have to think about safeguarding your sensitive data. So if your sensitive data is currently only protected through your enterprise application logic, but not for example, on the lower level of database level. And then you allow people to just directly query that database from a low code platform and you don't have proper security anymore, and then inevitably leads to a data breach. So there is quite a lot of things to consider when introducing this nifty concept into your enterprise
Policies, it's guidelines, it's training. It's really also just, um, making people aware of what's going on. So it's not just that simple that the user just writes the code that they require to do their work. There needs to be the, the framework in existence to make sure that if this approach is chosen within an organization and it's probably not easy to prevent, um, then it needs to be done well, just making sure that people follow the official way of doing this thing within an organization.
Absolutely. So let me just quickly rate your rate. One thing I am a huge fan of, well, maybe not the term citizen developer, but at least the idea that you'll let people quickly adopt this. If nobody else is out there for you, just do it yourselves quickly, or definitely using a proper low code platform instead of Microsoft Excel is also a great idea, but in the end you still have to think about all the potential risks and challenges. If you do it properly, or the productivity will thorough, but if you won't do it properly, you will suffer really, really serious consequences of that. But then even then massive data breach or it's the risk of business, what it's very rewarding. And if you do it properly
And I fully understand what you mentioned because many end users also have more or less a bit of an it background. And it's tempting to add this functionality when you have these tools at your fingertips and the data at your fingertips, just to improve. I know that there is a temptation to do that, but as you've mentioned to do it properly, and then you can earn the value from that, you've mentioned a first product, um, just, just before, um, where are we at? KuppingerCole when it comes to, um, research around that topic.
Um, we have not really touched a lot of specific products yet. Although there are some are reports in the works at the moment. So watch our website in the near future, but we have definitely have quite a lot of coverage for all those challenges and opportunities that come along. So database security, API security event, application security, it governance and compliance. This is all extremely important for citizen developer as a concept, as a program for your company. So I will really recommend starting with the region a little bit of theory about it before actually going and trying to choose the most appropriate platform.
That's a great summary from your side. Thank you very much, Alex, for being here today with me and talking about this concept of citizen developers. And I think that asks, this is on the rise. This is something that we will cover in more than one formats in the future as well. So maybe another podcast episode, but also with a blog posts, research notes, whatever we put out to the public as analysts. So thanks again, Alex for being here. Thank you, Mathias. And bye. Bye bye-bye.
