In the previous lecture, I shared with you four issues that need to be considered before mid-platform building. Considering these issues can help us avoid some risks in advance when we actually start building the mid-platform.

Okay, now assuming we have already figured out these issues, how should the middle platform be implemented?

In the past two years of participating in the construction of the middle platform, I have indeed stepped on many pitfalls and taken many detours. Below, I will use the remaining articles in the second part to introduce to you the middle platform landing ideas we have explored and organized in practice, hoping to be helpful and inspiring to you.

First of all, as mentioned in the previous article, there are many types of middle platforms on the market. The construction methods of different types of middle platforms may be completely different, but there are definitely some common ideas and methods. In the following part, I will take the construction process of a Central Product Platform as a sample to introduce the practice of middle platform landing, what difficulties will be encountered, and sort out some ideas and methods.

# The Beginning Stage of a Typical Central Product Platform

In order to let you experience some of the difficulties and problems of mid-platform building, we also use the case of Geek Real Estate to simulate the startup process of a mid-platform building from 0 to 1.

After receiving the boss’s commission, Xiao Wang is ready to start the construction of Geek Real Estate’s Central Product Platform.

Xiao Wang comes from a technical and architectural background. He has led the distributed service transformation of several large systems in the company and has extensive experience in distributed architecture design and implementation. He is also familiar with domain-driven modeling and microservice technology architecture that internet companies often mention when talking about the middle platform. Of course, this is also the reason why the leader entrusted this important task to Xiao Wang.

Just do it. At the beginning, Xiao Wang was still preparing to start with sorting out business needs as usual. But the first question stumped Xiao Wang: which businesses should be sorted out?

Previously, Xiao Wang dealt with single-product level products. As long as he caught the users or business experts of this system and understood the requirements for the product, no matter how complex the product was, there was still a boundary. As for the middle platform, it often involves all the Line of Business of the enterprise. Shouldn’t all the business of the enterprise be sorted out? If so, it basically means that the resources of the entire company need to be mobilized. Why do the various Line of Business cooperate? Even if the business actively cooperates, there are still follow-up questions. What granularity does Xiao Wang want to sort out?

Faced with various problems, Xiao Wang began to feel that something was not quite right. From a technical and architectural perspective, there was no difference between doing a middle platform and doing a distributed system before, but the situation, scope, and complexity faced were completely different. For a moment, he didn’t know where to start.

At this moment, Xiao Wang always feels something is different, but he can’t pinpoint what’s wrong and falls into deep anxiety.

# What is the difference between creating a Central Product Platform and creating a distributed system?

To be honest with you, this Xiao Wang is a true portrayal of my mid-platform planning and implementation when I first started in 2017. Of course, the case is not this virtual case, but the real situation and problems encountered at that time are very similar to those in the case.

Moreover, the problems I encountered at that time were much more numerous than these. For example, even if you have sorted out all the business and planned a middle platform, how can you prove that your middle platform is right and the best? Looking back, that period of time was indeed a painful experience, with these questions lingering in my mind every day. And all the problems can ultimately be summarized into a simple question: what is the difference between making a Central Product Platform and making a distributed system?

No nonsense, let’s just give the answer directly. After a long time of thinking and reviewing, my friends and I found the key point of the problem, which is actually very simple. We have repeated it many times before, but the scope is different. If we say it more clearly, it is still the three words: enterprise-level .

Why do I repeatedly emphasize these three words? I know many people don’t feel anything when they first see these three words, but these three words are indeed extracted from countless pits we have stepped on, and contain the answers to many questions.

Looking back now, the tools, methods, and ideas we used to create a middle platform were not too problematic. We just underestimated the scope and difficulty of the middle platform and made it simpler.

Many people, whether they are mid-platform product managers or architects, are like me at that time, doing more system-level or single business-level system construction or transformation. However, when we are doing mid-platform, we are dealing with things at a higher level and scope, which have jumped out of individual products and single lines of business and involve the enterprise level.

You may ask, what difference does it make if the scope is just a bit larger? I can only say the difference is significant.

First of all, if it is an enterprise-level problem, what you need to solve is a problem at the level of achieving enterprise goals. Such problems are inherently vague and generally at the strategic level, so you cannot just start with the current business situation. You need to start with the strategic analysis of the enterprise and fully consider the impact of future architecture planning on strategy.

Secondly, if it is an enterprise-level problem, you will face organizational issues. Organizational issues are sometimes much more difficult to handle than business issues because they involve the redistribution of enterprise interests. Once you encounter organizational and interest issues, there will be various questions that I call the “why series”, such as the most common one is why should I cooperate with the middle platform? Why should I give data to the middle platform? Why should I use the middle platform? and so on.

Also, if it’s an enterprise-level problem, returning to business is completely different from doing systems in the past. You will face the overall business of the enterprise, even those potential innovative businesses that will only appear in the future and whose appearance is unknown now.

In addition, there will be countless similar difficulties that we have never faced before when developing a system or product. That’s why I included the words “enterprise-level” in my definition of the middle platform. I always remind myself that what I am doing is not on the same level as creating a system or product, but a completely different species.

Thinking clearly about the enterprise-level issue has given me a very, very big inspiration, which is that I finally figured out where the things that felt wrong before were. In fact, I have been trying to solve the problems of an enterprise-level product and architecture using a system-level product and architecture approach. Looking back now, it is not surprising to encounter those problems and difficulties.

So, the nature of the whole thing has changed. Although we may still do business sorting, microservices, domain modeling, and other similar means, we need to be clear that when we are doing the middle platform, Essentially, we are doing an enterprise-level architecture, an enterprise-level architecture that incorporates new elements of the platform, which I call: user-oriented and innovative platform-type enterprise architecture .

# Then the question arises again, what is the difference between the mid-platform and traditional EA?

After realizing that the middle platform is essentially an enterprise-level architecture issue, I am not as excited as I imagined, but rather very disappointed. Why is that?

Friends who understand Enterprise Architecture must know that this is not a new concept. Mature EA frameworks like TOGAF have a history of more than 20 years. Common things we often see, such as business architecture, application architecture, technical architecture, data architecture, and even organizational architecture, are all included in the complete system of EA.

How can I describe the feeling I had at that moment? It was like thinking I had discovered a new species, only to find that it was nothing new at all. It had been recorded in every Lingo book. The sense of loss could be imagined.

Fortunately, there was a new turning point in the story later. After continuous exploration and practice, I found that traditional EA architecture has many aspects that are inadequate when dealing with platform-based enterprise architectures like the middle platform, such as:

• Traditional EA methods are mostly based on sorting out business processes, and the output is mostly about purchasing or developing systems to solve some problems in business processes. Therefore, most of the output is that enterprises need to purchase systems such as ERP and CRM to solve specific problems in certain fields. As for how to precipitate into a platform or even a middle platform, it seems not so applicable.
• Traditional EA methods are more about solving problems under the background of informationization at that time, that is, based on the current situation (As-is) business sorting, considering how to solve the problem of informationization transformation of business processes through system construction. However, when building a middle platform, the degree of informationization is often very high, and all the necessary systems are in place. Mid-platform building, even the digital construction that everyone often talks about, is more for the future (To-be) business development and innovation, which seems to be not very compatible with traditional EA methods.
• Traditional EA methods are mostly heavy processes that require long-term and extensive research, resulting in planning documents of hundreds of pages. This was feasible and mainstream in the era of low information development and waterfall processes dominating more than a decade ago. However, with the current speed of IT changes in the Internet and even traditional enterprises, even if it is planned with great effort, it may become outdated and not very compatible.

Therefore, I have reignited my enthusiasm for the methodology research of mid-platform planning construction. I am thinking about whether it is possible to use the traditional enterprise framework as the basis and incorporate some new ingredients, such as integrating Design Thinking to solve innovation problems, integrating Domain-Driven Design to solve the problem of identifying the capabilities of set up functional teams, and then integrating agile and lean thinking to solve the problems of heavy process, long process, and low change responsiveness. By pooling the strengths of many parties, a new enterprise-level architecture method, which is the platform-based enterprise architecture facing users and innovation, can be harmonized.

In the blink of an eye, more than two years have passed. As of now, we have developed an improved version of the EA method, which, as I mentioned above, integrates the strengths of various companies. Currently, we have helped many companies with mid-platform planning using this method, and many others are already in the process of implementation. It can be said that this method is very mature, so today we are officially sharing it with you.

What is this method? We call it the " D4 model ".

# Mid-platform planning methodology: D4 model

The reason why it is called D4 is mainly because we have divided the process of the middle platform from overall planning to delivery into four different stages, including two divergent and convergent processes.

The first stage is Discovery , which helps us establish a global perspective before mid-platform planning. In this process, we take the enterprise vision and strategy as input, combine industry trends, competitor analysis, user customer analysis, business status analysis, IT asset inventory, comprehensively and multi-angled understanding of the enterprise’s strategic market environment and business and IT overview, and help us make the most correct judgment.

The second stage is Define , which helps us to converge and analyze the various dimensional information diverged from the previous Discovery, and define the architecture of the middle platform. By analyzing the overlap degree of cross-Line of Business business combing, and combining domain analysis to further expand and analyze the core problem domain of the enterprise after the business appearance, we can converge and deduce the enterprise architecture design based on the middle platform. Based on multi-dimensional scoring, a specific implementation path plan is formed, which is to do what first and what later. It should be noted that at this time, the convergence is still at the enterprise architecture level. Products at the level of Central Product Platform and data mid-platform may only be a project in the implementation path. At this stage, we can also answer the question we are concerned about. Do we really need a middle platform and what middle platforms do we need?

The third stage is Design , which helps us to do detailed design for a product in the implementation path, such as Central Product Platform, including product-level business requirement analysis, functional and architectural design, implementation plan, etc. For example, for Central Product Platform products, in the Design stage, we need to answer the product vision, boundary, Product Form, technical architecture, delivery plan, cost estimate, etc. This process is a standard product design process, but in the middle platform project, it is mostly for middle platform products.

The fourth stage is Delivery . At this time, we can start the specific delivery process for a well-designed middle platform. We adopt an agile and lean software development approach, using rapid iteration and feedback-based adjustments to make up for the design deviation and other delivery problems caused by the complexity of mid-platform building itself, and pay attention to the governance and guardianship of the architecture to reduce the deviation between implementation and design.

The entire D4 process is a process from strategy to implementation, from enterprise architecture to product architecture and final delivery. Following the ideas of agility and lean, the entire D4 process is also constantly iterative. For example, every quarter to half a year, we can redo lightweight Discovery and Define to continuously make agile adjustments to the enterprise architecture to cope with market and self-changes and uncertainties.

Finally, a colleague asked me why it’s called D4 instead of 4D. There’s actually a little Easter egg here, because we think the pronunciation of D4 in Chinese is a bit like Diss, representing our attitude of constantly challenging old business forms, constantly innovating, and constantly changing, which is also very in line with the current wave of enterprise digital transformation.

# Summarize thinking

Today’s lecture, I will take you from a typical mid-platform building in the starting phase will encounter the problem cut, elaborated on the difference between a middle platform and a distributed system, and finally understand the essence of the problem behind the middle platform, In fact, it is a user-oriented and innovative platform-type enterprise architecture problem .

Afterwards, we analyzed why traditional enterprise architecture methods have limitations in dealing with mid-platform issues, combined with some relatively new practices, and integrated them into our current mid-platform planning and construction methodology, the D4 model.

Finally, I briefly introduced the overall situation and ideas of the D4 model to you. So far, we have used this methodology to help many companies plan and implement their middle platforms.

From the current feedback effect, this model is still very useful, because this method actually implements a principle we call Think Big, Start Small, Move Fast. We need to think long-term, quickly cut in, and maintain continuous evolution. This principle is particularly suitable and necessary when dealing with mid-platform planning and construction tasks with high uncertainty and complexity.

Finally, I’ll leave you with a few thought-provoking questions:

• What kind of problems have you encountered during the mid-platform building process? And how did you deal with them?
• What methods is your company using to plan and build the middle platform? What are the similarities and differences with the D4 model I mentioned?

Through the previous sharing, I believe you have gained some understanding of the concept of middle platform.

There are many people and articles discussing the concept of middle platform in the community now, but few articles describe the implementation methods in detail.

It’s not because the landing of the middle platform is so mysterious, but because as mentioned earlier, the middle platform is an enterprise-level ability to reuse platform. First of all, the middle platform focuses on the development of the enterprise level. Generally, we often refer to this level of problem as the strategic problem of the enterprise. Each enterprise has different strategies and core capabilities, so naturally the middle platform of each enterprise is also different.

Since the middle platform of each company is different, does that mean that the landing method of the middle platform can only be explored by oneself and there is no trace to be found?

The answer is naturally negative. There must be rules to follow when building a middle platform, but compared to other technical methods, it is more abstract. How to put it? Essentially, the middle platform is still an architecture problem, but it is no longer the technical architecture we often see, but a higher level, an enterprise architecture problem.

Therefore, starting from today, we will officially enter the second part of the course, which is the content of the landing section. Let’s explore the methodology of mid-platform building landing together.

Are you already eager to give it a try? However, we still need to wait a bit. Before we officially start discussing the methodology, we need to think about some questions first.

In recent years, I have participated in the mid-platform building of many enterprises. Some of them only got involved in the mid-to-late stage of mid-platform construction, in other words, to put out fires. When I first got involved, I found that mid-platform building had reached a bottleneck period and there were various problems. After continuous analysis, I found that most of the problems could be attributed to not thinking clearly about the following issues before the mid-platform construction officially began.

So, let’s start with these few questions.

# Start with a story

To help you better understand, here we create an example.

“Geek Real Estate” is a real estate enterprise. Unlike other real estate enterprises, this enterprise focuses on more vertical fields, mainly responsible for the development of real estate projects around high-tech parks in first- and second-tier cities, and the target audience is mainly IT practitioners.

The entire real estate industry is now developing towards a light-asset and diversified business direction due to policies and other reasons. I heard that several large real estate leading companies are vigorously conducting mid-platform building. The boss of Geek Real Estate called in Xiao Wang, the most senior and IT-savvy person in the company, hoping that Xiao Wang can take on the responsibility of mid-platform building and help the company’s future transformation and development.

After learning this news, Xiao Wang was very excited. As the person who knows the most about the company’s information construction, and has been paying close attention to the concept of the middle platform that everyone is talking about outside, he knows the core and importance of the middle platform to a company. With such an important task on his shoulders, Xiao Wang is determined to do it well and not disappoint the boss’s trust.

In the blink of an eye, six months have passed.

Looking at Xiao Wang at this moment, he has long lost his original ambition and ambition. Instead, he is exhausted and suffocated by the pressure from all sides. This is manifested in:

• Since the establishment of the mid-platform team, all businesses have been constantly submitting demands. The boundaries of the mid-platform itself are relatively blurred, but because people and resources were initially borrowed and divided from the front desk, it is difficult to refuse the demands of each front desk. The mid-platform seems to have become an internal outsourcing team shared by all front desk business teams. Problems of demand congestion and scheduling have also begun to emerge. There are too many demands to handle, and front desk business continues to complain about the slow response of the mid-platform, which affects front-line business.
• The position of the mid-platform team is also quite awkward. There are many stakeholders, with various business front-end teams in the front and various core systems that the enterprise already has to integrate in the back, and they also have to face continuous supervision from the leaders. Moreover, the most important thing is that all parties feel that there are different understandings and demands for the mid-platform, and even the demands of some different stakeholders will contradict and conflict with each other. The mid-platform team and Xiao Wang are sandwiched between all parties, constantly pulled and pulled by various stakeholders, which is very uncomfortable.
• Also, the middle platform has been under construction for some time, and half a year has passed. However, what worries Xiao Wang is that he feels that there are not many construction results. The things done are messy, mainly responding to the needs of various front-end businesses, but the front-end businesses do not like to use them much. When the requirements are raised, they are more and more active. When the front-end access is really needed after completion, they use various excuses to refuse and are not very willing to connect. It feels that there is not much difference between whether the middle platform is done or not, and it has not achieved the expected effect, and even the expected effect has not been thought through.
• ……

