The right choice of software architecture saves time and money. However, various decision factors must be taken into account when determining the architecture. We present three in more detail.
As in classical architecture, software architecture also lays the necessary building blocks in the development of a new system. So that the suitable architecture for the software can be found, an intensive clarification with the customer is accomplished in the apron. The goal of this clarification is to determine the fundamental framework conditions for the use of the software.
Depending on the software, different characteristics and decision factors play a significant role. These decisions affect the development of the software, since they can entail time-consuming consequences depending upon. From the total quantity of all requirements finally the subset is determined, which is of large importance for the architecture. These are to be looked for mostly in the non-functional requirements, and can correspond for example to the quality and performance requirements. From this, the appropriate architecture can ultimately be derived.
"Those who have only a hammer as a tool see a nail in every problem."
Often, the wheel does not have to be reinvented. Usually, the requirements are compared with previous projects and finally a proven reference architecture is chosen. However, the weighting of the requirements should not be underestimated. If the wrong decisions are made, it is often difficult and time-consuming to rebuild the software afterwards.
Which decision factors play a decisive role in the choice of software architecture? There are many different characteristics that need to be taken into account. We take a closer look at three of them:
When it comes to performance, there are many questions that need to be answered for a system. But two of the most important are certainly how the system processes behave in relation to real time, and how the load on the system relates to the evolution of the number of users.
With regard to time dependency, systems are divided into three rough categories: Systems which control time-critical processes, those which have to react promptly and those which do not exhibit any special time dependency.
- For time-critical systems, a real-time capable environment must usually be selected in which the runtime of processes can be determined in advance (e.g. VxWorks or Linux with real-time kernel). These are used, for example, for missile control systems or processes in vehicles.
- For real-time systems it is often sufficient to set up a fast feedback loop. For network connections, however, special protocols often have to be used (such as RTP, VoIP, etc.). Interactive processes like video chat or interactive simulations are usually implemented as near-time systems.
Many systems are only intended for a limited group of specialist users, which does not change much during the life of a system. However, if the number of users changes significantly or the system is to be made available to a broad general public, it must be designed in such a way that the fluctuating load can be cushioned accordingly. Today, this is mostly realized via horizontal scaling of the critical system components (usually in a cloud environment).
Systems on which human lives depend require different measures than normal business software. Also, the processing of financial flows requires a particularly low error rate. This usually has an impact on the quality assurance process (especially testing), but can also be decisive for the choice of technology (e.g. programming language with integrated reasoning like Coq or ACL2).
Fault tolerance can also refer to how the system must be able to handle operator errors without falling into an unusable state (keyword Undo/Redo).
Particularly robust systems are usually designed with redundancy so that the failure of individual components does not affect the entire operation. Another important factor in this area is logging and debugging. If failures still occur, the reason must be found so that any program errors can be corrected. Consideration should also be given to the extent to which the software could become a worthwhile target for cybercriminals, and if necessary, other decisions must then be made regarding fail-safety.
How important is it that the system's processes are protected against access by unauthorized persons? This is not only about access violations from the outside, but also about internal authorization problems and violations.
Many systems process data that is considered particularly worthy of protection in a number of jurisdictions and is linked to special processing laws. Risk analyses related to data loss or espionage also fall into this area.
Depending on how the software scores on these (or other criteria identified as important), one can apply different architectural patterns. In the next blog post, we will discuss some of these architecture patterns in more detail.