Low code is increasing. The widespread generalization and extension of low-code (and non-code) software platforms, suites, tools, and related services is on the rise. As many people know by now, low-code software solutions offer accelerators and automation that enable software application developers to work more quickly… and that (on a planet with very few developers) means they are popular.
Typically designed to compile the easily identifiable and repeatable tasks associated with coding software, low code isn’t for dummies and still requires a trained and qualified software engineer to handle it (some business people can use more services that aren’t very code-abstract), but it’s now recognized It is widely believed that their value is an essential part of the way we create applications now.
Every seller is now a low-level programmer
Once the sole specialist for organizations dedicated to low-code platforms (as we are said beforethis list usually begins with Appian, Mendix, and OutSystems), the low code has now penetrated the roadmap of what appears to be the entire enterprise software vendor space, with more than a couple (arguably) likely to implement it in an attempt to get its “share of the sound”.
With so much low code out there, how should organizations considering becoming low code customers actually talk to companies that specialize in providing this new type of enterprise application tool?
The reason this question is so difficult starts from the scope offered by the low code. Most enterprise software is designed for a specific function, such as human resources, payroll, purchasing, etc. With the low symbol, 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 a skateboard?
There is a lot to consider in a low-code purchase – and this fact means that it is really important to know how to communicate with vendors who work in this segment of the IT market. This opinion is supported by Sal Stangarona partner in an enterprise web application development company based in London and Illinois Michaels, Ross and ColeLtd.
“All these low-blade development tools are different. How different? Here’s a good analogy: Putting all the available low-blade tools into one category like roller skates, skateboards, wheelchairs, bikes, and cars into one big category called wheeled transport,” Stangarone said. “As a generalization. Sure, it can get you all from point A to point B, but the user experience is very different.”
The same diversity is true for low-code tools; Every toolkit today has 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 major questions to ask is exactly how much application customization is allowed? We usually 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 practice. Stangarone says organizations need to think about how customers customize their apps and can think about some important points.
“When a low-code user is thinking about how to customize the apps that are built, ideally, you want a graphical editor with the option to edit at the code level. Although you may rarely need to edit at the code level, it’s a great option. A must. Customers also have to wonder if they can add their own custom business logic – it’s quite a basic functionality to look for – and also the ability to add custom business rules or processes because that speaks to how well the software adapts to your business,” Stangaron explained.
What happens if we stop?
No logical software procurement manager, systems engineer, or individual software developer wants to think about the absolute negativity and consider what would happen if they stopped using any particular platform, development environment, suite or toolkit. But this reality is an important thinking in low code, especially if we take into account the popular view that adopting an abstract approach with low code vendor tools can lead to a degree of coherence.
The michaels and ross & cole team advocate first of all researching where the data is stored. The two primary options would be a) customer data is stored locally at the customer’s headquarters or b) a low code vendor stores the data and provides it as an external cloud service. Obviously, option a) provides more ability to export and download data when needed and option b) likely leaves the customer realizing that they didn’t really have control over their data the way they wanted.
“Customers with low code should also ask if their low code apps require an active subscription to run,” Stangaron said. “If the apps created need an active subscription to use them, the customer is tied to that vendor. Instead, the business should really look for apps that work independently of the developer. That way, they will work regardless of subscription status.”
Another consideration here is to consider whether a company can “maintain” (such as in maintenance of upgrades, expansion, debugging, etc.) applications outside of a low code tool. Some low-code platforms create standalone applications that can be maintained offshore, while other vendors force the customer into their platform for maintenance.
The team also reminds organizations to also ask what type of code the low-code platform 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 in use), or uses more standard software programming languages (Java, PHP, .Net, etc.). Low code platform specific code is obviously more challenging to keep off platform.
Open room for success
Customers should also consider what low-code platforms do in terms of their ability to enable the user base to actually succeed. why is that? Because the nature of low-code software is very different from that of a typical software tool.
“Typical software is closed. Software has set 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 the platform allows, even things you haven’t thought of yet. This leads to scenarios where the organization’s needs may extend beyond the scope of the tool itself. As such, the vendor behind the software plays a much larger role than typical software,” advises Stangaron.
Speaking of experience working across a selection of low-code tools over the years, the Michaels, Ross & Cole team advises that customers should always insist on support provided by a product expert already using the low-code tool on a day-to-day basis. Today themselves. This is to eliminate call center stuffiness and find product experts who can potentially help the customer by stepping in to help work with the tool itself (for example) to meet a tight deadline, or circumvent some kind of bottleneck in development.
Another area worth examining is how open a low-code seller is 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 small details like integration. How open is the vendor to adding new features or helping with integrations?
party to third party?
Another area that needs to be covered here is the question of how easily does low-code vendor tools connect to broader third-party Aplpication Programming Interfaces (APIs), frameworks and services (typically cloud-based)?
“As organizations move more of their business to the cloud, passing data between these different parts becomes critical,” Stangaron said. Moreover, there are a lot of open frameworks and services that can improve low code applications. Customers should ask how easy it is for a low-code platform to connect to cloud services and frameworks – like can the platform consume REST APIs… and also think about the fact that many companies need to add services like “single sign-on” to their applications . How easy is it to integrate something like this with your low code platform? Will the vendor help you with integration if needed? These are the questions to be asked,” Stangaron explained.
Source, scope, and simplicity (hopefully)
Low code is a growing space (based on some of the points above) that may not be fully understood and understood by the many customers who are now moving to adopt these tools.
Bringing some (if not all) of these points during the initial (if not subsequent) consultation process is certainly a path to achieving a higher level of understanding regarding source, scope, and (hopefully) the simplicity displayed in today’s low-level code arena.