Whatever application development you want to do, it’s essential that you can verify that it’s working properly. Your entire test strategy needs to be able to support the level of risk established in the original use case. We often come across the assumption that if you’ve written less code, as you would with low-code, there’s less chance that something can go wrong. But we think it’s prudent to be able to test that.
Few enterprise applications exist in complete isolation: most will need to integrate with other systems and be able to consume data and expose it to those systems. Increasingly, we’re seeing low-code platforms promise they’ll enable you to build the sorts of APIs you’d need to integrate successfully.
That’s probably going to be okay if your low-code app is only integrating with a handful of other systems. But the complexity of managing APIs when you’re having to integrate dozens of systems shouldn’t be underestimated. And it’s probably worth understanding what documentation you’ll get from your low-code platform. Will it enable you to manage your APIs in the long term?
One of the more unusual questions we’ve had from clients recently is: “What do we do if Google goes out of business?”. The chances of it happening appear to be vanishingly small, but it’s a question that many leaders in regulated industries are being forced to consider. Because no matter how likely any business-impacting event would be, they’re required to have an answer. And the same is true when it comes to low-code.
Many low-code providers can provide the reassurance that in the event of needing to migrate platforms, you’ll be able to generate code in something like C++, and recompile your applications from there. That’s probably a good start, but we’d urge anyone running a low-code application that has significant impact on their operations to test their ability to do this successfully and to check out what the resulting code looks like. It might be able to run, but would you ever be able to make changes to it? Generated code in these situations is often algorithmically correct, but unreadable for humans. It will execute properly but forget about ever changing it in a meaningful way. Much like the disaster recovery adage: you don’t want to wait until you need it to find out whether your backup plan works.
Scaling a success
Everyone loves a success story, but when it comes to low code, success can bring its own set of problems. Go into any enterprise, and you’re likely to find examples of applications that started out small, but have proven their worth over time and spread throughout the business. And given that likelihood, we think it makes sense to plan for that when using low-code platforms.
If one of your teams creates something compelling within your low-code platform, what do you do if it really takes off? How will you handle integration, risk assessment,and testing? How will you handle feature requests that increase the complexity way beyond the original use case? It’s all too easy to assume that you’ll be able to sandbox low-code development and treat it differently than your other software assets. But the reality is that you need to plan for what happens when a low-code app becomes mission critical.
Low code in practice
Let’s consider how this might play out in practice. For instance, say you want to create a package tracking app for your delivery service. The application itself is relatively straight-forward: at each point on the delivery chain, from warehouse to drop point, the package will be scanned, and that information should be presented to the customer via a web app.
Before you set about building this app using your low-code platform, you might want to consider scalability. Potentially, you could have millions of users for this app — have you checked that your back-end (not the low-code platform itself) can cope with that level of demand?
You might also want to consider the UI. You can reasonably expect that there’ll be a high degree of variety in the types of devices that your customers are using. Low-code platforms are designed to support this, and their built-in UI widgets will work across devices. But what about the specifics of the UI for parcel tracking? If your low-code platform doesn’t have a timeline module, you’re going to struggle. If the timeline module doesn’t behave exactly how you’d like it to, you might be forced to either live with it, or drop down into custom code to tweak it to your liking.
Even once you’ve overcome these hurdles and have your app successfully deployed to millions of users, you still face challenges. As the world turns to online shopping, return rates are becoming an ever-more pressing concern for retailers. Can your delivery app integrate with the systems of your retail partners and help them track which packages are being returned? If it’s just one retail partner, the answer may well be yes, but as more and more partners come on board, the number of integration points rises — and the task of managing that complexity becomes exponentially more difficult.
The low-code safe zone
There are many good reasons why organizations want to use low code, but we’d always advise doing so within a set of clearly defined guardrails. If you have an application that would typically need two or three developers, where the business logic is pretty constrained and the app will only integrate with a handful of other systems, you’re probably in the safe zone.
Once you go beyond those boundaries, you might still want to make use of your low-code platform — but you’ll want to seriously think about potential risks and the steps you put in place to mitigate them.
Lastly, you might think about that safe zone as a function of team size. This isn’t intended to be too prescriptive, but we do think that once you have more than six people working on a single app — including those on testing and the like — that the app is likely to start becoming too complex. Low code can undoubtedly give you some quick wins and prove it’s worth in the enterprise. Just be wary of trying to do too much with the platforms.