It’s not surprising, then, that low code tools have become popular. They build on familiar concepts to give end users a toolset that helps them build and share applications they need. The logical successors of Excel and Access, they’re playgrounds that open up access to data and provide ways of linking applications and services, while building simple user experiences out of common building blocks. You can think of them as modern process automation tools, able to extract workflows from operations and turn those captured actions into code. Low code tools like Zapier and Microsoft’s Power Platform are often seen as a way of offloading development demand, allowing users to build the apps they need, when they need them. As good as it is to have a way of reducing the app gap, there are significant limits that make it impossible to look at low code tools in isolation.
Managing APIs
What’s often forgotten in the rush to low code is that it’s at heart a workflow and integration technology, and that means building and managing endpoints. Here, existing development teams become essential, as they need to be tasked with providing managed APIs for existing applications and services. While the REST-based API models used by most low code tools are relatively easy to implement and support, that process introduces a new set of problems: who gets access to those APIs, and how much can they access through them? You can’t implement low code solutions without some form of API management, tied into your existing identity platform. Role-based access controls and managed throttles will be needed to ensure data security and integrity. You need to be sure that protected data can only be accessed by those who need it, and that too many users won’t affect operations for line-of-business systems. By making API management part of your low code suite, users who need access to APIs can be provisioned using simple self-service processes, with unused accounts scavenged to avoid data loss.
Working in teams
Then there’s the issue of low code being developed in isolation. Too often assets are created multiple times, missing out on the benefits of code reuse and portability. Part of the problem is that much low code is developed in proprietary environments, with no integration with source control systems, or with social coding environments like GitHub. Even the original low code environment, Excel, is moving away from the proprietary model, with its new LAMBDA function allowing you to share code blocks between different projects. What’s clear is that low code is code, even if it’s generated in a visual, drag-and-drop canvas. We need to treat it the same way as we treat the code in our mainstream enterprise developments, ensuring that it’s secure and reliable, and that, where possible, the knowledge used to build those applications isn’t lost and can be shared with other teams. Early low code tooling skipped over much of what was essential for this. Yes, you could build processes around it, with developer reviews and other milestones, but that approach gets in the way of the obvious benefits of low code, putting roadblocks in the way of the rapid development of apps that may only have a couple of months planned life. Bringing low code into large-scale development tools allows you to start taking advantage of the skills from different parts of the organization, building out what are becoming known as ‘fusion teams’ where different groups work together to build an app or service that solves specific problems. Each member of a fusion team will have a different responsibility: one might be the end user, one a low code developer, one managing service APIs. There’s no fixed structure for a team like this; it’s made up of the people needed for a specific task. They don’t even need to meet in the flesh – a Slack or Teams channel for the project might well be enough for most common interactions.
Low code as code
Newer tooling has started to change that, bringing in new management concepts and new ways of sharing code. One key development is a move away from purely graphical tooling, with the development of new languages that encapsulate much of what can be done with graphical tools and that allow us to build our low code development into CI/CD pipelines and social coding tools like GitHub. Those new languages are better suited to low code environments, building on concepts like SQL queries and Excel formulas. They’re quick to understand, using a mix of both declarative and functional programming concepts. Users can still work using their familiar graphical development environments, saving the resulting code into their git repositories automatically. Meanwhile developers can quickly review that code in their IDEs or code editors. There’s no switching context, and everyone gets the tools they need to do the jobs they need to do. Developers can then use CI/CD pipelines to quickly test code before release, looking for showstoppers and other critical bugs. SEE: Web developer or CTO, which tech jobs have the fastest growing salaries? Making low code into code allows you to take advantage of a new generation of machine learning-based coding assistants. Technologies like OpenAI’s Codex model can identify common patterns in code and make suggestions based on how other applications solve similar problems. If, say, a low code app needs a grid control connected to an ERP system, it can make suggestions for how to construct appropriate connection strings or how to best format a query. It’s an approach that’s still very much in its early days, but it shows promise. It’s not so much having an AI write code for you, it’s having an AI-based pair programmer who makes suggestions on how to improve code. As you learn how to build low code applications it’s a set of training wheels you can slowly take off, reducing dependency both on AI and on developer resources. It’s possible to see how this ends up, with core systems developers building APIs, AIs refining how those are used, and users quickly following their suggestions to build high-quality apps that work well and don’t disrupt other users. We’re in the early days of a big shift in how we build and use apps, and low code is going to be a key driver in this new revolution. The relationship between low code and mainstream application development needs to be a close one. However, with low code seen as a way of responding to lack of development resources, it’s a relationship that needs to be managed carefully. So, it’s good to see organisations acknowledging the importance of effective API management, of using tools that improve code sharing, of new team structures that cross organizational boundaries, and finally, using machine learning to reduce risk and increase productivity.
