Mid-platform type: Is the mid-platform you heard really a mid-platform?

Mid-platform type: Is the mid-platform you heard really a mid-platform?

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

image-20240531115927027

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.

image-20240531115950952

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.

image-20240531120007964

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?
The fourth step of the middle platform landing: the construction and access of the middle platform (Delivery)

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?
The second step of the middle platform landing: Enterprise digital panoramic planning (Define)

The second step of the middle platform landing: Enterprise digital panoramic planning (Define)

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.

image-20240531120754749

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:

image-20240531120818425

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.

image-20240531120838144

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!