Why so SAD?

#software #design #architecture

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 ¹.

Why bother with SAD

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.

What SAD is

Software Architecture design includes making decisions regarding ⁴:

Application Type
Deployment Strategy
Appropriate Technologies
Quality Attributes
Crosscutting Concerns: this covers such things as logging, authentication, and caching

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 ⁵:

Identify Architecture objectives
Have a list of key scenarios (use cases)
Application overview
List known and possible key issues of decisions made
Candidate solutions: prototype the architecture and run it through the list of key scenarios to ensure that all requirements are being met
Repeat the above steps until both requirements and stakeholders have been satisfied

SAD and Design

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 ². 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) ³.

Tools

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)
- This pictorial language is perhaps the most well know out of this list and is used not only in SAD but also in software design, and database design.
- If you are looking for a detailed tutorial I recommend Tutorial's Point UML
- For making UML diagrams the tool I usually go with is draw.io created by Google, Microsoft's OneNote can be utilized as well. Another tool I have seen listed numerous time is MagicDraw
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 ⁸.
4 + 1 model ⁷: 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.

Some SAD Styles

Listed below are some of the architectural styles out there that I found interesting ³:

Client/Server:
- Category: Deployment Architectural Style
- A distributed system that can have one or more client and one or more servers connected through a network.
- Advantages ⁹: improved data sharing, clients can integrate n number of services, maintenance is easier since it is a distributed system, and more secure because almost all servers come with authorization
- Disadvantages: there is a higher chance of data loss in these types of systems, and it could become costly to setup proper server backups and georeplication for better worldwide reach.
- Examples include: Websites, FTP clients, and data tools
Component-Based Style:
- Category: Structure Architectural Style
- This style focuses on breaking the design of the system into smaller and reusable chunks
- Advantages: Ease of deployment and development (components can be switched out without affecting the rest of the system), reduced costs (less money spent developing existing software), reusable, and reduces technical complexity.
- Example: bootstrap
Service-Oriented Architectural (SOA) Style
- Category: Communication Architectural Style
- This style provides services and functions, it is somewhat like component-based architecture in that it is modular but it tends to over more complex functionality.
- Similar advantages as the Component-based style
- Example: Amazon's Lambda

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.

References

I hope you found this post helpful (it's my first ever), I am open to any and all comments and feedback