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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Let me explain a little bit.

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

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

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

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

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

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

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

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

# Identifying commonalities through domain analysis

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

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

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

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

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

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

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

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

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

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

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

Don’t worry, listen to me slowly.

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

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

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

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

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

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

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

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

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

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

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

# Overview of Platform Enterprise Architecture Design

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

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

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

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

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

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

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

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

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

# Summarize thinking

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

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

My answer is very clear: very necessary .

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

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

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

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

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

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