What Developers Should Look for in a Low-Code Platform
Like asking for chocolate cake and getting a carob cookie instead, we’ve all felt the disappointment of expecting one thing and receiving its inferior cousin. The same can be said of low-code platforms, many of which claim to be the answer to your organization’s problems, but can actually leave a bad taste in your mouth. (Much like carob.)
When choosing a low-code platform, there are significant differences that need to be considered to ensure you don’t limit your organization’s potential for digitization — or, even worse, create new technical debt instead of reducing it.
Low code doesn’t necessarily mean low volume.
Too often, people associate citizen development efforts with small departmental apps, but that’s not always the case. Consider the number of apps you intend to build and the performance requirements from each. I’ve seen some very successful low-code apps used extensively across large organizations. Tens of thousands of records each month flow through these processes.
It’s important to ask yourself: Will this platform scale to meet my needs?
Consider whether your low-code platform of choice allows your low-code users to tap into the “pro-coder” talent pool as needed.
When I say pro coder, I am referring to IT people who went to school for computer science degrees and write code as their primary job. On more than one occasion, I’ve seen an ambitious low-code power user dive into an app, only to discover that their requirements, or ambitions, exceed their skill level or the platform’s capabilities. When it came time to ask for help from the pro coders, the entire app was thrown away and restarted from the ground up on a different system because the low-code platform was too limited and didn’t provide for deeper logic in code.
In such cases, IT ended up owning the app that started as a citizen development effort. Most IT people will tell you they really don’t want to take on more app support.
Make sure your low-code platform can extend all the way from citizen to professional developers so they can work collaboratively. When citizen developers tap into their specialized expertise and work on what’s important to them, while pro-devs add value and capabilities beyond the citizen developer skills, your organization gets the most bang for its buck.
But it goes beyond maximizing both types of resources. There is a job satisfaction factor at play here too.
Most pro-devs would rather work on stuff that’s more complex than creating reports and adding checkboxes. As one of those pro-dev/comp-sci people with decades of experience, I’m more interested in parsing a JSON response from a third-party system integration than adding a choice to a drop-down list.
Yes, I recognize how important that choice option may be to a finance person who needs to properly categorize expenses, but why not let the finance app owner take on that small task while I figure out how to get data from our platform to the finance system? The finance team gets their drop-down list updated quicker, and I stay motivated with technical challenges. Everybody wins!
Single System of Record
To minimize technical debt, it makes sense to reduce the number of platforms on which you build your apps. It follows that the fewer systems you have, the more value you get from each. When choosing a low-code platform, evaluate the other workflows you have deployed on that platform already, or plan to deploy in the future.
Let’s say you’re considering an employee suggestion box app. If you already have, or will have, a platform where you run employee workflows, then you not only accelerate the time it takes to create the suggestion box app, but reduce additional technical debt with costly integrations.
Bringing in a new platform means you have to replicate the employee information, which creates additional cost to implement and maintain. You can remove the need for that integration by having a single system of record where your employee suggestion box and existing employee workflows exist.
The biggest blocker to adopting low code usually centers around the process and technical governance of the ever-growing number of citizen developers and their apps. The key is being absolutely sure your low-code platform has adequate governance capabilities.
Process governance is how you manage things like the request or intake process, change management and release management. When it’s time to release an app on your low-code platform, theoretically it should be as easy as clicking a button. But this is where technical governance comes in. For example, does your low-code platform offer the ability to test the app and supporting data before it gets into production? As part of good technical governance, it should.
Remember: Not all low-code platforms are created equal. The right one should be scalable, enable low-code and pro-code developers to work together, support low-code apps that tap into existing workflows, and have capabilities to govern the entire process. Get those right, and you’ve got yourself a legitimately strategic solution.