The no-code or low-code conversation today is missing an important nuance: whether or not these tools aid or prevent you from practicing Agile when managing business applications.
‍
No-code and low-code are great, and it’s worth differentiating those two, as they are often lumped together. “No-code” means there is no programming whatsoever. This is most graphical user interfaces, like that of Salesforce CRM. Whereas “low-code” means there’s minimal programming, as in workflow engines like ServiceNow. Both allow non-coding developers to nevertheless deploy software. They are wonderful. But they have a flaw: They severely limit what you can do.
‍
With friendly interfaces, you lose the ability to search across configurations of several tools, to easily undo changes, and to coordinate your work with that of others.
‍
That prevents you from practicing Agile, which prevents you from scaling your business. But as I explore in this article, things don’t have to be that way.
‍

‍

What no- and low-code lack

What no- and low-code programs lack is a readable formal representation of the underlying configurations and metadata. Let’s explore what I mean by this.
‍
A formal representation of configurations means that all the unambiguous configurations and metadata are visible in one place where you can examine them, query them, and make changes that then reflect in the system. The value of having everything visible in one place becomes clear to anyone who’s had to dig 5-10 clicks into an interface to make a change. Or whose business team requests a change, but they have no way of knowing how it’ll affect other parts of the system.
‍
The reason interfaces are limiting is entirely intentional. The teams behind these business applications aim to delight users first, administrators second. They want it to feel easy, and that necessarily comes at the cost of robust change management. They hide advanced features and impose guardrails. These no-code/low-code software designers are, in sum, much more worried about helping untrained novices make changes than helping you, the expert, add new features, maintain, or revert.

The reason interfaces are limiting is entirely intentional
‍
And while you can access the XML for your business application configurations, it won’t suffice. XML comes close to being a formal representation, but it isn’t readable, and that brings us back to the second part of that requirement.

‍A readable representation is a summary of the configurations that anyone, even those who don’t know how to write the underlying programming language, can read and understand. It means that if you share a snippet of code with your sales leader and ask if this is what they want, they can simply reply, “Yes” in Slack.

If the representation is not readable, it means you will forever have to explain that application to others, and you become a bottleneck.
‍
Without the whole thing—a readable formal representation—it’s difficult to use outside workflow or Git tools to manipulate those applications the way you can with pro-code interfaces.
‍
That means with your business applications, you cannot easily:

• Undo changes
• Maintain a history of changes
• Maintain multiple environments
• Revert to a prior state
• Debug
• Understand what dependencies a field has
• Coordinate changes across many people and regions
• Understand why someone else made a change
  

You can think of these tradeoffs on a spectrum. The easier something is to use, the less easily you are able to practice Agile.

‍

This leaves you with two choices: Either you move slowly, relying on off-the-grid programming that’s difficult to document and maintain, or you move quickly and accept that things will break. (And accept the very real costs.)

So what do you do? You can extract a readable formal representation from your business applications, and display it in a low-code interface using a declarative language.
‍

Declarative languages solve the no-code/low-code problem

Your business systems may not have been designed for Agile, but you can achieve it anyway. This is a vast oversimplification, but here’s how:

• Extract all configurations and metadata using APIs—things you can access from the interface, as well as things you can’t
• Gather it into one formalized representation of all that code
• Display it in a declarative (readable) language
• Allow dual-works mode—users can make changes in the declarative system or the software interface

The beauty of using what’s known as a declarative language is that non-coders can read and write it, giving them the power of pro-code with the simplicity of no- or low-code. (Just to repeat: You do not have to be a programmer to understand a declarative interface—see below.)
‍

This is what HashiCorp’s Terraform did in the infrastructure space, and it’s now what Salto does with business systems. It allows you to apply software development and DevOps systems and methodologies to your business applications. It allows you to search, undo, revert, and coordinate actions via code branching, merging, and multi-environment testing that help you keep the systems functional and scale your business.
‍
Traditionally, you needed to be a developer to practice Agile. With declarative, you don’t need to be a developer to practice Agile
‍

Making no-code / low-code Agile

Business applications that operate with no- and low-code have many uses, but as they stand today, they prevent you from practicing Agile. This is because they lack a readable formal representation, which makes them time-consuming, error-prone, and difficult to manage across teams.Compared to software products, internal business applications tend to be a lot less agile and struggle to meet the constantly changing needs of the business.But systems like Salto are designed to help you change that, and when you can finally practice Agile in business applications, it opens a world of possibility. Your business applications today aren’t Agile. But they could be. And our team would love to show you how.