A concept, you couldn’t afford to miss
- You are planning to develop a dynamic web or mobile application or both.
- You have already deployed an application, but are facing too many technical problems in it, specifically related to robustness, upgrades, scalability, and maintenance.
This article covers:
- What is Application Architecture?
- What is the significance of a web application architecture?
- When should we start deciding the application architecture?
- What are the negative impacts that an unsuitable architecture can have on your project?
- What are the different types of application architectures?
- How to decide the architecture?
What is Application Architecture?
Every application has the following main components:
- Server-side components
- Database – The collection of data stored, retrieved, and processed by the application.
- Business Logic – The code that is responsible for the handling of the data.
- Client-side components
- Web Browser or Progressive Web app or Mobile app – The interface using which the users interact with the web application.
- Local database – The collection of data stored at the user-side
- External components
- Third-party services e.g. Google Map APIs, SMS gateway, etc.
An Application Architecture is the logical representation of components that indicates how these different components interact with each other.
What is the significance of a web application architecture?
Consider an example of a building construction project. The architecture of the building sits at the core of the building and decides the factors like durability, robustness, comfort, safety, etc.
A well-designed architecture takes care of risks and also the current and future developments that may be needed.
Similarly, a web application architecture plays a major role in the robustness, security, safety, maintainability, scalability, and many more aspects that decide the success of the application.
When should we start deciding on the application architecture?
Architects can work on the architecture of the building only when they know who are going to be the users, what’s their purpose, the types of features/functionalities required, etc.
Likewise, you should consider the application architecture once you have finalized the Empathy Map, Customer Journey Map, Experience Map, and Service Blueprint. If you are unaware of these terms, we recommend checking the article “UX mapping cheat sheet by Neilson Norman Group“
An architecture decided based on the initial requirements of the project is called an Immature Architecture, as it may not consider the risk factors and future developments that play a major role in the success of the web application.
Like any other kind of product, software products also evolve. People change, market requirements change, and market size changes.
While you may never face a dead end for choosing an unsuitable architecture, the right architecture can benefit you in the long run.
What are the negative impacts that unsuitable architecture can have on your project?
- Risks – Choosing an architecture that does not allow you or makes it difficult to add any feature that is important for your users increases your churn rate and reduces your customer retention rate. This puts the entire effort, budget, and time invested to develop the project at risk.
- Resource Optimization – The selection of an unsuitable architecture can result in the overuse of certain resources – e.g. an unsuitable architecture might consume heavy server resources for a simple set of operations. As a result, you end up spending unnecessary recurring costs for those resources.
- Efficiency – With an unsuitable architecture your developer and tester may end up spending significant time on redundant activities. With higher efficiency, you can build and release the updates faster.
- Time and cost – An unsuitable architecture will cause more time to develop the apps which will increase your development time and costs.
- Scalability – An unsuitable architecture can impact the scalability of your application, which increases the frustration of your users, and in some cases your sales and marketing team.
- Robustness – The inability of the web application to reduce the occurrences of errors or handle the errors will have a big negative impact on your business. An unsuitable architecture may not be able to ensure the robustness of the web application.
- Success – If you are losing your customers because of the above reasons, your web application will never be able to help you achieve your business goals, which fails the entire activity.
What are the different types of application architectures?
Single-page applications
This is an application architecture that allows the users to access different functionalities without reloading the pages. Such a web application may take a longer time to load the page initially. This happens because the web application has to load all the components in the users’ web browsers for the proper functioning of the app. But the subsequent loads happen faster( in some cases instantly). AngularJS, ReactJs, and Vue.js are some of those technologies using which you can develop SPAs.
Monolithic architecture
In this, the complete application is developed as a single unit. This means that all the services and components are built and deployed together as a whole.
This is suitable for applications that have simpler business logic, do not require frequent updates and all components use the same programming language.
If a complex web application is developed with Monolithic Architecture, your users may have to face downtime every time you upgrade the system. In such a case, you should develop a “System under maintenance” mechanism where users will get an appropriate message whenever the system goes down during an upgrade.
This architecture is not suitable for complex enterprise-level applications.
Microservices architecture
Microservices Architecture is suitable for applications that have a significant number of departments in an organization with distinct features and functionalities. In this architecture, each distinct module is developed as a microservice. These microservices are loosely coupled with each and hence, can work parallel to each other.
An example would be E-Commerce Marketplace which let us consider only two microservices namely, billing and shipping. A user who is in the billing department should be able to do his work independently of the shipping department. Obviously, he/she needs access to the shipping information frequently, but such information is logged in the database. So, due to any reason, if the shipping microservice is not functioning at the moment, the billing team will still be able to function properly.
Microservice architecture is popular among enterprise-level web applications. Don’t forget to develop a “System under maintenance” microservice to which you can route your traffic when a particular microservice goes down or requires an update.
Serverless architecture
Serverless architecture makes use of Backend-as-a-service platforms. The BaaS platforms provide three main components
- A database service where the data will be stored.
- An authentication service for authentication and authorization purposes.
- APIs for handling database operations and authentication.
In serverless architecture, the third-party BaaS platform takes care of the physical hardware, virtual machine configuration, performance, etc. It is equipped with rich APIs that allow the developers to process and handle the data and also provide the functionality to validate the data. Hence, your developer team will be focused on the implementation of the business logic of the application.
Examples of this would be the apps developed using Google’s Firebase, and MongoDB’s Realm.
How to decide on the architecture?
There is no fixed formula or process for this. It is similar to a construction project. You have to reach out to an experienced architect with the requirements and based on his/her experience, he/she can tell you which architecture is suitable for you.
Do your homework. Prepare the Empathy Map, Customer Journey Map, Experience Map, and Service Blueprint and share it with your consultant for a better and common understanding.
Note that throughout the article we have used the term “Unsuitable Architecture” and not “Wrong Architecture”. This is because there is no architecture that is wrong. There are pros and cons to each of those. It depends on the business case, requirements, functionalities, etc.
As the architecture provides a clear path to all the stakeholders of the project, we recommend finalizing the architecture before deciding on the technologies to be used to develop the project, so that everyone will be on the same page about the requirements and the expectations.