Hello everyone, today we are going to share the business architecture, but we are not talking about what a business architecture is and how to do it from the perspective of a product manager? Instead, from the perspective of a technical architect, it describes how to undertake the business architecture or how to judge the business change trend and respond to the system architecture in advance when there is no business architecture.
1. Background
The R&D person has a technical architecture, and the product manager has a business architecture (usually one person). When a technical architect does not understand the business architecture, the following dialogue will appear.
Xiao Wang, technical engineer: "The product manager changed the demand again. He told me yesterday that the order should be split according to the inventory status. I just went online and today he told me to split the order according to the type of promotion"
Architect Xiao Sun: "The business has been developing rapidly. He told me that day that he wanted to split it according to the volume of the product, but I blocked it."
Xiao Wang, a technical engineer: "Excellent, you still have the right to speak."
I believe that everyone often encounters similar problems, but if the technical architect understands the business architecture, it will become the following dialogue scene.
Technical engineer Xiao Wang: "The product manager changed the demand again. Yesterday he told me that the order should be split according to the inventory status. I just went online and today he told me to split according to the type of promotion. Fortunately, you told me about this rule last time. It’s changeable, let me split the logic of different orders into atomization, I can change the configuration and get it done, worthy of being an architect, how do you know this changeable piece? Do you know divination?”
Architect Xiao Sun: "Haha, predicting the future is originally the responsibility of an architect."
Technical engineer Xiao Wang: "Teach me quickly."
Next, let's learn how to enable technical architects to have the ability to predict future business development.
Two, the solution
Technical architects need to understand the knowledge of business architecture, but they don't need to know as much as product managers, such as value chain and other concepts. What he needs to know is how to identify the trend of business development and change, and structure and expand the technical architecture of the corresponding part. Today I will introduce a simple method - the MIT knowledge model. Simply put, it is 1: mapping (Mapping) 2 identification (identify) 3 inquiry (ask about)
Mapping (Mapping) : All requirements can be mapped to the following systematic and structured language, in which scenario (event) the computer program starts to act, which data (entities) the program needs to read, and in what order (activities), who (organization/role) executes the rules (tasks), and what data (entities) will be generated after execution. But for a specific scenario, the order (activities), rules (tasks) and who (organization/role) are easier to change.
Identify (identify) & ask (ask about **) : So when we communicate requirements with product managers, the most important thing is to identify the sequence and rules** (organization/role is usually configurable in the RBAC model of the permission system, and there is no need to consider). How to quickly identify the order and rules?
1. Sequence: multiple business activities in a scene, usually displayed in the business flow chart of a product manager, such as the product introduction function, which needs to go through multiple steps such as "insight", "selection", "investment", "legal affairs" and so on. Business process node. After finding this order, you can judge whether it is changeable by mainly asking the product two questions, "Is this order different for different customers/channels/categories or different channels?" "Is this order due to short-term online pressure? Simplified." Usually product managers will get this information when doing research. If the product manager is not sure, you can ask the product manager to have this information under investigation. When processing the system architecture, there are various ways to deal with scalability. You can create multiple microservices, or use process engine tools to implement scalability.
2. Rules: Usually (IF A then B) mode, it is usually under each sequential node, for example, when the product introduces "insight" business activities, if the following words are found: "If the product is a major appliance, Need to consider the competitive price factor", "If the product is a slow-moving type, you don't need to participate in insight" and so on. If you find such terms, you can basically judge that they are rules; of course, there are still some rules that are hidden and need us to dig out, for example, in the case ** "Orders are split according to inventory status. I just went online and today I told me to split according to promotion type. "分", **There is actually no obvious (IF A then B) pattern here, but usually verbs with adjectives may change (such as splitting according to inventory status). But if you dig or think carefully, you can see that the two split logics must be conditional or sequential, otherwise the split of the same order will be messed up. If at this time, we are asking two questions about the product, "1. Is this rule valid under specific conditions, such as different customers/channels/categories or channels, time periods, and priority order". "2. For this rule, there may be other rules for different customers/channels/categories and other ends or channels." Similarly, if the product manager is not sure, you can ask the product manager to have this information under investigation. When processing the system architecture, you can handle scalability in various ways. The simplest code can be used as a strategy model, or use configuration files. , rule engine dools, etc. to achieve scalability.
3. Case Analysis
Through the above simple model, we restore the demand scenario that the architect Xiaosun communicated with the product manager for the customer.
Product Manager Xiao Li: "This time we are going to do business and order fulfillment. This is my PRD, let's take a look today..."
Architect Xiao Sun: "The PRD is very detailed. Through my PRD, we understand the function of the order fulfillment. You can see if I am correct in saying this: the order fulfillment function needs to read the order data. Split and mark the sequence, generate multiple split orders, and transmit them to the logistics system. Usually these tasks are automatically processed by the system without human intervention. Right?
Product Manager Xiao Li: "Yes, the big logic is like this"
Architect Xiao Sun: "The order of splitting and marking here is different for different customers/channels/categories or different channels. Is the compromise just a simplification due to short-term online pressure?"
Product Manager Xiao Li: I researched 4 customers, 3 order channels, and competing products through these steps. There is currently no possibility of looking at new nodes.
Architect Xiao Sun: "Okay, then I will consider the cost. I will design the process nodes as fixed first, and then you will notify me in time if you find any changing scenarios here. In addition, I see that you mentioned that the order is in accordance with the order in the splitting process. Inventory status splitting, here are all orders split according to inventory status?"
Product Manager Xiao Li: "Um, I think so"
Architect Xiao Sun: "I suggest you investigate whether there are different logics under different customers/channels/categories and other terminals or channels", usually actions with adjectives may change.
-- after a while
Product Manager Xiao Li: "Yes, customer A said that in addition to inventory, they also have shipping costs, gift cards, and product volume split logic, which will be carried out in order."
Architect Xiao Sun: "OK. I designed this piece for scalability"
4. Summary statement
Look, it is actually quite simple for an architect to have business predictability or business sensitivity. Just find the right position and ask more questions, which can reduce a lot of workload for front-line R&D. This ability can also be called business sensitivity in many places. Therefore, the system scalability design must be inseparable from business input, but how to quickly find the place where the business changes through a few simple questions is solved by the MIT model I shared this time. You can also analyze the changing points of business according to this MIT knowledge model according to a business scenario.
Source: JD Cloud Developer Community
Author: Li Chunli of JD Retail (please do not reprint without authorization)