A guide to a modular and future-proof software architecture

Abstract

Software architecture is one of the most important aspects of a software system. However, it is misunderstood in many cases. These misconceptions mainly occur within the definition of software architecture and the role of the software architect in the project team. Consequently, incorrectly designing a software system can lead to multiple problems during and after development. Software architecture should draw a high-level overview of the subsystems that are being realised. These high-level components should be replaceable to create modularity within the architecture. While modularity brings a lot of good aspects, it also makes the process of developing an application a lot tougher. Finally, within a project, the architect is responsible for communicating the architecture on a level that the team can understand and efficiently work with. These insights for future-proof software architecture allow the team to work on big projects simultaneously.

This article discusses

• Common misconceptions made about software architecture.
• Taking non-functional architectural concepts into consideration.
• The architect’s role and team discipline when developing an application.
• Writing code with or without design patterns.
• Shortening of developing time.
• Developing software in an environment-friendly way.

Keywords

Software development, Software architecture, Modularity, Software architect, Future-proof, Design patterns.

Introduction

Future-proof software architecture

At the centre of every software system lies its architecture, defined by a set of principles that satisfy both the commercial and technical requirements of the system (Medvidovic & Taylor, 2010). This foundation must be well-reasoned to increase productivity and minimise maintenance costs. There exists no single definition for future-proof software architecture and the usual answer is “it depends”. As a result, this poses an enormous risk while developing a software system. This article aims to provide the reader with a multitude of insights as an introduction to designing a future-proof software architecture. These insights will be substantiated together with our personal experiences and opinions on the subject.

Modular software

Multiple articles online are written about unnecessary complexity added to gain a certain form of modularity. Most of this complexity consists of a design pattern or architecture. Before a team starts developing software, they start by thinking about a decent design for their project. Secondly, the team starts building the software design, so everyone can adapt their code to the chosen design. Thirdly, everyone can develop and maintain the software. This whole process takes a lot of time and sometimes the added frameworks and complexity are a waste of energy. Because the software is more bloated, it takes more power to run properly. Adding complexity could cause wasting energy that could be saved by sticking to easier designs. In our professional experience, we worked on a software application named Project Everyware, where a certain kind of modularity was used built-in by the frameworks called Nest and Angular. Additionally, we used a thought up architecture in the Android app so further development would not take too much time. Using design patterns means that you must invest more time during the start of the project. However, when the project is running, everyone is able to start working on a modular component because you know what each component should do and how to attach it to the actual project.

Related work

Future-proof software architecture

In research conducted by the Microsoft Patterns and Practices Team (2009), it was stated that software architecture is the process of defining a structured solution covering all technical and operational requirements. While this defines the goal of software architecture, in our personal experience, this imposes a certain constraint throughout the development process. As research by Bosch (2004) suggests, it should be possible to add, remove and change architectural design decisions against the limited effort. Furthermore, the Microsoft Patterns and Practices Team (2009) believes the key design considerations are deployment strategy, appropriate technologies, quality attributes, and cross-cutting concerns. Although we were in disagreement with the first statement, we fully endorse this conclusion and believe these design considerations to be of great importance as they define the non-functional requirements of a software system. Finally, software architecture is a team effort as it requires discipline from all team members. A common mistake made by software architects is to act highly authoritative over the application architecture and micromanage every aspect of the development process (Fowler, 2003). According to Taylor and Taylor (2021), architectural decisions should not be made without the team’s presence, especially when they impose great changes in the current architecture. Essentially, every team member is the architect over their own module (Taylor & Taylor, 2021).

Modular software

On the Modularity Assessment of Software Architectures: Do my architectural concerns count?
The author discusses different views on why modularity is or is not an important factor in writing software. Also, he discusses how a certain kind of modularity is acquired by sticking to certain designs or patterns. In the first part of the document, the author points out why sticking to a design pattern is important and how modularity is key when one is developing software. The document shows an example of some logical design choices.

Although we disagree with always using design patterns, we agree with this specific pattern. The command pattern as this pattern is called, adds the possibility to easily use your software on multiple platforms, which ensures you are writing software in a different environment than your production environment and this saves a lot of development time.

The Structure and Value of Modularity in Software Design
In this article, the author speaks about the modularity gained by using certain software designs. Additionally, the author mentions thinking upfront about what modularity one needs and certain techniques to gain that modularity. Then the author explains multiple techniques on how to gain modularity and what sort of modularity can be gained in what way. The author values the design structure matrix, which creates a nuance between functionality and design. Although we agree up to a point, we still insist that creating a matrix and building a design is not always required within the scope of a project.

Traceability and Modularity in Software Design
In the report Traceability and Modularity in Software Design, Roel Wieringa (1998) speaks about requirements and specific designs. Mr. Wierringa says that a requirement specification is a description of the desired way of functional business objectives. We partly agree with this because a requirement specification should be more than just business objectives. In addition to business objectives, some other specifications like minimal system specifications should be added because the developer can write the software with a clear objective in mind.

Software Bloat and Wasted Joules: Is Modularity a Hurdle to Green Software?
The report describes how modular software uses more power and is therefore less economically and environmentally friendly. The author speaks about how software should be fully modular and written with a design pattern in mind. However, the author does not speak about cases when modular designs are necessary.

Analysis

Future-proof software architecture

