When selecting a low-code platform, which aspects must be evaluated?

Please indicate the source for reprinting: , the official website of Grape City, Grape City provides developers with professional development tools, solutions and services, and empowers developers.

Currently, low-code technology is in the air, low-code platform products continue to emerge, and squandering is gradually becoming fascinating. As the person in charge of a software company or an enterprise IT department, what aspects do you need to pay attention to when selecting a low-code platform in order to smoothly "get on the car" and enable low-code to empower your team?

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

Q1: Does it support collaborative development and version management?

During the project development process, we will inevitably encounter a situation where a customer feedback that a newly developed function is useless, but regrets it after a period of time and hopes to add it back. This is the norm in software development. In order to solve this problem, traditional software development teams will introduce a version management mechanism, and low code is no exception. In the face of frequent demand changes, difficult troubleshooting, version management of low-code platforms, and specific module rollbacks, the value of operations will be reflected.

In addition, in order to accelerate the delivery speed of the project, we usually need to concentrate more personnel for simultaneous development. Only a low-code platform with collaborative development capabilities can make this process manageable and avoid confusion.

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

(Git: a mainstream version control system, the picture comes from the official Git website)

Q2: Do you support free design of database structure?

The database is the "foundation" of all enterprise management software. In order to make the development of subsequent functions more convenient, more scalable, and better maintainable, a good database design is essential. This point is determined by the properties of enterprise software itself, no matter it is low code or traditional pure code, there will be no change.

In fact, with the development of software development technology to this day, the best practices of database design have long been summarized as a tried and tested database design paradigm. Whether the low-code development platform can open up the free design capabilities of the database structure to developers, allowing 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 high-standard core business applications, or have requirements for scalability and maintainability in the later stages of the application, then database design capabilities are crucial in the evaluation process.

(Schematic diagram of the database structure that meets the requirements of the design paradigm, the picture comes from the Internet)

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

Different companies and different users have different usage habits and aesthetic styles. Even in the face of the same business requirements, customers will have completely different requirements for the presentation and interaction of software pages. For example, customer A prefers to find the submit button in the upper right corner of the page; customer B may be accustomed to the submit button appearing directly below the page, and customer C prefers the design of the submit button in the lower right corner of the page. So we need to make different page layouts for different customers to reduce training costs and improve user satisfaction.

For similar problems and solutions, I believe you have experienced it in your years of software delivery experience. Of course, the example here may be the tip of the iceberg, and the customer's differentiated requirements for page layouts and styles are far more than that. If you recognize the importance of satisfying the user's habits and adapting to the company's design style, please try to choose a low-code platform that supports flexible and free design of display pages to ensure that we will not fall into passiveness during project development and delivery.

Different companies and different users have different usage habits and aesthetic styles. Even in the face of the same business requirements, customers will have completely different requirements for the presentation and interaction of software pages. For example, customer A prefers to find the submit button in the upper right corner of the page; customer B may be accustomed to the submit button appearing directly below the page, and customer C prefers the design of the submit button in the lower right corner of the page. So we need to make different page layouts for different customers to reduce training costs and improve user satisfaction.

For similar problems and solutions, I believe you have experienced it in your years of software delivery experience. Of course, the example here may be the tip of the iceberg, and customers' differentiated requirements for page layouts and styles are far more than that. If you recognize the importance of satisfying the user's habits and adapting to the company's design style, please try to choose a low-code platform that supports flexible and free design of display pages to ensure that we will not fall into passiveness during project development and delivery.

Q4: Is it possible to support a system architecture with separation of front and back ends, and how to solve the complicated back-end logic?

As mentioned earlier, the software industry has developed for many years and has accumulated many best practices. Similar to the database design paradigm, there are separation of front and back ends, separation of database read and write, and so on. The previous point focused on the front end, but here we will turn our attention to the back end.

With the support of the front-end and back-end separation architecture, both software companies and corporate IT teams will accumulate their own "core digital assets" during the development process. These assets are often manifested in the complex logic calculation methods of some back-end business (some may It also contains some "magic numbers" for tuning). The background logic is highly complex, and the accumulated value of technology is large, and it is relatively stable. How to use low-code to implement complex back-end business logic and continue to accumulate "core digital assets" is a problem that low-code platforms must solve. When doing technical evaluation, don't forget that these run in the background without any interface logic, because these are the core competitiveness of the system and development team.

(The front and back ends are separated, the picture comes from the network)

Q5: Is there a solution for system-wide modules?

