Guest | Yao Qilin
Edit | Strict
With the continuous upgrading and progress of technology, the system also needs to be gradually upgraded, and the legacy system is like a "road blocker", blocking the road to transformation.
To govern legacy systems, you need to figure out what the legacy system really is. However, the definition of legacy systems can be described as a variety of opinions. What kind of system is called a legacy system? What do we need to do to prepare before we can govern legacy systems? How can we transform these legacy systems in a safer, more efficient, and lower-cost way to better support business expansion and adapt to the direction of technology development without impacting the business?
Based on the above questions, we invited Qilin Yao, senior consultant of Thoughtworks' digital transformation and operation department, to share her practical experience in the modernization of legacy systems, hoping to inspire you. At the same time, Teacher Yao Qilin is also in the QCon+ Case Study Club [What to do with the legacy system?] Carry the transformation to the end! 】The special topic brings the sharing of "Principles, Models and Practices of Legacy System Modernization", welcome to watch!
The following is an interview with Teacher Yao Qilin:
InfoQ: What kind of work have you been in charge of lately?
Yao Qilin: My current identity is a technical coach and technical consultant, mainly helping customers solve some software technology problems, including but not limited to code refactoring, architecture governance, DDD transformation, microservice transformation, agile transformation, talent empowerment and so on. More recently, it's about helping a business modernize their legacy systems. Interestingly, from the beginning of the industry to the present, I have been dealing with various legacy systems almost always, and I can say that I have been "abused" to get used to it.
InfoQ: There are different definitions of legacy systems, and from a personal point of view, what kind of system do you think would be called a legacy system?
Yao Qilin: This is a good question, when we govern the legacy system, we must first understand what is the legacy system and what is not. For legacy systems, Wikipedia defines them as "an outdated, but still in use computer system that uses old methods and techniques." Garnter defines it as "an information system based on outdated technology but critical to day-to-day operations." From these definitions, it can be seen that "technology is outdated, outdated, important, still in use" are the characteristics of legacy systems.
Definition of legacy systems in Wikipedia
The terms "technically obsolete" and "obsolete" speak for themselves and are in line with the vast majority of people's perceptions of legacy systems. But "important" and "still in use" are more interesting, as they illustrate the important role legacy systems play in business operations. Suppose an old reporting system that no one uses is a legacy system? If defined above, it is not because it is not "still in use" and "critical to day-to-day operations". So the definition of legacy systems implies a message that it's hard for businesses to ignore it, and if it's big and complex, it's hard to replace.
InfoQ: Faced with a legacy system, how do we start to transform it? What are the points to note before you begin?
Yao Qilin: In fact, I am more opposed to using the term "transformation" of legacy systems to describe the governance of legacy systems, because transformation may not necessarily be corrected, and if the method is not correct, it is likely to be worse and worse. I've seen a lot of legacy systems, and there's not a big difference between what you've changed and what you did before. There are also many changes that have been changed and cannot be changed, and can only be solved.
I'm used to using the term "legacy system modernization." Because "modernization" means that your goal is modern, then whether it is code, architecture, or various technologies, you need to introduce modern things. But that doesn't mean that everything should be up-to-date, and the new ones don't necessarily fit your system and team capabilities.
So when I say modernization, I mean modern development methods and architectural thinking. For example, when writing production code, you should add tests, pay attention to cognitive workload when doing architecture selection, build a DevOps platform to achieve continuous integration, and so on.
Of course, when starting a legacy system modernization project, there is also a lot of extra-technical things to do. The first is to define the goal of modernization, develop metrics, and then test them in a hypothesis-driven way. Many legacy system transformation projects are blind at the beginning, in order to change for the sake of change. For example, splitting a monolith into microservices just thinks that microservices are a popular system architecture, but doesn't think about what the benefits it brings to the entire system and how to evaluate this benefit. Therefore, after the change is online, as long as there are no major bugs, it will be accepted.
But in fact, this will bring a very bad experience to the business side, and it will be even more difficult the next time you want to "cooperate" to govern the system. If you can clearly define the metrics that have business significance before the change, monitor these indicators when you go online every iteration, and show them to the business side at any time, you can naturally get their approval and support.
Secondly, before the project starts, it is also necessary to communicate with the business side and the operator, and try not to launch new requirements during this period. Because it is very difficult to do improvements and new requirements at the same time, it will increase a lot of work out of thin air and increase the risk of improvement.
InfoQ: What was the practice of one of the legacy system transformations that impressed you the most? Why did you impress the most?
Yao Qilin: What impressed me most was not so much the transformation of the legacy system, but rather how to avoid a well-functioning system from becoming a legacy system. The skills and knowledge used are similar to the modernization of legacy systems, but the mindset of the customer is completely different.
If the customer's appeal is to govern legacy systems, most of our initiatives will be supported. But if the customer wants to make a piece of software, he'll focus more on the value we deliver than on how the code and architecture are maintained. However, this part of the work is very important, otherwise it will be on the road to the legacy system.
The attitude of our customers determines the resources we are given, including time, manpower and so on. How to guard code and architecture with limited resources is the biggest test for an architect.
InfoQ: What difficulties were encountered in this process? What kind of efforts did you solve, and what precipitation and inspiration did you have?
Yao Qilin: There are many difficulties. For example, as I mentioned above, if the customer wants to do the split of the single architecture, they will give you the time and personnel to do it, but if you are doing software delivery on a single architecture project, it is difficult to convince the customer to do the governance of the architecture, and sometimes it can only be done in time.
One of the projects I was involved in once finally persuaded a client to do an architecture split, but the resources were very limited, only about 80 people days. This is not enough for a single body of some size. But less is better than nothing, so the team members rolled up their sleeves and went dry. However, the process is very arduous, but the effect is not ideal, so that when you talk to customers about similar issues in the future, you will eat behind closed doors.
Eat a trench, grow a wisdom. After a careful review, we found that it is futile to blindly negotiate with customers from the technical aspect, and to start from the business and tell the customer the value that technological improvement can bring to the business. For example, if you strip out the services that are used more often during the busy season of the system and deploy and evolve independently, you can expand the service during the busy season to better support the business. At the same time, the expansion of a single service requires fewer resources and saves more money than the expansion of the entire monolith. For example, we set aside two people to optimize the deployment pipeline for two weeks, which can shorten the time from code submission to deployment launch by 20% and improve the agility of the business. When we come up with a value that is not a technical solution, the customer's attitude will naturally ease.
Of course, none of this is easy, because the metrics of the indicator cannot be accurately estimated.
Although I am talking about customer relevance, it is actually the same as communication with the business side and the operator. The problems faced by most software projects are not technical problems, but human problems, interest problems, and value problems.
InfoQ: What are some of the best practices and tools in the industry that can help us better transform legacy systems?
Yao Qilin: In fact, the reason why a system has become a legacy system is because it did not introduce modern development methods and thinking modes from the beginning, or introduced at the beginning, but did not evolve with the evolution of technology, and did not keep pace with the times.
What we have to do is reintroduce these great practices. For example, if a legacy system does not have tests, then we introduce tests; if the business is in the front-end JSP, then we move the Java code in the JSP to the back end and separate the front and back ends; if the responsibilities between the modules are not clear, then discuss with the business personnel and re-divide the context in a DDD way; if there is no CI/CD in the project, we will introduce CI/CD... Automated testing, front-end and back-end separation, DDD, deployment pipeline... These are all modern development methods, and if they are introduced into the legacy system step by step, then the modernization of the legacy system is complete.
When it comes to tools, there are actually many code analysis and module analysis tools that can help us find problems in the system. For example, Sonar, which may already exist in all projects, is a very good code analysis tool that can help us find many potential problems in the code. But I'm afraid most projects have just introduced this tool, and whether there are plans to improve the problems that Sonar scanned may not be mentioned.
Dependency analysis tools include Backstage, Aplas, Honeycom, Systems, and others that can help us build a map of legacy systems so we can quickly know what modules a business is made up of.
InfoQ: What are the new technology hotspots and trends you're currently looking at?
Yao Qilin: This question is a bit difficult for me, because I suddenly found that the hot spots and trends I have been focusing on recently have nothing to do with "technology". My recent focus has been on Cynefin, Team Topologies, Domain Storytelling, Metaversity, and Cognitive Psychology.
Cynefin is a cognitive framework that divides problems into clear, Complicated, Complex, and Chaotic areas, each with a different response. This framework is especially useful for problem solvers like us, allowing me to categorize problems before choosing a coping strategy.
Or take the legacy system, if it is a purely technical problem, it is located in the Complicated domain, and the coping strategy is to bring in experts, analyze and decompose, and decompose the complex problem into many simple problems of Clear. I used to think so, but it wasn't until later that I discovered that legacy system modernization wasn't a purely technical issue, it encompassed developers, business people, testers, architects, and so on. The uncertainty that these people bring makes this problem a Complex problem. The response becomes experimenting, finding a direction to explore, and then crossing the river by feeling the stones. Therefore, this framework of first locating the problem and then finding a solution has saved me a lot of detours.
Team Topologies translates to team topology, and I deliberately added the word "learn" to the back, because I think it is likely to become a software development methodology with agile in the future. Although it seems very superficial, including four team structures and three ways of collaboration, in fact, the idea of team first proposed by it is far ahead of the industry. The two founders of this concept have produced a book of the same name, Chinese version called "High Performance Team Mode", which interested students can check it out.
For a long time, in the field of modeling large software systems, there seemed to be only one method, Event Storming, and domain storytelling that has emerged in recent years has filled this gap. It's interesting to model the domain through storytelling.
Metaverse is a hot topic lately, and its appeal to me is this renaming operation. If it were called Virtual World or something else, I probably wouldn't catch a cold yet. But the name Metaverse is so good that it gives me infinite reverie. It jumps this concept out of limited scenes such as games and social networking, giving it infinite possibilities. In the medical field alone, I can think of many use cases such as remote consultation with the help of somatosensory clothing, simulated surgery to improve success rates, and so on, which can greatly change people's lives.
The focus on cognitive psychology stems from the cognitive load proposed in Team Topologies, which is a concept of cognitive psychology, and I read some books on cognitive psychology and became very interested. Another reason is that I need to tutor my fifth-grade daughter, and my curiosity about how to memorize knowledge and how to learn knowledge also led me to cognitive psychology.
InfoQ: Finally, how did you get on this career path? Share some of your growth and advancement experiences with you!
Yao Qilin: Speaking of this, I am also a halfway monk, undergraduate and graduate students have a degree in management, and the time to contact programming is relatively late, unlike many big cattle who start to participate in competitions in elementary school. I even asked my senior to do the only programming-related course assignments in college. But it was on that occasion that the senior, while chatting with me, completed a system, laughing and flying. The idea of "it's just so cool, I want to be like him" came into being.
Then, like many people, from programmer to architect, it went all the way.
Finally, share some experiences with friends who are interested in legacy systems. In fact, I would like to say that no one is interested in legacy systems, no one wants to work on legacy systems. But, as my colleague, creator of refactoring and microservices, and a titan in software development, said: Let's face it, all we are doing is writing tomorrow's legacy software today.
Every line of code you write today will become a legacy system tomorrow. So even if you're not working on a legacy system, you're about to work on it.
Therefore, you should adjust your mindset, face it positively, drink more hot water...
Introduction of guests
Yao Qilin
Senior Consultant, Digital Transformation and Operations, Thoughtworks
Senior consultant at Thoughtworks and translator of technical books. He has over 10 years of experience in software development, design and architecture. In recent years, it has continued to improve in the modernization of enterprise legacy systems, domain-driven design, agile software development, clean code and refactoring, and empowered the R&D team of the enterprise through theoretical guidance and practical exercises. Participated in the translation or review of several technical books, including Domain Specific Languages, and . NET Performance Optimization", "Deep Understanding of C#", etc.
Course recommendations
Legacy systems have always been the "hardest hit area" in the field of technology, and if you want to analyze the characteristics and problems of legacy systems in depth, I recommend that you study this column, which will solve the difficult problems of legacy system governance from the four directions of code, architecture, DevOps and team modernization, and help you and your team get out of the quagmire of legacy systems. Now open the super membership for the first month of 6 yuan to unlock, there are 200+ system lessons and 1400+ video lessons, waiting for you to taste!
Scan the code to open a member, save 99 yuan
Read the column "Legacy System Modernization Practice" for free
Click on one to see fewer bugs