Everybody talks about "Software architecture" these days (your humble servant included...) - but what the hell is it?
I mentioned in my first  SPAMMED Architecture Framework post. that Software Architecture "deals with the major components or structures, their relationships and interactions. It encompasses the major (read hard to change) decisions and their rationale and every system has an architecture (even if it is a default one)" - OK sounds nice, but is it enough?

Probably not (If I thought it was enough - I wouldn't have wrote this post...). There are literally dozens! of definitions for what (solutions) Software architecture is ( you can see many of them here). I am not going to quote all of them, instead, Lets spend some time looking at some of the more prevalent characteristics found in most definitions

• Architecture is Early - It represents (well at least, should represent) the set of earliest  design decisions which are both hardest to change and most critical to get right.
• Every system has an architecture - even if it is just a default one (i.e. it can be described using reverse engineering) it still there.
• Architecture is about breaking a system into components and setting boundaries. It doesn't describe all the components - it usually deals with the major components of the solution. Also it doesn't describe the complete characteristics of components - it mainly deals with their interfaces or other aspects that has to do with their interactions.

which brings us to the next point:

• Architecture is about the relationships and interactions of components. Again we are interested in the  behaviors of the components as it can be discerned from other components interacting with it.
• Architecture explains the rationale behind the choices (vs. the choices not made). It is important to understand the reasoning as well as the implications of the decisions made in the architecture since their impact on the project is large. Also it can be beneficial to understand what alternatives where weighted and abandoned (for future reference, when/if things needs to be reconsidered, and for anyone new to the project that needs to understand the situation).
• There isn't a single structure that is the architecture - there's a need to look at the architecture from different directions or viewpoints to fully understand it.

There's a very interesting standard called IEEE 1471-2000  "Recommended Practice for Architectural Description of Software Intensive Systems"  which defines the relations between the system stakeholders and the different viewpoints of the architecture. It serves as a good reference for understanding how to document an architecture - it also means that identifying the needs of the different stakeholders will tell us a lot what views (details of the architecture from a specific viewpoint) we need to have.

• Architecture is the first design artifact where a system’s quality attributes are addressed

Stakeholders are also the main source for these "quality" requirements and It is the architect's responsibility to balance the quality attributes of the system. This and the previous point are the main reason that the SPAMMED process first step has to do with identifying stakeholders  (And I'll elaborate more on this on the next SPAMMED related post - "Stakeholders Everywhere")

Apart for the quality attributes side of the last point - it also basically state that:

• Architecture is design (but not all design is architecture) 

Which raises another interesting question - what's the difference between architecture and design. But this will have to wait for another post as well