There are many similar problems. Xiao Wang has lost his initial sharpness and frowns every day.

# Four questions to consider before building a mid-platform

Although this is a fictional story, situations like Xiao Wang’s in reality are not uncommon. In the mid-platform building process of many companies I have come into contact with, similar problems have occurred to varying degrees, which have troubled all mid-platform teams and even shaken the determination of mid-platform building in enterprises, rethinking whether mid-platform is the right direction.

But in my opinion, to get out of this predicament, we need to think through four questions before mid-platform building.

What is the vision of mid-platform building?

“When in doubt, look at the vision.” This is the sentence I say the most in the process of mid-platform planning and implementation.

Too often we confuse the solution with the problem itself. The middle platform is just a solution, but many times I see people treating the middle platform as the problem itself, torn apart by what other people’s middle platforms look like, and what their own middle platform should look like, rather than focusing on whether the middle platform has solved the problem that needs to be solved, or even hoping that the middle platform will solve the problem without thinking clearly.

So what I am often asked is, what should the middle platform look like? How should the middle platform be built? And I usually ask back first: What problem are you building the middle platform to solve? What value does it have for the enterprise and business? In many cases, the other party cannot give a clear and direct answer, or they say a lot of “big talk” like eliminating chimneys and removing islands. In my opinion, this is because the vision of mid-platform building has not been clarified.

The mid-platform is like a product, it needs a clear vision so that everyone can clearly understand the value of mid-platform building for the enterprise and business, so that they can continue to move in the same direction together. If the vision is missing, we will easily lose our direction and determination in the mid-platform building process.

Vision helps us understand our mid-platform building goals and judge what is in line with the mid-platform building vision. As a mid-platform team, we need to consider this. In addition, it is more important to help us judge what is not what the mid-platform needs to do and subtract for the mid-platform. This is actually more important in the process of mid-platform building.

Especially in the early stages of mid-platform building, projects are often still in the pilot stage, and there are not many available personnel and resources. Without their own direction, they will fall into the situation where Xiao Wang is located, turning the mid-platform into an internal shared outsourcing team.

Therefore, before building the middle platform, the first thing to ask oneself is: what is our vision for building the middle platform? And more importantly, this vision needs to be clear and agreed upon by all roles, from the enterprise management to every relevant personnel in the middle platform.

How to achieve it specifically? In the actual implementation process, we will have some tools and practices. I will share them with you in the course of mid-platform design later.

Who are the users and customers of the middle platform?

This issue is also very crucial, because the middle platform is an enterprise-level matter and will inevitably face organizational issues and complex stakeholder issues.

To put it more bluntly, the construction of the middle platform usually accompanies organizational restructuring and the redistribution of interests and responsibilities within the enterprise. If the relationships between the various stakeholders in the middle-platform building are not understood, it is inevitable to encounter obstacles in the construction process of the middle platform, fall into a “stakeholders vortex”, face various obstacles, and fall into a very passive situation.

Therefore, before mid-platform building, it is best to clarify who the users and customers of the mid-platform are as a product. Are users and customers a group? What other stakeholders are there besides users and customers? What are their expectations for the mid-platform, and are these expectations consistent?

In order to clarify this issue, we can imagine a company as a family. Specifically, a Line of Business is like a child in the family, who cares more about whether I can play a little longer today, which is what we often call short-term tactical goals. Back in the company, it is whether the KPI goals of my Line of Business for this year or even this month can be achieved.

The management of the enterprise is like the parents of this family. They are more concerned about the future of their children, whether they can compete with tens of thousands of other children during the college entrance examination, and achieve sustainable development, which is what we often call long-term strategic goals. They are concerned about what the enterprise will look like in the next five years, ten years, or even longer.

At this moment, the middle platform is like a K12 English education product. Think about it, if you were the Product Manager of this product, who would you pay more attention to? Is it the short-term tactical goal of the child who is the actual user of the product, to make him enjoy playing, even like a game? Or is it the long-term strategic goal of the parents who are the actual buyers of the product, even sacrificing their child’s User Experience to achieve the best results?

In this example, the fundamental problem lies in the contradiction between long-term strategic goals and short-term tactical goals. The answer is actually very simple: we need to pay attention to both. We need to find the combination point between the focus of enterprise management and Line of Business, that is, the combination point of long-term strategic value and short-term tactical value.

Moreover, for the middle platform, the situation may be more complicated than mentioned above. Its stakeholders are not only users and customers, but also numerous and complex due to its special position. It is very difficult and necessary to find the combination of interests of all parties while maintaining its own direction. Otherwise, it will encounter resistance from all parties during the construction process, resulting in friction and making it difficult for the middle platform to be implemented.

On the other hand, the middle platform should not only try to meet the demands of all parties. After all, the mid-platform team is not an outsourcing team for business. The middle platform needs to have its own ideas and plans, be able to listen to others, but also clarify its own goals and follow its own path. Its goals come from the mid-platform building vision mentioned above, and the vision of the middle platform often comes from the strategic needs of the enterprise.

Therefore, I often say that although mid-platform building needs to take into account the interests of all parties, it is mainly to solve the fear and anxiety of the enterprise management for the long-term survival and sustainable development of the company .

It is very important to think clearly about this point, because the next question is related to this point, which is who should pay for the middle platform?

Who pays for the middle platform?

We often say that talking about money hurts relationships, but we often choose to avoid it. However, the issue of money is often the essence behind many problems and the source of many conflicts in the mid-platform building process.

The money here is spoken in plain language. For internal enterprises, it may represent people and resources. Therefore, this question can also be extended to where do the people in the middle platform come from? Should they be secondments from the front-end team or newly recruited? A mid-platform building often lasts for a long time, so who will bear the cost of these people? If the middle platform is empowered for front-end business, shouldn’t a portion of the budget for front-end business be allocated as the construction budget for the middle platform?

If these issues are not carefully considered, they will also bring great trouble to mid-platform building.

In my opinion, mid-platform buildings on the market can be basically divided into two types in terms of investment structure, namely " crowd funding model " and " investment financing model ". Of course, we can also see these two types of Blend Mode.

First, let’s talk about the " crowd funding model ". I believe you can understand at a glance that the crowd funding model is the user’s advance payment, and the producer promises to provide a certain type of product after a certain period of time. Returning to the background of mid-platform building, it is to raise funds from the front-end of the business. Those who have money hold a money field and those who don’t have money touch a personal field. Those who can come up with a budget come up with a budget, and those who can come up with people come up with people to form a mid-platform team, and then serve the front-end business team in turn.

As I mentioned in the previous lectures, the middle platform is born for front-end business, so it seems that the front-end provides resources and the middle platform serves the front-end, taking people’s money to help them avoid disasters, which is only natural.

Actually, there is a big problem hidden here, which lies in the matching of the vision of mid-platform building and the investment model of the middle platform. Because the business front-end prioritizes its short-term practical problems, it allocates certain resources from the already resource-tight front-end business to mid-platform building. As the actual investor of mid-platform building, the business front-end will also pay more attention to short-term tactical goals, naturally hoping that the middle platform can see results in the short term and help solve practical problems.

If the vision of the mid-platform is to solve the short-term problems of the business side, it’s actually okay. But most of the mid-platform building visions I see are at the strategic level of the enterprise and are built for the long-term development of the enterprise.

At this time, if the crowd funding model is still used, it will be found to be very contradictory. The management team of the enterprise is often the initiator of the middle platform, and they focus more on long-term strategic goals, which the mid-platform team needs to listen to. However, the front-end business team, as the actual investor and user of the middle platform, is both a user and a customer. They focus on relatively short-term tactical goals and need to see the actual value of the mid-platform building results for the business in the short term, which the mid-platform team needs to listen to. At this time, the team of the middle platform will naturally be pulled back and forth between long-term and short-term goals, which is very uncomfortable.

So if the vision of mid-platform building is to solve the long-term strategic goal of the enterprise, then I suggest using another “financing model” that everyone is familiar with, or at least a combination of financing model and crowd funding model.

The investment and financing model , as the name suggests, is a model in which the investor invests in the early stage of a product’s construction. After a period of construction according to the product’s construction goals, it gradually allows users to use it, and finally satisfies users through user services, achieving income and recovering enterprise investment and profits. Currently, most start-up companies adopt a similar model, which I believe you are also familiar with.

For the investment and financing model of mid-platform building, it is the early stage (from 0 to 1) of mid-platform building. Resources are not directly allocated from the front-end business team, but invested and constructed by the enterprise’s own strategic reserve resources. After a certain period of construction, such as 6 months, suitable front-end businesses are gradually found for pilot integration. If the effect is good, it will be promoted to more front-end business teams. After the service is stable and has generated stable value for the front-end, a certain amount of resources can be gradually collected from the front-end, which can be people or other resources, that is, the so-called recovery of investment and realization of profit. The profit here is just a metaphor, which may meet the needs of the enterprise management for the enterprise’s strategic goals.

The advantage of this model is that the mid-platform team will have more autonomy in the early stage of mid-platform construction, and will not be affected by too much existing business pressure during the start-up and fragile period, which can better realize the mid-platform’s own construction vision. However, the disadvantage is that the enterprise needs to have strong strategic resource support and greater strategic determination. I have seen many internet companies’ mid-platform building often adopt similar models, so in the eyes of the outside world, their mid-platform building is very direct and rapid.

Therefore, if the vision of your company to build a middle platform is to solve the pain points and problems at the short-term tactical level, you can use the crowd funding model and the progressive investment structure to start. The advantage of this is that the start-up of the middle platform will be smoother, the resource utilization rate will be high, and the initial new cost will be lower. However, if the goal of mid-platform building is a long-term strategic problem, such as business transformation, it is still recommended to consider using enterprise strategic investment and investment financing mode more, which is more conducive to the healthy and rapid development of mid-platform building.

How to verify the target of the middle platform?

Do you remember the story of Xiao Wang mentioned at the beginning? Another difficulty of mid-platform building is that it is difficult to quantify the construction results. This is not like the front-end Line of Business or the common ToC type products, where it is relatively easy to find some quantitative indicators to measure the success of the product, such as common user numbers, user engagement rates, or market coverage rates.

Of course, the mid-platform can also be said to have achieved these results in the front-end because of the empowering effect of my mid-platform, but this is often dangerous. Because we cannot provide detailed data to prove how many of these users and market share are actually due to the results of mid-platform building. On the contrary, the front-end business may say that the mid-platform is still lagging behind. If it weren’t for the mid-platform failing twice a few days ago, which affected our front-end business, the numbers might have been much better than they are now, and so on.

You see, as a front-end service provider, the middle platform not only cannot share the joy of business success, but is also easily blamed as a scapegoat.

Therefore, starting with the end in mind, we should consider how to verify and measure the middle platform before construction. By considering this issue in advance, we can avoid some disputes and risks in the middle and later stages of construction.

Currently, there are some mid-platform assessment standards in the industry that we can refer to. For example, Alibaba’s mid-platform assessment is designed as follows: 40% stability + 25% business innovation + 20% service access + 15% customer satisfaction.

Can we simply reuse other people’s metrics for our own mid-platform? The answer is definitely no. The vision of mid-platform building is different, and the assessment methods and metrics are naturally different.

For example, in the case of Geek Real Estate, the vision of mid-platform building is to support business transformation and new businesses. Therefore, it may not be necessary to require such high stability and access volume in the early stages. It may only support one or two new Lines of Business, and the focus is more on service satisfaction or other indicators.

When it comes to the verification index design of a certain middle platform in a company, it is a complex process that often evolves. It needs to be comprehensively designed based on the middle platform vision, investment model, stakeholders’ interests, and other relevant factors mentioned above. I will elaborate on some of the ideas and thoughts we use in the middle platform planning and design section.

Finally, it is recommended that you do not wait until the construction is completed to consider how to measure the problem. Try to consider it in advance or even make a clear agreement before the construction, so as to help the mid-platform building avoid deviation and confusion to the greatest extent.

# Summarize thinking

Actually, mid-platform building is a very “dangerous” process, and the above problems are only the most basic ones.

It is important to think through these issues because they can help us judge whether the “surrounding environment” of mid-platform building is ready. We see many companies building mid-platforms, some successful and some failed, not because of any significant differences in strength and methods, but because the problems and difficulties encountered by everyone are often the same.

The most important thing is whether the environment of the middle platform incubation has matured . Some companies have not succeeded in the end because they have gone too early, their ideas are too advanced, and the surrounding environment is not ready.

Therefore, before truly starting mid-platform planning construction, it is necessary and helpful to ask ourselves these four questions based on my own experience.

Finally, if your company is also planning or has already started building a middle platform, please think about whether you have thought it through for the four questions mentioned today. Can you write down the conclusions of these questions on one page of A4 paper and show them to others to see if their understanding is consistent?

If you haven’t been exposed to mid-platform building yet, do you have any questions about today’s content? Please feel free to share your thoughts in the comments section and let’s discuss together. You are welcome to share today’s article with your friends, see you in the next lecture!

Thank you for accompanying me all the way here.

Along the way, we traveled back in time, starting from the history of Zhongtai, re-examining the birth and development of Zhongtai, and gaining insight into the essence and trends behind Zhongtai from the current prosperity.

Afterwards, I also shared with you the origin, ideas, principles, and practices of our mid-platform building methodology, which is the D4 model. Let’s review it together, which consists of two rounds of “divergence and convergence”: the first round is Discovery and Define, and the second round is Design and Delivery, corresponding to the four stages of mid-platform landing: enterprise strategic decomposition and current situation investigation, enterprise digital panoramic planning, mid-platform planning and design, and mid-platform construction and access. Using the example of Geek Real Estate as an introduction, we will take you through the entire journey of building a mid-platform.

I know that the content about the middle platform is far more than that. There are many things that have not been mentioned, such as data mid-platform and technology mid-platform, and we have not expanded on organizational preparations.

Although there are some regrets, as a small column, since it is called “Talking Through the Middle Platform”, we will take less as more (Less is more), not seeking to be comprehensive, just to restore the whole picture of a middle platform for you, and give you a relatively complete middle platform map. Every corner of the map has dangers and surprises, and the actual exploration and specific process of the middle platform can only be explored, discovered, and experienced by yourself.

Is this the end? Have we talked about the middle platform thoroughly? I think there is still a little bit left, and there is one question that has not been answered.

At the beginning, we start with the end; in the end, we end with the beginning.

Returning to the question I was thinking about at the beginning, is the middle platform the trend or just a flash in the pan? Or, now, we can put it another way, is the trend of enterprise architecture evolving towards a platform the trend or just a flash in the pan?

Again, I believe the former more, why? Because: " users ".

Have you ever thought about why the middle platform is successful on the Internet? Traditional enterprises also have the same pain points and problems. Why hasn’t a successful middle platform or related concept emerged and instead become a follower of the Internet?

The difference here is not in the business, nor in the technology, but in: who are you looking at in the end?!

Internet companies need a middle platform, not to add icing on the cake, but to survive, because of fear . Because the competition is too fierce, whoever can grab users, who can win their hearts, who can retain users, who can kill others and succeed. This is not a political need, nor a technical need, it is a survival need , a life-and-death struggle. Therefore, Internet companies naturally focus on users, which is engraved in their genes for survival.

And the user is " spoiled ", and requires you to produce products in an endless stream, constantly iterative updates; also have to be economically cheap, unwilling to pay a little more cost.

