In the last article (how to build fresh B2B technology system from 0 to 1), we talked about how to quickly build technical system in fresh B2B business to support the needs of the start-up stage of the company. This article will continue to expand, to talk about the volatility and uncertainty of fresh B2B business How song Soon-chae technology reacted to the ambiguity, complexity and complexity. Some business scenarios we learn from the industry’s mature solutions, but more business scenarios are no reference can be used for reference, we can only use the lightest way to try – summary – optimization, this process precipitated song Xiaodai technology for fresh B2B in-depth understanding of the solution. Song side technology development process is sometimes seen, following instead because a sudden change in the business, we will be caught off guard, there’s no way to support business needs quickly, then back business bottleneck “charges”, this article will also record the us on technical errors, and will be back in again perspective to analyze the problem, and reasonable solution is given. Therefore, this article will share the successful experience and summarize the failure lessons.

1. Song Xiaocai’s business expansion brings technical challenges

If a startup’s initial business model works and is proven to be replicable, the next stage is rapid business expansion. Starting from June 2015, Song Xiaocai set out from Wuhan and planned to open 3 new cities (Hangzhou, Beijing and Shanghai) in China at the same time. At this time we are faced with several problems:

  • The technical team needs to be completely independent from the outsourcing development team, which has been unable to quickly respond to business needs.
  • As we mentioned in the previous article, the ERP system design did not take horizontal expansion into consideration. When the business volume was quadrupled, the single system architecture of THE ERP system at that time could not support the four-fold increase in traffic volume.
  • The warehouse model and commodity model in ERP system cannot support multi-city expansion.
  • Erp system integrates the function of data report, and data report is real-time query online database, sales students will frequently query data report to check their performance every day in single peak rush, because of the large amount of data, oom problems often affect the order of small B customers. The above problems will seriously affect business expansion. If we do not solve them before the business is launched, we will not be able to ask B to place orders in the new city. It only takes a month to solve these problems. Due to time constraints, complicated matters and great impact on online business, we have planned a new system architecture from the future direction of business, as shown in the figure below:

Figure 1. System architectureCopy the code

This system map basically determined the technical direction of Song Xiaocai for the next two years and supported the business development of Song Xiaocai for more than two years. According to this system map, we did two things:

  • System structure specification
    • Modular transformation. At the beginning, we did not do servitization upgrade, but modularized various business domains by jar package dependence.
    • System split, according to the acquisition and distribution business domain to build independent system support.
  • Core model abstract refactoring
    • The warehouse model supports multi-city logistics scheduling, with one set of warehouses in one city.
    • The product model supports upstream link collective purchase and downstream channel customized shelf sales.

2. Lack of unified architecture idea, system construction into chaos

This upgrade of system architecture has temporarily solved the problem of song Xiaocai’s sales expansion in 2015 to 2016, but the core problem has not been seen or solved. As can be seen from the system architecture in Figure 1, the technical team began to divide system modules according to business domains, and began to abstract and sink core service capabilities (order center, commodity center, inventory center, and user center). Frankly speaking, these designs refer to the system system of Taobao.com and apply to Song Xiaocai’s business. So how do you divide business domains? What are the core system capabilities? At the time of design and implementation, there was no set of architectural guidance. In 2016, when the business requirements were concurrent, the technical project team did not have a unified architecture specification and split modules according to their own understanding of the business. As a result, the business system was split too carefully, the system level was too deep, and there were too many modules. One CRM system needed to rely on dozens of business modules, as shown in the figure below:

  • The cost of new construction project increases, and the depth and breadth of familiar business increases.
  • Depending on module code changes, packaging tests need to re-pull the code, increasing the overall maintenance cost of the system.
  • Each module is maintained by different students. If you want to adjust the function and release system, you need to coordinate and communicate with students from multiple different modules. From 2015 to 2017, the size of the technical team was not large (only 30 people), the core development students of the team were basically stable, and automatic operation and maintenance tools existed, so the above problems did not bring much impact. However, it is not recommended to break down the system modules to make the leap into microservices architecture.

3. Understand the nature of requirements to design a system that meets business needs

