07 | the second step of the mid platform landing: enterprise digital panoramic planning (define)

Last time , We go through Discovery From three different angles and directions , After collecting sufficient information about the internal and external environment of the enterprise , Got a lot of information . Let's talk about this , How to analyze and converge these information , Using an enterprise architecture approach , Finally, analyze and form the digital panoramic planning of the enterprise , And finally deduce that we PD An important product of , In other words, it is an evolution roadmap for the implementation of the middle platform .

First of all, I need to introduce you to what is Enterprise architecture approach .

Enterprise architecture approach

Enterprise architecture approaches such as Zachman、TOGAF etc. , The longest has been 20 Years of history , It's very mature . One of the most widely used should be TOGAF 了 , Occupy at least half of the market , And we know it best .TOGAF The basic idea of , It starts from the latest vision, strategy and operation mode of the enterprise , Design enterprise To-Be Business structure , Then deduce in turn , Step by step derivation of data architecture 、 Application Architecture 、 Technology Architecture , That's the process .

We are now doing the enterprise digital panoramic planning with the middle stage as the potential preset goal , Also for reference. TOGAF This idea , be based on Discovery Spread the information collected from all dimensions , stay Define At this stage, the problems and pain points combed and analyzed by combining the top-down enterprise strategy decomposition measures and the bottom-up existing business architecture , Redesign the new business architecture , And further deduce other related architecture design .

But compared with the traditional enterprise architecture method , The whole process has been cut and lightened , Introduced Event storm 、DDD Workshop And other forms of collaboration and interaction , The key roles in the whole process are fully discussed , Work together to create , Strive to make the process light , It can also ensure the accuracy and consistency of the results .

But here's a key point , As mentioned earlier, the middle office is a platform based enterprise architecture from the architecture level , Compare it with the systematic enterprise architecture we used to do in the past , From the perspective of the enterprise as a whole , More accurately identify common business elements among multiple business lines , It is also a new challenge for us .

To solve this problem , In fact, it was mentioned earlier when we talked about the overview of methodology , We have integrated domain driven design into the whole process of enterprise architecture design （DDD）, Combined event storm , Analyze the problem domain behind the business process , And through the analysis of problem domain coincidence degree of different business lines , Help us see the essence of each business through the process , Look for common business elements .

Give this process a metaphor , It's like taking a picture of the business B Super identical , Help us better see the inner essence through the phenomenon .

For the enterprise architecture approach , for example TOGAF There are a lot of relevant information about , It's not going to unfold here , I will give you some references in the final summary , You can further expand your reading .

Then use the rest of the space , I would like to focus on some common problems related to the middle office during the implementation of enterprise architecture design .

How many types of capacity are there for midrange multiplexing ？

The first question is , If the middle office is an enterprise level capability reuse platform , In the process of enterprise architecture design ：

• What kinds of common capabilities are we looking for in different business lines ？

• What exactly do we refer to in the business we often talk about ？

• Then why is the middle office usually a business 、 data 、 Technology is a combination of the three ？

To answer these questions , Let me show you a model first ：

This is Harvard University Press 2006 A business operation model mentioned in a book on Enterprise Architecture strategy published in （Business Operating Model）, It proposes two quadrants ：

• The horizontal axis represents standardization （Standardization）, The higher the Standardization , You can simply understand that an enterprise is a business model （ Business function + The business process ） To realize the extension of business lines . For example, the vertical websites of e-commerce websites , Or globalization , All through the reuse of e-commerce business models , By reusing to different vertical domains , Or the expansion of different business lines in different regions .

• The vertical axis represents the integration （Integration）, It can also be understood as data integration , The enterprise of this operation mode is through the reuse of data , To realize the expansion of business lines . For example, Tencent is the most common , Through the integration and reuse of wechat user data （ Diversion ）, To help new lines of business （ For example, games ） Expand quickly .

So why mention this model , Because of the “ Business operation model ” It is very similar to the capacity reuse method in our middle office , That is, what you reuse is the business model ; Business data is reused ; Or neither , It just reuses the lower level technology .

Let me explain a little bit .

If two lines of business , Data is also a set , The business process is the same , It is very simple , They can actually share a system , This is our most common large monomer system . But this is increasingly becoming an anti pattern , Except in some highly standardized scenarios , For example, the core financial system .

If between two different lines of business , The business model is very similar , But the data needs to be isolated , That's the lower right area . Generally, common abstract business processes can be precipitated through the business middle office , Or use multi tenancy directly within the enterprise SaaS To realize the reuse of business patterns . In this quadrant , Business center and SaaS The difference is only the difference of abstract granularity and level , In essence, the problems to be solved are the same , Business pattern reuse .

SaaS High level of abstraction , Closer to business , However, there are high requirements for business standardization , Low flexibility . The business is just the opposite , The level of abstraction is SaaS low , Be situated between PaaS and SaaS Between （ So many enterprises call their business as ApplicationPaaS, or BussinessPaaS）, Away from business SaaS Far away , But more flexible . This also answers the questions that many people are puzzled about SaaS Differential problem .

