More Defining of Software Architecture

I’ve been reading a lot of books on software architecture recently and I’m amazed at how many definitions there are of “Software Architecture”. This blog post will look at the ones I’ve come across and critique them.

First is from the IEEE that I’ve been using a lot and had assumed it was being used every where (no it is not):

• Software architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.
  (IEEE 1471-2000)

I use this one a lot but this one doesn’t mention dynamic behavior although “relationships” although that could be interpreted in different ways. The elaboration of this definition defines various qualities of the system like performance which is related to dynamic behavior. Perhaps dynamic behavior is too closely related to functionality where the architecture is not?

From Wikipedia:

• ^· The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both. ^[1] The term also refers to documentation of a system's software architecture. Documenting software architecture facilitates communication between stakeholders, documents early decisions about high-level design, and allows reuse of design components and patterns between projects.^[2]

The one objection I have to this definition because software architecture designs are often not early in my experience. Some decisions must be made early but others need feedback from implementation before they can be made.

From the book Software Architecture in Practice (2nd edition), Bass, Clements, Kazman; Addison-Wesley 2003:

• The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

Again – we’re missing the dynamic behavior of the system.

In Just Enough Software Architecture, George Fairbanks says that “Architecture is mostly orthogonal to functionality”. He compares architectures to skeletons and points out that some architectures are more suited to certain functionality than others. Perhaps this is why the dynamic functional behavior is often left out.

One of my favorite definition isn’t from software domains , but is from A Taxonomy of Decomposition Based on Structures, Behaviors, and Goals, Koopman, Design Theory and Methodology ’95:

• ·System Architecture should contain goals /requirements artifacts, and structure and behavior artifacts based on those goals

This has more to do with documenting software architecture but it covers my main three points that I like to see. It doesn’t say anything about a set of rules like the IEEE definitions does. Rules governing the architecture are very useful in my experience and can evolve over time. The rules govern the teams design decisions and given meaning to any assumptions and constraints. If those constraints change, often the rules can change.

The Software Engineering Institute comprised this web site to answer the question: http://www.sei.cmu.edu/architecture/start/definition-form.cfm. I’ll be adding this last definition.