How to Plan the Technical Evolution of a Software System

1. Introduction

This article organizes some of my thoughts on technical planning for software systems.

This article was written in 2024 and reflects how I thought about the topic at the time. When migrating it to this site, I made only minor adjustments to some wording.

2. How I Understand Technical Planning for Software Systems

Technical planning for a software system, as the name suggests, means planning the future evolution of the system from a technical perspective. It can be understood through three parts:

1. Software system
2. Technical perspective
3. Planning

2.1. Software System

From desktop software, web applications, and mobile applications to a single service, module, component, or tool, all of them can be viewed as software systems at different scales.

Software systems usually leave room for further planning. On the one hand, real-world systems rarely remain in an ideal state forever. Over time, they accumulate problems in functionality, architecture, performance, reliability, or cost. On the other hand, even when a system is currently running well, changes in the business and advances in technology may still require us to consider whether and how it should evolve.

2.2. Technical Perspective

The technical perspective is often contrasted with the business perspective, but the two cannot be separated. Business development determines which problems technical capabilities need to solve, while technical capabilities also affect the efficiency and cost at which the business can grow. Therefore, although technical planning mainly focuses on technical problems, it cannot be detached from business goals and real-world constraints.

2.3. Planning

According to Baidu Baike’s explanation of “planning”, planning focuses on overall, long-term, and fundamental issues over a future period and designs action plans accordingly.

In my understanding, technical planning mainly contains two aspects:

1. Planning is a solution
2. Planning is also a plan of action

2.3.1. Planning Is a Solution

A solution exists to solve a problem. Therefore, the first step is to clarify what the problem is, then provide concrete approaches, implementation steps, and the reasoning behind the trade-offs.

Technical planning usually does not focus on one or two isolated defects. It focuses on foundational problems that may have a significant impact on the system’s future. Good planning should move from local issues to a system-wide perspective, analyze the relationships among problems, and avoid disconnected local optimizations.

2.3.2. Planning Is Also a Plan of Action

2.3.2.1. Planning Looks to the Future

Planning mainly concerns the future, but judgments about the future must be based on an understanding of the current state and the system’s historical evolution. Only by fully understanding the system’s current capabilities, problems, and constraints can we propose a reasonable direction for evolution.

2.3.2.2. Planning Covers a Certain Time Horizon

There is no single answer for how far technical planning should look ahead. In practice, the next 3 to 12 months can be used as a reference range, but the actual horizon still depends on the pace of business change, system complexity, team resources, and uncertainty. If the horizon is too short, planning can degrade into simple requirement scheduling. If it is too long, changes in the underlying assumptions may make the plan difficult to execute.

2.3.2.3. Planning Must Be Executed

Planning cannot stop at a description of direction. It also needs priorities, phased goals, and an execution plan, with continuous adjustment based on real feedback during implementation.

2.4. Summary

1. Software systems at different scales can all be technically planned
2. Technical planning cannot be separated from business goals and real-world constraints
3. Planning is both a solution to problems and an execution plan for the future
4. A basic process can be summarized as:
   1. Review the system’s history and current state
   2. Define a future target state based on the goals
   3. Identify the key gaps between the current state and the target state
   4. Design and select solutions for the key problems
   5. Build a plan and drive execution

3. Why Do Technical Planning?

The main value of planning is to establish goals and direction so that limited resources can be invested in more important problems.

For a software system, technical planning can help a team step outside the stream of recurring local requirements and incidents, identify the key problems that affect long-term development, and schedule necessary governance and engineering work in advance. For engineers, participating in technical planning also helps develop systems thinking: instead of only solving the immediate problem, they also need to understand why the problem emerged, how it relates to other problems, and what long-term impact it may have.

4. How to Plan the Technical Evolution of a Software System

4.1. Collect Information

Information gathering runs through the entire technical planning process. Common inputs include code, previous plans, technical designs, integration documentation, incident records, monitoring data, user feedback, and business plans. The completeness of these inputs directly affects the quality of later judgments.

4.2. Understand the Current State

The current state of a system can be reviewed from two perspectives:

1. Business functionality
2. Technical architecture

4.2.1. Business Functionality

You can experience the system from the perspective of users and integrators to understand which roles it serves, which problems it solves, and which major workflows it contains, then produce the necessary functional or integration documentation.

4.2.2. Technical Architecture

While experiencing the system, you can also use packet capture, logs, monitoring, and code analysis to understand the architecture and critical paths. Depending on the system’s complexity, you can prepare layered architecture diagrams, critical-path diagrams, or other materials that accurately describe the current state.

4.3. Define the Future Target State

When thinking about the system’s future shape, both inductive and deductive approaches can be useful.

4.3.1. Induction

Research similar internal or external systems, summarize practices that have already been validated, and then determine which capabilities are worth adopting based on your own system’s goals and constraints.

4.3.2. Deduction

When similar systems do not provide directly reusable practices, return to the system’s users, core value, and business goals, and derive the capabilities it will need in the future from those premises.

Whichever approach is used, the target state should not be an architectural form pursued for its own sake. It should also explain which problems it is intended to solve and which results can be observed or measured.

4.4. Identify Problems

A problem can be understood as a gap between the current state and the target state. Once both are relatively clear, the analysis can cover areas such as:

1. Technical architecture
2. Integration and development efficiency
3. Performance
4. Reliability
5. Cost
6. Security and compliance
7. Other constraints that affect the achievement of the goals

Problems should not simply be listed by count. They also need to be prioritized based on impact, urgency, cost of resolution, and dependencies.

4.5. Design Solutions

For key problems, compare multiple feasible solutions whenever possible. Explain the benefits, costs, risks, and applicable conditions of each, then make a choice based on the goals and constraints. There is no need to mechanically pursue a fixed number of alternatives. The important thing is to avoid committing to a conclusion too early without comparison.

The form used to present a solution should also serve communication and decision-making. For a complex system, layered architecture diagrams and critical-path diagrams can be useful. For a simpler problem, clear text, interface descriptions, or data comparisons may already be sufficient.

4.6. Schedule and Execute

After a solution is selected, break it down into tasks and clarify priorities, owners, phased goals, and acceptance criteria. For higher-risk changes, also consider gradual rollout, monitoring, and rollback mechanisms.

Technical planning is not a one-time document. During execution, continuously check whether key assumptions have changed and adjust subsequent plans based on implementation results.