In the previous section, a multitude of insights that make up the main considerations for developing software systems were provided. To summarise, software architecture should be modular and flexible; it must be possible to invoke architectural changes with limited effort (Bosch, 2004). Additionally, non-functional features should be considered (Microsoft Patterns & Practices Team, 2009). For instance, security is frequently overlooked in the initial design phase, as a result, the risk of security vulnerabilities increases (Sachitano et al., 2004). Finally, as software projects are usually in a team effort, they require good communication and discipline from all team members. The role of the software architect is to make sure that the project team is in a position to consult the architectural decisions made throughout the project (Taylor & Taylor, 2021), as well as mentoring the project team when needed (Fowler, 2003). In our professional experience as architects, we find mentoring the team on architectural decisions to be effective, because this way tasks are more efficiently delegated. As a result, it increases productivity in an agile work environment.

As mentioned earlier, software architecture should be modular and flexible. This concept has been proven in some modern based architectures where each functionality is divided into separate services that operate independently as opposed to a monolithic architecture where all features ship in a single application (Lewis & Fowler, 2014). In addition, one needs to consider non-functional features. A case study conducted by Sachitano et al. (2004) studied a software system called qmail. In the case of qmail, security considerations were included from the start. As a result, nobody has ever found any vulnerabilities in the system (Sachitano et al., 2004). In our professional experience, we find the above-mentioned considerations to be most helpful as they support future-proof development on large projects.

Modular software

Considering the advantages of using design patterns and modularity, a nuance between the two seems to be a perfect fit. Among the key benefits are:

• Easy maintenance of existing software.
• No need to study the software when someone is new to the project, since most of the time the newcomer has learned the framework beforehand.
• Design patterns are generic and easy to use so more time is spent setting up a project, but time is also saved maintaining the software.

On the other hand, some concerns against fully modular software are made. For example, some of the reasons against are:

• More complex software normally uses more power.
• The execution of excess function calls uses more resources. This means that one needs more resources and power.
• The creation of excessively large data structures also requires the use of more resources and power.

Since people started developing software, one of the big problems was that whenever someone wanted to work on some code, that developer had to study the old code to fully understand what was going on. Therefore, software designs and design patterns were created to ease the process of working on software that is yet unknown to newcomers.

Conclusions and recommendations

Future-proof software architecture

Over the years, it has been proven quite difficult to develop software architecture, as it is constantly evolving, making defining strict rules impossible. The gist of this article is not to cover the mentioned insights in depth. Instead, this article aims to inform the reader about the fundamental ideas of designing a software architecture. To conclude, designing a software architecture is a constant process of revisiting decisions. Consequently, it is the responsibility of the architect to communicate these decisions and streamline the development process.

Finally, since this article only covers the surface of the discussed subjects it is recommended that the reader uses this article as a starting point for further research on designing a future-proof architecture.

Modular software

The nuance between using or not using any form of modularity is clear: if the software ever requires maintenance, it is recommended to use a framework and use a modular design for your code. As described in one of the references, a design pattern uses more power than a non-modular piece of code, but further research should be conducted to know for sure what the difference is.

References

Bosch, J. (2004). Software Architecture: The Next Step. Software Architecture, 194–199.
https://doi.org/10.1007/978-3-540-24769-2_14

Cláudio Sant’Anna, E. F. (2007). On the Modularity Assessment of Software Architectures: Do my architectural concerns count? Lancaster: Computing Department, Lancaster University, UK.
https://www.researchgate.net/publication/250733753_On_the_Modularity_Assessment_of_Software_Architectures_Do_my_architectural_concerns_count

Fowler, M. (2003). Design — Who needs an architect? IEEE Software, 20(5), 11–13.
https://doi.org/10.1109/ms.2003.1231144

Kevin J. Sullivan, W. G. (2001). The Structure and Value of Modularity in Software Design. Charlottesville: University of Virginia Department of Computer Science. https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.29.1257&rep=rep1&type=pdf

Lewis, J., & Fowler, M. (2014, March 25). Microservices. Martinfowler.Com.
https://martinfowler.com/articles/microservices.html

Medvidovic, N., & Taylor, R. N. (2010). Software architecture. Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering — ICSE ’10. Published.
https://doi.org/10.1145/1810295.1810435

Microsoft Patterns & Practices Team. (2009). Microsoft® Application Architecture Guide, 2nd Edition (Patterns & Practices) (Second ed.). Microsoft Press.
https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ff650706(v=pandp.10)

Sachitano, A., Chapman, R., & Hamilton, J. (2004). Security in software architecture: a case study. Proceedings from the Fifth Annual IEEE SMC Information Assurance Workshop, 2004. Published.
https://doi.org/10.1109/iaw.2004.1437841

Suparna Bhattacharya, K. G. (2011). Software Bloat and Wasted Joules: Is Modularity a Hurdle to Green Software? IEEE Computer Society.
https://ieeexplore.ieee.org/document/6017179

Taylor, J. T., & Taylor, W. T. (2021). Software Architecture. Patterns in the Machine, 63–82.
https://doi.org/10.1007/978-1-4842-6440-9_5

Wieringa, R. (1998). Traceability and modularity in software design. Proceedings Ninth International Workshop on Software Specification and Design. Published.
https://doi.org/10.1109/iwssd.1998.667923