Low Code / No Code: How to Get the Value, Avoid the Pitfalls

0
787 views

Share on LinkedIn

Apart from a lot of other CX-related topics like e.g. customer data platforms, customer journey orchestration, configure, price, quote, artificial intelligence, machine learning, robotic process automation, and many more, there is another topic that currently gets quite some attention.

Low code and no code platforms.

It is said that low code / no code enables the ‘citizen developer’ and frees business departments from the strings of IT departments that move too slow to be able to fulfill business needs in an adequate time.

IDC, in its Worldwide IT 2020 Predictions (free registration required to access) finds that by 2023 more than 500 million digital apps and services will be developed and deployed using cloud-native approaches, most of these targeted at industry-specific digital transformation use cases. According to Statista, in 2020 there were around 25 million software developers worldwide, who could develop these apps.

So, let’s assume IDC thinks end of 2023 in this prediction; in this case, we have 125 million apps, that need to be implemented and deployed per year. This translates to every developer being in the need of developing 5 apps per year.

This is quite a daunting task when it comes to serious apps. And this is exactly what enterprise apps usually are. Still, let us keep this number in mind.

At the same time one can hear complaints about IT not delivering solutions for their burning issues fast enough and that as a consequence revenue is lost, not realized, or efficiency cannot be improved.

Therefore, the customer experience suffers.

Enter low code and no code platforms.

These platforms promise to open up the ability to implement these needed apps by ‘democratizing development’ and by providing the ‘citizen developer’ with the tools that they need to solve their challenges on their own. At the same time they can improve the implementation speed of professional developers significantly.

Being ‘platforms’ they promise the ability to connect data from different sources and applications with easy-to-use means.

In combination, this quite sounds like the disruption of outdated incumbent structures. Business people get urgently needed solutions to their issues right at their fingertips; IT departments get much-needed relief from their overload; businesses get more efficient and customers a better experience.

Sounds good, doesn’t it?

Almost too good to be true.

And, as with most things that sound too good to be true, it probably isn’t true.

Although there is a kernel – perhaps even more than just a kernel – of truth in this promise. And this kernel has a lot to do with the differentiation between processes and tasks and with the differentiation between customization and personalization.

Let’s start with the myth.

In plain English: Low code / no code platforms will not allow every member of a business department to just build the applications (s)he needs to efficiently perform and automate the work at hand. This work often includes the maintenance of data in different systems.

Several reasons speak against allowing them to freely build applications on top of these data silos. Most notably, there are the needs for data security, data privacy, and data consistency. Besides, isn’t one of the main problems that shall get addressed with low code / no code exactly the implementation of departmental point solutions? As Alan Trefler, CEO of Pegasystems stated in a recent CRMPlayaz episode: “This smells an awful lot like the times of Lotus Notes, where huge databases of applications got created.” With the unfettered ability to create applications and data we run the risk of creating even more data dirt.

The next challenge is maintainability. What happens with the next upgrade of the business software? Does the departmental or personal app still work? How much time will flow into the maintenance of this new breed of shadow IT apps? Again, as the example of the humongous Lotus Notes database shows: not much. There will just be a museum of forgotten about additional apps and potentially even a maintenance nightmare that in all likelihood haunts an already strained IT department.

Last, but not least, there are likely to be license implications that are caused by accessing other applications.

Consequently, businesses will really want to ringfence this ability.

And the kernel of truth?

On the other hand, we have the, admittedly enhanced, abilities to configure, customize and personalize business systems that especially no code platforms offer.

Especially customizing via configuration has been possible since the 80s of the last century, if not longer. But doing this usually requires a high degree of IT skills and knowledge of the internal workings of the application. Many business apps also offer embedded workflow engines for quite some time now. Some renowned business application vendors even have their roots in offering workflow engines (think of Pegasystems or Creatio, formerly known as BPM’Online).

Hell, back in the 90’s at Kiefer & Veittinger, we had an environment that enabled our business consultants to build fully functioning applications without writing a single line of code. Admittedly, to get to the final version, it needed serious development, but still, this was a significant feat.

SAP’s R/3 was configurable without coding right from the outset. Again, coding often becomes necessary. Still, point in case is that we currently hype a vehicle that is there for quite a long time. One of the underlying visions behind SAP Business by Design was giving the ability to build business processes and applications by connecting business objects through pointing and clicking, essentially without coding – before I get yelled at, I know that this hasn’t been achieved.

The advent of SaaS made things a bit more challenging. Vendors became more careful with what customizations they allow customers to do, generally restricting abilities considerably. In addition, many SaaS apps started less rich than the corresponding on-premise apps that they were supposed to replace. This, in turn, increased the necessity for custom development to enhance the applications.

Last, but not least, especially business analysts and superusers have a lot of knowledge about their processes and their shortcomings. Given some training and the right toolset and privileges, they can create creative and sometimes even sophisticated solutions that then also help to increase the customer experience as these solutions free employees to do more important work than business chores.

So, low code and no code platforms certainly have their place in a business ecosystem.

OK, what to do now?

Make no mistake: Low code / no code is here to stay. So are the corresponding platforms.

Along with other technologies, e.g. robotic process automation, it has the potential to help businesses overcome challenges that affect both, employee experience and customer experience by offering a way to automate and accelerate dull tasks, thereby improving reaction times.

Given the additional need for increasing efficiency, business leaders should strongly consider the adoption of a no code / low code platform to accomplish two objectives:

  1. Help the IT department deliver an ever-increasing demand faster
  2. Provide business departments with an additional help to help themselves

As part of doing this, a governance framework needs to be established that, amongst other more operational topics, defines the scopes of applications that the different groups of employees are allowed (and able) to create and deploy. In addition, it needs to describe mechanisms for storing, indexing, and helping other people finding and using them.

Once this is clarified, it is time to decide upon the right low code / no code platform to deploy. There is a good number of them around, with notable names (in no particular order) being Mendix, Salesforce, Pega, Creatio, Microsoft, Outsystems, but also Oracle and Appian. The analysis firm G2 offers deeper insight in its grids on no code and low code.

The platform of choice needs to be able to cover the current and known future needs as well as the defined restrictions. It also needs to be a good fit for the already existing business application platform(s).

Once the matching platform is purchased, do a phased rollout. Start with the IT department, assess, and then gradually involve more stakeholder groups. Reassess. This way, it is possible to learn, adapt and grow, so that this platform can be used with maximum effect while not creating a graveyard of applications.

LEAVE A REPLY

Please enter your comment!
Please enter your name here