Have you ever thought that these two types of needs are inherently contradictory, requiring both flexibility and economy? Enterprises have no choice but to unconditionally continue to satisfy users’ various " unreasonable demands " in order to survive. As for the middle platform or platform-based enterprise architecture, I believe it is also an inevitable product for enterprises to survive and develop in such a user-centric era. Why is that?

I don’t know if you’ve heard of it, but there’s an old saying in the IT industry, ‘Any problem encountered in software engineering can be solved by adding an intermediate layer!’

At the enterprise level, the emergence of the new middle layer, the middle platform, is to reconcile the contradiction between “flexibility” and “economy”.

The front desk vertically carries the flexibility of the enterprise; the middle desk horizontally carries the economy of the enterprise; and the separation, game and balance between the front desk and the middle desk is essentially the separation, game and balance between the flexibility and economy of the enterprise as a whole.

And everything, all the problems, why do companies need to build platforms? Why do they need to build middle platforms? Why do they need to become platform-based enterprise architectures? Why do they need to become platform-based organizations?

In the end, the answer has always been there, on the wall around us, those six bright red words: " User-centered ". The key is whether it is ultimately on the wall, on the mouth, in the eyes, in the heart.

And the six words " user-centered " are the final answers to all the questions in my entire column, and also the greatest harvest I have gained from studying the middle platform until now. If all the tools and routines are the moves of the middle platform, then these six words are the heart method.

Finally, I would like to share this heart method with you, hoping that you can also understand the mysteries of it as soon as possible, go beyond various superficial moves, and achieve the state of having a sword in your heart without a sword in your hand.

Today is the last lecture of our middle platform course. I have prepared a learning material package for you, mainly consisting of selected books and articles that I have classified according to their content. If you have the energy to read through these contents, you will gain something from the ideas and methods related to middle platform implementation.

How to make use of these materials specifically? Here are my suggestions. If you are more concerned about macro enterprise-level strategy, you can read more about strategy and change and platform organization. If you are interested in enterprise-level architecture, it will definitely help you. If you are more concerned about the design and implementation of a specific middle platform, I recommend reading about design thinking, domain-driven design, agile & lean, and architecture evolution.

Okay, our course has come to an end. You are welcome to continue sharing your thoughts and gains, or talk about the problems and confusion you have encountered. I will always be here and look forward to seeing you again in the Q & A section!

# Book recommendation

1. Mid-platform concept

• The Way of Enterprise IT Architecture Transformation Alibaba Middle Platform Strategic Thinking and Architecture Practice
• Mid-Platform Strategy: Mid-Platform Building and Digital Commerce

2. Strategy and change

• On Grand Strategy
• “The Essence of Strategy”
• “Leading Change”
• The New Generation of Business Models
• Systems Thinking

3. Platform organization

• Unlocking Potential: An Evolutionary Roadmap for Platform Organizations
• Reinventing Haier: A Replicable Path to Organizational Evolution
• Empower: Building Agile Teams for Uncertainty

4. Enterprise architecture methodology

• TOGAF Standard Version 9.1
• Enterprise-level Business Architecture Design: Methodology and Practice
• Winning the B-end: The Road to Product Manager Upgrade

5. Design Thinking (DesignThinking)

• Strategic Design Thinking
• Innovative Design Thinking

6. Domain-driven design

• Domain-Driven Design: Coping with Software Core Complexity
• Implementing Domain-Driven Design
• Domain-Driven Design patterns, principles and practices

7. Agile & Lean

• Lean Thinking
• The Lean Startup
• “Lean Enterprise: How High-Performance Organizations Innovate at Scale”
• Kanban Method: The Successful Way for Technology Enterprises to Gradually Transform
• Code Pipeline: A Systematic Approach to Releasing Reliable Software

8. Architecture Evolution

• Evolutionary Architecture
• The Way to Clean Architecture
• Microservice Design

In the previous lecture, I took you on a journey of nearly ten years of middle platform development, understood the background of middle platform development from the perspective of time, and also helped you analyze some of the reasons behind the rise of middle platform.

However, when we talked about it in the end, until now, there is still a lot of confusion about the concept of the middle platform. What exactly is the middle platform? What should the middle platform look like? What are the types? What is the value to the enterprise? Do I need to build a middle platform? These questions may still not have a definite answer in your mind.

Today I will take you to take a look at some different types of middle platforms that have appeared so far, and see if we can find some common characteristics behind these seemingly different types of middle platforms. In the next lecture, I will take you to explore the essence of middle platforms and answer your doubts.

As for the classification of mid-platforms, I have divided the current ones into two categories: “mainstream” and “non-mainstream”. Let me take you through them one by one.

# Mainstream representative: Business data dual middle platform

Central Product Platform

The term business is actually quite broad. I have heard many people say that business is not the same concept. Therefore, I have done some research. In simpler terms, business refers to the business-related affairs that need to be handled in various industries in order to sell products and exchange profits. Therefore, in the early days, we usually referred to sales as salespeople.

NetEase Vice President Wang Yuan once mentioned at the NetEase Cloud Innovation Summit: “All mid-platforms are Central Product Platforms”. I also agree with this statement because, in a broad sense, all mid-platforms, whether they are Central Product Platforms, data mid-platforms, or others, are for business, for enterprises to sell products and exchange profits at lower costs, higher quality, and faster response times.

Looking at it from a different perspective, from the perspective of enterprise architecture, application architecture, technical architecture, and data architecture all need to match the company’s business architecture, because “business”, that is, selling products and exchanging profits, is the core goal of the enterprise.

Okay, since all the middle platforms are Central Product Platform, what does the Central Product Platform in the business data dual middle platform that we often mention represent? In my opinion, The Central Product Platform that we often mention is a narrow business concept. The Central Product Platform needs to specifically carry out the necessary business elements to support business development, encapsulating the necessary problem space solutions that need to be solved to ensure the smooth development of business .

This may sound empty, but I have a trick. When I think about the Central Product Platform, I keep asking myself one question: What are the core issues that need to be solved for the smooth development of the enterprise’s business?

For example, in the scenario of e-commerce, if I were an e-commerce company and my business needed to develop smoothly, that is, to sell my products to users in exchange for profits, the core issues that generally need to be solved are:

• Who are my users? Where do they come from?
• What products do I sell? Where do they come from?
• How can I let users know about the products I sell?
• Why would users buy the products I sell?
• How do users buy?
• How to deliver the goods?
• How do users return or exchange goods?
• How to make users keep buying?

These are the most basic and core issues that an e-commerce business needs to solve in order to operate normally. In DDD (Domain-Driven Design), there is a proprietary term for the core problem space that these enterprises need to pay attention to in business development, which is the problem domain . The commonly used terms such as user domain and order domain also come from this.

For different Lines of Business of an e-commerce company, it is mostly due to different products sold, regions sold, and client bases. However, these problems also need to be solved, and in most cases, the solutions are similar. This is why the Central Product Platform can exist.

Therefore, the Central Product Platform we often mention can be understood as a narrow definition of the Central Product Platform. It abstracts and encapsulates solutions to the same problem domain from different Lines of Business, and takes into account the specific needs of each Line of Business through mechanisms such as configuration, plug-in, and service, to achieve business support for different Lines of Business.

Data mid-platform

After discussing Central Product Platform, let’s take a look at the currently most popular data mid-platform. Why is data mid-platform so popular? I have summarized several main reasons.

1. Quick results. Currently, the problem for most traditional enterprises is still the lack of data communication. The phenomenon of “data silos” is quite serious. The construction of a data mid-platform directly solves pain points and has strong driving force.
2. The burden of organizational adjustment is small. Generally speaking, enterprises of a certain scale already have a Big data or BI team, which naturally carries relevant functions and does not require further major organizational adjustments.
3. There is a certain technical foundation reserve. Most enterprises have been building data warehouses for many years, or have built big data technology platforms for many years with the wave of big data in recent years.
4. The trend is inevitable. Everyone is talking about the DT (Data Technology) era, and enterprises have a deeper understanding of the value of data. Everyone has realized that data is no longer just a tool for operational analysis, but has gradually become the core asset and competitiveness of enterprises.

With minimal organizational changes, established technical foundation, obvious pain points, low cost, and quick results, it is the trend of the times. Therefore, it is not surprising that data mid-platform has become a hot topic of concern.

However, since we are now talking about business digitization and data commercialization, and since the two concepts are also transforming and integrating with each other, what is the relationship between data mid-platform and Central Product Platform? What is data mid-platform? What are the differences and connections with the data warehouse and Big data platform built in the past?

I believe that these are also issues that many colleagues who pay attention to data mid-platform are particularly concerned about.

Regarding the relationship between Central Product Platform and data mid-platform, I agree with the viewpoint mentioned by Xie Chunliang, the technical solution director of Alibaba, in an InfoQ interview: " Central Product Platform is generating data, data mid-platform is doing secondary processing of data, and then serving the business with the results, empowering the business with data and intelligence. "

The key difference between data mid-platform and traditional data warehouses and data platforms lies in the fact that data mid-platform has taken a step forward and towards business compared to data warehouses and Big data platforms. It no longer only focuses on the construction of the technical level of Big data foundation, but also pays more attention to enterprise-level data governance and data assets, including but not limited to data asset management (quality, cost, security), data service construction, and data system construction (unified models and indicators).

For the sake of convenience, at ThoughtWorks, we often compare the data mid-platform to a Data Factory. It collects data from the raw material warehouse, processes it through the factory assembly line, and finally enters the product warehouse as a data product. Through the data store, it empowers the front-end or Central Product Platform in various ways (such as data API), and the entire process is coordinated and scheduled through the control center.

This metaphor vividly embodies the process of secondary processing of data by the data mid-platform, and also describes the intelligent processing of data through the data laboratory, and the relevant processing of data governance and assetization through Office.

After introducing our most common business data dual middle platform, here is a summary.

The Central Product Platform and the data mid-platform complement each other, support each other, and input and output each other. The Central Product Platform carries the general business capabilities of the enterprise, empowering multiple Lines of Business; the data mid-platform empowers the business in terms of data and intelligence through secondary processing of business data and feedback to the Central Product Platform. The close cooperation between the two has built a powerful rear artillery group for the enterprise in the business battlefield, which constitutes the most famous business data dual-middle platform model.

# Non-mainstream series

In addition to the dual middleware for business data, various middleware have also emerged, and the appearance of these middleware has made the originally clear concept of middleware somewhat blurred. Next, I will quickly introduce to you some middleware that I have come into contact with in recent years. In the process of my narration, you can also think about which of these middleware are Li Kui and which are Li Gui, who truly deserves the title of middleware, and who is here to ride on traffic.

Technology mid-platform

In addition to the dual middleware for business data, the most commonly mentioned one, in my opinion, is the technology mid-platform, which is between mainstream and non-mainstream. Compared with the Central Product Platform and the data mid-platform, the boundary of the technology mid-platform is also clearer. Simply put, it integrates and packages the ability to use cloud or other infrastructure and various technology Middleware capabilities under CloudNative. It filters out technical details, provides a simple, consistent, and easy-to-use application technology infrastructure capability interface, and helps the front-end and the rapid construction of the Central Product Platform and data mid-platform. However, there are also opinions in the industry that the technology mid-platform does not have strong business attributes, but is just a collection of Middleware, at most it can be considered a Middleware platform, not a mid-platform. What do you think?

R & D middle platform

Software development is a project that involves management, processes, testing, team collaboration, and so on. How to precipitate an enterprise’s development process and best practices into reusable “capabilities” to help the rapid development and iteration of innovative applications is also something we see many enterprises doing. We can call this platform that focuses on development efficiency management a R & D platform.

Mobile middle platform

In the era of mobile Internet, the principle of mobile first has become an indisputable fact. By encapsulating and precipitating the general technical components in the App development process into the mobile middleware, a large number of existing components and capabilities can be reused when building a new App to quickly build and respond.

Management middle platform

Recently, many enterprises have started to try to apply the middle platform thinking to the internal of the enterprise, and re-platform/set up functional teams for “people”, “things”, “processes” and “enterprise operations”. They attempt to accelerate the standardization of enterprise management and improve operational capabilities through the construction of set up functional teams.

Organization mid-platform

In Mr. Mu Sheng’s book “Unleashing Potential: The Evolution Roadmap of Platform Organizations”, he proposed the concept of an organizational middle platform by analyzing the evolution process of Haier’s platform organization. The organizational middle platform is similar to internal venture capital and innovation incubation institutions in enterprises, providing front-end organizations and teams with innovative front-end applications similar to investment evaluation (project screening), investment management, and post-investment management (incubation and risk control), truly supporting the rapid iteration and large-scale innovation of front-end organizations and applications from an organizational and institutional perspective.

Well, that’s all for the non-mainstream series. In fact, there are far more than that. Other platforms such as financial middle platform, procurement middle platform, supply chain management, AI middle platform, operation middle platform, security middle platform, management middle platform, etc. have also appeared in our field of vision. Today, I will not expand on them one by one.

# Summarize thinking

Finally, let’s make a summary. In this lecture, I took you through the common types of middle platforms on the market. At this point, you may feel more confused than before. There are so many different types of middle platforms, and you can’t tell which one is Li Kui or Li Gui. The ultimate question of what a middle platform is must still be lingering in your mind.

Don’t worry, through the divergence of the first two lectures, I want you to open your horizons like me, establish a global perspective from the dimensions of time and space, and in the next lecture, we will do the first convergence to explore the essence of the middle platform.

Finally, I’ll leave you with a few thought-provoking questions:

• Does your own company have a middle platform? What type is it?
• Do you have a different understanding of these middle platforms mentioned above?
• Besides what we talked about today, what other types of mid-platform have you seen?
• Do you have a standard to judge which ones are mid-platform?

Through the content introduced in the previous class, we finally obtained a mid-platform scenario as the entry point, identified the need to reuse data, processes, and functions through business sorting, and combined with the MVP principle to find the first fast verification requirement set. Combined with the access conditions of the front-end, we formed the first small mid-platform building sprint plan, and started with the end in mind. Before starting, we determined the verification indicators for mid-platform building, and had requirements, plans, and acceptance conditions.

If you can successfully pass the internal project approval and process of the enterprise, congratulations, you have already completed your first formal mid-platform project.

Next, we enter the fourth stage of D4, which is the last but possibly longest delivery stage.

The first step in delivery must be to build a combat-ready team. The capabilities required for mid-platform construction are quite different from those of traditional products. I would like to share with you a mid-platform personnel capability model by Teacher Sun Zhigang, which I think is very enlightening and hopes to help you understand the requirements of mid-platform for team capabilities. Teacher Sun has written an article about this model, which also mentions some difficulties in the mid-platform building process. I will put the article in the final summary as an extended reading recommendation for you.

After forming a formed mid-platform building team, the subsequent construction work is actually similar to the construction process of our general projects or products. However, due to the special position of the mid-platform, the requirements for product definition and the difficulty of modeling are one level higher than the complexity of other end point products. Therefore, we suggest adopting a lean Product Research & Development process , maintaining a process of small iterations, rapid construction, rapid measurement, rapid feedback, and rapid adjustment, to ensure that mid-platform building is a continuous evolution and business-driven process.

# Lean Product Research & Development Process

This is called the Lean Product Research & Development process, which mainly faces the uncertainty in the mid-platform building process, introduces lean thinking to achieve the definition and rapid flow and measurement of value, and combines agile development practices to make the entire software development process lightweight, fast, agile, and value-driven.

The term lean should be familiar to you. In the previous lecture, we talked about MVP from Lean Startup. People often mention lean software development, lean production and manufacturing, etc. Essentially, they are the results of applying lean thinking to a certain vertical field.

The key reason why lean thinking is popular is that it defines a complete ideological framework, and the ultimate core goal is to eliminate waste and create value. In the actual construction process of the middle platform, we also suggest introducing lean thinking, combining it with the software development process, quickly developing products in small batches, quickly introducing metrics, quickly verifying and recognizing previous demand assumptions based on measured data, and making rapid adjustments based on this.

