How can you remain adaptable when working with legacy systems in System Architecture?

To understand the system with a legacy - I usually try to reach out to stakeholders and get as much information as possible - where documentation is located, how this functionality works, what benefits it gives to the business etc. However, ~50% of the time, there are no stakeholders that could help you out. So - any kind of documentation (even code comments) helps. Test coverage helps even more - you see how the system is supposed to be used (tests are gold). If you have no documentation or tests - the only option is to perform reverse engineering, which is the most time and resource-consuming option. Prevent following it as much as it is possible. But hey - it could be fun, reading those 5k+ lines class with huge cyclomatic complexity.

In my experience - the only way to adapt when working with Legacy code/systems is to fix bugs, fix more bugs, and fix some more bugs. While doing so, find the gaps for improvements and work on it to make it much more resilient such that it paves a path to modern architecture.

To understand a system I typically start outside in. How is the system used and what are the core durable values it delivers.

Comprehending the legacy system's architecture, functionalities, and limitations (and as to why it was designed this way in the first place) I feel is the key first step. This knowledge helps in devising compatible solutions.

To work effectively with legacy systems, it's crucial to thoroughly understand their architecture, components, and functionality. Delve into the system's history, how it's been used, and its limitations. Understanding the underlying technologies and the rationale behind its design helps in making informed decisions and identifying areas that need improvement or can be leveraged.

Setting a clear “acceptance” criteria will bound the scope to avoid any creep. Measurable goals, qualitative and quantitative, help prioritize and avoid over designing.

One thing you can't forget when defining the scope for dealing with legacy systems is to stagger your scope. You should define the ultimate end state, whether it is keeping the system running or completely migrating it to a new environment, but then you need to determine how to break that ultimate end state into manageable improvements. You may start with something small, like fixing a bug. Then maybe you can migrate something small to a new system. Then you continue to take chunks and upgrade, migrate, or maintain them until you reach the desired end state.

Clearly define the scope of your involvement with the legacy system. Determine what needs to be maintained, improved, or possibly replaced. Setting clear boundaries helps in managing expectations and focusing efforts on areas that yield the most benefit. This step is essential to prevent scope creep and to ensure that changes made are aligned with overall business goals.

Uma boa forma de organizar o escopo de uma tarefa para uma tarefa é fazer sua varia??o da metodologia do 5W2H, uma ferramenta para elabora??o de plano de a??o. Originalmente os itens da ferramenta s?o: - O que ? - Por que ? - Quem ? - Onde ? - Quando ? - Como ? - Quanto custa ? Se adaptarmos a realidade da Engenharia de Software, teremos algo como: - O que? ( a a??o ) - Por que? ( o objetivo ) - Quem ? ( os envolvidos ) - Onde ? ( fontes de consultas, prototipos, documentos ) - Quando ? ( Data limite ) - Como ? ( checklist de itens técnicos ) - Testes ? ( Testes mínimos para assegurar qualidade )

Defining the scope is essential, as normally, the legacy system has some or many bugs. Although it may be uncomfortable to deal with an old and unperfect system, I think the most important part is to have the bugs correctly identified, and then, evaluate if they should be fixed or not. Having a perfect system is impossible, and there is a risk to consume time and money in unnecessary or irrelevant fixes. Any implementation (legacy bug fixing or new functionality implementation) has to be always in accordance with the available resources and the necessities of the project.

Specifically the choice between monolithic and microservices is a common descision I have observed being skipped. All too often people are worried about tool selection before even deciding which pattern to adopt. The 'why' should be the most important factor becasue moving from a monolithic architecture to microservices is not simple and has a cost.

Some legacy systems are better replaced because they are not scalable and can no longer meet the business goals at a large scale. I once inherited a legacy system designed and developed by freelancers and it was clear that a new system was required to meet the business's new needs. To that effect, choosing the right strategy and paving the path for a sustainable architectural runway were crucial. I retained the existing monolithic architecture, NoSQL database, and RESTful standard but introduced the Nest.js framework, containers, CI/CD with CircleCi, Jest, and ECS (Fargate Serveless, Loadbalancer). Monitoring was optional as it was a lean startup with a low budget.

