The development of low-code and no-code systems makes it far easier to create new software, with benefits for both amateurs and professionals
In today’s world, new enterprise software requirements surface on a continuous basis, driven by corporate realignments, regulatory shifts, new types of devices and more. We always seem to need more software – but this can pose challenges.
Software development can be expensive, labour-intensive, architecturally complex and time-consuming. It’s traditionally been a one-sided coin: programmers take ‘requirements’ from their user base, then happily disappear off to cut code according to their preferred and perceived vision of the solution needed.
This model of software creation is effective enough, but it risks cutting out user input: feedback from those who can solve particular business problems but mightn’t understand how to build the software required. This dynamic has paved the way for ‘no-code’ and ‘low-code’ software platforms and tools.
There’s a pronounced difference between the two approaches, with the clue quite definitely in the name.
No-code software suites offer users a visualisation layer that effectively abstracts all the lower-level coding mechanics and functionality into a drag-and-drop interface. Intended to be used by businesspeople to create workflows and even quite sophisticated new application functionalities, no-code corrals a given set of software processes and offers them to users in a sort of intelligent Lego box that specifies how the pieces can be connected, potentially encouraging them in a certain direction.
Low-code software operates one fairly significant step higher than no-code. Intended to be used by trained developers with scientific knowledge of programming, it offers shortcuts, pre-templated functions, componentised accelerators and reference architectures against which programmers can craft their next applications or data services.
Whether it’s low-code or no-code, any system of software shortcutting must have process controls to ensure applications stay within the realm of established governance and compliance regulations.
“Organisations must ensure their low-code platform has controls and standards baked into it,” says Malcolm Ross, VP of product strategy and deputy CTO at Appian, which offers a comprehensive low-code platform and corresponding software tools. “Whether it is health data, financial records or personal information in question, you need to make sure your provider adheres to global regulatory standards. Otherwise you risk staff developing solutions that fail to comply with your IT governance.”
By baking controls into their low-code platform of choice, organisations can avoid the spectre of dangerous ‘shadow IT’, where apps are built outside of central IT management’s view, Ross says. He insists that platforms in this space should adhere to industry standards when it comes to regulations like the EU’s General Data Protection Regulation (GDPR) or the US Health Insurance Portability and Accountability Act (HIPAA).
“Teams across an organisation can then build the solutions they need, whilst IT leaders rest easy knowing their standards are being met. We know data can sometimes sit in silos. But with low-code executed diligently, an enterprise has the option of gaining a unified view of its data in a single, accessible and compliant solution,” adds Ross.
In the low-code software market, two core types of technology platforms are coming to the fore. First, there are dedicated low-code specialists that develop tools to accelerate programming, including Appian, Mendix and OutSystems. Second, there is a new breed of low-code platforms that are attached to existing cloud software companies: ServiceNow, Salesforce and Microsoft are not pure-play low-code companies, but these firm’s low-code tools offer customers an additional tier of freedom to innovate, self-customise and prototype as they work to try and solve their own problems.
The wider benefit with technologies like ServiceNow Creator Workflows, Salesforce’s low-code offering and Microsoft Power Apps is that these vendors won’t necessarily need to support every conceivable feature that users build. That helps customers, too, because they don’t have to draw on the vendors for maintenance and support.
“No-code tools can eliminate a lot of tedium from software development. They also make it far more accessible,” says Dr Holly Cummins, senior principal software engineer at Red Hat, a software developer founded on the principles of open source, which is now part of IBM. “With the right tools, anyone can create software and create it quickly. The catch is that these kinds of tools are most suited to certain kinds of simple tasks, like filling in forms and simple approval workflows.”
While no-code tools make the easy things easier, they can also make hard things harder. Although no-code systems are more accessible to people who aren’t software engineers, Cummins notes that in some ways they’re less accessible to software engineers, who may find their usual tools and professional practices don’t work when they must dovetail with the no-code offering.
“Most developers will tell you that typing out code is only a small part of their skillset. Managing interactions with other software, making updates seamless and catching weird bugs is where the intellectual heavy lifting happens,” explains Cummins.
But there are always potential weaknesses. All software is prone to becoming fragile over time, Cummins notes. That’s particularly true for some shortcut low-code and no-code systems, which are typically tightly locked to the parent platform.
“This can make the resulting applications harder to maintain and harder to integrate with other, newer systems. It also makes them harder to understand and monitor. As it matures, the software industry is starting to feel the weight of its past,” says Cummins.
The bottom line is that no-code and low-code software will always come down to the trade-off between performance and flexibility versus simplicity. As we now embrace the layers of abstraction in these software development tools, it’s important to remember that application flexibility itself is not a factor of software code. It depends on how well we can understand, interpret and manage the code blocks we work and create with.
With the right enabling constraints, we can use no-code and low-code for a better competitive advantage for all. As for the hardcore programmers, they can focus on building even more complex model solving, all of which they can ultimately compartmentalise further into abstracted toolsets. Order a bigger pizza, dear software team – you’re going to need it.