You may have a question here, what is the difference between agile and lean?

In fact, Lean and Agile are often talked about together, and I find that many people do not understand the difference between the two. Simply put, Agile focuses on how to deliver value in a rhythmic manner through iterative methods of small steps and fast running when the value is determined; while Lean focuses on how to quickly locate the true value point with minimal cost when the value is uncertain .

We found that due to the high complexity of mid-platform building, applying lean thinking combined with agile thinking to the construction and development process of the mid-platform, combined with the establishment of the mid-platform operation mechanism that will be discussed later, can help us better deal with various problems in the mid-platform building process, such as the classic problem of defining the boundaries of the mid-platform.

As for our specific approach, you can refer to the following figure. The tools and practices involved are relatively mature, so we won’t go into detail here. The most important thing is to quickly verify the previously made demand value assumptions through data operation, which is based on continuous verification of measurement indicators, and continuously adjust them. In lean thinking, this is called perfection. What the team needs to do is to constantly accelerate the speed of this feedback loop. The faster the speed, the stronger our ability to deal with uncertainty and deliver the value of mid-platform products.

Of course, the whole process is a complex and systematic project, which generally involves projects such as cloud engineering, microservice and service-oriented capability construction, Devops-related capability construction, data operation capability construction, agile lean process improvement, legacy system service transformation, architecture guardianship and evolution, as well as governance and operation architecture construction related to the middle platform.

# Operation, governance and evolution of the middle platform

In addition to the construction process of the middle platform, we cannot ignore the continuous governance and evolution during the mid-platform building process, as well as the operation and management of the middle platform after truly connecting to the front desk.

Many of the difficulties and problems we encounter in the mid-platform building process on the market are, in my opinion, caused by the failure to do a good job in the governance and operation of the mid-platform. The industry’s understanding of the overall governance and operation mechanism of the mid-platform is also inconsistent. After all, as a platform product of an enterprise, the mid-platform does not serve the end users of the enterprise. Therefore, it is different from the product-based user-side operation often mentioned in the Internet. The mid-platform is more like a ToB product serving the front-end application of the enterprise internally.

As for how to operate toB platform products within the enterprise, it is currently a point of concern in the industry. Today, I will talk about a few key points that I think are important. Paying attention to these issues can help us avoid some detours and pitfalls in the mid-platform building process.

The first step to clarify is the user division of the middle platform product .

You must be confused when you see this. As an internal platform product of the enterprise, all the front-end users of the middle platform should be the would-be users of the middle platform, especially if they are all brother departments within the enterprise. Why do we need to divide the front-end users?

This is the interesting part, and also the lesson I learned in the process of mid-platform building in the past. At the beginning of the mid-platform building process, we did not make any division for the front end, treating everyone equally.

However, as a public service department, the middle platform will inevitably encounter different needs, schedules, quality requirements, and non-functional requirements from multiple front desks, and even often have conflicting needs or non-functional requirements between multiple front desks. The resources of the middle platform are limited, and it has its own vision. It is impossible to unconditionally meet the demands of all front desk users, often leading to a state of exhaustion and a rapid decrease in response and service quality to the front desk.

What should we do? The root of the problem is that although we say that the middle platform is an enterprise-level ability to reuse platform, one thing we often overlook is that if we use productization thinking to build the middle platform, the capabilities accumulated in the middle platform are not all of the product. We also need to add NFR (non-functional requirements) or SLA (Service-Level Agreement, Grade Of Service Agreement) to make the product. Because different front-end users not only have different demands for the functions of the middle platform product itself, but also have different demands for NFR or SLA. To give a simple example, for example, the core business may require 5 nines and 5 milliseconds of performance for the SLA stability of the middle platform; while a new innovative application may not have users yet, so it does not need such high requirements.

Offering = Capability + SLA/NFR

Since that’s the case, how can we use limited resources to serve the different demands of different users? The answer is to divide the front-end users based on their needs and NFR/SLA. This may sound fresh, but in fact, many products around us handle user segmentation in this way, thus achieving hierarchical response and operation of users.

The most common one is the three-tiers customer segmentation mechanism . By stratifying the front-end users, we can specify different demand response mechanisms, communication management mechanisms, service quality control mechanisms, problem handling and upgrade mechanisms, etc. for users at different levels. Naturally, different service types as front-end users also need to pay different costs or resources (people or money), and even the front-end and middle-end can fulfill their service commitments to front-end users by signing SLAs.

For example, when we start mid-platform building, we can only find one or two Seed Users to serve as Tier 1 users. Treat the needs of this Seed User as the highest priority and establish routine communication and service response mechanisms. Because the service is still in its early stages and not particularly mature, we can use the “free” way to use the enterprise’s strategic resources for construction. In this way, for front-end users, the resources are free, and it is a one-to-one service, so they will naturally be willing to cooperate with the construction process of the middle platform.

When the mid-platform construction reaches a certain stage, the service for Seed Users is close to stability, with certain ability accumulation and the ability to release certain resources, it is possible to use the released resources to start building a Self-Service Console (Self-Service Console) for Tier 3 users, and start building the operation team of the mid-platform product, formulating the NFR/SLA of Tier 3. In many Internet companies, this process is often rough because the self-service Console made is rough, and it seems to be the process of enhancing and optimizing the availability and governance of platform services. Most of it is just a white screen with some configuration options, so it is often called " visual operation of the platform ".

After the self-service Console of the middle platform is created and the Tier3 level SLA is built, we can re-sign the SLA and migrate the previous Tier1 users to the Tier3 level, completing the migration process from customized services to self-service services for Seed Users, thus releasing more resources for accessing new front-end users.

If for various reasons, it is impossible to achieve complete self-service in one step, you can also build a Tier 2 SLA or sign a new SLA to migrate the previous Tier 1 users to the Tier 2 level. By means of “self-service + VIP service”, you can maintain the continuity of the early Seed User service while releasing as many resources as possible.

At this point, we already have a three-tier user segmentation mechanism, which allows us to release Tier3 self-service services on a larger scale within the enterprise and achieve more user access through this method. At the same time, because some middle platform resources have been released, we can continue to select the next key Seed User (usually a key business) as a new Tier1 user to start the second round of mid-platform building.

By using the user segmentation and operation mechanism of the middle platform, different levels of operation systems can be constructed to achieve reasonable allocation of resources. We also avoid various problems and traps mentioned earlier in the mid-platform building process, operate users at different levels, and solve problems such as demand conflicts, scheduling conflicts, resource shortages, and slow promotion.

# Summarize thinking

In this class, we started with the launch of a mid-platform project, introduced the lean Product Research & Development process, combined lean thinking and agile practices into the R & D and construction process of the mid-platform, accelerated value flow, rapid feedback, and rapid adjustment, so as to better cope with the complexity and uncertainty in the mid-platform building process.

Afterwards, I shared with you the operation and governance mechanisms during the mid-platform building process. I did not delve into the details of the operation mechanism, but emphasized how to manage users in layers, allocate energy and resources reasonably, and achieve smooth progress and product evolution of mid-platform building through the user’s layered SLA mechanism.

Therefore, it should be emphasized that the process of mid-platform building is a long and arduous process. It not only requires enterprises to have the foundation of technology, business, and organization, but also the determination, patience, and preparation for continuous exploration and evolution.

Finally, I’ll leave you with a few thought-provoking questions:

• What is the process of mid-platform building in your company like? What are the similarities and differences with the methods mentioned in the article?
• What is the middle platform operation and governance mechanism of your company? Has user segmentation been done? Are there any issues mentioned in the article such as scheduling conflicts, insufficient resources, and slow response?

In the previous lecture, we collected a lot of information about the internal and external environment of the enterprise from three different perspectives and directions through Discovery. In this lecture, we will talk about how to analyze and converge this information, apply enterprise architecture methods, and ultimately form a digital panoramic plan for the enterprise, and derive an important output of our PD, which is an evolutionary roadmap for the construction of a middle platform.

First, you need to introduce what is the enterprise-level architecture method .

# Enterprise-level architecture approach

Enterprise architecture methods such as Zachman and TOGAF have a history of more than 20 years and can be said to be very mature. Among them, TOGAF should be the most widely used, occupying at least half of the market and being the most well-known to us. The basic idea of TOGAF is to design the To-Be business architecture of the enterprise based on the latest vision strategy and operation mode, and then derive it step by step from the data architecture, application architecture, and technical architecture. This is the process.

When we are currently working on the enterprise digital panoramic plan with the potential target of the middle platform, we also refer to the idea of TOGAF. Based on the information collected by Discovery from various dimensions, we combine the measures of top-down enterprise strategic decomposition and the problems and pain points analyzed from bottom to top in the Define stage, redesign the new business architecture, and further deduce other related architecture designs.

However, compared with the traditional enterprise architecture method, the whole process has been tailored and lightweight, introducing collaborative and interactive forms such as event storms and DDD workshops . The key roles in the whole process are fully discussed, collaborated and co-created, and strive to ensure the accuracy and consistency of the results under the premise of lightweight process.

But there is a key point here, because as mentioned earlier, the middle platform is a platform-based enterprise architecture from the architectural level. Compared with the system-based enterprise architecture we often did in the past, how to more accurately identify the common business elements between multiple Lines of Business from the perspective of the entire enterprise is also a significant new challenge for us.

In order to solve this problem, as mentioned earlier in the overview of methodology, we have integrated Domain-Driven Design (DDD) into the entire enterprise architecture design process, combined with event storms to analyze the problem domains behind business processes, and through the analysis of problem domain overlap between different Lines of Business, we can help us understand the essence of each business of the enterprise through processes and find common business elements.

To give an analogy to this process, it’s like taking an ultrasound of a business, helping us better see through the phenomenon and see the inner essence.

There are many materials related to enterprise architecture methods, such as TOGAF, which will not be elaborated here. In the final summary, I will provide you with some reference materials for further reading.

Using the remaining space, I would like to focus on some common issues related to the middle platform in the process of enterprise architecture design and implementation.

# What are the types of abilities for the middle platform to reuse?

The first question, if the middle platform is the enterprise-level ability to reuse the platform, then in the process of doing enterprise architecture design:

• What common abilities should we look for in different Lines of Business?
• What exactly does the business in the business platform that we often talk about refer to?
• Why is the middle platform usually a combination of business, data, and technology?

To answer these questions, let me first show you a model:

This is a business operations model mentioned in a book on enterprise architecture strategy published by Harvard University Press in 2006. It proposes two quadrants.

• The horizontal axis represents standardization. The higher the standardization, the simpler it can be understood as an enterprise expanding its Line of Business through the reuse of business models (business functions + business processes). For example, various vertical websites of e-commerce websites or globalization achieve the expansion of different Lines of Business by reusing the business models of e-commerce to different vertical fields or regions.
• The vertical axis represents Integration, which can also be understood as Data Transmission Service. Enterprises with this operating model achieve Line of Business expansion by reusing data. For example, the most common example is Tencent, which helps new Line of Business (such as games) expand quickly by integrating and reusing WeChat user data.

Then why mention this model? Because the “business operations model” here is very similar to the ability to reuse in our middle platform, that is, what you need to reuse is the business model; or what you need to reuse is the business data; or neither, just to reuse the lower-level technical part.

Let me explain a little bit.

If two Lines of Business have the same set of data and business processes, it’s simple. They can actually share the same system, which is the most common large monolithic system. However, this is increasingly becoming an anti-pattern, unless in highly standardized scenarios such as core financial systems.

If the business model is very similar between two different Lines of Business, but the data needs to be isolated, it is the lower right area. Generally, you can use the Central Product Platform to precipitate the general abstract business process, or directly use the multi-tenant enterprise internal SaaS to achieve the business model to reuse. In this quadrant, the difference between the Central Product Platform and SaaS is only the difference in abstract granularity and level. Essentially, the problem to be solved is the same, that is, the business model to reuse.

SaaS has a high level of abstraction and is closer to the business, but it has high standardization requirements for the business and less flexibility. Central Product Platform is just the opposite, with a lower level of abstraction than SaaS, between PaaS and SaaS (so many companies call Central Product Platform Application PaaS or Business PaaS), farther away from the business than SaaS, but more flexible. This also answers the question of the difference between Central Product Platform and SaaS that many people are troubled by.

Here I can add a sentence. Recently, a headless commerce (headless e-commerce) has emerged abroad, and a headless CMS also appeared last year. I think this trend of headless abroad is very similar to the middle platform in China, which is just finding a new level of abstraction between PaaS and SaaS.

Okay, after talking about the lower right, let’s talk about the upper left. It refers to scenarios where although the business models are different, Line of Business expansion can be achieved through data integration, connection, and to reuse. Generally, it can also be solved through the Central Product Platform and data mid-platform. Because the Central Product Platform also carries data, or in other words, the Central Product Platform produces business data.

As mentioned earlier, the data mid-platform performs secondary processing on the data produced by the Central Product Platform, such as some big data calculations, cross-domain business data integration calculations, or some AI empower scenarios.

Well, I hope the above analysis can help you understand the concepts and differences between these different middle platforms (including Central Product Platform, data mid-platform, technology mid-platform, as well as Central Product Platform and SaaS, Central Product Platform and data mid-platform).

Going back to the original question, what are the common capabilities we need to look for in different Lines of Business? Now it is very clear, and basically there are four categories: business data, business functions, business processes, and general technical capabilities .

# Identifying commonalities through domain analysis

Since the capabilities that enterprises can reuse are the above four categories, aside from the relatively independent technical capabilities, how can we specifically identify the remaining three common business capabilities of business data, business functions, and business processes?

Taking Geek Real Estate as an example, for the two Lines of Business, Line of Business for property management and Line of Business for long-term rental apartments, they seem to solve completely different problems on the surface. However, this does not mean that there are no business data, business functions, or business processes to reuse between these two Lines of Business. For example, the most direct way is to connect the owner data of the property and the user data of the long-term rental apartment, and achieve the conversion of property owners to long-term rental apartment users through the simplest point mechanism sharing. This achieves user diversion and new business hot start, accelerating the rapid development of emerging businesses.

So how can we identify similar capabilities to reuse scenarios through business processes? Yes, it’s Domain Driven Design (DDD) .

We are for the business that has been sorted out, and we go deeper. We use domain-driven design combined with event storming tools to further analyze the problem space and solution space behind the business process through workshops, identify key aggregations, and then use the problem domain overlay projection across Line of Business to find the problem space and aggregation that everyone is concerned about, so as to continue to expand to identify common scenarios and capabilities.

Here I mentioned a lot of words, such as problem space, solution space, problem domain, and aggregation. These are commonly used terms in DDD and are easy to understand. If you are not familiar with DDD, it is recommended to look it up by yourself before coming back. The whole process is also in the form of brainstorming and workshops.

Returning to the example of Geek Real Estate, let’s fully discuss together and unfold the event storm of the Line of Business and the Line of Business for long-term rental apartments. Combined with the problem domain analysis and aggregation analysis of the domain-driven design strategy part, we can know which problem spaces overlap between these two different Lines of Business, such as the customer domain or the operational domain.

Then expand the problem domain to identify the common business data, business functions, and business processes in these overlapping problem spaces, thus completing the identification of the ability to reuse.

# What are the differences and connections between the middle platform and microservices?

After talking about the business, let’s talk about another issue that everyone is most concerned about and also troubled by in technical architecture design, which is the relationship between Central Product Platform and microservice structure. This is also a question that is often asked when talking about the middle platform, at least ranking in the Top 5. It happens to be about the technical architecture part, and I will briefly talk about my understanding.

First, let me give you my answer: these two are not related!

Isn’t it a bit counterintuitive? After all, these two concepts are often mentioned together. Many books about Central Product Platform also talk about technical architecture and microservices. How can you say these two are unrelated?