One more thing to say here , Recently, a kind of Headless Commerce（ Headless E-commerce ）, Last year there were also Headless CMS. I think this wave abroad Headless The trend of , It's very much like the middle stage in China , Also in PaaS and SaaS It's just finding a new level of abstraction .

good , With that, right down , Let's talk about the top left , It refers to those that although the business model is different , But through the integration of data 、 The scenario of realizing business line expansion by opening up and reusing , Generally, it can also be solved through the business middle office and the data middle office . Because there is also data carried in the business , In other words, what is produced in the business is business data .

As mentioned earlier , The data middle stage is the data produced by the business middle stage , Carry out secondary processing , For example, some big data computing 、 Cross domain business data integration computing or some AI Enabling scenario .

Okay , I hope that through the above analysis , Can help you understand these different platforms （ Including the business center , Data center , Technology Center , And the business center and SaaS, Business center and data center ） The concept and difference of .

And back to the beginning , What kinds of common capabilities are we looking for in different business lines ？ Now it is very clear , To sum up, there are basically four categories ： Business data 、 Business function 、 Business processes and common technical capabilities .

Identify common capabilities through domain analysis

Since the reusable capabilities of enterprises are the above four categories , That leaves aside the relatively independent technical ability , For the rest of the business data 、 Business functions and business processes are three common business capabilities , say concretely , How do we identify ？

Or take the example of geek real estate , For the property business line and the long-term apartment business line , On the surface, it seems to solve a completely different problem . However, this does not mean that there is no business data between the two business lines 、 Business function or business process reuse scenarios , For example, the most direct way is to connect the owner data of the property and the user data of the long-term apartment , Share through, for example, the simplest integration mechanism , To realize the transformation from property owners to long-term apartment users , Realize the diversion of users and the hot start of new services , Accelerate the rapid development of emerging businesses .

How can we identify similar scenarios of capability reuse through business processes ？ you 're right , Namely Domain-driven design （DDD）.

We are dealing with the business that has been sorted out , It goes deeper , Use Domain Driven Design in conjunction with event storms （EventStorming） These two tools , In the form of workshops, the Problem space and Solution space Do further analysis , Identify key aggregations , And then through the cross line of business Problem domain Superimposed projection , Find out the problem space and convergence of common concern , So as to continue to expand to identify common scenarios and capabilities .

I said a lot of words here , Like problem space 、 Solution space 、 Problem domain 、 polymerization , These are all DDD A common term for , Well understood. . If you're not familiar with it DDD, It is suggested to check it first and then come back . Yes, of course , At the end of the column, I will also recommend some relevant learning materials to you .

The whole process is also in the form of brainstorming and workshops .

Back to the example of geek real estate , Let's have a full discussion together , The event storm against the property business line and the long-term apartment business line , Combined with problem domain analysis and aggregation analysis of domain driven design strategy , We can know these two different business lines , What problem spaces are coincident , For example, the customer domain or part of the operation domain .

Then expand the problem domain , We can recognize that in these overlapping problem spaces , What are the common business data 、 Business functions and business processes , So as to complete the identification of reuse capability .

What are the differences and connections between the middle office and the micro service ?

Having finished the business , Let's talk about technology architecture design , Another problem that we are most concerned about and equally troubled by , That is, what is the relationship between the business platform and the microservice architecture ？ This is also a question often asked when talking about Zhongtai , At least until Top5 in , Just to the technical architecture , Let me talk a little about my understanding .

Give me my answer first ： It doesn't matter ！

Is it a bit counter intuitive , After all, these two concepts are often mentioned together , Many books on business platform also talk about microservices when talking about technical architecture , How do you say it doesn't matter ？

Don't worry. , Listen to me .

in general , In business, the platform and microservice solve different problems , At different levels of abstraction .

As mentioned earlier, the middle office of the business solves the business in the business field （ data 、 function 、 technological process ） The problem of reuse , Microservice architecture is a lightweight distributed technology architecture , The solution is in the field of technology “ Component compile time dependency ” Problems caused .

And the business platform is not necessarily a microservice architecture , Microservice architecture is not necessarily to solve the problem of capacity reuse .

First of all, let's look at the business center . The business middle office needs to solve the problem of how to quickly reuse business capabilities , Even if there is a big monomer behind it , As long as it is exposed API It is also possible to meet the purpose of rapid reuse of business capabilities . This is easy to understand , Let me explain my view on the microservice architecture .

When it comes to microservices , It has to be said that the chief scientist of our company is generally accepted and adopted by the industry Martin Fowler Definition of microservices ：

Here is a key point , I don't think it has attracted enough attention , So I think that the vast majority of the so-called microservice architecture systems on the market today are defined by Lao ma , They are all pseudo micro service architectures . The key point is “ Can be deployed independently ”, I think it translates into “ Capable of being delivered independently ” More appropriate , This is also the key factor to judge whether a microservice architecture can play its value .

This is what I mentioned earlier “ Component compile time dependency ” The problem of . In fact, componentization has always been the pursuit of everyone , For example, we often see jar Package and various open source components are good component encapsulation . Microservices are technically nothing more than changing the dependency points between components from “ Compile time ” Pushed back to “ Runtime ” nothing more .

