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