The software development process has many techniques for (functional) requirement gathering. Mostly functional. As architect, one must consider many other factors in addition to those requirements that are not directly related to the domain functionality.
The important aspects of the system, independent of the problem domain.
Characteristics describe our desired behavior of a system across different dimensions. it is important to understand the desired characteristics and to make an explicit commitment to them. A system must not comply or concern itself about all the possible Architecture Characteristics that we can think of, cause for each system, this will differ.
What is important, is that a conscious and explicit decision is made of what Architecture Characteristics are important for given system. In addition these decisions must be clear and preferably quantifiable so it is easy to asses of the system complies with desired characteristics or not.
Characteristics are often interconnected. This means it can be often challenging to accommodate various characteristics as they might oppose each other in design. Hence, why it is important to be picky and limited in the preferred characteristics that you prioritize. As always, it’s a trade-off.
Note: Non-Functional requirements are the same, but not considered a good name.
Everyone might create their own interpretation of these terms, but we commonly separate them into 3 categories.
A universal list doesn’t seem feasible, there are various variations and interpretations of possible characteristics. Ideally you make a list with definitions for your organization to align around the names, definitions, and their scope.
However, below is a list of examples to help you get started. You can also see the ISO 25010 list for inspiration.
| Term | Category | Definition/Example |
|---|---|---|
| Availability | Operational | How long does the system need to be available ? (e.g. 99.9% up) |
| Continuity | Operational | Disaster Recovery capability |
| Performance | Operational | Response time |
| Recoverability | Operational | Business continuity requirements (e.g. ISO27001) |
| Reliability | Operational | Fail-safe? Mission critical in a way that it affects lives |
| Robustness | Operational | Ability to handle errors and boundary conditions while running if the internet connection drops |
| Scalability | Operational | Ability of the system to perform and operate as the number of users/requests increases |
| Configurability | Structural | Ability for end users to change aspects of the software configuration |
| Extensability | Structural | How important is it to plug new pieces of functionality in |
| Installability | Structural | Ease of system installation on all necessary platforms |
| Reuse | Structural | Ability to reuse common components across multiple products |
| Localization | Structural | Support for multiple (human) languages |
| Maintainability | Structural | How easy to apply changes and enhance the system |
| Portability | Structural | Does the system need to run on more than one platform? |
| Supportability | Structural | What level of technical support is needed by the application ? |
| Upgradeability | Structural | Ability to easily upgrade from previous versions |
| Accessability | Cross-Cutting | Access to all your users, including those with disabilities |
| Archivability | Cross-Cutting | Will the data need to be archived or deleted after some time ? |
| Authentication | Cross-Cutting | Security requirements to ensure users are who they say they are |
| Authorization | Cross-Cutting | Ensure users can access only what they are allowed to access |
| Legal | Cross-Cutting | GPDR ? Data protection ? |
| Privacy | Cross-Cutting | Ability to hide transactions from internal company employees. |
| Security | Cross-Cutting | Does the data need to be encrypted at-rest or in-transport ? |
| Usability | Cross-Cutting | Level of training required for users to achieve their goals |
The aforementioned list is mostly about implicit architecture characteristics, there are at least 2 more ways to uncover architecture characteristics:
Listen well to domain/business stakeholders and understand their concerns. Don’t mistake a single concern as one characteristic.
| Domain Concern Example | Architecture Characteristics |
|---|---|
| Merges & Acquisitions | Interoperability, Scalability, adaptability, extensibility |
| Time To Market | Agility, Testability, Deployability |
| User Satisfaction | Performance, availability, Fault tolerance, testability, deployability, agility, security |
| Competitive Advantage | Agility, testability, deployability, scalability, availability, fault tolerance |
| Time and Budget | Simplicity, feasibility |
Sometimes there are explicit requirements (e.g. min/max amount of users) or just from having a lot of domain knowledge. If you have a class registration system that is once per year used, for 24h, all students will need to use it. You probably only need to deal with a small peak, and further not worry about availability.
Common problems around the definition of architectural characteristics:
There are 3 types of measurements:
Governance is an important role of an Architect, negligence can lead to disastrous quality problems. Fitness functions are excellent to help with this.
When architects talk about scalability, generally that discussion is around the scalability of the entire system. That was a safe assumption a decade ago when everything was monolithic. With the advent of new architectural styles like microservices, the scope of architecture characteristics has narrowed considerably. When evaluating many operational architecture characteristics, an architect must consider dependent components outside the code based that will impact those characteristics.
In modern systems, architects define architecture characteristics at the quantum level rather than system level.
To successfully design, analyze, and evolve software, developers must consider all the coupling points that could break. To identify these coupling points, consider the architecture quantum boundaries. So what is an architecture boundary?
An independently deployable artifact with high functional cohesion and synchronous connascence.
| Fundamentals of Software Architecture | Chapters 4, 5, 6, 7 |