Don't underestimate this change , There are many benefits . Because dependence is postponed to “ Runtime ”, It is possible to achieve something similar to “ Components are delivered independently ”、“ Component runtime dynamic extension ”、“ Component technology is heterogeneous ” Etc , But it also needs to bear the cost of the complexity brought by the distributed architecture .

Why is it that most microservice architectures are fake ？ Because there are integration tests or other factors , As a result, there is no real independent delivery （ Note that it is not deployment ）. I also wrote an article about this 《 Do you dare to deliver your microservices independently ？》, It's about how to do this without integration testing , Use the strategy of contract testing to design and realize the independent delivery of microservices , Fully unleash the value of the microservice architecture , If you are interested, you can have a look .

And if the microservice architecture wants to really bring value into play , The main point is that “ service ” Be stable enough （ Easier said than done ）.

therefore , There is no direct relationship between the business platform and the microservice architecture , Just because of the low coupling feature that the microservice architecture runtime depends on , It is usually used to realize the team separation of different capability units in the business 、 Technology separation 、 Lead time separation and other features , Can only be regarded as a good pair of partners .

Overview of platform based enterprise architecture design

In the end, let's go through it quickly , A complete planning process of platform enterprise architecture .

1. First, analyze the existing business architecture of each business line , Root cause analysis combined with identified pain points , Improve and design the business architecture , So as to improve the existing business architecture , Design new and improved business architecture , Solve the problems behind the current pain points .

2. At the same time, refer to the objectives and measures for each business line after the strategic decomposition , integrate into To-Be Business architecture design , Make the new business architecture design match the enterprise strategic requirements and solve the short-term tactical pain points at the same time .

3. For the improved business architecture , Do cross business line comparison and analysis , It can help us find the overlap of business functions and business processes of different business lines , Provide support and input at the business level for the subsequent judgment on the necessity of middle office construction .

4. Use Domain Driven Design （DDD） The strategic part of , For each line of business , Do problem domain and bound context analysis , And the identification of key aggregations , To try to cross the flow , Examine the essence of the business from the perspective of the field , What problem space is being solved , And through the division of problem domain （ The core 、 Universal 、 brace ）, Distinguish the importance of problem space to the enterprise .

5. Similar to business architecture , Similarly, for the domain analysis view analyzed by each business line , Make horizontal comparison and projection , Identify problem domains in different lines of business from the domain layer 、 Bound context and coincidence degree of aggregation . It may be more abstract , You can understand it as similar to stacking several translucent paintings together , To find the intersection . Help us identify business data and business models （ function + technological process ） The deep-seated common ability .

6. Combined with the existing business architecture and application architecture , Improve the application architecture design of each line , And pass As-is and To-Be The application architecture of Gap analysis , Produce IT Specific opportunities for construction , This opportunity point is similar to creating a new one CRM Systems or something .

7. Then based on cross domain business architecture analysis and cross domain domain domain analysis , Discuss and judge the business coincidence degree of multiple business lines , And identify in detail that the overlap is more at the business model level （ Travel 、 Online retailers ）、 Overlap of business function levels （ Sign in , The shopping cart ）、 Or business areas （ Get through with user data ） Coincidence of levels . Based on the results of the discussion , Decide whether it is necessary to introduce the construction of the middle floor , And according to the coincidence , Expand the application architecture of the platform layer in the plan in detail .

8. Finally, the current situation and To-Be The gap between the final planning , Produce a specific list of opportunity points , And based on multi-dimensional （ Common e.g. strategic importance 、 The degree of emergency 、 cost 、 Resource readiness 、 Technical readiness 、 risk 、 Pain points Mapping etc. ） Do prioritization , Generate the final roadmap .

To sum up

Through this lecture and the previous lecture on a complete Discovery and Define Explanation of process , We have completed a strategic goal and vision of the industry and enterprise , To the complete process of finally forming an enterprise level architecture based on the middle office . Of course, this process is much more complicated than the written description , But by telling , I hope you can build a comprehensive picture of the platform enterprise architecture .

At this point , You may ask , I just want to be a middle stage , Do you need such a troublesome strategic planning ？

My answer is very positive ： highly necessary .

Because I have experienced many practical cases of China Taiwan construction , Many of them are due to the lack of such a Discovery and Define The process of , As a result, the construction goal of Zhongtai is very vague , There are only a few slogans on the wall , Did not think clearly whether it is necessary to build a middle platform , And what exactly does the Zhongtai construction mean to the enterprise .

There's something else , When we finally converge , It is found that although the necessity of building a middle platform exists , But for the current situation of enterprises and industries , It's not the highest priority , Or do not have the relevant conditions , At this time, it is also very dangerous to rashly carry out China Taiwan construction .

Only here , adopt Discovery and Define Analysis of , We really need a business center , And the priority is very high , Then how to build the business middle office ？ Next, I will continue to bring you the second level of divergence （Design） And convergence （Delivery）.

Finally, I'll leave you a few thinking questions ：

• You heard before 、 Have you known or used the enterprise architecture method ？

• Have you used the enterprise architecture method to make the overall planning of the middle office ？

• Do you have any questions and experiences to share in the enterprise level middle office planning ？