I'm going to define a software systems architecture as
the set of principal design decisions about the system. Where
principal here, implies a degree of importance, that grants
a design decision architectural status. And the point here, as
we discussed with Neno early on, is that when
building a system, we make tons of design decisions, and
most of them do not affect the architecture of
the system. For example, the effect of choosing a for
loop, instead of a while loop, in the code, or the
fact of deciding that we are going to use data structure A
instead of data structure B. Some decisions however, do affect the
architecture of the system. And in some cases the distinction between these
two kinds of design decisions is clear. In some other cases
it is much fuzzier and it depends on the context. The
bottom line here, is that if you believe that something is
an important design decision, that becomes an architectural decision. That is a
decision that impacts a system's architecture. In this spirit,
we can see a software architecture as the blueprint
for a software system, that we can use to
construct and evolve the system. And the key point
about software architecture is that this blueprint encompasses every
facet of the system under development. It encompasses its
structure, of course, but not only. It also involves
the behavior of the system, the interactions within the system,
and the non-functional properties of the system. And we will see
how this happens in the rest of the lesson. Another important
point about software architecture is that there is a temporal aspect
to it. And the point here is that you don't build the
software architecture in a single shot, but you do it iteratively,
over time. So, basically, you go from having no architecture to
your final architecture. So, at any point in time, there is
a software architecture, but it will change over time. And this happens
because design decisions are made, unmade and changed over a system's lifetime.