1, the definition of product architecture diagram
The product architecture diagram is a visual graphic designed by dividing the business architecture, functional architecture, information architecture, technical architecture, ecological architecture and business model of a specific product into layers and combining modules. Its abstract and concise expression is very suitable for introducing complex product systems. Common product architecture diagrams include business architecture diagram, functional architecture diagram, information architecture diagram and mixed architecture diagram.
There is a saying that the more complex the thinking, the simpler the form. Many great knowledge and laws in human history are expressed in concise and elegant forms, such as Aristotle's syllogism, Newton's three laws, Euler's God formula and Darwin's theory of evolution. After enough thorough thinking, complex architecture and logical relations can be expressed in a simple form. On the contrary, many seemingly simple forms of expression bear great complexity behind them.
Compare with various product outputs (documents, prototype drawings, flow charts, etc.). ), the product architecture diagram is the simplest form, which is composed of a single rectangular control, but it has the highest degree of abstraction and complexity in all product outputs. The output of product architecture diagram is a measure and embodiment of product manager's product design ability.
2. Why do you want to draw a product architecture diagram?
When designing a product, the first thing to output is the product functional architecture diagram. The process of thinking about how to draw this picture is to help you sort out product design ideas and determine product boundaries. For example, if you are asked to design a CRM system now, you can try to draw the functional architecture diagram of the CRM system for specific business first. In the process of drawing, it will help you to think about which core functional modules the whole CRM system consists of, what is the relationship between the modules, and what to do at each stage, thus forming a complete product design idea.
Secondly, the process of product design is like that of Gai Lou, and the output of product functional architecture diagram is like the process of laying foundation. The process of product prototype design is like that of Gai Lou. There is no problem with the foundation, and there will be no big problem with adding bricks and tiles later. If we don't pay attention to the quality of foundation from the beginning, we will find that the whole project has problems in the middle of construction, and the maintenance and reconstruction will waste huge resources and costs. Therefore, the product functional architecture diagram is a very important deliverable in the early stage of the project. When you want to start designing a complete product scheme, if you skip the step of drawing the product architecture diagram and start drawing the prototype and writing the PRD document directly, it is easy to change it again, or even make a version of the requirements and then overturn it.
Finally, after the product is launched, it needs a highly abstract, concise and easy-to-understand carrier to introduce the overall situation of the product, and it is impossible to describe it with complicated pages and words. At this time, the product architecture diagram will be a good communication medium to introduce the concept, function and design of the whole product.
3. How to draw the product architecture diagram
What is the product architecture diagram and why it should be drawn is introduced above. Next, how to draw the product architecture diagram is introduced. The drawing method of product architecture diagram is mainly divided into four steps, namely: (1) determining the object; (2) Dismantle the structure; (3) mining relationships; (4) Expression output.
Figure 5- 1 Drawing Method of Product Architecture Diagram
(1) Determine the object
First of all, it is necessary to clarify the scope and boundaries of the objects described in the product architecture diagram. For example, a CRM system needs to draw a business architecture diagram, a functional architecture diagram, an information architecture diagram, or a mixed architecture diagram that combines various elements.
(2) Structural disassembly
After determining the type of the description object, it is necessary to disassemble it. For example, the business structure of the lending platform Tu Tu can be divided into pre-lending business, in-lending business and post-lending business. For example, if you output a functional architecture diagram of the CRM system, you can disassemble the functional modules of the whole CRM system, such as account management module, customer management module, user management module, authority management module, system setup module and so on.
(3) Relationship mining
After decomposing the architecture of the output object, it is necessary to explore the relationship between modules. Similarly, taking the functional architecture diagram of CRM system as an example, when disassembling the functional modules of the whole system, the relationship between functional modules should be analyzed next. There are four main relationships among the internal elements of product architecture diagram: statistical juxtaposition, father-son inclusion, auxiliary support and bottom support.
(4) Expression output
After determining the relationship of each functional module, it is necessary to express the relationship, and the module elements at the same level need to be arranged together according to the parallel relationship at the same level.
For example, in the CRM system, the customer management module and the authority management module belong to the same level. The relationship between the authority management module and the authority distribution function module belongs to the parent-child inclusion relationship. When expressing the parent-child inclusion relationship, the parent module usually contains child modules.
Secondly, some non-core functional modules of the product or some functional modules outside the product, such as the SMS functional module of the third-party platform, have played a certain auxiliary role in the realization of the product's own functions, showing the auxiliary support relationship with other product functional modules, and the auxiliary support module is drawn on the right side of the product architecture diagram.
Finally, the underlying support relationship. For example, the membership system of a product is based on the account system, so the account system and membership system belong to the underlying supporting relationship. The expression of bottom support relationship is generally that the supporting module is below and the supported module is above. The diagrams of these basic relationships will be introduced in detail in the next section with practical cases.
After the expression of the structural relationship within the whole boundary is completed, check whether there are any omissions or errors as a whole, and match the title of the whole architecture diagram after checking. The title of the architecture diagram is often a description of the whole architecture diagram, which is usually placed at the top or left and right sides of the framework to finally output a complete product architecture diagram.
Einstein said: If you can't describe a thing clearly in the simplest language, it means that you haven't understood it. For the product architecture diagram: If you can't clearly describe a complex product structure with simple rectangular arrangement and combination, it means that you haven't really understood the product you made. Therefore, in daily product work, we should cultivate our habit of drawing product architecture diagrams, cultivate our ability of abstract thinking, and assist ourselves to complete product scheme design efficiently.
Original address: webe.com/articles/157113.html.