Because we did not understand the nature of the business, the model designed at that time was unstable. Once the business form and business operation method changed, the online model needed to be reconstructed. Over the next two years, we rebuilt the product model three times, and by the end of 2016 we realized what had gone wrong —- did not understand the nature of the business requirements. Many students in the design of system, the first focuses on the system access performance, stability, security and other technical details, then consider using some new frame and new technologies to help decoupling between modules and meet future system extensibility, according to the needs of the business in the needed information dimension to design table, meet the needs of data storage. This process of system design ignores the nature of business requirements. Why do people have such inertial thinking, because in the Internet high-speed development period, technical circles about the most is all sorts of general high concurrency, extensible elastic problems and solutions, once the skillful use of these solutions, run into any system requirements, with the existing solutions to design the system, it is similar to a skilled workers use a hammer, You get caught in the cognitive trap of trying to hammer a nail into everything you see. So I want to talk to you about what the right system design process is. All business requirements are actually want to use the product function to solve business problems in the specific scene, and we are at the time of design system, without having to understand the nature of the problem is to use existing solutions to solve the problem, a big probability screen using a set of perfect system design scheme, but not solve the problem of user after implementation. Even if the system design scheme is complete without defects and does not solve user problems, it is also a set of failed system design scheme, which does the opposite thing. Therefore, the first step in the system design process is to understand the business requirements and find the fundamental problem behind the business requirements to solve. And then you think, isn’t that what product managers do? It is ok for us to design the system according to the product plan of the product manager. Why should we, as architects or developers, understand the nature of requirements? I thought so before I built a business system from zero to one. After song side three years of system design and development, especially through the above-mentioned three years three refactoring commodity, I realized that the system designer must with product managers to think about business needs, to understand the nature of the demand, help the product manager to optimize product solutions, help the product manager why say so? Because architects and developers are most familiar with business systems, architects and developers are stronger than product managers in systematic thinking and abstract thinking, and in the product process (product design + product development), systematic thinking and abstract thinking are needed to help the design of product solutions. When the product manager receives the demand from the business side, it will be difficult to abstract and systematize the demand from the specific demand because of the long time in the business scene. The product solution without abstraction and systematic design may simply translate the business demand without really solving the user problem. There is a typical example is given to show the problem, at the beginning of the 20th century in the United States, due to the fast speed of economic development, people are increasingly demanding for traffic speed, at that time, the American people’s main transport is the carriage, their demand is how to let my horse run faster, many businessmen see the chance, try very hard to study how to make the horse run faster, improve water chestnut, let the horse eat more . Henry Ford alone invented the automobile for the masses and popularized it as a means of land transportation all over the world, because he understood the nature of the American people’s need, not for a faster horse, but for a faster destination. Abstract and systematic means to express and think with models. Therefore, from the end of 2015, we began to look for modeling methods suitable for Song Xiaocai business. By chance, WE saw the introduction of DDD(Domain Driven Design) and the problems to be solved on the Internet. After systematically learning DDD, we tried it several times on a small scale, failed due to a lack of understanding and the team’s ability to abstract the business to implement DDD, and then decided to abandon the DDD practice. But starting in 2017, we found that many Internet companies to try and implement (especially some senior architects in the alibaba tech circles continuously promote DDD) in hangzhou, and then in April 2017, ali, a senior architect ray volume was invited to song dishes to share technology and brought new about DDD implementation experience and advice, we began to continue on Implement and try in system design process. In the process of continuous implementation, we found that ddD-based architecture ideas can help us sort out the system and plan a set of architecture that meets the business needs. Even in the case of the rapid change of fresh B2B business, it can still ensure that the overall architecture is clear and the business system can quickly respond to the needs. The following figure shows the business system architecture planned using DDD.

Figure 3. Ddd-based business system architecture In figure 3, we according to company current business was divided into three big business domains (business domain of supply chain and logistics business, buyers business domains), and then abstracts from the three business domain core business elements, these elements of the business layer formed the system capability of six service center (commodity center, the user center, trading center, the repair order center, logistics center, warehouse Heart). During song Xiaocai’s 3 years of business development, the business model and operation method have been changing, but the business direction and core business elements have not changed:

  • people
  • car
  • cargo
  • The warehouse
  • trading
  • Synergy these core business elements correspond to the service center of the capability layer
  • People -> User center
  • Goods -> Merchandise center
  • Trading -> Trading center
  • Car -> logistics center
  • Warehouse -> Storage center
  • Synergy -> Work order center Contrast figure 1 and figure 3 system architecture, we can be found by understanding the business nature of the song side dishes, precipitated the song side own core service ability, in the process of business development in the future, as long as the song started business direction remains the same, we can through the bottom sediment core services ability to quickly build out the upper different business domains of the different approaches of business system. This architectural approach abstracts the business, reduces repetitive business element building and development, and can quickly respond to new business requirements and old business iteration requirements. The figure below shows the industry’s summary of the development efficiency of building systems using DDD versus other building systems.

4.Be good at using external capabilities to make up for your technical shortcomings

In the system architecture diagram in Figure 1, we can see that we use a lot of open source technical frameworks and also a lot of aliyun paid solutions. This is the second point to be thrown out of the article. Be good at using external capabilities to make up for your technical shortcomings. In today’s Internet environment, more and more small companies can in a short span of 2 to 3 years to grow into a unicorn, such ability is need enough technology to support business development speed, and these companies generally use the open source solutions and similar ali cloud to provide business solutions to help companies in the short term technical ability to corner overtaking. Ps: The following article will supplement how Song Xiaocai makes use of external capabilities to promote fresh B2B business.

5. Suggestions for quick response to fresh B2B business changes

  • In the fresh B2B business, understanding the nature of business requirements enables quick delivery of products that meet business requirements, and DDD’s approach helps architects and development students sort out and understand complex and changing business requirements.
  • In fresh B2B company development process, the technical team must be good at using external ability to quickly improve their technological capabilities, will he not good at and not part company core competence to the third party to run, to focus on the core capability, and modeling ability is the core competence of the technical team.

About how to set up efficient raw B2B platform, because of the large contents, also is very complex, unable to give you an article, this article is just beginning, the following will be divided into several articles from industry present situation, the situation of business and product overview, technical team building, the server-side technology platform, the front-end development, such as multiple dimensions to tell, We will be more than three years in the B2B field of the precipitation of core products and technology platform to open, hope that more people in the industry can have a deeper understanding, less detdetments, hope to help you, the distribution of this series of articles is as follows (will continue to update) :

1, “How to build an efficient FRESH B2B platform (B2B technology sharing the first article)”

2, “Song Xiaocai how to enter the fresh B2B market (B2B Technology sharing second)”

3, “fresh B2B platform product system iteration (B2B technology sharing third chapter)”

4, “fresh B2B how to build an efficient technical team (B2B technology sharing fourth chapter)”

5, “how to build fresh B2B technology system from 0 to 1 (B2B technology sharing fifth chapter)”

6, song Xiaocai technology how to deal with the rapid change of fresh B2B business (B2B technology sharing sixth chapter)

7, “fresh B2B technology platform front-end team how to build (B2B technology sharing seventh)”

8, Song Xiaocai about “Ability” design and Thinking (B2B Technology Sharing chapter 8)

9. Design and Thinking of Service Separation (B2B Technology Sharing chapter 9)