Click here to Skip to main content
15,945,344 members
Articles / Containers / Virtual Machine

Software Architecture Review Guidelines

Rate me:
Please Sign up or sign in to vote.
4.58/5 (21 votes)
12 Sep 2007CPOL7 min read 151.5K   86   4
This text tries to bring together elements a reviewer can use in his/her software architecture review.


Reviews are an opportunity for others to eyeball your documents/design/code/software architecture and for you to inspect others' work. They facilitate knowledge interchange. But their primary goal is to increase software quality. They help you to spot faults before they become real disasters. This text tries to bring together elements a reviewer can use in his/her software architecture review.


If you want some formal definitions what a software architecture is, I recommend reading the information here.

The general tone in these definitions is that you need to make high-level decisions about the system you're going to build:

  • What style are you going to use? What is the structure?
  • How is it going to function? How do structural components of the architecture work together?
  • How does it meet the needs of all the stakeholders?

For an existing system, you can detect these key factors that will give you an idea of the software architecture. An approach in evaluating software architecture is reasoning about the quality attributes a software architecture exhibits.

In the bullets below, I tried to sum up the different quality attributes together with some typical things to look for when you're conducting a review. This list is not intended to be exhaustive. Maybe you also have ideas that you would like to share ....?


The time required to respond to stimuli (events) or the number of events processed in some interval of time.

Typical Design/Architectural principles to look for:

  • Connection pooling - reducing the execution time overhead associated with establishing database connections by establishing a shared pool of connections
  • Load balancing – spreading the load evenly between a set of resources
  • Distributed processing
  • Caching – using a local copy of data to reduce access time
  • Lazy instantiation
  • Transaction Concurrency
  • Process isolation between OLTP and OLAP
  • Replication of data

Typical unit of measurement you could use:

  • Transactions per unit time
  • Amount of time it takes to complete a transaction


The ability of the system to keep operating over time in the context of application and system errors and in situations of unexpected or incorrect usage (to perform in a predictable manner).

Typical Design/Architectural principles to look for:

  • Using preventive measures (administration) e.g. recycling of server processes in IIS.6 ASP.NET /COM+ 1.5
  • Containment - COM+ server process isolation
  • Database transaction logs (rollback)

Typical unit of measurement you could use:

  • Mean time to failure


The proportion of time the system is up and running.

Typical Design/Architectural principles to look for:

  • Fail-over - make the system more available as if one server instance is down, another instance can take over the work.
  • Transaction Manager - it improves availability and reliability by helping to ensure that the system is always in a consistent state and by providing a system-wide strategy for handling certain classes of failures.
  • Stateless design - When a particular stateless server fails, its work can be re-directed to a different server instance without implications for state management.

Typical unit of measurement you can use:

  • Length of time between failures
  • How quickly the system is able to resume operation in the event of failure.


Measure of the system's ability to resist unauthorized attempts at usage and denial of service.

Typical Design/Architectural principles to look for:

  • Authorisation - How is the control access to information in the system organized once a user is identified and authenticated? (Role based ACL)
  • Authentication - Identification and representation of end-user in your system and verification if he is telling the truth?
  • Auditing - Verification and monitoring of the security policy
  • Integrity - Protection against improper or undetected modification of information in transmission or storage? (encryption)
  • Confidentiality - Protection against improper disclosure of information during transmission and storage (encryption)
  • Denial of Service - Continuity of services? (intrusion detection)
  • Data isolation (general public apps versus internal LOB apps)


Ability to make changes to a system quickly and cost effectively.

Typical Design/Architectural principles:

  • Client-server (separation of concerns) – This mechanism involves providing a collection of services from a central process and allowing other processes to use these services through a fixed protocol.
  • Independence of interface from implementation – This mechanism allows architects to substitute different implementations for the same functionality.
  • Separation – This strategy separates data and function that address different concerns. Since the concerns are separate, we can modify one concern independently of another. Isolating common function is another example of a separation strategy.
  • Encoding function into data meta-data and language interpreters – By encoding some function into data and providing a mechanism for interpreting that data, we can simplify modifications that affect the parameters of that data.
  • Run-time discovery no hard-coded connection strings, queue names, etc.

