Evolutionary architecture never lacks design methods, the biggest resistance lies in "people"｜ONES Talk

On August 18th, the ArchSummit Global Architect Summit hosted by InfoQ, a subsidiary of Geekbang Technology, was held in Beijing. The theme of this summit was "Upgrading Architectural Thinking, Supporting Business Development", focusing on cutting-edge trends and technical practice case sharing.

As a leader in enterprise-level R&D management tools, ONES was invited to attend this conference. ONES R&D Director Chen Liangyu delivered a speech entitled "Post-Architecture Era: How Technology Management Promotes the Continuous Evolution of Architecture", and shared with technical managers and architects from all walks of life the thinking and practice of ONES in evolutionary architecture design .

The following is the essence of Chen Liangyu's speech.

What are the characteristics of the post-architecture era?

The "post-architecture era" is also known as the "evolutionary architecture design era". This era has the following three characteristics:

The market environment is changing rapidly, and the business is developing rapidly, and the architecture design must be continuously evolved to meet the needs of the business;
As the scale of the enterprise grows, the corruption of the architecture design cannot be avoided, and it can only continue to evolve in the evolution;
The architecture can be incrementally changed without breaking the original architecture.

What are the dilemmas of evolutionary architectures?

Evolutionary architecture has never lacked design methods, and the biggest resistance lies in "people". As the famous Conway's Law states, "The architecture of a design system is constrained by the communication structure of the organizations that generate those designs."

So, what problems does "people" bring?

Functional architecture teams have many roles, such as back-end architecture team, front-end architecture team, operation and maintenance architecture team, etc. Different functions have different architecture goals;
The architecture supports the business, which requires cross-functional and cross-departmental coordination of multiple teams, which is difficult to manage;

"How to get out of the predicament of "people"?

Architecture design is a production process that goes through a complete life cycle from design, implementation to delivery. Pipeline is an effective way to improve production efficiency. Constructing an efficient production architecture pipeline can reduce the problems that may be caused by the variable "people". , to help us out of the predicament.

Intuitive framework for problem solving

When we encounter a problem, we usually deal with it in four stages:

• Identify the problem: Know what the problem is? What to change?
• Analyze the problem: What is the root cause of the problem? What will it be changed to?
• Problem solving: finding solutions based on the results of problem analysis;
• Review questions: Quantify the results, review the process, continue to improve, and find the next problem.

ONES practice sharing

Next, we will start from the practice of ONES, focus on the problem-solving framework of "discovery-analysis-solution-review", and share with you how to use products to establish an open and transparent feedback loop and construct an efficient architecture pipeline.

(1) find the problem

Different perspectives will have different feedback, so to find problems, we must collect feedback from the inside out.

Taking ONES as an example, to analyze the problems on the architecture pipeline, we need to identify the problems to be solved from the two dimensions of the internal architecture team and the external business team.

internal pressure

It is necessary to have an in-depth understanding of the past architecture design and ensure the normal operation of the ONES business while refactoring;
The plan is the foundation of all ONES work, and the architecture team should estimate the input-output ratio before execution;
The architecture team is an elite team of ONES. When the R&D team encounters difficult and miscellaneous diseases, they will help to troubleshoot.

external pressure

The delivery time cannot be promised and it is difficult to be punctual;
The estimated time is short, but the development cycle is long.

(2) Analyze the problem

Once the problem is identified, the analysis phase begins. The basis of analysis is visualization, and there is no way to objectively analyze what cannot be seen.

At ONES, we will follow the following two steps to build a visual architecture pipeline.

Step 1: Understand what the team does

• Know what types of work items your team has: architectural requirements, defects, or ad hoc tasks, and what are the characteristics of each type of work item? What is the source? What is the workflow like? What are the delivery expectations of the source for the type of work item? What is the arrival rate for each work item type? Programmable or completely random state?
• Understand the service categories for each work item type: What is the team's service strategy for handling these work items? Do you need to immediately drop the work at hand and interrupt all transactions to respond, or do you just need to ensure that it is completed within a fixed delivery time, or is it a regular response, first-in, first-out?
• Understand the deliverability of each work item type: How many architectural requirements can the analysis team accomplish? How many defects?

Step 2: Build a Visual Kanban

When enough information is obtained, it is necessary to build a clear and intuitive visual kanban. ONES Project supports Kanban View, which helps us to efficiently build a visual Kanban of the entire work.

When building visualization boards, keep in mind:

