SAD(Software Architecture Design), is the decision-making process of figuring out the what, how, and why of a piece of software. It contends the technical, business and operational requirements and presents them in a useful and easy to comprehend manner 1 .
Before delving into more detail regarding what software architecture design entails, I would first like to point out a few reasons why it is important and useful:
First, one of the biggest reasons to design the software's architecture before jumping straight in and coding is that it robs you of the chance to fully consider some aspects of the software's foundation. It will also give you a chance to evaluate the issues the choices might lead to, and does not give you the chance to plan for contingencies for when things go horribly wrong.
Additionally, having software architecture design in place (whether it was created at the inception of the project or later) will help give your team a clear idea of what they are building, and how new pieces that they are adding fit, and how certain aspects connect to each other when making changes to an existing code base. Also, having reasons laid out for why certain decisions were made early on should help make changes to that aspect of the foundation easier and less disastrous.
Furthermore, the team having a better idea of the product leads to them spending less time untangling code and wondering why certain decisions were made. Giving your developer an accurate birds-eye view of the software gives bosts their confidence in their understanding of the software and enables them to design better code and come up with more robust bug fixes. That will all lead to an increase in morale, productivity, and development time.
Finally, it will also help with the onboarding process for new developers to your team, instead of letting them learn the software's architecture as they go.
Software Architecture design includes making decisions regarding 4 :
Going through each one of the items and making the choices appropriate for your software that falls within the business and real-life constraints, is the first and perhaps the most crucial step of the process but it does not end there. The process of SAD is rarely a one and done thing (teams who attempt to plan it all at the start almost always fail or get bogged down in too many minute details), it is an ongoing process that guides the software production.
The steps for core architecture design activities include 5 :
Software architecture design and software design sound extremely similar but they are not and due to the similar names often get mixed up. The major difference between the two is that software architecture looks at the big picture and how the big pieces connect and interact with each other, while software design handles the smaller pieces and how they are implemented 2 . One similarity between the two is that depending on your software you might end up using one style or a combination of two or more styles, i.e. your software might be a website that has both aspects of a client/server and component-based architectural styles (more specifics on styles below) 3 .
Making decisions on architecture are all well and good, but without proper documentation, it is about as useful as herding cats.
UML (Unified Modeling Language)
ADL (Architecture Description Language): this seems to be a special kind of beast, it appears to be a hybrid language somewhere between a programming and a modeling language. There is a list of different ADLs out there and the option to create your own that follow a set of requirements 8 .
4 + 1 model 7 : this method of representing SAD seems to be the most widespread model, it was created by Philippe Krutchen . As you can see in the image below it consists of 4 main views: logical, development, process, and physical; each view is targeted at a different stakeholder. The '+ 1' view or rather the fifth view is the scenarios, the stakeholders for this view is everyone and it proves that all the other views work together through validation and testing.
Ultimately, when it comes to documenting your SAD which language, tool, or model you use depends on you and the software.
Listed below are some of the architectural styles out there that I found interesting 3 :
Now for the final question: who is responsible for the architecture of the software? Some companies hire software architects that specifically manage that part of the product, an issue with that might occur is that they produce unrealistic designs causing the rest of the developer to ignore the design. I believe the best approach is an Agile one, one team member well versed in everything SAD and the rest of team actively contributing to the architecture design. With the whole team involved not only will the final architecture design be more robust, everyone will feel responsible, more informed, and a much higher chance of the design being followed.
I hope you found this post helpful (it's my first ever), I am open to any and all comments and feedback