Software Architecture

There are a lot of different opinions and discussions of what exactly Software Architecture is. I personally like the definition from Bass, Clements and Katzman:

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

The definition of IEEE (IEEE 1471) is more comprehensive in the sense that it includes the explicit connection to both the context and the underlying principles:

“The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.”

What is then the goal of Software Architecture? In my opinion, first and foremost a Software Architecture is a solution which tries to maximize different (sometimes competing) objectives under a given set of constraints. As a result, the Software Architect needs to balance a large number of factors, such as economical, technical, political, social and aesthetic under technology, personnel, schedule and budget constraints.

Regarding the deliverable of Software Architecture, this is the “Architecture Description” (IEEE 1471), sometimes referred to as the “Architecture Blueprint”. The Architecture Description is a collection of views which present different perspectives of the same architecture blueprint. There is, however, no consensus about the set of views which must be included in an architecture description. The Zachman Framework, defines 36 views while the Rational Unified Process (RUP) defines 4+1 view models.

There are usually more than one possible valid software architectures solutions for a given problem. It’s important to stress the point that that an architecture can not be judged or evaluated unless the context of the problem on which it was developed is well understood. Based on that context, architecture alternatives can be assessed and compared against each other. Bass, Clemens and Katzman propose a methodology called Software Architecture Analysis Method or SAAM for short. Microsoft, in MSF v4 for CMMI Process Improvement, offers a similar methodology called Lightweight Architecture Alternative Assessment Method (LAAM). Essentially, each architecture alternative is evaluated and ranked according different project specific attributes, such as: performance, scalability, reliability, availability, usability and functionality under constraints such as technology, resources, cost and schedule; and against project business objectives, such as: return on investment, time, budget and risk. This provides a structure and systematic methodology which should be documented for future reference.