How do you evaluate and review legacy software architecture?

1 Assess the goals and context

The first step is to understand the goals and context of the legacy software architecture. What are the functional and non-functional requirements of the system? What are the business and technical constraints? Who are the stakeholders and users? How does the system fit into the overall enterprise architecture? Answering these questions will help you define the scope and criteria for the evaluation and review.

3 Analyze the quality attributes

The third step is to analyze the quality attributes of the legacy software architecture. Quality attributes are the properties or characteristics of the system that affect its performance, reliability, security, usability, or maintainability. You may use tools such as metrics, checklists, scenarios, or patterns to measure and compare the quality attributes of the architecture. You may also use tools such as surveys, interviews, or feedback to gather the opinions and experiences of the stakeholders and users.

4 Identify the issues and risks

The fourth step is to identify the issues and risks of the legacy software architecture. Issues are the problems or deficiencies that affect the quality or functionality of the system. Risks are the potential threats or uncertainties that may harm the system or its stakeholders. You may use tools such as issue trackers, risk matrices, or impact analysis to prioritize and document the issues and risks of the architecture. You may also use tools such as root cause analysis, fault tree analysis, or SWOT analysis to understand the causes and effects of the issues and risks.

5 Propose the improvements and changes

The fifth step is to propose the improvements and changes for the legacy software architecture. Improvements are the actions or modifications that enhance the quality or functionality of the system. Changes are the adaptations or transformations that update or replace the system or its components. You may use tools such as design principles, best practices, or refactoring techniques to suggest and justify the improvements and changes for the architecture. You may also use tools such as prototypes, simulations, or experiments to test and demonstrate the improvements and changes.

6 Communicate the results and recommendations

The final step is to communicate the results and recommendations of the evaluation and review of the legacy software architecture. You may use tools such as reports, presentations, or reviews to summarize and explain the findings and suggestions of the evaluation and review. You may also use tools such as feedback loops, action plans, or change management to involve and inform the stakeholders and users of the implementation and impact of the improvements and changes.

7 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?