I. Introduction
Today, I re-read Chapter 4 of "The Way of Enterprise IT Architecture Transformation-Alibaba Zhongtai Strategic Thought and Architecture Practice"-Building a shared service system. The shared service center described in the book actually contains two levels.
-
First, the underlying PaaS capability, which is used to solve the requirements of the architecture of the overall system group in the enterprise in terms of distribution, availability, high availability, and real-time monitoring;
-
Second, general business capabilities, my understanding is actually building SaaS, the purpose is to sink and share the core capabilities of enterprises, and accelerate the speed of enterprise innovation.
Here I also want to talk about the second one: the construction of general business capabilities to talk about an understanding of it.
2. Construction history of shared service center
Taobao initially had only four shared service centers: user center, commodity center, trading center, and store center; the selection and positioning of each center can give us some inspiration.
User Center
: Why choose User Center? The main consideration is that 1) the complexity of the business is lower than that of commodity/trading centers, and the risk of transformation is relatively low; 2) the user-related information is called most frequently, and the cost reduction after service is easier to test (because no business logic is involved does not involve new business functions);
Commodity Center
: Taobao is a platform-based e-commerce company, and commodity management is one of Taobao's core capabilities, so it should be shared most;
Transaction center
: The transaction center initially included functions such as shopping cart, transaction process, order management, settlement, and marketing; however, with the continuous development of the business, inventory and marketing were separated into an inventory center and a marketing center. Such a process reflects the dynamic evolution of service centers.
Store Center
: The store was originally responsible for the seller’s store management and other business functions. Later, with the improvement of the store system and the expansion of the business scope, it developed into the most dynamic third-party store decoration market on Taobao. This is the best platform practice.
From the above, we can vaguely summarize some things:
1. These centers are individuals full of vitality; with the development of enterprise business, an original functional module will grow and become a new service center independently, and the center itself may derive new functions; I call it Evolutionary Service Center;2. Before doing business in the middle stage, enterprises must first sort out what their core capabilities are;3. In the process of building China-Taiwanization, try to use core capabilities with relatively low complexity and obvious effects to separate functions and integrate them into shared service centers;4. The ability provided by the center to the channel should not be limited to the form. My understanding is that it can be provided in the form of API or WEB interface. Of course, it can also provide data capabilities or some general tools. Slowly, these centers can be provided to the platform. direction of evolution.
3. Principles of service center division
The division of shared service centers not only considers the technical dimension, but also needs to consider the business operation dimension. Don't forget what is our original intention to do this? Everything is for the purpose of quickly responding to business and promoting business innovation. I try to describe the 4 principles in the book that I understand through my poor language.
1. The principle of high cohesion and low coupling
It should be said that this is not only a service division, but also a basic principle that our usual system design must follow. In the context of the service center, it means that the business isolation between services is relatively large. When you make an order, try to only include order functions (such as simple additions, deletions, checks, etc.), and do not include user information functions; but Some functions with a certain degree of business relevance require specific analysis of specific issues. Let’s take that specific example. Among the teams the author is in charge of, one of the teams is responsible for the construction of the e-commerce mall. Billing, customer rights, etc., everything was fine. However, the business planning also wants to further work on customer rights and interests. After continuing to make several rights and interests related requirements on the original e-commerce mall, we found that there are many problems (such as resource coordination, system boundaries, etc.), and finally decided to change the rights and interests system Use the microservice framework for independent development.
From the perspective of the whole process, some people may say why not design an equity system or equity center at the beginning. But I still say the same thing, in this VUCA era where customer needs are changing rapidly, and the product cannot clearly explain what to do in the next 3 months, we 1) cannot measure whether we need to independently build an equity system, 2) ) Is there a transitional design at this stage? After all, we have ROI considerations. If the business direction is adjusted after two months, wouldn’t it be a waste of development resources? However, is there nothing that can be done in advance? Of course not. Based on past experience, we can at least do the following at the engineering level:
1. For the scope of functional requirements in the first phase, if it basically does not need to use some existing business data tables, and the functional scope is evaluated based on experience, in addition to the traditional adding, deleting, checking and modifying, there are some aggregation layer functions, generally it will be Consider creating a new standalone service (in jar form);
2. Otherwise, develop on the microservice with the highest degree of correlation between existing business functions, but try to be independent in the package dimension, so that if you need to develop independently in the later stage, you can quickly and directly extract it together with the tool class to become a microservice. Serve;
3. At the database level, it is generally preferred to use a separate table in the same library to support new business functions; why not use a separate library or a separate schema? Mainly considering the management of multiple data sources, the database management module in the project becomes more complicated, because we do not want to introduce unnecessary complexity to the data source management module due to uncertain services, especially when cross-database transactions are involved. It is more complicated. Be as simple as possible. Didn't Einstein say that "simplicity is the great goal pursued by science"?
From the whole process of the above example, if you take a closer look, you have actually been following the basic principle of "high cohesion and low coupling".
Therefore, if we want to ensure the advanced nature of the system architecture (service division), or how we can guard the architecture to ensure that the system or organization does not become corrupted when the entropy increases, the key is to add "evolution capability" to the system. One of the basic principles to be followed for "evolution capability" is "high cohesion and low coupling".
2. The principle of progressive construction
This principle is more from the implementation level. Still in the context of the VUCA era, customer needs and operational needs are changing at any time. There must be an overall top-level design, because it is more of a guiding nature, and it is beyond doubt to draw a clear circle at the macro level. However, when building a specific service center, what we need more is the strategy and ability to quickly adjust, so it is more recommended to run in small steps (especially for those systems or projects that do not need to be reinvented) , Don't do it all at once.
In addition, as I said just now, the system architecture is alive. First, it grows exogenously with business development, and synchronization also grows endogenously due to the continuous upgrading of technology. I have always believed that service-oriented architecture is an art of pursuing balance. It is not only a balance in design principles, but also a trade-off in terms of technology, cost, resources, construction period, performance, etc., in order to come up with a solution that best meets the conditions at the time. better solution. Based on such a premise, our plan is definitely not perfect, and what we can only do is infinitely close to perfection. The subtext is that each shared service center actually needs incremental construction, even after the construction of version 1.0, continuous iterative optimization is required. (Because people themselves are not perfect, the things we design must also be imperfect, but this is a philosophical category that will not be discussed here, haha.)
3. The principle of data integrity
This basic principle should echo the first principle above, or it can be understood as the embodiment of "high cohesion and low coupling" at the data model design level. But what I want to emphasize here is that the so-called data integrity is broad. Here we can borrow the aggregation and aggregation root in domain modeling to explain.
What is aggregation? Aggregation is actually a combination of a group of related objects, which has specific aggregation roots, entities, and aggregation context boundaries. Among them, the boundary defines the entities or sub-entities that should exist in an aggregation.
What is an aggregate root? In DDD, the aggregate root acts as a unique bridge for the internal entities of the aggregate to communicate with other external aggregates (cross-aggregate reference).
What is an entity? Entity is each concrete object.
From the figure below, in the entire customer aggregation, the customer is the only aggregate root (you can understand it as a primary key of a database table), and other external aggregations can access all other entities in the customer aggregation through it (you can understand it as a database different tables in , but with the same primary key). The entire aggregation embodies the principle of data integrity, because
1. When I want to clean up the data of a certain customer, the aggregation has told me what customer data to clean up;
2. When I want to analyze the portrait of a certain customer, the specific model is ready to come out;
Data integrity means using a unified data model. Only in this way can we use a unified data model and corresponding algorithms to perform corresponding statistical analysis on the generated overall data, so that the corresponding results can be obtained most efficiently and for the sake of The later targeted operation strategy provides a more valuable reference.
4. Principles of business operability
My understanding here is that if we build a shared service center, we should also take business operations into consideration, that is, with certain business logic. Because only such a service center, the business can 1) continuously accumulate business data in the process of using this service center, 2) naturally breed innovative ideas due to different business needs during use, as mentioned in the book In the use of the commodity center, commodity inspection technology was born because of the massive commodity SKU and SPU. It can be seen from this that the center can continue to evolve and evolve only if it is used by users. At the same time, new technologies or services are spawned due to new operational difficulties. This is a positive cycle.
We should also follow this principle to the greatest extent during the construction of shared services, because the commonly used keys are always on.