Written by: Joel, Senior Backend Engineer at Clevertech

Technological evolution

The ENIAC (Electronic Numerical Integrator and Computer) didn't go unnoticed, how could it? It took up the entire room at the University of Pennsylvania when it was created between 1942 and 1945. This was the first completely electronic general purpose computer created. Obviously hardware was really important in tech in the 40s and 50s. Now we see software architecture is the way of the future. But how did it get here and what are the requirements?

Software's Slow Rise to Center Stage

The technology industry became one of the most competitive businesses in the world and has not looked back since! Software gradually became a key technology for handling the simpler applications even for super complicated enterprises.

Despite having the momentum of the world behind it there wasn't a satisfactory toolset for supporting software development, the same for software development practices. In the meantime, the importance of maintenance crept out of the woodworks and was fundamental for bringing longevity to products.

Have you heard of [Margaret Hamilton?] (https://en.wikipedia.org/wiki/Margaret_Hamilton_(software_engineer)) She is credited as one of the computer scientists that coined the term software engineering bringing to the world the concept of building software. I will let her explain:

The Software Systems Nature

What makes a system well architected? Well, when the system does what the user expects, right? Yes, somewhat, you also need a quality evaluation that identifies successfully architected software attributes. There are two important attributes in particular that deserve our attention: reliability and maintainability . A certain level of reliability is essential to a software system, independently of its usage implying that the application will perform its functions as expected.

In this context, maintainability has two different aspects

• Need of repair: Defects which require fixes
• Need of evolution: New requirements satisfaction

Software architecture

Given the software growth in terms of size and complexity, problems started requiring bigger picture or macro solutions, in contrast to localized optimizations. The design of the global system structure frames these new software development challenges in a different way, - orienting the software development by the architecture.

The architectural software development comprehends structural components as:

• Project alternatives
• Performance & scalability
• Organization and general control structure
• Communication protocols
• Project components functionality assignment

It is important to recognize commonly used structures, and understand the existing architectures, which helps the engineers make better decisions about alternatives.

Requirements

Generally speaking, it is recommended to define system requirements during the initial steps of the development cycles, since they are the specification of what needs to be implemented. The requirements are descriptions of how the system should behave, contains domain information and restrictions about the system operation. While discovering requirements, a software engineer focuses on identifying the system's specificities which need to be supported. Once a set of requirements is identified it is possible to start an architectural project. The software development process oriented by architecture puts the architecture as a guideline, in other words it works as the process orientation factor, so we can also say that in an architecture oriented development the requirements are an essential aspect of the development process. The system complexity can be determined by its functional requirements (what it does) and by its quality / non-functional requirements (how it does). The distinction can be done using the following definitions:

Functional requirements

Software Requirement Specifies a functionality that the system or a software component needs to be able to perform. These requirements define the system behavior, the transformation process that software or hardware components do on the inputs to generate the outputs (Thayer, 1990).

Quality (Non-functional) requirement Describes how the software performs its tasks, not what it does. Furthermore, there are the performance requirements, restrictions and software quality attributes. Non-functional requirements are difficult to test, so they are normally evaluated subjectively. Non-functional requirements have a main role during a system development, they can be used as selection criteria for project alternatives, architectural style and implementation method. Disregarding or not considering these requirements properly is admittedly expensive and makes it difficult to correct once the system has been implemented (Brooks, 1987).

Quality requirements

Usability

• A quality requirement of any interactive system. Usability notion comes from the fact that any system designed to be used by people should be easy to learn and use, making it easier and enjoyable to perform any task. Ease to learn: Associated to the time and minimal effort required to reach a given level of performance using the system. Ease to use: Related to the task execution speed and reduction of errors while using a system.

Maintainability

• A quality requirement normally applied when referring to changes performed after the system is available to use. It is a wide term, involving repair of some existing error, as well as change / evolution activities.

Reliability

• A property of a software not causing a failure during a certain amount of time, under specific conditions. The reliability is generally defined on statistical behavior, it is the probability that a software will operate as expected during a known interval.

Performance

• Another important quality attribute for software systems. Given the impact it can cause, the performance requirements are the most important quality requirements. Furthermore, performance is important because it affects the system usability, impacting then the users productivity.

Reuse

• One of the characteristics of engineering is to make use of existing projects to minimize the effort of new projects. In this way, components which have been already developed and tested could be reused.

Principles

Finally, As a way to successfully implement a product where the identified system requirements are satisfied, there are some architecture principles that are highly desirable to be followed.

Separation of Concerns (SOC)

• The separation of concerns principle allows us to deal with different aspects of a problem focusing on each of them isolatedly. This idea can be applied in order to deal with inherent complexity. Its application can be observed when a system is decomposed in several modules, with the architecture containing more than one component.

Abstraction

• A process in which we can identify the important aspects of some phenomenon and ignore its details. Abstraction can also be seen as a special case of SOC, where we separate the important aspects of concern from the non-important details. By doing so, the engineers can concentrate on what they judge relevant and ignore the details.

Modularization

• When software engineers face a big / complex system they generally divide them into smaller pieces or modules A system composed of a set of modules is called modular.

Resources sharing

• In modular systems, the components should have a low level of coupling ideally, as it can become difficult to analyze, comprehend, change, test and even reuse highly coupled systems. However, it is still possible to have low coupled components even when sharing resources. The resources can be data or services which are shared across several independent components.