Don’t worry, listen to me slowly.

Overall, Central Product Platform and microservices solve different problems and are at different levels of abstraction.

As mentioned earlier, the Central Product Platform solves the problem of reusing business (data, functions, processes) in the business domain, while the microservice structure, as a lightweight distributed technology architecture, solves the problem of “component compilation dependencies” in the technical domain.

And the Central Product Platform is not necessarily a microservice structure, and the microservice structure is not necessarily to solve the problem of ability to reuse.

First, let’s take a look at the Central Product Platform. The Central Product Platform aims to solve the problem of how to quickly reuse business capabilities. Even if it is a large monomer behind it, as long as the exposed API can meet the purpose of quickly reusing business capabilities, it is also possible. This is easy to understand, so I will focus on explaining my views on microservice structure.

Microservices: Microservice structure is an architectural pattern that advocates dividing a single application into a group of small services. Each service runs in its own independent process and communicates with each other using lightweight communication mechanisms (usually RESTfuI API based on HTTP protocol). Each service is built around specific business and can be independently deployed to production environment, class production environment, etc.

There is a key point here that I think has not received enough attention from everyone. As a result, I believe that the vast majority of systems on the market that claim to have a microservice structure are pseudo-microservice structures from the perspective of Lao Ma’s definition. This key point is " can be independently deployed ". I think it is more appropriate to translate it as “can be independently delivered”. This is also the key factor in judging whether a microservice structure can play its value.

This is also the issue of “component dependencies during compile” that I mentioned earlier. In fact, modularization has always been pursued by everyone. For example, the jar packages and various open-source components that we commonly see are good modularization encapsulation. From a technical perspective, microservices are nothing more than pushing the dependencies between components from “compile time” to “runtime”.

Don’t underestimate this change, it brings many benefits. Because dependencies are postponed to “runtime”, it is possible to achieve benefits such as “component independent delivery”, “component runtime dynamic expansion”, “component technology heterogeneity”, etc., but it also comes at the cost of the complexity brought by distributed architecture.

So why is it said that most microservice structures are fake? Because there are integration testing or other factors that result in not achieving true independent delivery (note that it is not deployment). For this reason, I have also written an article “Do you dare to deliver your microservices independently?”, which talks about how to use contract testing strategy design to truly achieve independent delivery of microservices without the need for integration testing, fully unleashing the value of microservice structures. If interested, you can take a look.

In order to truly realize the value of a microservice structure, the main point is that the “services” in it must be stable enough (easier said than done).

Therefore, the Central Product Platform has no direct relationship with the microservice structure. It is only because of the low coupling characteristics that the microservice structure depends on at runtime that it is usually used to achieve team separation, technical separation, and delivery cycle separation of different capability units in the business platform. It can only be regarded as a good pair of partners.

# Overview of Platform Enterprise Architecture Design

Finally, let’s quickly go through the planning process of a complete platform-based enterprise architecture.

\1. Firstly, through the analysis of the existing business architecture of each Line of Business, and then combining the root cause analysis of the identified pain points, we make improvements and designs to the business architecture, so as to improve the existing business architecture and design a new improved business architecture to solve the problems behind the current pain points.

\2. It is also necessary to refer to the goals and measures of each Line of Business after the strategic decomposition, and integrate them into the design of the To-Be business architecture, so that the new business architecture design can simultaneously match the requirements of the enterprise strategy and solve short-term tactical pain points.

\3. For the improved business architecture, cross-Line of Business comparison and analysis can help us find the overlap of business functions and business processes of different Lines of Business, and provide business-level support and input for the necessity judgment of subsequent mid-platform building.

\4. Use the strategic part of Domain-Driven Design (DDD) to analyze the problem domain and bounded context for each Line of Business, as well as identify key aggregations, so as to attempt to cross the process and deeply examine the essence of the business from the perspective of the domain. What problems in the problem space are being solved? Through the division of the problem domain (core, general, support), the importance of the problem space to the enterprise is distinguished.

\5. Similar to business architecture, for the domain analysis view analyzed by each Line of Business, horizontal comparison and projection are performed to identify the problem domains, bounded contexts, and overlapping degrees of aggregation in different Lines of Business from the domain layer. This may be rather abstract. You can think of it as similar to stacking several translucent pictures together to find the intersections. This helps us identify the deep commonalities in business data and business models (functions + processes).

\6. Combine the existing business architecture and application architecture to design and improve the application architecture of each line, and conduct gap analysis through the application architecture of As-is and To-Be to generate specific opportunities for IT construction. Such opportunities are similar to building a CRM system.

\7. Then, based on the cross-domain business architecture analysis and cross-domain domain analysis, discuss and judge the degree of business overlap of multiple Lines of Business, and identify in detail whether the overlap is more at the level of business model (travel, e-commerce), business function (login, shopping cart), or business domain (user data integration). Based on the discussion results, decide whether it is necessary to introduce the construction of the middle platform layer, and according to the overlap situation, plan the application architecture of the middle platform layer in detail.

\8. Finally, analyze the gap between the current situation and the final plan of To-Be, generate a specific list of opportunity points, and prioritize them based on multiple dimensions (such as strategic importance, urgency, cost, resource readiness, technical readiness, risk, pain point mapping, etc.) to generate the final roadmap.

# Summarize thinking

Through the explanation of a complete Discovery and Define process in this lecture and the previous lecture, we have completed a complete process from industry and enterprise strategic goals and visions to the final formation of an enterprise-level architecture based on the middle platform. Of course, this process is much more complex than described in words, but through the explanation, I hope you can establish a comprehensive overview of a platform-based enterprise-level architecture.

At this point, you may ask, I just want to be a middle platform, do I need to go through such complicated strategic planning?

My answer is very clear: very necessary .

Because from the many practical mid-platform building cases I have experienced, many of them are due to the lack of such a discovery and definition process, resulting in a very vague goal of mid-platform construction, only some high-end slogans, without thinking clearly about whether mid-platform building is needed or not, and what mid-platform building represents for enterprises.

In some cases, when we finally converge, we find that although the necessity of mid-platform building exists, it is not the highest priority or does not meet the relevant conditions for the current situation of enterprises and industries. At this time, it is also very dangerous to rashly carry out mid-platform building.

Only here, through the analysis of Discovery and Define, can we conclude that we really need a Central Product Platform, and the priority is also very high. So, how to build the Central Product Platform next? In the next lecture, I will continue to bring you the second layer of divergence (Design) and convergence (Delivery).

Finally, I’ll leave you with a few thought-provoking questions:

• Have you heard of, understood, or used enterprise architecture methods before?
• Do you use enterprise architecture methods for overall planning of the middle platform?
• Do you have any questions or experiences to share about mid-platform planning at the enterprise level?

Welcome to share your opinions in the comment section, and also welcome to share today’s content with friends around you. See you in the next lecture!

In the first two lectures, we completed the first round of enterprise-level divergence and convergence in the D4 model through Discovery combined with Define. Standing at the height of the enterprise, based on the enterprise vision and internal and external environment, we determined the final platform-based enterprise architecture through top-down strategic decomposition and bottom-up current situation investigation, and then applied enterprise architecture analysis methods to answer questions such as whether to build a middle platform, what types of mid-platform buildings are needed, who should build first and who should build later.

Starting from this lecture, we will enter the second round of divergence and convergence of the D4 model. From the perspective of a mid-platform product, let’s take a look at how to design and implement it, which is the two stages of Design and Delivery in D4. Similarly, this lecture starts with Design. We will use the design and implementation of a Central Product Platform as a sample to explain the ideas and key points of this stage.

Okay, at this point, we still need to borrow the example of Geek Real Estate.

We assume that after the first round of enterprise-level research and architecture design, Xiao Wang and his team found an urgent need to build Geek Real Estate’s own Central Product Platform to achieve the company’s strategic goal in 2022, which is to transform from heavy asset business to light asset service business, and better provide multi-scenario services for Geek Real Estate’s client base, that is, IT practitioners.

So the next question is, how should we build the Central Product Platform? And where should we start building the Central Product Platform?

In this class, let’s discuss the specific design and launch issues of the middle platform together. In the current example, it is the design process of Geek Real Estate’s Central Product Platform (hereinafter referred to as Geek Middle Platform).

During the design phase, the questions we need to answer are: what is the vision of the geek middle platform? What does it include? Where does it start to be implemented? After completing the design phase, we should have a clear idea of how to start mid-platform building, which can allow the team to start developing the middle platform MVP. If you are not sure what MVP is, don’t worry, it will be introduced later.

# Determine the vision of the middle platform product

By now, you must know that the first step is to clarify the vision and goals of this Central Product Platform, because this is the foundation of our entire mid-platform building process and the original intention of mid-platform building.

Do you remember what we mentioned before? The construction of the middle platform is a road full of thorns and twists and turns. We will encounter various problems and choices during the process. A good vision for the middle platform can help us always maintain our original intention and not easily lose our direction.

So how can we develop a good vision for the middle platform? When I go to a company to do consulting related to the middle platform, the first question I ask the person in charge of mid-platform building is: You said you want to do the middle platform, what is the vision of mid-platform building?

Most of the answers I received were positive, after all, no one would admit that their project doesn’t even have a goal or vision. But once asked what the specific vision is, it usually starts with a long narrative, from the company’s history to the current situation, from industry discussions to recent speeches by the company’s management. In short, my summary is: if the leader says we want to do the middle platform, we will do it.

I think this is quite dangerous. After all, as we mentioned earlier, the vision of the middle platform, as the starting point of all problems, needs to be simple and clear enough to become a tool that guides the direction of our mid-platform building process like a Compass, and also to achieve the “look at the vision when in doubt” mentioned earlier.

Here is a simple and useful tool that we often use to help us diverge and converge our product vision. Of course, it is also applicable to the middle platform, which is the Elevator Pitch.

As the name suggests, the elevator speech assumes a scenario where we encounter the company’s management on the elevator and can explain to them clearly what we are doing, such as the middle platform, within a limited time. This requires us to be sufficiently restrained. Therefore, the form of the elevator speech mainly limits several key factors of the product, such as who the user is, what problems they solve, and what the differentiation characteristics are. Each element is very important. If you cannot answer or the team’s answer is different, it reflects to some extent that everyone has not yet reached a consensus on the vision of mid-platform building, which will lay the foundation for the emergence of various problems in the future.

Don’t underestimate such a small elevator speech. It feels like answering a few questions is enough. From my actual experience, every discussion on planning the mid-platform product vision will exceed the time limit. At first, I thought it might be such a simple thing that could be done in an hour. Later, because the discussion was too intense, the time expanded to half a day. Now, we usually reserve half a day or even a whole day to fully diverge and converge the mid-platform product vision.

But even though we have spent so much time, I still think it is very necessary. It is worth spending more time on discussing the vision, because it will affect the future direction of our mid-platform design and construction. Once formed, it will become the foundation of our mid-platform building. The importance of this step cannot be overemphasized.

Here is a question that needs to be mentioned. The value and difficulty of vision lies in full convergence But I have seen many companies’ visions, although they also use elevator speeches, but the result is full of walls. Although it looks shocking, the effect is actually greatly discounted. After all, we cannot repeat the content of a whole wall in one elevator time. As the saying goes, addition is easy, subtraction is difficult.

# Determine the scope of business consolidation

After the vision of the middle platform product is determined, the next step is to sort out the business architecture of fine grain, extract commonalities, and identify the specific needs of the middle platform product.

However, for the same enterprise-level reasons, the problem we often face is not knowing where to start. After all, the middle platform has enterprise-level attributes. Even if it is business sorting, it will involve the entire Line of Business of the enterprise, and it is an end-to-end and full-process sorting work. The workload is often daunting.

Do all Lines of Business need to be sorted out? Do all stages of end-to-end need to be sorted out? What level of granularity does business sorting need to reach? These are frequently faced issues.

Generally, the situation of different companies is different here. If the overall scale of the company is not particularly large, it is also possible to do end-to-end business sorting for the entire business. The advantage of this is that it is more comprehensive and less likely to be missed. It can have an overall picture of the business status of the enterprise, and the identification of common middle platform needs will also be more accurate.

However, many enterprises, especially those with the highest demands in the middle platform, are often large conglomerates with multiple Lines of Business. For enterprises of this scale, it is basically impossible to do end-to-end sorting of the entire business, otherwise just coordinating personnel will be a troublesome problem. At this time, we need to first determine a scope, and then carry out business sorting and development within this scope.

So how should this scope be defined? As the saying goes, when in doubt, look at the vision. This is where the mid-platform vision we discussed earlier comes in handy.

Taking Geek Real Estate as an example, the vision of mid-platform building is to quickly achieve lightweight transformation of the business through the ability to reuse mature business capabilities and reuse them in other new types of light asset Line of Business, such as long-term rental apartment business (specific elevator speeches will not be elaborated here).

Currently, Geek Real Estate focuses on serving the IT community, and its real estate and property businesses have matured with a very sound IT infrastructure. There is a strong demand for long-term rental apartments targeting this group, but as a new Line of Business, long-term rental apartments start from scratch in terms of investment expansion, design, inviting tenders procurement, engineering construction, decoration and renovation, customer management, and property operation.

Returning to the issue of business organization scope, with a clear vision, we can make our business organization more focused.

First of all, from the perspective of business lines, not all Lines of Business need to be sorted out. Let’s take Geek Real Estate as an example. Its subsidiaries have a wide range of interests, and Line of Business focuses on investment, culture, education, etc. Because these Lines of Business have long-term independent development and are not directly related to the vision and goals of Geek Real Estate’s mid-platform products mentioned earlier, they can be skipped directly.

Then comes the end-to-end business Value Chain. Through analysis, since the company’s strategy is to serve light assets, it is not applicable to the construction of projects in the real estate industry, that is, the part of building buildings and houses, and the new business based on the company’s light asset strategy investment, so there is no need for further sorting.

Based on the vision of the middle platform construction, we can converge into a focused area in the horizontal end-to-end Value Chain and vertical business lines.

Further business sorting and development in this focused area will be more efficient and focused.

# Finishing of fine grain business

After determining the scope of sorting, the next step is the specific business sorting work.

Generally, everyone’s approach is based on existing processes or systems to sort out the existing business processes, such as the four flows often mentioned in the field of e-commerce, which specifically refers to the sorting work of information flow, business flow, capital flow, and logistics. The tools used are mostly flowcharts , which are very mature tools.

However, this kind of sorting based on existing processes sometimes has some limitations. Simply put, it may deduce pseudo-middle platform requirements based on past business debts. What does this mean? It means that for some long-term and mature businesses, the existing business methods may not be the best way, but rather the product of long-term development and compromise with various peripheral and IT restrictions in the past.

For example, Line of Business, which usually takes a long time, will have a very complex approval and review process. However, the review and approval process is actually just a solution. The problem to be solved may be process fraud or other internal risks and problems. Complex approval processes are often the product of process control in the information age or even earlier paper age. Since information technology only digitizes offline processes, it has continued to this day. In order to highly replicate and restore the process of the paper age, various strange approval logics, such as countersigning, have emerged with Chinese characteristics.

However, if we return to the problem domain and rethink the problem itself, we will find that in today’s digital age, where Big data and AI are widely used, there may no longer be a need for process approval. Through new technologies, we can use real-time audit analysis or risk identification to discover some anomalies in business processes, and even completely automate and eliminate the involvement of intermediaries, fundamentally solving these problems and truly unleashing the power of digitalization.

This kind of thinking method of returning to the problem domain itself, returning to the origin of the problem, and redesigning the solution based on the user request under the current business and technical conditions can avoid the business debt trap mentioned above, and is also mostly used in innovative business. The design process, and this way of thinking also refers to and borrows a lot of design thinking methods.

