Architecture Review Process
Join the DZone community and get the full member experience.
Join For FreeA 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
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) ?
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.
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) ?
Architecture
Published at DZone with permission of Ricky Ho, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
Effortlessly Streamlining Test-Driven Development and CI Testing for Kafka Developers
-
Design Patterns for Microservices: Ambassador, Anti-Corruption Layer, and Backends for Frontends
-
Observability Architecture: Financial Payments Introduction
-
Top 10 Pillars of Zero Trust Networks
Comments