In this article, the author has sorted out and output the two dimensions of system application architecture and product function architecture.
The term architecture sounds like a lofty thing, and for junior and intermediate product managers, it is often the product functional architecture that is more exposed to it. Through the product functional architecture, we can jump out of a specific functional detail, and stand on a higher perspective to understand the product, design the product and plan the product. The enterprise-level application architecture requires the product manager to have strong abstraction ability and experience accumulation in order to design a reasonable architecture that can support the company's strategic development and the rapid operation of the business architecture.
1. System application architecture
1. Definition of system application architecture and common structure
Definition of system application architecture: The enterprise-level application architecture plays a role in unified planning, connecting the previous and the next, undertaking the strategic development direction and business model of the enterprise upward, and planning and guiding the positioning and function of each IT system downward. He covers the application architecture blueprint of the enterprise, architecture standards/principles, system boundaries and definitions, and the relationships between systems.
A modern enterprise architecture typically consists of the following six tiers:
- External system: The first layer is the external system. All systems used by external customers are at this layer, including the official website, C-side H5, APP, etc., used by ordinary users or customers.
- Management background: The second layer is the management background corresponding to the C-end system. Some modules will be abstracted into public services and sink to the fifth layer.
- Business Unit Support System: The third layer is the Business Unit Support System. The vast majority of business development cannot only rely on online operations to achieve, which is especially obvious in B-end enterprises, which often need offline sales (CRM system), warehousing services (warehouse management system), intelligent production (MES system) and so on to support business operations.
- Functional unit system: The fourth layer is the functional unit support system. After the enterprise develops to a certain scale, there will inevitably be a perfect functional unit as a logistics department to support the operation of the business unit and the normal operation of the enterprise, such as the legal, finance, and human resources departments, and the work of each department needs the support of the corresponding system.
- Basic service support system: After the informatization construction reaches a certain level, it is necessary for enterprises to make general functions as services and platforms to improve service efficiency and ensure the rationality of application architecture. This type of system mainly provides basic service capability support for other application systems. For example, all kinds of middle office systems.
- Data Layer and Application: Similar to Layer 5, this layer mainly focuses on the unification and encapsulation of the data layer and provides data services to various downstream systems. For example, data warehouses.
2. Apply architectural design principles
The system application architecture adopted by different stages of the enterprise (early stage, growth stage, mature stage) and different business models is definitely different. Until now, there has been no standard set of application architecture design principles, and there are only a few general rules that can be followed when designing.
Second, the product functional architecture
1. Product functional architecture definition
To put it simply, product functional architecture is a concrete expression used by product managers to express their product design mechanisms. It describes how the various functional modules, subsystems, or components of a product relate to each other and interact with each other. It abstracts the entire product into an informational, modular, and hierarchical architecture, and transmits the business process, business model and design ideas of the product through the interaction between different layers, the combination of functional modules, and the flow of data and information.
2. The role of product functional architecture
The product functional architecture mainly has two roles for yourself and the team, and you can help yourself jump out of the details of product realization and design and plan products from a higher perspective. Just like having an outline before writing an article, it can help us have a clearer design idea. The product requires the joint efforts of the whole team, so the product functional architecture is like a basic product manual, so that the team members can see it at a glance and let everyone have a clear and unified direction.
3. How to draw the functional architecture of B-end products
There should be no standard accepted methodology for how to draw a product functional architecture, and the following only represents personal practical work experience.
Classic formula: one scene painting process, two columns of pages and modules, three functions to cluster, four or five vertical and horizontal methods, a good picture is worth a thousand words.
In the B-side demand survey, the basic business scenarios, business processes, and business rules are obtained. In each business scenario, users may operate and access different interface modules, so they need to extract the common content in these scenarios and classify them.
Case background: With the continuous development of a fintech company, it is considering the systematic Saas of standardized risk control capabilities and financial capabilities to meet the supply chain finance loan needs of core enterprises in various industries and their cooperative customers.
1) Scenarios and processes are abstracted into modules
The following are some examples of core scenarios.
Before the construction of the B-end system, it is necessary to clarify what problems the product solves for different roles, the core roles and their expectations, and the corresponding core business processes. For the C-side, this step should be to list the problem domains and core functional processes.
2) Clear architecture layering
A product architecture diagram with a front-end and back-end relationship is divided into at least three layers: user perception layer (in which scenarios and how to reach users), functional module layer (through which functional modules realize the core functions of the product, and which external platform functions have information interaction), and data layer (where the product data comes from and where the product data is precipitated). In this case, there are two different roles involved in the use of the nuclear enterprise and the customer, so there will be two sets of subsystems involved. The user perception layer can be quickly built through the PC and H5 terminals.
3) Join the flow of information
In addition to expressing the core function of the product, the product architecture diagram should also reflect the path of information flow: the interaction of data at the current level forms the product function, and the product function generates new data, so as to promote the operation of the function of the next level.
4. Three abstract ideas
Why is it possible to abstract modules from scenes and processes, and how to abstract them? Here are three commonly used abstraction ideas.
1) Based on the business domain abstraction module
Business domain is a broad concept that may include business units, business units, business entities, and so on. The business domain is used as the basis for module division, so that the modules reflect stronger internal cohesion and loose coupling characteristics.
2) Abstract module based on business scenarios
The difference between the business scenario-based abstract module and the business domain-based abstract module is that the latter has stronger cohesion attributes and is more in line with the module design of the technical architecture, while the former is more based on user experience and business logic to divide modules, and may integrate the functions of multiple modules under the scene menu.
The menu design of the WMS system, the first-level menu includes transportation management, purchase management, shipment management, return management, inventory management and other modules, which are typical warehousing and distribution business scenarios.
3) Based on the business object abstraction module
The key business objects (people, things, and things are possible) in business operation are defined as modules, and the most representative is SFA CRM for sales teams.
3. Distinction between systems, modules, and functions
The enterprise-level system application architecture is designed from a higher business panoramic perspective, and a reasonable enterprise-level application architecture can quickly support enterprises to develop new business models.
The product function architecture simply aggregates a class of highly related functions from the perspective of product function aggregation, so as to facilitate function group management and help the team form a unified overall understanding of the product. Compared with the enterprise system application architecture, the product function architecture is a kind of architecture diagram that junior and intermediate product managers have more contact with. He pays more attention to the division of specific functional modules of a certain system.
This article was originally published by @B Duan Achao on Everyone is a Product Manager. Reproduction without permission is prohibited
Image from Unsplash, based on the CC0 license
The views in this article only represent the author's own, everyone is a product manager, and the platform only provides information storage space services.