Business Architecture Design Patterns

background introduction

We are a CRO business technical team for merchants, and we have been doing business environment governance business for 4 years. As a vertical business technology group (different from the platform technology team), we also face the torture of most business technology teams: what is the difference between business technology and platform technology? How does business technology do it? How to understand business? How to do a good job in technology in the short-term and fast business rhythm? Some questions have answers; some are still looking for better answers. This article is a summary of the past four years: a basic thinking framework is extracted from two perspectives of business and technology for reference by students developing business lines.

Business perspective: Business-driven technology is a feature of the front-end business. Business development must gradually develop the ability to look at the business from a global perspective : understand the business model from the perspective of delivery value; grasp the product direction from the perspective of capacity planning. The first part of this article introduces the practice of value-led business architecture
Technical perspective: The content of application architecture is very large. The second part of this article introduces two methods (styles) of architecture design, as well as two architectural concerns of domain division and process modeling

business structure

Business Architecture Purpose

The scope of business architecture is relatively large. What this article wants to talk about by borrowing the word "business architecture" is: how business development should pay attention to & analyze business problems ; how to understand business and guide system design

What does business architecture do

The most important thing about business architecture is to " look at the overall situation " (everyone has a different position/angle/height, and has a different understanding of the "global situation"). The emphasis here is: the awareness of looking out , not how to look at it . Look at the overall situation from three points of view:

Look at " things " clearly: From a macro perspective, "things" are the source of value, business strategy & goal & value; from a micro perspective, "things" are business processes. If you see the "things" clearly, you can understand the two core issues of " why " and " how ". Take our business as an example: the macro "work" is to help merchants deal with risk issues at low cost, reduce business operating costs, and improve platform competitiveness ; the micro "work" includes merchant risk warning process, risk feedback process, etc. In the stage of viewing , try to separate from the specific system/business , and expand the horizon to height and breadth . Take risk early warning as an example: From the perspective of breadth, how are risks identified (what upstreams are there), how to reveal them (what content is needed), and how to reach merchants; from a height perspective, how many risks can be early warning (common What is it), how does the merchant deal with it (how much is the cost, etc.), and whether there is a better way to deal with it.
Clarify " people " : who ( stakeholders ) do this "thing" together. Classify and manage stakeholders, identify different demands of users, and sort priorities. The key point is what the user wants (user perspective, not external perspective).
Clearly distinguish " responsibility " : the rights & responsibilities of different "persons" , and their roles in the process . From the perspective of product construction, the identification of people, rights, and responsibilities is to deeply understand user demands and design product capabilities. For example, merchant products need to consider the rights & responsibilities of employees in different roles of the merchant, as well as the product functions required by different roles.

How to do business architecture

See things clearly - value stream/capability mapping

Value Stream: A value stream is a complete process of end-to-end value delivery described from the perspective of stakeholders (customers, end users, or recipients of products, services, or deliverables resulting from work).

Business Capabilities: A business capability is a specific capability or capacity that a business may possess or exchange to achieve a specific purpose or result

Capability/Value Stream Mapping: The process of mapping business capabilities to each stage in the value stream to highlight which capabilities are of greater or lesser importance to business operations

Analyzing the value stream helps to understand the entire business process from a more macro perspective : the value delivery process is broken down into several stages, which are completed collaboratively by different roles; each stage requires different capabilities. By analyzing the status quo of capabilities (complete, missing, partially satisfied), evaluating value & urgency, ideas for future planning can be formed. The figure below is an example diagram of Togaf’s recruiting employee value stream, which describes the complete process of recruiting employees and product capability requirements, and distinguishes the status of different capabilities through colors (green represents satisfaction of demands; yellow represents partial satisfaction; red represents lack of capabilities).

Clarify People & Responsibilities - Role Analysis

Use UML use case diagrams to describe "people" and responsibilities in the business. There are 3 roles in the business business, and the responsibilities of each role are shown in the figure below

With a global overview of people & responsibilities, needs, problems, or opportunities for resolution can be identified by analyzing the working patterns of specific scenarios. The change here is: not only focus on the current individual requirements, but look at the business demands from a global perspective , so as to have a more reasonable judgment on the rationality and importance of the requirements; provide business perspective considerations for the design plan. For example, the example in the figure below describes the working mode of employee recruitment. (It can be seen from this that there is a lot of room for improvement in the entry stage)

application architecture

Architecture: The structure of components , their interrelationships , and principles and guidelines for their design and evolution over time.

The main things that architecture does are: identify components, define relationships, and determine principles. Components are related to design perspectives , and the form/granularity of components under different perspectives:

DDD: Subdomains are components, relationships between domains, domain design principles
Process perspective: processes, sub-processes, and stages are all components; define the interaction relationship and principles of components at different granularities
Data perspective: data tables are components, relationships between tables, and design principles (paradigm and anti-paradigm)
Architecture layering: layers are components, relationships and principles of layered interactions
....

This article will introduce two general design methods (top-down, bottom-up), as well as knowledge of domain modeling and process modeling.

