This article is my keynote speech in Hangzhou station of the Product Manager conference held by Everyone is Product Manager in July. Based on the outline of the speech, I rewrote the article, aiming to discuss and interpret the product construction problems in Zhongtai from a new perspective, so that you can have a deeper understanding of the essence of Zhongtai design.
The full text is about 11,000 words and takes 30 minutes to read.
Photo taken at hangzhou Product Manager Conference in July 2019
00
preface
Zhongtai construction, is a very hot topic in the past two years, from product zhongtai, to technical zhongtai, and then to the organization zhongtai, a variety of concepts, ideas, and methodology have been deeply studied and discussed.
For the field of Internet products, zhongtai is more a subject involved in 2B product construction, because the abstract reuse of software system is more a problem faced in the construction of complex B-end system. Therefore, mid-stage product design is a topic that all b-end product managers should pay close attention to.
In the field of b-end product design, how to design products in Taiwan? What are the characteristics? What is the nature of design? What are the challenges? This article will review zhongtai product construction from a new perspective, so that you have a deeper understanding of zhongtai product design essentials.
01
The construction of Central Taiwan from the perspective of classics
First of all, it is necessary to review the classic perspective of Zhongtai construction. Generally speaking, the industry often from the organization of Taiwan, product Taiwan, data Taiwan, technology Taiwan these four themes and discuss the construction of Taiwan.
Organizations China: China is the study of the enterprise internal organization structure design, how to reasonable power and responsibility division, as well as the management structure, improve the management ability of business units, rapid response to market changes, and be able to make enterprises to enhance general interagency collaboration across business line efficiency, reduce operating costs, realize standardized management. In fact, the so-called design idea of organization center has existed for many years. In group enterprises, the organizational form of division system is often adopted, which is combined with the construction of various shared service centers to realize the separation of front and back businesses, with the front business maintaining mobility and the back business providing fire support. Similar to Financial Shared Service Center (FSSC), Human Rersources Shared Service Center (HRSSC), In fact, it is the typical organization form and functional department construction method under the central Taiwan management idea, as shown in the figure below.
A common divisional organization diagram
Products China: China is the study of the software system within the enterprise is how to abstract and design, so that the enterprise software system flexible, like building blocks, can be repeated and efficient use of ready-made software components, the rapid assembly to develop new software system, thus saving the cost of software development, and to support new business in very fast. Many articles also refer to such mid-platform products as business mid-platform, or business mid-platform products. At present, the widely discussed product center includes e-commerce transaction center, account center center, etc., among which the e-commerce transaction line is more widely discussed, including order center, payment center, commodity center, promotion center, etc. There is another meaning of product Center, that is, management software products that can provide consistent services for the whole company and the whole enterprise can also be included in the category of product Center, such as call center and project management software. To some extent, these standardized software products are also Taiwan products.
Data Center: Data Center studies the internal data management and governance of enterprises, as well as the construction of data product system and data underlying structure. The research scope of data Center includes unified data security, data specification, metadata management, data coding management, and topological architecture of data warehouse and data mart, as well as the construction and reuse of big data bottom layer and computing capability. It should be noted that the Data Center is more concerned with the governance, management and application of data from the business and product levels, rather than technical issues.
Technical Center: Technical Center studies which technical processing capabilities and architectures can be abstracted and reused in the technical implementation process of software products, such as messaging middleware MQ, distributed computing framework Hadoop, distributed service framework HSF, various Open APIS and so on. The technology platform is to think about the reuse ability of basic services and basic modules purely from the bottom of the technology implementation, and its design ideas are consistent with the product platform, which is a problem that technical personnel need to think deeply.
The above four topics cover all the topics for the construction of enterprise middle platform under the Internet mode. Among them, for product managers, the work is the most relevant, and the most need to pay attention to the product middle platform and data middle platform.
In fact, the above four themes are the segmentation of Enterprise Architecture (EA) theory, which is very core in the construction of traditional Enterprise informatization, from the IT perspective of Enterprise business management. The organization center corresponds to the organizational structure governance part of Enterprise Business Architecture (EBA) studied in EA. The product center corresponds to the Enterprise Application Architecture (EAA) of EA, and the Data center corresponds to the Enterprise Data Architecture (EDA) of EA. The technical center corresponds to the Enterprise Technology Artchitecture (ETA) in EA, which studies Enterprise Technology architecture.
The discussion on EA may make many students with pure Internet background confused, but in fact, the so-called middle-stage construction idea of Internet enterprises cannot escape from the theoretical framework of information technology and management after decades of precipitation. The traditional information technology theory has a strong reference value in the construction of B-end products of Internet enterprises.
However, the topic of our discussion today is not to study the guidance of enterprise architecture EA on the middle platform construction, but to try to explore the design essence of product middle platform and data middle platform from a deeper perspective, especially the design essence of product middle platform which is very core for B end product manager.
At present, the recognized key points include the following keywords: enterprise-level, abstract, sinking, reuse, these keywords represent the characteristics of the construction of the product platform, but also in the design of enterprise application architecture need to be deeply considered. (enterprise application architecture, refers to the enterprise internal each software system, should be in the form of what construction, combination, so as to efficiently support the enterprise the management operation), therefore, if you want to deep thinking about the enterprise abstract, sinking, reuse of software products, can undertake new look from the following three angles, respectively is: Based on the perspective of abstract reuse, based on the perspective of architecture rationality, based on the perspective of business unified management.
From these three perspectives, we can comprehensively deconstruct the essence of zhongtai product design, and we can comprehensively describe the methodology, key points and difficulties of Zhongtai construction.
02
Construction of middle platform based on the perspective of abstract reuse
1. Purpose of construction
Abstract reuse refers to the abstraction and submergence of repeated functions and modules in software.
What is abstract? What is sinking? Let’s give an example.
As shown in the figure below, there are two systems I and II, among which system I has module M and system II has module N. After analysis, it is found that the functions of modules M and N are highly similar and repetitive, which can be combined abstractly to avoid repeated construction.
Identify common modules
It is decided to separate modules M and N from system I and II respectively, as shown below.
Remove common modules
After separating M and N, we abstract and merge their functions, as shown in the figure below. After M and N are combined, module A + B + C is obtained, where A is the common function of M and N, and B and C are some customized functions provided for system I and II respectively. Although A few functions cannot be fully combined and reused, the vast majority of function sets A in the new module have been highly abstracted and can be reused by system I and II. The new modules A+B+C, which will be stripped and merged, will sink down one layer as basic services to support systems I and II. The diagram below.
Merging common modules
The above case demonstrates how the system functions are merged, abstracted and sunk. This design idea saves the cost of software research and development and is a very classic mid-stage design idea.
Next, we further demonstrate this design idea through a practical case.
2. Case: Unified customer view construction
Case background
For a traffic-oriented Internet company, the realization mode IS mainly advertising Sales for small and medium-sized enterprises. The business team includes telephone Sales team (IS, Inbound Sales), field offline Sales team (OS, Outbound Sales), and customer service team. The three business teams have their own independent business systems to support their operation. Each business system has personalized functions, such as outbound call management for IS, visit management for OS, and care return visit for customer service. There are also repetitive functions with highly similar functions, such as customer management lists, customer details pages. The system architecture is shown in the figure below.
Duplicate customer detail page construction
Problems encountered
The three business systems are maintained by product RESEARCH and development teams respectively. In the early stage, the systems were built to quickly support the business and respond to business demands quickly, making great contributions to business development. But with the gradual maturity of the system, some of the problems are also gradually prominent, the first problem is the repetitive development and construction of functions. Although the three business departments have different priorities for customers, they have the same basic demands, hoping to see all the important information of customers. Therefore, the functions of the customer details page of the three systems are highly similar, and every adjustment and change of customer information needs to be repeated three times by the three R&D teams, which is a waste of human resources.
The solution
In order to solve the three sets of business system in highly similar customer details page repeated development problems, and also for business people to provide a consistent and accurate view of customers, the company decided to customer details page module stripping from the three business system, the function after the merger, the construction of “unified customer view (ECIF)” module, the module has a consistent customer data, And provide a complete customer information query service interface, and can be embedded into the business system directly used by the customer details page components. “Unified Customer View” will be used as a mid-Taiwan product to provide services and views of enterprise customer data query for each business system. The diagram below.
Build a unified customer view center by abstracting the customer details page
Any business system, can call the module mature interface to query the customer data and design of front page, also can be directly embedded into the “unified customer view” provide ready-made customer details page of the component, and the page components can be flexible access configuration, defined for different business systems, different scope of data to view, edit, user role.
As a result, we completed the abstraction of the customer details page, and the three sets of pages that had been repeatedly developed were merged into one set, so that the r&d team could maintain only one set of pages, freeing up the r&d manpower.
This is a typical mid-stage product designed from an abstract reuse perspective. A significant feature of this model is that software abstraction and reuse is a cost issue and does not affect the business. In this case, although three sets of customer details pages were repeatedly constructed, it was only a waste of resources and would not affect the development of business.
3. Challenges
Abstract reuse of software function modules is a very challenging task. Wrong abstractions can be made if the analysis is not done properly or if the experience is not enough.
We always want to be able to make the right abstract decisions about software and functionality, so that the abstracted systems and modules have highly overlapping features, as shown in the figure below.
Desired abstract results
However, limited by inadequate experience, or lack of information, is likely to make wrong judgment and design, made the wrong decision, abstract from the abstract system module, and cannot be fully reuse, just made a strange strange module, blunt put a bunch of unrelated functions forcibly knead together, brings to the research and development work instead of more trouble, the following figure.
Wrong abstract result
We will demonstrate this design error through practical cases.
4. Case: Construction of order center
Case background
An Internet company simultaneously develops the business of electricity business and movie ticket business. Each line of business has an independent C-end system and background trading system (including commodity management, order management and promotion management) to support business. In order to follow the trend, the company decided to merge the order centers of the two business lines to realize the order center, as shown below.
Not necessarily correct order in Taiwan
Bad decision making
In fact, the company management of B2C electronic commercial business and shade ticket business, have a great difference on the trade form, particularly on the design of the orders module, the order of the state machine, data model, and financial accounting treatment mode is completely different, forced the two merged, and not a lot of common modules and functions, finally only seemingly China implements the order, However, the functional modules inside are independent and run independently, without abstraction and reuse.
Extension problem
Now, company managers think they have a strong “order center” that can support the rapid launch of any new business. Soon, the company decided to carry out air ticket sales business, for the air ticket business, independent C-terminal, commodity management, promotion management. However, when product managers and engineers began to look forward to the powerful capability of ORDER Center, it was a pity to find that Order Center could not provide any ready-made function reuse capability for air ticket business. The order model of air ticket is different from that of e-commerce and video ticket.
The designers of the airline ticket business line are faced with an embarrassing situation. They either “politically correct” integrate the airline ticket order center into the unified construction of the order center, but in fact, this will seriously reduce the development efficiency, because the RESEARCH and development team in Taiwan will certainly not attach as much importance to the development of new business as their own research and development team in the airline ticket business. Or you could ditch the order center and develop the order module yourself, but that would make it look like the order Center isn’t delivering the value it should. If you’re in charge of airfare, what are the trade-offs? The system architecture is shown below.
Order center does not support ticket business very well
It can be seen that the order center, under different business modes, is not necessarily suitable for the construction of Taiwan. Designers should have enough critical thinking ability to judge whether the product form is worth abstraction and whether it can provide reuse capability. However, this is also a very difficult part of software engineering design.
The design of any software system is based on inductive method rather than deductive method, that is, software designers always complete software design by summarizing and refining the existing world and business, but cannot complete software design by inference and deduction. Designers cannot predict the future of the business. They can only ensure the flexibility and correctness of the design based on their limited experience. It’s important to understand this, and it will help you design your software and your products in awe, and not in pursuit of serious over-design that can’t be proven in the short term.
5. Suggestions in practice
The following are some suggestions for constructing the middle platform based on the perspective of abstract reuse.
- Modules that clearly have commonalities are abstracted early
- Modular post-abstraction of uncertain universals
- Avoid outsourcing human resources to the center
03
Build the middle Platform from the perspective of structural rationality
1. Purpose of construction
Software application architecture design is not a combination of arbitrary systems and modules, but a profound design methodology and rationality. In order to meet the requirements of application architecture rationality, software often needs to be abstracted and sunk one layer.
2. Case: Construction of customer master data
Case background
Problems encountered
- Online customers need to re-register if they want to experience offline services, and the customer experience is very poor
- Offline customers need to re-register their accounts if they want to experience online services, resulting in poor customer experience
- Online and offline customer data is repeated and uniqueness cannot be identified
- The customer data presented to the customer service staff is synchronized with lag
- Customer service can not accurately identify customer information and help customers to modify information
- Enterprises are unable to do correlation analysis of online and offline customer consumption and cross-sell
The solution
This pattern is characterized by software abstraction and architectural design that affect business
3. Challenges
Ideally architecting may actually slow down the business
4. Case: Construction of account center
background
Problems encountered
5. Suggestions in practice
The core goal of architecture design is to support business development, and sometimes it can allow unreasonable architecture to exist.
04
Based on the perspective of business unified management to build the center
1. Purpose of construction
Through the sinking and abstraction of software, centralized management and control of business can be realized
2. Case: Unified customer sales control of multiple business lines of the Group
Case background
Business demands
- The three companies often have the phenomenon of repeated procurement flow, which wastes the marketing cost of the group;
- The three companies often repeat marketing to the same customer, resulting in customer complaints;
- Customer value can not be fully tapped, cross-selling and up-selling across business lines is not good;
The solution
- Establish the group’s unified customer identification database (built as the core module of the Group’s unified customer management center), identify customer uniqueness from the group level, ensure that existing customers can be correctly filtered when purchasing traffic of each business line, and save costs.
- With unique customer identification capability, unified customer marketing management, customer journey management and anti-harassment control can be achieved at the group level. Customer journey through a unified customer management center, harassment prevention control module, insert the control strategy to each subsidiary sales system, to ensure that each subsidiary sales contact of task before must first after calibration and control of the control center of group level, to ensure that the same customer won’t be several lines of business at the same time sales repeated harassment.
- The unified customer management center can also realize the cross-selling module, which can distribute cross-business sales tasks according to customer data in some business scenarios. For example, when identifying a life insurance customer with good economic strength, the customer will be pushed to the sales system of financial services to try the secondary sales transformation.
The demands of centralized business management must be realized through software abstraction and architecture design, which is also the characteristics of this construction mode
3. Challenges
The need for centralized business management is always lagging, which brings challenges to the design and implementation of systems and midstage
4. Suggestions in practice
- Don’t think too much about what may or may not happen in the future
- Drive system iterative abstraction through business value and business demands
- Senior management must step in to ensure progress
05
Summary of zhongtai construction mode from three perspectives