Therefore, unlike the traditional business process sorting based on the status quo, we have adopted a large number of methods based on design thinking , combined with User Experience Map (User Journey Map) and Service Blueprint (Service Map) in the process of business sorting. Returning to the business itself, starting from the problem domain, user-centered, User Experience design and business service blueprint sorting are also very good in terms of effect.

Of course, it’s not about which method is better. Different tools and methods have different applicable scenarios and advantages and disadvantages. If they can be flexibly mastered, they can even be used in combination to fully leverage their respective advantages.

By sorting out the business architecture within the scope, combined with the analysis of cross-scenario general capabilities, we can have a certain in-depth understanding of the business overview of the focus area, and identify some business data, business functions, and business processes that can be reused in different Lines of Business. These general business data, business functions, and business processes are processed and analyzed to form the specific requirements of the middle platform. For these requirements, we describe them through User Story (User Story).

# Determine MVP

Through business sorting, we have identified and organized a large number of Central Product Platform requirements. It is worth noting that the so-called middle platform product requirements at this time are more derived from qualitative abstraction. Considering that the requirements of the middle platform are often not as clear as those of the front-end business system, strictly speaking, the requirements at this time still belong to a series of high-risk assumptions.

From the mid-platform building projects I have actually participated in, it is often the case that the mid-platform requirements initially envisioned deviate greatly from the original expectations after the actual development is completed. This means that the longer the mid-platform building cycle, the greater the risk and cost of the assumed requirements.

Therefore, in the process of building the middle platform, we introduced the MVP principle (Minimum Viable Product) in Lean Startup, and also implemented the Start Small in the overall principle I mentioned earlier.

In order to achieve MVP and ensure that the MVP produced is usable, we adopt an end-to-end vertical segmentation method for business requirements, combined with multi-dimensional scoring and sorting of requirement priorities, to ultimately determine the scope of MVP requirements. The final form of implementation may be the first iteration of the User Story list.

Now that we have a specific User Story list, can we start developing it? Don’t worry, there are two things we suggest considering before starting mid-platform building, which are operational plans and metrics.

# Operation prerequisites: Develop iteration plans and access plans

First, let’s take a look at the operation plan. For the middle platform, it may be the promotion of middle platform products, the front-end (user) access plan, and the operation support after access.

What I have seen in the past is that it is often too late to start considering these issues in the middle and later stages of mid-platform building. Moreover, in many cases, the front-end will not stop and wait for mid-platform building to be completed, and then start their own business evolution after integration, so it is often the front-end and middle-end parallel.

This process is very similar to branch development in our development, modifying the same piece of content, so it will be very painful when merging.

Therefore, it is crucial to consider the operation plan, especially the access plan, in advance, and try to use a reasonable access plan (I have seen many companies call this access plan the on-board plan, which is very vivid) to avoid some risks, which is also crucial for the construction of mid-platform products. The specific operation strategy will be introduced to you in the next article.

# Metric Prerequisites: Define Validation Metrics

Another thing that needs to be clear before the mid-platform product construction starts is the measurement index. I don’t know if you remember this, but we have already talked about the four questions that need to be clear before mid-platform building. The specific reason why it is necessary to design the measurement index before development has been explained before. Here, I will share some design ideas for the measurement index with you.

First, let’s take a look at the commonly used indicators. I have divided the most common product measurement indicators on the market into four categories: strategic, user, market expansion, and cost reduction and efficiency improvement. Based on each dimension, many commonly used measurement indicators can be found.

As for the middle platform, the difficulty lies in the fact that there is still a front-end layer between it and the market and users, so the measurement is not as clear as the front-end system that directly contacts users. However, we say that the middle platform is empowering the front-end business, and it cannot be separated from the business. Simply measuring some technical aspects, such as interface stability and interface quantity, does not conform to the positioning and value of the middle platform for business support empowerment.

Therefore, when considering the measurement indicators of the middle platform, we generally take strategic value and business value as the starting point, start to break down and deduce, and use multi-dimensional and multi-level indicator design to examine the effect of mid-platform building according to the different concerns of stakeholders. It should be emphasized here that although the dimensions and perspectives are different, we must ensure that the mid-platform building goal reflected by all indicators must be the same.

As for the specific implementation method, it is difficult to give a standard answer because each middle platform product is different. In the practical operation process, it is recommended that you think more from the perspective of others and ask more “how” questions. I believe you are familiar with the 5Why analysis method. Here we can slightly modify it and use 5How to drive the design of verification indicators.

For example, if I stand from the perspective of the company’s management:

• So how do I judge the results of mid-platform building? If the answer is to empower new businesses,
• So how do I verify the effectiveness of empowering new businesses? If the answer is to look at the launch speed of new businesses,
• So how do I verify the launch speed of the new business? If the answer is to look at the time from project approval to launch of the new business,
• Then how do I verify…

You see, people often say that measurement is difficult. In fact, everyone has a scale in their heart, but we just haven’t expressed it clearly. Through 5How, we can constantly ask questions and discover this scale in everyone’s heart to better guide the construction and promotion of our mid-platform products.

# Summarize thinking

This lesson takes the construction process of a Central Product Platform as an example. Taking the vision of the Central Product Platform as the starting point, it introduces the tools for elevator speeches. Then, based on the mid-platform building vision, it clarifies the scope and priority of business sorting.

After clarifying the entry point and scope of business sorting, we can carry out user-centered business process sorting and service design based on design thinking, combine domain-driven design for business model sorting, and finally identify the middle platform requirements of common business data, business processes, and business models through cross-Line of Business comprehensive analysis.

Afterwards, by introducing the MVP principle from Lean Startup, end-to-end vertical segmentation is adopted based on business priorities for mid-platform requirements, and the starting point of mid-platform building is finally determined, which is the specific construction content of the first phase.

Finally, with the analysis and design of the product operation mechanism and measurement indicators in the middle platform, we can officially initiate the project and enter the delivery stage for specific implementation.

In the next lecture, we will officially enter the final stage of D4, which is the delivery stage of Delivery. Let’s take a look at the ideas and methods we use in the delivery stage, as well as the issues we need to pay attention to.

Finally, I’ll leave you with a few thought-provoking questions:

• What is your business sorting process like? How are the middle platform requirements analyzed?
• Have you adopted the MVP principle? How do you avoid the hypothetical risk of mid-platform building?

Please write down your thoughts in the comment section and discuss with me. You are also welcome to share today’s content with your friends and learn together. See you in the next lecture!

In the previous two lectures, I took you through the development process of the middle platform from a time perspective, and also introduced various middle platforms that have appeared on the market from a spatial perspective.

You must be a bit confused by so many types of middle platforms now. Can these middle platforms be called middle platforms? It feels no different from the platforms you have been working on before, right?

This is also a question that I have been constantly asking myself in my heart for the past few years. As the last article of the concept section, I will try to take you out of the dimension of time and space to analyze why companies need to build a middle platform. When we talk about the middle platform, what are we really talking about?

# Why do companies need to build a middle platform?

Let’s first look at why companies need to build a middle platform. To answer this question, we need to first solve another question, which is why companies need platformization?

Why do companies need platformization? Here’s my answer:

Because in today’s internet era, users are the center of the business battlefield. In order to quickly respond to user needs, leveraging the power of platforms can achieve twice the result with half the effort.

The logic behind this is simple: constantly responding, exploring, exploring, and leading users’ needs is the key factor for enterprises to survive and continue to develop.

Those companies that truly respect users and even adjust or overturn themselves to respond to users will survive and develop in this user-centered business war. Conversely, those companies that are complacent about past achievements and hope that users will continue to follow them as before will be eliminated by users.

It’s cruel, but this is the most basic corporate survival rule of this era.

The reason why platformization is important is that in this user-centered modern business war, it endows or strengthens the most core ability of enterprises: user responsiveness . Platform Thinking encourages enterprises to constantly abstract and precipitate their core underlying capabilities. Through platform packaging, it can better empower front-end business and help enterprises cope with the uncertainty of front-end business and end-user requests with the certainty of the underlying layer.

From the results, it can be seen that in today’s uncertain business battlefield, the real trendsetters are mostly those enterprises that have platform thinking and have started to focus on platform construction early on, which also proves the importance of platform for a company to some extent.

Okay, now we understand the first question: why do enterprises need platformization? However, platformization is not a new concept, and many enterprises have been working hard and accumulating in this direction for many years. So why has the relatively new concept of “middle platform” emerged in recent years? For enterprises, why can’t the traditional "front-end + back-end (or platform) " platformization architecture meet their requirements?

This brings us to our core question: Why do companies need to build a middle platform?

Similarly, give me the answer first:

Setting up functional teams is the next stop of platformization. It is a process in which the platform continuously evolves its own governance, breaks through technical boundaries, gradually embraces business, accommodates business, and has stronger business attributes. The middle platform focuses on empowering front-end business, truly born for the front-end.

In order to explain my point more clearly, it is necessary to first define what front-end and back-end refer to in the context of today’s discussion.

• Front-end: A front-end business platform composed of various front-end systems. Each front-end system is a user touchpoint, mostly directly used by enterprise end-users, and is the intersection between enterprises and end-users. For example, websites, mobile apps, WeChat official accounts, Mini Programs, etc. directly used by users belong to the front-end category.
• Backend: A backend support platform composed of backend systems. Each backend system generally manages a type of core resources (data + computing) of the enterprise, such as financial systems, product systems, customer management systems, warehouse logistics management systems, etc. These systems constitute the backend of the enterprise. (After chatting with many friends in the Internet industry, many Internet companies do not have the concept of backend, and more directly use the concept of platform, such as dividing it into the front-end layer and the platform layer, but the position and function are similar to the backend in traditional enterprises. Here, I directly use the concept of backend to represent it.)

After defining the front-end and back-end, let’s come back to the question of why enterprises need to build a middle platform.

We see that many companies’ back-end systems were not primarily designed to serve business innovation in the front-end system, but rather to achieve electronic management of back-end resources and solve the efficiency problem of enterprise management. These systems are either software packages purchased at a high price in the past, requiring a large amount of service fees to be paid annually, and some versions are already very old, making customization difficult; or they are self-built at a high cost, with long-term disrepair and patches all over them, making it difficult to change and basically impossible to change. They are also the so-called “legacy systems” of enterprises.

It can be said that for most enterprises, the existing backend either cannot be used by the front-end, is not user-friendly, or cannot keep up with the pace of front-end business development. In summary, it can be summed up in two words: “slow” and “expensive”. The response to business is slow, and it costs a lot of money to change small functions.

Some people may say, you can’t bring up legacy systems, we can create a new backend system, the whole 2.0, won’t the problem be solved?

This is a problem-solving approach. However, even for newly built back-end systems, because the back-end management is often the key core data of the enterprise, considering restrictions such as enterprise security, auditing, compliance, and laws, such systems are often unable to be directly used by the front-end system, or are subject to various restrictions and cannot change quickly, and cannot support the rapid business innovation needs of the front-end.

At this time, the front-end and back-end are like two gears with different speeds. The front-end needs to respond quickly to the needs of front-end users, emphasizing rapid iteration and innovation, so the faster the speed, the better. The back-end, on the other hand, faces relatively stable enterprise core back-end resources, often with outdated and complex systems, and even subject to compliance constraints such as laws, regulations, and audits. Generally, stability is the top priority, and the slower the speed, the safer it is.

Therefore, with the continuous development of enterprise business, the problem of “unbalanced matching” of “front-end + back-end” gear speed has gradually emerged.

With the continuous development and growth of enterprise business, the cost and risk of back-end modification are increasing. This drives us to try our best to maintain the stability of the back-end system, but at the same time, we also need to respond to the continuous needs of users. What should we do? The most natural way is to directly stuff a large amount of business logic (business capabilities) into the front-end system, because the front-end is close to the user and the response is relatively fast.

However, this also comes at a cost. The consequence is the introduction of duplication, which also leads to the continuous expansion and bloating of the front-end system, forming a “chimney-style single application” of large mud balls. The result of this situation is that the “user responsiveness” of the front-end system is gradually worn down, the Customer Satisfaction Score gradually decreases, and the competitiveness of the enterprise also continues to decline.

Gatner released a report in 2016 titled “Pace-Layered Application Strategy” to address this issue. The report proposed a solution, which is to divide the enterprise’s application system into three levels based on “pace” (which coincides with the three levels of front-end, middle-end, and back-end), and adopt completely different strategies for each level.

The Pace-Layered Application Strategy also provides theoretical support for the inevitability of the “middle platform”.

In this report, Gatner proposed that the systems built by enterprises can be divided into three categories from the perspective of Pace-Layered: SOR (Systems of Record), SOD (Systems of Differentiation), and SOI (Systems of Innovation). Each type of system has a different rate of change, so it will also have different lifecycles, suitable for different technical architectures, different development processes, and even different investment models.

Going back to the two-layer architecture of the backend and frontend mentioned earlier, if mapped to this model, it is actually a two-layer application architecture with only SOR (backend) and SOI (frontend). In this case, we also need to try our best to maintain the stability and reliability of the backend (SOR) system, and the frontend system (SOI) should be small and beautiful, and iterate quickly. Therefore, the problem of “gear matching imbalance” mentioned earlier naturally arises, and it feels like we can’t have our cake and eat it too.

What to do? The SOD in Place-Layered is the answer. It provides stronger stability than the front-end (SOI) and higher flexibility than the back-end (SOR), finding a wonderful balance between stability and flexibility.

The middle platform is SOD. With this layer of “middle platform”, we can “sink” the stable and universal business capabilities in the already bloated front-end system to the middle platform layer to help the front-end lose weight and restore its responsiveness. We can also “extract” the business capabilities in the back-end system that need to change frequently or be directly used by the front-end to the middle platform layer, giving these business capabilities stronger flexibility and lower change costs. Alternatively, we can directly transform the back-end by setting up functional teams, accelerating the back-end through configuration, self-service, visual operation, and other forms, thus providing the front-end with more powerful, faster, and easier-to-use “capability artillery” support.

The middle platform is like a set of “gears” added between the front-end and the back-end, matching the speed of the front-end and the back-end, serving as a bridge and lubricant between the front-end and the back-end. It is born for the front-end, easy to use by the front-end, and smoothly directs back-end resources to users, supporting enterprises to better respond to users.

Okay, now we can summarize and answer the question of why enterprises need to build a middle platform. It’s simple. In the process of platformization, enterprises need to build their own middle platform in order to continuously provide better services to front-end business, support continuous response to users, and increase user responsiveness.

# Define the middle platform

After talking about the ins and outs of the middle platform and various forms of expression, as well as my understanding of enterprise platformization and setting up functional teams, you may still feel that it is quite abstract, so I think we must try to define the middle platform.

Why do I need a definition? It’s not for any other reason. I think I need to give myself a simple ruler so that I can easily remember the characteristics of the middle platform and use it to quickly judge whether a so-called middle platform meets my understanding of the middle platform. Therefore, my definition of the middle platform is:

Enterprise-level capability to reuse the platform.

It’s simple, are you a little disappointed? But in order to find a definition that I think is reliable, I spent almost two years. During this period, various definitions have emerged, but at least so far, I think only this definition is the most appropriate, simplest, and accurate. It can explain almost all the problems I have encountered about the middle platform, such as:

• Why are there so many mid-platforms?
• What is the difference between setting up functional teams and platformization?
• What is the difference between setting up functional teams and service-oriented?
• How to build the middle platform?
• ……

These 9 characters may seem simple, but what’s important is the interpretation of the value of “middle platform” behind them. Let me break them down for you one by one.

1. Enterprise level

Enterprise-level defines the scope of the middle platform. It does not mean that an enterprise can only have one middle platform, nor does it mean that a middle platform can only contain one enterprise. Enterprise-level represents the problems that the middle platform handles at the enterprise level, which means at least including multiple Lines of Business or serving multiple front-end products (teams). If a middle platform only supports one Line of Business or product line, it is not a middle platform, even if it uses service-oriented or Big data technologies.

