The central theses
- Your no-code business systems are mission-critical.
- You should manage the entire application lifecycle, not just the development part.
- You don’t have to reinvent the wheel – you can use solutions to similar problems in software development.
- You need to break down the silos separating your business systems teams – it’s all the same back-office product.
- Teach your no-code developers to behave like engineers.
Businesses today have a bewildering array and variety of business applications—for example, over 800 for midsize companies. And while many people like to point out how SaaS is spiraling out of control, that’s not really the problem. Today, most of these applications are maintained by non-developers.
By developers 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 company’s CRM, HCM, ERP, LMS, MAP, and dozens or hundreds of acronymized third-party applications are modified, engineered, and maintained by people not trained to think like developers, they haunt short-term results working toward long-term disaster.
In this article, I will explain why I think 2022 is the year for these companies to catch up and start training and nurturing no-code business application developers.
Many medium to large companies I speak to have a simple problem: an admin wants to retire a field in one of their business applications, be it Salesforce, NetSuite or Zendesk. They assume it is unused. You don’t see any activity and it would be nice to clean up. But there is no certainty. And because they’ve tried that before, and the field was critical to a formula that shattered the dashboards of some business units, they resent it and take no action. Salto CEO Rami Tamir calls it tech debt paralysis. Reinforced in a company, this is a serious problem.
Suppose the sales team wants to change the options on a picklist and it takes the CRM team a quarter to figure this out, and for a quarter some deals are routed incorrectly. Or the board of directors decides it’s time for an 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 fill a lead shortage, but the business applications team is taking six months to port the segments.
These problems can manifest themselves in all sorts of ways. Consider these three real-life examples I’ve heard from customers:
An international SaaS company relies on NetSuite for its ERP. On the last day of their fiscal year, many critical reports suddenly stopped working and they couldn’t close the quarter. It took the entire team late into the night to realize that someone had modified a “saved search” in production, unaware that it was being used by other critical parts of their implementation.
A large retailer that uses Zendesk for their customer support system. An administrator made a small error in a trigger definition right in production and fired off a confusing email to hundreds of thousands of unsuspecting customers, which then turned into a flood of new tickets.
A large, publicly traded SaaS company couldn’t figure out why it was seeing a significant drop in its lead-to-opportunity conversion. After months of analysis, it finally found that leads from a particular campaign were not being assigned to a sales rep due to an undetected stuck workflow in Salesforce. Those tracks just lay there untouched.
All of these issues have very real, balance sheet-changing implications. They make the business less competitive. As they grow and these problems worsen, their smaller, more nimble competitors will overtake them as they grow more and more slowly. Whatever compromises a company has made by allowing each business unit to choose their own systems to move quickly can ultimately lead to errors and failures. And all because these systems evolve primarily without the guidance of trained developers.
There are two problems companies must overcome if they want their business systems to continue functioning as they continue to grow. The first is to look at the world of software development and best practices as used in organizations that practice DevOps and Agile development methodologies to guide themselves.
For nearly sixty years, software developers have faced a similar problem as business application managers do today: They need a way for many remote teams to coordinate building a highly distributed system. They need quality checks to ensure there are no errors. Pre-production environments so you can test without consequences. Versioning so they can manage many versions of the application in case something breaks.
If developers were solely responsible for business applications, they would bring these habits and tools to fruition. You would think in terms of reusability, separation of concerns, and resilience. They would 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 would look at the whole thing.
Today, most teams that manage business applications exist in silos. You have the CRM team, the finance apps team, and then all sorts of “civic developers” who buy and manage SaaS, each striving to make their own team’s life easier. Most of these systems are large enough to be their own ecosystems and contain many products. They are also integrated and share data. People versed in software development methodologies and principles would look at this problem very differently than most do today: there are no more than 800 products that need to play well together. They are all one product – the company’s operating system – and each new addition must be created and maintained for the integrity of the whole.
And that’s just the first problem. Second, many of these business applications weren’t designed to be managed by people who think like developers, either.
That said, most business systems were designed with user growth in mind. The interfaces are designed so that end users can get things done and administrators don’t have to keep everything in order. Beyond that, if you think about application lifecycle development, they are only designed for the first step.
That means they lack native capabilities to do things developers might expect, like versioning, the ability to search the entire codebase, the ability to manage multiple environments, and in some cases the easy way to pull changes from one Transfer sandbox to production. Some now offer “development” environments, but it’s rarely all you would need.
Fortunately, I believe that the solution to the second problem is the solution to the first problem: teach more business system 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 build into manageable chunks, ticketing systems to document and prioritize work, and build their own tools when needed.
If business systems administrators, trained to think like developers, start pushing for more of these features, I bet more business systems vendors will develop them. And if they don’t, hopefully, like engineers, these newly crowned “developers” will build their own.
No code, no problem
Remember these three real-life examples from back in the day? The companies with problems in NetSuite, Zendesk and Salesforce? Each of them has adopted no-code DevOps tools and methodologies to create guard rails around their systems:
The international SaaS company that uses NetSuite has implemented alerts for its most important configurations. If someone changes the criteria for the saved searches required to complete the quarter, the admin will receive a notification.
The major retailer that uses Zendesk now prohibits admins from making changes directly in production. Instead, they adopt the practice of “versioning” and sandboxing from DevOps – each administrator develops configurations in their own sandbox, then moves them to another for integration and another for testing, and only then implements them in production.
The large public SaaS company with the missing sales now uses a DevOps tool that gives them a complete “blueprint” of each Salesforce org and the ability to review and make changes. If a key workflow isn’t working, they can discover it, test it, and fix it in days instead of months.
If the world of business applications drew on the past sixty years of software development thinking, frameworks, and methodologies, you’d see a lot less tech debt paralysis. Fewer sales and marketing teams would feel handicapped by operations. Fewer companies could not grow because of business systems.
I believe your systems should evolve as fast as your business and support it through that growth. I only see that in more no-code developers.