Skip to end of metadata
Go to start of metadata

First we need to define what "software architecture" means, and this is no easy task

Martin Fowler discusses some definitions in his Who needs an architect? article. One definition is the following:

The architecture of a software system (at a given point in time) is its organization or structure of significant components interacting through interfaces, those components being composed of successively smaller components and interfaces.
--RUP/IEEE

Fowler seems to agree with Ralph Johnson (of GoF fame), that it is important to understand that there is also a social aspect to software architecture, as described below. Ralph Johnson provides 3 definitions of software architecture:

1) In most successful software projects, the expert developers working on that project have a shared understanding of the system design. This shared understanding is called 'architecture.' This understanding includes how the system is divided into components and how the components interact through interfaces. These components are usually composed of smaller components, but the architecture only includes the components and interfaces that are understood by all the developers.

2) Architecture are the decisions that you wish you could get right early in a project.

3) Architecture is about the important stuff. Whatever that is.
--Ralph Johnson

What is good software architecture?

A good software architecture must ensure that the system is designed in such a way that both the functional and non-functional requirements of the system are met. Grady Booch coined the term FURPS as a mnemonic for the different categories of system requirements:

  • Functional — features, capabilities, security.
  • Usability — human factors, help, documentation.
  • Reliability — frequency of failure, recoverability, predictability.
  • Performance — response times, throughput, accuracy, availability, resource usage.
  • Supportability — adaptability, maintainability, internationalization, configurability.

In addition, there might be requirements such as:

  • Re-use-ability - whether parts of the system should be designed to be re-used by other applications.
  • Operations support - functionality and qualities that ensure that the application can be managed and monitored satisfactory in its operational setting.

The "goodness" of an architecture should always be measured against the requirements. A simple design with poor scalability qualities might be the correct architecture in one case, and a very wrong architecture in another.

Architecture principle index
Page: It is all about the data
Page: Software Orthogonality
Page: Scalability Axiom no 2 - CAP theorem
Page: A software architect is a part-time Archeologist — Title says is all, really
Page: A software architect is a part-time Archeologist — Title says is all, really
Page: Build to excel, buy to support
Page: Availability Over Consistency
Page: Scalability Axiom no 1 - Utmost scalability
Page: Scalability Axiom no 3 - Divide and Conquer
Page: Clear and consistent responsibility power all great architectures
Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.