Importance of getting the application architecture right

To successfully create anything, you have to get the base right. Whether it is constructing a building or making a pizza, if we don’t get the base right, we have to start over. Yeah! I know. But there is no other way around.

Building a web application is no different. The architecture is the base and has to be carefully thought through to avoid any major design changes and code refactoring at a later point.

Speaking from experience, you don’t want to delve into re-designing stuff. It sucks up your time like a black hole and has the potential to push your shipping date further down the calendar by months, if not longer. I won’t even bring up the waste of engineering and financial resources caused due to this.

How much we have to refactor largely depends on the stage of the development process we hit an impasse due to hasty decisions made during the initial design phases. So, before we even touch the code and get our hands dirty, we must make the underlying architecture right.

A look at our app’s architecture should bring a smile to everyone’s face. I understand that software development is an iterative and evolutionary process. We don’t always get things perfect on the first go. Still, this can’t be an excuse for not doing our homework.

An overview of the software development process

In the industry, architects, developers and product owners spend a lot of time studying and discussing business requirements. In software engineering jargon, this is known as Requirement Gathering and Analysis.

Once we are done with the business requirements, we sit down and brainstorm the use cases we have to implement. This also involves figuring out the corner cases as early as possible while trying to fit the building blocks together.

If you’re a fan of documentation, you might also want to write a high-level design document.

Once we understand the business requirements, use cases, including the corner cases, it’s time to start the research on picking the right technology stack to implement our application.

Proof of concept

After we pick the fitting tech stack, we start writing a POC (Proof of Concept).

Why a POC?

A POC helps us get a closer, more hands-on view of the technology and the primary use case implementation. We get an insight into the pros and cons of the tech, performance, or other technical limitations, if any.

It helps with the learning curve if we’re working with entirely new tech. Additionally, the non-technical people, like the product owners and stakeholders, have something concrete to play with and base their future decisions on.

Now, this is only for an industry scale product. If you are an indie developer or a small group, you can always skip the POC part and start with the main code.

So, we showcase the POC to the stakeholders. If everyone is satisfied, we get a green light to finally get down to creating the main repo and our first dev branch on GitHub or any similar code hosting service the business prefers.

Phew!!

By now, you would have realized the importance of getting the application architecture right the first time and the knowledge of web architecture to software developers.

Course design

The course is divided into two parts. In the first, we discuss the concepts and the architectural components involved in designing web applications. You will get insights into different tiers of application architecture, monolithic repos, microservices, peer-to-peer architecture, and much more.

In the second part, we will go through some of the use cases of designing the architecture for applications that we use in our daily lives and are well familiar with.

We will also understand how applications are designed from the ground up. What is the thought process behind picking the right technology stack for our use case and so forth?

So, without further ado, let’s get started.