Architecture in a nutshell 1.

Lately I have been trying to get back into my studies on Software Architecture. As a developer I have built many systems with not much afterthought to the architecture of that system. The result of this is that most of what I have built, especially in the beginning was a hodgepodge of things I saw online or copy and pasted into my projects. As I have matured as a developer I have started to think more and more about the quality of the things that I produce. As such it has led me to start trying to study the heart of software architecture and that has led me to the book "Software Architecture in Practice: 3rd Edition" by Bass, Clements and Kazman. What follows is my summary of the introductory chapter. I hope to follow this post with many more but we will have to see how that pans out. 

Software Architecture, a definition 

Like most books on architecture we are introducted to a definition that the book chooses to base its approach on. Unlike folks like Mr. Fowler who could sum up things as the "Important parts", the book chooses to focus on a more clinical and less abstract view of what architecture is. Bass, Clements and Kazman state that software architecture is "The structures needed to reason about the system." While this may seem as abstract as finding the "important parts" the reasoning behind this wording is the difference in approaches. First they state that the definition is different in that it focuses on the structures themselves instead of our assessment of their relative importance. A second reason for this approach is that the argument is made that structures are easier to reason about. 

Structures, elements and whatnot

So, we now know that the authors are pushing the concept of structures as a defining aspect of architecture. So what is a structure? In the most succinct language an architecture is a "Set of elements held together by a relation". So elements are the building blocks of architectures. Elements are the bits and bobs of your system, they could be classes or modules or libraries. What is considered an element depends mainly on what layer of abstraction you are looking at. A high level could see a pdf library as an element of a large architecture. While a low level would see something like a single method inside a class as an element of an architecture. 

So to further this idea the authors separate the concept of structures into three distinct categories. 

  • Modules: These are structures that are given responsibilities in the system. They often form the basic for the divisions of work in teams. 
  • Component and Connectors: These are described as the runtime structures. They are essentially the way in which components interact while the system is being run. 
  • Allocation Structures: So this type of structure is more geared towards describing the way the system will be deployed. It's environment, operating system requirements, and requirements that are more physical in nature. 

Something that needs to be mentioned here is that the authors go out of their way to include certain assertions when it comes to what architecure is in this book. The first is that they want readers to understand that software architecture is an abstract process. Because you examine every aspect of a system at the same time it's important to realize that your architecture is not going to include every possible view. Some things will have to be left up to the developers or are just simply not important enough to be documented. The next is that whether you like it or not, every system has an architecture. It may not be documented or documented poorly but it is there. Just because its not documented does not automatically make it a bad architecture. Another thing to remember here is that you have to document the behavour of the system as well as its modules and parts. Because the behavour of a system can be used to reason about the system its something that must be included in the documentation of the systems architecture.