Typical unit of measurement:

  • Using specific changes as benchmarks and recording how expensive those changes are to make


Ability of the system to run under different computing environments. Sometimes considered as special kind of modifiability.

Typical Design/Architectural principles:

  • Virtual machine


Ability of the system to do the work for which it was intended.

Typical unit of measurement:

  • Number change request


New feature implementation/replacement of components with improved versions and the removal of unwanted or unnecessary features or components.

Typical unit of measurement:

  • Easy, incremental addition of functionality (time, budget, etc.)
  • Coupling/cohesion

Conceptual Integrity

Underlying theme or vision that unifies the design of the system at all levels.


Interaction with other sub-subsystem, or a well defined access to externally-visible functionality and data structures or interaction with other run-time environments.

Typical Design/Architectural principles:

  • Simple data-types
  • XML
  • Web services


How easy is it to use the program?

Typical Design/Architectural principles:

  • GUI standards between product line

Typical unit of measurement:

  • Number of errors made by a user familiar with prior releases or other members of the product line.


Problem fixing, repairing a software system after errors occur.

Typical unit of measurement:

  • Easy localisation
  • Ripple effects of change


Deals with the use of the resources available for execution of software, and how this impacts response times, throughput and storage consumption.

Typical Design/Architectural principles:

  • Acquire late, release early
  • Reducing round-trips
  • Lowering traffic throughput (only send what is necessary, only retrieve what is necessary)


How easy is it to test code a unit, sub-systems, etc.

Typical design/architectural principles:

  • Interface based programming
  • Inversion of control/Dependency injection
  • Classes with well defined responsibilities


On SW arch level, the ability to reuse the SW architecture for another application.
On code level, framework aspects.

Ease of Deployment

How quickly can you deploy the system?

Typical measures:

  • Installer programs (wizards)

Typical unit of measurement:

  • Can be measured by the time and resources required to install the product and /or distribute a new unit of functionality

Ease of Administration

Refers to the infrastructure, tools, and staff of administrators and technicians needed to maintain the health of the application. E.g. Change physical location of service with minimal impact on the rest of the system.

Typical unit of measurement:

  • Decreased Support Cost: can be measured by comparing number of help desk calls for a standard period of time.


Number of user changes while maintaining other qualities. Support continuous growth to meet user demand and business complexity. It must be possible to extend the minimum hardware configuration needed for the application with additional hardware to support increased workloads.

Typical Design/Architectural principles:

  • Stateless design
  • Load-balancing
  • Concurrency (optimistic)

Debug-ability /Monitoring

Preparing application for easy and efficient debugging . Registration of abnormal behaviour. Real-time monitoring.

Typical Design/Architectural principles:

  • Tracing support
  • Logging in exception handling mechanism

Development Productivity

Cost and time saving mechanism to aid development of applications based on the software architecture. The developers should be able to learn the architecture concept and how to implement it easily. Extending the development team with new developers should not cost much effort in instruction, etc. A standardized way of working using templates and coding standards could help raise both the learning curve and quality.

Typical Design/Architectural principles:

  • Framework
  • Templates /code generation
  • Best practices Coding checklist & standards


  • 13th September, 2007: Initial post


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Written By
Software Developer
Belgium Belgium
Alexander Nowak is .NET application developer working for Capgemini Belgium. Topics of interest are .NET Application architecture ,design and programming as well as Software development practices.

Comments and Discussions

GeneralMy vote of 5 Pin
Mohammed Hameed9-Jun-13 9:08
professionalMohammed Hameed9-Jun-13 9:08 
GeneralMy vote of 4 Pin
Sudhakar Shinde1-May-13 21:51
Sudhakar Shinde1-May-13 21:51 
Generalhelpful article Pin
BillW3314-Sep-07 3:43
professionalBillW3314-Sep-07 3:43 
I am pleased to see an article on software review. Review is a very valuable technique, which is underutilized. Too little has been written on how to do a proper review.

Bill W
GeneralRe: helpful article Pin
Alexander Nowak24-Sep-07 5:28
Alexander Nowak24-Sep-07 5:28 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.