architectural approach

top down

Top-down design refers to the process of referring to standard solutions and tailoring/fitting specific solutions . Many business domains already have standard models or solutions (such as financial domain, e-commerce, supply chain, etc.), and it is a good choice for these business domains to adopt a top-down approach . Designers with rich experience/wide knowledge are suitable for adopting this method; of course, if designers are inexperienced, they can also take the initiative to conduct research and practice. In most businesses, the top-down method is not used much and will not be expanded in detail.

bottom up

Top-down design refers to the process of starting from specific business details, analyzing and summarizing, and finally obtaining a solution . Bottom-up is a method we often use in our daily business. This article focuses on how to do bottom-up design.

Bottom-up "Three Broadswords"

We have summarized the "three axes" of bottom-up design from practice, as a framework to guide the design process:

The first trick: Bottom-up induction

Analyze the problem space and reduce complexity through inductive classification. Divided into two processes: scene sorting and scene classification

Scene sorting: list all the details of the problem. For example: process modeling first lists all sub-processes; domain modeling first lists all concepts in the domain
Scene Classification: Divide types and merge similar items. Identifying the classification is to refine the information of the problem space. Some classifications are easy; some classifications require an iterative process:

- First select the main division dimension based on experience or intuition , and identify the type
- Classify the scene into the corresponding category
- When encountering scenes that are difficult to generalize, evaluate whether the classification needs to be adjusted

The second trick: abstract analysis out of the design

The so-called solution is the solution in the solution space, and the design process is the transition from the problem space to the solution space. This is the difficult point in the process , and also the most difficult point. The design results depend on the goals (sometimes domain models; sometimes process frameworks, etc.), and the methods used also need to be combined with the problem.

The third measure: test the scene from top to bottom

The design proposal should be placed in the design scene for " deduction ". The deduction process is very important: it is necessary to deduce known scenarios to evaluate whether existing needs are met; it is also necessary to deduce future scenarios with high probability to evaluate future adaptability.

Architecture practice

domain modeling

This article does not go into details about the specific methods of domain modeling, but only discusses the issue of " subdomain division ". Although there are many articles introducing the method of sub-domain identification, it is still relatively difficult to grasp the division of domains. If you see 5+ subdomains in a business application, don’t be surprised if there are only a few objects or methods in some subdomains. These subdomains are likely to be the product of imitating the textbook method; Get it in your head (common situation), many domains are divided "by feeling" (for example, many applications have "configuration domains").

Look at an example: Can the domain model in the figure below find a clear subdomain boundary? In the model, find out the few connecting lines and draw the dividing line. The fewer connecting lines on both sides, the clearer the boundary. It is difficult to find a clear and suitable boundary in the picture below, but the design scheme is divided into 4 sub-domains, and such domain division is worth deliberating. (PS: Looking at pictures and talking is an intuitive and easy-to-use method in domain division)

domain purpose

Back to the original intention of domain division: the purpose of domain division . Domain division and maintenance are costly (the cost is not low), and the benefit must be considered after paying the cost. What is the purpose of domain division (that is, the benefit)? I think there are two most important points:

Controlling complexity : In life, large complex problems are usually divided into several small problems that are easy to solve. DDD's strategic tool "subdomain" is a tool to control complexity : the core domain, general domain, and support domain are specific ways to divide the whole into parts and reduce complexity.
Improve reusability : The concept of "general domain" in the DDD subdomain type clearly indicates the reusability of domains.

The design principle of domain division, my point of view is: do not divide if it is not necessary; do not divide if there is no benefit; do not divide if you are uncertain . Domain division must have benefits: either complexity reduction; or reusability improvement; or both. If there is no benefit or too little benefit, don't subdomain. There are two " bad smells " of wrong domain division in practice :

The domain is very shallow: the domain division is very fine, and there are a few objects in each domain. Usually, the problem is not complicated and does not need to be divided.
Fuzzy domain boundaries: Domain object relationships are complex, and there is no clear boundary between subdomains, implying wrong model relationships or wrong division of subdomains.

domain identification

Although there are many ways to help identify subdomains, the most important thing is to rely on practice and iterative design from both positive and negative directions:

Positive direction: identify possible domains based on various characteristics/methods (domain division includes: starting from domain definition/referring to existing standard schemes/identifying domain conceptual ambiguity/four-color modeling/event storm, etc.);
Opposite direction: verify the rationality of division through domain design principles and benefits ;

domain verification

The " autonomous unit " summarized by Starlink is the most complete domain design principle, which is more practical.

Domain autonomy is consistent with the design principle of high cohesion and low coupling. The core judgment points are:

Minimal completeness & self-fulfillment look at " dependence " : the value proposition of the domain determines the domain responsibility, the domain contains the necessary information needed to complete the responsibility and can make independent decisions, and does not/less rely on external domains. For example: In the design of business systems, we often see the design of the operation domain and the configuration domain; any function performed by the operation domain depends on the configuration domain information. Then from the perspective of domain completeness and self-fulfillment, this split is inappropriate.
Stable space & independent evolution Look at " change " : Stable space means that the current domain is not/less affected by changes in external domains; independent evolution means that changes within a domain have no/less impact on external domains. For example, if subdomain A directly references domain object C of subdomain B, changes in object C must affect subdomain A; this situation indicates that domain A is not stable enough; or that domain B cannot maintain independent evolution.

