Creating a software is not just about coding. It involves many activities, such as gathering requirements, analysis, design, development, testing, deployment and maintenance.
Software architecture is definitely about gathering requirements and analysis but it also affects the decisions that will be taken in the other phases.
Software architecture is the art of drawing lines that I call boundaries. Those boundaries separate software elements from one another… — Uncle Bob Martin
The architecture is the input of the development phase, and it defines:
- How the components are organised and assembled
- How the components communicate with each other
- The constraints the system is ruled by (scalability, availability, resilience, adaptability, …)
I picked 5 different architecture approaches, trying to describe briefly their characteristics and cases of use. Descriptions are not exhaustive, this is just a very high level description of these architectures. At the bottom I added a few links to other posts or books, in the case you want do dig deeper on one of more of these architectures.
