Even while modern tools make developers more productive, there's still a gap - the gap between the existing code base, the code that your stakeholders want, and the resources to build. Dev teams must prioritize their work, focusing on core business systems and the tools needed to work with them. It's not surprising that low code tools have become popular. Low code capabilities build on familiar concepts to give end users a toolset to build and share applications they need. Post Excel and Access, they enable access to data and provide ways of linking applications and services, while building simple user experiences out of common building blocks. Low code tools like Zapier and Microsoft's Power Platform are often seen as a way of offloading demand on Dev team, allowing end users to build the apps they need, when they need them.
API Management
What's often forgotten about Low Code is that it is a workflow and integration technology at heart – that means building and managing endpoints. Existing Dev teams become essential in such a scenario 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, the process introduces a new set of problems - who gets access to those APIs, and how much can they access through them. One can't implement low code solutions without some form of API management, tied into existing identity platform. Role-based access controls and managed throttles will be needed to ensure data security and integrity. One 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 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.
Dev Collaboration
Too often SW 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. Low code is code, even if it's generated in a visual, drag-and-drop canvas. It needs to be treated the same way as we treat the code in our mainstream enterprise developments. Developers need to ensure 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. One could build processes around it, with developer reviews and other milestones, but the 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 one 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 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 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 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 developers to build low code development into CI/CD pipelines and social coding tools like GitHub. These 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. Converting 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 programmer who makes suggestions on how to improve code.
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. It's good to see organizations 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 AI/ML to reduce risk and increase productivity.
/Service Ventures Team
Comments