SAIP: What is Software Architecture?

What Software Architecture Is and What It Isn't

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

The definition above fits well with the other definitions that we have seen so far especially the one from Garlan and Shaw's Introduction to Software Architecure. However, there are some subtle yet distinctive points about this particular definitions:

• Systems can consists of more than one structure.
  For large systems, there can be many structures. And not one of them is the software architecture for the system. As we have seen in the 4+1 paper by Krutchen, there can be indeed different views for the same architecture with each view contributing toward a different structure.
• All computing systems have a software architecture
  Even if the architecture is a Big Ball of Mud. It might not be describable, but an architecture definitely exists. And the definition does not discriminate against bad or good architecture.

Three useful terms are defined in the book that will be pivotal to the discussion of software architecture:

• An architectural pattern is a description of element and relation types together with a set of constraints on how they may be used.
  It's interesting to note that this chapter considers client-server as an architectural pattern and not a software architecture. In this book, the term architectural pattern is synonymous with architectural style. I suppose that the patterns describe in Patterns of Enterprise Application Architecture would fit this category. The original 23 design patterns from the Gang of Four might fit in here as well though some of them are pretty low-level and does not address the system as a whole.
• A reference model is a division of functionality together with data flow between the pieces
  A reference model is an abstraction of how the system should function. For me, I think of it as a metaphor for the system. For instance, if I want to represent an XML document, I might conceptually think of it as a tree since all the nodes can be nested within one another. So to actually use an XML document, I will need a reader, writer and some internal representation. That is the conceptual idea I have of a an application that uses XML. I do not have a definite design or implementation for the reader, writer or the internal representation yet.
• A reference architecture is a reference model mapped onto software elements and the data flows between them.
  It simpler terms, it tries to connect the architectural pattern and the reference model. Once you have that mapping (the reference architecture) you are in a better position to actually solve the problem at hand. For instance, to solve a database problem, I can relate my database schema to the Active Record pattern.

Here is a picture to make things clearer.

So why do we need software architecture? Krutchen already discuss how it gives a representation of the state of the software to the stakeholders. And in Chapter 1, we saw how an architecture helps stakeholders make decisions about the future stage of the software development.

Furthermore, software architecture is also important because it's the earlier manifestation of the design decisions that go into the software. With this software architecture, developers have a better sense on how to organize the structure of software, how to handle changes and how to proceed in the next iteration. Though at the early stage, this manifestation is most probably incomplete and even inadequate, the software architecture serves as an early model for which to base future cost and schedule estimation.

Another importance of software architecture as given by the book is the fact that it is a transferable abstraction of the system. While this is definitely possible, I would argue that architectural patterns (defined above) are more transferable than software architecture because in a software architecture the parts are more detailed and concrete already. As can be seen from figure 1 above, software architecture is the product of the reference architecture stage. As you recall, the reference architecture stage provides the mapping between the abstract architectural patterns and the reference model. Therefore, I believe that some level of abstraction has been lost. Instead, I think that the software architecture might provide a good example of the use of the architectural pattern. But the architectural pattern is the high-level description that should be shared amongst developers.

This chapter also proposes some alternative views for representing software architecture in contrast to Kruchen's 4+1 view. These forms of representations become increasingly important as systems grow more complex. It is no longer possible to represent the entire architecture with just one diagram. By using multiple diagrams, each structure of the software architecture becomes clearer. It becomes easier to identify the important elements for each structure.