Menü
Making a case for low-code platforms

There just aren’t enough developers to go round. Businesses have long understood that software development can be complex and costly, and not everything within the enterprise is mission-critical or customer facing. Not all of your applications need to be bulletproof or come with a slew of features; sometimes basic, working software is enough to enable a team or department to become more productive and deliver more value. You can see how businesses have sought to deal with the fact that they can’t build everything themselves with things such as packaged apps, outsourcing and the like.


The latest ‘silver bullet’ comes in the form of low-code platforms: an environment programmers use to create application software through graphical user interfaces and configuration instead of traditional computer programming. A typical low-code platform will provide a drag-and-drop development environment and model-driven logic to enable creators to build an application that solves their particular need.

Can low-code take the pressure off your software developers?
Can low-code take the pressure off your software developers?

The premise is simple: you don’t need to waste your dev teams’ time on limited-use apps; simply get someone that understands your business to create the apps they need in the low-code environment. Low-code promises to clear up backlogs, spark innovation and build up a citizen developer workforce.


It’s an approach that has many fans. Analyst house Gartner, for instance, predicts that by 2024 fully two-thirds of application development will be done on low-code platforms. This doesn’t imply traditional software development output will drop dramatically, but that a greater proportion of new applications are developed on low-code platforms.


To get the best out of any technology, it’s necessary to dig behind the hype and properly understand its strengths and weaknesses. Used correctly, low-code could be a promising addition to an organization’s technology toolkit.


Where low-code gets the job done


In any typical enterprise, there are a multitude of business-enhancing applications that don’t require full-stack development teams, where practices such as continuous deployment, end-user acceptance testing, or test-driven development might be overkill. Think of a bank that wants to introduce a simple, in-branch, customer service touchscreen or a simple branch employee mobile app.


We see that the following app characteristics might fall into this sweet spot for low code:

  • The application is mostly a simple UI, and you can take advantage of building on top of newly developed digital platforms or APIs in the enterprise
  • An off-the-shelf version isn’t available
  • Off-the-shelf applications are too complex or too expensive
  • The business problem to be solved is simple and straightforward 
  • The resulting systems architecture for the low-code application fits within your overall IT estate 
  • The low-code development team can be small, and doesn’t need to coordinate too heavily with other teams

Running up against the edges


For those IT leaders contemplating low-code deployments, the real challenge comes from thinking about the edge cases, where we run outside of the low-code sweet spot and into the messy reality of the problems for which low code may not be suited.


Complexity

Take complexity. Few applications are ever created to be complex, but the reality of today’s enterprises is that complexity is a part of life. Low-code environments tend to use a visual metaphor to describe logical program flow, and once the ‘diagram’ for the code becomes too large it becomes very difficult to understand. As a result, there’s an upper boundary on the complexity of logic that can reasonably be implemented in a low-code platform.


This is a problem that many of the low-code platform providers recognize. Their solution: if anything is getting too complex, you can drop down into custom code. And this is where the alarm bells should start ringing.


Anyone that’s had the experience of customising a COTS package knows the perils of straying too far from a vanilla install. If you start modifying the code behind your low-code apps, can you be sure you’ll remain on the upgrade path? And if not, what costs are you likely to incur?


Security and testing

And it’s not just migration paths. What about security? We all know about the multitude of risks facing today’s enterprise, but when you don’t really know how your applications were developed, how can you understand where your weak spots might be?


In an archetypal application development process, you can implement a testing regime to bug bash and check the quality of your code. When you’re in a low-code environment, you’re reliant on both those doing the application development to test their results and also on the tooling provided by your low-code partner. In many instances we’ve encountered, the tools for testing low-code applications fall short of what we’d expect.

Low-code platforms can struggle with the realities of modern businesses
Low-code platforms can struggle with the realities of modern businesses

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.


Integration 

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? 


Lock-in

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.

Catch the latest edition of the Technology Radar