The low-code / no-code train has officially left the station, and everyone’s jumping on board, but there are plenty of cautionary tales of big costs and elusive benefits, so here’s the Sayers synopsis on how to get value from these platforms.

“Low code” tools have been around for well over 20 years – starting with concepts such as Domain Specific Languages (DSL) that enabled reuse, then evolving into visual modelling tools that further reduced the amount of custom code (think tools like MS Visual Studio). As COTS adoption accelerated in the 90s and SaaS in the 00’s, and these platforms began to build developer ecosystems around them, they became low-code platforms themselves.

One way to think about the suitability of these platforms is by asking ‘what were they born to do?’

1. Platforms born out of business process automation software – historically these platforms have been model-driven. The model is used to abstract the business semantics and logic, and is then interpreted at runtime into a working application. No code is generated and the application is always dependent on the model for its functioning. This is good for business users who can define the model and then have the application derived from it, but exportability and customisation is hard - the magic tends to happens underneath the covers.
2. Platforms born as application development software – here the model is used as a starting point to describe business semantics and relationships and then converted into real code. There is no runtime interpretation of the model. This gives greater flexibility and customization by allowing developers to access, modify and fully extend real code. The ‘magic’ is fully visible.
3. Platforms born out of packaged Software – many of the major B2B SaaS platforms have released low / no-code tools in recent years, and they tend to cater to both professional and citizen developers. The core SaaS platform is, of course, configurable by end users at a relatively superficial level (typically the UI). More complex changes can be made by trained ‘super-users’, like managing security and sharing data. Applications can then be built on top of the core SaaS platform using low-code tools – for example bespoke workflows or analysis. Some of these platforms are providing new low-code tools designed for developers. LCNC extensions to the major SaaS platforms remove the UX and logic constraints of the core platform.

Healthy competition means these distinctions are blurring, but picking the right horse for the course matters. Before you race ahead and pick a horse, let’s look at some common use cases and assess the fit of low code platforms.

1. Decades ago, Pete built Solution X to enable this unique thing that our organisation does that no-one else does. Over the years he integrated it with a bunch of third-party applications as well as some more custom coded applications. Pete retired 3 years ago. The systems work, but the pandemic meant we changed the way we did business, and the system couldn’t adapt. Every time we tweak something, it’s a nightmare to test. Low-code may be a good fit, but don’t underestimate the time and skills required to build the new application. Someone needs to be able to articulate the business logic behind it for it to meet your needs. Some platforms may be able to infer the logic from Pete’s code, but you’ll want to engage your business users to make sure you’re building for the future rather than the past. Secondly, it sounds like you’ve got a bunch of integrations to handle. Think carefully about which of those peripheral applications should be brought ‘on-platform’ (combined into a single new cloud-based technology and logical application), and which should stay where they are, and make sure the documentation you get from the low-code platform will allow you to manage those APIs long term. Finally, think about the kind of ongoing changes your teams will want to make, who will make them, and what they will cost.  
2. We’ve had several persistent digital teams for a few years now. We’ve embraced DevOps and have seen an improvement in our cost and speed to release, but we are struggling to attract the talent we need – in fact we’re losing our best devs to start-ups. Think about your operating model. Are you going to establish a citizen developer team outside of your DevOps core? If so, how will changes they make get released? What are the guardrails you would want to put around where citizen developers can play? Or are you wanting to embed low code tooling into your DevOps teams? If so get them to play with and feedback on the different tools first, or risk a rebellion!
3. We are launching a new digital product. It doesn’t exist in the world yet – or at least not the way we envision it. It may or may not be successful – we want to take an MVP approach. Speed is of the essence, and we’ve got to keep our burn-rate low. Think about whether you can attract the tech talent to design and / or build in-house or whether you would prefer to use a partner. Whether in-house or outsourced, consider what platforms the team have experience designing for and building with. Then its all about cost, scalability and user experience. How scalable is the platform – at what scale might you be forced to re-platform and is the cost worth it? If consumer facing, how good / customisable is the UX? What discounts is the platform provider willing to give in the early stages? What’s the risk of vendor lock-in and lack of contestability down the track?

As you can see that the considerations are quite different depending on the context, but here are some general questions you need to be able to answer before picking a platform:

• How unique is the application / process in question and is there a SaaS solution that does this out of the box? It probably doesn’t make sense to turn your finance team into citizen developers to build a payroll app for example, but having subscribed to payroll software, you might want them to be able to build a predictive forecasting tool using a low-code platform.
• How mature is your in-house DevOps (and increasingly MLOps) capability, and what language do they speak? DevOps has fuelled a cultural and organizational shift, which in turn has empowered enterprise software teams to deliver better software quicker. But DevOps practitioners still tend to favour hand-coding applications, focussing automation tools on testing and deployment. On one hand, embedding the use of no-code tools by citizen developers in an organisation with a mature DevOps capability could up creating a shadow Citizen DevOps team. On the other, if you’re seeking to embed low-code tools into DevOps teams themselves, you want a tool where the abstractions are seen as helpful rather than limiting, and where the code generated is in a language the team is proficient in.
• How available is the skillset required to develop and maintain the applications you develop on the platform? – whether the work of building and running the applications is done in-house or outsourced, by business or technical users, you are going to have to acquire the platform skills or build them.
• How much integration complexity will the platform or application need to cope with? – Self-contained, simple applications are one thing – a room booking system for example. But enterprise applications rarely exist in isolation, and you don’t want a mission critical app to get lost in translation. Often the choice of low-code tools will be informed by your other platform choices, and sometimes the platform choices of your customers and partners.

In summary, low-code / no-code platforms hold huge promise, but questions of strategy and operating model are important to answer. Keep your user, whether they’re a professional or citizen developer, in-mind and engaged from the start. LCNC is not an alternative to custom code, but a complement to it: almost all organisations require a healthy balance of both.