Key takeaways
Low code adoption is growing, but it’s still far better suited to some development scenarios than others
Low code has been discussed as an alternative to traditional development processes and practices. But decision-makers need to understand its constraints and build appropriate guardrails around application development.
Ask the right questions up-front to determine if low code is the right choice for a given application
Low-code tools and platforms have enabled people to create useful software systems without having to write and maintain large custom codebases for many years now — winning advocates and critics in near-equal numbers.
But, with some forecasts predicting that by 2025, as much as 70% of new applications could be created using low-code tools and platforms; and ongoing developer shortages driving businesses to explore new ways of accelerating software delivery and reducing workloads, more organizations than ever are exploring what the technology could do for them.
Low-code capabilities have matured significantly in recent years but skepticism persists — and for good reason. While low-code tools have the potential to empower a new generation of so-called ‘citizen developers’ and take pressure off dev teams by streamlining the creation of simple capabilities, the fact remains that they simply aren’t suitable for every development scenario.
The first step towards determining if low code is right for you — and ultimately gaining the value it could potentially deliver for your business — is understanding what it’s best suited to support.
When (and when not) to use low code
There is a wide range of drivers that lead organizations to adopt low-code platforms. Here are four of the most common, with a look at how suitable low code really is in each scenario:
Scenario #1: Responding to developer shortages
With global demand for development talent still significantly outstripping supply, the prospect of tools that enable any user to build powerful software is compelling. But choosing to adopt low code because you have a shortage of development and coding skills in your organization can lead to trouble.
Without skilled developers and IT experts overseeing what business teams use low code to create, you get “software without strategy”: lines of business continuously solving problems with bespoke point solutions, with little-to-no cohesion or interoperability between them. It's a scenario that can’t scale, and one that’s entirely at odds with leading practices like platform thinking. IT leadership needs to set strategy and put guardrails in place, allowing for the development of low-code solutions where appropriate, giving business users the ability to solve important problems without creating large and complex problems (technical debt, systems that don’t scale).
Scenario #2: Supporting rapid business growth
For early phase scale-ups, low code can help create new capabilities and services quickly, without needing to scale development resources too sharply. That, in turn, ensures that their software doesn’t become a bottleneck for their rapid organizational growth.
However, those organizations need to recognize that many of the solutions they create with low code platforms may eventually have to be replaced. If not, they may find that core parts of their infrastructure are built on inflexible foundations. In fact, this is a challenge for many applications built using low code.
To get the most value from low code, growing businesses should use it to create the capabilities they need quickly — but be ready to retire those capabilities and replace them with something more robust as they outgrow them.
Scenario #3: Building new, business-critical software
The more central a piece of software is to your business, the less likely it is that low code is the right option for building and maintaining it. That isn’t because low code lacks the capability or sophistication to build critical apps, but rather because business-critical apps need to be able to scale, grow and transform easily.
Even if your original design for an app sits in the sweet spot for low code, if it’s critical to your business, there’s a very good chance that design will need to evolve in the future. You may need to add more complex capabilities, integrate them with other apps or migrate it to a new enterprise platform. Those things are a lot harder if not planned appropriately in partnership between business and IT.
Scenario #4: Empowering lines of business
If your goal is to give lines of business greater technological autonomy and empower your team to become citizen developers, adopting low-code tools is a great way. Low code is easy for users to get started with, and teams can quickly start managing and enhancing capabilities to meet their own needs.
However, keep in mind that even with the most intuitive tools in their hands, IT should be involved in the selection and extension of low-code tooling. Not all low code tools are created equal, and it’s important to select tools that are sufficiently extensible, scalable and that can integrate into the broader IT ecosystem.
The importance of balance
When low code first emerged, much of the narrative around the technology positioned it as an alternative to traditional development — one that would reduce or even remove organizations’ dependence on skilled developers.
That narrative has proven very unhelpful, both in terms of the unrealistic expectations it has set for low code, and how it has positioned low code and traditional development processes as enemies or opposites.
By enabling and encouraging low code across the right use cases — typically empowering software capabilities used by small teams of business customers — you can accelerate delivery, cut cycle times, and meet business rapidly without completely doing away with current development practices.
You retain all of the control, governance, and strategic input delivered by core IT and development teams while empowering lines of business and accelerating delivery. The best of both worlds is possible, but only when you strike the right balance.
Five questions leaders need to answer before choosing a low-code platform
Before you jump in and choose a low-code platform or set of tools, it’s important to establish if low code is well suited to your business and your needs today.
You’ll likely want to conduct your own in-depth evaluation but answering these questions is a good place to start:
How many people are going to use the software you’re building?
More users mean more needs to adapt to, and a greater chance of the software you develop becoming business-critical and expanding beyond the sweet spot for low code.
Do you want to build core or supporting (edge) software?
The closer your software sits to the core, the more important it is that it remains as flexible, scalable, and interoperable as possible — which should lead you away from using low code to build and maintain it.
Could the supporting software you’re building today become critical as it grows in adoption?
If you already know that the systems that need to be built or modernized are business-critical, it’s very unlikely to present a strong use case for low code, unless you are willing to accept the limitations of the low-code platform.
Are your team ready to become citizen developers?
For low code to deliver its full potential value, your team needs to be eager to adopt it and start creating their own capabilities. They’ll also need some level of software proficiency, as well as the right mindset to bring valuable capabilities to life.
What problems are you really trying to solve?
If you’re looking to clear an extensive backlog for example, there may be better ways to achieve that than adopting low code. You may be trying to treat the symptoms of process inefficiency, rather than addressing the underlying challenges. You may also be able to define specific needs that can be carved out using a low code solution.
Low code isn’t one-size-fits-all but it has a lot to teach us.
Low code isn’t a replacement for code. If an organization were to retire its development team and use low-code platforms to completely hand the development reins over to the line of business teams, they’d be extremely limited in what they could achieve.
But for a specific set of use cases, low code is still a very powerful technology. It provides the means to close capability gaps quickly, decentralize the creation of edge software for small user groups, and enables business teams to bring their own desired capabilities to life, when they need them.
By applying low code alongside traditional code and development practices, organizations can empower citizen developers without sacrificing the flexibility and scalability demanded by core software. That’s the real low code sweet spot — a place in the organization where it’s applied at the edge to solve very specific LOB demands; where it’s reviewed by IT experts and applied alongside traditional development practices and resources — rather than replacing them.
Low code: a definition
There are a lot of platforms that call themselves ‘low code’ — but what does that mean? In our experience, low code is often used to describe platforms that allow the creation of business logic and interfaces using graphical tools that non-developers can use.
Typically, they are more configurable and customizable than no-code platforms, although there is a fair amount of overlap. Low-code tools also usually allow some (small) amount of ‘real’ code — usually a so-called scripting language such as JavaScript — to do things that the regular graphical tooling can’t, such as more complex business logic or more complex integrations.