Enterprise-level is very, very important. It made me realize that mid-platform building is not a technical issue, but a problem that needs to be elevated to enterprise architecture. When doing mid-platform building, we must step out of a single Line of Business and look at the business panorama from the perspective of the entire enterprise.

After thinking this through, my understanding of the middle platform has undergone a qualitative change, and I finally understand why using a system service-oriented approach to do the middle platform at the beginning would face so many problems, such as the most common issues of organization and management, as well as interest redistribution.

We can also see a trend in the rise and explosion of the mid-level platform, that is, more and more enterprises, whether they want to improve their own Operational Efficiency or meet the needs of business innovation and development, have accumulated the ability of enterprise global perspective and cross-Line of Business to an unprecedented strategic height.

2. Capacity

When it comes to the middle platform, the most commonly heard word is “ability”. This may be because the word “ability” is simple enough yet has enough tolerance and breadth.

The ability defines the main objects that the middle platform carries.

The abstraction of ability explains why there are so many types of middle platforms, and also explains why the middle platforms of each enterprise are different. The reason why different enterprises can coexist is because their core capabilities are different, which can meet the needs of users at different levels, that is, what we often call differentiated competitiveness.

3. to reuse

To reuse defines the core value of the middle platform and carries the evolution process from platformization to setting up functional teams mentioned above. Traditional platformization has not paid enough attention to “reusability” and “ease of reuse”, but more attention to how to eliminate duplicate capacity building, also known as “deduplicate”.

However, the proposal and rise of the middle platform reflects a trend of paying more attention to the user experience of front-end business. People shift their focus from the internal construction of the platform to the support of front-end business by focusing on “reusability” and “ease of reuse”. There is a shift from the perspective of governance to empowerment, from “deduplicate” to “to reuse”.

Deduplicate “and” to reuse “often appear together and are mentioned together, but they are talking about completely different things, with different purposes and difficulties.” Deduplicate “talks more about looking backwards and being technology-driven, while” to reuse "talks more about looking forward and being business-driven and user-driven. I think this shift in perspective is the key to understanding the concept of the middle platform, so

• “To reuse” is the goal that the middle platform pays more attention to.
• “Reusability” and “ease of reuse” are important metrics for measuring the quality of mid-platform buildings.
• Business responsiveness “and” business satisfaction "are important criteria for assessing the progress of mid-platform building.

This also explains why many Internet companies refer to the process of platform governance as the set up functional teams transformation process through business abstraction, configurability, and white screen transformation.

4. Platform

The platform defines the main form of the middle platform. Different from the traditional way of piecing together application systems, the middle platform realizes the flexible reuse of enterprise capabilities through the identification and platformization of finer grain capabilities, better supports front-end business, and meets the needs of quick response and reuse for business.

Although the definition of " enterprise-level ability to reuse platform " seems simple, after such a long time of practice and thinking about the middle platform, I think the meaning behind this definition is currently the most appropriate interpretation of the value of the middle platform.

• " Enterprise-level " defines the scope of the middle platform, distinguishing between service-oriented and microservices of a single system;
• " Capability " defines the main carrier of the middle platform, and the abstraction of capability explains the existence of various middle platforms;
• " To reuse " defines the core value of the middle platform. Traditional platformization has not paid enough attention to ease of reuse and front-end User Experience. The proposal and rise of the middle platform allow people to shift their focus from the internal design of the platform to the support of the front-end business through reusability.
• " Platform " defines the main form of the middle platform, which is different from the traditional way of piecing together application systems. Through the identification and platformization of finer grain capabilities, it realizes the flexible reuse of enterprise capabilities and better supports front-end business.

# Summarize thinking

Today we started with why enterprises need platformization and discussed why enterprises need to build a middle platform. Combining the content of the previous two lectures, I gave my opinion. I don’t know if it has inspired you, but let me summarize it again in the end.

User-centered continuous large-scale innovation is the core goal of mid-platform building. The user response ability and large-scale innovation ability of enterprises are the core embodiment of the comprehensive competitiveness of enterprises in the Internet era. Platformization, including setting up functional teams, is only a means to help enterprises achieve this goal, not the goal itself.

The construction of the middle platform (whether it is a technology mid-platform, Central Product Platform, or organizational middle platform) is fundamentally to solve the dilemma of enterprise responsiveness, to make up for the contradiction between the front-end that needs rapid changes for innovation-driven and the back-end that needs relatively slow change cycles for stable and reliable driving. It provides a middle layer to adapt to the speed problem of the front-end and back-end, connects and smoothly links the front-end requirements and back-end resources, and helps enterprises continuously improve user responsiveness as a whole.

Therefore, what the middle platform is is not important at all. The most important thing is to find ways to continuously improve the responsiveness of the enterprise to users. Platformization or setting up functional teams just happen to be on the right track.

Finally, we gave a definition to the middle platform, which is " enterprise-level ability to reuse platform ". With this definition, we can not only use it as a ruler to measure whether a middle platform is genuine, but also have a clear idea of how to build a middle platform.

Because if “the middle platform is the platform for enterprise-level capabilities to reuse”, then “set up functional teams” is also "the process of using platform-based thinking and means to sort out, identify, precipitate and to reuse enterprise-level core capabilities ".

Okay, from the next lecture, we will officially enter the landing section. Let’s take a look at how we plan and implement the middle platform.

Finally, I’ll leave you with a few thought-provoking questions:

• Does your company really need a middle platform?
• If you were to define the middle platform in one sentence, how would you say it?
• Is the middle platform the solution or the problem itself in your company?

As of now in 2019, if there are any hot topics in the IT industry, then the middle platform will definitely occupy a place. It’s like any company or news related to the middle platform will attract attention for a while. If something is not related to the concept of the middle platform, it seems to fall behind the times.

The middle platform has become one of the focuses of attention for a while.

But what exactly is Zhongtai? The answer is still unclear and vague, and many people are still pondering whether this concept has its own significance and whether it is another hyped concept, just a flash in the pan.

I sorted it out. In the past half year of 2019, not counting the ones I have read, I have collected no less than 300 articles related to the middle platform. Recently, for this course, I reviewed all the content again and found that each author has their own perspective and viewpoint on the middle platform in each article. Even now, the industry is still unable to completely unify and there are still different opinions. However, it is gratifying that there is more and more consensus in many aspects, and the concept of the middle platform is slowly fading away its mystery and coming to us.

And this is also the reason why I am interested in taking this course. In recent years, I have been working full-time on mid-platform related work. I have had the privilege of personally participating in the mid-platform construction projects of many large-scale group enterprises as an architect and product manager. Therefore, I hope to take this opportunity to organize and summarize what I have seen and learned, and try my best to restore a panoramic view of the mid-platform for you, helping you understand the essence of this concept and trend.

I have always followed a viewpoint that in order to understand a concept or technology, one must first go back to history, go back to the time of its birth, walk through its development process, and explore the background and reasons for its emergence.

As the saying goes, one must know the reason why things happen.

Today’s content serves as the beginning of the main course. I want to take you back to 10 years ago, to the starting point of the birth of the middle platform. Let’s walk through the birth and development of the middle platform together with the pace of time. Let’s see where the middle platform comes from and where it will go.

# 2008~ 2015 Keywords: Pregnancy

The rise of the middle platform is a trend. However, the concept of the middle platform was first noticed by everyone and must be considered as the middle platform strategy proposed by Alibaba. I don’t know if you have noticed this, but there is an interesting point, which is why I said that the middle platform was first noticed by everyone because of Alibaba, instead of directly saying that the concept of the middle platform was created by Alibaba?

Since our column is called “Explaining the Middle Office”, we can say a little more here. Many people believe that the term “middle office” was created by Alibaba. However, as of now, there are still some different opinions and views in the industry on this issue, because there have been front-end, middle-end, and back-end divisions in banks for a long time. Interestingly, when Alibaba introduced the Alibaba dual middle offices at the 2019 Alibaba Cloud Ali Cloud Aliyun Summit in Shanghai, the English translation also used the translation of “middle office” in banks. However, there is currently no official information from Alibaba to confirm whether this concept is related to the middle office concept in the banking industry.

But for you and me, whether the term Zhongtai was created by Alibaba or indeed refers to an existing concept in the banking industry, I think it is not that important. We can focus more on what this concept is and how it can help us in the context of IT.

As for Alibaba’s middle platform strategy, it is generally believed in the industry that it started with Jack Ma’s visit to Supercell in 2015. However, after following the information shared by Alibaba and actually understanding it with many colleagues from Alibaba, I learned that this visit can only be regarded as a prelude. Alibaba’s process of setting up functional teams had already begun before this. Therefore, to truly understand the background and reasons for the emergence of Alibaba’s middle platform, we need to go back even earlier, at least to 2008.

Because in 2008, with the adjustment of Alibaba’s strategy, Tmall emerged. However, due to its own characteristics compared to Taobao, there was a problem of duplicate construction between Tmall and Taobao at that time, which is now commonly referred to as the chimney-style system architecture.

The chimney-style system architecture has caused a lot of duplicate construction and resource waste. What should we do? The most natural idea is to integrate the duplicate organizations and systems. Therefore, the Alibaba Sharing Business Unit was officially born, responsible for platform transformation of the public parts in various front-end systems. After a painful exploration, it took the opportunity of Juhuasuan’s outbreak to truly establish the important position of the Alibaba Sharing Business Unit and sow the seeds of Alibaba’s large-scale platform strategy.

# 2015 Keywords: Alibaba middle platform strategy born

History is like a train traveling between ridges, everything is moving forward in a predetermined direction at a leisurely pace.

The new species of Zhongtai is also constantly nurturing with the passage of time, waiting for an opportunity to come.

In 2015, this opportunity finally arrived.

Next is the story that everyone is talking about: In 2015, Jack Ma led Alibaba executives to visit Supercell, the world’s most successful mobile game company located in Finland. You may feel unfamiliar with this company, but when it comes to the games developed by this company, I believe you have heard of them. Famous games such as “Clash of Clans”, “Island Raiders”, and “Cartoon Farm” are all produced by this game company.

However, what touched Jack Ma and Alibaba’s executive team at that time was that the company that gave birth to so many globally popular games had less than 200 employees. Each team responsible for a game had an average of only 5 to 7 team members. The team had sufficient freedom to decide what kind of product to develop, and then the public beta version would be launched as quickly as possible for the market to judge and verify the quality of the product. Once the product failed, it was quickly abandoned. At this time, there would be no punishment, but the team would raise a glass to celebrate and immediately make adjustments to continue to quickly find new directions.

Hmm, yes, this is the typical routine of Lean Startup.

However, in order for this mechanism to operate normally, there must be a prerequisite, which is that the construction time of the product must be short enough, and the cost of trial and error must be low enough. Only in this way can the team ensure that through continuous learning from failures and continuous iterative adjustments in a large number of trials and errors, the correct direction can be found as soon as possible, and the innovative and successful Progress Bar can move forward quickly.

What supports this mechanism is the common and universal game materials and algorithms that Supercell has accumulated over 6 years in the game development process. Based on these basic materials and algorithms like Lego building blocks, it is possible to support several small teams to quickly develop a new game in a few weeks, just like building blocks.

This approach touched the visiting Alibaba executive team, and this concept coincides with the “thick platform, thin application” architecture direction that Alibaba and the industry have been trying and conceiving for many years. It was this visit that strengthened the Alibaba management’s determination to adjust the organizational structure and accelerated the formal birth of Alibaba’s middle platform strategy.

Shortly thereafter, on December 7th, 2015, Zhang Yong, then CEO of Alibaba Group, stated in an internal letter: “Starting today, we will fully launch Alibaba Group’s 2018 middle platform strategy, and build a more innovative and flexible’big middle platform, small front desk 'organizational mechanism and business mechanism that is in line with the DT era.”

With this, Alibaba’s middle platform strategy is officially born, and the previous “thick platform, thin application” has also become “big middle platform, small front desk”.

Interestingly, when Alibaba’s mid-platform strategy was first proposed in 2015, it didn’t cause much of a stir in my impression. At that time, people were still talking about Hua Qian Gu and “My Skateboard Shoes”, while the internet circle was talking more about Internet + and O2O. Little did they know, a new battlefield had already begun to breed, and the seeds had been planted.

# 2017 Keywords: Emergence

With the birth of the mid-platform concept in 2015, after a silent but turbulent 2016, we gradually began to hear more and more voices about the mid-platform in the community in 2017. Alibaba and Didi Chuxing coincidentally began to share their experiences in mid-platform building, and books related to the mid-platform also appeared on the market.

The collective voice of internet giants has brought the concept of middle platform back into everyone’s view after two years.

As far as I know, many companies, whether they are internet giants or some strategic enterprises, are starting to re-examine and attach importance to this emerging new concept at this point in time.

Most of the earliest companies to start their own mid-platform planning and construction also began at this time. It was also at that time that I became familiar with the mid-platform, paid attention to and studied it, and actually participated in the actual mid-platform projects of each customer.

However, at that time, everyone faced many problems and difficulties. Companies like Alibaba or Didi Chuxing shared their middle platforms from the perspective of their own development process and problems. There is no doubt about this, but when everyone looks back at their own mid-platform building, each company’s situation is different, and each company’s problems are also different. What should their middle platform look like? How to build it? Many of these questions cannot be directly answered in books or sharing, and can only be explored bit by bit by themselves.

At this point, some brave pioneers began their respective mid-platform exploration journeys, although this was destined to be a path full of thorns.

Looking back now, some of the explorations at that time ultimately failed, while others are still ongoing. However, in any case, the explorations and experiences gained and lost by these pioneers have cleared many obstacles for our current understanding and construction of the middle platform. Without these explorations and reflections, there would not be the current experiences and consensus.

# 2018 Keywords: Full Outbreak

In mid-2018, Zhongtai had been accumulating momentum for a long time and finally ushered in a comprehensive outbreak.

This is something I have personally experienced. I remember it very clearly. It was at noon on September 9, 2018, when my colleagues were all taking a nap on their desks. Finally, I took the opportunity to post an article that I had been holding back for more than three months to my official account as usual. This article is about my thoughts on the middle platform over the past year. In my opinion, it is an ordinary article.

What happened afterwards far exceeded my imagination. My article was reposted by various community accounts in the afternoon, and the reading volume quickly exceeded 10,000, 20,000, 30,000, 40,000… For me, who usually only has a few hundred views when writing articles, I was a bit at a loss. At that time, I felt that all my friends, friends of friends, and friends of friends were reposting this article from the platform.

That was also the first time I felt the heat of the middle platform. It had been accumulating momentum for a long time and finally ushered in its own outbreak.

But only this one big discussion is not enough. You may still remember what happened afterwards. Come, let me quickly review it with you.

• On September 30, 2018, Tencent announced its largest organizational change in seven years, establishing the Cloud and Smart Industries Group (CSIG). At the same time, Tencent established a new technology committee and announced that it will build a technology mid-platform in the future.
• On November 26th, 2018, Alibaba announced an organizational upgrade. The Alibaba Cloud Ali Cloud Aliyun business group was upgraded to the Alibaba Cloud Ali Cloud Aliyun Intelligent Business Group, fully integrating mid-platform intelligence with Alibaba Cloud Ali Cloud Aliyun.
• On December 21, 2018, JD.com Group Human Resources released an announcement regarding the organizational restructuring of JD.com Mall. The announcement stated: “Under the new organizational structure, JD.com Mall will be customer-centric and divided into front, middle, and back offices. The middle platform will provide professional capabilities for front-end business operations and innovation.”
• ……

It is precisely because of the dazzling collective operation of this wave of internet giants that they have all spoken out for the relay of the middle platform, officially pushing the middle platform onto the stage and ushering in a comprehensive outbreak.

