Software Architecture: What is it?

I can still clearly remember the first program I’d ever written. It was the most traditional first program: Hello World! I was working my way through a Dutch book on Java 6 and eventually created my very first calculator. Creating a window with JFrame, positioning the buttons with actual pixel coordinates, methods containing the business logic, all in one single class. It was small, but it sparked my interest, and it was the start of what made me who I am today.  

Now, this little analogy might sound silly because I hear you wondering: what on earth does this story have to do with software architecture? Allow me to elaborate. We all started small, putting everything in just one class. In the beginning, we could afford ourselves to do that because our programs were small and hardly did anything complex. My calculator could add numbers, subtract, multiply, and divide. The UI was also not ground-breaking rocket science: ten number buttons and four buttons for each calculation, and a label that showed the calculation and the result.  

Since the program was rather simple, it is easy to program everything in just one class file. However, after a while, you become more proficient at programming, and your programs evolve and grow. That one class file becomes huge and difficult to navigate through. In order to organise things a bit, you can split the file into multiple files. One class for the UI and one or more classes for the business logic. The more your program grows, the more files you need.  

Eventually, your program has reached a new all-time high. Multiple files, some for UI, some for business logic, some for communication with databases, APIs, services, you name it. But this whole cluster of files becomes unclear after a while as well. Just like that one large class file, you now have one extensive directory with multiple files scattered all over the place. How will you organise this mess? 

Software architecture will help you out here. Software programs are like houses, it consists of multiple components that work together to become one unit. An architect designs houses before the builders start building because the architecture serves as a blueprint for the builders. It works almost the same with software architecture. It is a very high-level blueprint of what the software should look like. It is also often seen as the foundation of software. Everything eventually comes down to the software architecture. If the architecture changes, everything in the software changes along with it. All the other models regarding software engineering (e.g. domain, sequence, and component models) are derived from the software architecture. You have to build your walls on the foundation of your house, and this is no different with software. If your domain model does not fit the architecture of the software, things will get difficult very quickly. 

However, do not be fooled; software architecture is hard. There is a big difference between being able to read the software architecture models, to apply them, to understand them, and to create the architecture model for your software. Of course, it all depends on the complexity of the software. Most important are being able to read and apply software architecture. Utilising software architecture is different between disciplines, but I’ll get more in depth about that in another post. 

I had a small 8-week course on reading software architectures, and at the time I thought it was boring as hell. Like my classmates, I didn’t understand the usefulness of the subject. However, I still did my best to finish the course with good grades and pick up as much of it as I could. Honestly, I am glad I did put my effort into the class. Now, I almost get to see architecture models or pieces of the whole model nearly every week, if not almost every day. It has also given me the ability to understand software in general better. Software architecture looks at software from a completely different perspective, and I am slowly adapting that perspective as well. 

Ever since my internship research, I’ve been looking at software from multiple perspectives. Of course, building is tons of fun, hopping from one problem to another and finding solutions for all of them. However, there is so much more to it. A tester looks at software from a slightly different angle to find any problems with the software. Developers often see this different angle as trying to break the software. Software architects are more like a helicopter, hovering over the infrastructure of the software to ensure that the developers build the software according to the architecture.