In a recent developerWorks article, What is a software architecture?, Peter Eeles attempts to capture a definition for the elusive notion of software architecture. Some of the more illuminating portions of this article for me were:

[An architecture] is only concerned with those elements that are deemed to be significant. Significant elements are those that have a long and lasting effect, such as the major structural elements, those elements associated with essential behavior, and those elements that address significant qualities such as reliability and scalability. ... Architectural significance can also be phrased as economical significance, since the primary driver for considering certain elements over others is the cost of creation and cost of change.

Here I felt he captured the idea that the architecture is an abstraction, a high-level view, of the system. It focuses on aspects of the system that are most helpful in accomplishing major goals for the system such as reliability, scalability, and changeability. The architecture explains how you go about accomplishing those goals.

Eerles also pointed out that a system's ability to incorporate change over time is a measure of the goodness of the architecture:

It is also worth noting that the set of significant elements is not static and may change over time. As a consequence of requirements being refined, risks identified, executable software built, and lessons learned, the set of significant elements may change. However, the relative stability of the architecture in the face of change is, to some extent, the sign of a good architecture...

These portions of Peter Eerles article reminded me of the ideas of Luke Hohmann, who, when asked in an interview, "What is architecture?", said:

That's like asking, what is culture? Culture is the way you do things in a group of people. Architecture is the way you do things in a software product. You could argue by analogy, then, that architecture is to a software product as culture is to a team. It is how that team has established and chosen its conventions.

Which leads us inevitably to the question of "goodness". How do you know if an architecture is good? Consider an architecture that isn't built using a strong domain model, and instead relies heavily on stored procedures. That might be OK, or it might not be OK. You could have decided that part of your architecture is to use a really strong domain model and not use stored procedures, right? So an architecture is some reasonable regularity about the structure of the system, the way the team goes about building its software, and how the software responds and adapts to its own environment. How well the architecture responds and adapts, and how well it goes through that construction process, is a measure of whether that architecture is any good.

What's important about software architecture?

I think one of the most important ways to think about architecture is that it is an opportunity to provide leadership. The architecture embodies the decisions of the architects, the leaders, on how things should be done in the project. The architecture should make it easy for people working on the project to do things the right way: the way the architects believe things should be done. In other words, instead of just saying that things should be done a certain way, the architects should design architectural systems and structures that guide the team down that path.

For example, we have made a lot of decisions about how we'll do things in our new architecture at Artima, and we recently captured many of those decisions in some code generators. So instead of just decreeing that entities can be versionable, and that versionable entities will have deletion and history tables that follow certain conventions, we made it so easy to do things that way, that no one will ever be tempted to do it any other way. All you need to do is add the word "versionable" in front of "entity" in the DSL we created for defining entities. The generated code will always follow the conventions exactly.

In other words, not only can the architecture explain the way the team does things in a software project, it should guide the them to do things that way.