The fourth step of the middle platform landing: the construction and access of the middle platform (Delivery)

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?