# The fog of 2019 still exists

The popularity of the middle platform exploded at the end of 2018 and continued into 2019, showing no signs of fading, but instead increasing.

However, despite the outbreak, it does not mean that the previous problems have been solved. The problems and confusion still exist, and have not become clear due to the popularity of the concept. Instead, as more and more companies follow suit, the problems increase instead of decrease.

• What is the difference between the middle platform and the platform?
• How many types of middle platforms are there? Which ones are not? Is there a construction order?
• How to build the middle platform? Where to start? How to calculate the end?
• Does the middle platform need organizational adjustment? How to adjust?
• How to verify the construction effect of the middle platform?
• ……

And these issues have been troubling me for the past few years. Now, after such a long time of exploration, research, and learning from predecessors, I have some of my own thoughts and summaries. Now, I am sharing these contents with you to explore the answers to these questions and help you clear some obstacles in your mid-platform building.

# Summarize thinking

Today, I reviewed the development process of the middle platform with you. Finally, let’s see if we can answer the question at the beginning: Why is the middle platform so popular?

Just as many trends are not formed by a single force, I think the popularity of mid-platform is at least due to the combination of the following four aspects.

1. The model effect of Internet companies. This is beyond doubt. At present, the model and benchmark effect of Internet companies, especially major companies, is still very strong. What’s more, the attitude of Internet companies towards the middle platform is so highly consistent that it is rare in the past. The construction effect is also really visible to everyone, which makes people envious.

2. Why are Internet companies so unanimous in promoting the mid-platform? There is a deeper reason behind it. This year’s industrial Internet is booming. In the mid-to-late stage of consumer Internet, the battlefield on the consumer side is becoming increasingly white-hot. Internet companies have turned their attention to the supply side in order to pursue sustainable growth. This is why ToB is also unusually popular this year. The cloud and mid-platform strategy is a very good entry point for Internet companies to enter traditional industries. Therefore, we see more and more Internet companies participating in the process of cloud migration and digital transformation of traditional enterprises, bringing their own technologies and practices to traditional industries. Throughout the process, the mid-platform is indeed a good breakthrough point and weapon.

3. As the saying goes, it takes two to tango. This timing does indeed coincide with the transition of some industries from systematization to platformization. Through years of informatization construction and accumulation, the information systems that should be built in the enterprise have also been built, such as ERP, CRM, etc. The enterprises that started informatization construction earlier also began to experience pain points such as chimneys and data islands mentioned earlier in their internal systems. And the enterprises that started informatization construction relatively later also want to take a shortcut through this mid-platform wave and achieve it in one step. At this time, a whirlwind of mid-platform struck, and every enterprise felt the need and pain points of doing mid-platform, and began their own mid-platform planning and construction.

4. Finally, I think there is another very important and fundamental reason, that is, the overall economic trend in the past two years has not been very good. Uncertainty and unpredictability are constantly impacting various enterprises and even industries, and the fear and anxiety of enterprise managers about the future development of enterprises have doubled. At this time, Internet enterprises use the mid-platform strategy to precipitate and reuse their capabilities, use certainty to cope with uncertainty, and have the ability and ideas of rapid trial and error and rapid innovation, which allows traditional enterprises to see a breakthrough direction. When the economic situation is good, everyone is either busy expanding their business quickly and doing what they can quickly, or they are stuck in their mature business, harvesting on time, without strong motivation to change. But when the economic situation is severe, the pressure and fear are becoming more and more serious. In order to maintain the survival and sustainable development of the enterprise in the future, or to prepare for the next round of improvement, the mid-platform strategy has become the choice of more and more traditional enterprises and industries, following the example of the Internet industry.

In short, the so-called favorable timing, geographical location, and human resources have brought together various factors to give birth to this wave of mid-platform hotspots. Is the popularity of mid-platform just a flash in the pan? Or will it become another important milestone in IT development like Cloud Service and microservices? It is still uncertain, but I personally believe that the latter has a very high possibility.

Finally, I also want to know why you are interested in the middle platform. Why do you think the middle platform is so popular? What is your biggest concern about the middle platform now?

Looking forward to fully discussing with you in the column. You are also welcome to share today’s content with your friends. See you in the next lecture!

In the previous lecture, I introduced you to the overview and sources of our mid-platform building methodology. Starting from this lecture, I will take you through the four stages of our mid-platform planning and construction, introducing the goals of each stage and some commonly used tools and practices.

Okay, let’s start with the first stage of Discovery, which means we need to establish a “comprehensive perspective” on the enterprise and industry.

So why do we need to do this first? Let me add one more thing. In fact, the first two parts of D4, Discovery and Define, are a process of divergence and convergence at the enterprise level. Our company has a name for this process internally, called Portfolio Discovery, abbreviated as PD. In actual implementation, PD is a 4-8 week brainstorming workshop. The following figure shows a complete PD workshop roadmap to help you understand.

Regarding the overall planning of the middle platform, that is, answering questions such as whether to build a middle platform, which middle platforms to build, and who should build first and who should build later, we now evaluate and judge through the process of PD. You may have doubts about why PD, as a method, can help us make planning judgments for the middle platform. Here, we will briefly explain.

# Why use PD to plan the middle platform?

Portfolio Discovery is translated into Chinese as investment portfolio planning, which is equivalent to product line planning when applied in enterprises. To put it bluntly, if I am the CIO of a company and have a disposable IT budget of 100 million yuan this year, what I am most concerned about is in the next period of time (which may be 1 year or 3-5 years), in order to achieve the goal of enterprise development.

• How much money do I need to spend on digital construction?
• How should this money be spent? How should it be allocated? Which systems should be added, purchased or self-developed? Which systems should be eliminated? Which systems should be optimized? Which systems should be maintained? Which systems should be kept unchanged?
• Do you want to build a middle platform?
• ……

You see, to put it simply, it’s still a matter of how to spend money wisely. Essentially, it’s also a matter of quotas. How to find the best investment portfolio with limited resources, or how to spend money where it should be spent.

And building a middle platform is just one of the potential options. One of the potential solutions is to add a middle platform layer to the application architecture based on the enterprise’s strategy and current situation to solve the problems currently encountered by the enterprise.

Whether the mid-platform solution is suitable for enterprises or not still needs to be researched and judged. Therefore, if we take the mid-platform as a definite direction from the beginning, it will inevitably limit our vision, and we may miss better, simpler, and more effective solutions than the mid-platform, or over-design too early, and carry out mid-platform building in a scene where the mid-platform is not needed, which is a waste of time and money.

Should the company allocate a portion of the money and resources for mid-platform building? What is the value of adding a new architecture layer like a middle platform for the company? When is the best time to do it? What is the priority? These are also the questions that PD mainly focuses on and needs to answer.

In order to avoid impulsive situations, the main purpose of Discovery as a PD in the first half is to conduct sufficient divergence and research, that is, to use various tools and means to help us fully understand industry trends, competitor situations, company strategic decomposition, and bottom-up current situation research and other information and environment, in order to provide sufficient information support and basis for the convergence of the next stage of Define, that is, for the design of new business architecture, application architecture, technical architecture, and even organizational structure of the enterprise.

Overall, Discovery can be simply divided into three different directions: from outside to inside, from top to bottom, and from bottom to top.

# From the outside to the inside: industry and competitor analysis

Knowing oneself and the enemy leads to victory in a hundred battles. Before understanding ourselves in detail, it is necessary to broaden our horizons and see what the industry’s major trends and competitors are doing.

I remember that Teacher Liang Ning once mentioned the theory of “point-line-surface-body” in his column “30 Lectures on Product Thinking”. If the middle platform itself is just a point, then it may only be a product of a company’s development to a certain stage, not the beginning or the end. Therefore, we should look at the middle platform from the main line of a company’s development process and see where it comes from, why it appears, and where it will go. Even consider what the next stage of the middle platform will be and what it will be replaced by. I also look at it this way when observing the middle-platform building process of a company, including the formation and development of the entire middle platform trend.

Is having a line enough? Not enough. We need to take another dimension to see what other lines in the same industry, that is, what other companies in the same industry are doing? What are their strategies? What is the focus of digital construction? Are they also doing mid-platform building? What are the goals of the construction? What is the effect?

However, it should be noted that analysis does not necessarily mean direct reference. If others are building a middle platform, we should build one. This idea is not advisable because even in the same industry, due to differences in corporate vision, strategy, business model, customer base, etc., each company is different.

Finally, we need to step out and examine the industry itself from a higher dimension, or learn from other industries and aspects. There are generally two benefits to doing so.

• First, if there are good concepts or methods in other aspects, we can learn from them to help our own enterprises gain an advantage in their own industries. The concept of middle platform originated in the Internet industry and is currently being referenced and borrowed by various industries.
• Another benefit is that if you find a better surface and a better industry, you can realize the leap of the enterprise across industries, and you may seize the opportunity to enter another fast lane. That being said, at present, the purpose of many enterprises’ mid-platform building is to identify the core capabilities of the enterprise, sediment them into the middle platform, and use it as a springboard and support to carry out business innovation and exploration, so as to jump to another more promising new track.

After talking about the benefits of industry research and competitor analysis, how to do it specifically? In fact, the industry has many very mature methods that you can use directly, such as the common ones: Five Forces Model, SWOT, Business Model Canvas, Competitor Product Line Analysis, Competitive Situation Analysis Matrix, etc .

# Top-down: Corporate Strategy Decomposition

If the main output of PD is the blueprint and roadmap for digital construction, then the input of PD is the vision and strategy at the enterprise level.

We have talked a lot about vision before, which should be relatively easy to understand. It refers to the image or goal that we hope the company can become after a certain period of time. For example, in the case of Geek Real Estate, the vision may be to achieve the transformation of business from heavy assets to light assets by 2022. More specifically, the proportion of service business in total revenue should reach more than 70%.

Let me add one more thing here. We have indeed seen many companies start large-scale mid-platform building without a clear corporate vision. It’s like a fleet going out to sea without a clear destination, which may lead to being lost in the ocean and running out of ammunition. Therefore, if a company is in this situation, it must first supplement this part of the content.

Here, let’s assume that the company already has a clear vision and strategy as input for PD before starting the planning process.

Looking at the word “strategy” again, our understanding may seem vague and abstract. In the book “On Grand Strategy”, it is mentioned that “strategy refers to how to achieve a balance between goals and capabilities, and make appropriate adjustments according to environmental changes.”

Here is the strategic balance triangle that we often use, which can help you understand the relatively abstract concept of strategy.

Through this strategic balance triangle, we can simply make some mathematical transformations to explain what “enterprise strategic decomposition” really is. The following derivation process may be a bit brain-burning. If you can’t understand it at the moment, you can read it several times. I believe it will be very helpful for you to understand the word “strategy”.

Okay, let’s get started. Based on the strategic balance triangle, with the company’s vision and goals already determined:

• Enterprise strategy can be simplified to understand: combined with the enterprise’s own capabilities and the environment in which it is located, what measures need to be taken to achieve the enterprise’s predetermined vision and goals?
• And the enterprise strategy decomposition can be simplified to understand: combined with the ability of the enterprise departments themselves and their environment, what kind of measures need to be taken to achieve the enterprise’s predetermined vision and goals?

Okay, the deduction is complete. There are many tools and practices in the industry for decomposing corporate strategy, such as the corporate strategy analysis model designed by BMGovernance. However, in order to cope with the rapidly changing market environment, we use the Lean Value Tree tool in PD to help decompose the strategic vision.

Lean Value Tree is a value-based tool used to analyze and communicate business vision, strategy, and investment. Its core is to establish a top-down alignment from vision, goals to investment initiatives, so it adopts a hierarchical tree structure, as shown in the following diagram.

This process is what I call a top-down strategic decomposition process. For a certain middle platform, it may only be a specific measure that is ultimately derived. Upward, it still needs to be traced back to the relevance and value of the company’s vision and goals, and match and correspond to the company’s vision and goals.

# Bottom-up: Current Situation Research and Analysis

If we understand the decomposition of corporate strategy as a top-down analysis and deduction process from the corporate vision, can we simply implement the derived measures?

Often it is not enough, because every enterprise that has survived and developed in the market for a long time will encounter various problems and limitations. If they deviate from the status quo and ignore these problems and limitations, they will definitely face great resistance and risks.

Therefore, we not only need to decompose the enterprise strategy from top to bottom to help us think about whether it is necessary to take the middle platform or other measures, but also need to fully conduct bottom-up current situation research to help us understand the current situation and history. On the one hand, we fully respect all the problems encountered in the past, collect and summarize pain points; on the other hand, we are required to break free from past limitations, start from the business and users, and explore new possibilities based on new technologies and architectures.

Here we often use many tools and practices, such as high-level interviews, stakeholders maps, organizational structure analysis, strategic design thinking, business architecture status quo sorting, user journey, service blueprint, domain-driven design, application system status quo sorting, technical architecture status quo sorting, and so on.

Adequate and multi-dimensional current situation research and analysis not only allows us to have a comprehensive and clear understanding of the current situation of business, applications, technology, data, and organization, that is, the current situation of enterprise architecture, but also supplements the context of the timeline through interviews and research, including what happened in the past, why the current situation is like this, what kind of future everyone hopes for, and why.

However, there is one issue you may need to pay attention to here, which is the scope and depth of the sorting. Don’t forget that we are currently doing enterprise-level architecture sorting, and the width and scope may far exceed our imagination. If the depth is not well controlled, you will find that you are still spinning in a small field and Line of Business.

Therefore, in the face of such problems and risks, I suggest that you:

• First, complete the top-down decomposition of the enterprise strategy, and then conduct a bottom-up current situation investigation. After completing the strategic decomposition, we already have some understanding of the company’s industry, business, vision, and strategy. When conducting the investigation, we will have a global control, making it easier to grasp the granularity and depth.
• Make sufficient preparations and complete the content that can be completed in advance through reading materials and small-scale research.
• Make a detailed plan, and you can reverse engineer the scope and granularity of sorting according to the total time of the current investigation. If there is enough time, you can spend two days to sort out the business architecture of a Line of Business, so that the sorting can be deeper. But if there is only half a day, the granularity can be appropriately bolded to ensure that there is a global business view.
• It is suggested that at the beginning, the granularity can be coarser, and do not get too caught up in details too early. However, how to control the granularity does require a deep understanding of the company’s strategy and business, which is also the most effective part. When the judgment is not good, it can be coarser first. If there is still time in the end, another round of research can be conducted to expand further.

For a medium-sized enterprise with four or five different Lines of Business, it usually takes about 2-4 weeks to implement such a current situation survey, depending on the client. After completing the survey, we have a comprehensive understanding of the current situation of the enterprise in all aspects, and have also collected a large number of pain points and problems for each Line of Business, which provides a prospect for the future architecture.

When doing bottom-up research on various Lines of Business, the tools we use are not traditional business process diagrams, but are combined with the idea of design thinking, using the way of combining user journey with service blueprint . The specific content will be introduced to you when introducing the design process of a Central Product Platform in 08.

# Summarize thinking

So far, we have conducted industry analysis from the outside to the inside, competitor research, top-down enterprise strategy decomposition, and bottom-up investigation of various dimensions of the enterprise based on the current situation, and have made sufficient divergence to collect sufficient information.

We conducted the entire PD process (including the Define process to be discussed in the next lecture) in a workshop format, where relevant roles brainstormed and fully discussed together to produce the final result. The entire process was very lightweight and efficient.

After completing the first half of Discovery in PD, the next step is to analyze and integrate the collected raw material information to form a specific mid-platform building plan, which is the second half of PD, the process of Define. I will introduce it to you in the next lecture.

Finally, I’ll leave you with a few thinking questions:

• What is the vision of your company? What is the strategy? When it comes to your department, what are the measures?
• Does your company really need to build a middle platform? Can it match the company’s vision?