Like any other complex structure, software must be built on a solid and well-designed foundation. Failing to consider key scenarios, failing to design for common problems, or failing to appreciate the long-term consequences of key decisions can put your application at risk.

There are many guides and checklists available online to help teams conduct fruitful architectural reviews. Below is a general guideline to highlight the key components necessary for a successful architectural analysis.

Review Early

Ideally, the review takes place as early in the design stage as is reasonably possible. You want to conduct the analysis when the architecture is specified, but before anything has been implemented. The goal is to identify potential issues with the architecture before the construction phase, while any flaws are still relatively easy and inexpensive to correct.

That being said, a review can be conducted at any stage in the lifecycle of a system. For projects using an iterative development approach, an analysis can take place with each iteration if architectural decisions are being made. Reviews can also be conducted on legacy systems to assess their ability to support future business objectives.

Be Specific

Define the scope of the analysis before the review meeting. The scope describes the quality attributes that will be analyzed during a review.

Reliability, security, availability, extensibility, and manageability are all quality attributes that can be considered in an architectural analysis. Keep the review manageable and useful to your project by defining the scope and objectives of the evaluation before the meeting.

Define Measurements

Based on the scope, create a list of the specific criteria to measure the architecture. The list might include system-wide properties, significant functional requirements to deliver, and general attributes of quality architectures. For small-scale evaluations, a simple checklist could be enough, but most analysis will more in-depth.

A proven technique involves the use of scenarios, which allow the quality attributes to be evaluated in specific contexts. Walking through the steps of a scenario provides you with the opportunity to describe how an architecture will respond to specific demands.

For example, performance is a quality attribute that ends up on most evaluation criteria lists. To evaluate the architecture, the performance criteria must be stated. An example could be the system’s ability to deliver 3,000 lookup requests and 4,000 transactions within a four-hour period, with a peak load of 15 percent of the transactions taking place in a 45-minute window.

Report the Findings

After the analysis is conducted, the final step is to document and communicate the findings to the project team. The report should include the scope of the review, review objectives, architecturally significant requirements list, findings and recommendations, and an action plan.

It is important to provide recommendations that are actionable. The intention of the analysis is to uncover potential issues. If recommendations are too generic to be implemented, the analysis will not contribute to the success of the project.

The report should be continually reviewed during the product lifecycle to ensure the current architecture of the system still meets the goals laid out in the original analysis. This process provides guidance for future features and determines when a new architecture change is needed.

Learn More

Check out our white paper, Benefits of a Well-Planned Architectural Analysis, to learn the business implications for a successful architectural analysis.