The four cornerstones of no-code lock-in (and how to avoid them)

As enterprises use an increasing amount of no-code software tooling, then it may be reasonable to suggest that the business will become disproportionately reliant upon its handy-but-abstracted software toolset on a number of levels, all of which will increase the chance of lock-in – so how can that pitfall be avoided?

IDGConnect_nocode_lockin_shutterstock_2016579524_1200x800
Shuttrestock

Technology companies always talk about freedom. They love to say that their core go-to-market proposition is built on a foundation of customer choice, freedom to use any selection of their own (or other vendor’s) tools, services and functions, a laissez-faire attitude to whichever implementation partner an organisation wants to select… and a belief in platform-agnostic open source technologies that provide maximum choice, flexibility and control.

In truth, that’s sometimes just showboating.

Although they may promise to travel the open road to interoperability and indeed develop and align most of their platform DNA to be clear and transparent, there’s always an element of ‘we do it better’ that emanates from most tech firms that would rather see customers buy all-in if at all possible.

At its best, this is just a natural desire to win, which can’t necessarily be faulted. At its worst, it amounts to elements and instances of vendor lock-in, where customers find themselves ring-fenced into using a restricted set of IT tools due to the contracts, clauses and customs associated with any given vendor-customer relationship.

Ask any even half-seasoned software or data engineer about this kind of thing and they’ll most likely have already been there, done it and got the t-shirt. We all know that these kinds of scenarios exist, but the rise of low-code and now no-code software platforms is seen by some as an accelerating exacerbator that could make this predicament more common.

The suggestion here is that if an enterprise uses an increasing amount of no-code tooling, then it will become disproportionately reliant upon that abstracted software toolset on a number of levels, all of which will increase the chance of lock-in.

To continue reading this article register now