Reprinted please indicate the source:
Grape City Official Website, Grape City provides developers with professional development tools, solutions and services to empower developers.

At present, low code technology is in the air, low code platform products continue to emerge, disorderly flowers gradually charming eye. As the person in charge of the IT department of a software company or enterprise, what aspects should be paid attention to when selecting the low code platform so as to “get on the bus” smoothly and enable the low code to empower their team?

In addition to whether the product features meet the requirements of the current project and whether the price is within the budget, the answers to the following questions are equally important.

Q1: Is collaborative development and versioning supported?

In the process of project development, we will inevitably encounter customers’ feedback that a newly developed feature is useless, but after a period of time, they regret it and hope to add it back. This is the norm in software development. To solve this problem, traditional software development teams introduce versioning, and low code is no exception. In the face of frequent requirement changes, thorny problem troubleshooting, version management of low code platforms, rollback of certain modules and other operations will be valued.

In addition, to speed up project delivery, we often need to focus more people on simultaneous development. Only low-code platforms with collaborative development capabilities can make the process manageable and avoid chaos.

So, regardless of the size of the project, choosing a low-code platform that is compatible with the mainstream code base and supports agile development will help.

(Git: a major version control system, image from the Git official website)

Q2: Is free design of database structure supported?

The database is the “foundation” of all enterprise management software. In order to facilitate the development of subsequent functions, the expansibility is stronger, and the maintainability is better, a good database design is very important. This point is determined by the nature of enterprise software itself, whether it is low code or traditional pure code, there will be no change.

In fact, with the development of software technology today, database design best practices have long been summarized into a well-tested database design paradigm. Whether the low code development platform can open the free design ability of database structure to developers and enable developers to continuously optimize the data structure based on the database design paradigm directly determines the professionalism of the platform. If you need to develop a high-standard core business application, or if you need extensibility or maintainability in the later stages of the application, then database design capability is critical in the evaluation process.

(Schematic diagram of database structure meeting the requirements of design paradigm, pictures from the network)

Q3: Can you design the display page flexibly and freely?

Different enterprises and different users have different usage habits and aesthetic styles. Even with the same business requirements, customers have completely different requirements for the page rendering and interaction of software. For example, Customer A prefers to look for the submit button in the upper right corner of the page. Client B might be used to having a submit button right at the bottom of the page, while Client C would prefer a submit button in the bottom right corner of the page. Therefore, we need to make different page layouts for different customers in order to reduce training costs and improve user satisfaction.

I’m sure you’ve experienced similar problems and solutions from years of software delivery experience. Of course, this example may be the tip of the iceberg, and customers’ differentiated requirements for page layout and style go far beyond this. If you recognize the importance of meeting the user’s usage habits and adapting the company’s design style, please try to choose a low code platform that supports flexible and free design of display pages, so as to ensure that we will not be stuck in a passive position in project development and delivery.

Different enterprises and different users have different usage habits and aesthetic styles. Even with the same business requirements, customers have completely different requirements for the page rendering and interaction of software. For example, Customer A prefers to look for the submit button in the upper right corner of the page. Client B might be used to having a submit button right at the bottom of the page, while Client C would prefer a submit button in the bottom right corner of the page. Therefore, we need to make different page layouts for different customers in order to reduce training costs and improve user satisfaction.

I’m sure you’ve experienced similar problems and solutions from years of software delivery experience. Of course, this example may be the tip of the iceberg, and customers’ differentiated requirements for page layout and style go far beyond this. If you recognize the importance of meeting the user’s usage habits and adapting the company’s design style, please try to choose a low code platform that supports flexible and free design of display pages, so as to ensure that we will not be stuck in a passive position in project development and delivery.

Q4: Can you support the system architecture of front and rear end separation? How to solve the complex logic of the back end?

As mentioned earlier, the software industry has evolved over the years and many best practices have evolved. Similar to the database design paradigm, there is front-end separation, database read-write separation, and so on. The previous point focused on the front end, but here we need to turn our attention to the back end.

With the support of the back-end separation architecture, both software companies and enterprise IT teams will accumulate their own “core digital assets” in the process of development. These assets are often represented in some complex logic calculation methods of back-end business (some may also contain some “magic numbers” for tuning). The logic complexity of the background is high, the accumulated value of technology is large, and it is relatively stable. How to use low code to realize complex back-end business logic and continuously accumulate “core digital assets” is a problem that low code platform must solve. When doing technical reviews, it’s important to remember that these things run in the background, without any interface logic, because these are the core competencies of the system and the development team.

(Front and rear ends separated, picture from network)

Q5: Is there a system-wide modular solution?

