Category: Blog artikelen
Author: Ardiles Mozesz, Developer

Choosing the right application architecture

Today, most organizations within IT projects work according to the Agile/Scrum methodology. One of the characteristics of this is that one starts small and starts developing a 'Minimum Viable Product', abbreviated to MVP. Often the simplest application architecture is chosen: a monolith. For example, the MVP principle is applied with only one view, one controller and one model. As far as we are concerned, this is certainly possible, as long as it remains a small and simple application.

Small applications grow big

Our experience shows that the original small application is often extended and becomes much more complex. As soon as a first version of the MVP is finished and used by the business for the first time, the added value of the application really becomes clear. The business analysts then continue to work on optimizing the relevant business processes.

As a result, the size and complexity of the application will increase. And because the business sees this added value, the pressure on the productowner and the development team will also increase. In many cases, the focus will be on further developing the application as quickly as possible and bringing new features live.

Increasing development capacity

In order to develop new features even faster, the organization can take a number of measures. For example, the development team can be expanded with additional software developers. This often goes well in the beginning, but at a certain point the development team reaches maximum velocity. As the size and complexity of the application increases, there are also more and more dependencies between different pieces of code. This makes it a greater challenge for the developer to adapt existing functionalities and to add any new functionalities.

In practice, we see that the existing functionality falls over sooner, but also that new developers need more and more preparation time before they can write a letter of code at all. It's sometimes said, "Let's add an extra development team". But that makes the project even more complex, since we all work in the same pieces of code.

That's when we say that the basis of the application, the application architecture, is no longer adequate.

From a monolith to a modular design

Changing the application architecture to a modular design offers, among other things, a solution to the problems described above. For this, the basis of the application needs to be modified, but this has an impact on the existing code. Consider in good time whether the application architecture is still adequate, because the longer you wait, the greater the impact on describing the existing application architecture.

But what does a modular design mean?

A modular application architecture design means that an application is divided into smaller modules. Each module has a logical function and its own responsibility, with the goal that each module can perform its task separately. A combination of the modules forms the final application. This brings a number of advantages, which we will briefly explain below using examples.

1. Reducing complexity

A complex piece of code can be divided into smaller, separate and more simple tasks. This reduces the complexity of the overall application.

2. Scaling up in development capacity

It is easier to scale up the development capacity. Multiple developers/teams can work on one program at the same time. Each developer can work on a separate module without the need for in-depth knowledge of the other modules.

3. Reduced application time

The familiarisation time of a developer is reduced. The developer can focus on a specific part of the application, instead of the entire application. This is possible because the application is split into several modules.

This makes changes to existing functionality, but also new functionality, faster and easier to implement.

4. Analyzing issues

Issues in the software are easier to analyze and fix. This shortens the resolution time of bug fixes. In addition, issues relating to performance, for example, can be analysed more easily and quickly. This is because the focus is only on a part of the entire application.

5. Reusability of modules

Modules are reusable so you don't have to build and maintain the same thing twice. For example, it is possible to use modules from one program in another program without having to make any changes to these modules.

6. More manageable

The refactoring of the code will become more manageable. Take, for example, a library that is used by the entire application and needs to be upgraded. One has the choice of whether or not to upgrade each component. In this way, one can weigh up per component how much effort it will cost and what it will eventually yield.

What else do you have to take into account?

Compared to a monolithic application architecture, a modular application architecture design initially takes more time to establish a basis for an application. What is especially important for the developers is that they get a sense of where the application is heading. It is the task of the productowner to properly map out the wishes of the business in the short and long term.

As soon as several developers start working on different modules for the same application, good coordination and communication between the developers is important. Despite the fact that modules are developed independently of each other, there are indirect dependencies such as api's, migrations, release schedules and functional links.

Since the development process is often a technical party of the developers, it is also important that the productowner and business are regularly and well informed by the developers.

A modular application architecture can be overkill for a simple small application. We therefore advise to apply this architecture to the more complex and larger applications and/or more business-critical applications. This requires a lot of knowledge, skills and experience to make a good decision. Therefore, always call in an experienced expert who can provide concrete advice that suits your organization.

Specific questions?

Enter your e-mail address and Oliver IT will contact you as soon as possible!

Done! We will contact you soon!
Gerben Moerland Partner
Gerben Moerland