• Service start point and delivery point: determine the entire production line, confirm the delivery from the time point, and confirm that the delivery has been completed at the time point;
• Define WIP rules: define WIP rules for work item types, service categories, and people;
• Define circulation rules: Make these rules transparent and synchronize to everyone in the team.

After the construction is completed, we can check whether all the work has been visualized, and whether there are still some implicit work that have not been recorded. If so, repeat the previous work, analyze first, and then build a visualization board until the team Everyone can see what all the jobs are through the Kanban board.

Tips for analyzing the problem:

• Estimates don't produce value, SLAs can do the same. Accurate estimation is just a promise made by the architecture team to the outside world. The cost of estimation will actually reduce the output of value, because the output of the architecture team is the architecture design itself, and the estimation increases the time from the architecture design to the final delivery. .
• Fixed delivery does not imply urgent delivery. If a task takes only a week, but the deadline is a month away, does it need to be done as soon as possible? In fact, no need, we can completely control the completion of this task two weeks before the deadline.
• When everything is an urgent delivery, there are no more urgent deliveries. What if multiple demands come at the same time and exceed the overall load of the team? We have to evaluate the most urgent item from these urgent matters and finish it first.

(3) Problem solving

In an architectural production pipeline, the beat of the bottleneck node determines the productivity of the entire pipeline. It's like on a highway, the speed of the narrowest part of the highway determines the speed of the entire highway.

Based on this rule, ONES simplifies complex problems, and improves the output speed of the architecture pipeline by continuously analyzing and solving bottleneck problems.

Step 1: Identify the bottleneck

There is an obvious feature at the bottleneck, upstream accumulation and downstream starvation. As shown in the figure below, a lot of work has been developed and is waiting for testing, but the test is already fully loaded. It is clearly found through the visual kanban that at the current stage, the testing resources are bottleneck.

Step 2: Solve the bottleneck problem

Maximize the use of bottleneck resources: We have identified earlier that bottleneck resources are test resources. Next, we need to check where the time of test resources is invested, whether it is on implicit work or non-essential work. We can remove some non-essential work content that has little bearing on the value output to ensure that the test resources maximize the output.
Cooperate with bottleneck resources: When the output of test resources is maximized, it is necessary to cooperate with the upstream and downstream, because any work requires the participation of the whole team. Testing input is also required. This can cause work to pile up at the bottleneck and eventually wait for the test resources to complete. Therefore, if the input of upstream and downstream resources is not reduced, it is impossible to truly maximize the utilization of bottleneck resources.
Breaking through the bottleneck: When we make use of the entire channel, we can consider breaking through the bottleneck, such as improving the human efficiency of testing resources, or increasing testing resources.

Some counterintuitive questions

• Why not just increase the resource investment at the bottleneck in the first place?

The answer is simple, if we hire from the beginning, it will result in testing that takes a lot of time to train the new person and supervise the new person's work before he can work independently, so that the workload at the bottleneck increases for a period of time , the flow rate will become slower.

• Why reduce upstream and downstream resource investment?

Taking the highway as an example, we all know that traffic jams usually occur on the narrowest road section. If you suddenly enter a narrow road section from a wide road section, the speed of the vehicle will drop quickly, but if the road is a straight road, it will not happen. problem because the road is clear.

(4) Questions about replay

When measuring R&D effectiveness, there are many metrics involved. However, in the process of analyzing and solving problems, ONES will focus on the following three core indicators:

• Business lead time: measure the overall time from requirement creation to final delivery;
• Delivery lead time: measure the delivery time of the requirement from the start of delivery to the final delivery;
• Throughput: By comparing the throughput before and after optimization, you can evaluate whether the team's ability has improved.

The first two metrics are very important, and we use them to conduct an overall value stream assessment to identify where more time is being spent at the current stage.

After we define the indicators, we can use various reports to help us perform visual analysis, such as histograms, area charts, and trend charts.

Thinking and Summarizing

The biggest resistance to evolutionary architecture design is people. The purpose of good technology management is to manage people well. In short: good technology management can effectively promote the continuous evolution of the architecture.

In addition, we repeatedly mentioned a word in the solution path: incremental, which means that we can gradually improve the productivity of the architecture pipeline by constantly discovering and solving bottlenecks. Therefore, incremental improvement is the way to construct an efficient architecture pipeline. important means.

Wonderful moments at the conference

At the conference site, ONES had a warm exchange with many industry experts and technical managers.