Low Code Capability Model

Preface

Under the banner of low-code, various low-code platforms are bustling:

• Application scenarios: PC middle and back office, mobile H5, mini programs, also cross-platform like React Native

• Core functions: UI orchestration, (logic) process orchestration, even service orchestration

• Interaction methods: form configuration, drag and drop, even rich text extension

Can't help but have several questions:

• Compared to them, what's special about the low-code platform I'm doing (or going to do)? What key problems can only be solved by ourselves?

• Which stage is the platform in hand currently at? Where is the next stage? How to get to the next stage?

To resolve these doubts, we try to establish a capability model, making the changes of low-code platforms traceable.

I. Business Scenarios

The first dimension of the capability model is business scenarios. The more business scenarios covered, the stronger the low-code capability.

Business scenarios can be divided from different angles, for example:

• Product: 2C, middle and back office

• Business: marketing activities, feedback forms, regular text and image display, complex rich interactions

• End: mobile, PC Web, mini programs

Such broad categories may not be suitable for all businesses. Can be specifically divided according to business importance (core, important, edge), degree of difference (technical system used, user groups faced), etc. If necessary, can also subdivide into various sub-dimensions. The purpose is to quantitatively describe the support degree of existing low-code capabilities for target business scenarios. Which types of business scenarios can the platform already satisfy? Which can it satisfy in the future?

On the basis of vertical scenario division, can also derive mixed exploration directions such as cross-business line delivery, cross-end building and delivery, one-build-multiple-delivery.

II. User Groups

The second dimension is the user groups facing the low-code platform. The larger the user group, the stronger the low-code capability.

Generally divided by user professionalism:

• Specific technical personnel: frontend, backend, DBA and other professionals

• General technical personnel: developers with certain logic coding capabilities, can quickly understand and use concepts like expressions, events, etc.

• Non-technical personnel: product, operations, business, administrative personnel without development experience

If the platform's ultimate goal is to face non-technical personnel, then it requires high abstraction of functions, shielding lower-level technical details, to lower the usage threshold and bring in a wider range of users. On the other hand, the number of users is also an important indicator for measuring low-code capability. The larger the covered user volume and the more users of different attributes (teams, departments, third parties), the more it can reflect the maturity of the low-code platform.

III. Capability Completeness

The third dimension is capability completeness (i.e., the completeness degree of technical expressiveness). The higher the completeness, the stronger the low-code capability.

In target business scenarios, a low-code development platform with complete capabilities has technical expressiveness equivalent to source code development. That is, what can be achieved by manually writing code can definitely be completed through the low-code development platform.

Taking Web App as an example, capability completeness requires the low-code platform to be able to express UI (including interaction effects), frontend business logic, API calls, even backend business logic, data models, etc. It can replace source code development, and target users can complete all development work of target requirements through the platform, rather than being limited by platform capabilities and only able to complete a certain part of the work.

IV. Raw Material Inclusiveness

The fourth dimension is raw material inclusiveness, i.e., the low-code platform's acceptance ability for different inputs, for example:

• Does it support entering existing business components and modules?

• Does it support referencing any third-party modules?

• Does it support introducing non-standard modules?

A major advantage of source code development lies in being able to maximize reuse of existing code. Whether public components/business components, third-party modules, or even non-standard modules, can be introduced through encapsulation at any time, or even reused through source code copying. Low-code platforms are different. For components and modules, there are mostly clear access rules. Only "raw materials" that meet standards can enter the pool for platform users to reuse.

A simple approach is to divide into public components and business components according to the generality of components (module processing is similar to components, this section will not strictly distinguish). The platform only collects general public components, greatly simplifying component version management. But this division is not suitable for businesses with long-term continuous iteration. Due to inability to reuse existing code, development efficiency in low-code mode is far lower than highly reusable source code development.

Therefore, a better approach is to divide components into standard components and custom components according to standard degree:

• Standard components: Components preset by the platform

• Custom components: Other components that platform users can introduce at any time

Only by allowing users to enter custom components can their code reuse needs be met, bringing development efficiency back to the same level. Because for long-term iterative businesses, what's most frequently used daily must be business components, not general public components. In this case, how to enter custom components and how to support mixed use of custom components and standard components are directions worth exploring in depth.

V. Output Richness

The fifth dimension is output richness. The richer the output product forms of the platform, the stronger the low-code capability.

Output products can be divided into 3 categories:

• Final products: Function modules, pages, applications

• Intermediate products: Business components, blocks, templates

• Primary products: UI components

Final products have the highest completion degree but lowest reusability. Primary products are the opposite. Multiple forms of output products mean powerful reusability and flexible integration methods, for example:

• Low-code development and source code development used together, allowing smooth transition

• Secondary development based on semi-finished products from low-code platform output, reducing part of the workload

That is, capability completeness determines target application scenarios, while output richness determines the actual application scenarios of the low-code platform.

VI. Link Coverage

The sixth dimension is link coverage, indicating the coverage degree of the complete production chain. The higher the coverage, the stronger the low-code capability.

Complete production chain generally includes requirements-design-development-testing-release-operations. The more complete the low-code platform's coverage of the production chain, the smoother the collaboration process and the more obvious the efficiency improvement. In different business environments, specific production chains may vary, but all need to clearly define the link coverage scope of the low-code platform, continuously optimize links within the coverage scope, while minimizing collaboration costs with links outside the scope.

Specifically, there are 2 ways to improve link coverage:

• Incorporation: Bring links outside the scope in. For example, on the basis of supporting development, provide testing, release process management, and corresponding one-click deployment capabilities. Provide as complete support as possible for necessary processes, avoiding exposing the joints between low-code platform and upstream/downstream of production chain to users for manual filling.

• Connection: Connect with links outside the scope. For example, a low-code platform with very limited expressiveness may need to be used with source code development mode. At this point, can consider linking with code repositories in source code development, uploading products to code repository with one click, or conversely embedding low-code capabilities into IDE to assist source code development.

To cover the full production chain doesn't necessarily mean incorporating all links into the low-code development platform. Just need to connect data links and link with existing tools and platforms, for example:

          Raw Material Protocol
Material Assets ----------> Low Code Platform
           Output Protocol
Low Code Platform ----------> Release Platform/Code Repository
             Intermediate Product Protocol
UED Design Tool --------------> Low Code Platform
            API Description Protocol
API Management Platform ------------> Low Code Platform
           Data Description Protocol
Low Code Platform -------------> Data Mock Platform

VII. Collaboration Efficiency

The seventh dimension is collaboration efficiency, referring to the collaborative work efficiency of different roles in low-code mode. The higher the collaboration efficiency, the stronger the low-code capability.

Different from source code development, low-code development as a new R&D mode has great room for imagination in terms of collaboration efficiency, for example:

• Product managers: Can produce high-fidelity prototypes through low-code platform, handed over to R&D personnel for further development, even able to quickly adjust copy, image materials, etc. by themselves.

• UED: Design tools connect to low-code platform, no need for manual annotation, effect inspection.

Design2Code (design to code) is another approach to solve collaboration efficiency problems between UED and R&D personnel. In comparison, the core advantage of low-code platforms lies in lowering professional requirements, enabling non-technical personnel like product managers, UED, etc. to have the ability to adjust independently, even complete part of requirements independently.

VIII. Intelligence Degree

The eighth dimension is intelligence degree. The more intelligent, the stronger the low-code capability.

First, how to define intelligence?

Simply defined as the ability to help or even replace manual decision-making. That is, the program can automatically make (what I also think are correct) decisions, then it's intelligent. For example, modern IDEs can comprehensively calculate the most likely several alternatives as completion hints based on massive code library word frequency features, current input context, user coding habits, etc. Most likely it's what I want to input, so it's called intelligent hint.

Configurational (data-driven) low-code development is the necessary path to intelligent development, because the foundation of intelligence is data. Patterns derived from big data set analysis are important basis for program decision-making. Source code development, due to its flexibility, cannot provide detailed effective input. Low-code platforms limit the flexibility of manual coding, providing a configurational program expression method. The generated configuration data can serve as input for recommendation algorithms,进而 helping manual decision-making:

• Automatically recommend/select content, such as layout templates, component styles (font size, color), image materials, etc.

• Automatically recommend/select copy, such as keywords, sentence patterns, styles, etc.

• Even automatically generate大量 UI combinations, equally distributed for verification effects, automatically select the best based on effect feedback.

Letting part of production links move from manual decision-making to automated data-driven decision-making, low-code platforms play an irreplaceable role in such intelligent processes.

At this point, the 8-dimension low-code capability model has been established, as shown below:

[caption id="attachment_2311" align="alignnone" width="500"] low code model[/caption]