process modeling

process design issues

Take the DDD four-layer model as an example: the domain layer model design has gradually received attention; but the application layer design has not received enough attention. Generally speaking, the responsibility of the application layer is to organize business processes for use cases . In the actual code implementation, a lot of confusion in the application layer can be found to increase the code complexity. Typical problems include: different stages of granularity; unclear node responsibilities; and confusing interactions. The root cause of these problems is that the business logic is organized around the "data center", and the process is not carefully designed and organized.

What does process modeling do

The "process modeling" here specifically refers to the organization of business logic processing . There are three things in process modeling: set stages, set responsibilities, and set interactions .

fixed stage

The concept of " stage " here is similar to that of " process node/processing node ". Determining a stage is to design the program processing steps in a business scenario , including business and technical considerations. The stage is designed to convey the point of view: According to the design purpose (performance/flexibility/clear structure, etc.), the granularity/sequence of the stage is optional. Note: The stage division granularity of the same type of process remains the same . The same type is understood as similar scenarios, for example, message processing scenarios, then the stage granularity of the processing flow of different types of messages (creation/end/revocation, etc.) remains consistent.

Responsibilities

Define the terms of reference for each phase . In design (regardless of coarse-grained design such as domain identification/application layering or fine-grained design such as class/method), the definition of responsibilities is very important: clear responsibilities essentially define boundaries . In this way, the realization position of each function is well designed, which reduces arbitrariness and is conducive to the clarity of the overall architecture, so as not to rot into a big mud ball.

fixed interaction

Inter-process & intra-process call relationship. Please see the execution process of the example in the figure below (this is restored from the real code): node A calls the extension point, and after the extension point is executed, it calls node B. Think about it first, is this reasonable?

Dialogue with higher-level organizations in daily life, communication between upper and lower organizations within the organization, and communication at the same level between organizations; few low-level employees directly talk to leaders of external organizations. This is our life experience, and the principles of process interaction design are similar. Nodes are responsible for organizing the execution logic in this stage, and notify the next node after completion. This kind of node interaction principle is summarized as: up-down dialogue within a stage, and horizontal dialogue between stages.

How to do process modeling

Bottom-up process modeling is simplified into three steps: exhaustive -> induction -> deduction, and each step can be improved through several iterations.

Exhaustive: Choose a proficient tool to sort out the process (flowchart, ES, etc. can be used), the suggestion is: sort out by business scenario type, one or several scenarios can be sorted out at a time, and completed in multiple times.
Summary: " Look through " the scene, find the commonality, find the difference, find the design points , and use the three skills of " combining, adding, and adjusting " (merging similar nodes; adding missing nodes; adjusting the order of nodes) to complete the process design. How to "adjust the order" depends on the design purpose, for example, the performance is prioritized and some business check nodes are adjusted to the front.
Deduction: Use the process designed in step 2 to deduce the business, and mainly evaluate the execution sequence and node responsibilities to meet business needs.

Example exercises

Bottom-Up Process Modeling

Use the bottom-up method to model the employee onboarding tracking process: first, HR enters the personal information and materials of the employees to be hired, and after confirming that they are correct, assigns office space to the employees; then the system prepares assets and opens accounts & permissions for employees; employees receive Assets, after logging into the account, the onboarding process is complete

The first step is bottom-up induction

From the value flow heat map above, we know that the company's onboarding tracking process needs to be built urgently: onboarding tracking and employee information management capabilities are lacking; asset management & facility management & safety management have basic capabilities, but need to be improved. This time, the event storm method was used to sort out the onboarding tracking process together with business, product and R&D, with the purpose of building onboarding tracking capabilities.

The second step is to abstract and analyze the design

Employee onboarding tracking receives events from information management systems, asset management systems, and safety management systems, and updates onboarding progress. The designed process model is shown in the figure below. Added technical nodes: message parsing, verification, and protocol adaptation; in order to maintain the clarity of the process, the node for judging whether the "first inflow" is performed before the protocol adaptation is advanced.

The third step is to test the scene from top to bottom

Deduction is to express the business execution process in terms of processes; scenario deduction technology is especially suitable for the verification of complex businesses, and can find missing points in the design stage. The figure below deduces the processing flow of the event that the employee has reported to work.

Summarize

This article provides a business architecture design pattern for your reference. The whole framework hopes to express two key points: 1. First of all, we must think from a business perspective, break through the business architecture thinking that only focuses on the realization of requirements, but start from business value; 2. Emphasize the logic of design: top-down or top-down Both emphasize the design process , and each design decision needs to be deduced.

The above is a business architecture design mode provided in this article: a basic thinking framework is extracted from the two perspectives of business and technology, for reference by business line development students.