The importance of modular architectures in mobile applications

When developing a mobile application, it is important to plan your technical architecture well from the start. Often many companies tend to focus solely on aspects such as user experience, usability or design, but the quality of the code or concepts such as maintainability and scalability, among others, are often neglected.

The result is an application that initially meets the expectations of both the company itself and the end users, but in the long term it becomes difficult to maintain — difficult to extend with new features, and a project that nobody wants to work on. In this article we will try to analyze these situations and how to avoid them

An architecture is a set of elements and decisions that define how the internal structure of an application's code should be (and should evolve). This concept is not specific to mobile applications, but has been present for many years in many software projects of any technology.

In the specific case of the apps for iOS and Android, an architecture is the way in which the different views, the code associated with them, the graphic resources, the business logic, the data models and the communication with services and databases and data persistence are structured, among others. It also describes how the different elements that are part of the structure of an application have to communicate.

It is quite common in mobile applications to not take technical design into account and give precedence to other aspects. It is important not to overlook how a modular architecture can benefit a mobile application if the project is moderately large. In the case of smaller applications, the use of this type of architecture would be considered overengineering

To understand this, it is best to use an example from everyday life: let's imagine that you have just acquired land and want to build a house on it. Nowadays there is a wide variety of options: prefabricated homes, modular homes, traditional construction, etc.

When one sets out to manufacture a house or to buy one that is already made, one looks at various aspects such as the type of materials to be used, their quality, the cost they represent for the whole work, durability and other topics of greater or lesser interest.

Depending on the choices that are made, the house that we build will be a luxury house or a normal house, it either will last 10 or 200 years, etc. This does not mean that one option is better than the other, but that we must take into account the number of years that we want to live in it or if we plan to completely renew it over time. We have to make sure that the project meets our expectations.

If we only focus on it being beautiful and functional but we do not take into account key elements such as the foundations, the quality of the walls and others, we will surely have serious problems as we spend time living in that house: humidity, noise from the outside, leaks... and endless problems.

Can you imagine a house where the toilet is in the kitchen and the bathroom has an oven? Surely you would not live in that house or at least you could not call it a home. But with a code we are not able to see these things if we do not have technical knowledge — surely in your application you have an oven in the bathroom.

We can have an application that is beautiful and functional in its launch, but the code may not be optimal and have many coupled features. In this scenario, extending that same code with new functions or maintaining it and looking for its errors to fix them becomes increasingly difficult. Following the previous example, relocating the toilet to the bathroom and the oven to the kitchen is not as simple as moving the elements, for that requires changing a large part of the installation.

It is a factor that not only impacts the project but also the rotation of technical personnel.

The architectures not being well thought out from the beginning not only causes problems for the developers, but also for the companies themselves. When a project has not been considered well from the beginning and someone is asked to continue expanding its operation, in the end it ends up generating frustration because things get worse. It is very difficult to structure something that was initially poorly planned, no matter how many hours are spent on refactoring code and rewriting certain parts.

This frustration often ends in problems between team members (usually between technical and non-technical people), due to the inability to transmit and make stakeholders understand that the application architecture was not well planned from the beginning. In the end, like everything in life when something doesn't work, it ends up breaking completely and people end up leaving. Every time a person on the team leaves, not only does a resource leave, but all that person's knowledge and experience as well.

It is usual to think that with a more senior or more experienced person we will solve the problem, since they will rewrite parts of the code that are not correct and thus there will be no more frustration. But usually the opposite effect is achieved: the more experience a professional has, the more easily they realize the structural problems of an application and will surely end up leaving the ship before a more junior profile, who will take longer to realize the situation.

It is a vicious circle, and end users keep waiting for updates with new features and bug fixes that never come.

The only possible solution is to rewrite the entire application, but changing the process. If you did not take into account the technical design when the project started, it is time to do it if you decide to start from scratch. If you try to rewrite parts or fix some small flaws, the root of the problem will always be there. It is like trying to solve a problem of coexistence without both parties acknowledging their mistakes with sincerity — the problem will reappear again over time.

Nowadays, modular architectures are a growing trend. They are not just a fad, because they  come to solve two main problems: maintainability and scalability. Let's see how they do it.

A modular architecture is one that allows you to divide an application into several modules. A module is a subset of an application that has:

• A unique responsibility. Just one
• A certain functional behavior and no others
• The ability to communicate with other modules but without knowing them completely.
• The ability to change its interior without affecting the exterior

This type of architecture uses a technique called divide and conquer, which consists of dividing a very large problem (a great application) into very small and specific fragments. This way, every time one of these modules is made it is like starting a project from scratch: if something does not work well, you can make it again.

The main difference with a traditional architecture is that the different modules can use and communicate with each other, but they should not know each other. This way it is relatively easy to change one piece that does not work, since the rest of the pieces will know how to communicate with the new one immediately. On a technical level, the description of this architecture is said to follow the SOLID principles, which you have surely heard of before.

Like everything in life, modular architectures have advantages but also disadvantages. Let's see what they are:

Most relevant advantages

• They allow you to redo parts that don't work without affecting the rest.
• They allow further development parallelization once the technical base is established.
• They facilitate maintenance by being divided into smaller and less complex parts.
• They improve the happiness of the team in the long term since they do not generate so much frustration.
• They allow to adapt quickly to new functionalities of the operating systems (eg the "App Clips" recently announced by Apple).

Most relevant drawbacks

• They require a greater initial effort: the economic investment they need compared to a traditional architecture is much higher. Mainly because you need very experienced profiles and you have to spend a lot of time writing technical documentation and carrying out complex technical analyzes that provide solutions to long-term business needs.
• They require constant monitoring: in order to avoid distorting the initial approach, it is essential to periodically monitor the status of the code, that the established guidelines are followed, etc. The teams that usually do these tasks are often called technical offices. It is not necessary that they be made up of many people, but it is strictly necessary that they exist.

At Opentrends we have solid experience developing modular architectures for large client applications.

If you are thinking of starting a new project that is going to have a long journey or your company is in a situation like the one we have described in this article (maintainability problems, impossible to add new functions, high turnover of technical personnel, etc.) We can help you avoid repeating the same mistakes again. Get in touch with us and we will be happy to help you.