Exploring quality in software architecture

Strength, utility and beauty.  Here we will be exploring a number of the traditional “ilities” of software architecture and seeing how they can be related to these three architectural qualities.  These three qualities have been around for quite a while, under their Latin names of firmitas, utilitas and venustas, and were first written about by Vitruvius.

Now architecture is always created with the intention of supporting something, e.g. an application (in the case of application architecture) or a business (in the case of enterprise architecture).  For brevity, I’ll refer to “the thing which the architecture supports” as “the system”, although I believe that my points here relate to all types of software architecture.

Utilitas, or Utility: Functional and behavioural aspects of the architecture

The architecture needs to guarantee that the system can perform operations in a certain manner.  Architectural aspects which achieve this are:

·         Availability – expected levels of uptime that the architecture can provide

·         Auditability – keeping a log of changes and operations within the system.

·         Correctness and verifiability – sometimes operations within the system can be externally verified.  The architecture needs to support and pass such verification.

·         Environmental compatibility – the architecture needs to fit into its environment, e.g. there may be a high latency network which needs to be considered

·         Performance – how quickly operations can be performed

·         Security and confidentiality – authentication and authorisation

·         Transactionality – the architecture needs to ensure that operations are atomic

A person can only really be called an architect if they can design an architecture that works, i.e. displays these aspects.

Firmitas, or Strength: Non-functional aspects of the architecture

In addition to supporting the operations of the system, there are a number of further considerations for architecture:

·         Adaptability – how well the architecture can cope to evolving situations without being changed

·         Efficiency – how well does the architecture use its resources such as CPU, memory, bandwidth, etc

·         Extensibility – how easily can the architecture be extended and changed

·         Maintainability – this is really just a combination of extensibility and understandability.  If an architecture is easy to understand and easy to change, then it is easy to maintain.

·         Recoverability – is it possible to reconstitute the state of the system after a disaster

·         Reliability – how stable is the architecture under normal circumstances

·         Resiliance – how stable is the architecture under abnormal circumstances

·         Scalability – can the throughput of the system be increased without requiring changes

·         Understandability – how easy is it to comprehend the architecture

Really good architects manage to incorporate these aspects into architecture they design.

Venustas, or Beauty: Aesthetic aspects of the architecture

Beauty, as a quality, is practically impossible to define objectively.  “Beauty is in the eye of the beholder”, as the saying goes.  However, you do know beauty when you see it.  Here are some points which I think contribute to making architecture beautiful:

·         Conceptual integrity – sometimes called the principle of least surprise, there should be an underlying theme or vision that unifies the design of the architecture at all levels

·         Elegance – closely related to simplicity, elegance implies a certain understated effortlessness

·         Simplicity – an architecture should be as simple as possible, but not simplistic

An architect that can incorporate these aspects into a design that also displays utility and strength, is really one of the greats.

And so what?

And so we have a bit of a framework for inspecting the quality of architecture.  I don’t regard all of these aspects as quantitative, but at least we can discuss architecture in qualitative terms.  In my next post, I’ll be discussing some of the specific considerations of iterative development of software and how these points here should influence that process.

October 19 2007
blog comments powered by Disqus