An APP contains various functional elements according to the different services it provides. Product architecture is to classify and integrate these functional elements for different purposes around specific goals.
1. Why do we need product architecture
When we open an APP, the first thing that catches our eyes is an exquisite page, some rich information, navigation, and some vivid banners to guide us to do some interesting things. These things are an integral part of the APP and some necessary functional elements of the APP. They serve as display, guidance, and inducement functions respectively. An APP contains various functional elements according to the different services it provides. Product architecture is to classify and integrate these functional elements for different purposes around specific goals.
If we stack some functional elements that apps need to provide, regardless of priority, users don’t know where to start, what will happen after clicking the button, it’s hard for users to find what they want, and they don’t know what to do. To get the desired result, the user is at a loss and can only give up leaving with a deep sense of frustration. Through the structure, the product allows users to smoothly complete the tasks they want to perform according to their expectations, achieve the desired results, and leave with peace of mind. Architecture is necessary for the product.
2. Product structure analysis
Everything is composed of some elements. For a thing with a clear boundary, its constituent elements are always traversable (some system constituent elements have too much data and are difficult to traverse. This is technical limitation and cannot be said to be traversable. .). Similarly, all the constituent elements of things are always related to different degrees. These elements and the relationship between the elements together form the overall form of things that are displayed in front of us. The product architecture we want to analyze now is the relationship between various functional elements and elements of the product. The relationship between these functional elements and each other forms a system model of a product. Users try to understand a product through the system model, and continuously form a cognitive model of the product. The difficulty for users to establish a cognitive model through the system model determines the user’s recognition and acceptance of the product.
1) Functional elements
The functional element mentioned here is a complete function with the smallest granularity that the user can complete a small round of operation. For example, a page that displays a list of hotels that can be booked, a function element that can trigger an event to return a result after a click, and a function of password modification. Rather than the buttons, labels, and text boxes of the components of the product interface. The functional elements here carry certain operations and their result attributes.
In a good architecture, the user completes a unique job through a functional element, not half a job, nor multiple jobs. This design will not make users confused about the operation and the results obtained.
Examples of bad architecture design:
This is a function of a product I have refactored. The problem that the function wants to solve is to open a financial account for the user, and the user can use the money in the financial account to pay for some of the company’s financial payment types such as the receipt fee, the delivery fee, the order fee, and the store reward fee. If the user wants to use the financial account to pay for the order, it can only be used to pay for the order of some specific channels.
To summarize briefly, this financial account has two attributes: payment type and order channel
Before I refactored, this function was designed like this: the order channel is used as an attribute of the order payment type. If the user wants to add different order channels to the financial account, he needs to add multiple payment types with different order channels to the financial account instead.
In this example, a functional element is integrated into two task goals, and every time the user completes an operation, it is a part of the task that has been completed. He has to complete a complete task many times.
2) The relationship between functional elements
In the example of the bad architecture design in 1), it seems that colleagues have also explained the problem of the relationship between the functional elements very well. The order channel is understood as the attribute of the payment type, but there is actually no necessary connection between the two. In the product architecture, functional elements are organized according to their mutual relationships .
The relationship between different functional elements in a product is divided into direct relationship and indirect relationship. Only the directly related functional elements will be organized together, and those elements that are not directly related will have indirect relationships at different levels through other direct relationships. The relationship between a good architecture entity and the entity is clear. Sometimes for performance, data integrity, system stability, or specific user scenarios, similar functional elements are appropriately redundant, but they are all within a necessary and reasonable range, and the premise is that there is no ambiguity or ambiguity. A far-fetched situation.
What is composed of functional elements that cannot form any relationship cannot be called a system. Some functions are designed to have no relationship with each other, and such components are more common in platform-based products. In order to avoid technical problems such as scattered brand influence, troublesome installation, or other reasons, they are organized as several components in a unified platform-based product to provide different services for different user groups coming to the platform. For example, in order to expand the target user group, enhance their competitiveness, or increase user viscosity, some companies will open up services in different fields or different experiences in the same field, as more options are juxtaposed to provide users with more choices.
3) System function level
The mission of a product is to provide a specific service for a specific user group, and all the functions of the product serve this unified goal. No matter how many functional elements a product has, it can only be summarized into a complete and simple highest-level functional element in the end. For example, the only function that a shopping product needs to provide is: find what you want to buy -> place an order -> receive goods. There will be many other functions to assist the completion of a certain part of the highest-level functions. These auxiliary functions are the lower-level functions; some complex lower-level functions will also have lower-level functions to assist users in completing it. . In a well-structured product. Different functional elements form a simple, clear and consistent system of structure, operation, and experience at the appropriate level of their appropriate links.
This is a very complicated part. So far I hope my expression is clear, and I hope you can still see it clearly.
PS: Recommended reading: “Pyramid Principle”
Through a deep and clear understanding of who the product is to solve and what problems, we can understand what kind of results we want to achieve with the complete functions of the highest level of the product. By understanding how the target user solves his problems when he does not have our products, we can initially know how we can solve the problem, and then think about whether there is a better solution, and find the best solution from the imaginable solution. Conveniently, this is the complete process at the highest level of the product. Decompose and analyze each step in the process, and recurse to the indivisible functional elements, and you will get the architecture scheme of the entire product.
4) Company business
Peter Drucker, a master of management, said that the purpose of an enterprise in society is to provide customers with products or services.
Then the purpose of a specific enterprise in society is to provide specific products or services to specific target customers. Does it feel consistent with “the mission of a product is to provide specific services to specific user groups”?
Yes, even completely the same. The difference is that it has reached a higher level. What is to be organized here is not the functional elements of a system, but different systems are to be organized here. I understand this as a business architecture. . Just as the product architecture is about understanding who is to solve what problems, the business architecture needs to understand the company’s target customers and how we provide them with what kind of products and services.
Why not one system but multiple systems?
Only a collection of functional elements that have a direct or indirect relationship with each other can be called a system. Within an enterprise:
- Externally, there is no direct or indirect relationship between services that independently provide different functions for different target user groups, and different systems need to be formed.
- Internally, different administrative organizations are independently responsible for relatively independent business within the company, and there is no direct or indirect business relationship between businesses, and different systems need to be formed.
What problems does the business architecture need to solve that the product architecture will not encounter?
- Different business systems are very large functional elements, and the relationship between them may need to be managed as a system. The most common is the order system, which connects the customer and the supply chain. This requires product managers not only to have a deep thinking and understanding of the business as a whole, but also to have stronger abstraction capabilities.
What capabilities do product managers need to reserve before making business planning?
- It is necessary to have a certain technical ability to assist in a clear understanding of how information is exchanged, stored, coupled and decoupled between different systems.
- There must be a certain business philosophy, such as saving costs, increasing revenue, and improving efficiency.
- Business integration requires a deep understanding of the business itself, and a deep understanding of the company’s different businesses requires more capabilities, such as sales, finance, customer service, and business operations.
- It requires a stronger abstraction ability than product design. It is not only to abstract a job into a function, but to abstract a business into a system; not to clarify the relationship between tasks and tasks, task results and other tasks, but to clarify the relationship between business and business.
- Need to have a strong insight into business models and strategic planning. Only in this way can the company better support the growth of the business during the rapid growth of the company, and respond in time when the company’s strategy or business model is adjusted, so that the information platform will not become the bottleneck of the company’s development.
What are the characteristics of a good business architecture?
- The various subsystems of a good business architecture cooperate with each other to form an integrated platform. The subsystems are independent of each other with minimal duplication, and each supports different business segments, and jointly supports the company’s business to provide customers with good products and pre-sales , Sale and after-sales service.
- A good architecture can well and conveniently support the horizontal expansion of the business. Poor architecture is relatively poor in supporting the horizontal expansion of the business, or even does not have the ability to support the horizontal expansion of the business. New businesses can only be completely re-developed, which is a huge waste of labor and time costs.
- The data of each system of a good business architecture is continuous, complete, and complete in the business as a whole. Through combination extraction and analysis, it can well drive business operations and provide data support for enterprise development planning and strategic decision-making.
- With a good business architecture, the system can provide more than just business functions, as well as data that drives the business of each module and the business of each partner to make better decisions all the time and everywhere.
- A good business architecture provides a docking platform for external development and provides a docking method for other platform partners at all times to ensure that companies do not have to miss any good opportunities.
