How to Talk to a Low-Code Vendor

Low-code is growing. The widespread popularization and extension of low-code (and no-code) software platforms, suites, tools, and related services are on the rise. As many people know by now, low-code software solutions offer accelerators and automations that allow software application developers to work faster…and that (on a planet with too few developers) means that they are popular.

Generally designed to compose the more easily defined and repeatable tasks associated with coding software, low-code is not for dummies and still requires a skilled and professionally trained software engineer to handle it (more highly abstract no-code services can be used by some business people), but its value is now widely recognized as integral to the way we now build apps.

Every supplier is now a low-coder

Once the only specialized pool of organizations dedicated to the low-code platform (like us has already saidthis list typically starts with Appian, Mendix, and OutSystems), low-code has now penetrated the roadmap of what appears to be the entire enterprise software vendor space, with more than a couple of ‘companies (presumably) sticking to it in an attempt to get a “share of voice”.

With so much low-code, how should organizations considering becoming low-code customers actually talk to companies that specialize in delivering this next generation of enterprise application tools?

The reason this question is so difficult starts with the sheer scope that low-code offers. Most business software is designed for a specific function, such as HR, payroll, purchasing, etc. With low-code, the sky is the limit. You can use it for anything, i.e. even projects you didn’t plan to use it for.

The simplicity of skateboarding?

There’s so much more to consider in a low-code purchase – and that truth means it’s really important to know how to communicate with vendors who operate in this segment of the IT market. This opinion is supported by Sal Stangaronepartner of an enterprise web application development company based in London and Illinois Michaels, Ross & ColeLtd.

“All of these low-code development tools are different. What’s the difference? Here’s a good analogy: Putting all available low-code tools into one category is like putting roller skates, skateboards, wheelchairs, bicycles and cars in a broad category called ‘wheeled modes of transport’ in general. Sure, they can all get you from point A to point B, but the user experience differs hugely,” Stangarone said.

The same diversity is true for low-code tools; today’s toolsets all have different functionality, interfaces, limitations, and use cases. What organizations looking to adopt these tools now need to understand is that it’s impossible to compare options if you don’t know what to look for.

One of the first key questions to ask is how much customization of the resulting application is allowed? Generally, we think of low-code as an environment with limited (or no) customization options for software applications produced with these tools, but this is rarely the case in real-world practice. Stangarone says that organizations need to think about how customers will customize their applications can take into account some important points.

“When a low-code user is thinking about how they will customize the generated apps, ideally you want a graphical editor with the ability to edit at the code level. Although you rarely need to edit at the code level, c is a great option to have. Customers should also consider whether they can add their own custom business logic – that’s a fairly essential feature to look for – as is the ability to add custom business rules or processes, because it indicates how well the software will fit your business,” Stangaron explained.

What happens if we stop?

No software purchasing manager, system architect, or individual software developer wants to think about the ultimate negative and consider what will happen if they stop using a platform, development environment, suite, or set of software. given tools. But this reality is an important consideration in low-code, especially considering the popular view that taking an abstract approach with a low-code vendor’s tools can lead to some degree of lockdown.

The michaels, ross & cole team recommends first seeing where the data is stored. The two basic options would be a) the customer data is stored on-premises at the customer’s headquarters or b) the low-code provider stores the data and provides it as an external cloud service. Obviously option a) provides more scope to export and download data when needed and option b) can potentially leave a customer realizing they never really had control of his own data as he wished.

“Low-code customers should also ask if their low-code apps require an active subscription to run,” Stangaron said. “If the generated applications require an active subscription to be used, the client is tied to this provider. Instead, a business should really look for apps that run independently of the developer tool. This way they will work regardless of the subscription status.

Another consideration here is whether a company can “maintain” (as in servicing upgrades, expansion, patches, etc.) applications outside of the low-code tool. Some low-code platforms generate standalone applications that can be maintained externally, other vendors force the customer to come to their platform for maintenance.

The team also reminds organizations to also ask what type of code the low-code platform actually generates in terms of the type of software language used. Customers will need to know if the platform generates proprietary code (specific to the low-code platform used itself) or uses more standard software programming languages ​​(Java, PHP, .Net, etc.). Proprietary low-code platform-specific code is obviously more difficult to maintain outside of the platform.

Open Scope of Success

Customers also need to think about what a low-code platform does in terms of being able to enable a user base to actually succeed. Why is it? Because the nature of low-code software is very different from the nature of a typical software tool.

“Typical software is closed. Software has defined capabilities and you know how you are going to use it. Low-code software is different. It combines the closed nature of software with the open nature of software development. You can develop anything what the platform enables, even things you haven’t thought of yet. This can lead to scenarios where an organization’s needs may even exceed the scope of the tool itself. As such, the vendor behind the software plays a much bigger role than with typical software,” advises Stangaron.

Drawing on their experience working on a selection of low-code tools over the years, the michaels, ross & cole team advises customers to always insist on support from a product expert who actually uses the everyday low-code tool. day by day themselves. It’s about eliminating call center padding and finding product experts who could potentially help a customer by stepping in to help work with the tool itself to (for example) meet a tight deadline or circumvent a sort of development bottleneck.

Another area worth considering is a low-code provider’s openness to “feature requests” (i.e. new functionality) from customers. Organizations need to think about what happens if they need a new feature, customization or integration added to the software, Stangaron asks. Anyone who has developed software knows that the devil is in the little details like integration. How open is the vendor to adding new features or helping with integrations?

Party to third party?

Another area to cover here is how easily a low-code vendor’s tools connect to third-party application programming interfaces (APIs), frameworks, and (usually cloud-based) services. wider?

“As organizations move more of their business to the cloud, the transmission of data between these different elements becomes critical,” Stangaron said. Besides that, there are many open frameworks and services that can enhance low-code applications. Customers should consider how easily a low-code platform will connect to cloud services and infrastructure – like a platform can consume REST APIs…and also consider the fact that many companies need to add services such as “single sign-on” for their applications. How easily can you integrate something like this with your low-code platform? Will the provider help you with the integration if needed? These are the questions to ask,” Stangaron explained.

Source, scope and (hopefully) simplicity

Low-code is a growing space that (based on some of the points above) may not be fully and completely understood by many customers now looking to adopt these tools.

Raising some (if not all) of these points during an initial (if not subsequent) consultation process is certainly a way to achieve a higher level of understanding with respect to source, scope and (hopefully) the simplicity of offering in the low-code arena today.

Leave a Reply

Your email address will not be published.