Architecture Review Process

A formal "Architecture Review Process" can be a very efficient way to understand how the existing system work via interaction with existing developers and architects who has good understand on different parts of the existing system. If these people doesn't exist (maybe left the company already), then a different reverse engineering effort need to be taken instead.


It is usually involved a number of key persons

• A facilitator who orchestrate the whole review process and control the level of depth at different stages (lets say I am playing this role here)
• A recorder who documents key concepts, ideas, observations and outstanding issues (me playing this role also)
• Key architects and developers who understand the details of the legacy systems, and be able to show you the code if necessary.
• Business domain experts who understand every details of how people use the system to complete their job, what are their current pain points and what feature will help them most. This person also helps to set priorities between conflicting goals.

The architecture review process has the following steps.

Use Cases and Actor
From the business domain expert, we focus in the "actors" (who use the system) as well as the "use case" how they use it.

Activity Analysis
Drill down from each use case, we focus in the detail activities that each actor carries out to fulfill each use case. How they interact with each other as well as the system, what is the duration of the whole flow and what is the measurement of the efficiency of this flow.

Component Analysis
With the key architect and developers, we dissect the whole system into components. For each component, we look at
The responsibility of each component
The interface of each component
Get a sense of the code quality. Looking at some of the major classes and methods.

In case if the people who is familiar with the code base already left the company, then a longer reverse engineering process need to be conducted.

Change and Extensibility Analysis
Understand the parameters that affects the behavior of the system. Under different scenarios of changes, can the system still serve by just changing those parameters. Get a sense of how extensible the system can be based on what are those configurable parameters are. For example, does the system hard code business rules or using some kind of rule engine ? Does the system hard code the business flow or using some kind of workflow system ? What if the system need to serve a different UI device (like mobile devices) ?