Companies now have a bewildering volume and variety of business applications—800+ for mid-sizes, for example. And while lots of people like to point to that as an example of how SaaS is out of control, that’s not really the issue. It’s that today, most of these applications are managed by non-developers. 

By developer, I don’t mean people who can code. It’s a subtle nuance, but I believe you don’t have to code to be a developer. It’s more about thinking like an engineer. And when a business’ CRM, HCM, ERP, LMS, MAP, and dozens or hundreds of acronymized third-party applications are modified, constructed, and managed by folks who aren’t trained to think like developers, they pursue short-term results that build toward a long-term disaster. 

In this article, I’ll explain why I think 2022 is the year for those companies to catch up, and start training and promoting business application no-code developers. 

Without engineers, you get tech debt paralysis

Lots of mid-sized or larger companies I talk to share a simple problem: An administrator wants to retire a field in one of their business applications, be it Salesforce, NetSuite, or Zendesk. They suspect it’s unused. They don’t see any activity and it’d be nice to clean up. But there’s no knowing for sure. And because they tried this one before and the field was crucial to a formula that knocked out some business unit’s dashboards, they fret over it and take no action. Salto CEO Rami Tamir calls this tech debt paralysis. Amplified across a business, it’s a serious problem. 

For example, say the sales team wants to alter the options on a picklist and it takes the CRM team a quarter to figure it out, and for a quarter, some deals are mis-routed. Or, the board decides it’s time to IPO, but realizes there’s no way to make their messy NetSuite instance SOX compliant in time. Or the marketing team wants to ramp up email campaigns to deal with a lead shortfall, but it takes the business applications team six months to port the segments. 

These issues can manifest in all sorts of ways. Consider these three real-life examples I have heard from customers: 

An international SaaS company relies on NetSuite for its ERP. On the last day of their financial year, many critical reports suddenly stopped working, and they couldn’t close the quarter out. It took the entire team scrambling till late night to realize that someone changed some "saved search" in production without knowing that it was used by other critical parts of their implementation.

A large retailer which uses Zendesk for its customer support system. An administrator made a minor mistake in a trigger definition directly in production, and it fired off a confusing email to hundreds of thousands of unsuspecting customers, which then turned into a flood of new tickets.

A large, public SaaS company couldn't figure out why it was seeing a considerable drop in its lead-to-opportunity conversion. After months of analysis it finally discovered that leads from a certain campaign weren’t being assigned a sales rep because of an undetected stuck workflow in Salesforce. Those leads had just sat there untouched.

All of these issues have very real, balance-sheet altering implications. They make that business less competitive. As they grow and these issues compound, their smaller, nimbler competitors will zip past them while they grow slower and slower. Whatever tradeoffs that company made in allowing every business unit to select their own systems to move quickly can, in the end, strangle in errors and misses. And it’s all because these systems primarily evolve without the guidance of trained developers. 

A developer is someone who draws upon sixty years of wisdom

There are two problems companies will need to overcome if they want their business systems to continue to function as they grow. The first is to look to the software development world, and to good practices like those employed in organizations who practice DevOps and Agile development methodologies for guidance.

For nearly sixty years, software developers have been running into similar issues that business applications managers are today: They need a way for many remote teams to coordinate building one highly distributed system. They need quality checks to ensure there are no bugs. Pre-production environments so you can test without consequences. Versioning, so they can maintain many versions of the application in case something breaks.

If developers were exclusively responsible for business applications, they’d bring those habits and tools to bear. They’d think in terms of reusability, separation of concerns, and resilience. They’d use Git-like tools to fork, branch, merge, and commit changes in a way that allows many minds to work together and reduce human error. Perhaps most importantly, they’d consider the whole. 

Today, most teams managing business applications exist in silos. You have the CRM team, the financial apps team, and then all manner of “citizen developers” purchasing and managing SaaS, each striving to make their own team’s lives easier. Most of these systems are big enough to be their own ecosystems, and contain many products. They are also integrated and sharing data. People steeped in software development methodologies and principles would look at this problem very differently than most do today: It’s not 800+ products that need to play nicely together. They’re all one product—the company’s operating system—and any new addition needs to be built and managed for the integrity of the whole. 

And that’s just the first problem. The second is this: Many of these business applications were also not built to be managed by people who think like developers. 

That is, most business systems were constructed with user growth in mind. The interfaces are constructed to allow end users to get things done, not administrators to keep it all in order. Furthermore, if you’re thinking in terms of application lifecycle development, they’re only built to solve for the first step. 

Image source

That means they lack native features to do things developers might expect, like versioning, the ability to search the entire code base, the ability to manage multiple environments, and in some cases, the simple ability to push changes from a sandbox into production. Some now offer “dev” environments, but it’s rarely everything you’d need.

Thankfully, I believe the fix to the second problem is the fix to the first problem: Teach more business systems administrators the wisdom of software developers. Developers often don’t have all the systems they need—so they build or borrow what they need to get the job done. They use Git tools to abstract what they’re building into manageable chunks, ticketing systems to document and prioritize the work, and, when needed, build their own tools. 

If business systems administrators trained to think like developers start agitating for more of these features, I’ll bet more business system vendors will build them. And if they don’t, those newly crowned “developers” will, like engineers, hopefully build their own. 

No-code, no problem

Recall those three real-life examples from earlier? The companies with issues in NetSuite, Zendesk, and Salesforce? Each of them adopted no-code DevOps tools and methodologies to create guardrails around their systems: 

The international SaaS company using NetSuite has implemented alerts for its most important configurations. If anyone changes the criteria for the saved searches it needs to close out the quarter, the administrator gets an alert.

The large retailer using Zendesk now forbids administrators from making changes directly in production. Instead, they borrow the practice of “versioning” and sandboxing from DevOps—each administrator develops configurations in their own sandbox, then moves it to another for integration, and another for testing, and only then implements it in production. 

The large public SaaS company with the missing sales now uses a DevOps tool that provides it a full “blueprint” of each Salesforce org, and the ability to inspect it and make changes. When an important workflow isn’t working, they can discover it, test it, and fix it in days, not months. 

It’s time to promote your no-code developers

If the business applications world were drawing from the last sixty years of thinking, frameworks, and methodologies in software development, you’d see a lot less tech debt paralysis. Fewer sales and marketing teams would feel hampered by ops. Fewer companies would find themselves unable to grow because of business systems.

I believe your systems should evolve as quickly as your business, and support it through that growth. The only way I see that happening is more no-code developers.