If you take the cloud, edge computing, AI, throw in governance and compliance plus, of course, data and operational security, then top it all off with a continuing need to innovate and improve business effectiveness and expand new market opportunities…then what is the missing link that might tie all these needs and opportunities together?
The answer is, I suspect, low code/no code applications development. Why do I say that? The answer can be found in the word ‘innovate’. IT has seen huge innovations over the last 50 years or so, and with the arrival of generative AI, coupled with what cloud services have already achieved and what edge computing will add to that, the pace of innovation can only sky-rocket.
A good measure of it will be entirely new, as-yet unthought of applications and services. But it is likely that even more of them will be re-workings of, and enhancements to, old established functions and processes. It is here that the most danger in terms of availability, security and governance may be created. There is now a huge need, and potential, for small and localized innovation in applications, and a commensurate possibility of huge backlogs of work building up, leading to security problems caused by sloppy development practices.
Indeed, I feel there is an argument that all the strutting around that vendors have been doing this year about their ability to innovate may prove to have been misguided, and that such innovating may not always be a good idea. Tech has now got to the point where the basic format of everything is pretty much established, but the need for improvement/enhancement is growing ever-more pressing.
It is now time for vendors to back away a bit, and let the users innovate with what they have so that it all works better and more easily, especially in terms of greater collaboration. Product differentiation - the vendors’ favorite tool to apply some proprietorial intervention - is still one of the great stumbling blocks for users, and the amount of engineering time, money and effort wasted by users in trying to work with those idiosyncrasies is, I suspect, considerable. It also equals lost user innovation time.
As those idiosyncrasies fade away, and the strength and complexity of the interconnective tissues implicit in cloud services grows, one other factor should then come into play. The common number for the size of the global developer community is said to be around 26 million, and it doesn’t seem to grow that much. Given that the potential workload of updates/enhancements is going to be signifiant, huge applications development bottlenecks seem inevitable. I can already hear the clarion call answer that will be raised - let AI identify and resolve all those re-workings and enhancements’ to which the answer, in these very early ‘walk-in-front-with-red flag’ days of AI’s development, is `yeeeeees, right’.
Code: low and no
This is where the growing use of low and no code applications development is now likely to find its real role, despite the common suggestion made against them that their very nature is a major hindrance to innovation. In some respects Frank Baalbergen, the Chief Information Security Officer at lo-code applications tools vendor, Mendix, agrees with that assessment, and points to Google as an example of how innovation can happen and transform a business:
Gmail was originally not planned to be like it was created. It was developed by some people randomly, within the organization.
A classic case of a few skilled developers having an idea and having the time to pursue it to a successful conclusion. The key word there is `time’, for one of the old adages of software development – perhaps THE oldest – is that developers spend around 70% of their working life on maintaining and updating existing applications. Despite the claims of many vendors to have found the way to reduce that time burden and free up developers for more creative/productive tasks, the burden stubbornly remains the same.
Not surprisingly then, this where Baalbergen cites some of the advantages of low/no-code applications development, and the ease with which it can be exploited:
The great thing is that it's easy to explain that this code function is doing that action because you can see its visual, executable models. You can just press play, and you have your application. And you can immediately iterate together with business users.
Perhaps the more important aspect is that not only do they contain code modules that are tailored to provide specific functionality in an environment where they can be readily linked together to build a range of applications and functions, plus having the base level platform where all the necessary functional control is pre-coded, they also come with two key defence systems - security tools for both the data and the process steps, and compliance and governance tools, to ensure that the applications created comply with whatever controls and restraints are applicable to a business.
You don’t go creating apps with all kinds of basic hygiene mistakes. In principle, from a technical school perspective, you don't really have to think about technical security measures as long as you stay within the Mendix environment. For example, you don't have to think about security certifications, it is one of the things that we do. You don't have to think about all the ground level anymore, you just have to focus on building your app; we take care of the rest; that is more or less our approach.
That does then lead to a rather obvious conclusion. If AI is going to lead to a vast array of new, more complex applications innovations, and if cloud and edge computing are to combine to expand the range and scope of those applications in real life, and if the world is already pretty strapped for the human resources that will be required, then the time has come for the real emergence of a community of workers that has often been talked about and commonly derided as an unworthy idea - the Citizen Developer. Baalbergen says:
Putting it simply, this is an interesting area, because the citizen developer, or more specifically the employee developer, gives a different view on innovation rather than `hindering’. And it possibly does in many ways, especially when it comes to the application of governance and control regulations control on what can be done. Rather than restricting large-scale innovation in is freeing up a multiplicity of small-scale innovation, in a way that you can't actually get it wrong.
For example, in my department we were able to retrace certain apps ourselves to solve a business problem, based on general central guidance, It worked great. And normally, you would have everything flowing around in emails, and that's unscalable. So what we try to do when scaling is required we can use metrics. It's very easy for us to use that.
Baalbergen sees it as very important that businesses pick a platform that is mature enough and also coincides with its goals. For example, Mendix is more of an executable model, which is better for business users, and probably better suited to the employee developer, whereas other low/no code suppliers tend more towards the code generation approach, which is generally preferred by developers, he says:
What is great about having low/no code tools is it is possible to add all kinds of new features, such as generative AI or compliance for seeing what data attributes you're processing. It is easier to see what's happening with your data than going through a million lines of code, then go into your entity module and asking what are the use cases of this attribute or entity. So, if you have that standardized way of working, suddenly those new tiny features become much easier.
He readily accepts that this is not innovation in the way that many at the bleeding edge of software development would refer to it. But it is not really intended to be. This is innovation undertaken by those who know what is required of some upgrade or enhancement but lack the skills to do the work in the traditional way. That may be some simple change or addition to a standard process, but it could also be quite major tasks.
It could, for example, even be the replacement of an old legacy system, where the core functionality needs to be combined with new ideas and functions. Though that would normally be considered a major task Involving general innovation – and therefore potentially more risky – it is now increasingly possible for employee developers who normally use the application regularly to use modern low code tools to define and develop the additions and enhancements that a legacy application requires and build the connectivity necessary.
What is helping this along is the fact that most of the available low/no code tools now readily communicate with each other, allowing greater development flexibility through mix’n’match options. Balbreegen says:
According to Gartner, in like five to 10 years or so, many enterprises who will have low/no code capabilities available from up to four different suppliers. They can communicate with each other using REST API's, and with Mendix it's like two clicks or so with mandates to expose or call an API. So integration with the new low codes and no codes, as far as I know, should be super easy.
All this should give the citizen/employee developer more than applications design and development capabilities to effectively meet the vast majority of local design innovation needs that most businesses will require. This should leave the skilled developer community free to address the new, truly innovate work that will be needed, while the low level innovation will be done, increasingly, by the people who use the applications in their daily lives.