Software Architecture: An Abstract Introduction

My dear reader, how are you? السلام عليكم

Without requirements and design, programming is the art of adding bugs to an empty text file – Louis Srygley

In this post, we will add another few concepts to our ‘web-journey‘ and understand the software architectures of modern-day and optimized web applications. Before jumping in directly, I suggest revising a few basics from previous posts: 1) DirectMe, and 2) DirectMe.

Building software is not just coding! and it is nothing new in this statement but most software developers forget to keep it in mind when it comes to building software. It eventually leads to creating a loophole in the software system. Creating software involve a lot of activities and phases and they are all important. I will now list all of them from start to end and give a few links to tutorials that explain each process in finer details. It starts with requirements engineering (what does that mean? DirectMe. what is it in case of software? DirectMe), analysis (what is software analysis? DirectMe), design (DirectMe), development, testing (what is software testing life cycle? DirectMe. You should also be knowing user acceptance testing DirectMe), acceptance (DirectMe), and deployment (DirectMe). Well, there is another crucial and important phase after deployment, i.e., maintenance and regular update (DirectMe). Let us revise them all in a summarized tutorial DirectMe.

Each stage requires an input from the previous stage and should result in a defined output. So with all this information, it is now easy for us to define software architecture. Software architecture is:

  1. how the defining components of a software system are organized and assembled,
  2. how they communicate with each other, and
  3. the constraints the whole system are ruled by.

The first part is also called an architectural pattern. The second part mainly refers to APIs through which the components talk to each other.  The third part refers to the non-functional attributes and is mainly concerned with quality attributes, i.e., scalability, resolvability, resilience, and adaptability etc. Some developers also call it the ilities of the software. It is important to keep it in mind as it impacts the software development phase. Many developers make a mistake and use the term software architecture and architectural pattern interchangeably. This confusion arises with their understanding of designing the architectural pattern as a major component of the software. Which actually is not true as you have already learned in the above definition of software architecture. In short, the architectural pattern is a part of software architecture and it refers to the overall structure of the software on which your code will be structured. Some common examples of architectural patterns include layered architectural pattern, microservices pattern etc. The architectural pattern defines the granularity of the pattern which also means how big or small should the individual component be.

What is the difference between the architectural pattern and the design pattern? Architectural pattern deals with the high level and universal components of the software and helps to understand how the individual components are organized and assembled. However, the design pattern goes to much deeper details and has a lower-level scope. It explains how the individual components should be built. So they both have a different scope but they do relate with each other. There comes a time when the architectural pattern restricts to have a specific design pattern in software. Architectural patterns are of many types, e.g., monolithic, service-based, or distributed. These patterns can be layered (n-tier), microservices (service-based) and event-driven (or plugin pattern) schemes. There are two more common patterns, i.e., service-oriented architectural patterns and space-based architectural pattern. Want more details? I would recommend a book which explains all of this in a very abstract way DirectMe. Design patterns can be creational, structural and behavioral.

In the future post, we will discuss each architectural pattern in detail. Stay in touch!

Leave a Reply

Your email address will not be published. Required fields are marked *