Knowing Software Architects – Part 3, Architecture Process

Hi everyone! In the last blog, we went into understanding the mindset needed to be an Architect. Stepping into the shoes of a Software architect may give us more details as to why architecture is a crucial step in the software development lifecycle

Today we are going to understand a bit more about the process that goes into designing a system, and the architecture process that a software architect follows.

So what does an Architect’s architecture process looks like? Read on to know more

Architecture Process

The Architecture process can be broken down into the following model:


Understand the System’s requirements

Remember, requirements describe what a system should do. This usually begins with a high-level task such as allowing users to view telemetry data and often also workflows, logical services and user interface elements. 

These may be usually defined by system analysts or those who work directly with the clients.

The first job in the architecture process would be to set up these meetings to understand what is actually needed in the system to be developed

Understand the Non-Functional Requirements

Non-functional requirements define the technical and service level attributes of the system.

For example, the no. of users, concurrency, heavy load, volumes of data and performance can be classified as non-functional requirements.

A client or system analyst may not always know these requirements so it falls to the Software architect to map them down there. They are for atleast the Software Architects much more important than regular requirements as many architecture elements depend on how the non-functional requirements are structured.

Map the Components

The next phase of the architectural process is to map the various components of the system.
The components are the moving parts of the system that represent both functional as well as non-functional requirements.

The mapping must have two goals:
a) To make the understanding of System functionality completely clear

b) To communicate the understanding thus gained to the Client

This phase is also completely non-technical and we are just mapping the components needed to understand the system.

Select the technology Stack

This is one of the most important steps in this process. In this process, a Software architect decides together with the development team which tech stack should be used for development

Usually, this is done for Front-end, Back-end, Data Store etc.
There are a lot of factors for this selection and thus must be decided wisely.

Design the Architecture

Now the job is to design an architecture for the system that is first secure, reliable and easy to maintain. It must have qualities like loose coupling, caching, messaging and lots more that act as the building block of the architecture. This however is not the formalization of the architecture and is basically a brainstorming and mapping session where we combine learning from previous steps to form architecture to our needs.

Write Architecture Document

This is the greatest creation and the culmination of an effort that an Architect has put into the system designing process. 

It describes the whole process that underwent the designing process and gives the developers and management the full picture of the system that is going to be built. 

A good architecture document is relevant for all the levels in the organization like the CEO, the CIO, the project managers and of course the developers.

Support the team

The job of a software architect does not end with just the Architecture document creation process. The architect must be there for the developers to help them make sure they are developing according to the software architecture document.

There will be questions and dilemmas raised that are going to be a part of the development and the architect must be there to either resolve them or make sure to incorporate necessary changes in the architecture so that the architecture document does not become a glorified paperweight.

The job of the architect is not done until the system is in production and even then there might be a lot to do.


So that is it for part 3! In part 4 we shall explore more about working with System requirements and the types of Applications involved

Discover more in the next blog!!

I keep on coding something cool, visit ankush.tech to see what all I am doing!

If you wish to read about my work, here is a book that I published recently – “CSS Bullets, a comprehensive guide to all the CSS you need!

Interested in React? Learn react from scratch with my book, “REACT Bullets“.

Not subscribed to the newsletter? Subscribe now!!!

Thanks for sticking around!

Leave a Reply

Discover more from The CodeWolf

Subscribe now to keep reading and get access to the full archive.

Continue reading