Architecture Review
Introduction
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.
Background
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:
Ø
Authorization - 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
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 localization
Ø
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)
Testability
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.
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
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 behavior.
Real-time monitoring.
Typical Design/Architectural
principles:
v
Tracing support
v
Logging in exception handling
mechanism
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
Comments
Post a Comment