In the actual project delivery process, if we can only meet 99% of the requirements and the other 1% of the requirements cannot be met, the real users will probably not pay. Therefore, when evaluating low-code products, we must ensure that the platform can support the development of all types of system modules, or at least be extensible enough to ensure that modules developed in pure code can seamlessly integrate with low-code modules.

Given the huge productivity gap, the more modules the low code platform covers, the more efficient the overall project will be. So what types of modules are typically involved in enterprise software? The most common ones are as follows:

  • Multiterminal page
  • Accurately printable reports
  • A large visual screen of graphs
  • Automated task

Q6: How to ensure the system security of developed applications?

Security is critical to any system. Most of the logic in applications that use low-code platforms is built by the low-code developers themselves, rather than by the low-code platform vendors. As a result, it is hard to simply judge the security of a developed application based on the security reports of the platform, in the same way that no one cares about the security reports of Visual Studio and Eclipse.

This does not mean that we should not be concerned about the security of the low-code platform itself. So, how do we look at the security of a low-code platform, and how do we evaluate the security of developing applications using that platform? The following points are worth referring to:

  1. Does the low code platform have financial or banking customers? These industries generally have relatively high requirements for safety, and they can certainly use the general industry
  2. During the evaluation phase, you can create a demo program based on the platform and do a security check for the demo. Here are some security check tools or products: ZAP — OWASP (free), SonarQube — SonarWorks (charge), BURP Suite — Portswigger (charge), AppScan — IBM (charge)

(OWASP ZAP detection tool, picture from ZAP official website)

Q7: Is the platform independent and independent of other third party products?

As strange as this point may sound, why would a low-code platform rely on a particular third-party product? This is related to the development stage of low code in China. Let me give you two examples:

  • Some products say it’s the design mode of Excel, but in fact all of their page design is in Excel, and even when they visit it, they access it in Excel, which doesn’t sound like a big deal, but there’s a very important point, Excel often updates Excel2008, Excel2010, Excel2016,… . In this way, you need to buy their platform again every time you upgrade Excel;
  • Some low-code products claim to be B/S architectures, but you have to install their specific browser to access them. How is this different from C/S architectures?

To ensure that the subsequent development and deployment process is manageable, I recommend that you prioritize independent, low-code platforms. If, for other reasons, you need to choose a low-code platform that relies on specific third-party software, such as a database, Web server, etc., you need to include those dependencies in your deployment manifest and manual.

Q8: Will new “data islands” be created?

The concept of data island has been the problem that the enterprise information industry hopes to solve most since it was put forward. As a new generation of software development technology, we don’t need to use low-code applications to become new islands of data. So, whether it’s connecting to an existing database or supporting interoperability with other software through Web APIs, low code must be open and not create new database silos.

Further, if this low-code platform can help us solve the problem of data island of the enterprise, get through multiple systems and realize synergism by integrating multi-source data, it will be an even more bonus project.

(Data island phenomenon, picture from the network)

Q9: How about the ecological construction of products on this platform? Is there an incentive mechanism?

If a low code product chooses to fight alone, without ecology, the high probability is not long. For low code development platforms, the value of ecology is reflected in the following two aspects:

  • Templates: A template, also known as a development artifact, is a “half-baked” system built by a developer using a low-code platform for a particular industry or scenario. Secondary development based on semi-finished products can further speed up the construction of enterprise applications. A mature low-code platform usually has a template market, and through business and technical means, developers are encouraged to share or sell their applications using the platform, creating a positive cycle of “everyone for one, one for all”.
  • Plug-ins: Low-code platforms often open plug-in mechanisms to attract more developers to encapsulate their own “modules.” Plugins and platforms work together to enrich application scenarios for low-code platforms. In fact, no matter how strong the technical ability of a platform manufacturer is, it cannot meet all the requirements of customers. Only by opening up the plug-in mechanism and establishing the plug-in payment environment, can developers join in and build a stronger platform together.

The key to low code platform ecology lies in how to establish long-term incentive mechanism to achieve positive cycle, which is commonly understood as allowing developers upstream of the ecosystem to get reasonable returns through payment mechanism. We believe that only a platform ecosystem that provides long-term incentives can be sustainable.

(Multiple connector plugins, image from Power Apps website)

summary

In the boom period of low-code platforms, users should sharpen their eyes, choose the right platform products, and take full advantage of the new value and new momentum brought by new technologies. The above nine questions are the low code technology selection ideas that I sort out for you. I hope they can help software companies and enterprise IT departments that are evaluating the low code platform to avoid detour, seize the trend of The Times and start the journey of low code.