One, foreword

Recently, there was an article about Alibaba tearing down its own central platform, which stifles innovation anyway. There is no good and evil in dao? It’s all about who uses it. In the cook’s body can produce the whole world delicious, in the murderer’s hand that certainly produces the tragedy. I have read an article on the first principles of Middle School thoughtWorks, and it seems reasonable. According to the Cynefin cognitive model, deductive method can be deduced:

In essence, the evolution of enterprise architecture represented by the middle platform is that in the process of development, with the continuous improvement of the cognition of market information, enterprises seek certainty from uncertainty, continuously explore common Best practices across business lines, and carry them by the middle platform. Finally, it is used to support and realize the process of rapid response, replication and enhancement of business development.

Second, the role of the Central platform

There is no silver bullet in the world, and you are blind if you think that all the problems in the enterprise can be solved by going to the middle stage. But is Mr Ali’s favoured centre really useless? First of all, the middle-stage highlights 1) maximizing reuse for fast replication, 2) depositing enterprise core capabilities to support business innovation, and 3) reversely promoting the evolution of business side to cross-business direction.

1. Maximize reuse for fast replication

As true programmers, don’t we write code that we reuse? Yes, we write the utility class every day, or we package it as a standalone microservice, after all, the DRY (Don’t Repeat Yourself) concept is a basic requirement of the programmer. But who actually uses the common code when it’s taken out and encapsulated? It’s usually just the team playing and singing by themselves. Can other teams use it? Usually less. Why? I think there are three aspects.

1.1. The response rates of demanders and service providers are inconsistent for reusable modules in business requirements

For the service demand side, since there is demand, there must be a requirement for response speed. On the other hand, the service provider’s KPIs dictate that their response principle must be to prioritize their own work. The fault of the service provider is not that the team responsibilities have not been properly set. As a result, teams are not comfortable with this reuse because of the lack of support and responsiveness.

1.2. Rights and responsibilities, after all, KPI is different

What are the benefits of priority assistance to the demander and the provider for the service provider? If their KPI indicators are not connected, it is unhealthy for team development from the perspective of responsibility, because there is no constraint, and no constraint means no responsibility.

1.3. The existence of silos between teams

