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

What makes a good (software) architecture

Lately I've been investigating software architecture with regard to how it can impact on an agile development project. I recently read (here) a very short list that resonated really powerfully with me and describes key architectural virtues (explanations are mine):

  • Strength - reliable, secure, resilient to change
  • Utility - must deliver either business value or (more likely) developer productivity
  • Beauty - easy to understand and communicate, clean design, minimal

It turns out that these ideas have been around for quite a while, under their Latin names of firmitas, utilitas and venustas.

I hope to produce a series of blog posts detailing my thoughts and expanding on some of these points, including why I think this question is especially relevant to iterative development.

September 11 2007

An architect is like ... Polyfilla

A colleague insisted that everyone knows what an architect does.  More by nature of a comparison than from wanting to assume the label of "architect", I said "Well, what I do when I join a team is to try and fill whatever holes there are and then do what it takes to ensure delivery".  To which he replied "And that's it in a nutshell".

I find that quite an unsatisfying definition of an architect.  I've met people in the past who are clearly very good architects, in that they can come up with system designs which are incredibly simple and yet solve the business problems at hand in a very powerful way.  I think that someone like this does more than just fill in cracks.

 

[small print: Polyfilla is a registered trademark of Polycell]

November 27 2006

Partial architectures are dangerous

Once development work begins on a project, there is no such thing as a partially designed architecture - there are only partially complete architectures and these are dangerous.  Let me explain the distinction and why it's important.

Firstly, let me admit that an architecture can definitely be partially designed - but only while the architect is working on it.  This can happen on whiteboards, on paper, in Visio, in the Visual Studio class designer, in someone's head or in any number of other places.

Risks of a partially complete architecture
When development work begins, it will (hopefully) be in line with the current view of the architecture.  As soon as the first line of code is written, modifications to the architecture have to be called "changes" - there will (most likely) be changes required to the code to bring it in line with the new architecture.  And here's the key point - it's a new architecture.  It's not just the old architecture fleshed out a little bit.

Now you may think I'm splitting hairs here, but once development work begins it gets increasingly more expensive to change the architecture.  This exponential increase in cost generally continues as development progresses.  So revisions to the architecture can be costly.  And this means there's a temptation to cut corners, which would translate into the development team not changing the code to completely match the new architecture.  If this happens, you'll have a hybrid architecture which is neither the old one or the new one and heaven help you when you want to change the architecture yet again!

The other real risk of a partially complete architecture is that one of the developers may get to the "edge" of it and try to keep going.  In other words, they will encounter a problem, realise that it isn't handled within the current architecture and come up with their own point solution to it.  When a different developer hits the same problem, communication within the team may or may not be good enough for them to realise that it has already been solved.  If it isn't, then they will also come up with their own solution.

Am I being too precious?
Now I know that so far I sound quite precious about my architecture design, as if I don't want other people making decisions.  That isn't really the case.  I just want to be involved in the decision-making because it's my responsibility to try and ensure that all the decisions contribute to the bigger picture.  As David Armour writes, agile development teams can often just plough ahead delivering functionality without giving any thought to architecture.  This is the kind of project that I don't want to be involved in.

I'm also trying to mitigate the risks of a lack of development discipline (i.e. architectural changes not being completely worked through) and poor team communication (i.e. the team doesn't know that a particular problem has already been solved by someone).  Isn't it strange how these "soft" issues can have very direct impacts on our development processes?

Is there another way?
The other point I should make, is that some project teams take a different approach to this problem.  James Shore talks about Continuous Design and the mindset you need to operate in this way.  This approach sounds appealing to me, but still doesn't get around the fact that somebody has to have the bigger picture view, they have to know that it is accurate and they have to let it influence the decision-making process.

August 15 2006
Older Posts