How To Talk To A Low-Code Vendor

Cloud How To Talk To A Low-Code Vendor Adrian Bridgwater Senior Contributor Opinions expressed by Forbes Contributors are their own. I track enterprise software application development & data management. New! Follow this author to improve your content experience.

Got it! Jul 6, 2022, 03:03am EDT | Share to Facebook Share to Twitter Share to Linkedin Low-code is not just a one click-and-go experience. Adrian Bridgwater Low-code is growing. The widespread popularization and extension of low-code (and no-code) software platforms, suites, tools and related services is in the ascendancy.

As many people will know by now, low-code software solutions offer accelerators and automations that enable sofware application developers to work more quickly. . .

and that (on a planet with too few developers) means they are popular. Typically built to componentize the more easily defined and repeatable tasks associated with coding software, low-code is not for dummies and still requires a professionally trained and qualified software engineer to handle it (more highly abstracted no-code services can be used by some businesspeople), but its worth is now widely recognized to be a core part of the way we now create applications. Every vendor is now a low-coder Once the sole specialist preserve of dedicated low-code platform organizations (as we have said before , this list usually starts with Appian, Mendix and OutSystems), low-code has now penetrated the roadmap of what seems to be the entire enterprise software vendor space, with more than a couple of firms (arguably) likely just tacking it on in an attempt to gain some ‘share of voice’.

With so much low-code out there, how should organizations thinking of becoming low-code customers actually talk to the firms that specialize in providing this new breed of enterprise application tools? The reason this question is so tough starts from the very scope that low-code offers. Most enterprise software is built 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 that you haven’t planned to use it for.

MORE FOR YOU Western Digital’s Journey To Build Business Resiliency Through Cloud And ERP Transformation Amazon Climate Pledge: Two Years In And Going Strong Microsoft Takes First Steps To Finally Kill The Password Skateboard simplicity? There’s so much more to consider in a low-code purchase – and this truth means it’s really important to know how to communicate with the vendors that operate in this segment of the IT market. This view is backed up by Sal Stangarone , partner at London and Illinois-based enterprise web application development company michaels, ross & cole , ltd. “All of these low-code development tools are different.

How different? Here’s a good analogy: Placing all of the available low-code tools into one category is like grouping rollerskates, skateboards, wheelchairs, bikes and cars into one big category called ‘wheeled modes of transportation’ as a generalization. Sure, they can all get you from point A to point B, but the user experience differs wildly,” said Stangarone. The same diversity is true for low-code tools; today’s toolsets all have different features, interfaces, limitations and use cases.

What organizations looking to adopt these tools now need to realize is that comparing options is impossible if you don’t know what to look for. One of the first key questions to ask is just exactly how much resulting application customization is allowed? Typically we think of low-code as an environment with limited (or no) customization options for the software apps 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 apps can consider some important points.

“When a low-code user thinks about how they will customize the generated applications, ideally you want a graphical editor with the option to edit down at the code-level. While you might rarely need to edit at the code level, it’s a great option to have. Customers should also question whether they can add their own custom business logic – it’s quite an essential function to look for – as is the ability to add custom business rules or processes because this speaks to how well the software will adapt to your business,” explained Stangarone.

What happens if we stop? No rationale software procurement director, systems architect or individual software developer wants to think the ultimate negative and consider what happens if they stop using any given platform, development environment, suite or toolset. But this reality is an important conidersation in low-code, especially if we consider the popularized view that adopting an abstracted approach with a low-code vendor’s tools can lead to a degree of lock-in. The michaels, ross & cole team advocate first looking to see where data gets stored.

The two basic options would be a) customer data is stored on-premises at the customer’s own headquarters or b) the low-code vendor stores the data and supplies it as an external cloud service. Clearly, option a) offers more ability to export and download data when needed and option b) can potentially leave a customer realizing that they never really owned control of their own data in the way they wanted to. “Low-code customers should also ask whether their low-code applications require an active subscription to run,” said Stangaron.

“If generated applications need an active subscription to be used, the customer is tied to that vendor. Instead, a business should really be looking for applications that run independently of the development tool. That way, they’ll work regardless of subscription status.

” Another consideration here is to think about whether a business can ‘maintain’ (as in maintenance for upgrades, expansion, patching and so on) applications outside of the low-code tool. Some low-code platforms generate standalone applications that can be maintained outside, other vendors force the customer into their platform for maintenance. The team also reminds organizations to also ask what kind of code does the low-code platform actually generates in terms of what type of software language used.

Customers will need to know whether the platform generates proprietary code (specific to the low-code platform in use itself), or uses more standard software programming languages (Java, PHP, . Net, etc. ).

Proprietary low-code platform-specific code is obviously more of a challenge to maintain outside of the platform. Open scope for success Customers should also think about what a low-code platform does in terms of its ability to enable a user base to actually succeed. Why is this? Because the nature of low-code software is far different from the nature of a typical software tool.

“Typical software is close-ended. The software has set capabilities and you know how you’re going to use it. Low-code software is different.

It combines the close-ended nature of software with the open-ended nature of software development. You can develop anything that the platform allows, even things that you haven’t thought of yet. The can result in scenarios where an organization’s needs may even go past the scope of the tool itself.

As such, the vendor behind the software plays a much larger role than with typical software,” advises Stangaron. Speaking from experience working across a selection of low-code tools over the years, the michaels, ross & cole team advise that customers should always insist on support provided by a product expert who actually uses the low-code tool on a day-to-day basis themselves. This is to weed out the call center padding and get down to finding product experts that could potentially help a customer by stepping in to help work with the tool itself to (for example) meet a tight deadline, or get around some kind of development bottleneck.

Another area worth examining is just how open a low-code vendor is to ‘feature requests’ (i. e. new functionalties) from customers.

Organizations need to think about what happens if they need a new feature, customization or integration added to the software asks Stangaron. Anyone who has developed software knows that the devil lies in the little details like integration. So just how open is the vendor to adding new features or assisting with integrations? Party to third party? One more area to cover here is the question of how easily a low-code vendor’s tools connect with wider third-party Aplpication Programming Interfaces (APIs), frameworks and (usually cloud-based) services? “As organizations move more of their business to the cloud, passing data between these different pieces becomes critical,” said Stangaron.

On top of that, there are plenty of open frameworks and services that can improve low-code applications. Customers should ask how easily a low-code platform will connect with cloud services and frameworks – such as can a platform consume REST APIs. .

. and also think about the fact that many businesses need to add services like ‘single sign-on’ to their applications. How easily can you integrate something like this with your low-code platform? Will the vendor help you with integration if necessary? These are the questions to ask,” explained Stangaron.

Source, scope & (hopefully) simplicity Low-code is a growing space that (based on some of the above points) may not be thoroughly and completely understood by many of the customers now moving to adopt these tools. Bringing some (if not all) of these points up during an initial (if not subsequent) consultation process is surely a route to achieving a higher tier of understanding in relation to the source, scope and (hopefully) simplicity on offer in the low-code arena today. Follow me on Twitter or LinkedIn .

Adrian Bridgwater Editorial Standards Print Reprints & Permissions.