In The book Borders (original name: The Silo Effect: The Peril of Expertise and The Promise of Breaking Down Barriers, silo thinking is great. Because of the silos, the book says, the risks in the books were hidden from the bankers’ eyes, even when inspected by risk regulators. Due to SONY’s internal divisions and lack of communication, there were two walkmen with similar functions at the product launch, and Apple beat it by breaking product boundaries (that is, poking through silos).

I briefly talked with a former colleague who once worked in an Internet company. Although different teams are separated according to business functions (such as payment, product, advertising, etc.), they complement each other in TERMS of KPI. What do you mean? That is, team A’s acceptance and completion of team B’s needs is of positive significance to team A’s performance, so team A is also happy to see its success and cooperate. Only on the basis of such performance, the maximum reuse is not a false proposition, otherwise the middle is just a beautiful castle in the air built from hi.

Because there are silOS between teams, progress is predictable unless the lead of that line pushes it hard. Then we should learn and apply “Conway’s Law” and build independent teams to extract and promote common characteristics, so as to cleverly bypass SILO problems at least from the level of organizational structure.

2, precipitation enterprise core ability to support business innovation

So let’s talk about precipitation. How to precipitate? Who is most familiar with business processes? Application development teams.

Let the people who can hear the cannon make the decisions. Similarly, it is best to have the application development team facing the business requirements do the extraction. But how do you achieve this through organizational structure? I think it’s the following:

The “bring in” model. Is to establish a business team, first dispatched to their respective application development team responsible for daily demand development, and then business commonality knowledge to the team to assist in the construction of the central Taiwan.

“Go out” mode. Is to select some backbone from their respective teams to form a business team in Taiwan. After all, we have been in contact with the business system for so long that we can immediately form a combat effectiveness. This scheme is more efficient.

Contact mode. I also recruited people from the application development team to be responsible for knowledge transfer and modification of the central team and help the business central team to grow.

3. Reverse the service side to cross-service evolution

After the construction of zhongtai, everyone thought that the “battle” had been completed. It is precisely because of the reuse of Zhongtai that other businesses are destined to communicate and assist with zhongtai Product Department frequently, and then cooperate with appropriate KPIs. Gradually, there will be a situation of interdependence and mutual cooperation between departments can be more “result-oriented”.

Third, there is a use cost of Taiwan

Cost means you have to pay something. A lot of people think that as long as you find a manufacturer or set up a research and development team, in a hurry on what Taiwan is a cure-all. As everyone knows, although the construction in Taiwan after want to use good or have a few costs. Of course, it’s a matter of perception, whether you think it’s a simple problem or a complex problem. But in fact, in many cases, technology is not the only factor in the construction process of the Central Taiwan. There are also a series of problems to be considered.

1. Organizational structure

The construction of central Taiwan often takes obvious organizational transformation color. But how do you turn it?

First of all, the front desk has business attributes. If the lack of full-time product department in Taiwan, Taiwan will not be able to carry out construction planning, all to the demand is “hit a gun dry one shot”. Ok, we will first build the Taiwan Product department, but what are their KPIs after that? Which businesses are willing to plug in?

Next, let’s review how Ali did it. First of all, the sharing business Division had juhuasuan.com, a huge traffic entrance at that time, and ali’s senior management required all other e-commerce platforms to access Juhuasuan.com through the sharing business Division. It was this finishing touch that gave the shared business Unit a starting point and window for a real organizational transformation. It can be seen from this that, in fact, everything is driven by interest (first of all, it should be clear that interest is a neutral word with neither praise nor contempt). Other e-commerce platforms need this huge traffic entrance, and the sharing business division needs to start the transformation. Both sides still have a certain basis of interest. Therefore, today, in addition to setting up a Product department in Taiwan, it is not enough to make the Product Department in Taiwan and other business lines the same in terms of interests or convergence to a certain extent, so as to slowly succeed in the transformation.

2. Demand management

I think it’s also a strategy and part of the portfolio. The intermediate system is only a “tool”, if the lack of effective demand management of this “method”, in fact, is half the result with twice the effort. One of the teams I was in charge of was also trying to build a reusable service center at the early stage, but due to the lack of unified product manager and overall product planning, the final version 1.0 was more of a bunch of functions that were hard put together to meet business needs. However, the planning or positioning of the service center gradually became clear after it was made clear that a unified product manager would follow up. Therefore, it can be seen that without stable personnel for demand management and planning, even if you have a ready-made middle stage, it will eventually evolve into “Sidissimilar” for various reasons.

Fourth, the Central Taiwan is a process of evolution

Here, abandon the idea of “fighting for the best” and embrace the idea of being prepared for the long haul. We should be good at viewing problems from a dynamic and developing perspective. The construction of Zhongtaihua itself is a process of continuous iterative construction. If we take the 1.0 version of the zhongtai requirements prototype to build, after the completion of the hope that this constant support for the constantly changing business scenario, then the Zhongtai construction will fail in the end, if not fail, will slowly die. Since the construction of Zhongtai is also a continuous process, any process should be managed based on the closed loop of PDCA, just like the agile development, there is no final product, only the constantly optimized product can have strong vitality.

From requirements to accept the level, when we have a demand to in China if you’re just going to have to cover, and then you said China does not support, but had to use (after all, China positioning in here), then asks business model to fit middle existing function, it must stifle innovation, because it is the practice of metaphysics.

When we accept the demand, we should first identify the part that the middle stage can undertake, and support the rest through other systems. This is as if, for example, the company itself is a ready-made B2C mall system, commodity center, payment center. Suddenly you receive the demand of another business department to do a B2B mall, it depends on the specific business model, but if considering the commonness of B2B and B2C mall (high cohesion and low coupling principle) or need to do commodity management and supplier management, it may be suggested to directly reuse the commodity center, However, the front-end B2B mall may need to be rebuilt due to the inconsistent style and purchase process (payment center is the same road). Maybe someone will say goods management and supplier management module may also have changed, but as long as not against high cohesion and low coupling principles directly in the middle of adaptation transformation is also reasonable, after all, architecture is a pursuit of the art of balance, it is for the purpose of technology, cost, resources, such as performance for balance in order to achieve the most efficient meet business needs, So where exactly each business function goes really depends on the situation.

From the perspective of operation, many people think that only one or two people need to operate and maintain the business after it is well built. But in fact, this platform needs nutrients, if there is no continuous front-end business application system “extract the essence” and “digestion and absorption”, the platform will sooner or later because of the loss of vitality and flexibility also die. Our front end business is actually exposed to different operations every day and has a variety of business ideas, some failures and some successes. When a business model is proved to be successful, it should be quickly incorporated into the middle stage and copied to other business lines with low cost and high efficiency, so as to be able to enter the market earlier than competitors, rapidly increase market share and form scale advantages.

After five, language

It just depends on what you want. If you really hope that the center is a silver bullet to solve all the problems of the enterprise, it is indeed considered useless because it cannot meet expectations; However, this does not prevent it from serving as a vehicle for best practices in the core business capabilities of the enterprise.