It’s Time to Start Growing No-Code Developers
- Your business systems without code are critical to the mission.
- You should manage the entire application lifecycle, not just the development part.
- No need to reinvent the wheel – you can draw from solutions to similar problems in software development.
- You’ll have to break the silos that separate computers from your business systems – it’s all the same back office product.
- Teach your codeless developers to behave like engineers.
Companies now have a bewildering volume and variety of business applications – more than 800 for medium-sized businesses, for example. And while many people like to point it out as an example of how SaaS is out of control, that’s not really the problem. Is 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 don’t think you need 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 third-party acronym applications are modified, built, and managed by people who aren’t trained to think like developers, they pursue short-term results. which build towards a long-term disaster.
In this article, I’ll explain why I think 2022 is the year for these companies to catch up and start training and promoting code-free business application developers.
Many medium or large companies I speak with share a simple problem: An administrator wants to remove a field from one of their business applications, whether it’s Salesforce, NetSuite, or Zendesk. They suspect it is not being used. They see no activity and it would be nice to clean up. But it is not known for sure. And since they’ve tried it before and the field was crucial to a formula that removed the dashboards of some business units, they worry and don’t take any action. The CEO of Salto, Rami Tamir, calls this paralysis of technological debt. Amplified in a company, is a serious problem.
For example, suppose the sales team wants to change the options in a picklist and the CRM team takes a quarter to figure it out, and for a quarter, some offers are sent incorrectly. Or, the board decides it’s time for the IPO, but realizes there’s no way to get their messy NetSuite SOX instance to meet on time. Or the marketing team wants to increase email campaigns to address a lead deficit, but the business application team takes six months to lead the segments.
These problems can manifest in all sorts of ways. Consider these three real-life examples I’ve heard from clients:
An international SaaS company relies on NetSuite for its ERP. On the last day of its exercise, many critical reports suddenly stopped working and were unable to close the quarter. It took the entire team fighting until well into the night to realize that someone changed some “saved search” into production without knowing that it was being used by other critical parts of its implementation.
A large retailer that uses Zendesk for its customer service system. An administrator made a small mistake in defining an activator directly in production and sent a confusing email to hundreds of thousands of unsuspecting customers, which later turned into a lot of new tickets.
A large public SaaS company could not figure out why it was seeing a significant drop in its lead-to-opportunity conversion. After months of analysis, he finally discovered that potential customers in a given campaign had not been assigned a sales rep due to an undetected blocked workflow in Salesforce. Those tracks had sat there untouched.
All of these problems have very real implications that alter the balance sheet. They make this business less competitive. As they grow and these problems add up, their smaller, more agile competitors will overtake them as they grow more and more slowly. Whatever compensation the company made to allow each business unit to select its own systems to move quickly can, in the end, miss mistakes and mistakes. And it’s all because these systems evolve mostly without the guidance of trained developers.
There are two problems that companies will have to overcome if they want their business systems to continue to function as they grow. The first is to look at the world of software development and good practices such as those used in organizations that practice agile development methodologies and DevOps as a guideline.
For nearly sixty years, software developers have encountered problems similar to those of today’s enterprise application managers: they need a way for many remote computers to coordinate by building a highly distributed system. They need quality controls to make sure there are no errors. Pre-production environments so you can try without consequences. Versioning, so they can keep many versions of the app in case something breaks.
If developers were solely responsible for business applications, they would use these habits and tools. They would think in terms of reuse, separation of worries, and resilience. They would use Git-like tools to fork, branch, merge, and make changes in a way that allows many minds to collaborate and reduce human error. Perhaps most importantly, they would consider the whole.
Today, most computers that manage business applications exist in silos. You have the CRM team, the financial applications team, and then all sorts of “citizen developers” who buy and manage SaaS, each striving to make life easier for their own team. Most of these systems are large enough to be their own ecosystems and contain many products. They are also integrated and share data. People steeped in methodologies and software development principles would see this problem very differently than most today: there are no more than 800 products that have to play well together. They are all a single product, the company’s operating system, and any new additions must be created 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 created to be managed by people who think like developers.
That is, most business systems were built keeping in mind the growth of users. Interfaces are built to allow end users to do things, not administrators to keep everything in order. Also, if you are thinking in terms of application lifecycle development, they have only been created to solve the first step.
This means that they don’t have native features to do things that developers might expect, such as version creation, the ability to search the entire code base, the ability to manage multiple environments, and in some cases the simple ability to ‘drive changes from a sandbox to production. Some now offer “development” environments, but it’s rarely all you need.
Fortunately, I believe the solution to the second problem is the solution to the first problem: to teach more enterprise system administrators the wisdom of software developers. Developers often don’t have all the systems they need, so they create or borrow what they need to get the job done. They use Git tools to abstract what they are building into manageable fragments, ticketing systems to document and prioritize work, and, when necessary, build their own tools.
If enterprise system administrators trained to think about how developers are starting to demand more of these features, I’ll bet more enterprise system vendors will create them. And if they don’t, these newly crowned “developers,” like the engineers, will expect them to build theirs.
No code, no problem
Remember those three real-life examples from before? Troubled companies on NetSuite, Zendesk and Salesforce? Each of them adopted code-free DevOps tools and methodologies to create railings around their systems:
The international SaaS company that uses NetSuite has implemented alerts for its most important configurations. If someone changes the saved search criteria they need to close the quarter, the administrator will receive an alert.
The large retailer used by Zendesk now prohibits managers from making changes directly to production. Instead, they borrow the practice of “versions” and sandbox of DevOps: each administrator develops configurations in their own test box, then moves it to another for integration and another to test it, and only then does it implement it into production.
The large public SaaS company with missing sales now uses a DevOps tool that provides you with a complete “plan” of each Salesforce organization and the ability to inspect and make changes to it. When a major workflow doesn’t work, they can discover it, test it, and fix it in days, not months.
If the world of business applications were to take advantage of the last sixty years of thinking, frameworks and methodologies in software development, you would see much less paralysis of technological debt. Fewer sales and marketing teams would feel hampered by operations. Fewer companies would be unable to grow due to business systems.
I believe your systems should evolve as fast as your business and support that growth. The only way I see it happening is more developers without code.