One, foreword
When working on enterprise services (ToB) products, we often encounter the following scenarios:
Each customer comes to us with a list of their needs and asks if our products meet their needs. As shown in the figure:
Each customer needs overlapping content, also have different content, and these needs, in a certain field have strong universality.
How do you meet these customer requirements while still depositing each requirement as a standard feature, not just for project delivery? This becomes the question that ToB product managers think about most.
In order to support customer demands, the basic approach is to abstract various requirements, implement standard functions, and assemble each function into a product. However, after a period of time, people will find that more and more functions, products become bigger and bigger, but the user experience is worse and worse, product development and maintenance is more and more difficult. How to not only meet customer demands, but also solve these problems? Modular design is one direction. After we expand the introduction, the number stack in the modular design of some experience for reference.
Ii. Introduction to modular design
(1) Purpose
- From the perspective of business sales, product modules can be freely combined quotation, fit the needs of different customers, improve product sales into a single rate.
- From the point of view of product research and development, reduce the phenomenon of repeated wheel manufacturing, improve the efficiency of research and development and product expansion.
(2) The implementation of modular design in the data stack platform is mainly divided into the following three ways from large to small:
- Son of the transition
- Public module
- Component/plug-in development
1) Demand background: Every customer, even the same customer, has different understanding of data center at different stages.
- For example, customer A is A medium-sized enterprise and hopes to have A product to help him build an offline data warehouse to meet basic data development demands. Then the offline development module of the data stack can meet their demands.
- For example, customer B is a large group enterprise, and wants to build the group data center from data development, data service, data governance and other aspects. Then, it needs to output a set of data stacks to satisfy the customer.
2) Design ideas:
- Product – According to the business logic, each module is decoupled independently, positioning and upgrading into sub-products, responsible for solving the demands of different business scenarios.
- Business – sales can be individually quoted output, but also a combination of quoted output.
3) Implementation results: As a data center product, Data Stack includes sub-products such as offline development, real-time development, algorithm development, data services, data assets, data quality, and smart labels. Each sub-product can solve the demands of different business scenarios and supports independent and combined deployment.
- Increased the user’s use cost. For example, the same user, the same data source needs to be maintained multiple times within each sub-product, and it is easy to cause ambiguity.
- Increased product research and development costs. The same function needs to be repeated, which wastes r&d resources and operation and maintenance costs.
2) Design ideas:
- Remove the common functions of each sub-product as a common module, maintain and manage it in a unified manner, and then provide services for each sub-product.
- The design of the public module needs to fully investigate the demands of each sub-product. For the general appeal, abstract the standard function; To expand the appeal, provide configuration function; For individual appeal, by the sub-products to achieve.
3) Landing results:
3. Component/plug-in development
1) Requirement background: If the modular design of the first two parts is a test of product manager’s ability, this part is more a requirement for developers.
The following three problem scenarios are introduced in our daily work: a. During product design, an input box needs to be added. The requirements are as follows: It is mandatory, the content format is limited to Chinese and English, and the length is limited to 255 characters.
The requirements were simple, but at each review, the product manager had to explain to the r&d how to prompt when it was empty, how to prompt when the content did not meet the format requirements, and how to deal with when the length exceeded the limit. The communication cost was huge, and this was less than 1% of the total prototype design content.
B. During product design, it is necessary to reuse the form in another module, and all form items maintained in the form and their association logic are the same. However, after research and development, it was found that the original form processing logic and business processing logic were strongly coupled, so the form code could not be reused and needed to be independently developed again.
C. In the process of product iteration, it is found that there is a kind of requirement, which is updated relatively frequently. The requirement logic has certain commonness, and the update will not involve the change of existing functions. Such requirements for development, similar to common modules for products, can be abstracted as a common technical capability to provide services externally. For example, we often encounter requirements such as adding support for a data source, adding a task type to the engine, etc.
2) Solutions:
- The front-end precipitates a library of standard components. For some common designs, component reuse is used to reduce the workload of development and production. We currently have 30+ front-end components and are iterating continuously.
- Low coupling design of code. This part of the requirements are vague and have no very clear boundaries, rely on development experience and understanding of the business, and require continuous growth.
- Plug-in design. Distinguishes the application layer code from the underlying code. The plug-in encapsulation of the underlying code can support different applications in the upper layer and support rapid iteration without affecting existing functions. In this way, the development of the application layer can invest more energy to support services. At present, it has landed: data source plug-in, data synchronization plug-in, Engine plug-in, blood parsing plug-in.
Third, summary thinking
Modular design is a solution, not an end in itself, so you can’t design a product for its own sake. Especially in the early stage of the product, at this time, the product is not rich in functions, and in order to seize the market quickly and iteratively, it is not suitable to invest more energy in this matter. But once the product reaches stable growth, both product managers and r&d students should start thinking about modular design in their daily work.
Modular design is not a product to change the name, do an independent page is modular, how to divide the business level, how to cooperate between modules, where is the boundary of plug-in stripping, how to decouple the code logic and so on, these are the places that need to think about.
Stack is a cloud native – site-based data central-platform PaaS, and we have an interesting open source project on Github and Gitee: FlinkX is a batch data synchronization tool based on Flink. It can collect static data and real-time data. It is a data synchronization engine with all-domain, heterogeneous and batch integration. If you like, please give us a star! Star! Star!
Github open Source project: github.com/DTStack/fli…
Gitee Open Source project: gitee.com/dtstack_dev…