Architecture design — detecting non-technical functional requirements and selecting relevant software quality attributes
The main driving factor for architecture decision is business. Depending on the needs we will choose a different architecture, it might be fully serverless, monolith, or service-oriented architecture with ESB. Good understanding of business requirements is key to success.
Why should we care about how our architecture will look like? Because the main requirement is that we want to build better software faster. It will allow us to deliver business features quickly and cheap. From a business perspective, this is important to have information as fast as possible whether something works for users or not.
The requirement breakdown
From an architectural point of view, every high-level requirement is composed of two things: function requirements (related to the domain) and non-function requirements (related to applications architecture) based on which the engineers team can select relevant quality attributes and work on them.
How the process of making a decision can look like?
I will describe to you the already tested process which I used in a few different companies and products. Starting from a new, small application in startup and ending in huge corporation applications with millions of users. All data used in the example were invented for this exercise.
There is an engineers team in one of the biggest company in the insurance industry. Business requested extending module for new features. In past, there was not much investment in this area, so this is a small module with low responsibility. The existing system is written in monolith architecture and hosted in the company, local datacenter. From time to time the system is down, mostly due to performance issues, as there is a problem with scalability machines. Many teams work on the same code base so feature delivery is slow. The frontend layer is written in jQuery in a way that reusing components is impossible. UI was not refreshed for 5 years and looks legacy, the user journey is quite long.
Steps which I usually take:
- Detect non-functional requirements for new features.
- Select relevant quality attributes that satisfy founded non-functional requirements.
- Choose the right technology and patterns to meet the targets for selected quality attributes.
Step 1: Detecting non-functional requiments
Non-functional requirements are about how the system should work rather than what the system should do. It’s judging on availability, security, capacity, or any other attribute, examples of requirements:
- In the next 6 months, we expect up to 300 000 users online at the same time during the day
- We plan to store very sensitive data from our customers
- We have customers across the world, our application should be fully available 24/7
- Features built-in one part of the application should be easily reused in any other place
- Our target group are people above the 50-year-old, the application should be easy to use
Step 2: Select relevant quality attributes that satisfy founded non-functional requirements.
At this point, we already know non-functional system requirements. Basing on them we can identify quality attributes. It will give us clarity on what should we focus on:
- Scalability, due to expected huge traffic in the next 6 months. In addition, the current legacy system has already a problem with performance.
- Security as a system will store very sensitive data.
- Availability and recoverability, because the system will be used by customers across the world 24/7.
- Interoperability to be able to reuse features across the platform.
- Usability as a system will be used by older people
There are many more available quality attributes I encourage you to read more about them to be sure that you will detect all of the possibilities. List of attributes: security, serviceability, manageability, recoverability, regulatory, usability, capacity, data integrity, environmental, interoperability, availability, scalability, reliability, and maintainability.
Usually, I did not have space for addressing all of the listed quality attributes once. In such a case I choose few the most important, but with giving the possibility to resolve others in the future.
Step 3: Choose the right technology and patterns to meet the targets for selected quality attributes
As an engineers team, we know that there will be no space for resolving all attributes in the first stage. Due to that, we will focus on fundamental ones.
We will create a new dedicated service for this domain, which will be hosted in the cloud instead of extending the existing monolith. It will allow us to scale independently and automatically this piece of application depending on customer needs. We are aware that it will require setting up a new CI/CD pipeline, which is additional work in comparison to the previous one.
In the first iteration, there will be one service, even the responsibility will be higher, but written in a way where we can easily separate it into other services or microservices.
Availability, and recoverability ✅
Cloud provider allows us to deploy our application in a data center on the other side of the world, so availability and performance will be high. In addition, we will create a new dashboard for monitoring which will notify us in case of emergency. Service will have implemented a health check pattern described in my previous article Microservices — part 1: Health check API in practice.
All data in the system will be encrypted by us or by the data storage provider. The decision on this will be based on development estimation and final cost calculation.
The display layer will be built with the usage of React and TypeScript as independent applications hosted as static files. Components will be not reusable in any other piece of application, however, it will be built in a way in which publishing it for other domains in the future will be easy.
We know that UI/UX department is now overload by other domains, due to that we will design the system on our own to not having any dependencies. In case of needs for any improvements, we can address it later.
As you can see not all quality attributes were addressed, the engineering team decided that the fundamentals ones are scalability, security, availability, and recoverability. Usability and Interoperability will be covered in future improvements.
Detecting the most important elements is a key to success, I usually focus more on the infrastructure and backend side, rather than on the display layer. It’s much easier to adapt or even replace all display components than make any heavy changes on the backend side.
There are many ways to design correct architecture, in this article I described a way in which I work on a daily basis. For cases which I had, it was the most effective way. Cross fingers that you found anything useful for your case or I just confirmed that your way of designing architecture is better! 😊