No-code interfaces, aka your everyday software user interfaces, are amazing. I’ll say that first. 

They have been a primary force—perhaps the driving force—that has made SaaS possible. They have democratized software access. An HR manager who doesn’t know Python can run reports, and marketers who can’t write Javascript can still send marketing emails. (Though maybe we wish some of them couldn't.) It’s a big success story.

But, there is one big gigantic but. The no-code trend has also led us down a developmental cul-de-sac from which the enterprise software industry now badly needs rescuing if companies want to continue adopting software.

To understand this challenge and how to address it, it’s worth stepping back to consider what all this software actually does, and the role that the people who manage it play.

‍

An unmanageable influx of business apps

Most software interfaces are only built to manage themselves. Yet the average enterprise now has 874 SaaS applications, most of which connect, pass data, and make changes to each other. That’s a lot of different interfaces and different conventions to manage and far too many dependencies for one team to track.

In the recent past, it was the IT team who was responsible for these applications. But they have plenty of other duties and the surge in the number of apps has seen a new IT team emerged—the business systems team—also called business engineering. This team’s full time job is to ensure these applications connect, function, integrate, and play well with others.

Business engineers face a few unique challenges. Firstly, the role is fairly new so there aren’t  a lot of best practices or methodologies to rely on. This means these folks rely on the interfaces of each application, which often thoroughly lack the safeguards and time-saving principles you might expect from systems so crucial to a company. This all means that errors are frequent, and they tend to cascade across a business until suddenly, they wipe away revenue, which is what happened with organizations from Avon to HP.

Many business systems managers do not actually write code, making them exceptionally reliant on these “built-in” interfaces. And therein lies the problem.

‍

You don’t have to code to be a developer, but you do have to act like a coder

People like to make a big deal about the difference between code and no-code development (aka simply using a software interface to make changes). But really, they are the same, and are all just instructions to the software. All that differs is the interface, or what developers might call “the level of abstraction.”  

And if that’s true, there’s not much difference between coders and business application administrators. Both are developers and both are reshaping how the software works, integrating apps to each other, and building what are essentially new products within a software suite. Some do it with Python others do it using a graphical user interface.

Take the business systems administrator who builds what’s known as a quote to cash pipeline, which is a system that moves a “lead” in the CRM system through to a “customer” in the finance system. Have they not built something new? Have they not solved a problem by manipulating the underlying code?

And if people who don’t code are nevertheless doing developer work, they’re bound to face the same problems developers face, which they do. Teams managing business applications frequently run the risk of making irreversible changes on applications that affect others in the company. Because of the limitations inherent in many business applications, they often struggle to foresee how changes in one system might break things in another. These teams end up spending a lot of time searching for and resolving bugs, creating and sharing patterns, and documenting it all.

They are developers but without any of the typical tools and safeguards afforded to traditional developers.

And this is a shame because the so-called “pro-code” industry—software developers who code—have had fixes for all of this since Sputnik.
‍

DevOps has already solved this problem—so why the gap?

The first tools to allow developers to track changes to a code-base and share those across a team (aka “revision control”) arose in the 1960s. And integrated developer environments, where a bunch of developer tools come as a single software bundle, came about in the 1970s. While continuous integration emerged in the 1990s. What this means is that software developers have had a long time to get good at testing changes, collaborating, reducing errors, and doing all of this for the entire lifespan of the software.

‍

The tools and methodologies I’m talking about allow every current pro-code team to:

• Maintain and control versions of their code
• Use multiple environments to develop, test, and safely release changes
• Read and understand what’s currently implemented
• Document changes
• Collaborate and review change requests
• Manage releases
• Rollback changes
• Monitor system health
• Automatically test
• And much more

Collectively, these software delivery lifecycle principles constitute a major part of the development operations (or DevOps) set of practices/methodologies. Ultimately helping the software development industry dramatically shorten the development lifecycle while increasing software quality.
‍
Do any of these capabilities sound good? Useful? Necessary in business applications? Well, I’m here to tell you business systems teams can borrow them and use these same principles to address the issue of rapidly expanding software interfaces. Here’s how.
‍

Borrowing from DevOps

DevOps is highly reliant on a mode of thought known as systems thinking—creating repeatable systems or “guardrails” so people can focus on new development and application management. For instance:

• Code collaboration: DevOps teams use source control tools like Git (Or GitHub, GitLab, BitBucket, etc.) to allow multiple developers to work on the same code base via a system for forking code. Any developer can clone a piece of code, edit it, and then request others review it before it’s re-merged and goes live. Business applications teams can also use these tools for managing ERP, CRM, HCM configuration, and implementation.
  

• Versioning and change management: Source control systems allow pro-coders to branch their code-base into in-development and pre-production versions so they can test whether something works without the fear of causing real damage downstream. This capability is rarely available in business applications, but these teams can use source control systems to accomplish it nevertheless.

• Documentation: In software development, documentation happens as a byproduct of work done and is recorded along with tickets justifying ticketing tools like Jira and ServiceNow. Business applications teams often have to provide this information to regulatory auditors, but applications don’t natively document things in enough detail. But with a ticketing system, source control system, and a few other systems, you can do the same.
  

• Automation: Today, most testing and deployments in software development are fully automated, saving precious time and allowing for immediate feedback. There is no need to wait for Joon to deploy to the test environment and for Ari to manually test the changes. You can let your continuous integration and delivery system do the work and alert you if anything goes wrong. Systems now exist for you to do something similar for business applications.
  

And perhaps most importantly, all these third-party systems - like source control - are application agnostic. You can apply the same deployment schema to Salesforce as you can to NetSuite and Workday. That’s a big deal. Because rather than designing 874 processes and systems, you’re designing just a few. It’s a scalable solution to a problem that’s quickly scaling out of control.
‍
Development is development. Whether someone is a software engineer or a business applications administrator, they are all developing software. This means they should be versioning, managing change, documenting, and testing with rigor. It’s the only way forward.

‍

The issue is within AND between applications

The good news is that the industry is starting to wake up and realize we need to address these business application management gaps. However, we’re still in the early stages.
‍
Some fixes are coming from the vendors themselves. For example, Salesforce has launched Salesforce DX (short for “developer experience”) which allows for some team collaboration, version control, and the ability to make changes from a code interface. The ERP vendor NetSuite has launched (the somewhat confusingly acronymed) SuiteCloud Developer Framework (SDF) with similar capabilities. You’re also seeing third-party vendors emerge who do the same, such as Copado, Gearset, and Strongpoint.
‍
Yet we need to think hard about how we define the problem here because each of the aforementioned solutions share one thing in common: They are each still specific to one business application. Salesforce DX is great but it only works for Salesforce, the same goes for  Copado. If you want developer tools to manage your applications, you’re talking about 874 systems to manage 874 applications, which really puts the challenge in perspective.
All these systems connect, pass data, and make changes to each other. If enterprises want to continue to adopt software and manage it at scale, they’re going to have to not only adopt DevOps, but learn from its history. Just as Hashicorp’s Terraform normalized these issues for pro-coders, so too will no-code teams need systems that help them rationalize and manage the crush of business systems.
‍
I’ll say it again, no code and software interfaces are amazing. They have democratized software and they should continue to democratize software. But without something to tie them all together, enterprises are going to have an exceedingly difficult time continuing to adopt and manage it all. And most of what can tie these applications together and guide us out of this developmental cul-de-sac can be borrowed from DevOps. Which means you can start today.