Selecting an appropriate strategy for working with legacy systems is key. This might involve gradual refactoring, a complete overhaul, or integrating new features while maintaining existing functionalities. The strategy should balance the need for modernization with the risks and costs associated with altering a legacy system.

There is several strategies to keep the new system working and operable along with the legacy systems. Strategies including change data capture (CDC) and anti corruption layers (ACLs) ensure the integrity of both system and their synchronisation along the way

Employ tools that are compatible with the legacy system yet modern enough to improve efficiency. This includes using version control systems, modern IDEs that support older languages, and migration tools that facilitate changes without disrupting existing operations. The right tools can make working with legacy systems more manageable and less error-prone.

Utiliza??o de ferramentas podem criar certas facilidades, mas também podem causar uma maior curva de aprendizado para o time. Ent?o calcule o peso de duas decis?es.

The right systems should be considered and reconsidered as the system changes and evolves, putting as top priority the automation of processes to become more error-prone. Older systems should be either migrated to latest/current system technology, which should be maintainable, either continued to be used as before , but only after auditing that they are still relevant to current processes and day-to-day procedures, not posing any risk to the organization or increasing technical debt of the system.

Sometimes using several tools (the new and the old one) for the same purpose is unavoidable, since it is not possible (or it does not worth it) to migrate smoothly to a modern one. It can be annoying and tedious to deal with redundant data or performing doble tasks, but this has to be seen as daily bussiness and taken into account when evaluating the tools to be used.

Effective documentation and communication are vital when dealing with legacy systems. Document any changes made, challenges encountered, and solutions implemented. Clear communication with stakeholders about the implications of these changes ensures alignment and support. Regular updates help in managing expectations and facilitate collaboration.

Documentation is indeed a must, in code and as reference, not only for legacy code, but for any code. Coding and documenting the code should come together (though unfortunately most developers do not follow this). Remember that people move, roles change, and you might find yourself sitting with a legacy design / code already implemented on a customer site, without any developer who worked on it. In such cases, maintaining the legacy release for existing customers can be a headache, as we can't just go and replace the application.

Thorough documentation capturing the system's architecture, changes and issue resolutions is crucial. Based on previous projects I have been part of, a key piece of information that has been valuable has been to maintain a repository of past issues to aids troubleshooting and to ensure a smooth transition when dealing with legacy systems.

Na Documenta??o de um sistema, a comunica??o clara e mais aberta, em canais fáceis como discord, slack, é uma forma mais democráticas para integrar o time e facilitar as mudan?as.

Setting clear and realistic expectations allows the work to be broken down into manageable delivery horizons and aid is iterating for tangible value that can be demonstrated and evaluated along the way.

Working with legacy systems is an ongoing learning process. Continuously seek to improve your understanding of the system and the skills required to work with it. Stay updated on new approaches and technologies that can be applied to legacy systems. Learning from each project and adapting your approach is crucial for long-term success.

While working with Legacy systems, you must identify the small components which can be refactored over time and even upgraded. If the Legacy system is a monolith, you can not do much about upgrades, however, if the legacy system follows service oriented architecture, you can smartly pick services and upgrade the code and tech stack, while making sure the existing functionality and interfaces remain intact.

I would add a chapter for proper version control and configuration management. When having multiple versions of a file (being this a requirement, code, document, test file, test result, system problem report file...) it is crucial to control which point of the development is refered to, regarding date, branch, product... in order to enable the other actions: understanding the system, backwards compatibility, traceability, documentation, collaboration, improvement...

Some additional points to be considered are: - Proper Risk Management: Legacy system may have different types o risks involved. Such as not having clear boundaries between the functional and technical parts. Another risk is poorly managed dependencies between components and inefficient data management. These all risks should be accounted while planning enhancements, modernisation and integrations. - Extra Security: In-general these systems are not designed to face current world vulnerabilities and potential cyber attacks. - Building a dependable resource base: finding individuals trained in legacy systems is tough. We need to invest in trainings to make sure that we have a pool of resources capable to manage the system.

Consider the impact of changes on users and other systems. Ensure backward compatibility and minimal disruption. Engage with other experts who have experience in legacy systems for insights and best practices. Additionally, be prepared for unexpected challenges and have contingency plans in place. Balancing innovation with stability is key when dealing with legacy systems.