Key Considerations for Implementing No-Code Tools

If you’re looking to leverage low or no-code tools as a solution within your enterprise, there are a number of factors to consider to ensure success.

Integration

In choosing a low or no-code solution to solve a process challenge, a key consideration for your project should be integration.

For businesses looking to build a simple, low-end low or no-code solution, integration won’t necessarily be an issue.

However, as with nearly every system, as they get bigger due to requirements evolving, bringing in more business processes and additional workflows, data will inevitably sit across your low or no-code solution and other business systems.

At the offset businesses should ask three core questions:

• What are you going to integrate with?
• How are you going to execute the integration?
• Where is the software that fulfils the integration going to sit?

For example, is this within your low or no-code tool, in the tool that is going to pull data across, or within an integration service in the middle?

Integration can be considered as in the same sense as electric cars and the concept of the long tail pipe. An electric car can be ‘completely green’, but what is the emission requirement to charge the battery? You may have a no-code solution to your problem, yet you may have a stack of code that is trying to integrate with disparate systems.

In order to resolve this, businesses seeking low or no-code solutions should establish where they are going prior to implementation, identifying potential integration points and choosing the appropriate tool that supports this.

Without this, businesses risk being in a situation where they have replaced one problem with another. You may have successfully replaced your complex spreadsheets with a no-code solution, but in order to get anything useful from it, you need to export spreadsheets and complete additional work.

People & Roles

In implementing low or no-code solutions, businesses also need to consider which people will be involved – which employees will build the solution, which people will use the system and what are their defined roles.

In traditional approaches, you’d have assumed roles such as, at a lower end, employees simply creating spreadsheets and saving them onto office 365. And at a higher end ,in large-scale software projects, clearly defined roles in project managers, product owners, business analysts, developers and testers, with an established methodology.

Here, businesses need to define what the team will look like. For example, if you’re aiming to create a simple no-code application that can be built in a couple of days, do you need fifteen people for delivery?

At this stage it’s important to establish a sensible balance of roles appropriate to your project in order to ensure a successful and optimised delivery.

Visibility

Visibility is also a key consideration when implementing low and no-code tools from a security perspective.

Businesses should define who is actually going to be using the solution. Is the product going to be internally accessible across departments, publicly visible to 3rd parties, or globally visible on the web?

It is common to see tools initially being used by an individual or small team, which then evolve, resulting in more people using the solution. All of a sudden, data held in the system, that was potentially sensitive and only meant to be visible to one/a few person, can begin to creep out across internal and external locations.

This can end up creating a shadow IT environment, with people taking it upon themselves to publicly make internal data available externally. With risks around unknown authentication, this can present potentially significant data security issues.

In order to avoid this, businesses need to ensure they have robust policies and procedures in place for data security, and consider rigorous testing for a full-proof solution.

Roadmap

Businesses should consider their overall vision and where they want to go with their low or no-code solution, in both the short and long term.

Prior to implementation, organisations should ask questions around:

• How long is the platform going to be used for?
• Are we using it to solve a specific problem?
• Are we using it as a prototyping tool to develop ideas?
• Is this a stepping stone to a bigger system we will be moving to?

In some cases, as these apps develop, businesses can quickly find themselves in a position where people across teams have limited knowledge of what’s going on, what decisions have been made and why they have been made. Here it is important to have a clear change management processes when initially adopting a no-code solution, alongside appropriate documentation.

When considering roadmaps, it’s key to identify the use-case for your solution appropriately. This will provide a core foundation to build in line with.

Businesses should consider the long and short term objectives and define whether they are choosing the application as a quick solution to get over a bump, solve a specific challenge or achieve end goals.

Data Security

As with any software project, data security is always a key consideration, particularly with regards to availability, confidentially and integrity, as in ISO:27001 standards.

When choosing a no-code platform, businesses should ensure they cover security factors such as:

• How do you manage sensitive information?
• What is the impact of a data breach or data loss?
• How are we training people for managing secure data?

It’s key to start with policies and procedures at the beginning of the project, which would fall in line with ISO:27001. As well as prioritising user education around what they are using the product for and what type of data should be going on this type of system.

As with any other web application project, businesses should carry out a level of testing too. Here it’s worth noting about 3rd parties – in some cases the product may be hosted on a 3rd party platform, so you would need to gain approval before you carried out testing such as penetration tests or performance tests, in case you run into any issues and affect other users in parallel.