What is the role of the technology center?
To understand this, you need to first understand the relationship between "technical front desk", "technical middle desk" and "technical background", as well as their respective roles and functions.
Let's talk about our "technical front desk" first.
Technical front desk
"Technical front desk", to put it bluntly, is the technical team that develops functions for the business department.
If it is a ToC business, the delivery must be close to the end user, and if it is a ToB business, the delivery must meet the needs of the merchant.
You must always keep in mind the concept of "running in small steps, quick trial and error". Whatever the business says, it is what it is, and you do what the business wants to do.
In addition, the investment in R&D resources is basically equal to that of the business. If there are more business needs, the number of people will increase, and if the business needs are less, the number of people will decrease accordingly. Moreover, the team organization is basically divided by functional lines.
The technology stack used is also relatively simple. Taking the Java language as an example, usually "1 NG + 1 War/N Jar + 1 database" is enough, and the rest of the technical services will be provided by the "Technology Center".
The core value of "technical front desk" is reflected in the understanding and realization of business logic, and it is a ladder for technology to deliver value to business.
I think at this point, it is somewhat similar to the front-end marketing of the offline sales team.
Technology Center
Let's talk about our "technical middle platform".
To put it bluntly, "technical middle platform" is a platform system that emphasizes resource integration and capability accumulation. When the "technical front desk" realizes business functions, it provides them with support for underlying technology, data and other resources and capabilities.
How do you understand this?
As can be seen from this picture, the "technical middle platform" is a bit like an adaptation layer during programming, which acts as a link between the past and the future, separating the technical capabilities of the entire company from business capabilities, and providing technical empowerment to the front desk in a productized manner. Form a strong support.
Under what circumstances is it necessary to be a technical center?
As the saying goes, "Know yourself and know your enemy, and you will win a hundred battles." In my opinion, when facing technical problems, "knowing yourself" is more important than "knowing your enemy".
Before implementing "technical middle platform", should we calm down and conduct "soul torture" on ourselves? For example, is the time ripe now? Or what is called maturity?
In my opinion, in order to be a "technical platform", the objective environment needs to meet two prerequisites: vertical technical organizational structure, and multiple and complex business lines.
Otherwise, the result of "technical middle platform" will only be two kinds: a farce or a money-losing business.
| Premise 1: Verticalization of technical organization structure
A friend once said that the evolution of every company's organizational structure is a history of blood and tears. I am very puzzled, ask why?
He said, because there are too many subjective judgments and emotional entanglements mixed in.
For example, an employee thinks that the company's management is chaotic, and the organizational structure is adjusted back and forth. One day, one team will be dismantled, and another team will be merged tomorrow. The company is hopeless.
However, the executives shouted that they were wronged, and felt that the purpose of organizational structure adjustment was to improve output and human efficiency. If you are unhappy with your work, you can leave. This kind of thing is impossible to satisfy everyone. Appreciate it, but those who have lost their benefits must be raving about it, so ignore it.
Indeed, this kind of "self-revolutionary" adjustment is basically impossible to achieve in one step. It needs a process of gradual evolution, and in this process, it will naturally encounter a lot of resistance or doubts.
Look at this structure, the classic division of labor model, is there any problem?
Not only can I not tell the problem, but I can even find 10,000 reasons to explain the benefits of this model. Development is separated by business line, and testing and operation and maintenance form an upper-lower relationship. No one wants to control the other.
So under what circumstances will you feel that this model is problematic?
Objectively speaking, the functional division of labor model is more suitable for the waterfall development model. First talk about the demand, then talk about the construction period, and then proceed step by step
But when the needs of users start to change, and the business side needs to add a new function from time to time, when building a new system, you will find that the developed system is difficult to change, at least it is difficult to change quickly.
So, you reorganize development by system function, and each team works around "delivery speed", but this encounters two new problems:
-
There are a variety of middleware, and each team selects the middleware independently. There is no unified maintenance, no unified knowledge accumulation, and it is impossible to guarantee the SLA in a unified way.
-
The goals between development, testing, and operation and maintenance are inconsistent (for example, testing Mr. A, the development requires you to only do functional testing, and go online soon, but the testing boss asks you to do non-functional testing to ensure quality and avoid taking the blame... Who do you listen to? ?), caught in endless wrangling and quarrel.
In the face of these two new problems, we have made adjustments:
-
Set up a platform architecture group to be responsible for the development and maintenance of technical tools or services such as middleware, automated testing/operation and maintenance, and database.
-
Split the testing team in the quality management department and the application operation and maintenance team in the system operation and maintenance department into various development teams according to system functions, and the original development manager is in charge to form their own independent Feature Teams.
By this time, although the entire organizational structure has not fully realized the vertical division of labor, it has basically achieved the goal of "quick trial and error, small steps and fast running".
In addition, this is more like another prototype of platformization, which is to gradually abstract some public and underlying technical capabilities, separate them from business logic, and form various access-based basic services, which can provide services for multiple business lines at the same time .
That is to say, the premise of building a "technology center" is platformization, and the prerequisite for platformization is "verticalization of organizational structure and publicization of technical tools."
If there is no such premise, the foundation of building a "technical platform" will be lost.
| Premise 2: There are many and complex business lines
A friend once asked me, what is the core value of technology? My answer is "change the world".
He said, don't talk nonsense, talk well.
He said that for business-driven companies, the core value of technology is to "reduce costs and improve efficiency". From the perspective of architecture design alone, the two means to achieve this goal are "universality" and " Reusability".
Thinking about it now, this sentence can be perfectly connected to the "technical middle platform".
Looking back a few years ago, our business logic was also very simple, either buy and sell funds with your bank card, or use your e-wallet to buy and sell funds, which is convenient and fast.
Gradually, with the increase of business innovation business, custom development of front-end and back-end systems is required, and the difficulty of logic compatibility increases.
In such a situation, in order to meet the organizational requirements of enterprise scale expansion and diversified operation, the company began to turn to the divisional system, dividing business units according to products, regions or markets (customers).
In response to this adjustment of the business side, we began to separate some shared services in business development, and established a business center group (since this article focuses on the technology center, the content of the business center will not be explained)
The reusable services and codes are handed over to these groups to develop services for use by the business group, so that the data model will be unified. When developing business, first check which ready-made services can be used, not all of them Developing from scratch will also improve development efficiency.
Echoing the "business middle platform", the "technical middle platform" is like a large warehouse of tools, which is full of various technical tools. No matter which team or person it is, you can quickly find your own tools and use them immediately. Just use it.
The group of people who maintain tools does not need to be close to business development. The daily task is to study how to use these tools, how to tune them, how to debug when encountering problems, and form knowledge accumulation.
With such a group of full-time people, you can choose a limited number of technology stacks to focus on research according to your own situation, and limit the business group to use only these tools to ensure the consistency of model selection.
If you only have one line of business, then don't engage in "technical mid-stage", and gather people together to save money and effort.
With the technology platform, can you go to heaven?
Theoretically speaking, when the number of business lines increases and becomes more and more complex, the "technical debt" between the front desk and the back office will increase accordingly, and the phenomena of repeated wheel creation and high communication costs will increase. to a certain extent to solve this problem.
This theory seems perfect, but it is difficult to implement in practice.
Imagine that if too much "technical middle platform" is done, the resource investment will be huge, and it will not be possible to form a positive benefit transmission;
If the "technical middle platform" does too little and cannot deeply understand the business, the implementation of the adaptation plan will deteriorate and gradually lose its value.
How do you understand this sentence?
Ten years ago, I worked in a financial software company. As the number of customers increased, the contradiction between cost and efficiency/quality became increasingly prominent.
Imagine, from one group of people maintaining one set of codes, gradually to one group of people maintaining several sets of codes. In this way, bugs will increase, efficiency will decrease, and complaints will also increase. Resignation, the team fell apart, Game Over...
In this case, the general company will take three countermeasures:
-
One-to-one service - project system: Multiple teams, multiple sets of codes, multiple sets of standards, serving multiple customers, but the cost is unbearable, and over time, it will definitely become insolvent.
-
One-to-many service - standardization: one team, one set of codes, one set of standards, serving multiple customers, but customers don't buy it, customers say that my needs are all personalized, don't come to a certain standard to guide me, called Whatever you do, you just do it, don’t you want to? Then you go, I will find someone else to do it.
-
One-to-many service - productization: one team, one set of code, multiple sets of standards, serving multiple customers, through technology and configuration means, using SOA thinking, to build its own productization platform, but requires high technical investment , especially rely heavily on core talents, small and medium-sized enterprises generally find it difficult to retain these people, as long as they leave, the company is basically finished.
Looking back, how many of those software companies that were so shocking back then survived? Taking the financial industry as an example, Hang Seng was relatively successful on the second road, but we died on the third road back then.
In my opinion, our "Technology Center" is a "Party B Service Company", and our "Technology Front Desk" is more like a "Party A E-commerce Company".
It is undeniable that after having this "Party B service company", in the face of large-scale projects and fast-changing business, the investment in technology and the initiative are stronger. The position of "the ass decides the head" can easily lead to conflicts between the front office and the middle office.
From the perspective of responsibilities, the front office is to "respond to business changes quickly", and the middle office is to "provide services stably and efficiently".
One pursues efficiency and the other pursues quality. This contradiction exists naturally.
How to understand? Let me give a small example to illustrate.
The A team and the B team of the front-end department, due to business needs, simultaneously proposed to the "Technology Center" to access the caching service
In the middleware product line of "Technology Center", there is a self-developed distributed cache system based on Proxy, which has been running in other business lines for many years. However, because the technical debts of Team A and Team B are different, it is necessary to add adapters to complete access
But at this time, there are not enough manpower, sorted by importance, we can only pick up team A first, but team B also has needs, and can't wait, what should we do? Just give him a Redis first and then play around, and wait for Team A to pick it up before picking you up.
A month later, when Team A finished the pick-up and found Team B, the pain point no longer existed at this time, and the enthusiasm of the team was naturally low. After all, there was no benefit, so it was nothing.
A few months later, the security team proposed to change the encryption of the Redis cluster. Because team A accesses the "technical middle platform" caching middleware product, it adopts the proxy mode and operates through the console, which is convenient and fast. Find a night, and within 5 minutes, everything will be done.
However, Team B uses the mode of direct connection to Redis, and the password is embedded in the SDK. Not only does the foreground and the middle office need to be linked during the encryption process, but also the application service needs to be restarted after the encryption is changed. cycle to do this.
In the end, what could have been done in five minutes took three full weeks. The operation and maintenance students of the "Technology Center" even stayed up all night many times, and an accident was caused by human negligence.
Just one year after this incident, due to the gradual increase in the business scale of the B team system, the number of Redis has also gradually increased, and the operation and maintenance costs and risks of the "technical middle platform" have also increased.
During this period, the middle office has negotiated with the front office many times, hoping to connect the A team to the cache middleware through adaptation, but it has not been achieved.
From the perspective of "Technology China Taiwan", "You only care about yourself and don't care about others. You take the credit and we take the blame?"
From the perspective of the "technical front desk", "You know what the hell! We are almost driven crazy by the business, don't you just spend more labor? Will more overtime work kill you? Why are you always talking about some ideas? It's not beneficial to you. What are you doing?"
Because of this division of labor, there are many contradictions in the work, and it seems that there is no better way to solve it completely.
Some people say that it is very simple to solve it, you can either force it or increase your investment, and you will get it if you are ruthless.
Let’s talk about strong pressure first. It seems that the goal can be achieved in a short period of time, but it is purely a tactic of "killing one thousand enemies and harming eight hundred". Is it necessary for the business R&D team to stop what they are doing and come out to carry out technological transformation together? ? What's more, the pressure on the front office is unimaginable for the middle and back office teams.
Taking a step back, putting aside the topic of "mutual understanding", the routine of coercion is equivalent to "siege the city as the top, and attack the heart as the bottom", which will bring a lot of trouble to the future management and team atmosphere.
Let's talk about increasing investment. Look at the "software companies that are dying on the road" I mentioned above. Do you still want to increase investment in the middle and back office?
If you are not a big factory, forget it.
How do you say that? The most tragic ending is that your technical background is getting stronger and stronger, but the scale of your business is gradually shrinking.
Sad, deplorable.
Summarize
In the Internet age, there seems to be no shortage of hot topics in the technology circle, but there are very few of them that are quality, in-depth, and can solve practical problems.
Now everyone is discussing "China Taiwan", today "product China Taiwan", tomorrow "data China Taiwan", one said that it can improve efficiency, and the other said that it can overcome all difficulties, chatting happily.
For enterprises, it doesn't matter whether the topic is hot or not, and it doesn't matter whether the solution is awesome. The key is to help users find the balance point between efficiency, quality and cost, and perhaps it can be regarded as a qualified "technical platform".
Category: Other