In the actual project delivery process, if we can only meet 99% of the needs and the other 1% cannot be met, there is a high probability that real users will not pay. Therefore, when evaluating low-code products, we must ensure that the platform can support the development of all system module types. At least it must have sufficient scalability to ensure that modules developed using pure code can be compatible with low-code modules. Sewing integration.

Taking into account the huge productivity gap, the more modules covered by the low-code platform, the higher the development efficiency of the entire project. So, what types of modules are usually involved in enterprise software? I list the most common of them as follows:

• Multi-terminal page
• Accurately printable reports
• Large visualization screen composed of charts
• Automated tasks

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

Security is essential to any system. In applications developed using low-code platforms, most of the logic is built by low-code developers, not from low-code platform vendors. Therefore, it is difficult for us to simply judge the security of the developed application through the security report of the platform, which is equivalent to no one caring about the security report of Visual Studio and eclipse.

This does not mean that we do not need to care about the security of the low-code platform itself. So, how do we view the security of low-code platforms and how to evaluate the security of applications developed using this platform? The following points are worthy of reference:

1. Does this low-code platform have financial or banking customers? These industries generally have relatively high security requirements, and they can be used in general industries.
2. In the evaluation phase, you can create a demo program based on the platform and perform a security check on this demo. Here are some security check tools or products: ZAP-OWASP (free), SonarQube-SonarWorks (charged), Burp Suite- PortSwigger (charged), AppScan-IBM (charged)

(OWASP's ZAP detection tool, the picture comes from ZAP official website)

Q7: Is the platform independent and can it not rely on other third-party products?

This sounds a bit strange, why are there low-code platforms that rely on specific third-party products? This is related to the development stage of the domestic low-code. Let me give two examples:

• Some products say that it is the design mode of Excel, but in fact, all their page design is in Excel, and even when they are accessed, they are also accessed in Excel. It does not sound like a big problem, but there is a very important point, Excel. We often update Excel2008, Excel2010, Excel2016,..., so every time Excel is upgraded, you need to purchase their platform again;
• Some low-code products say that they have a B/S architecture, but you must install their specific browser to access them. What is the difference between this and a C/S architecture system?

In order to ensure that the subsequent development and deployment process is controllable, I recommend that you choose an independent low-code platform first. If for other reasons you need to choose a low-code platform that relies on specific third-party software, such as databases, web servers, etc., you need to include these dependent software in the deployment list and operation manual.

Q8: Will there be new "data islands"?

Since the concept of data islands was put forward, it has always been the problem that the enterprise information industry most hopes to solve. As a new generation of software development technology, we do not need to use low-code applications to become new data islands. Therefore, whether it is to connect to an existing database or to support intercommunication with other software through Web API, the low-code must be open, and new database islands cannot be created.

Going further, if this low-code platform can help us solve the problem of enterprise data islands, connect multiple systems, and achieve synergy through the integration of multi-source data, then it will be a bonus project.

(Data island phenomenon, the picture comes from the Internet)

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

If a low-code product chooses to fight alone, without ecology, it is highly probable that it will not last forever. For low-code development platforms, the ecological value is mainly reflected in the following two aspects:

• Template: A template is also called a development result, which refers to a "semi-finished" system built for a specific industry or scenario by a developer using a low-code platform. The secondary development based on semi-finished products can further improve the construction speed of enterprise applications. A mature low-code platform usually has a template market. Through commercial and technical means, developers are encouraged to share or sell the applications they have developed using the platform in the market to create a "everyone for me, I am for everyone". To cycle.
• Plug-ins: Low-code platforms usually open up the plug-in mechanism to attract more developers to package their own "modules". The plug-in and the platform run together to enrich the application scenarios of the low-code platform. In fact, no matter how strong the technical capability of a platform manufacturer is, it cannot fully satisfy all the needs of its customers. Only by opening the plug-in mechanism and establishing a plug-in payment environment can the majority of developers participate and work together to build a more powerful platform.

The key to the low-code platform ecology is how to establish a long-term incentive mechanism to achieve a positive cycle. The popular understanding is to allow developers in the upstream of the ecosystem to obtain reasonable returns through the payment mechanism. We believe that only a platform ecosystem that provides a long-term incentive mechanism can last.

(A variety of connector plug-ins, the picture comes from the official website of Power Apps)

summary

During the blowout period of low-code platforms, users should keep their eyes open, choose appropriate platform products, and make full use of the new value and new momentum brought by new technologies. The above nine questions are the low-code technology selection ideas I have compiled for you. I hope to help software companies and enterprise IT departments that are evaluating low-code platforms avoid detours, seize the trend of the times, and start a low-code journey.