Why firms are starting to talk more about low code/no code

Mainstream among retail and manufacturing sectors, the securities services industry should be paying more attention to more adaptable technology codes, writes Virginie O’Shea, founder of Firebrand.

It’s no secret that when it comes to core technology transformation, as an industry we’re pretty far behind other sectors like retail. That sector and manufacturing have been talking low code for some time, but we’re starting to wake up to the benefits of not having to suffer the IT bottleneck when tweaking or adapting our core operational systems.

The vendor community has been marketing the heck out of anything that even vaguely resembles a low code environment for some time (even if it isn’t low code at all under closer examination), but what does it actually mean? Essentially a low code environment is one that doesn’t require specialist knowledge of the technology’s proprietary code base to be able to make changes (usually minor ones) to the system. This means that business users that have received some training (and we’re not talking years of coding here, more like a few weeks) can adapt the system as market, client or regulatory requirements dictate.

This could mean adding a new field to a report via a simple drag and drop interface, or it could mean tweaking a reconciliation rule via an easy-to-use rules dashboard. The key here is that the environment democratises the process of making changes to a technology solution, so that the request isn’t added to the long list of the firm’s overburdened IT team. Given the number of changes firms must make to their systems in any given year due to regulatory updates such as ESMA’s endless stream of Q&A documents, or client requests for a new piece of data presented in a certain way, such an environment can mean competitive advantage over your peers.

Such an environment is not easily found however, as it takes a solution that has been built with business user experience in mind (and we all know many core platforms look more like they’ve been designed by and for IT people). Moreover, it also must have been built by people that understand the nuances of the process intimately—this isn’t easy when you look at some of the complexities of the process that must be simplified into an easy-to-use front end.

Last year, I blogged about how firms need to think more about user experience and this is a further extension of that notion. If we can rely on our wider pool of employees to be able to adapt the systems they use on a day-to-day basis—in a controlled and auditable manner, of course—couldn’t we reduce our key person risk, increase our time to market and become better, more agile organisations as a result? Just some food for thought.